I totally agree with most of the content of this article but. Regarding formatting I would go farther than that.
I would love if all programming language had “normal form” for their source code. The very least would be that Formatter should be projections ( format(x) = format(format(x)) ). But a normal form would be even better. I know this is something very difficult to achieve mostly because of social issues regarding code formatting preferences. Typically, what about the 80 column rule? Etc… By normal form I mean a function that would parse your code to an AST and only use the AST to output a formatted text. The normal form won’t be affected by adding/removing a newline, adding spaces/tabs, changing alignments. It should be affected by comment though, that would certainly change some programming languages paradigm because it would mean that the comment should be part of the AST even if ignored. I am sure I forget a lot of difficulties about how to write one.
One big advantage about having such a normal form is that it would separate the “syntax” from the “AST” and it would be easier to split the “parsing” of your language for your preferred syntax. It would then be easier to have tools that could provide different equivalent syntaxes for your language. You could choose between “C/C++/Javascript like format”, “Python / Ruby” like format, ML/Haskell-like format, LISP like format, etc… But in the end the code would only be the “AST” using one of those format, typically the one considered the most readable by the team. Also it would greatly reduce “false” commit that are only a reformatting away.
This idea has been tried MANY times. I watched a talk about a Lisp that provided skinnable Python, C, etc. syntax maybe 12 years ago.
I would just try making a language yourself that does this, and you might realize why it isn’t a more widely adopted idea. It’s not like nobody has thought of it for the last 20-30 years.
I came up with a very similar idea. I got it from GUI skinning. So, you have the base language represented by a grammar or something. Then, the IDE can let the programmer define their own syntax that any file they receive is automatically converted to. Then, there were certain differences in structuring that might be handled with source-to-source translation like in Semantic Design’s tool.
You can do this with reader macros in lisp. In addition to switching per file, you can switch between syntaxes in the same file with #. Most people don’t bother, but it’s already implemented if you want it.
Not only is that very difficult to do technically, it ignores that languages are usually chosen to take advantage of concepts that may not exist in another language.
If I write a template in C++, how do I translate that into Haskell? How do I translate it to Go? If I use the built-in parallelism in Erlang, how do I translate that to Python? If I use a Python list, what does that become in C++?
It’d be incredibly difficult to implement, or it would end up with a common denominator subset of features that wasn’t particularly useful.
I think a group of languages could be designed from the ground up to be AST compatible with each other, but I doubt it’s possible to do for an arbitrary group of existing languages.
Regarding IDEs, I think that a very exciting “modern” development are the language servers. Rather than packaging all the typical IDE features into a single program, a small server responds to IDE queries (e.g., what are the valid completions for “wri”, where is logger.warn defined, etc.). This makes it possible to keep using your favorite editor without having to sacrifice useful features. OCaml’s Merlin and Rust’s Racer and RLS are examples of this.
It’s helpful for me to see language-specific package management in the list of modern features. It’s something I’ve found to be rather a nuisance, but I suppose I’d be suffering more without. Is it misguided to hope for cross-language package management, based on something like nix?
As an aside, while looking into the language package management history (I suppose things sort of started with CTAN and CPAN?), I ran across binary repository managers. Is the notion widespread? The Wikipedia articles read like something out of the marketing department of the listed projects…
And so we are clear, Java had guidelines, but guidelines are insufficient.
I’ve heard, but I’m not certain this is accurate, that one of Java’s problems was that a lot of the Java code that Sun released themselves (even code for the standard library?) didn’t follow them at all.
If language designers were serious about the “one-style-to-rule-them-all” (I’m looking at you, Rob Pike) then they would make the “one-style-to-rule-them-all” as part of the language. If you have to rely upon another program, the language designers failed.
I would personally put version control itself, for most companies, in the “not really modern” category. 20 years ago most were using CVS, Perforce, or something similar, and now most are using… well, often still Perforce or similar, or else git but with a central-repository model rather than really using it as a DVCS in the way the Linux kernel does.
Some of the tooling around it has changed, though, things like web-based patch proposal and code review (whether in a Gerritt style or GitHub pull requests style or whatever).
I totally agree with most of the content of this article but. Regarding formatting I would go farther than that.
I would love if all programming language had “normal form” for their source code. The very least would be that Formatter should be projections ( format(x) = format(format(x)) ). But a normal form would be even better. I know this is something very difficult to achieve mostly because of social issues regarding code formatting preferences. Typically, what about the 80 column rule? Etc… By normal form I mean a function that would parse your code to an AST and only use the AST to output a formatted text. The normal form won’t be affected by adding/removing a newline, adding spaces/tabs, changing alignments. It should be affected by comment though, that would certainly change some programming languages paradigm because it would mean that the comment should be part of the AST even if ignored. I am sure I forget a lot of difficulties about how to write one.
One big advantage about having such a normal form is that it would separate the “syntax” from the “AST” and it would be easier to split the “parsing” of your language for your preferred syntax. It would then be easier to have tools that could provide different equivalent syntaxes for your language. You could choose between “C/C++/Javascript like format”, “Python / Ruby” like format, ML/Haskell-like format, LISP like format, etc… But in the end the code would only be the “AST” using one of those format, typically the one considered the most readable by the team. Also it would greatly reduce “false” commit that are only a reformatting away.
This idea has been tried MANY times. I watched a talk about a Lisp that provided skinnable Python, C, etc. syntax maybe 12 years ago.
I would just try making a language yourself that does this, and you might realize why it isn’t a more widely adopted idea. It’s not like nobody has thought of it for the last 20-30 years.
I came up with a very similar idea. I got it from GUI skinning. So, you have the base language represented by a grammar or something. Then, the IDE can let the programmer define their own syntax that any file they receive is automatically converted to. Then, there were certain differences in structuring that might be handled with source-to-source translation like in Semantic Design’s tool.
I never went past the concept, though.
You can do this with reader macros in lisp. In addition to switching per file, you can switch between syntaxes in the same file with
#.Most people don’t bother, but it’s already implemented if you want it.Not only is that very difficult to do technically, it ignores that languages are usually chosen to take advantage of concepts that may not exist in another language.
If I write a template in C++, how do I translate that into Haskell? How do I translate it to Go? If I use the built-in parallelism in Erlang, how do I translate that to Python? If I use a Python list, what does that become in C++?
It’d be incredibly difficult to implement, or it would end up with a common denominator subset of features that wasn’t particularly useful.
I think a group of languages could be designed from the ground up to be AST compatible with each other, but I doubt it’s possible to do for an arbitrary group of existing languages.
Regarding IDEs, I think that a very exciting “modern” development are the language servers. Rather than packaging all the typical IDE features into a single program, a small server responds to IDE queries (e.g., what are the valid completions for “wri”, where is
logger.warndefined, etc.). This makes it possible to keep using your favorite editor without having to sacrifice useful features. OCaml’s Merlin and Rust’s Racer and RLS are examples of this.It’s helpful for me to see language-specific package management in the list of modern features. It’s something I’ve found to be rather a nuisance, but I suppose I’d be suffering more without. Is it misguided to hope for cross-language package management, based on something like nix?
As an aside, while looking into the language package management history (I suppose things sort of started with CTAN and CPAN?), I ran across binary repository managers. Is the notion widespread? The Wikipedia articles read like something out of the marketing department of the listed projects…
I’ve heard, but I’m not certain this is accurate, that one of Java’s problems was that a lot of the Java code that Sun released themselves (even code for the standard library?) didn’t follow them at all.
Ditto Python and PEP-8.
If language designers were serious about the “one-style-to-rule-them-all” (I’m looking at you, Rob Pike) then they would make the “one-style-to-rule-them-all” as part of the language. If you have to rely upon another program, the language designers failed.
When language designers fail to impose their preferences as part cult, part fascism, I don’t see that as a downside!
I would personally put version control itself, for most companies, in the “not really modern” category. 20 years ago most were using CVS, Perforce, or something similar, and now most are using… well, often still Perforce or similar, or else git but with a central-repository model rather than really using it as a DVCS in the way the Linux kernel does.
Some of the tooling around it has changed, though, things like web-based patch proposal and code review (whether in a Gerritt style or GitHub pull requests style or whatever).
Idk about others but it helped me. Nice one..