5 ms·

After saying that it's a dynamic general-purpose, actor language, the introduction talks about spacing style, comment style, naming and purity. That's very lac

After saying that it's a dynamic general-purpose, actor language, the introduction talks about spacing style, comment style, naming and purity. That's very lackluster. Show me a Fizzbuzz or an advent of code. Tell me a story of why it exists. Now the only discussion I can have is why are there no reserved words and can we call our functions and variables "set", "call" and "def" then?

vidarh 3y ago
And makes syntax choices (strictness of spacing that forces verbosity) that instantly guarantees that I will never consider the language.
- JonChesterfield 3y ago
  If you choose language based on syntax instead of semantics you miss everything with useful semantics which doesn't happen to use syntax you're familiar with. That seems a terrible loss. E.g. I deeply dislike the syntax of makefiles and xslt, but the declarative model is so good where it fits that it's worth dealing with the visual discomfort.
  - layer8 3y ago
    Can you recommend any learning material on XSLT that is not focused on the transform-XML-to-HTML use case?
    - JonChesterfield 3y ago
      It turns out XSLT is a trivial programming model (pattern match on the tree) with crazy aesthetics and a near-useless stdlib, which shipped a MVP called 1.0 and then got basically abandoned for json. It's a bit of a disaster of history really. There are newer and saner specifications out there which I am totally ignoring. A bit too much of the world is written in java but you can get xsltproc which is a tiny C program built on libxml2 and run that commandline style. As far as esoteric language go it's great. I'm doing dubious things involving representing ASTs in XML which I'll probably post to github. Taking an example from that in the meantime. The setup is roughly a bunch of calls to xsltproc to turn one XML representation into another: xsltproc --output thing.list.xml tree_to_list.xsl thing.tree.xml I'm liking having a schema for the before and the after forms and generally having a much better time where each individual transform doesn't do very much. The general pattern is recognise the bits you're interested in and copy everything else through unchanged, and view a given .xsl transform as a XML->XML function in weird syntax. Google will find you an "identity transform" which looks like nonsense, a lot of functions can start by copying that and then adding a match for something you care about. One of my data representations is a tree where the information of interest is all in the leaves. That gets turned into a flattened list, then that list gets turned into a text file, then something else goes "oh that text file has C in it, awesome". Tree flattening looks like a reasonable thing to copy&paste in here, thus: <?xml version="1.0" encoding="UTF-8"?>  <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:str="http://exslt.org/strings" xmlns:ext="http://exslt.org/common" extension-element-prefixes="str ext" > <xsl:output method="xml" indent="yes"/>  <xsl:template match="/TokenTree"> <TokenList> <xsl:apply-templates select="node()|@*"/> </TokenList> </xsl:template>  <xsl:template match="@*"> <xsl:copy> <xsl:apply-templates select="@*"/> </xsl:copy> </xsl:template>  <xsl:template match="node()">  <xsl:if test="not(@*)"> <xsl:apply-templates select="node()|@*"/> </xsl:if>  <xsl:if test="@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:if> </xsl:template> </xsl:transform> So yeah. The syntax is not wonderful. You write xsl: a lot, or at least your editor does. The documentation on this stuff all seems to be a bit java themed and the prevailing attitude seems to be that XML is an ugly thing from the before times. Though see also https://www.defmacro.org/ramblings/lisp.html https://www.defmacro.org/ramblings/lisp.html. I'm working by trial and error instead of documentation but that's going well enough. The "oh, that's a tree? Have a declarative DSL for functional transforms to other trees" is a really compelling example of wondrous magic hidden behind insane syntax. (for a nice bonus effect, emacs is really clear on what editing tree structured documents means, and there's a "relax-ng" schema which you can use to find errors in the XML and to have emacs tell you lots of stuff about the document as you type it)
      - vidarh 3y ago
        I see the appeal of that - I used to toy with a language whose default representation was XML (with two way translation from/to text as well as a diagram based editor), but XSL is way to verbose a syntax for me to interface with what is a very simple core you can build out as a library to write the same kind of tree rewrites. Today I'd pick that option over actually using XSL anywhere - to me the only redeeming feature of XSL itself is/was the built-in support for applying XSL to XML in browsers (I worked on a web app ~2006 where XML was translated to HTML using XSL on the frontend, and you could turn off the server-side transformation and let the browser do it instead, which meant your source view was the underlying XML, which was very handy for debugging).
  - vidarh 3y ago
    There are more than enough options that there is rarely a compelling reason to suffer. Useful semantics rarely remains confined. I spent too much time working with syntax to tolerate one that makes the code more time consuming to read or write (and that includes XSL; I worked a lot with XSL, and I'm not doing it again - if I need its semantics I'll implement something to do it with a less insane syntax).
brabel 3y ago
This is the spec for the language Douglas Crockford (author of the book "JavaScript: The Good Parts", the JSON specification[1], JSLint[2]) had explained in his famous talk: "The Next Programming Language"[3]. The "big things" in the language are the Actor model, favouring immutability and capabilities-based security. Presumably, there will be a flashy website later that actually motivates why you should use this language and what's cool about it. Notice this looks similar to the JSON spec website[4]. [1] https://en.wikipedia.org/wiki/JSON https://en.wikipedia.org/wiki/JSON [2] https://www.jslint.com/ https://www.jslint.com/ [3] https://www.youtube.com/watch?v=R2idkNdKqpQ https://www.youtube.com/watch?v=R2idkNdKqpQ [4] https://www.json.org/json-en.html https://www.json.org/json-en.html
- JackMorgan 3y ago
  Thanks for linking the talk, that helped a lot to see where he's coming from.
Modified3019 3y ago
I think space-style nonsense was a great thing to have up front, because it immediately informed me that I will hate this language and never use it. Genuinely appreciate them saving me time.
- FrustratedMonky 3y ago
  I don't get this. Do you purposely 'not' indent your code, to obfuscate it?
  - ktm5j 3y ago
    I think they share my distaste of languages (like python) that use indentation instead of brackets to signify a code block. People have different preferences and it's totally valid, whatever the reason for those preferences.
    - FrustratedMonky 3y ago
      What I don't get is, even if you have brackets, you should be indenting and organizing your code. It seems like people that fight against indenting must have some bad habits, and are upset that the compiler is enforcing any change. Like rehab, they have an addiction (sloppy indenting, poor organization), and the compiler is rehab (forcing you to deal with your addiction to give up bad habits). I do prefer brackets as they are more 'clear'. That doesn't mean different peoples code should have wildly different ways of indenting. We all follow the same traffic rules or it turns into chaos.
      - gkbrk 3y ago
        Copy-pasting Python code can easily end up in wrong indentation and broken code. Copy-pasting code in bracketed languages usually pastes and then auto-formats that section automatically.
        norir 3y ago

vidarh 3y ago

And makes syntax choices (strictness of spacing that forces verbosity) that instantly guarantees that I will never consider the language.

JonChesterfield 3y ago
If you choose language based on syntax instead of semantics you miss everything with useful semantics which doesn't happen to use syntax you're familiar with. That seems a terrible loss. E.g. I deeply dislike the syntax of makefiles and xslt, but the declarative model is so good where it fits that it's worth dealing with the visual discomfort.
- layer8 3y ago
  Can you recommend any learning material on XSLT that is not focused on the transform-XML-to-HTML use case?
  - JonChesterfield 3y ago
    It turns out XSLT is a trivial programming model (pattern match on the tree) with crazy aesthetics and a near-useless stdlib, which shipped a MVP called 1.0 and then got basically abandoned for json. It's a bit of a disaster of history really. There are newer and saner specifications out there which I am totally ignoring. A bit too much of the world is written in java but you can get xsltproc which is a tiny C program built on libxml2 and run that commandline style. As far as esoteric language go it's great. I'm doing dubious things involving representing ASTs in XML which I'll probably post to github. Taking an example from that in the meantime. The setup is roughly a bunch of calls to xsltproc to turn one XML representation into another: xsltproc --output thing.list.xml tree_to_list.xsl thing.tree.xml I'm liking having a schema for the before and the after forms and generally having a much better time where each individual transform doesn't do very much. The general pattern is recognise the bits you're interested in and copy everything else through unchanged, and view a given .xsl transform as a XML->XML function in weird syntax. Google will find you an "identity transform" which looks like nonsense, a lot of functions can start by copying that and then adding a match for something you care about. One of my data representations is a tree where the information of interest is all in the leaves. That gets turned into a flattened list, then that list gets turned into a text file, then something else goes "oh that text file has C in it, awesome". Tree flattening looks like a reasonable thing to copy&paste in here, thus: <?xml version="1.0" encoding="UTF-8"?>  <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:str="http://exslt.org/strings" xmlns:ext="http://exslt.org/common" extension-element-prefixes="str ext" > <xsl:output method="xml" indent="yes"/>  <xsl:template match="/TokenTree"> <TokenList> <xsl:apply-templates select="node()|@*"/> </TokenList> </xsl:template>  <xsl:template match="@*"> <xsl:copy> <xsl:apply-templates select="@*"/> </xsl:copy> </xsl:template>  <xsl:template match="node()">  <xsl:if test="not(@*)"> <xsl:apply-templates select="node()|@*"/> </xsl:if>  <xsl:if test="@*"> <xsl:copy> <xsl:apply-templates select="node()|@*"/> </xsl:copy> </xsl:if> </xsl:template> </xsl:transform> So yeah. The syntax is not wonderful. You write xsl: a lot, or at least your editor does. The documentation on this stuff all seems to be a bit java themed and the prevailing attitude seems to be that XML is an ugly thing from the before times. Though see also https://www.defmacro.org/ramblings/lisp.html https://www.defmacro.org/ramblings/lisp.html. I'm working by trial and error instead of documentation but that's going well enough. The "oh, that's a tree? Have a declarative DSL for functional transforms to other trees" is a really compelling example of wondrous magic hidden behind insane syntax. (for a nice bonus effect, emacs is really clear on what editing tree structured documents means, and there's a "relax-ng" schema which you can use to find errors in the XML and to have emacs tell you lots of stuff about the document as you type it)
    - vidarh 3y ago
      I see the appeal of that - I used to toy with a language whose default representation was XML (with two way translation from/to text as well as a diagram based editor), but XSL is way to verbose a syntax for me to interface with what is a very simple core you can build out as a library to write the same kind of tree rewrites. Today I'd pick that option over actually using XSL anywhere - to me the only redeeming feature of XSL itself is/was the built-in support for applying XSL to XML in browsers (I worked on a web app ~2006 where XML was translated to HTML using XSL on the frontend, and you could turn off the server-side transformation and let the browser do it instead, which meant your source view was the underlying XML, which was very handy for debugging).
- vidarh 3y ago
  There are more than enough options that there is rarely a compelling reason to suffer. Useful semantics rarely remains confined. I spent too much time working with syntax to tolerate one that makes the code more time consuming to read or write (and that includes XSL; I worked a lot with XSL, and I'm not doing it again - if I need its semantics I'll implement something to do it with a less insane syntax).

brabel 3y ago

This is the spec for the language Douglas Crockford (author of the book "JavaScript: The Good Parts", the JSON specification[1], JSLint[2]) had explained in his famous talk: "The Next Programming Language"[3]. The "big things" in the language are the Actor model, favouring immutability and capabilities-based security. Presumably, there will be a flashy website later that actually motivates why you should use this language and what's cool about it. Notice this looks similar to the JSON spec website[4]. [1] https://en.wikipedia.org/wiki/JSON https://en.wikipedia.org/wiki/JSON [2] https://www.jslint.com/ https://www.jslint.com/ [3] https://www.youtube.com/watch?v=R2idkNdKqpQ https://www.youtube.com/watch?v=R2idkNdKqpQ [4] https://www.json.org/json-en.html https://www.json.org/json-en.html

JackMorgan 3y ago
Thanks for linking the talk, that helped a lot to see where he's coming from.

Modified3019 3y ago

I think space-style nonsense was a great thing to have up front, because it immediately informed me that I will hate this language and never use it. Genuinely appreciate them saving me time.

FrustratedMonky 3y ago
I don't get this. Do you purposely 'not' indent your code, to obfuscate it?
- ktm5j 3y ago
  I think they share my distaste of languages (like python) that use indentation instead of brackets to signify a code block. People have different preferences and it's totally valid, whatever the reason for those preferences.
  - FrustratedMonky 3y ago
    What I don't get is, even if you have brackets, you should be indenting and organizing your code. It seems like people that fight against indenting must have some bad habits, and are upset that the compiler is enforcing any change. Like rehab, they have an addiction (sloppy indenting, poor organization), and the compiler is rehab (forcing you to deal with your addiction to give up bad habits). I do prefer brackets as they are more 'clear'. That doesn't mean different peoples code should have wildly different ways of indenting. We all follow the same traffic rules or it turns into chaos.
    - gkbrk 3y ago
      Copy-pasting Python code can easily end up in wrong indentation and broken code. Copy-pasting code in bracketed languages usually pastes and then auto-formats that section automatically.
      - norir 3y ago