A large part of the effect that cars have come from massive subsidies and policy choices that push for cars over alternative options. The comparison shouldn't be "cars vs literally nothing" but rather "car-dominated infrastructure vs the same investments in alternatives". (Not to say that it's an either-or; the optimal equilibrium might still involve some mix of car investments, just far less than we have now.)
It's the folks pushing cars that are both the most strident and the most successful at pushing their "obviously correct" way onto everyone, at least in the US.
Cars are not popular becuase people pushed them. Cars are popular because the utility is undeniable.
This is true for any kind of transformative technology. Marketing and lobbying can only get you so far. If something has enough utility, it will be used regardless of what people say they want.
> Cars are not popular becuase people pushed them. Cars are popular because the utility is undeniable.
I think this is somewhat of a chicken and egg problem. Cars' utility is undeniable partially because society has twisted itself thoroughly around The Car being an assumed part of it. This societal change was both pulled (by car customers) and pushed (by car manufacturers).
Yes absolutely—I think cars have obvious utility as machines, but there has now been 100 years of building everything around them and changing laws in such a way that encourages their use: through direct and indirect subsidy, land use rules that largely outlaw building cities in any way other than sprawl that itself increases the importance and utility of cars, and various other preferential regulations that often tolerate the harms in a way that is not applied elsewhere (c.f. panic over e-bike safety vs American highway safety overall).
Cars won because they were (and are) better than the alternatives. The need for powerful individual transportation with utility has always existed, and was originally met with horses. Bicycles meet the transportation need, but not the need for utility. Cars do both, and they do it better than anything else. Even before fueling infrastructure was rolled out, you could still run a car on petroleum you bought from the chemist, which is still infinitely better than the acres of pasture you need for horses. If you had an early diesel, it would run on oil, which is even easier.
The idea that cars needed all this infrastructure that other alternatives didn't just doesn't match the reality of the history of the automobile. And yes, we've leaned on those advantages in the century since, which has also created vast areas where a car is necessary to participate in society, but we only did so because the advantages and utility were so undeniable.
We can't read everything, so we need markers of taste to figure out what is and isn't worth engaging with. AI tells are markers of drastically bad taste.
It's a great time to get into programming languages stuff: designing domain-specific languages, building new tools/abstractions and, especially, formal verification. If you're mathematically oriented, you can explore formalizing mathematical proofs in Lean.
LLMs have really revitalized interest in these areas. AI can really help navigate the initial learning curve, can do a surprising amount of "heavy lifting" and can make tedious but useful work much easier. Do you want your little language to have a language server and nice editor-specific syntax highlighting? Do you need to write a parser with decent error messages? Do you need to prove a bunch of largely straightforward lemmas to get to the proof you actually care about? All of these things are easier (and, hopefully, more fun) than they were a few years ago. But, at the same time, there is still a lot of room for human insight and design in this process. There are a lot of areas that AI can't handle (or, at least, can't handle well) and, of course, nothing stops you from doing the fun stuff by hand even if you could hand it off to Claude.
And, of course, all this PL stuff was fun before LLMs. It's even more fun now even if you don't want to use AI yourself, because more people are doing and talking about PL stuff online, and there are more tools and libraries you can use yourself.
You can have both: you start with a small, mathematically inspired algebraic core, then you express the higher-level more user-friendly operations in terms of the algebraic core.
As long as your core primitives are well designed (easier said than done!), this accomplishes two things: it makes your implementation simpler, and it helps guide and constrain your user-facing design. This latter aspect is a bit unintuitive (why would you want more constraints to work around?), but I've seen it lead to much better interface designs in multiple projects. By forcing yourself to express user-level affordances in terms of a small conceptual core, you end up with a user design that is more internally consistent and composable.
Every layer of the organization tells a more rosy version of the truth up the chain of command. The programmer might tell the PM that they're running Apache software with the serials filed off, but by the time that filters up the chain to the CEO / Board, the product is "fully proprietary and 100% built in-house"
The most productive teams I've seen (eg at Jane Street) rewrite things all the time, and still move faster than any "normal" teams I've seen. I remember when I interned there over a decade ago, they were already on like the seventh? version of their incremental computing framework, and were building a new build system. But they were also incredibly effective at getting things done both on a per-engineer basis and in terms of making money.
> No one has ever made a purchasing decision based on how good your code is.
This is very much a "it's not the fall that kills you, it's the sudden stop at the end" sort of thing. (Same with the other variant I've heard, which is something like "no company has gone out of business because of tech debt".)
Code is as much a tool for developing and expressing conceptual models as it is for making computers do things. So not only does code quality have proximate impacts on engineering productivity and reliability, but, done well, it also improves the holistic design of the system you're building. You get better tools, faster, by putting some thought and care into your codebase and, especially, your core abstractions. Teams with good code move faster even in the short term and produce better tools and products.
Of course, it's not just a matter of code; you also need a culture that gives engineers the agency to make real, long-term decisions about what you're building (not just how) which, unfortunately, is rare to find in the modern tech industry :/ The dominant "high-output management" paradigm where code is seen as a virtually fungible "output" to be "delivered" loses the higher-order advantages of good code and good conceptual design, and leaves us with something much closer to the trade-off you describe. But there are other ways of approaching technical work that don't make this trade-off at all!
reply