Hacker News Reader

Comment by the_duke | Hacker News Reader

Yeah it seems so obvious in hindsight: of course a language should have ONE editor-optimized compiler/analyzer for IDE like features, which can be reused by all editors out there instead of building half-baked implementations for each IDE.

But many things seem obvious in hindsight.

View on HN

IMO the reason this rather obvious idea took so long to be implemented was because on one hand the closed source vendors didn't really have a strong incentive to provide something like that (you support your own ecosystem and let the others deal with theirs) and on the other the open source community was spread across many compilers and interpreters which made standardizing difficult. The only project I can think of with enough clout to impose a system unilaterally was GCC, which was notoriously hard to extend and modularize (especially before LLVM started shaking things up a ~10 years ago).

So overall the effort to create a protocol and then getting everybody to accept it was rather huge and the chances of success rather slim. It's great that MS finally decided to do it and the huge popularity of VScode (especially with younger coders) seems to have helped a lot.

the funny thing is that gcc was pretty easy to extend before the eggs split. unfortunately, it was also pretty stagnant and nowhere near as good of a compiler suite as it is today.

I recall the lack of extensibility in gcc being deliberate, according to RMS -- he wnated everything around gcc to be free, and plugins would allow for non-GPL or even closed source code.

Deliberately harming your users to own the corps. Jokes aside, open source is great, but RMS’s perspective is extreme. I don’t think it’s an exaggeration to say that the overall quantity and quality of open source software is much greater because of closed source software because companies fund open source initiatives with profits from closed source initiatives and then the second order effects of maintaining a huge pool of professional programmers, some of whom use their skills to contribute to OSS.

No one should make money selling software. Beg for donations or sell ads if you need to pay your bills. Or get a cushy university appointment like me, and spend your days polemicizing about freedom.

That's your moral view, but you missed my point which is that it's incompatible with a florishing ecosystem of open source software.

Open source software existed before closed-source software was even a thing. Software used to come in source-code and freely-redistributable form; it was basically funded as a loss leader for things like hardware and support, that could be billed for. Many companies today which fund FLOSS have very similar models, only with other sorts of value-added services being added to the toolset. Others have even managed to pay for FLOSS directly via crowd-funding.

To be clear, "OSS predates CSS" is not a refutation for "CSS makes the OSS ecosystem larger and more robust". Apologies if that's not the point you were trying to make.

I think you have to put his principles in a historical perspective. Sure it sounds somewhat extreme today when OSS dominates many layers of our business stacks. But assuming that the industry would have naturally seen the OSS light is far from a given IMHO. I think copyleft licenses where a very important springboard to start the virtuous OSS cycle.

The key element was Andreas Heijlsberg work on the Roslyn C# compiler which exposed all stages as APIs (e.g. AST etc). He calls the dragon book as significant outdated when it comes to modern compilers (Channel9 video).

That then transferred to TypeScript, which again influenced VS Code. OmniSharp was then externalizing it. In VS Code I think Erich Gamma took it over and put it into standardized a protocol.

I wish there was a book that teaches how to create a programming language based on the Roslyn idea.

Well that's great to know. I just bought the dragon book. Is there a better book out there?

It is still a pretty damm book to read about compilers, if not anything else, at least from historical perspective.

The Tiger book, "Compiling with Continuations" and "Lisp in Small Pieces" are some of my favourite ones.

Then if you want to learn about language semantics validation, "Formal Syntax and Semantics of Programming Languages: A Laboratory Based Approach".

The Tiger book is a better reference nowadays.

Another good alternatives are "Compiling with Continuations" and "Lisp in Small Pieces".

> many things seem obvious in hindsight.

The best ideas seem obvious in hindsight. I've had the experience of reading some books that explain groundbreaking ideas so well that you feel "shit, that's obvious. I should have thought of that". I think Language Server protocol is similar.

It sounds pretty much like Steve Yegge's Grok project (now "Kythe") from over a decade ago. They just started at a different use case.

Reply on news.ycombinator.com