Live data from Hacker News

What Happened to Perl 7?

blogs.perl.org

171–180 of 245 posts

Re: What Happened to Perl 7?

#171
post #36

Earlier quoted context omitted.

Yes i know, in fact i thought about it when writing that line but i thought it'd be obvious that the issue still remains, especially if said files are too big. It might be easier but you are not really solving the problem as well as opting in to the new functionality when and if needed.

I hope we can agree that Python 3 was qualitatively different because all of your libraries had to migrate first. Now, your new argument depends on how hard it is to migrate a single file. If that’s sufficiently easy, you simply do it. Migrating to the last Rust edition, I had to fix maybe a handful of things in an entire crate ; most files didn’t have to be touched at all.

Certainly, Python 2 to Python 3 was harder due to all the dependencies and having to convert the entire program.

My argument isn't really about migration is about not having to migrate if you don't need the features while not losing anything - by opting in to the new features/changes you can use whatever you want without wasting time on changing your code to do the same stuff just in a different way (unless you decide that this different way is actually better and worth doing, but that'd be your choice and not something indirectly forced on you by the ecosystem you decided at an earlier point in time to rely on).

Re: What Happened to Perl 7?

#172

Earlier quoted context omitted.

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 com…

> 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 wish there was a kind of super-upvoting that added one to the font-size of the comment you're upvoting, because I would absolutely super-upvote this comment.

> 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.

Absolutely. It's possible (arguably, too easy) to build a bad DSL, but the point of a DSL is to surface the inherent complexity of your domain so you can grapple with it on its own terms. Not using a DSL doesn't mean that complexity goes away; it just means you have to grapple with that complexity using coarser tools. You usually end up with a DSL-lite of types and functions that work in your domain, often with warts due to poor interactions with the host language's feature set.

For a lot of reasons, I'm a big fan of eDSLs, which aren't too much different from the DSLs-lite we usually end up with. But overcoming that impedance mismatch with the host is not easy. (That's one of the benefits of Lisp, I think -- very low impedance mismatch to overcome!)

I've gotten somewhat good at doing eDSLs in Java(!), where you want to keep things mostly idiomatic, unconstrained Java while still adding the novel behaviors you need for your domain solutions. But you're always going to have to wrangle the complexity of your domain, whether or not you involve a DSL in that effort.

Re: What Happened to Perl 7?

#173

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 think Perl fell victim to a huge change of fashion around the 2000s.

'There's more than one way to do it' and the whimsical, deliberately slightly obtuse design of Perl used to be what people valued.

Then something happened (perhaps it was how people started building much larger apps in 'scripting' languages, to use an out-dated term) and I think to most people under 35 deliberately having 'more than one way to do it' sounds like an atrocious idea and something they don't want anything to do with. Same with linguistic whimsy in their language design - they don't want to have to look up why a method to do with objects is called 'bless' for example.

Look at the success of languages like Go, which are the polar opposite of Perl's philosophy.

Re: What Happened to Perl 7?

#174
post #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...

Being skilled in Lisp or other DSL producers can be amazing for one-man projects.

Above that sticking with standard languages really is useful. I remember seeing a "DSL cycle" somewhere - http://mikehadlow.blogspot.com/2012/05/configuration-complex...

Re: What Happened to Perl 7?

#175

I'll speak up for Perl. I learntbit voluntarily in my own spare time and actually get a lot of delight out of the language. I like that it is very unrestrictive. The sigils make sense when you wrap your mind around them and you miss them in other languages. It is excellent at parsing text. I wrote a static site builder using Perl along with a very rudimentary templating system ( https://soft.thran.uk for the curious)…

A couple of the things that perl has over python and ruby... #1 is execution overhead, although that may have changed in recent times. #2 is that it's preinstalled on most linux/BSD OS's as a requirement for its plumbing, which makes it nice if you're trying to run a system on minimal dependencies.

It's ugly for all the reasons that people complain about it for but those are largely complaints and the rest of us have work to get done.

Oh yeah, and if you liked perl - I highly recommend learning AWK/SED. Even lower on the execution overhead (Can do shit in the processor cache and avoid memory allocation bottlenecks on enormous hundreds of gigabyte CSV datasets with a crappy processor in milliseconds kind of stuff)

Re: What Happened to Perl 7?

#176

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…

[deleted]

Re: What Happened to Perl 7?

#177

I'll speak up for Perl. I learntbit voluntarily in my own spare time and actually get a lot of delight out of the language. I like that it is very unrestrictive. The sigils make sense when you wrap your mind around them and you miss them in other languages. It is excellent at parsing text. I wrote a static site builder using Perl along with a very rudimentary templating system ( https://soft.thran.uk for the curious)…

[deleted]

Re: What Happened to Perl 7?

#178
post #124

An anecdote of my career is that some programming languages attract different kinds of programmers. I've dealt with Delphi in the beginning of my career and while there was nothing wrong with the language, it seemed to attract a lot of bad programmers writing really poor code. And Perl was the opposite of this anecdote: the most brilliant engineers I've met in my career were Perl monks, as they would call themselves.…

[deleted]

Re: What Happened to Perl 7?

#179

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 think Perl fell victim to a huge change of fashion around the 2000s. 'There's more than one way to do it' and the whimsical, deliberately slightly obtuse design of Perl used to be what people valued. Then something happened (perhaps it was how people started building much larger apps in 'scripting' languages, to use an out-dated term) and I think to most people under 35 deliberately having 'more than one way to do…

And then there was the rise of Javascript, which also allows for many many ways of doing the same thing.

Re: What Happened to Perl 7?

#180

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…

The problem is, as appealing as building a DSL (in or out of another language) is to engineers, turning your source base into a pool of pidgins where there are no native speakers and all new hires or people moving between parts of the code base will need to learn a new language is not an advantage. It is completely unnecessary friction. We all get this when we encounter jargon-crazy groups, but somehow forget it when…

OTOH an application does have its own language. Someone said "When you devised an application you wrote a hundred words [(functions)] or so that discussed the application and you used those hundred words to write a one line definition to solve the application. It is not easy to find those hundred words, but they exist, they always exist."

I think for non-trivial programs it is not avoidable to have to learn first the terminology of the domain and the terminology of the program (how things were named when it was not dictated by the language of the domain).

However, hacking the syntax of the language is a whole different story, and perhaps that's where DSL-ready languages go wrong. That's ironic coming from someone that just quoted the author of a language that has no syntax to speak of, and macro powers that are sometimes compared to Lisp macros. Just use them wisely, one would say, but that kind of wisdom comes with experience.

Post reply on HN