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.
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++.
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.
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.
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.
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???)
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).
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.
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.
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.
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.
This function is loosely similar to `print` in the sense it sends a version of its arguments to an output handle (STDOUT by default).
But `say` is emphatically casual and human oriented in stark contrast to the formal and computer oriented `print`. For example, `say` uses human friendly gists of its arguments and truncates arguments that are absurdly long. I think `say` fits perfectly.
hyper
Er, yeah. Reasons. Onward:
race
A race delivers the first of several competing concurrent computations to successfully complete (or the last to fail if none succeed). What would be clearer?
start
`start` starts something that will complete later. Again, what word would you pick?
I agree with kbenson about `my` and `our` and note that those were stolen from Perl 5 because they're considered to be spot on.
See my reply to kbenson for my uneasyness with casualness and human orientation of names. :)
But following my gut feeling for completeness in bikeshedding:
say → Two things irk me, also in other languages. First is the where of writing out. Which is missing here. So I'd always use it as a method of the corresponding handle, here STDOUT. What to name the method? .write would be used for generalized writing (print in Perl6, I think). .writeLine for writing with Newline. And yes, say seem to write a custom representation of the written objects. STDOUT.writeRepresentation would be to long even for me. ;) So .. Stdout.writeRepr(), maybe.
.hyper, .race → If I understand .race correctly after some googling (the Perl6 docs seem to be very sparse), it doesn't returns the result of a race, e.g. a winner or an ordering from winner to loser. Instead it transforms an Iterable into a parallel processing pipeline with custom map/filter/... methods which do their work on parallel workers.
Iterable::inParallel / Iterable::inOrderedParallel would be my compromise.
start → I don't have a Problem with Promise.start but with the corresponding global routine. Start seems so be a too often used concept for different things, most of them custom defined by the user of the language. But I don't know how pervasive usage of promises is in Perl 6, so maybe it is warranted.
`start`ing Promises, `race`ing pipelines, and `say`ing are all frequently used Perl 6 features. So we want nice simple short words for them. I think the ones we've got are well chosen but it's clearly a taste thing. You could always define aliases... :)
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.
> "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?
> 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.
"private" is used in several major programming languages to mark private instance variables. But all instance variables are private in Perl 6 so the keyword is unnecessary. Using it instead for what "my" is used for in Perl 6 would be very confusing.
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.
