thefaux

I agree. Indeed, it is clear that Bach would have had for more impact (and produced better music) if he had written in clear and detailed prose his intention for each of his pieces including all subjects and answers as well as the overall structure of the musical argument and allowed the interpretation to be automated by a musical notation generator.

I don't think other people's dreams are boring. I think there is a cultural bias against dreams and their interpretation that it has become almost a trope to be dismissive of them.

It sounds like you don't code much in bed or with your feet up.

A laptop is a distinct tool from a desktop and if you try to use it like a desktop, I agree it is a terrible substitute. Personally I find laptops vastly more ergonomic than a desktop, but I never program with my feet on the ground.

On scala, I think there were several factors that led to it stalling out in the mid to late aughts. I am not convinced the community was the root cause. I think more significant was the scala 3 transition. When they were still near the peak of the hype cycle, the core team decided to spend more than five years rewriting the compiler. In my opinion, while there were good reasons to do a rewrite, they focused on the wrong things if widespread adoption was the goal. The biggest problems with scala were compiler and sbt performance, as well as related dev tooling. The new scala 3 compiler had to first approximation equivalent performance to scala 2 and they did nothing to improve the build system. In the meantime, other languages that overlapped with scala in various ways rose up: kotlin, typescript and rust come to mind. The unique value proposition was diluted, and the poor tooling experience persisted.

Now, that's not to say that the community was not also a factor in scala losing momentum. I agree with your take. At the same time, that elitist community was also building cool and useful stuff that significantly improved upon what was available in other ecosystems so I think it was a double edged sword. Even today, there are things that are easily done in scala that are useful, elegant and impossible to do directly in most of its peer languages. It may never have reached truly mainstream ubiquity but I think with better technical decision making, the language could have remained very strong its niche.

There is something that I don't fully understand about this design: why are they insisting on building a giant binary for debug builds that contains all of the code? From my perspective, a simpler approach is to generate many smaller shared libraries (perhaps at the file level) and link them in to the final binary. With this approach, the program binary would have a tiny text section and a (potentially long) list of shared libraries to load. But even with thousands of shared libraries to load, the resulting program binary would not be all that long and there would be no need for binary patching.

I understand that for a release mode a single giant binary may be desirable, but I am struggling to understand this design for debug builds. Moreover, while reading this article, I found myself wondering what happens if the main binary becomes corrupted. Maybe the user cancels compilation with ctrl+c while it is patching the binary. Even if they have a story for avoiding and/or detecting corruption, it is simpler to not patch in the first place and always generate a new main binary. Again, this is reasonable because the new binary is mainly just a list of shared libraries to link which will not take up much space and can be written to disk quickly. Moreover, this process can be done recursively, e.g. at the subdirectory level, so that during incremental linking a few quite small shared libraries may be produced rather than patching in the new code and writing cascading relocations.

Syntax and semantics are never orthogonal and you always need syntax so it must be considered from the start. Any reasonable syntax will quickly become much more pleasant to generate an ast or ir than, say, manually building these objects in the host language of the compiler which is what the semantics first crowd seem to propose.

It also is only the case that most of the work is the backend for some compilers, though of course all of this depends on how backend is defined. Is backend just codegen or is it all of the analysis between parsing and codegen? If you target a high level language, which is very appropriate for one's first few compilers, the backend can be quite simple. At the simplest, no ast is even necessary and the compiler can just mechanically translate one syntax into another in a single pass.

Cold-blooded cost/benefit analysis is an abdication of moral reasoning and responsibility. There is no such thing as an abstract life, only concrete realizations. What if the victim of an avoidable fatality is the one person who had they survived had the skills/insight/vision to literally save humanity from extinction?

I can accept an argument that there are societal tradeoffs that we must make that involve the sacrifice of human lives (obviously we should not try to remove risk to the extent that we live in sterile protective bubbles), but we should be honest about what we are doing and not hide behind some phony numbers that mask the fact that money, and hence numerical value, isn't an imaginary construct and that lives are fungible under this value system.

I further think that if we have an honest conversation instead of hiding behind quantitative analysis, we may actually have a productive dialogue about risk tradeoff and accountability. Perhaps if there is a wide gap between the bean counters and the bleeding hearts, there is a third possibility that needs to be explored.

I have written a compiler for a language at more or less this abstraction level. It provides access to 16 general purpose registers and a set of virtual instructions that operate on these registers. I program on an intel mac so the virtual instructions all map directly to x86_64 instructions, but it would be very straightforward to write an arm backend that may compose multiple arm instructions for the equivalent x86_64 behavior. I also could support virtual registers for platforms with fewer than 16 registers.

Having this compiler, which is extremely fast (it is self hosted and self compiles its own 9750K line source file in 15ms on my 2019 macbook pro and I've seen throughout ranging from 500K to 10M lines per second for other programs), I have little interest in ever using LLVM again. I would rather just write optimal code than pray that LLVM does a good job for me. For equivalent programs, I find LLVM can be anywhere from 50-10000x slower than my compiler and doesn't necessarily produce better code. I can produce examples of LLVM code becoming significantly worse at -O2 than at -O0.

The only real utility LLVM offers me at this point is that I could use it to figure out what an optimal solution to a small subprogram might be by compiling a small c program and inspecting the output. Then I can just directly write the optimal solution instead of being perpetually bogged down by llvm's bloat as well as also being exposed to unexpected regressions in the optimizer and/or having to learn its strange incantations to get desired performance.

> Why would anyone create a new language now? The existing ones are "good enough", and without a body of examples for LLMs to train on, a new language has little chance getting traction.

Compiler writing can be an art form and not all art is for mass consumption.

> Java has won (alongside many other winners of course), now the AI drawbridge is being raised to stop new entrants and my pick is that Java will still be here in 50 years time, it's just no humans will be creating it.

This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it.

It is interesting though that he evidently didn't notice this 2.5X productivity increase until you pointed it out to him.

Just because it is small doesn't mean that it isn't important.

The lead maintainer of sbt does it as a labor of love. I am very curious if he actually will be receiving any money.

The examples that you and others provide are always fundamentally uninteresting to me. Many, if not most, are some variant of a CRUD application. I have yet seen a single ai generated thing that I personally wanted to use and/or spend time with. I also can't help but wonder what we might have accomplished if we devoted the same amount of resources to developing better tools, languages and frameworks to developers instead of automating the generation of boiler plate and selling developer's own skills back to them. Imagine if open source maintainers instead had been flooded with billions of dollars in capital. What might be possible?

And also, the capacities of llms are almost besides the point. I don't use llms but I have no doubt that for any arbitrary problem that can be expressed textually and is computable in finite time, in the limit as time goes to infinity, an llm will be able to solve it. The more important and interesting questions are what _should_ we build with llms and what should we _not_ build with them. These arguments about capacity are distracting from these more important questions.

This feels like it conflates problem solving with the production of artifacts. It seems highly possible to me that the explosion of ai generated code is ultimately creating more problems than it is solving and that the friction of manual coding may ultimately prove to be a great virtue.

I do see this as a bad thing and an abdication of taking responsibility for one's own life. As was recently put to me after the sudden death of a friend's father (who lived an unusually rich life): everyone dies, but not everyone truly lives.