7 ms·

what is this obsession with terse languages that look like a composition of random characters, didn't we learn from Perl

by cheez 6y ago

rscho 6y ago
Terse languages are a must for single or few-user experiments, e.g. research. Not everyone is implementing a commercial website that needs to be understood by 50 people.
- j88439h84 6y ago
  I still use good variable names in projects where I'm the only person reading the code. I wouldn't remember what things mean otherwise.
  - cheez 6y ago
    Indeed.
  - rscho 6y ago
    We have a different definition of terseness.
    - j88439h84 6y ago
      What do you mean?
      - rscho 6y ago
        I mean that programming in a terse language has nothing to do with obscure variable names. The point of terse languages is that knowing the primitives allows you to write concise programs comfortably. It doesn't mean you have to use single letter variables which in opposition to primitives do change between programs.
        j88439h84 6y ago
        Isn't the way those languages make concise programs by having short symbols instead of descriptive names? Comparing NumPy to APL it looks that way. https://analyzethedatanotthedrivel.org/2018/03/31/numpy-another-iverson-ghost/ https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot...
        rscho 6y ago
        Well yeah, referring to my above comment the primitives are symbols and it's expected that the user knows them, just as you're supposed to know the keywords in any language. Good (professional) APL though, will intersperse those primitives with meaningful variable names. Whether one thinks it's worth the effort to know the symbols vs know the keywords is matter of opinion. But if one dares calling oneself let's say a python programmer, I'd argue that anybody would expect that you'd know the keywords anyways.
braythwayt 6y ago
I don’t think that ‘terseness” is “the problem with Perl,” any more than “Too many parentheses” is the problem with Lisp. APL is a terrific language that is terse. It might not be the right tool for a job where you are constantly recruiting interns to hack on a massive code base, but it’s a fine language for its designed purposes. Which tells me that terseness in-and-of-itself is not a problem. It presents a tradeoff that may not be right for everyone.
kick 6y ago
APL came before Perl, and APL is regarded by many to be one of the best languages overall. I'd recommend reading Iverson's "Notation as a Tool of Thought" for a new perspective. Plenty of people, from Richard Stallman to Alan Perlis, have found great value in APL. Even if just looking at terseness, Chuck Moore, the creator of FORTH, is considered to be one of the best, if not the best, programmers of all time. He credits it all to terseness.
alfiedotwtf 6y ago
Perl is a beautiful language written by a linguist who thought hard about salience. This is why it’s such a shame that other languages don’t have sigils while others prefer ugly hacks like Hungarian notation :smacks forehead:
klibertp 6y ago
I don't think this comment should get downvoted this much - it may sound a bit provocative, but the question is an interesting one, and worth getting answered. > what is this obsession with terse languages It's not an obsession at all. It's a recognition of the fact that there are certain areas where the terseness is helpful, sometimes exceptionally so. It doesn't fit everywhere, and indeed there are domains where it would be downright detrimental. Still, people who prefer compact languages know this and are sure to carefully evaluate the circumstances before choosing APL or Forth. There are "rabid fans" - who would like to rewrite the whole world itself in their beloved language - in every language community, but in my experience, they're scarce among APL, J, or Forth users. > that look like a composition of random characters, Most of the tersest programming languages are meant for interactive, REPL-driven development. In PLs like APL, Forth, J, K, Cat, and now Xs, you are supposed to build your programs as a series of short expressions that you create and evaluate interactively in the interpreter. In such a setting, where you're likely to rewrite and evaluate every expression often, it's faster and more convenient to work with as concise syntax as possible. It's simply a different development mode, and it has its strengths, and - like every other programming model - its weaknesses. > didn't we learn from Perl First, Perl is nowhere near the terseness of APL or J, so I'm not sure what it is you think we should have learned from it. Further, Perl sigils are actually an elegant solution to the problem of type conversions in a dynamically typed language. Take a look at JavaScript and PHP, with all their implicit type-related shenanigans, then come back to Perl - chances are you'll appreciate the sigils quite a lot. The most important thing with APL descendants is that they all have a minimal amount of core operations, which compose incredibly well. Xs is at a very early stage of development, and it will undoubtedly grow, but for now, it has but 5 functions bound to single-character symbols. You can check out the J vocabulary to see a mature, well-developed array language: https://code.jsoftware.com/wiki/NuVoc https://code.jsoftware.com/wiki/NuVoc It might look overwhelming at first, but it's essential to realize that what you see on that page is the entirety of J - there's nothing more to the whole language. It's not English-based, but math notation also isn't, and it's similarly concise. Plus, for a significant portion of the planet's inhabitants, English-based languages are just as foreign as J is to you. To sum it all up: the conciseness of the APL-related languages, which comes from both heavy use of symbols for function names and the tiny amount of core concepts which compose effortlessly, opens the door to a style of programming which fits certain domains and circumstances very well. It may be hard to grasp without first putting some effort and playing with them for a bit... Still, the array and concatenative languages are powerful, and in the right circumstances, can provide an indispensable boost to programmers' productivity.

what is this obsession with terse languages that look like a composition of random characters, didn't we learn from Perl

by cheez 6y ago

what is this obsession with terse languages that look like a composition of random characters, didn't we learn from Perl

rscho 6y ago

Terse languages are a must for single or few-user experiments, e.g. research. Not everyone is implementing a commercial website that needs to be understood by 50 people.

j88439h84 6y ago
I still use good variable names in projects where I'm the only person reading the code. I wouldn't remember what things mean otherwise.
- cheez 6y ago
  Indeed.
- rscho 6y ago
  We have a different definition of terseness.
  - j88439h84 6y ago
    What do you mean?
    - rscho 6y ago
      I mean that programming in a terse language has nothing to do with obscure variable names. The point of terse languages is that knowing the primitives allows you to write concise programs comfortably. It doesn't mean you have to use single letter variables which in opposition to primitives do change between programs.
      - j88439h84 6y ago
        Isn't the way those languages make concise programs by having short symbols instead of descriptive names? Comparing NumPy to APL it looks that way. https://analyzethedatanotthedrivel.org/2018/03/31/numpy-another-iverson-ghost/ https://analyzethedatanotthedrivel.org/2018/03/31/numpy-anot...
        rscho 6y ago
        Well yeah, referring to my above comment the primitives are symbols and it's expected that the user knows them, just as you're supposed to know the keywords in any language. Good (professional) APL though, will intersperse those primitives with meaningful variable names. Whether one thinks it's worth the effort to know the symbols vs know the keywords is matter of opinion. But if one dares calling oneself let's say a python programmer, I'd argue that anybody would expect that you'd know the keywords anyways.

braythwayt 6y ago

I don’t think that ‘terseness” is “the problem with Perl,” any more than “Too many parentheses” is the problem with Lisp. APL is a terrific language that is terse. It might not be the right tool for a job where you are constantly recruiting interns to hack on a massive code base, but it’s a fine language for its designed purposes. Which tells me that terseness in-and-of-itself is not a problem. It presents a tradeoff that may not be right for everyone.

kick 6y ago

APL came before Perl, and APL is regarded by many to be one of the best languages overall. I'd recommend reading Iverson's "Notation as a Tool of Thought" for a new perspective. Plenty of people, from Richard Stallman to Alan Perlis, have found great value in APL. Even if just looking at terseness, Chuck Moore, the creator of FORTH, is considered to be one of the best, if not the best, programmers of all time. He credits it all to terseness.

alfiedotwtf 6y ago

Perl is a beautiful language written by a linguist who thought hard about salience. This is why it’s such a shame that other languages don’t have sigils while others prefer ugly hacks like Hungarian notation :smacks forehead:

klibertp 6y ago

I don't think this comment should get downvoted this much - it may sound a bit provocative, but the question is an interesting one, and worth getting answered. > what is this obsession with terse languages It's not an obsession at all. It's a recognition of the fact that there are certain areas where the terseness is helpful, sometimes exceptionally so. It doesn't fit everywhere, and indeed there are domains where it would be downright detrimental. Still, people who prefer compact languages know this and are sure to carefully evaluate the circumstances before choosing APL or Forth. There are "rabid fans" - who would like to rewrite the whole world itself in their beloved language - in every language community, but in my experience, they're scarce among APL, J, or Forth users. > that look like a composition of random characters, Most of the tersest programming languages are meant for interactive, REPL-driven development. In PLs like APL, Forth, J, K, Cat, and now Xs, you are supposed to build your programs as a series of short expressions that you create and evaluate interactively in the interpreter. In such a setting, where you're likely to rewrite and evaluate every expression often, it's faster and more convenient to work with as concise syntax as possible. It's simply a different development mode, and it has its strengths, and - like every other programming model - its weaknesses. > didn't we learn from Perl First, Perl is nowhere near the terseness of APL or J, so I'm not sure what it is you think we should have learned from it. Further, Perl sigils are actually an elegant solution to the problem of type conversions in a dynamically typed language. Take a look at JavaScript and PHP, with all their implicit type-related shenanigans, then come back to Perl - chances are you'll appreciate the sigils quite a lot. The most important thing with APL descendants is that they all have a minimal amount of core operations, which compose incredibly well. Xs is at a very early stage of development, and it will undoubtedly grow, but for now, it has but 5 functions bound to single-character symbols. You can check out the J vocabulary to see a mature, well-developed array language: https://code.jsoftware.com/wiki/NuVoc https://code.jsoftware.com/wiki/NuVoc It might look overwhelming at first, but it's essential to realize that what you see on that page is the entirety of J - there's nothing more to the whole language. It's not English-based, but math notation also isn't, and it's similarly concise. Plus, for a significant portion of the planet's inhabitants, English-based languages are just as foreign as J is to you. To sum it all up: the conciseness of the APL-related languages, which comes from both heavy use of symbols for function names and the tiny amount of core concepts which compose effortlessly, opens the door to a style of programming which fits certain domains and circumstances very well. It may be hard to grasp without first putting some effort and playing with them for a bit... Still, the array and concatenative languages are powerful, and in the right circumstances, can provide an indispensable boost to programmers' productivity.