5 ms·

> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that

by chrsig 3y ago

> I've lately thought that a package manager is as essential to a new language as a standard library. I would also add a LSP and standard code formatter to that list. Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. > It is a bit unfortunate because all of the above is a pretty tall order. We're getting to the point that new languages are expected to boil the ocean by the time they reach 1.0 In order to get into production? yes. there are minimum requirements that must be met. those are higher now than in the past, because of lessons learned the hard way. those problems have been solved (for some value of solved) in existing ecosystems -- a new language wont change the need for them to be solved. it shatters the dream of hacking up something on a weekend and having it turn into a hit success, but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years. Until they have what you mentioned, the languages aren't ready for large scale use -- they need to grow into it. They can be useful prior to that -- enthusiasts and early adopters can reap what benefits are provided. That adoption is what fuels the development of things like a standard code formatter. edit: fixed omission of a unit of time after '30'

clessg 3y ago
> but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years Ha, I thought this sounded distressingly familiar! "In September 1995, a Netscape programmer named Brandan Eich developed a new scripting language in just 10 days. It was originally named Mocha, but quickly became known as LiveScript and, later, JavaScript."
- erhaetherth 3y ago
  I think JS was somehow salvaged after all that time. The event loop paradigm is lovely.
6keZbCECT2uB 3y ago
Not sure about lsp, but I think if you defined your language in tree sitter, you might be able to define a basic autoformatter generically on tree sitter to accelerate bootstrapping your language. You could also use an existing language agnostic package manager like nix, guix, or conda to bootstrap your language package manager. Lsp is something I don't know of a way to make that easy without overly constraining the design space.
xormapmap 3y ago
> Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. Are people realistically reviewing code formatting? As long as people aren't making egregious violations I generally don't care if someone leaves a brace on the same line or writes a one-line if statement. I tend to review the overall design and look for bugs and edge cases that might've been missed. If somebody told me they didn't like the way I formatted the code then they've got their own editor and are welcome to change it if they want to be petty.
- throwawaymaths 3y ago
  Nobody is reviewing it. They are rejecting malformatted code in CI step.
  - nickcox 3y ago
    That's not the workflow your GP is describing.
- xxpor 3y ago
  Absolutely. Inconsistency is sloppy, increases cognitive burden while reading code, and can hide bugs. Everyone should take the time to setup their editor to format their code consistent with the project style, it doesn't take long at all.
- hyperhopper 3y ago
  You're looking at it the wrong way People review code. As soon as that happens, formatting is part of the conversation. Either consciously or subconsciously
- patmorgan23 3y ago
  The point of the auto formatter is to get those slight differences out of the way so your Brian can focus on parsing and understanding the important parts
- brundolf 3y ago
  In addition to reviews, I've started to really enjoy format-on-save as a way to save keystrokes. Instead of manually formatting my code (even for myself), I can take the shortest editor path to the AST that I want and then have everything else snap into place
erhaetherth 3y ago
Makes me so sad that I can't just code up a parser and have a useable language. I have a lot of ideas, but heck, just syntax highlighting is... I don't know where to begin. And auto-completions. I need a tool that does 90% of that like PegJS or other parser-generators do for the parsing part. Don't see why a parser-generator can't also spit out an LSP. And if it knows what tokens are valid next, it should be able to generate completion suggestions. And if you have an AST, you can probably format the code half decently. And then I imagine it's possible to have a semi-universal package manager, I don't know why we need one per language, really. Aren't they all "put some code in some predefined location, and resolve these dependencies with semver please"? Maybe some extra junk for precompiled deps but still.
- aldanor 3y ago
  Because LSP is not just "give me some semi-decent completions based on parsing tokens in this file". Proper LSP will treat code semantically, in case of e.g. Rust it may complete a method name from a trait method because you have the trait somewhere in scope, which comes from a third-party package which the LSP also parses, where it needs to expand some procedural macros to get to source code, etc etc. We've been spoiled by good LSPs, perhaps. But again, it's not just "parse this file please".

by chrsig 3y ago

clessg 3y ago

> but it also removes the case of hacking up something in 10 days and suffering the consequences for the next 30 years Ha, I thought this sounded distressingly familiar! "In September 1995, a Netscape programmer named Brandan Eich developed a new scripting language in just 10 days. It was originally named Mocha, but quickly became known as LiveScript and, later, JavaScript."

erhaetherth 3y ago
I think JS was somehow salvaged after all that time. The event loop paradigm is lovely.

6keZbCECT2uB 3y ago

Not sure about lsp, but I think if you defined your language in tree sitter, you might be able to define a basic autoformatter generically on tree sitter to accelerate bootstrapping your language. You could also use an existing language agnostic package manager like nix, guix, or conda to bootstrap your language package manager. Lsp is something I don't know of a way to make that easy without overly constraining the design space.

xormapmap 3y ago

> Agreed. Especially on a formatter. The number of code review comments it cuts out is incredibly time and energy saving. Are people realistically reviewing code formatting? As long as people aren't making egregious violations I generally don't care if someone leaves a brace on the same line or writes a one-line if statement. I tend to review the overall design and look for bugs and edge cases that might've been missed. If somebody told me they didn't like the way I formatted the code then they've got their own editor and are welcome to change it if they want to be petty.

throwawaymaths 3y ago
Nobody is reviewing it. They are rejecting malformatted code in CI step.
- nickcox 3y ago
  That's not the workflow your GP is describing.
xxpor 3y ago
Absolutely. Inconsistency is sloppy, increases cognitive burden while reading code, and can hide bugs. Everyone should take the time to setup their editor to format their code consistent with the project style, it doesn't take long at all.
hyperhopper 3y ago
You're looking at it the wrong way People review code. As soon as that happens, formatting is part of the conversation. Either consciously or subconsciously
patmorgan23 3y ago
The point of the auto formatter is to get those slight differences out of the way so your Brian can focus on parsing and understanding the important parts
brundolf 3y ago
In addition to reviews, I've started to really enjoy format-on-save as a way to save keystrokes. Instead of manually formatting my code (even for myself), I can take the shortest editor path to the AST that I want and then have everything else snap into place

erhaetherth 3y ago

Makes me so sad that I can't just code up a parser and have a useable language. I have a lot of ideas, but heck, just syntax highlighting is... I don't know where to begin. And auto-completions. I need a tool that does 90% of that like PegJS or other parser-generators do for the parsing part. Don't see why a parser-generator can't also spit out an LSP. And if it knows what tokens are valid next, it should be able to generate completion suggestions. And if you have an AST, you can probably format the code half decently. And then I imagine it's possible to have a semi-universal package manager, I don't know why we need one per language, really. Aren't they all "put some code in some predefined location, and resolve these dependencies with semver please"? Maybe some extra junk for precompiled deps but still.

aldanor 3y ago
Because LSP is not just "give me some semi-decent completions based on parsing tokens in this file". Proper LSP will treat code semantically, in case of e.g. Rust it may complete a method name from a trait method because you have the trait somewhere in scope, which comes from a third-party package which the LSP also parses, where it needs to expand some procedural macros to get to source code, etc etc. We've been spoiled by good LSPs, perhaps. But again, it's not just "parse this file please".