Perl 7 Announced As Evolving Perl 5 With Modern Defaults

[boxie]

I'm still an avid Perl user but trying to move on to Ruby. I still love using Perl but no one where I work seems to take a script seriously unless it's written in !Perl. I don't think it deserves a lot of the flack it gets but it surely deserves some of it... Raku addresses some of this but in reality the servers at work have Ruby or Python 2. Even if they had Python 3 frankly I'd lean towards Ruby but that's only because I fall into the "mandatory whitespace is malarky" camp

2 points on whitespace:

1. If your editor doesn't take care of that for you, get a better editor
2. Indent you code your horrible horrible developer - future you will thank you :P

I feel Ruby is Perl without the stupid. Ruby code can be "too expressive" which leads to code that is not easy to reason about, and therefore maintain. while some of this is discouraged, there is still a lot of developers that try and be "clever" with their golfing.

[Raka555]

After actually reading the Perl announcement, my personal opinion is that this will be the final nail in Perl's coffin...

They cite the following users of Perl:

• People who are never going to change their code
• People who use new features
• People starting from scratch

The problem is there will be no "People starting from scratch" because of all the bad press.
It also seems to be too hard to learn for the new generation.

That leaves only the other 2 categories.
So now they are going to break most existing scripts/modules in favor of new features. (I know they promise and claim otherwise)

This will just piss off current Perl users and instead of fixing the old scripts, they will rewrite it in something "new" and close the chapters on Perl...

RIP Perl. We had a lovely romance ...

[pgoetz]

unlike languages like Python, PHP, Ruby, Javascript, shell scripting, etc, you can't just read Perl and get the gist of how to work with it. You really have to go out of your way to understand it.

If you don't know Perl, you won't be able to read Perl code, this is true. One might argue that you probably shouldn't be trying to modify code written in a language you don't actually understand. If you know Perl and still can't read the code, that's not on Perl, that's on the shitty programmer who wrote the code. Perl is extremely flexible and allows you to write poorly formatted, obfuscated code. That doesn't mean you should do so. You can make Perl code just as readable and elegant as code written in any other language.

[pgoetz]

I absolutely despise any language that depends on indenting like basic and Python.

Not only that, Python is not very well designed:

https://www.quora.com/What-are-the-main-weaknesses-of-Python-as-a-programming-language

https://medium.com/@the1mills/fuck-python-4fa122e03e30

https://www.quora.com/What-are-the-p...mming-Language
https://www.quora.com/Why-is-the-whi...rd-Kenneth-Eng

[pgoetz]

I find C and Java easier to read than Perl and they sure as hell are more powerful.

You do realize there's a yearly competition for writing the most obfuscated C code? It's possible to make C just as, if not way more unreadable than badly written Perl. And I'd rather shoot myself in the head than to have to read another paragraph, er line, of Java code.

Do you blame them? Most languages you can learn without a book. I learned how to write programs in python, PHP, and Javascript without spending more than 5 minutes on tutorials, and I was paid using all 3.

The Camel book does more than teach you how to program Perl, it's a treatise on how to think about programming in general. The Camel book is still hands down the best programming book I've ever read, and I've read quite a few. If you were able to write programs in languages after spending less than 5 minutes on tutorials, then either you're talking about a language whose syntax is very similar to another language you've already spent extensive time with, or you're writing mickey mouse programs. Anyone who knows anything about programming knows that all those "Learn C++ in 20 Days!" books are complete bullshit. Yes, you can learn some syntax in 20 days, but it takes at least months, generally years of practice to become proficient in a language that's sufficiently expressive to allow for the solution of complex tasks.

In particular, you did not learn how to program in javascript after spending 5 minutes on a tutorial. Just saying that tells me you don't know javascript and are bullshitting. Just understanding how "this" works takes more than 5 minutes.

All you're really telling us is you're not interested in spending the time to learn Perl, which is fine, but don't extrapolate your ignorance into a criticism of the language itself.

[swagg_boi]

2 points on whitespace:

1. If your editor doesn't take care of that for you, get a better editor
2. Indent you code your horrible horrible developer - future you will thank you :P

My editor takes care of whitespace and I do indent my code. I just don't like it being mandatory; for example with one-liners it's nice to be able to do a whole "block" of code as one line. Perl gives you the flexibility to choose. Ruby seems to allow some shenanigans as well:

coats = ['black', 'tabby', 'orange']

coats.each { |kitty| puts kitty.capitalize }

# or

coats.each do |kitty|
  puts kitty.capitalize
end

[boxie]

My editor takes care of whitespace and I do indent my code. I just don't like it being mandatory; for example with one-liners it's nice to be able to do a whole "block" of code as one line. Perl gives you the flexibility to choose. Ruby seems to allow some shenanigans as well:

coats = ['black', 'tabby', 'orange']

coats.each { |kitty| puts kitty.capitalize }

# or

coats.each do |kitty|
puts kitty.capitalize
end

... and you are not even trying to get into one liner shenanigans there

I have no problem if the language forces you to one statement per line, it generally leads to more maintainable code (IMHO)

[ssokolow]

Not only that, Python is not very well designed:

https://www.quora.com/What-are-the-m...mming-language

https://medium.com/@the1mills/fuck-python-4fa122e03e30

https://www.quora.com/What-are-the-p...mming-Language
https://www.quora.com/Why-is-the-whi...rd-Kenneth-Eng

Your choice of links doesn't fill me with confidence that the people who posted them know what they're talking about. Since I've got a half hour to kill and feel like some mindless entertainment, here's what's wrong with them:

• "Much of the language consists of special cases rather than general features that combine in orthogonal ways. This results in infelicities and weird corner cases." (Gives no citations or specific examples and at odds with my own experience. What can be asserted without evidence can be dismissed without evidence.)
• "Guido van Rossum has a history of getting the language design really wrong (e.g.,"
  
  First, he's actually blogged about the amount of actual empirical research that went into things like colons beginning block statements. Second, attacking this rationale is rich when it's the viewpoint shared by the developers of pretty much every language that isn't Haskell or some other language which needs guaranteed tail recursion optimization to be useful.
  
  Here's an excerpt from his rationale: "Once tail recursion elimination exists, developers will start writing code that depends on it, and their code won't run on implementations that don't provide it"
• "Python has perpetual scope confusion. As far as I can tell, this is because van Rossum didn't understand lexical scope initially, so he got it wrong. (This isn't a problem unique to Python. It seems pretty common among early versions of scripting languages.) Originally, Python was dynamically scoped, which everyone but RMS agrees is wrong."
  
  OK, I'll admit it's inconvenient to have to hack around the fact that, without a keyword like var or let, assigning to a variable in a lower stack frame shadows the one in the higher stack frame, but that's not really lexical vs. dynamic scope. In fact, while I'm having trouble googling it up again and don't feel like walking back through each Python changelog, I remember reading that, back in the 1.x or 2.x series, Python announced a switch opposite to what the poster thinks happened, from lexical to dynamic.
  
  The standard rule of thumb for lexical vs. dynamic scope is that, if you can declare two functions side-by-side, where one calls the other, and then have the lower stack frame read variables from the higher stack frame, then you're dynamically scoped. If you can't, you're lexically scoped. You can definitely read variables from higher frames in Python... as bad an idea for maintainability as it is... you just can't assign to variable bindings in higher scopes due to a quirk of Python's syntax that makes it ambiguous whether you want to assign or shadow.
  
  To quote Wikipedia's "Scope (computer science)" article:
  

  With lexical scope, a name always refers to its (more or less) local lexical environment. This is a property of the program text and is made independent of the runtime call stack by the language implementation.

• "eval breaks alpha-equivalence — that is, you can't arbitrarily change the names of variables, because some variable occurrences can hide in strings, which makes the binding structure of Python undecidable."
  
  It doesn't speak well for them that they're attacking Python for something that pretty much every scripting language has, but don't acknowledge that ubiquity in their phrasing.
• "Python is untyped, which means that a whole bunch of errors that are easily detected ahead of time aren't detected in Python until they happen. Some people like it that way — and more power to them! — but it's always worth considering whether it's a misfeature for your particular application"
  
  Better than talking about eval, since it doesn't feel like they're implicitly shaming Python for having that design feature, but Python isn't "untyped" unless you're a programming language theorist. (That's what they call dynamically-typed languages, since the types aren't decidable at compile time) Python disallows things like my_int + my_string without explicit conversions, unlike languages like PHP, Perl, and assembly languages, where the operators are typed rather than the data.
• "Syntactic whitespace can be nice, but it makes code generation harder than it has to be."
  
  A fair point.
• "Limiting the bodies of lambdas to be expressions rather than statements is arbitrary and annoying."
  
  Also a fair point... though only arbitrary in the sense that it's intended to be consistent with Python's lack of an alternative to syntactic whitespace.
• "Python, like the other table-based languages, encourages you to use "mappings" for many things where sum-of-products (algebraic) datatypes would be more appropriate."
  
  Also a fair point, and I like that they recognize how common this flaw is.
• "All that said, I'd still rather work with Python than PHP. But that's like saying I'd rather eat Jack in the Box than McDonald's. It might be slightly more palatable, but it's still pretty bad."
  
  Yeah, I get the impression this person probably programs in Haskell or some other strongly typed functional language for leisure, and, if they haven't been able to find a job in that, something like Java, C#, or C++ for work.

Next person:

• "Scoping — having to use nonlocal to scope closures. JavaScript does not have this problem, JS is nice and smooth in this regard, scope is “linear”."
  
  See my previous comment about Python's problem being the lack of a var/let keyword to distinguish child-scope reassignment from shadowing. Also, nonlocal is a Python 3.x thing and I question the sanity of designing closures which require the ability to write into parent scope in which they were defined. (You don't need nonlocal for reading from such scopes. A simple foo=foo in the closure's arguments has sufficed since I started with Python 2.3 and looks more like the capture lists languages like PHP use.)
• "Variables don’t get declared, it’s hard to tell when a variable was initialized or reinitialized/overwritten."
  
  A fair point but Python isn't the only language with "first assignment is declaration" semantics, so you can only call it out by comparison to a language you like more... as this coder is doing with JavaScript.
• "Python version 2 or 3, which to use?"
  
  In 2018? That's like asking whether to use Windows XP or Windows 10 in the months leading up to the final termination of extended security updates for Windows XP.
• "the GIL — the Global Interpreter Lock — JavaScript avoids this problem by being “single-threaded”"
  
  This has a "not even wrong" feel to it. It's like saying "I can't crash my car because it has no steering wheel". At least Python's Threading+GIL situation has preemptive multitasking, not cooperative multitasking like Windows 3.1 and classic MacOS.
• "JavaScript/V8 runs faster than Python, around 5–10x, Python is one of the slowest languages around."
  
  First, you're usually gluing together compiled modules written in C when you write Python. Second, of course that's the case when CPython has no JIT and V8 has had insane amounts of time and money thrown at it. Third, PyPy is about 4x as fast as CPython. Fourth, if you're really pointing fingers, JavaScript isn't exactly fast in the grand scheme of things either, compared to Ahead-of-Time compiled languages which allow explicitly specifying cache-friendly memory layouts. Use rust-cpython or neon for your CPU-bound bits and call it a day.
• "fuck every single programming language that utilizes whitespace for syntax" (Again, what can be asserted without evidence can be dismissed without evidence.)
• "Object Orientation was tacked on — passing ‘self’ to methods? wtf. it’s actually not that bad from a developer perspective, but I assume performance is bad since all the methods need to bound to each instance, every time an instance of a class is created?"
  
  This person clearly knows nothing about how programming languages work under the hood when they assume it must have a performance penalty (heck, it can be resolved at parse time), and Python is hardly the only language that chose not to have a magic name for the instance reference. I could just as easily dismiss C++ and JavaScript because I hate Pascal's magic return value variable name.
• "Python is dynamically typed — that’s a major downside for most real applications. Obviously a problem that JS has as well, that only TypeScript can fix."
  
  Aside from being a complaint against an entire class of programming languages, this person is clearly underselling the amount of effort the ecosystem is putting into gradual typing. Just on the checkers alone, I believe both MyPy and Pyre (Facebook) already existed in 2018, and we've now got pytype (Google) and pyright (Microsoft) too.
• "No support for multi-line anonymous functions."
  
  A fair complaint, though a dangerous tool to want, given some of the code I've seen out there.
• "Python error stack traces — they are horrible, I don’t think it’s a matter of getting used to — they are just really painstaking to sift through."
  
  I'd need more information. They don't look particularly bad to me, compared to other languages I've seen.

Next:

• "Also, the slightest accidental misalignment of code can cause an obscure and difficult-to-find bug. Hey, accidents do happen."
  
  This, I'll agree with as a reasonable complaint. That's why the world seems to be going in the direction of punctuation-based scope and automatic formatting, as with languages like Go and Rust.
• "Another thing is the peculiar scoping rules (solved with global and nonlocal keywords, but still ugly)."
  
  Again, it's not scoping that's peculiar, it's shadowing. Again, I've almost never used global and never used nonlocal and every use of them I've seen has been a code smell, even in my own code.
• Another thing is the wonky implementation of OOP. You “hide” instance variables using underscores as a prefix, but they aren’t really hidden.
  
  How is that wonky? It's just a language without access control modifiers that grew a convention for indicating that something's not part of the public API. Perl is the same way. The only thing that makes Python so noteworthy is that a language still so actively evolving hasn't yet gained a private keyword to complement the gradual typing.
• "You must always pass self (or some other name of your choice) as the first argument to an instance method in its definition. But this is inconsistent with the actual method call!"
  
  I don't get why this bothers them so much. Should I start calling out the objectively more confusing languages like C++ where there's no syntactic difference between member access and accessing non-member variable/functions visible in the current scope?
• "Expected object attributes are special-cased. For example, an object that should have a length attribute is passed to a global function, len(obj), instead of using obj.len()."
  
  Fair, though how much this bothers you depends on which languages you have prior experience with and Python is older than the languages people usually think of as "better" in this respect. It's sort of like criticizing C for not being C++ or Rust.
• The rest of the points were already covered before

Finally:

• "First, the mix of tabs and spaces can be very confusing. Depending on the editor configuration, a tab can be 2, 4, 8, or any number of spaces. This makes it confusing for other developers who must look at your code with their differently configured editors."
  
  Python 3 made it an error to mix tabs and spaces, and the PEP8 style guide most Python developers follow (which has auto-formatting tools available) calls for 4-space-per-step indentation.
• "Second, cut-and-paste becomes a dangerous operation. It’s too easy to accidentally misalign your code, and if you’re tired, you won’t catch it."
  
  Again, a fair complaint.
• "Third, deeply nested control structures can push far over to the right and beyond the edge of the edit window. Since the language is so opinionated, you cannot easily work around this."
  
  In my just under 20 years of coding Python, I've become convinced that needing deeply nested control structures to the point where this becomes an issue is a code smell.
• In free-form languages like C and Lisp and Smalltalk, you can reformat your code any way you like.
  
  It's funny that they'd mention two ancient languages, when modern free-form languages are going in the direction of automatic code formatting, which locks in a much stricter format than Python does and the delimiters are just to protect against human error.
• "Fourth, line continuations with ‘\’ annoy me to no end. It’s ugly, ugly, ugly. I doubt that I’m alone."
  
  Amen... that's why I always use alternative syntax, such as putting parens around what I need to break over multiple lines.
• "Fifth, if Python is your first language, you will find a difficult transition to most other programming languages.
  
  If your first language is one of most other programming languages, you will find a difficult transition to Python."
  
  "No wonder Off-side rule syntax is the #1 criticism of Python for most developers."
  
  Citation, please? Both of these claims are at odds with my own anecdotal experiences, so I'd want something with good methodology.

Most of the complaints in your links are equally (if not moreso) applicable to PHP, Perl, Ruby, Lua, and just about any other mainstream dynamic language that isn't TypeScript. Many of the remaining ones are more a mark against the skill/experience of the person making the complaint. As for what's left, sure, they're valid, but every language has its warts and no language is suited to every task.

[pgoetz]

[*]"Python version 2 or 3, which to use?"

In 2018? That's like asking whether to use Windows XP or Windows 10 in the months leading up to the final termination of extended security updates for Windows XP.

Thanks for taking the time to write all that up -- it was informative.

I'll speak to just one point, the one quoted above. I work with scientists, particularly molecular biologists who are becoming more and more dependent on computational methods, and virtually everything we use is still written in Python 2. The Python 2 vs. Python 3 thing is an ongoing source of frustration in the real world; so much so that almost everything has be to run out of a conda environment, which comes with its own problems; most particularly when you need to pipe the output from one program to the input of another one in a different conda environment. Seriously, the Python 2 vs. Python 3 thing alone has me cringing every time I get a request for a new analysis tool and find out it's written in Python, or is encapsulated in miniconda by someone who doesn't really understand how the conda thing works (the norm, since it's frequently biologists writing the software).

[Vistaus]

I think bash is excellent for it's job. if you need to run a lot of different utilities and the primary thing you are doing is calling external processes bash is the best tool for the job. Granted you can do the same with a more limited shell. It's mostly a matter of picking the right tool for hte job. Python is more cumbersome in that regard.

Bash sucks. Fish ftw