chipsy

Or you could just have data. The behavior of mixing is not going to change because of those things.

No faith in his claims if he speaks like he writes.

After a certain point, it's better for a system to be absorbed into an API instead of trying to be configurable. Then you can just write code again, and it's complex but not idiosyncratic.

In the past, Gamasutra has also published data indicating correlations between "biggest problems/biggest successes" and marketplace success.

The takeaways I remember about that: A good producer matters, a team of a least three people does better than one or two, and experience shipping stuff matters.

Cold logic. The advertisement defines life as something that is not doing chores. Therefore people who do chores are not living. Whether that makes them "subhuman" does involve some interpretation, but if you call someone "not alive" you aren't exactly complementing them.

A train seat is not the thing I am paying for. A transit company is typically chartered around provision of service regions and schedules, and it has the power to divert passengers to alternatives like buses if problems arise preventing use of some existing infrastructure. The customer is not there to "ride the train" but to reach a destination - the transit is judged upon how well this demand is satisfied.

Private property law allows owners to enforce their own rules(to a point). This both explains the private control over the train and tracks and lends weight to the possibility of being kicked off the train, as it is justified in terms of disruption to service and resulting monetary losses. To wit, a positive externality of transit service is economic gain from the population having improved market access(more goods, services, workplaces within reach). The transit company does not realize these gains, the public does. The company's enforcement of rules is guided by the premise that some amount of security and order is necessary to achieve its service goals.

My dependency strategy over time has moved towards more static, project-owns-everything behavior, and specifically "one synchronization script per dependency" - including my own utilities library. The script leaves a echo of the timestamp so that I can also see when it was updated.

That way, different projects can have different versions of everything, and system environment is only important to the synchronization step - trivial to fix up if needed, trivial to copy between machines.

Perhaps an appropriate measure for interviewing is to do some psychological profiling to spot where a candidate is imbalanced, and then incorporate into the remainder of questioning. As an interviewer, you're always going to be biasing towards your own strengths and downplaying weaknesses, and although there are personalities that pose more or less danger to others, there isn't a perfect personality overall.

In a lot of ways, FBF animation has never been disrupted so much as just temporarily displaced by other techniques for reasons of efficiency. The animator still has to make good design decisions up front so that the figure construction works and objects move in a perceptually believable way. Everything else - whether it's rotoscoping or tweening or something else - assists, but doesn't aim to truly emulate the thought process that a traditional animator uses, so you get different results that are often more mechanically precise but less interesting to watch.

This may be the best advice in the whole thread. Once in the Real World, you are free to be an asshole about how you negotiate and just...not stick to your statements of obligation. You suffer consequences only if you have to deal with the exact same person again. But if the org is big they won't really notice.

We're just all so used to schools setting up all the obligations for us and monitoring everything, that taking a more freeform approach is unsettling at first.

That isn't clear to me. Computers are good at arithmetic and sequential algorithms by design, but those are also applications of their power, and categorizing them by the intended application is also pretty dumb. It is the tricks and happy accidents that propel a lot of innovation - indeed, the fact that such has happened is one the numerous challenges to positivism.

When I was confronted with this dilemma for the first time I attacked it by using multiple passes. My original draft is markdown. I pandoc it to DocBook. Then I add frills and edits in DocBook.

I see the process as not being different from what's needed to do the writing - compiling notes and sketches and outlines into a coherent narrative.

With respect to Checkers (specifically, the 8x8 English Draughts variant), it's been a solved game as of last decade, and people still play in tournaments. I don't think it's that silly, since there are many techniques we've automated away, yet still practice by hand.

Things that this does not cover:

Transportation Education Health Childcare Clothes Job-seeking expenses

If you want the flexibility to cover every avenue of "i and my family have a shot at making it," you either arrive at a combinatorial explosion of complex needs-tested programs, or basic income.

Since every program you make will induce some unique form of leakage, corruption or freeloading, the expectation of BI is that it limits that to "some people do not have the personality to manage personal finances, and will always be broke in any given situation." But that doesn't take anything "away" from people who can be responsible - they will in fact be insulated from the drag-the-family-down dynamic that prevails in the deepest instances of developed-world poverty, because they get their own BI at adulthood and can just run away from the situation without severe risk or hardship.

It's actually a good contrast to the biases of id tech 4 - bright, huge scale outdoor landscapes and arenas with hundreds of AI opponents vs. dark interiors with mood lighting and smaller engagements. It's an early example of heavy usage of "modular" model instances to add detail instead of relying on brush geometry to do everything. There are plenty of nifty features like split screen.

From an overall technology standpoint, both engines should prove worthy of study given the radically different focus.

The logistic function (or "S-curve") describes systems that expand first at exponential rates, then logarithmic ones. With respect to new technologies, it's been observed that adoption rates and most measurable improvements follow a logistic function.

For example, people did not go from buying 1 car to buying 10 cars and then 100 cars - most of us hit saturation somewhere between 1 and 2, and stayed there. Similarly, the average speed of our cars did not increase at an increasing rate except in the earliest years of automotive technology; we have a "highway maximum" between 50 and 70 MPH, and a "technical maximum" in the high 200's range for production cars which do not rely on rockets or other not street-legal tricks (a quick search brings up the Hennessey Venom GT at 270.49 MPH). Likewise applied to fast moving vehicles as a whole, including supersonic aircraft and rockets, we've already brushed up against vehicle weight and power density limits that slow the rate of improvement in acceleration.

Applied to the Moore's Law measures, that indicates we have a "endless sunset" period ahead of us where we'll still get more doublings of semiconductors, but they'll come increasingly slowly as more fundamental innovations become necessary to realize them.

What we don't know is whether there is a logistic curve on technology as a whole. Belief in the Singularity is premised on this not being the case.

There's always an element of "one step forward, two steps back" with major technology shifts. Every time we've had a big change in platforms, we also had to redo existing engineering work.

I don't think this is doom and gloom for accessibility, though. The future is in general-purpose assistance technologies that mediate any application. You can smell it with the new work in ML. It is not here now, but as with everything in technology, by the time it's mature and widely available, it's nearly obsolete.

It isn't a tree search algorithm.

Well, it is equivalent. Not in terms of what a played back sound is like, because tape and digital both introduce characteristic artifacts, but in terms of "this signal peak is so many dB above the noise floor."

If you actually code some audio DSP(and I do), you quickly learn that there are a lot of ways to color sound that aren't quantified except in a very broad statistical sense, but are measurable in audition. What digital is very good at is the basics of reproduction with a (statistically) uncolored result. At artistic effect, it is somewhat more limited; a lot of compute time and engineering has to be thrown into reproducing some straightforward analog world things and model accuracy still has room for improvement even now.

If you want to quibble with the video, do so on its terms. It isn't saying that digital is better, it's saying that digital is better at a very specific task.

I have to assume this is coming from people who are not good text communicators in general because the same problem exists with email: "when would you like to schedule this" without indication of your own schedule is one such pet peeve. It's really easy to stretch out asynchronous conversation by wasting the other person's time.

"I have a question" in speech DOES have a purpose, which is to prime listeners to enter conversation mode instead of stopping you to say "what" after you've said two words. Of course, I've seen people who are on the ball and impatient still get testy about that convention.

Edit: the most infuriating experience I've had in recent memory is a friend who will consistently spam his shitposts over IM without warning, but when it comes time to do business will say "hi" or "are you there" instead of asking the question.

This is the old "freedom/security" debate in the guise of interpersonal consent. Governance has always involved coercion at the individual level, because governments rule with force, and a certain amount of force is necessary for order and security; without making that move to unify under some law, a population gets mired in low-level disorders and disagreements. It can be a really shitty Hammurabi-style eye-for-an-eye law, legitimize slavery, rape, etc., but if it protects the interests of the ruling class and is not an immediate threat for most of everyone else, it sticks. Thus, for thousands of years, most people lived as peasants, and enjoyed equality and fraternity with their immediate peers, but few freedoms around property, invention, travel, or other such actions that might threaten harmony in society.

But the consent of the people does exist, as a mass body. It takes quite a lot for a critical mass of them to decide that the government is no longer legitimate and disorder would be preferable, but if they do, the government is pushed into crisis. And when governments make breakthroughs, it's in the moment of crisis where leadership is forced to either make a big concession or be pulled down by the mob. In between crises, the status quo sticks and politicians jockey for position within it instead.

What that never translates to is the individual who sticks out of the crowd, arguing for change, getting special treatment. At all times, even in the era of post-Enlightenment reason, they are viewed suspiciously, because good enough is good enough, and they might just be another "bad guy" (criminal/barbarian/spy/rebel/etc.) trying to pull a fast one. They get no credit; as with business and innovators vs. fast followers, it's the people who come afterwards, using more polished rhetoric and building existing small movements into large ones, who tend to turn those ideas into reality.

As i start to read this, "Dancing Queen" comes on. Clearly they control the airwaves.

I read Dear's The Dungeon Master back in high school and want to reread it at some point. It's a complex, real story, and told with some empathy.

I agree. Ravioli code is particularly nasty because it fulfills "DRY" in the small but hurts the ability to make further changes. In both the spaghetti and ravioli situations a cyclical attack of "factor/inline/factor/inline" flushes away the worst stuff and reveals opportunities for more substantial changes, but it's easier to start from the case where there's too much inline code than to fumble through a deep callstack.

That said, if your functions are pure functions, they won't contribute much to overall complexity. It's a much different situation from having a do_the_thing() method that does some mutability magic.

It's a rebrand of Flashdevelop (with cruft stripped out). We're still waiting for the ultimate Haxe IDE-in-Haxe...

This is definitely along the lines of what transportation tech has done to date. Instead of new replacing old altogether, the options just get more flexible over time, easier to "packet switch". You don't take just the bike or the bus, you take the bike to the bus and open up a set of possibilities different from the two alone.

Likewise with the new generation of small EVs, visual processing, and networking, you can scale the infrastructure for everything more exactly, with a variety of vehicles of different sizes and carefully synchronized transfers, instead of forcing car traffic into primacy.

From that perspective it's easy to see why PRT was a hard sell - it's less flexible than a car and it doesn't have the capacities of light rail. The automation part has stuck, though.

Most of these things really come down to implementation detail(e.g. formatting rules), and they are mostly interesting for aesthetic purposes.

The important ones like conventions surrounding replies are weird artifacts left over from the early days of the product. Twitter bottlenecks quickly in lengthy conversations amongst multiple parties and you really have to carefully respect the social dynamics it creates, or people will just block your rude self. If there is one place where the product could use revision, it's in improving average case conversation quality.

There's certainly arguments for accumulating towards a target number. You can also combine this with the streak method and say "through date xx aim for yy frequency" - in effect having a goal number and the rate at which you plan to reach it.

Regardless, I like having end points on these projects because they give you a sense of relief at the end. It also helps to aim for low frequency with each goal so that your daily schedule isn't rigid - a 15 minutes per day investment is actually quite a lot.

It's the biggest fallacy in armchair transit planning: Misunderstanding what induced demand means. If the system is at capacity everywhere, but you build to the point where a modality(any modality) is no longer congested, new demand will shift towards that modality. Thus, you can have a city where all the trains are packed, or one where it's the highways. Presumably, if you invested enough in them, bikes and buses could go the same way.

But what you can't do is create an "all-around" city where every transit option has equally low congestion. People will show a preference for whichever mode they got used to, and fill the others only as they hit their tolerance limits - not because one is faster, or cheaper, unless it's substantially so(and then congestion will arise to even the odds). This typically manifests today in a city crowding the highways but leaving the buses empty. New construction will mostly be used by newcomers unless there is some disincentive to drive, like downtown congestion charges, reduction of parking, smaller roads, etc.

The bus lane capacity thought experiment equates velocity to throughput. This is obviously wrong; while a bus interferes with some traffic, it also pulls more people into less space. Multiply that along the whole route, at high frequency, and you end up with geometric efficiency. A bus may go at a third of the speed, but it carries easily 10x as much as a four-seater, and bigger buses could hold even more. At the peak hours, congestion and slow speeds are assumed and vehicle capacity starts to matter for delivering the most commuters home in a timely fashion.

Then consider the network benefits of running more routes and connections at higher frequencies. Public transit has to hit a certain critical mass of densities and destinations before it really takes off; most of the US today, being heavily suburbanized in the mid-century fashion, does not enjoy this. But the New York City region got there, and several other metros are showing signs of moving in this direction. Access to transit is implicitly improving now that we're in the era of electric rideable vehicles and people making their first/last-mile connection can go at 10-15 MPH on whatever weird gadget they want without breaking a sweat or having to find lockup space. Capacity becomes a complicated equation with all these factors.

I really feel like the web today - the turnover, the frameworks, The Cloud, the burying of old under new - is the automation trend working faster and harder than ever. It all works better for the 80% case than an individual doing it from scratch - so we all succumb to it. And that's always been true of technology, but it used to be at the behest of a big platform owner like an MS or Sun or Apple. They set the marching orders and developers hopped on the bandwagon. You redid everything for the new platform.

But with the Web, the genie is truly out of the bottle and nobody can put it back in. It's the same shitty platform as ever, with more and more kludges added on. So we look to automation for a silver bullet, and by sheer force of numbers we've succeeded in building something that Just Works most of the time and requires deep technical skills to fix otherwise.