5 ms·

I used to really like Perl, but endless operator-obfuscation nonsense a la C++, Perl 6, Scala REALLY makes me appreciate Lisp (should I ever get to use it again

I used to really like Perl, but endless operator-obfuscation nonsense a la C++, Perl 6, Scala REALLY makes me appreciate Lisp (should I ever get to use it again outside of 80s college work). Every function has a plain old name, no magic symbol operators, inner parens evaluate first. No bullshit.

ktRolster 11y ago
It's kind of amazing to me, after learning all kinds of abstractions and syntaxes, how much I just come back to the function to organize my code. And over and over, that seems like the most flexible and powerful way to do that.
- Roboprog 11y ago
  That does work really well for me in my Javascript code. Java is getting increasingly painful to look at (even without operator overloading), and most of our work is still Java (due to the need to write so much of it???)
mjn 11y ago
I go back and forth on that. I like both Perl 5 and Common Lisp, and am investigating Perl 6 now. Perl has more operator magic, but it also makes many things a lot less tedious to write, and for common tasks I quickly figure out a nice way of doing things. Common Lisp is more uniform but somewhat clunky and verbose for a lot of common things. And when it's not, it's because you created a nice little DSL using macros (maybe even read macros), which then starts looking more like Perl-style magic (except done with metaprogramming, not built in). As far as heritage, I think Perl's love of magic and concise operators is influenced more by the awk/sed/sh trio that it originally borrowed a lot of its syntax from, rather than by C++.
- deleted 11y ago
  [deleted]
zvrba 11y ago
> endless operator-obfuscation nonsense a la C++ C++? Ever looked at some "advanced" Haskell code?
- maemre 11y ago
  I don't know why you got downvoted but Haskell also gives excessive freedom for infix operators with adjustable precedence, ability to make up new operators etc. and a lot of libraries use such operators excessively so I think you are right. Come to think of whenever I need to write a PEG or use a not-so-common typeclass I need to open documentation to see what juxtaposition of ascii characters to use where. On the other hand, I think the expressibility outweighs the cognitive overhead in case of infix operators, especially when using relatively common operators (Scala kind-of has a similar feature and I (ab)use it frequently and it is nicer and closer to math when combined with Unicode. Closeness to math is an important feat. when translating academic papers into code or vice versa).
  - Roboprog 11y ago
    The funny thing is I have seen many more damaging errors caused by operator precedence / grouping, which continue running and doing the wrong thing, than by type mismatch errors, which blow up and stop.
- yyhhsj0521 11y ago
  The problem with the code you talk about is that they use libraries that are intended to create a new DSL, instead of fuse into the language itself. Apart from that, there isn't really much problem with Haskell's operators. There are only few in standard library addressing applicative and monad, and the de facto standard Lens library.
- Roboprog 11y ago
  Nope. But thanks for the warning.
Montezuma123 11y ago
Damian Conway (Perl5 frequent contributor) is a professor who knows and has taught Lisp classes. He made a good point that although Lisp is powerful in it's own way, you don't get a lot of information by simply glancing at some code. With sigils and other known operators, Perl gives the reader a lot of information as long as it isn't abused.
- zaphar 11y ago
  This is a great point that often get's ignored or glossed over. Perl code is information dense which makes it look messy to someone who doesn't know what each of the sigils and syntax elements mean. What this means is that perl has a longer learning curve but once you get over the hump you know a lot more about what the code is doing in a glance than you do for other languages. So it's not more readable to the new guy but it can be more readably to the ones who put in the effort to get up to speed.
lmm 11y ago
I do wish Scala libraries would stop using symbolic operators, but I do think they're less bad there than the other places: symbolic names are just ordinary method names (no magic desugaring), and make no difference except for a short precedence list.
ttepasse 11y ago
Related: While flipping through the slides I was annoyed how many of Perl's plain old names aren't really exact name but more casual description. .say, .hyper, .race, start for Promises in this slides. Even the keywords my, our, has annoy me a little bit. Not to forget strange jargon like bless. Yes, at the end they all are token and one has to learn them. But I miss more exact words for some value of exact. Going a little bit into the ObjC school of naming would do Perl some good.
- kbenson 11y ago
  So, what exactly are the "exact words for some value of exact" that you would prefer? Extern? local? Keep in mind that there's a duality between my and our which is obvious and part of the words themselves, so they don't need as much memorization. "my" is private, and local, "our" is shared, and not local. I'm not super happy about some of the other words chosen (start, race, etc), but I think my/our has a nice symmetry to it.
  - ttepasse 11y ago
    > "my" is private, and local, "our" is shared, and not local. Which begs my question: If you already have more exact words (”private“, ”shared“) for these concept, why not use them? Yes, ”my“ and “our” have these connotation too, but it works only for humans and their relations. I guess that's my disquiet with some of these names: Perl mixes the realms of machines and humans. See also `bless` and `say`. And the anthropomorphization of abstract concepts only creates a slightly uncanny valley in my mind. Maybe because english isn't my mother tongue. Perhaps native speaker is more ok with this mixture of concepts?
    - kbenson 11y ago
      > Which begs my question: If you already have more exact words (”private“, ”shared“) for these concept, why not use them? Yes, ”my“ and “our” have these connotation too, but it works only for humans and their relations. It works on items to denote their relationship to people. That Perl expects the code to be written by a person and uses terms people are used to for dealing with ownership doesn't seem weird to me. That you see it as weird and other words as more appropriate I think is more likely related to what words you learned first for those concepts. I don't see them as inherently superior in any way. > I guess that's my disquiet with some of these names: Perl mixes the realms of machines and humans. Given that it's creator is a linguist, and there's some very specific things that were attempted, your feeling that it's taking terms you associate with relation and using them somewhere else is probably purposeful. Perl was designed with some very specific ideas, and one of them was to make it usable in a way more like a natural language. > And the anthropomorphization of abstract concepts only creates a slightly uncanny valley in my mind. I think you're stretching your analogy too far to make a point. My and our denote ownership of an item. It's used in Perl to denote something very similar, as the core concepts are the same, responsibility and access. > Maybe because english isn't my mother tongue. Perhaps native speaker is more ok with this mixture of concepts? Possibly. I'm a native speaker and the concepts aren't mixed in my mind.
CuriouslyC 11y ago
The biggest problem with lisp as I see it is that the code is typically not read in the order that it is evaluated. This results in significant cognitive overhead when reading code. Additionally, while there is a definite elegance to its simplicity, most people have built up fairly good understanding of a number of glyphs. Using some of the additional glyphs to make the code more visually distinctive would definitely improve code reading speed. Ultimately it seems like operator overloading is something that should be possible, but made intentionally difficult to discourage abuse.
- Roboprog 11y ago
  Lisp doesn't prevent you from sequentially assigning expressions to symbols, rather than "infinitely" nesting stuff. I suppose what you said is an "occupational hazard", but not an unavoidable problem.

ktRolster 11y ago

It's kind of amazing to me, after learning all kinds of abstractions and syntaxes, how much I just come back to the function to organize my code. And over and over, that seems like the most flexible and powerful way to do that.

Roboprog 11y ago
That does work really well for me in my Javascript code. Java is getting increasingly painful to look at (even without operator overloading), and most of our work is still Java (due to the need to write so much of it???)

mjn 11y ago

I go back and forth on that. I like both Perl 5 and Common Lisp, and am investigating Perl 6 now. Perl has more operator magic, but it also makes many things a lot less tedious to write, and for common tasks I quickly figure out a nice way of doing things. Common Lisp is more uniform but somewhat clunky and verbose for a lot of common things. And when it's not, it's because you created a nice little DSL using macros (maybe even read macros), which then starts looking more like Perl-style magic (except done with metaprogramming, not built in). As far as heritage, I think Perl's love of magic and concise operators is influenced more by the awk/sed/sh trio that it originally borrowed a lot of its syntax from, rather than by C++.

deleted 11y ago
[deleted]

zvrba 11y ago

> endless operator-obfuscation nonsense a la C++ C++? Ever looked at some "advanced" Haskell code?

maemre 11y ago
I don't know why you got downvoted but Haskell also gives excessive freedom for infix operators with adjustable precedence, ability to make up new operators etc. and a lot of libraries use such operators excessively so I think you are right. Come to think of whenever I need to write a PEG or use a not-so-common typeclass I need to open documentation to see what juxtaposition of ascii characters to use where. On the other hand, I think the expressibility outweighs the cognitive overhead in case of infix operators, especially when using relatively common operators (Scala kind-of has a similar feature and I (ab)use it frequently and it is nicer and closer to math when combined with Unicode. Closeness to math is an important feat. when translating academic papers into code or vice versa).
- Roboprog 11y ago
  The funny thing is I have seen many more damaging errors caused by operator precedence / grouping, which continue running and doing the wrong thing, than by type mismatch errors, which blow up and stop.
yyhhsj0521 11y ago
The problem with the code you talk about is that they use libraries that are intended to create a new DSL, instead of fuse into the language itself. Apart from that, there isn't really much problem with Haskell's operators. There are only few in standard library addressing applicative and monad, and the de facto standard Lens library.
Roboprog 11y ago
Nope. But thanks for the warning.

Montezuma123 11y ago

Damian Conway (Perl5 frequent contributor) is a professor who knows and has taught Lisp classes. He made a good point that although Lisp is powerful in it's own way, you don't get a lot of information by simply glancing at some code. With sigils and other known operators, Perl gives the reader a lot of information as long as it isn't abused.

zaphar 11y ago
This is a great point that often get's ignored or glossed over. Perl code is information dense which makes it look messy to someone who doesn't know what each of the sigils and syntax elements mean. What this means is that perl has a longer learning curve but once you get over the hump you know a lot more about what the code is doing in a glance than you do for other languages. So it's not more readable to the new guy but it can be more readably to the ones who put in the effort to get up to speed.

lmm 11y ago

I do wish Scala libraries would stop using symbolic operators, but I do think they're less bad there than the other places: symbolic names are just ordinary method names (no magic desugaring), and make no difference except for a short precedence list.

ttepasse 11y ago

Related: While flipping through the slides I was annoyed how many of Perl's plain old names aren't really exact name but more casual description. .say, .hyper, .race, start for Promises in this slides. Even the keywords my, our, has annoy me a little bit. Not to forget strange jargon like bless. Yes, at the end they all are token and one has to learn them. But I miss more exact words for some value of exact. Going a little bit into the ObjC school of naming would do Perl some good.

kbenson 11y ago
So, what exactly are the "exact words for some value of exact" that you would prefer? Extern? local? Keep in mind that there's a duality between my and our which is obvious and part of the words themselves, so they don't need as much memorization. "my" is private, and local, "our" is shared, and not local. I'm not super happy about some of the other words chosen (start, race, etc), but I think my/our has a nice symmetry to it.
- ttepasse 11y ago
  > "my" is private, and local, "our" is shared, and not local. Which begs my question: If you already have more exact words (”private“, ”shared“) for these concept, why not use them? Yes, ”my“ and “our” have these connotation too, but it works only for humans and their relations. I guess that's my disquiet with some of these names: Perl mixes the realms of machines and humans. See also `bless` and `say`. And the anthropomorphization of abstract concepts only creates a slightly uncanny valley in my mind. Maybe because english isn't my mother tongue. Perhaps native speaker is more ok with this mixture of concepts?
  - kbenson 11y ago
    > Which begs my question: If you already have more exact words (”private“, ”shared“) for these concept, why not use them? Yes, ”my“ and “our” have these connotation too, but it works only for humans and their relations. It works on items to denote their relationship to people. That Perl expects the code to be written by a person and uses terms people are used to for dealing with ownership doesn't seem weird to me. That you see it as weird and other words as more appropriate I think is more likely related to what words you learned first for those concepts. I don't see them as inherently superior in any way. > I guess that's my disquiet with some of these names: Perl mixes the realms of machines and humans. Given that it's creator is a linguist, and there's some very specific things that were attempted, your feeling that it's taking terms you associate with relation and using them somewhere else is probably purposeful. Perl was designed with some very specific ideas, and one of them was to make it usable in a way more like a natural language. > And the anthropomorphization of abstract concepts only creates a slightly uncanny valley in my mind. I think you're stretching your analogy too far to make a point. My and our denote ownership of an item. It's used in Perl to denote something very similar, as the core concepts are the same, responsibility and access. > Maybe because english isn't my mother tongue. Perhaps native speaker is more ok with this mixture of concepts? Possibly. I'm a native speaker and the concepts aren't mixed in my mind.

CuriouslyC 11y ago

The biggest problem with lisp as I see it is that the code is typically not read in the order that it is evaluated. This results in significant cognitive overhead when reading code. Additionally, while there is a definite elegance to its simplicity, most people have built up fairly good understanding of a number of glyphs. Using some of the additional glyphs to make the code more visually distinctive would definitely improve code reading speed. Ultimately it seems like operator overloading is something that should be possible, but made intentionally difficult to discourage abuse.

Roboprog 11y ago
Lisp doesn't prevent you from sequentially assigning expressions to symbols, rather than "infinitely" nesting stuff. I suppose what you said is an "occupational hazard", but not an unavoidable problem.