Yeah, the freeze killed momentum and left the community to wither. Python's transition was much better but is still not quite complete, and consumed a lot of time and effort.

Making a backwards-incompatible change to a programming language == making and launching a new language, with all its difficulties.

If Python's transition actually was much better, that says quite a bit about how awful the Perl transition is gonna be - since the Python 2->3 transition seems pretty widely acknowledged to be a disaster.

There is not and will not be a transition. It is a completely new and different language.

Which is exactly what Python should have done. Call Python3 a new language and not try to kill/degrade Python2 but have both live on... which they will anyway regardless.

Is it so crazy though? With frameworks like Mojolicious and Dancer, you can set up a whole website using syntax familiar to someone coming from Sinatra on Ruby or Express on NodeJS.

There was discussion about it yesterday: https://news.ycombinator.com/item?id=10331008

I've spent a year now using Perl exclusively at my job, and I love it. It's incredibly powerful, expressive, concise, and well-documented. It's a lot like js where the language has some cruft but as long as you're not working with any cowboys you can build some really elegant software.

> Also the language is crazy to write substantial programs in!

I would not want to write anything big in Perl 5. But for small-ish scripts (say, less than a thousand lines) it is pretty hard to beat.

Perl is awesome for writing big programs in. One of the things that people find frustrating about Perl is its expressiveness -- that is, there are many different ways of doing the same thing. The result is sometimes that you get 100 different people doing things 100 different ways.

This is not so much a problem with the language as it is with programmers not learning to agree on a set of idioms that they will use for a project. They are not reading each others code and having discussions about what they want to see.

Languages that impose "the one true way" cut down on the apparent problems, but you are still going to have massive issues down the road if you build large projects because nobody is paying attention to what the other people are doing. Especially on large projects, it is vital that people read and comment usefully about design issues. In such large projects, removing the choice of idioms available though language design is a bit like deciding not to carry a canary down the mine with you because it keeps getting killed by poisonous gas.

The expressiveness of Perl allows you to choose the idioms that will work best for your team/project. It is true that it requires more discipline and communication, but these are the things that are necessary for success on a big project anyway.

I haven't written any Perl code for years now, but I have always been fond of it. I find that I can write better code in Perl than in many of the more restrictive languages that I've used.

Then you might be pleasantly surprised to learn that Perl 6 has a type system and compile time errors functions (but methods are runtime errors - on purpose).

As for missing hash keys... It sounds like you are using a hash when you really want an object. There are cases where that's preferable, but part of that trade-off is that you need to make sure the data is as you expect it. Perl 6 supports tightly packed (C struct equivalent) objects if you choose.

Compile time checks are not a replacement for a good test suite.

And a good test suite is no replacement for being able to express invariants in your code. They are complementary tools.

Who said they were?

You don't write a lot of tests, do you?

"I wouldn't write anything big in <insert language>" is pretty much always a true statement. What changes it is the framework.

I can write a web application in some homebrew <insert language> and it can grow to 40 developers, 1000 db tables and thousands of files. But it would be terrible to work on (I know I've seen it). Or i can write the same thing with a framework, and have it much more manageable.

Realistically, when was the last time you say down and wrote a big application in vanilla <insert language>?

Don't worry, within 24 hours there will be hundreds of comments all explaining how Perl 6 is of no interest to anyone.

The companies I know using Perl are generally not so conservative - many of them also have Go code bases, heavy focus on DevOps, and so on. They tend to keep using Perl because they have developers who love programming in Perl...