chromatic

Did you read a book or tutorial which explained the two types of context (value and type) in Perl, the topic variable, or operator monomorphism?

They've heard that JavaScript has first-class functions, which they've heard of. They've also heard that JavaScript is like Scheme, which they've also heard of.

My collection of Programming Books Which I Will Discard Before I Ever Move Them Again includes a book about CGI programming with the Korn shell. I am not making this up.

As you well know, back in the day when CGI was magic and server-side includes were amazing, there weren't a lot of options for server side programming. You had C, if you were a Unixy systems programmer and didn't mind doing string processing in C. You had Tcl, if you wanted to go the AOLserver route. You had whatever shell script you wanted, if you wanted to pipe and stream together Unixy commands. After a time, you even had server-side JavaScript, if you spent a lot of money on Netscape server products.

You also had Perl, which ran on just about every Unix under the sun and behaved the same way pretty much everywhere. Even if you couldn't rely on one Unix utility behaving the same on every Unix variant (unless you somehow managed to get the GNU tools installed), you could rely on Perl being just about everywhere. Better yet, it had a fair library of code being developed and published because people were sharing it.

In the early days, you might have to use a Perl fork to connect to an Oracle or a Sybase installation, but you even had that option. (Yeah, you could do that in C too, but that would be borrowing pain far beyond string handling in C.)

It's pretty easy to see why Perl ended up with a lot of that market. It fit that niche which hadn't previously existed, and there wasn't much competition. (Korn shell. Korn. Shell.)

The market expanded rapidly. Then the competition expanded rapidly because the market expanded rapidly. It's innumerate to suggest that the relative position of market share will remain the same or even grow when the market grows so rapidly and so much competition appears.

Hopefully not in strength of module system, automated testing, extension mechanisms that aren't monkeypatching, quality of core development practices, metaprogramming (if you count Moose or p5-MOP), documentation, lexical scoping, or Unicode support.

It's full of SQL injections, to start. (I really like using the subdomain name from the HTTP_HOST environment variable in a SQL query. That's a new attack vector I hadn't considered.)

It's full of silly inefficiencies, such as iterating over an array and preparing distinct but trivially parametric queries for each element.

It has a strange mix of effectively package global lexical variables and block-scoped lexical variables, which means that running this in any sort of persistent service model would be very buggy.

It looks like it ignores parts of the CGI standard.

It looks like it takes database connection information from cookies (except it never uses that code).

The `find_node` function looks like it's using the wrong data structure entirely, but that's okay, because that pattern's repeated a few times. That's doubly suspect, because this seems like the sort of thing a WHERE clause in the SQL query could handle (though to be fair, it might require a subquery, and the version of Mysql Facebook had deployed in 2005 might not have supported those very well; I don't remember).

http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5....

More like "an alternate mortgage registry that has allowed entities to initiate foreclosures even if they don't hold the mortgages".

http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...

After all, much of programming culture is stuck on the idea that the clarity of syntax of a programming languages to novices is more important to maintainability of programs written in that language than domain knowledge, for example.

If you're referring to Fred Brooks, he wrote "[T]here is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity." (emphasis mine)

The surrounding context makes his comment a very specific prediction which means something different from what most people claim he meant. Much of the rest of his essay suggests techniques which address the issue of essential complexity and which, when applied together, he hoped would produce that order of magnitude productivity.

Perhaps there was no single such improvement in the years 1986 to 1996, but when people use the phrase "no silver bullet" to dismiss potential improvements in productivity, I believe they're doing Brooks and the rest of us a great disservice.

http://www.modernperlbooks.com/mt/2013/02/goodnight-parrot.h...

You are probably thinking of Ruby. Wait, Haskell. Hold up, Erlang. Sorry, Node.js.

Parrot started in 2001, and there was at least one P6 implementation in the works shortly after:

https://github.com/parrot/parrot/commit/9bb281bf85088000ee40...

The Parrot backend was used to nail down the object system.

That's not how I remember things. Jonathan may have implemented the current object system on Parrot, but then he prototyped one on the CLR and one on the JVM (or vice versa), then wrote one for Rakudo based on that.

Concurrently, they are developing their own VM to get rid of the semantic mismatch between the language runtime and backend VM.

That's a very charitable interpretation of what they're doing.

No, it doesn't. Anyone who told you so was fibbing. Perl's design allows you to add your own keywords to the language in such a way that the parser knows their arity and any contextual coercions--in other words, as if they were operators defined in the parser itself. This is rare (it doesn't happen often) and it's almost never ambiguous, but because the language used to define these custom keywords is Turing complete, it's possible to create pathological cases which depend on random factors to define a keyword in one of multiple ways...

... but no one ever does that except to prove that it's possible.

It should seem bizarre, because no one ever argues that.

I think the perl community works incredibly hard at writing lots of CPAN modules to try and correct for perl's defects.

The module of greatest use to me today allows me to iterate through cells in a spreadsheet. Is it really a defect in a language that something like Spreadsheet::Parse Excel or Apache POI exists?

Perl uses sigils for two reasons. First, to provide a separate namespace for variables and language keywords. Second, to allow amount contexts.

Reasonable people will disagree about the value of both of those reasons, but those are the reasons why sigils exist in Perl.

Seems doubtful to me. With yearly releases and a two year support cycle, only the enterprisey distribution nonsense is still infected with that particular brokenness.

Perl claims to have a compilation stage, by which the documentation means that the lexer and parser produce an optree, which the runtime phase traverses. During that compilation stage, it's possible to run code which changes how the parser will treat subsequent syntactic elements.

Sure you can! The cost of switching languages may outweigh the expected value of the extra features, especially if they're only marginally more useful or not useful at all.

* ... the benefits of a good and clean Smalltak-flavored object system like Ruby's.*

I'm unconvinced. Ruby's hacky metaprogramming is hacky because you just don't get the Smalltalk browser without an image-based environment. You can make huge messes in Smalltalk if you monkeypatch hither and yon, but you also get better tools to help avoid the situation and to extricate yourself from it.

I don't understand this. If this hurts you, wouldn't you have the same problem with domain knowledge, except an order of magnitude worse? Why are your developers not talking to each other?

To my mind, that's a success for Perl: it allows people who wouldn't otherwise be able to write programs to do so. Sure, they make messes--who doesn't at first?--but they get things done.

Moose did take inspiration from the object model designed for Perl 6, but it grew out of attempts to implement that object model in Pugs, not Rakudo. You might even say that it was the first full implementation of the Perl 6 object model.

Do you mean Moose or the abandoned Perl 5 MOP experiment?