3 ms·

I remember having just left a scala event I was running in a cab, and seeing Martin on a london bridge with a gaggle of guys following him. I wasnt aware he was

I remember having just left a scala event I was running in a cab, and seeing Martin on a london bridge with a gaggle of guys following him. I wasnt aware he was the student of Nikalus Wirth -- but it makes a lot of sense. It's a shame though, that Wirth's philosophy was, imv, ditched from 90s-00s (where we get: python, js, ruby, ...scala). It seems now language design is rediscovering Wirth and his techniques (see, eg., google's carbon which iirc, seeks to be ast-free single-pass).

7thaccount 3y ago
Everything is a balance. Can you have the power of Python in a Wirth-like language? Pascal compiles fast into executables that are easy to distribute. Python is extremely flexible and easy to use for a wide array of problems, but is a packaging nightmare. Languages like C are blazing fast and easy to distribute, but require a lot of code to do what I can do in a few lines of Python. I haven't used Swift, but hear it may be a bit of a compromise in that it compiles (albeit not in a single pass I don't think) and using it is not that much more verbose than Python. I know Nim and Crystal are similar attempts, but Nim doesn't seem as easy to use to me.
- archargelod 3y ago
  > ... but Nim doesn't seem as easy to use to me. Hm... Can you elaborate why? For me, Nim is the easiest language to work with. It really feels like Python with static typing. This one is probably a hot take, but I believe that static typing is vastly superior and easier to think about than dynamic typing. In languages like Python or JS, Lua, etc. it's not like they don't have types, types are merely hidden, you still should be aware of types. They just move responsibilty for handling type errors from compiler to the programmer. Or maybe because Nim is extensible? I know that big point of Nim is macros, and macros in general are hard. But in my experience I've never felt that I need to write one, when using Nim.
- mjburgess 3y ago
  The jai, zig, etc. approach is compile-time metaprogramming; make the compiler available to program, make the build system plugging into the compiler. Then I think you can do it. The compile-time is "a Wirth" and the runtime is "a Wirth". You get 95% the benefits of a python, since 95% of the dynamics you want are actually just static transformations of the program.
  - 7thaccount 3y ago
    I don't see how you can get 95% of the benefits of Python by programming in Zig. When I looked into Zig, it was like coding in C. Not as many built-in data structures and you have to manually manage memory and all that. Zig seems like an attempt for a better C.
    - mjburgess 3y ago
      for most applications you dont need gc, you can just have a one-off temporary allocator. you only really need the malloc model, or the gc model, of memory management for long running apps for python-style apps, theyre all die quickly
cwzwarich 3y ago
> (see, eg., google's carbon which iirc, seeks to be ast-free single-pass) Carbon’s (mostly hypothetical) frontend is actually 3 passes: lexing, parsing, and a semantic analysis pass, each with separate IRs. One of their arguments is actually that they are more efficient as separate passes operating on packed data structures rather than e.g. a parser that calls into a lexer for each individual token. In a way, this is a claim that Wirth’s approach is inherently inefficient on contemporary CPU microarchitectures.
- mjburgess 3y ago
  Hmm, i read it as "wirthing" each layer. since, iirc, the IR representation of each pass is in fact, basically, just a linear array of ints. So you have linear scans on top of linear scans.
norir 3y ago
There is something deeply attractive about writing an ast-free single pass compiler. It's a great exercise to write a compiler that targets a scripting language like lua or js in a single pass. I think though that there are significant advantages to having an ast and multiple compilation passes, particularly on present day computers that have effectively unlimited memory for the purpose of compiling a single source file. Multiple passes allows you to break down the problem into separate orthogonal components. To support the same functionality in a single pass, you have to jam an enormous amount of functionality into one place which can make it very difficult to see the forest of the trees as well as introduce unintended coupling. It also is difficult to implement certain recursive features in a single pass (though this could be considered an advantage depending on how powerful you intend the language to be). Ideally, a compiler can also provide apis that will expose the ast at different phases. It is somewhat sad to me that tree-sitter has emerged as an LCD solution for syntax highlighting and semantic analysis. If a compiler could export e.g. a json representation of the ast after parsing, that could be used for syntax highlighting rather than tree-sitter.
- disconcision 3y ago
  tree sitter seems to do pretty well in its limited role; why is this unfortunate in your opinion?
  - NateEag 3y ago
    Not OP, but I think their point was clear - they seem to wish that compilers offered their own ASTs / tools for working with ASTs, so that tools like tree-sitter wouldn't exist at all. It makes sense - tree-sitter is in large part a reimplementation of many, many parsers, and supporting a new language means duplicating yet another parser. The tree-sitter grammars are doomed by nature to forever chase the latest features in any evolving language, and reaching full compatibility turns out to be a ton of effort in many cases. That said, language design being the freewheeling "if you can dream it, you can make it" thing it is, though, I doubt it's realistic to expect every language to have a fully-reusable, standardized parser - people just won't ever be that consistent, IMO. Those who want consistency will need to provide it themselves, in the form of tools like tree-sitter.

7thaccount 3y ago

Everything is a balance. Can you have the power of Python in a Wirth-like language? Pascal compiles fast into executables that are easy to distribute. Python is extremely flexible and easy to use for a wide array of problems, but is a packaging nightmare. Languages like C are blazing fast and easy to distribute, but require a lot of code to do what I can do in a few lines of Python. I haven't used Swift, but hear it may be a bit of a compromise in that it compiles (albeit not in a single pass I don't think) and using it is not that much more verbose than Python. I know Nim and Crystal are similar attempts, but Nim doesn't seem as easy to use to me.

archargelod 3y ago
> ... but Nim doesn't seem as easy to use to me. Hm... Can you elaborate why? For me, Nim is the easiest language to work with. It really feels like Python with static typing. This one is probably a hot take, but I believe that static typing is vastly superior and easier to think about than dynamic typing. In languages like Python or JS, Lua, etc. it's not like they don't have types, types are merely hidden, you still should be aware of types. They just move responsibilty for handling type errors from compiler to the programmer. Or maybe because Nim is extensible? I know that big point of Nim is macros, and macros in general are hard. But in my experience I've never felt that I need to write one, when using Nim.
mjburgess 3y ago
The jai, zig, etc. approach is compile-time metaprogramming; make the compiler available to program, make the build system plugging into the compiler. Then I think you can do it. The compile-time is "a Wirth" and the runtime is "a Wirth". You get 95% the benefits of a python, since 95% of the dynamics you want are actually just static transformations of the program.
- 7thaccount 3y ago
  I don't see how you can get 95% of the benefits of Python by programming in Zig. When I looked into Zig, it was like coding in C. Not as many built-in data structures and you have to manually manage memory and all that. Zig seems like an attempt for a better C.
  - mjburgess 3y ago
    for most applications you dont need gc, you can just have a one-off temporary allocator. you only really need the malloc model, or the gc model, of memory management for long running apps for python-style apps, theyre all die quickly

cwzwarich 3y ago

> (see, eg., google's carbon which iirc, seeks to be ast-free single-pass) Carbon’s (mostly hypothetical) frontend is actually 3 passes: lexing, parsing, and a semantic analysis pass, each with separate IRs. One of their arguments is actually that they are more efficient as separate passes operating on packed data structures rather than e.g. a parser that calls into a lexer for each individual token. In a way, this is a claim that Wirth’s approach is inherently inefficient on contemporary CPU microarchitectures.

mjburgess 3y ago
Hmm, i read it as "wirthing" each layer. since, iirc, the IR representation of each pass is in fact, basically, just a linear array of ints. So you have linear scans on top of linear scans.

norir 3y ago

There is something deeply attractive about writing an ast-free single pass compiler. It's a great exercise to write a compiler that targets a scripting language like lua or js in a single pass. I think though that there are significant advantages to having an ast and multiple compilation passes, particularly on present day computers that have effectively unlimited memory for the purpose of compiling a single source file. Multiple passes allows you to break down the problem into separate orthogonal components. To support the same functionality in a single pass, you have to jam an enormous amount of functionality into one place which can make it very difficult to see the forest of the trees as well as introduce unintended coupling. It also is difficult to implement certain recursive features in a single pass (though this could be considered an advantage depending on how powerful you intend the language to be). Ideally, a compiler can also provide apis that will expose the ast at different phases. It is somewhat sad to me that tree-sitter has emerged as an LCD solution for syntax highlighting and semantic analysis. If a compiler could export e.g. a json representation of the ast after parsing, that could be used for syntax highlighting rather than tree-sitter.

disconcision 3y ago
tree sitter seems to do pretty well in its limited role; why is this unfortunate in your opinion?
- NateEag 3y ago
  Not OP, but I think their point was clear - they seem to wish that compilers offered their own ASTs / tools for working with ASTs, so that tools like tree-sitter wouldn't exist at all. It makes sense - tree-sitter is in large part a reimplementation of many, many parsers, and supporting a new language means duplicating yet another parser. The tree-sitter grammars are doomed by nature to forever chase the latest features in any evolving language, and reaching full compatibility turns out to be a ton of effort in many cases. That said, language design being the freewheeling "if you can dream it, you can make it" thing it is, though, I doubt it's realistic to expect every language to have a fully-reusable, standardized parser - people just won't ever be that consistent, IMO. Those who want consistency will need to provide it themselves, in the form of tools like tree-sitter.