13 ms·

"TXR Lisp programs are shorter and clearer than those written in some mainstream languages "du jour" like Python, Ruby, Clojure, Javascript or Racket. If you fi

"TXR Lisp programs are shorter and clearer than those written in some mainstream languages "du jour" like Python, Ruby, Clojure, Javascript or Racket. If you find that this isn't the case, the TXR project wants to hear from you; give a shout to the mailing list. If a program is significantly clearer and shorter in another language, that is considered a bug in TXR." That section made me chuckle. Admirable if true.

auvrw 7y ago
i agree that the general-purpose programming language space is fairly crowded ... the lisp dialect/user ratio especially so. DSLs, otoh, are in short supply. while awk or plain sed are great for shell programming, this is the only (open source) DSL i'm aware of targeting certain types of NLP-esque "munging". this space is mostly full of statistical approaches, which, while conceptually pure, don't allow the kind of flexibility that would be useful in many applications. i wonder if, eventually, the DSL portion of TXR could be sheared off (possibly via metacircular evaluation of the TXR lisp?) into something that's portable across lisps or at least to semi-standardized scheme implementations?
- kazinator 7y ago
  N. Westbury has been cloning it in Java: https://github.com/westbury/txr-java https://github.com/westbury/txr-java
flavio81 7y ago
>That section made me chuckle. Admirable if true Mostly true for very high level languages like Lisp/Scheme, or ML/OCaml/F#/Haskell, when faced against not-so-high-level languages like C, C++, Java. Against Racket, i wouldn't be so sure. Nor against Ruby. Python and Javascript are high level languages but they are crippled by some bad design decisions.
- Zaak 7y ago
  I know that Python and Javascript have their warts (as do all languages in my experience), but what decisions in particular are you thinking of?
  - fnord123 7y ago
    Lambdas are limited to a single expression. Threads don't work the way anyone would ever want threads to work because o the GIL. That said, homoiconicity (s-expressions) is not a feature I want. It makes code like reading a wall of text compared to a nicely laid out magazine.
    - Zaak 7y ago
      Gotcha. I do agree about homoiconicity. It's great for writing macros, and terrible for everything else. Of course, go too far in the other direction and you get perl, so... yeah.
      - klibertp 7y ago
        I don't want to reopen this 50+ years old can of worms, but I have 2 questions: 1. Is it about homoiconicity in general or specifically s-expressions [EDIT: I see GP writes about s-exps specifically, missed it at first]? Prolog, Erlang, TCL, and Rebol (just some examples) are homoiconic, but not s-exps based. What do you think about them? 2. Do you often read code without syntax highlighting and proper indentation? Assuming the code is properly indented and colorized, what makes it so hard to read in your eyes? Take a look for example at snippets in: https://docs.racket-lang.org/quick/index.html#(part._.Local_.Binding) https://docs.racket-lang.org/quick/index.html#(part._.Local_... - what do you feel is wrong with them? Is it only the placement of parens, or is there something else?
        Zaak 7y ago
        1. It's homoiconicity in general. It's most obvious in arithmetic expressions, but homoiconicity (as far as I've seen) eschews semantic indicators besides function name and argument position. I find that keywords and symbols are almost indispensable for smooth eye-parsing of code. 2. No, I use syntax highlighting and indentation all the time. Trying to put words to my vague thoughts, I think the main issue is that, for example, in a let block the only indication of the meaning of all the items is the single function/macro name at the beginning of the block. Whereas in an algol-type language you have assignment operators in each item to indicate what they mean.

auvrw 7y ago

i agree that the general-purpose programming language space is fairly crowded ... the lisp dialect/user ratio especially so. DSLs, otoh, are in short supply. while awk or plain sed are great for shell programming, this is the only (open source) DSL i'm aware of targeting certain types of NLP-esque "munging". this space is mostly full of statistical approaches, which, while conceptually pure, don't allow the kind of flexibility that would be useful in many applications. i wonder if, eventually, the DSL portion of TXR could be sheared off (possibly via metacircular evaluation of the TXR lisp?) into something that's portable across lisps or at least to semi-standardized scheme implementations?

kazinator 7y ago
N. Westbury has been cloning it in Java: https://github.com/westbury/txr-java https://github.com/westbury/txr-java

flavio81 7y ago

>That section made me chuckle. Admirable if true Mostly true for very high level languages like Lisp/Scheme, or ML/OCaml/F#/Haskell, when faced against not-so-high-level languages like C, C++, Java. Against Racket, i wouldn't be so sure. Nor against Ruby. Python and Javascript are high level languages but they are crippled by some bad design decisions.

Zaak 7y ago
I know that Python and Javascript have their warts (as do all languages in my experience), but what decisions in particular are you thinking of?
- fnord123 7y ago
  Lambdas are limited to a single expression. Threads don't work the way anyone would ever want threads to work because o the GIL. That said, homoiconicity (s-expressions) is not a feature I want. It makes code like reading a wall of text compared to a nicely laid out magazine.
  - Zaak 7y ago
    Gotcha. I do agree about homoiconicity. It's great for writing macros, and terrible for everything else. Of course, go too far in the other direction and you get perl, so... yeah.
    - klibertp 7y ago
      I don't want to reopen this 50+ years old can of worms, but I have 2 questions: 1. Is it about homoiconicity in general or specifically s-expressions [EDIT: I see GP writes about s-exps specifically, missed it at first]? Prolog, Erlang, TCL, and Rebol (just some examples) are homoiconic, but not s-exps based. What do you think about them? 2. Do you often read code without syntax highlighting and proper indentation? Assuming the code is properly indented and colorized, what makes it so hard to read in your eyes? Take a look for example at snippets in: https://docs.racket-lang.org/quick/index.html#(part._.Local_.Binding) https://docs.racket-lang.org/quick/index.html#(part._.Local_... - what do you feel is wrong with them? Is it only the placement of parens, or is there something else?
      - Zaak 7y ago
        1. It's homoiconicity in general. It's most obvious in arithmetic expressions, but homoiconicity (as far as I've seen) eschews semantic indicators besides function name and argument position. I find that keywords and symbols are almost indispensable for smooth eye-parsing of code. 2. No, I use syntax highlighting and indentation all the time. Trying to put words to my vague thoughts, I think the main issue is that, for example, in a let block the only indication of the meaning of all the items is the single function/macro name at the beginning of the block. Whereas in an algol-type language you have assignment operators in each item to indicate what they mean.