Live data from Hacker News

What Happened to Perl 7?

blogs.perl.org

161–170 of 245 posts

Re: What Happened to Perl 7?

#161

Earlier quoted context omitted.

> it is very unrestrictive That makes collaboration hard. The freedom I have in putting my thoughts into code, uninhibited by syntax, types and conventions makes it nearly impossible for others to understand and modify my work.

The freedom to flexibly put thoughts into code can be used to make code more readable, or less, it depends on the programmer. A significant code base in any language can turn into a hot mess The perl coding team I was on made readability our #1 priority. We didn't use tricky or out of the ordinary syntax unless it was absolutely necessary (like unusual regex, etc), and in those cases we would document what was happen…

Anything that "... depends on the programmer" is doomed to fill up with the output of a lot of programmers who were insufficiently disciplined. At some point the majority of the work becomes avoiding or working around or firewalling that output on your own projects. Telling people to just "Get Gud" at programming is a non-solution. The more I do this the more convinced I become that using a robot (compiler, linter, static-anlyzer) to enforce discipline is a good idea and the more difficult it is to escape that robot's gaze the better. Anything else is just going to cause massive pain later.

Re: What Happened to Perl 7?

#162

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I've always enjoyed Perl as a language . But I walked out of that presentation thinking "That was so beautiful, and I don't want it anywhere near my business." Because the last thing I need is softw…

> I never liked Python much, until I got forced to use it on a new team. Now I'm convinced that it has a really distinct advantage -- there aren't too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. This is why I picked up Python many years ago. I had been using Perl 5 for my scripting and system administration needs. While it worked just fine any project larger than…

"It's elegant when writing but frustrating when reading"

As a person who used to use Perl 5 rather extensively back in the day for all sorts of things, I fondly remember the joke that Perl is a "write-only language" :)

Re: What Happened to Perl 7?

#163
post #80

Earlier quoted context omitted.

How you use or abuse that freedom is entirely your choice.

The languages that truly let you do anything you want flexibly invariably lead to incomprehensible ivory towers. It is why managers hate Lisp, it's why Perl is joked as write-once read-never. The issue with the "DSL" is the third letter in the abbreviation: LANGUAGE. A language isn't just a specification of syntax. A language is a collective shared understanding between a sufficiently large number of people. Without…

> The languages that truly let you do anything you want flexibly invariably lead to incomprehensible ivory towers. It is why managers hate Lisp, it's why Perl is joked as write-once read-never.

I've yet to see that happen in a Lisp project. On the other hand, inflexible languages like Java lead to abominations like the Spring framework, where tons metaprogramming happens at runtime via reflection.

The thing about compile-time macros (e.g. Lisp macros) is that they can be debugged at compile time. For example, if you see a macro invocation, and you don't know what it does, you can just expand that macro right in your editor, and look at what code was generated.

People are always worried about DSLs, but most projects end up with their own DSLs. They're just often built out of functions, methods, objects, etc.

I think the real issue with understanding a project is learning the concepts, architecture, and abstractions they use. Knowing e.g. Go really well doesn't save you from having to wade through the giant pile of code used to express the program's intent. Abstraction is a way to get that complexity filtered down as close to the problem's inherent complexity as possible. Yes, you'll have to learn the abstractions, but if done reasonably well, that will still be much easier than trying to understand the non-abstracted version.

Re: What Happened to Perl 7?

#164

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I've always enjoyed Perl as a language . But I walked out of that presentation thinking "That was so beautiful, and I don't want it anywhere near my business." Because the last thing I need is softw…

you've also described the reason lisp ultimately failed IMHO - it's selling point is creating first-class DSLs, but you can't hire anyone experienced in the DSL you've got...

Re: What Happened to Perl 7?

#165
post #159

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I've always enjoyed Perl as a language . But I walked out of that presentation thinking "That was so beautiful, and I don't want it anywhere near my business." Because the last thing I need is softw…

Everything you loved about Perl is exactly why I hate it. The syntax noise is too great and it has too many ways for people to be too clever with it.

I totally agree. That's why I loved it for me, but hated it if I ever had to deal with someone else's code. And why I never use it any more, unless I'm doing a bunch of text processing on my own workstation.

Re: What Happened to Perl 7?

#168
post #40

Earlier quoted context omitted.

> it isn't like there was any choice on that matter There was another choice. This is what I mean: however bad you think py2->py3 was, people are using py3 now unless they've got really good reasons not to and are prepared to suffer. When it came to perl5/6, it turns out over time most people choose "neither". SUSE didn't update the link like others did so it's not really that py2 is the default, but python2 was alwa…

The “neither” choice happened with Python 2/3 as well. The current re-emergence of Python as a machine learning/data science languages is basically a new trend. Long before that, before the Python 3 transition, there was a significant amount of buzz around everything from web frameworks to desktop GUI applications. The way I remember it, almost all of that attention was killed during the transition, when people tried…

it was a trend made possible by numpy and scipy being built for a decade before the phrase 'deep learning' was coined. it had just the right mix to blow up: easy to read, easy to write, batteries included.

it wasn't inevitable, but it was damn likely.

Re: What Happened to Perl 7?

#169
This seems like a whole lot of bending over backwards to avoid breaking a handful of edge cases that could be cleaned up on their own without too much drama.

I would kind of prefer the features be enabled by default if you use a high enough version and if a module breaks you just fix it or dial back the version number at the top of your script until it is fixed.

But I'd also run all of the test suites on CPAN against every new feature that comes out and fixing or at least tagging anything that breaks. Maybe even list a "maximum tested version number" for each module and emit a warning if you exceed it.

Re: What Happened to Perl 7?

#170

Earlier quoted context omitted.

> For all the buzz about python3 fiasco, we're pretty much migrated now and py2 Python 3.0 was released in 2008, the fact that 14 years later 2.7 is still widely available (and often the default python, e.g. in my openSUSE Tumbleweed system here) means that the "buzz" was more than warranted. Also of course things would migrate, it isn't like there was any choice on that matter (and projects like Tauthon that tried t…

> it isn't like there was any choice on that matter There was another choice. This is what I mean: however bad you think py2->py3 was, people are using py3 now unless they've got really good reasons not to and are prepared to suffer. When it came to perl5/6, it turns out over time most people choose "neither". SUSE didn't update the link like others did so it's not really that py2 is the default, but python2 was alwa…

> There was another choice.

Only if you count "not making a choice" (ie. staying with Python 2) as a choice. But this isn't really practical since everything else is pushed towards Python 3.

Post reply on HN