chipsy

Protectionist tariffs did, in fact, play a role in the action of the Great Depression.

Such policies, which were adopted by many countries during this time, contributed to a drastic contraction of international trade. For example, U.S. imports from Europe declined from a 1929 high of $1,334 million to just $390 million in 1932, while U.S. exports to Europe fell from $2,341 million in 1929 to $784 million in 1932. Overall, world trade declined by some 66% between 1929 and 1934.

[0] https://history.state.gov/milestones/1921-1936/protectionism

I'm optimistic about it, though I admit that I haven't tried it. Code written by a mob would have the benefit of receiving intensive review at the design phase. There wouldn't be many opportunities for a mob project to spiral out into duplicate functionality or mismatched modules. It's also potentially less taxing than pairing because you'd get the chance to sit back and ponder higher-level issues without constant prompting to fill in the next line. So the overall result should be higher quality in the average case, with less siloing of knowledge, and smoother daily output.

There are cases where you'd want the team to work more independently, but they have to be weighed against communication costs. Those pile up quickly on any team.

It can be done but it's quite expensive to engineer such a solution, both in time spent theorizing and in runtime performance consequences. There are many small gameplay features that are trivial with mutability and a data-oriented model, but require a major spec change if functional style is applied. The parts that are easy to do functionally are relatively trivial in comparison.

The happy medium for gameplay simulations is to write straight-line imperative code and minimize your use of subroutines and indirection - you want "static" synchronization that loops over data in big batches where execution flow reads easily. When it's kept simple like this, major desynchronization challenges come down to compilation behaviors and interactions with other modules(render, network, etc). The main loop gets big as a result, but factoring it out only makes it harder to follow, because the complexity is coming from the high number of sync points, not duplicated code.

At the core of XML you can still see the SGML origins. It is great stuff if you have an actual document to work on - like, documentation, or an essay, or a manual... there are some very comprehensive schemas and renderers around for those use cases, that can do heavy lifting where Markdown or Word start failing you, and TeX is inappropriate.

What polluted XML the most was simply being overhyped, especially as "human-readable". It's not binary, but it's also not a good front end for any human task. Although it's capable of flexible markup, that makes it an inefficient source format. Even in the case where you have a document to write, it can be more palatable to parse something simpler and convert it, and then apply finishing touches to the XML where the precision works in your favor.

That said, most data is not really a document, but a tiny fragment with relations. Documents only make sense once you have some kind of story to tell.

Image editing is one of those great examples of the workflows being so diverse that no generalized interface solution will be very good for all of them.

What's tickling my brain at the moment is the idea that these complex apps might be better as languages first, just shipping with thousands of well-organized example scripts that cover all the bread and butter - in the same way that synthesizers moved towards being preset-centric over time, to the point where one of the big features of new VST plugins is the content they ship with and the ease of browsing it.

IFF is still relevant even now if you want a really straightforward binary blob package. There's almost nothing to it for basic parsing - just watch out for the byte alignment padding and endianness, and default to loading chunks by name, not order.

(On that note, a lot of software that works with IFF/AIFF/RIFF will "do it wrong" and expect a particular chunk order for the data it works with, which over the years has led to a lot of "fix-up" software for cranky programs needing massaged data.)

And I think he's heavily overrated because he presents well.

For one thing, his basic premise is not really much different from Engelbart and Kay.

For another, he doesn't propose specific processes or nuts and bolts design. The thinking trails off after "and then we make it more interactive..." Again, Engelbart did this. We've incorporated some pieces of it. We can still refine things. But the design problems always exist in the realm of compromise - if we automate more, we also have to specify more. General purpose solutions tend to fall back towards tried and true. When you put up a slick interactive demo, you have the benefit of being able to solve a very small problem, very precisely.

You know what UX problem needs the most solving? Documentation. You made a thing to automate a thing. But you didn't document it. So it's too non obvious to bother with. So it doesn't get used. The best work that Victor, Case, et al have done is fundamentally a form of documentation, not expressive tools. I've seen lots of folks try to take the lesson to heart and make their app more like that documentation. But it's a mess because it tends to leave out some necessary level of power or performance to be a good tool. It's extremely expensive to add the interactivity in many real world cases.

If seeking pleasure is dull and boring, then it must be a rather difficult task to sustain daily pleasure over a lifetime.

Enlightenment, in comparison, has the notion of finishing built into it, and finishing at philosophy is a rather troublesome idea too.

I personally believe that it is the practice, not the narrative, that makes a philosophy work. A very modest idea can allow a lifetime of ponderings.

The numbers are better than private automobiles driven by humans, but they cannot exceed the potential of trains and buses because of simple geometry: more space is used per person transited when they have to run as a fleet of small, independent vehicles.

This makes PRT a fine idea, by itself, at medium densities, but troublesome in the context of existing road and rail systems that are set to be fully roboticized and "shared" in coming years. Each time we squeeze more capacity out of the existing paradigms, PRT loses a little bit of its appeal.

The silver lining in this cloud is that the general idea of coordinating traffic better is very promising. Several new PRT-style ideas have a notion of a "modular" highway that smoothly loads taxi-style shared vehicles into trains while in motion, eliminating a major transfer delay. Because the vehicles are shared you don't get the parking issues or the stops that dog traditional rail - just a very smooth, fast point-to-point with a bit of climbing in and out of cabs.

The biggest weakness of all existing transportation is that it's "lumpy" and oscillates between overcapacity and overcrowding very quickly, whether it's a highway or a subway. What changes is how this turns into a user disadvantage - either in vehicle congestion and heavy land use impact, or frequent stops and crowded cars.

Pascal will cover a few of your points and move you sideways on others. For example you do have a required forward declaration but it's all in a single module file. FPC is a good compiler and should cover most concerns around tooling. And it's all been documented in depth at some point, although you might be studying from pretty old sources.

But because it remains a pretty simple language, it's not going to have so many nifty time saver features. If you're going for that you might be better served with a "new and hyped" language like D or Nim - those languages aren't as convoluted as C++ but they are still complex.

I see Africa now like China in the late 80's or early 90's - the change is there, but the perceptions haven't shifted yet and anyone doing business there faces a situation of chaotic progress. A good place to be if you like extremes of risk/reward.

I surveyed my own VSTs when I went to implement a synth UI knob and discovered that most actually behave like a y axis slider. A few, like Synth 1, will teleport the cursor to an actual slider as you start dragging. The ones that try to make you literally "turn" it are by far the exception.

As for other feedback... it's unusable for me. Notes are triggering unexpectedly or get stuck, the interface goes unresponsive for seconds at a time and then suddenly catches up. I haven't been able to see what the knobs are like on this program because of the unresponsiveness. Tested Firefox 42, Chrome 46.0.2490.86 m.

I can play a few chords, at least. It reaches hard clipping distortion easily when I do that.

Gender is - or was - convenient. With binary genders you have a convenient model to categorize people into different groups, in the same way that you can categorize by age, skin color, language, homeland, or religion. Politically, categories are mostly used to drive up the "us vs. them" tension factor that unifies groups, and pushing for harder-edged definitions of gender and gender roles is a convenient way to politicize just about everything in a human life. Further, it naturally works out that your voting bloc floats at around 50% when you appeal to the gender binary, which helps sustain the division in a way that you can't get with things like "race" or "religion".

Of course, one of the truisms of data modelling is that it never captures 100% of the system, and it's guided by your expectations of what the system will look like. Our push to digitally model everything exaggerates all the points of breakage. In the same way that you end up with people whose legal name are flagged fake by Facebook, or reverse image searches that think black people are "gorillas", you end up with a lot of data points that are bad fits for a model of binary gender.

This is not a huge surprise when humans are equated with other mammals in all their variety. But we have the problem of being emotional, well-socialized, and biased first, and smart second. So we're probably just going to have an extremely long culture war to rethink this categorization, with specious arguments trotted out at every turn.

We're basically approaching the part of the Myer and Sutherland wheel of reincarnation[0] where the display processor is as powerful as the main processor and therefore it should all be folded back together. Of course, this turn was anticipated by AMD well in advance, and the GCN architecture, APU hardware, etc., all plays into it.

At the end of the day, the optimization envelope is always shifting around, and industrial computing architectures chase that incrementally, so they'll always be looping around the wheel as today's "narrow fast path" gradually becomes tomorrow's "general purpose".

[0] http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland...

I don't think it's about the surface politeness factor, but about what kind of discussion is conducted.

The ideal for an intellectual discourse is to have questions be responded to with more questions. If question is met with answer, then old ground was covered, there was nothing new to see. If answer is met with answer, you're just ramming into each other. (And yes, there are disingenuous questions, but those tend to be "Jeopardy answers".)

Politeness/rudeness does factor into that in that it "bulks up" the rhetoric. You can be a polite bullshitter or an insulting truth-seeker. You can use rhetoric tactically to goad the other person into the questioning mode, or you can use it to shut down the discussion.

Protest was once a thing that was mostly practiced on a local level, within the family and church, and subject to the constraints of small groups. It is now fully secularized and pushed into the hands of the masses. There is a subculture for everyone.

And this works against "strong and silent". Strong and silent is not particularly noble in practice - it's a self-sacrificing game theoretical strategy. To take the upper hand in social situations, you avoid showing vulnerability and instead consistently display strength. For any problem someone cares about, you will show that you don't have to care, that you'll soak up the consequences rather than try to help. For any threat presented, you shrug it off or escalate until they cave in. Then everyone else has to bend to your wishes if they want your cooperation.

The ideal strong and silent person is psychopathic. Most people trying to follow it tear themselves up to do so.

The alternative is to allow the small complaint, to whine a little bit about how something wasn't right today. Because you have a subculture to validate you, your feelings become "reality" in that you can have an ongoing conversation about it instead of being told to shut up. On balance, a good thing for every underrepresented idea under the sun.

What we don't know how to deal with yet is when this turns into a social media mob; the new face of the manipulator is someone who points the subculture at a target and says "their fault; go get 'em." But - my conjecture is that eventually, most people burn out on this kind of radicalization.

So then, are we getting better? Will Endless September come to a conclusion? Stay tuned, I guess...

The biggest change to my coding style in the past few years has been to opt out of the most expressive solution if it will fall apart in a cut-and-paste situation.

Many new features are variations on old features. The incremental cost of implementing one so that I can cut and paste the next half dozen is small. The cost of refactoring to a generalization after that is also small. But the cost of poorly generalizing early and having to reimplement feature one and everything it touches in order to make feature two possible is quite painful.

This becomes more obvious when you have different codebases with similar features that might want to share from time to time. A formally generalized solution becomes a big dependency, as it relies on a heavily specified problem. A slightly too primitive solution flows between codebases freely - plug in new primitives and it runs.

The pyramid scheme analogy only holds true if you are paying in with money, not time. Other social networks are investments of time too.

Testimony: I registered for Tsu and have been active on it a for a few days after reading that story. There is nothing within the site that pushes monetization at you - there is a tab for payments, but it does not direct you there, and I didn't look at it until just now. When I did, I was presented with a terms of service, and then a "no spamming" click-through agreement.

Therefore I have to conclude that all of the hubbub is generated by some combination of early external marketing efforts and the natural tendencies of wishful thinkers. They've decided to stop pushing that angle, most likely because they hit their critical mass targets and can move on towards more sustainable growth options.

I'm a bit concerned about building up SV since it has a largely unresolved legacy of buried toxic waste...an irony standing in direct contradiction to the extreme desirability and real estate prices of today.

I mean, it's not that we aren't facing that problem already, but adding population may make it harder to resolve.

That only proves the point of the article: Mobile is still bad and has fundamental barriers to overcome. In the 1980's, the "obsolete the moment you buy it" and "expensive paperweight" jokes were commonly encountered for PC's.

The nature of what will cross those barriers is still up in the air, though: It could be plugging the phone into a dock to access the traditional peripherals; it could be used in tandem with a novel display technology like a VR headset, and likewise use novel interaction methods. The market hasn't started proposing serious solutions yet.

It's a whole-ecosystem issue. There are plenty of built-in features that happen to depend on GC, and while the ways to eliminate GC use are only increasing with time, the "idiomatic D style" is left in doubt when it's so dependent on allocation strategy. Precision choices for performance are characteristic of D - you have a lot of options to type or annotate your code towards a certain envelope of performance, or ignore almost everything and leave it to the GC. So this is not an unfamiliar problem, but it's a point of friction in the same way that borrow-checking poses friction for Rust - the friction may be centered on what you want for your problem domain.

If nothing else, you can write C in D, in a roughly similar way to how you can write C in C++ - the features are there, and so are the libraries.

The way I got into synthesis was with Jeskola Buzz. [0] You can still use it today... Free and community-driven, it has lots of modules, some are unique and brilliant, just as many are dodgy and likely to crash.

In terms of making electronic music, it's far easier to stick to a simple sample-driven workflow than to actually dive into synth programming, but there's a special joy in dialing in exactly the timbre you want.

[0] http://www.buzzmachines.com/

Interaction accomplishes the browsing of information, just like scanning a picture or looking through a card catalog.

And when folks make broad appeals to interactivity, they are saying that somehow the interaction of the gamepad is fundamentally different from turning the page of a book.

But that isn't what we are thinking about as we get immersed in a game experience - we soon forget that the controls are there.

It is the simulation that people turn to next - a believable world that responds to your actions in complex ways.

But again, there is a problem - more than one problem. If the simulation is as chaotic as reality, people lose track of the hooks that kept them involved - they no longer have the ability to make extensive plans or strategies, neither are there any puzzles to solve cleanly and gracefully. And if the simulation adds detail without purpose, it dilutes any designed intent. The small differences in situations are vastly overwhelmed by a few key elements that control the real outcomes - leading to a noisy experience. Only a few kinds of games can survive the extensive sim treatment - the kinds of games that you play with the intent of telling a story about later. Put to this purpose the details rise back to the surface as important story elements.

If not those two things, what is it that is grabbing you about Starcraft? Here I would pause to consider what unifies chess, science, and literature. It is the conversation of being posed problems and arguing your case and proving your points, given a factual situation involving arbitrary rules. There are different interactions involved in each case, different skills and levels of execution needed. But it is this thing of being posed interesting problems with variety, one after another, that drives both the best liked games and stories. They don't have to be hard or deep problems - "who will the main character hook up with" drives countless stories and "which team will get the most points" drives most sports - but they give you something to chew on.

And so a writing focus is, in this light, an equal partner to a mechanics focus - either could be taking the lead role. The writing could pose a question that the player solves mechanically - that's a very typical model. Or the writing could usher you in one direction, only to reach a mechanical contradiction, leading the player to a critique of the system, a desire to escape the rules.

What we don't ask people to do in games is to design, from scratch, large parts of the experience. That takes us out of the realm of immersion, browsing, and strategizing, and into "hard" creativity where an intentional vision drives large bodies of work.

I would venture to guess that subsidies also drive our obsession with adding dairy products to everything.

Life can't be defined by arriving at a place and feeling that you've "made it" or "gotten ahead." If you actually do "make it" by accident, the next thing that happens is that you die - in spirit, if not in body. A lot of people who suddenly get rich or famous meltdown, because they still don't know what to do. And a lot of people who go all-in on their careers burn out. There are opportunities that you can miss and regret, but you aren't an abstract person or a movie action hero - you won't be "on" all the time.

Instead, focus on the everyday cycle. How do you want to construct your life so that you are living well each day, each week? Take whatever things you're already good at - and can do without much effort if you just start, and concentrate - and put more of your chips behind those. It's in the regular practice that you become really "great", and there is no book or curriculum that can tell you how to practice at that level of motivation. It might lead you away from core CS, but that's okay. There are a lot of kinds of gigs out there, and you might overlook a possibility and come back to it later, so you aren't necessarily harming your future at this stage. Stay in good health and keep your stress down and you will get there eventually.

There are all sorts of little things that I'm sure other people figured out long before I did, and then things that I learned that they will never learn in their lives. If you value learning a lot, you end up not valuing wealth and status as much, because it doesn't have much to teach you. And then it doesn't matter that you didn't intern at a top company, because suddenly your friends are all a bunch of weirdos too.

I only recently realized that technical writing was a thing I might want to do, and I'm 30. I also only recently realized how to stop overtraining with weights and make more substantial progress, and this was after some 15 years of off-and-on practice with lifting. (It's simple: two-day split once a week instead of once every 2-4 days.)

IMHO the basic fallacy of this essay is that ideology is not reality. It sets the goal to be communism as classically envisioned(worker's paradise), and only some people are absolutely convinced that that's the culture they want. We still largely have a strong belief in private property, for example.

In making this case, the author raises a bunch of bogeyman images of everything else being sacrificed on the altar of UBI. This is a paranoia tactic. The real exchanges made are done at the level of individual politicians horse-trading against rivals and various interest groups. It's possible for something to be popular enough that capital is told to go get dunked, despite all its other advantages, because the alternative is political suicide. It doesn't happen often, but this is one of those issues that captures people's imagination in a big way.

I think the advice re. competitors tends to be about "how much should you worry about what a competitor is doing _right now_" - and the answer to that is pretty much always "not a whole lot." You can have two businesses doing similar things but taking radically different approaches to execution and both succeeding in their own way.

But on the macro scale there are always windows of opening and closing opportunity on what makes for a viable business before (new technology takes over/bigger companies start paying attention/governments try to regulate you out of existence), and it is that more general climate of whether it's possible to execute at all that pressures the potential unicorns into a do-or-die mode. Monopolistic competition like e.g. Uber vs. Lyft is an exceptional case for technology; the expectation is that if you succeed at all you will probably be in complete control until the technology ecosystem itself shifts.

There is a second half to this, of course, which is that the type of people who found a fast-moving VC-backed startup are so deeply enmeshed in their plans for the company that they will put themselves into an unsustainable overdrive and expect everyone around them to do the same. Their enthusiasm can be entirely real and still be basically toxic and lacking in conservative sensibility. There are a lot of commonalities among founder personalities, IME.

It cheats a ton. You can turn misses into hits by carefully jiggling the camera. Still a great game though.

I've had the experience of understanding feedback loops perfectly well but still feeling inclined to blame a "big bad" for most ills. I had trouble developing an ethical basis for my actions because I swing across the political aisle very readily based on utilitarian arguments, but simultaneously feel tons of empathy for others and thus want to be in collaboration with everyone I meet. Thus I swept through the gamut of political thought, radical in various ways at various times, moderate at others.

Working through that meant gaining a better distinction of the self from the system. I explicitly use a virtue ethics mode for my immediate surroundings and everyday behaviors(i behave in the way in which i feel the least guilt), and then a utilitarian mode when I have to make a decision affecting potentially large groups(e.g. my voting decisions tend to be less selfish and more model-based). This keeps my priorities healthy because it stops me from pointing to an inappropriate "scale" of thinking for the situation.

It's not a useful distinction since many kinds of games use player UX "cheats" like slight warping to physics algorithms, RNG weighting, etc. Most of these features act to take emphasis off of precise, low-level execution, or the pain of a string of unlucky results, in favor of higher-level strategy concerns, fast decision making, and expected values over time. There is an occasional chorus of "simulation purism" from some folks, but really, simulation elements are bulldozed in games constantly and consciously. The actual results are subtle and people don't take much notice when rules are bent, they just experience "fluid control" or "fair outcomes."

Auto-aim is only well-known because it's visually obvious when it occurs - the gun did not point in the direction of the camera.