Ruby on Rails and its imitators blew away tons of boilerplate. Despite some hype at the time about a productivity revolution, it didn’t _really_ change that much.
> , libraries, build-tools,
Ensure what you mean by this; what bearing do our friends the magic robots have on these?
> and refactoring
Again, IntelliJ did not really cause a productivity revolution by making refactoring trivial about 20 years ago. Also, refactoring is kind of a solved problem, due to IntelliJ et al; what’s an LLM getting you there that decent deterministic tooling doesn’t?
couldn't have said it better. all of the people clamoring on about eliminating the boilerplate they've been writing + enabling refactoring have had their heads in the sand for the past two decades. so yeah, i'm sure it does seem revolutionary to them!
There have been a handful of leaps - copilot was able to look at open files and stub out a new service in my custom framework, including adding tests. It’s not a multiplier but it certainly helps
most frameworks have CLIs / IDE plugins that do the same (plus models, database integration, etc.) deterministically. i've built many in house versions for internal frameworks over the years. if you were writing a ton of boilerplate prior to LLMs, that was on you
Habe they? I’ve used tools that mostly do it, but they require manually writing templates for the frameworks. In internal apps my experience has been these get left behind as the service implementations change, and it ends up with “copy your favourite service that you know works”.
> my experience has been these get left behind as the service implementations change
yeah i've definitely seen this, ultimately it comes down to your culture / ensuring time is invested in devex. an approach that helps avoid drift is generating directly from an _actual_ project instead of using something like yeoman, but that's quite involved
Sorry - I’m aware that rails/dotnet have these built into visual studio and co, but my point was about our custom internal things that are definitely not IDE integrated.
> it comes down to ensuring time is invested in devex
That’s actually my point - the orgs haven’t invested in devex buyt that didn’t matter because copilot could figure out what to do!
And for a lot of AI transformation tasks, for a long time I've been using even clever regex search/replace, and with a few minutes of small adjustment afterward I have a 100% deterministic (or 95% deterministic and 5% manually human reviewed and edited) process for transforming code. Although of course I haven't tried that cross-language, etc.
And of course, we didn't see a massive layoff after the introduction of say, StackOverflow, or DreamWeaver, or jQuery vs raw JS, Twitter Bootstrap, etc.
I just had a relevant experience. I asked Claude to add “trace(‘$FunctionName’) {}” to all Composable functions in my app. Claude spent some time doing something. In between, I was like shoot, I could just do a deterministic regex match and replace.
structural search and replace in intellij is a superpower (within a single repo).
for polyrepo setups, openrewrite is great. add in an orchestrator (simple enough to build one like sourcegraph's batch changes) and you can manage hundreds of repositories in a deterministic, testable way.
Oh, I had completely missed that he’d done this in a Dutch paper too. All I’d heard of it previously was that his articles had been pulled by the Irish Independent, so I was expecting the apology to be in English.
People have been trying hydrogen. It’s generally a bit of a disaster.
And increasingly I think that is being quietly admitted. It has a weird afterlife in buses (where the range potential is interesting for long-range intercity routes), but even there, at this point, it’s marginal. The Irish transport authority placed an order a few years back for 800 BEV buses… and three hydrogen buses, for instance. A decade ago, BEV buses and hydrogen buses were both basically experimental. Today BEV buses are ordered by the thousand; hydrogen buses are still experimental.
(Also I expect hydrogen _trains_ to hang around as a concept for a while, and it _may_ actually be viable there where adding overhead lines is not.)
> It would allow legacy vehicles to stay on the road
How? Hydrogen cars _are electric cars_; they just have a fuel cell instead of a battery. If you’re imagining that they have, er, a four stroke engine that they burn hydrogen in or something, yeah, that’s not a thing.
I suppose if you wanted to get _really_ weird you could have a hydrogen turbine car? But again, that’s nothing like current petrol cars tech (and would be horribly inefficient relative to the fuel cell ones).
They just have to replace most use cases. There will come a point, not too far away, where battery progress makes them cheaper to purchase than petrol cars (for many use cases the point may already have come where TCO is lower, and Trump’s oil crisis will only speed the arrival of that point for more use cases.)
I never said they can't sell in China. My question with this was if they can maintain the same levels of profitability they enjoyed during the ICE glory days, as a lot of EU economies are dependent on the profitability of the auto sector. If profits slump, then so will the lives of a lot of working class Europeans. Keep in mind the auto sector used the be the biggest R&D spender in EU.
Some companies accept a profit loss in some markets compensated by the profit gains in others in the interest of capturing a growing market so this might distort VW's success in China.
The third-biggest BEV maker is VW AG, a legacy car brand. Likely soon the second, given their hefty (33% last year) growth vs Tesla’s modest shrinkage; unless something changes they’ll overtake in a year or so.
Ford of Europe is arguably a European car brand which happens to be owned by a US company (in much the same way as Chrysler/Jeep etc are clearly American car brands, despite being owned by a European company).
> and high restructuring costs from the shift to electric vehicles.
I’m baffled how you think “it’s going to cost us a lot to shift to electric vehicles through 2030” could be read as “VW is retreating from electric vehicles”.
> I’m baffled how you think “it’s going to cost us a lot to shift to electric vehicles
I'm baffled how you refuse to read further into the topic - How does cutting 50,000 jobs due to EVs translate to "it's going to cost us a lot to shift to electric vehicles" according to you? That's just shifting the baseline of the argument.
VW even cancelled EV models after posting this loss. Again, Google, first page.
The original link literally shows job losses due to lack of demand for EVs. If that's not a data point indicating retreat, then what else is according to you?
Ruby on Rails and its imitators blew away tons of boilerplate. Despite some hype at the time about a productivity revolution, it didn’t _really_ change that much.
> , libraries, build-tools,
Ensure what you mean by this; what bearing do our friends the magic robots have on these?
> and refactoring
Again, IntelliJ did not really cause a productivity revolution by making refactoring trivial about 20 years ago. Also, refactoring is kind of a solved problem, due to IntelliJ et al; what’s an LLM getting you there that decent deterministic tooling doesn’t?
reply