And on top of that, the sigils, refs, and `wantarray` systems means that figuring out what syntax you need to invoke something correctly is confusing mental overhead that you have to keep in mind for every function call
Basically the things I learned in perl were the least transferrable concepts of any programming language I've ever worked with. You learn Haskell, or Forth, or Lisp and you learn insights and patterns that you can use in any language. You learn perl, and you've learned nothing but Larry Wall.
$| This variable, if nonzero, will flush the output buffer after every write() or print() function. Normally, it is set to 0.
In other languages, you do something like os.stdout.buffered(true) or sys.stdout = io::buffer(sys.stdout) or something like that where you're combining composable pieces: the standard std variable, a standard way of opening files with or without a buffer, etc. Perl instead has an obscure global variable that you have to look up/memorize, and it doesn't even have a sensible name like $STDOUT_BUFFERING, so readers who come across $| in a file have to look it up/recall from rote memorization, or hope it has a good comment above it.
Only, it's the programmer saying it this time, not the layman. Perl is a 10x engineer.
use IO::Handle;
STDOUT->autoflush(1);
STDERR->autoflush(1);(for those unfamiliar: https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to...)
"There’s more than one way to do it, but sometimes consistency is not a bad thing either."
If hard-to-read-and-remember syntax exists, people WILL use it. And some people will make a POINT to use it, because it makes them feel cool.
Having two totally but pointlessly different syntaxes for the same thing doesn't absolve you from having to learn both syntaxes, because you'll still encounter other people's code that uses both of them -- it just gives you twice as much syntax to learn.
If there's a "sensible alternative", then why does there have to be a "senseless alternative" in the first place?
No-one ever deliberately invents 'senseless' things, we just discover better ways over time. Sure, if we could somehow magically always invent the best way first of all, that would be great. But we can't, so we make the best of what we have, and improve when we can. But there's no need to punish the existing users of older, 'worse' things.
Python has a REPL but you couldn’t dump a Python one liner in your Bash pipeline.
Maybe a LISP might qualify but then you’re back to a language family that is unreadable to many and unknown to most (and I say this as someone who loves LISP)
When talking about the original design of Perl you can’t put it in the same category as Python, Pascal and the C-family of languages. Perl was born from an entirely different problem to solve and that’s why some of it’s historic features seem so alien to people outside of the Perl community.
For this particular case, I'm not sure what drove the selection, but I would guess (since the decision would have been made many decades ago!) it was probably based around perl trying to operate similarly to other command line tools of that era, like awk, sed, (or even ed?), so that people could switch to perl and have a familiar environment? But I don't know, nor have I researched it. In any case, perhaps give the designers the benefit of the doubt before assuming their incompetence?
This leads to serious Perl projects relying on the numerous headers (as described in the very article we are discussing) to ensure everyone applies a more modern coding style.
So you can absolutely stop people from using $|
The point of Perl 7 is to have sane defaults.
You mean like string instrument tab coloured by finger instead of sheet music? Yes, exactly like that.
Restrict scale to pentatonic even for professionals (remove physical keys, holes etc). They would absolutely mess up otherwise.
Yes. Yes I can[1]
[1]: https://how-to-play-electric-guitar.net/tab-symbols.html
The problem isn't merely that notation is easy/hard, but that people will not only pass judgement about a language (or any other idea), they will also work actively to convince others to agree with them, and oh yeah, that programmers are people too.
Are we really?
Yes, of course I can: https://en.wikipedia.org/wiki/Simplified_music_notation and from the linked website "is designed for learners in general".
> "worse, that he/she expects the language to be dumbed down to make it easier to learn."
And why should "simplify" have the connotation "dumbed down, for dumb people"? Everyone benefits from simpler things with fewer warts and fewer hazards.
"If hard-to-read-and-remember syntax exists, people WILL use it"
This statement doesn't appear to hold up under scrutiny.
Not with the sigil names, are they?
Wouldn't be surprised if Perl had a hundred or a thousand times more developers, it used to be popular in the 90 and 2000s. They are still alive today and commenting about it, even though they're probably working professionally in something else.
>This statement doesn't appear to hold up under scrutiny.
What scrutiny? I don't see any scrutiny. You just said that, without scrutinizing.
Just like every human language that ever existed. And last time I checked, programming languages aren't used or written by AI's or aliens.
[0] https://stackoverflow.com/questions/26127617/what-exactly-ar...
In Perl, you learn pretty early that single character non-alphanumeric variables ($|, $_, @_ $@) are special and if you encounter them and don't know them, look them up. You also learn that $1 through $9 and $a and $b have special uses, so don't use those without knowing what you're doing either.
> utterly confounding the first time one accidentally runs into it.
Yeah, but every language has some of those. Who remembers "Unexpected T_PAAMAYIM_NEKUDOTAYIM" in PHP? Or giant template error messages in C++? Or just plain segfaults? All paradigms and the languages within them have their own trade-offs and gotchas, and part of learning the language is learning those.
edit:
BTW if $| is really at risk of clashing with a variable you defined... something else is wrong. :)
Compare that with the shell, where names like IFS can do unimaginable things if you don't know about them and set them by mistake. (Or maliciously; it's imported directly from the environment, and stuff like this is why shell scripts can basically never be given untrusted input, whereas perl, with the 'taint' option, can.)
Reflecting on all this it's pretty sad that newbies in 2020 are encouraged to learn bash, and continue creating arcane, unreadable, booby-trap-laden scripts in it, all the while looking down their nose at perl.
The $ is a sigil, so it appears before variables like $var, so it's just saying | it out. When typed at the beginning of a one liner it becomes quite obvious what you want. This is clearly not a feature for a large project, but a quick UNIX style one off awk-like script.
Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose.
Today I can run Perl code written two decades ago, but with the latest interpreter. I don't think any other interpreted language can do that, can they? (Bourne shell?)
(The first version was released in September 1995, but wasn't JavaScript until Dec 4, 1995.)
My limited experience with Swift suggests that even 25 hours ago could be a tall order...
A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.
Windows NT was released in July, 1993. Almost exactly two years before Windows 95.
In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)
My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.
I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.
Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.
It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.
Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.
I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.
That's not true since v5.10 (2007). Here's a sample that matches a subset of LaTeX markup:
$matcher = qr{
(?&File)
(?(DEFINE)
(?<File> (?&Element)* )
(?<Element> \s* (?&Command)
| \s* (?&Literal)
)
(?<Command> \\ \s* (?&Literal) \s* (?&Options)? \s* (?&Args)? )
(?<Options> \[ \s* (?:(?&Option) (?:\s*,\s* (?&Option) )*)? \s* \])
(?<Args> \{ \s* (?&Element)* \s* \} )
(?<Option> \s* [^][\$&%#_{}~^\s,]+ )
(?<Literal> \s* [^][\$&%#_{}~^\s]+ )
)
}xms
Perl 6 (as lizmat pointed out), has more powerful rules. I don't know a ton about them.
There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).
I only used Ruby briefly over 20 years ago so I can't comment.
I was obsessed with that book one summer and wrote a bunch of parsers after learning incremental techniques (/o I think), and then 8 months later I could no longer remember how anything that I wrote worked. Lol me.
http://web.archive.org/web/20160308115653/http://peope.net/o...
I mean, you can do it, it just lacks elegance. And TBH, I still prefer C for lots of things.
But even though it has a similar powerful set of operations for regular expressions, people mostly don't use it, because there are better ways to deal with text.
That's just badly written libraries that exist in pretty much every ecosystem. By now it seems we have settled that after a couple of args the way to pass multiple arguments is via a hash.
The wantarray feature is a problem with Perl, and not libraries. It has nothing to do with how you pass your arguments, but rather how the data comes back. Every single function has to deal with the potential of context. Every choice you make has downsides. The choices made around wantarray tend to age poorly. And many Perl programmers are deeply confused about the difference between these lines:
my $bar = foo();
my ($baz) = foo();
That you can not really know how it works and still get by in Perl without problems 95% is a testament to Perl trying to make life easier for the programmer, as well as one of the things that contributes most to people not understanding Perl or viewing it as inconsistent and confusing.
That said, I don't really think you can remove it from Perl without making it a drastically different language. Context pervades almost everything, and is how many idiomatic statements actually function (e.g. assigning a hash to another hash is really just list context read from a hash and list context write to a hash).
Perlmonks, in my view, is one of the main reasons Perl community went nowhere. The answer to a question should not be, excuse my french, an exercise in who can swing their dick in the most intricate and convoluted way while accidentally answering the question in the most obfuscated way possible.
class Point {
has $.x;
has $.y;
}
Point.new(x => 42, y => 666);Have you even seen what Javascript is calling OOP? Or the weirdness around "this" keyword? They finally have a "class" keyword, but it's just syntax sugar on top of the weird prototype hashes they have always used.
Lots of languages have weird OOP systems. C++, in particular, if you really want to dive into that. Maybe Java and Ruby are somewhat sane. But I'd prefer not to use either of those, myself.
It is flexible and fun and I do miss it.
True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!
> I don’t really know much about Python. I only stole its object system for Perl 5. I have since repented.
Perl first, then JavaScript.
Did you know JavaScript classes are blessed hashes?
They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
Old JavaScript made the blessing crude and obvious.
Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)
There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.
IMO, that's why both languages have been able to be extended and adapt so much.
If you look at tools like Moo and Moose in Perl and the different coding paradigms that evolved in JS before the "class" keyword was standardized, this is pretty clearly evident.
JS has had the advantage of a standards committee pushing new language features aggressively. Perl has moved more slowly, keeping a majority of functionality in libraries.
> They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").
omg, I totally forgot that (I left day-to-day JS use a good decade ago, sorry!).
I especially like the sigils - they serve in a way as a primitive type system and actually convey useful information when reading code. I suspect people who complain about them are the same who dislike strong typing.
Interestingly, like you, nowadays I am very fond of Scala.
Yes, the memory isolation model of mod_php was the crucial factor in beating the competition. With mod_perl you had to write your Perl modules to a specification so that globals were not accessible by other hosts. That was too much of a risk for shared hosting providers. The situation is muddied, however, in that a lot of shared hosts only allow PHP as a cgi which, in theory, puts it on a level playing-field with Perl. However, in practice, Perl only has one PHP-alike templating framework - HTML::Mason - and that requires mod_perl to perform decently. So PHP's other advantage is that its templating engine is simply faster.
Python 1.2 was released in 1995.
The first public release of Java as 1.0 was in 1996.
JavaScript appeared in 1995 as well, but the first ECMAScript standard didn't appear until 1997.
First release of PHP was in 1995, same with Ruby.
Perl pre-dates the initial release of all those languages and was already up to its fifth major version by that time.
Up to you to decide when you think it started, but I'd say the current language we think of as "Perl" started with the release of Perl 5.
Today, objects are used heavily. And furthermore the way we write those classes has changed a lot since Moose and friends became popular. As a result most Perl code bases written in the last dozen years look less like early Perl 5 than early Perl 5 looked like Perl 4.
Perl 4 and Perl 5 are more of a continuum than different languages.
Depending on how you look at it you are at least a decade too late: we Java folks had the Rhino Javascript engine back in the late 1990ies, and it had an interpreted mode since 1998: https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
I think it is even mentioned in the Javascript in a Nutshell book by David Flanagan (I haven't read it since then but I studied that book as I wrote a map rendering system in Javascript back in school in 2005.)
Node came out in 2009, and writing server-side JS was still a fringe practice for a couple more years, so 2010 is me being generous to avoid comments on the exact timeline ;) It really picked up mainstream adoption around 2011-2012.
I would agree, but I don't think you meant it the same way I would: I prefer nice cold sheets when I sleep, and I much prefer Tcl to Perl!
It died a noble, honorable death. RIP.
How much production software is started from scratch every day using the language?
I started my career in Perl and I still have fond memories of working with it up to late 2000's, but by that time the writing was solidly on the wall.
Dead in this context means "niche".
Edit: Whoops, had operators reversed because I explained them after the fact. Fixed!
An operation may be evaluated in list or scalar context. For example, if you evaluate an array in list context, you get the members of the array, however, in scalar context, you get the number of elements in the array.
This idea is generalized to discuss different evaluation contexts for scalars. You might hear people discussing how a value behaves in boolean or string context. It's also common to talk about casting as "-ification", for example casting something to boolean context is "boolification".
By default, undefined values convert to empty string and 0. However, this can be made to generate a warning or even a fatal exception by setting the appropriate pragmas.
I've found this greatly increases reliability.
An example is that I enabled those on the W3C checkers and a serious latent bug was discovered and fixed, even on code I wasn't familiar with.