5 ms·

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 pro

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.

sbergot 3y ago
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.
- tester756 3y ago
  There's also Debugger Adapter Protocol iirc.
- hardwaregeek 3y ago
  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.
  - danielvaughn 3y ago
    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.
    - otteromkram 3y ago
      Why are you creating a language? There aren't enough good ones out there to cover your use case(s)?
      - throwaway17_17 3y ago
        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.
        danielvaughn 3y ago
        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.
        throwaway17_17 3y ago
        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.
      - cinntaile 3y ago
        Looking at his Github he seems to be creating a programming language for UI designers.
        3y ago
  - 1-more 3y ago
    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.
- owlstuffing 3y ago
  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_.
  - adonovan 3y ago
    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.
  - mike_hearn 3y ago
    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.
    - owlstuffing 3y ago
      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.
citruscomputing 3y ago
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.
- gtani 3y ago
  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... )
mike_hearn 3y ago
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.
- chriswarbo 3y ago
  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.
- hardwaregeek 3y ago
  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
- adgjlsfhk1 3y ago
  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.
  - pjmlp 3y ago
    As Rust folks keep re-discovering in compiler regressions, likewise LLVM has many of the limitations of the C and C++ abstract machine model.

sbergot 3y ago

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.

tester756 3y ago
There's also Debugger Adapter Protocol iirc.
hardwaregeek 3y ago
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.
- danielvaughn 3y ago
  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.
  - otteromkram 3y ago
    Why are you creating a language? There aren't enough good ones out there to cover your use case(s)?
    - throwaway17_17 3y ago
      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.
      - danielvaughn 3y ago
        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.
        throwaway17_17 3y ago
        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.
    - cinntaile 3y ago
      Looking at his Github he seems to be creating a programming language for UI designers.
      - 3y ago
- 1-more 3y ago
  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.
owlstuffing 3y ago
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_.
- adonovan 3y ago
  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.
- mike_hearn 3y ago
  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.
  - owlstuffing 3y ago
    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.

citruscomputing 3y ago

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.

gtani 3y ago
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... )

mike_hearn 3y ago

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.

chriswarbo 3y ago
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.
hardwaregeek 3y ago
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
adgjlsfhk1 3y ago
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.
- pjmlp 3y ago
  As Rust folks keep re-discovering in compiler regressions, likewise LLVM has many of the limitations of the C and C++ abstract machine model.