7 ms·

The Lx Programming Language

63 points by kick 7y ago

LessDmesg 7y ago
Hmm, one might think there's a trend in how almost none of the 'programmable programming languages' catch on. Lithp, Rebol, Forth, Nemerle, this one. Perhaps it has something to do with readability being more important than writeability? Me, I find macros and implicits repulsive. Give me Zig over LX any day (Zig purposefully contains no macro facility).
- kick 7y ago
  Ruby is still one of the most popular languages (especially for beginners, whom readability is extremely important for), and it was intended as a simple Lisp. Metaprogramming doesn't make code less readable.
  - sidkshatriya 7y ago
    I am not convinced with your conclusion that metaprogramming does not make code less readable. My personal experience speaks otherwise. Metaprogramming has a lot of "magic" associated with it which makes code hard to debug and understand sometimes. You cite the success/popularity of Ruby as an example of why metaprogramming does not make code less readable. The popularity of a programming language does not mean that the language does not have significant warts. There are cultural and historical factors that make a language popular. Availability of web frameworks (e.g. Rails) are another powerful influence. For the large part, Ruby code _is_ understandable/readable if you avoid metaprogramming. Once you have a large codebase and advanced frameworks that make heavy use of metaprogramming you can quickly get lost. There are lot of "effects at a distance" i.e. one library changes something and that can break something far away and potentially not even connected. Would you say your code is readable? No, the code is not readable because it runs in a totally unexpected manner. My theory is that beginners decided to learn Ruby because it was easy to start with and it had a lot of powerful framesworks (e.g. Rails). The learning curve is gentle. But pretty soon when you start writing advanced ruby or start using advanced frameworks things can get complex.
- vkazanov 7y ago
  None catch on? Depends on how you define "programmable". Lisps are still here (think Clojure). Rust has macros. New-style C++ is mostly about metaprogramming.
- codr7 7y ago
  Now I'm curious, what is it about macros you find repulsive? And what's an 'implicit'? I would trade real macros for almost any other language feature, as having them means being able to patch over whatever is missing. The more powerful a language is, the less popular it will be. Couldn't be any other way, since only people with enough experience appreciate and feel comfortable dealing with them.
  - LessDmesg 7y ago
    What I find repulsive is that macros are a micro-optimization for the author but a huge destroyer of readability. Consider a simple macro like "if-not" - just an inverted if. In a lanaguage without macros, the maintainer can be sure that there is only one construct like if. The eyes can skim over code, easily understanding semantics of the code without reading into it. Now consider the mere possibility that some if are if-nots: suddenly the mere ifs become a minefield for the reader. And if LX claims ability to eg modify the semantics of X.Y - it's going to be an unreadabe mess. My point is, readability of code increases proportionately not just to the complexity and size of code, but also proportionately to the size of syntax. In a language with no macros, the latter is fixed and you get a linear dependency. In extensible PLs it's a quadratic one with an unknown second factor, jeesh! I think the approach with a more powerful but almost fixed language (eg Haskell where macros are hard and mostly used to generate boilerplate definitions) is better than a small but extensible language with every programmer on a contest of who makes a wittier and sleeker new control structure that is like the builtin ones but SO much cooler...
    - c3d 7y ago
      I don't know if you are aware of that, but at the time Pascal started emerging, the exact same arguments were presented by foiks used to BASIC that having the ability to add your own "words" to the language would inevitably lead to a mess. Why didn't it happen? Because programmers overall are reasonable folks. So, yes, in theory, you can define a factorial function and call it "Not_a_Cat" (technically, it is true), but nobody does that. Similarly, giving the ability to define `X in Y..Z` makes code more readable if you use it right, not less.
- pjmlp 7y ago
  Java has compiler plugins, annotations, reflection and aspect oriented programming as metaprogramming tools. .NET has T4 templates, attributes, reflection, expression trees, and F# adds code quotations to the mix.
  - thelazydogsback 7y ago
    T4 barely counts, as it's string- and not AST-based. For meta-programming to be useful, IMHO it really needs to be part of the language and base tool-chain. I certainly don't want to write code in Java, f'rinstance, that needs random compiler plug-in to weave in AOP calls, etc. But in Lisp, Prolog (and not Elixer, etc.) macros are part of "how stuff works".
    - pjmlp 7y ago
      Then languages like D don't have metaprogramming capabilities if using AST based one is considered a requirement.
  - thelazydogsback 7y ago
    F# quotations are nice, but it's really too bad that .Compile() doesn't use the actual compiler tool-chain and creates super-slow code. I understand due to history why it doesn't, but it certainly would be easier if F# used the Roslyn tool-chain.
- sitkack 7y ago
  Zig has CTFE which takes the same place as macros. It doesn't need macros because it has macros.
  - fluffything 7y ago
    Is there an example of a Zig CTFE function that, e.g., parses your whole Zig library, and generates new code from it ?
- haolez 7y ago
  They are less popular for the same reason that Go is popular: if every project is its own DSL, it becomes more difficult for newcomers to ramp up on a new project. That’s exactly what Go is good for.
- yiyus 7y ago
  There are languages like Go intended to write large systems by large teams and languages like Forth that are better suited for small software written by a single programmer. There's no need to choose between Zig and LX. Use the one that better fits the problem. If for your case that's Zig, good for you.
  - c3d 7y ago
    To be honest, the real issue with LX / XL / Tao3D is that I never ever really "finished" any implementation. By the time things were working, I had new ideas and broke things again. So except for Tao3D, I never really delivered a version of the language that was solid enough. I'm trying to work on that now, which is why I'm presently spending so much time on documenting where I want to go. The idea is that if I first write a "spec", then a community can build to implement it, and it's not just my own (limited) time. So if you are interested in helping right now, I'd say: read the doc (in progress) and send comment / doc fixes.
- dragonwriter 7y ago
  > Hmm, one might think there's a trend in how almost none of the 'programmable programming languages' catch on. Lithp, Rebol, Forth, Nemerle, this one. Uh, Lisp caught on quite well. Rebol was held back by coming out when being open source (or at least having an open spec) was expected for languages, but it wasn't until most of the interest had passed. Forth I gather was pretty popular, but fell of its peak even before Lisp did. Of course, while not with Lisp style macros, pervasive metaprogramming was a key distinguishing feature of both Python and Ruby, which both reached fairly intense levels of popularity. And of course Perl... > Me, I find macros and implicits repulsive. And it's fine that that is your taste, but it's clearly not as universal as you would like to pretend.
- chubot 7y ago
  The other important consideration is that most language users are not good language designers! This strategy is kind of "punting" a lot of design work onto the user, which has a lot of downsides.
c3d 7y ago
Disclaimer: Author of the language / web page speaking. This one is hopelessly outdated. See https://github.com/c3d/xl https://github.com/c3d/xl for the current state of things. A bit of history of the language here: https://github.com/c3d/xl/blob/master/doc/HISTORY.md https://github.com/c3d/xl/blob/master/doc/HISTORY.md. Warning: this is currently under heavy repair / refactoring, so Nothing Works™. An interesting (if old, 2010) application of the language here: http://tao3d.sourceforge.net http://tao3d.sourceforge.net. Contributions and ideas welcome.
- WesternStar 7y ago
  So I was thinking about something similar to this in the sense of a language where syntax was extendable but with making different choices. I was interested in forming some sort of base lingua franca with additional composable dialects that are available per translation unit. Imagine if you could take go know for sure you don't have any concurrency in a section or the memory management section is missing so no worries about memory management. Increasing expressiveness but also reducing cognitive load to the calling code and its interfaces and nowhere else. Want to run very complicated domain specific code and not have the guy who designs the webserver know anymore than what is nessecary to rout it great. Want to add hot code,io, complexity annotations in the code, Great(Obviously this isn't free you need good tooling and to do sampled profiling and for complexity you need to make choices about what code is complex, etc.But if we're dreaming why not dream big.). Metrics,Explicit resource bounds etc. In this context for the things most people would want i.e. concurrency you would have a readily available dialect that fits 80% of use cases which would be infrequently changed. I don't know if that makes much sense in what you have in mind but I did find what you're doing interesting.
- axilmar 7y ago
  What you did there is very cool! I am speaking for both LX as presented in the old link and the new work that you are doing. Personally I have given up creating a new programming language about a decade ago because I realized no matter what language I create, people will not use it, it it comes from a random github page. Also, existing languages cover almost all business needs and while languages like LX provide a lot of improvements, the cost of change seems to be greater than the cost of not having these improvements. As for ideas, what I'd like to see in a programming language is signal-based programming: the execution flow of a program is not 'one instruction after the other' but reactions to signals. A program shall be built by wiring output signals to input signals. I'd also like to see types morph based on run-time conditions. The most fundamental problem of all the current programming languages is that types are too rigid and don't allow for catching all the possible outcomes. For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed. I believe that the combination of signal-based programming and type morphing will increase the reliability of programs, leaving only bugs that cannot be proven to be solved due to their nature (aka like the halting problem). I may not be necessarily correct, but I have a strong belief in the above.
pmontra 7y ago
The name of the language is XL, not Lx. The title of the Readme is "XL - An extensible language" and the URL ends with /xl
- skrebbel 7y ago
  It wasn't in the past. See https://news.ycombinator.com/item?id=21425044 https://news.ycombinator.com/item?id=21425044
- c3d 7y ago
  I'm not too sure about the dates, but the rough history is this: LX: Langage expérimental (~1992) Ada like with "pragmas" extending the language LX: Langage extensible (1998): Rewrite with documented object-oriented parse tree LX/XL: Extensible language (2000) based on object-oriented parse tree, cross-language framework called Mozart, that also had a Java front-end called Moka XL2: Extensible language (2002) based on simple parse tree, 8 node types, Ada-like in syntax XL2: Self compiling compiler (2005?) with same 8-node parse tree, Ada-like XLR: LLVM-based functional variant (2008-2009), same parse tree, functional, very simple, library-defined if-then-else Tao3D: real-time 3D graphics running on XLR (2010-2015) ELiOT / ELFE: Distributed programming (2015?), based on interpreted version of XLR XL: Reconvergence of all of the above (WIP), all merged, implemented as a library with a tiny front-end.
  - c3d 7y ago
    I forgot to mention that XLR meant "XL Runtime" and was initially thought of as a back-end for XL2. Then it took a life of its own.
Reisen 7y ago
It makes me so happy to see more rewrite based languages. Another one that is extremely cool that I almost never see brought up is [pure][1][2]. [1]: https://agraef.github.io/pure-lang/ https://agraef.github.io/pure-lang/ [2]: https://github.com/agraef/pure-lang/wiki/PureIntro https://github.com/agraef/pure-lang/wiki/PureIntro

63 points by kick 7y ago

Hmm, one might think there's a trend in how almost none of the 'programmable programming languages' catch on. Lithp, Rebol, Forth, Nemerle, this one. Perhaps it has something to do with readability being more important than writeability? Me, I find macros and implicits repulsive. Give me Zig over LX any day (Zig purposefully contains no macro facility).

kick 7y ago
Ruby is still one of the most popular languages (especially for beginners, whom readability is extremely important for), and it was intended as a simple Lisp. Metaprogramming doesn't make code less readable.
- sidkshatriya 7y ago
  I am not convinced with your conclusion that metaprogramming does not make code less readable. My personal experience speaks otherwise. Metaprogramming has a lot of "magic" associated with it which makes code hard to debug and understand sometimes. You cite the success/popularity of Ruby as an example of why metaprogramming does not make code less readable. The popularity of a programming language does not mean that the language does not have significant warts. There are cultural and historical factors that make a language popular. Availability of web frameworks (e.g. Rails) are another powerful influence. For the large part, Ruby code _is_ understandable/readable if you avoid metaprogramming. Once you have a large codebase and advanced frameworks that make heavy use of metaprogramming you can quickly get lost. There are lot of "effects at a distance" i.e. one library changes something and that can break something far away and potentially not even connected. Would you say your code is readable? No, the code is not readable because it runs in a totally unexpected manner. My theory is that beginners decided to learn Ruby because it was easy to start with and it had a lot of powerful framesworks (e.g. Rails). The learning curve is gentle. But pretty soon when you start writing advanced ruby or start using advanced frameworks things can get complex.
vkazanov 7y ago
None catch on? Depends on how you define "programmable". Lisps are still here (think Clojure). Rust has macros. New-style C++ is mostly about metaprogramming.
codr7 7y ago
Now I'm curious, what is it about macros you find repulsive? And what's an 'implicit'? I would trade real macros for almost any other language feature, as having them means being able to patch over whatever is missing. The more powerful a language is, the less popular it will be. Couldn't be any other way, since only people with enough experience appreciate and feel comfortable dealing with them.
- LessDmesg 7y ago
  What I find repulsive is that macros are a micro-optimization for the author but a huge destroyer of readability. Consider a simple macro like "if-not" - just an inverted if. In a lanaguage without macros, the maintainer can be sure that there is only one construct like if. The eyes can skim over code, easily understanding semantics of the code without reading into it. Now consider the mere possibility that some if are if-nots: suddenly the mere ifs become a minefield for the reader. And if LX claims ability to eg modify the semantics of X.Y - it's going to be an unreadabe mess. My point is, readability of code increases proportionately not just to the complexity and size of code, but also proportionately to the size of syntax. In a language with no macros, the latter is fixed and you get a linear dependency. In extensible PLs it's a quadratic one with an unknown second factor, jeesh! I think the approach with a more powerful but almost fixed language (eg Haskell where macros are hard and mostly used to generate boilerplate definitions) is better than a small but extensible language with every programmer on a contest of who makes a wittier and sleeker new control structure that is like the builtin ones but SO much cooler...
  - c3d 7y ago
    I don't know if you are aware of that, but at the time Pascal started emerging, the exact same arguments were presented by foiks used to BASIC that having the ability to add your own "words" to the language would inevitably lead to a mess. Why didn't it happen? Because programmers overall are reasonable folks. So, yes, in theory, you can define a factorial function and call it "Not_a_Cat" (technically, it is true), but nobody does that. Similarly, giving the ability to define `X in Y..Z` makes code more readable if you use it right, not less.
pjmlp 7y ago
Java has compiler plugins, annotations, reflection and aspect oriented programming as metaprogramming tools. .NET has T4 templates, attributes, reflection, expression trees, and F# adds code quotations to the mix.
- thelazydogsback 7y ago
  T4 barely counts, as it's string- and not AST-based. For meta-programming to be useful, IMHO it really needs to be part of the language and base tool-chain. I certainly don't want to write code in Java, f'rinstance, that needs random compiler plug-in to weave in AOP calls, etc. But in Lisp, Prolog (and not Elixer, etc.) macros are part of "how stuff works".
  - pjmlp 7y ago
    Then languages like D don't have metaprogramming capabilities if using AST based one is considered a requirement.
- thelazydogsback 7y ago
  F# quotations are nice, but it's really too bad that .Compile() doesn't use the actual compiler tool-chain and creates super-slow code. I understand due to history why it doesn't, but it certainly would be easier if F# used the Roslyn tool-chain.
sitkack 7y ago
Zig has CTFE which takes the same place as macros. It doesn't need macros because it has macros.
- fluffything 7y ago
  Is there an example of a Zig CTFE function that, e.g., parses your whole Zig library, and generates new code from it ?
haolez 7y ago
They are less popular for the same reason that Go is popular: if every project is its own DSL, it becomes more difficult for newcomers to ramp up on a new project. That’s exactly what Go is good for.
yiyus 7y ago
There are languages like Go intended to write large systems by large teams and languages like Forth that are better suited for small software written by a single programmer. There's no need to choose between Zig and LX. Use the one that better fits the problem. If for your case that's Zig, good for you.
- c3d 7y ago
  To be honest, the real issue with LX / XL / Tao3D is that I never ever really "finished" any implementation. By the time things were working, I had new ideas and broke things again. So except for Tao3D, I never really delivered a version of the language that was solid enough. I'm trying to work on that now, which is why I'm presently spending so much time on documenting where I want to go. The idea is that if I first write a "spec", then a community can build to implement it, and it's not just my own (limited) time. So if you are interested in helping right now, I'd say: read the doc (in progress) and send comment / doc fixes.
dragonwriter 7y ago
> Hmm, one might think there's a trend in how almost none of the 'programmable programming languages' catch on. Lithp, Rebol, Forth, Nemerle, this one. Uh, Lisp caught on quite well. Rebol was held back by coming out when being open source (or at least having an open spec) was expected for languages, but it wasn't until most of the interest had passed. Forth I gather was pretty popular, but fell of its peak even before Lisp did. Of course, while not with Lisp style macros, pervasive metaprogramming was a key distinguishing feature of both Python and Ruby, which both reached fairly intense levels of popularity. And of course Perl... > Me, I find macros and implicits repulsive. And it's fine that that is your taste, but it's clearly not as universal as you would like to pretend.
chubot 7y ago
The other important consideration is that most language users are not good language designers! This strategy is kind of "punting" a lot of design work onto the user, which has a lot of downsides.

c3d 7y ago

Disclaimer: Author of the language / web page speaking. This one is hopelessly outdated. See https://github.com/c3d/xl https://github.com/c3d/xl for the current state of things. A bit of history of the language here: https://github.com/c3d/xl/blob/master/doc/HISTORY.md https://github.com/c3d/xl/blob/master/doc/HISTORY.md. Warning: this is currently under heavy repair / refactoring, so Nothing Works™. An interesting (if old, 2010) application of the language here: http://tao3d.sourceforge.net http://tao3d.sourceforge.net. Contributions and ideas welcome.

WesternStar 7y ago
So I was thinking about something similar to this in the sense of a language where syntax was extendable but with making different choices. I was interested in forming some sort of base lingua franca with additional composable dialects that are available per translation unit. Imagine if you could take go know for sure you don't have any concurrency in a section or the memory management section is missing so no worries about memory management. Increasing expressiveness but also reducing cognitive load to the calling code and its interfaces and nowhere else. Want to run very complicated domain specific code and not have the guy who designs the webserver know anymore than what is nessecary to rout it great. Want to add hot code,io, complexity annotations in the code, Great(Obviously this isn't free you need good tooling and to do sampled profiling and for complexity you need to make choices about what code is complex, etc.But if we're dreaming why not dream big.). Metrics,Explicit resource bounds etc. In this context for the things most people would want i.e. concurrency you would have a readily available dialect that fits 80% of use cases which would be infrequently changed. I don't know if that makes much sense in what you have in mind but I did find what you're doing interesting.
axilmar 7y ago
What you did there is very cool! I am speaking for both LX as presented in the old link and the new work that you are doing. Personally I have given up creating a new programming language about a decade ago because I realized no matter what language I create, people will not use it, it it comes from a random github page. Also, existing languages cover almost all business needs and while languages like LX provide a lot of improvements, the cost of change seems to be greater than the cost of not having these improvements. As for ideas, what I'd like to see in a programming language is signal-based programming: the execution flow of a program is not 'one instruction after the other' but reactions to signals. A program shall be built by wiring output signals to input signals. I'd also like to see types morph based on run-time conditions. The most fundamental problem of all the current programming languages is that types are too rigid and don't allow for catching all the possible outcomes. For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed. I believe that the combination of signal-based programming and type morphing will increase the reliability of programs, leaving only bugs that cannot be proven to be solved due to their nature (aka like the halting problem). I may not be necessarily correct, but I have a strong belief in the above.

pmontra 7y ago

The name of the language is XL, not Lx. The title of the Readme is "XL - An extensible language" and the URL ends with /xl

skrebbel 7y ago
It wasn't in the past. See https://news.ycombinator.com/item?id=21425044 https://news.ycombinator.com/item?id=21425044
c3d 7y ago
I'm not too sure about the dates, but the rough history is this: LX: Langage expérimental (~1992) Ada like with "pragmas" extending the language LX: Langage extensible (1998): Rewrite with documented object-oriented parse tree LX/XL: Extensible language (2000) based on object-oriented parse tree, cross-language framework called Mozart, that also had a Java front-end called Moka XL2: Extensible language (2002) based on simple parse tree, 8 node types, Ada-like in syntax XL2: Self compiling compiler (2005?) with same 8-node parse tree, Ada-like XLR: LLVM-based functional variant (2008-2009), same parse tree, functional, very simple, library-defined if-then-else Tao3D: real-time 3D graphics running on XLR (2010-2015) ELiOT / ELFE: Distributed programming (2015?), based on interpreted version of XLR XL: Reconvergence of all of the above (WIP), all merged, implemented as a library with a tiny front-end.
- c3d 7y ago
  I forgot to mention that XLR meant "XL Runtime" and was initially thought of as a back-end for XL2. Then it took a life of its own.

Reisen 7y ago

It makes me so happy to see more rewrite based languages. Another one that is extremely cool that I almost never see brought up is [pure][1][2]. [1]: https://agraef.github.io/pure-lang/ https://agraef.github.io/pure-lang/ [2]: https://github.com/agraef/pure-lang/wiki/PureIntro https://github.com/agraef/pure-lang/wiki/PureIntro