Hacker News Reader

Comment by hardwaregeek | Hacker News Reader

I got to see this talk irl and it was definitely one of the highlights of the conference. It did make me feel a little bad for how many times I’ve ragged on programming languages for having poor UX/tooling, even though it’s pretty unrealistic to expect a community driven project to invest the thousands of developer hours. I do wonder if there are ways to lower that burden, although that still doesn’t help with the cost of support and developer relations.

View on HN

The Language Server Protocol is a newish thing that allowed some languages to gain more tooling for cheaper. I have a ton of respect for MS for doing this. They didn't need to do it that way. Tooling is still a ton of work and the protocol seems to have issue but looking the adoption it seems that a lot of project are finding value in it both on editors and language sides.

There's also Debugger Adapter Protocol iirc.

Yeah I've written about what I call "Tooling for Tooling", stuff like the LSP or tree-sitter that make it easier for language authors to build out their tooling ecosystem. I wish people invested more into these sorts of projects so we could raise the standard of tooling for everyone.

Yeah, as someone who's actively building a language right now, I can attest that the process is rough. Rough in the sense that I need to invest heavily into putting together my own set of tooling. It's a non-trivial exercise, to say the least.

Why are you creating a language? There aren't enough good ones out there to cover your use case(s)?

Not who you asked, but for me (I use a custom language for work) it was a matter of being able to do what I wanted, in the way I wanted. The other added benefits were I could ensure that code I wrote for clients and for my employer met the ethical and professional obligations that I incur as an attorney. The only downside (according to others) is that my language implementation belongs to my employer, the theoretical foundation and language definition are owned by me. Overall, I feel more productive and I feel like the value I deliver is greater than it would be in another language.

Please tell me you called it legalese.

Jokes aside, that’s a really interesting use case. I’ve often wondered how laws, and changes to them over time, are recorded. It seems like the kind of thing that could be made more efficient with a formal syntax along with version control.

I now regret that I didn’t have that thought myself. As to the encoding of laws formally, I know there are some existing attempts to achieve that, but that type of thing doesn’t really apply in my line of work. I do however have a database version of the statutes that keeps the textual history and is searchable implemented.

Looking at his Github he seems to be creating a programming language for UI designers.

Thanks, yep that's exactly what I'm doing.

Why not? It’s fun and a cool exercise. It’s like writing songs. They may not be hits but they can still be fun to make.

Yep, I'm trying to build a language that allows UI designers to express their design decisions: https://matry.design

I felt like a danged genius when I got a competent Rust writer at work to help me put the Elm LSP or tree sitter or whatever it was to work in Difftastic. Standing on the shoulders of a few giants at the same time.

LSP is a double-edge sword. Indeed, it offers a quicker path from a zero IDE support position, which is a boon not only to language authors but also to the hosting IDE. MS I’m sure recognized the leverage potential of the latter. For them faster onboarding meant all the difference, and it worked.

The downside is the nature of LSP, which is to say it is necessarily a common denominator API. As a result a tool built on LSP-based API tends to be significantly inferior compared with similar tools built on comprehensive, proprietary APIs. For instance, the IntelliJ IDEA Open API illustrates this advantage quite well.

Thus, the economically rich tool authors maintain a clear advantage _if dev experience is the key differentiator_.

True, but I guess the amount of work that goes into a proprietary bespoke IDE is on another order of magnitude. For example our team maintains an LSP server for Go with only about 3 FTE, but I guess JetBrains has a much larger team devoted to Goland (a bespoke IDE), and benefits from common infrastructure with their IDEs for Java and other languages.

As the name implies, the IntelliJ Open API is open, as in open source. It only works with IntelliJ indeed because it's the IntelliJ API, but that doesn't make it not open.

True, it is not technically “proprietary”, but it is a perfect example of a polar opposite of LSP.

Utilizing the vernacular put forth in the talk, the sophistication of the IJ API is both the means and the cost of establishing a presence on the IntelliJ-dominant Language Tooling Avenue.

There are projects that try to do this, but you do have to use them.

LLVM is one. That's pretty successful.

The JVM is another. That's very successful, there are lots of languages that build on the JVM to reduce their tooling costs. Java, Kotlin and Clojure are examples of that.

GraalVM is another. If you use their Truffle framework then you get JIT compilation, debugging, tracing, instrumentation, different kinds of interpreters, advanced strings, some LSP support, language interop and FFIs and more.

But what you see, generally, language authors tend to start by hacking together a compiler and standard library starting from a C hello world program. Not that many survey the landscape and look for ways to reduce the costs.

Racket, PyPy and Parrot (RIP) are also designed to host multiple languages. BEAM is another interesting VM (fault-tolerance, distributed systems, live updates, etc.). GNU has a bunch of projects to help language implementers, like Lightning, Jitter, libjit, superopt, etc. Eclipse's Xtext lives in the same space as tree-sitter and (to some extent) LSP.

Yeah part of the issue is that language designers by definition have not-invented-here syndrome. So it takes a lot to convince them to not write it themselves. LLVM has solved a sufficiently hard problem that it’s gotten over this barrier, but other meta-tools will likely struggle to achieve that

IMO, LLVM is more successful than JVM in this metric. JVM has definitely had some powerhouses, but it's inherent limitations has meant that it is only able to produce languages that have many of the same limitations as Java. Since LLVM generates machine code, the limitations of LLVM compiled languages end up being a lot closer to the limitations of modern processors.

As Rust folks keep re-discovering in compiler regressions, likewise LLVM has many of the limitations of the C and C++ abstract machine model.

It seems like the main problem, for implementers of languages significantly different to C and C-like languages, is that LLVM doesn't offer direct access to hardware registers or the stack, and it has built-in calling conventions. (Although, that's kind of the point of LLVM IR. GHC implementers wanted certain values to be always kept in registers, from what I understood of it.)

This was a problem in writing an LLVM backend for both the Glasgow Haskell Compiler and the Standard ML of New Jersey Compiler. It seems like it was easier for the GHC implementers, because they were already able to compile their semantic IR (the spineless tagless G-machine) into C--/Cmm, which conceptually isn't that different from LLVM IR. The SML implementers compiled to the continuation passing style, which is harder to map to LLVM IR. However, the GHC implementers still had to extend LLVM with a custom calling convention, so it was still challenging.

Paper on the LLVM backend for GHC Haskell: https://llvm.org/pubs/2010-09-HASKELLSYM-LLVM-GHC.pdf

Paper on the LLVM backend for SML/NJ: https://people.cs.uchicago.edu/~jhr/papers/2020/ifl-smlnj-ll...

Thanks for the links.

At this point, between Rust, Julia, and Swift, it is in pretty good shape. The biggest one that used to be a problem was handling of undefined behavior, but at this point, LLVM's poison system works quite well.

JVMs also produce machine code ;) In practice LLVM is designed for C/C++ like languages. You can use it for other things but not easily. GraalVM is the closest thing to a universal VM so far, but even then, it's more optimized for high level languages than stuff like Rust (even though it can run those).

Or does it allow you build a lot of very similar languages with slightly different looking syntax?

Clojure and Java are dissimilar in non-trivial ways.

Also there's a CL on the JVM - Armed Bear Common Lisp.

TruffleRuby is a good existance proof that it's not just that. (Clojure is another dynamic language, but it was designed to be hosted on the JVM so it's an easier case)

Though LLVM seems like it best maps the semantics of a language like C++, there's a fairly diverse lot of languages with LLVM backends, including Common Lisp, Haskell, Scala, and Swift.

Also got to see it live, agreed. Sat with my friend who gave a talk earlier about developing programming languages, and who was hoping for answers on how to get paid to do it. Funny how the talk ended.

I think I get the Clojure guy now.

I'm always rooting for projects like zig, odin, vale, nim, even jai. I think some killer apps are JS runtimes and defensive security, making eBPF more straightforward (and whatever tigerbeetle does... )

Reply on news.ycombinator.com