Live data from Hacker News

What Happened to Perl 7?

blogs.perl.org

191–200 of 245 posts

Re: What Happened to Perl 7?

#191

Earlier quoted context omitted.

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…

Perl is excellent for data analysis in a terminal. It is built to work with pipes, it's fast, concise, stable, and easy to extend. The REGEX integration is superb. It seems to me that we have a couple of generations of programmers who turn up their nose at anything that isn't Python notation and then repeat vague arguments about Python's superiority. But like all dogmatic systems, there is no agreement among the zeal…

Python wins out the popularity contest because of ease of readability that I think we can take for granted. Perl is true wizardry, I mean 'sigils' and stuff you need to know in order to make it work... Plenty harder to get at first glance for sure but it's truly occult in a lot of ways. I think that's kind of cool.

The way I see it is that you can do interesting things in pretty much every computer language written out there, it's just some are more arcane than others in some ways than others.

I remember when python started getting big and all the old perl heads were complaining about the forced indentation hahahaha

Re: What Happened to Perl 7?

#192

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…

when i first heard that lisp was supposed to be good for making DSLs, my first thought was 'gross, i'll just stick to writing plain lisp thankyouverymuch'

but i think that's a misunderstanding- it's not a suggestion to make a mess with reader macros or whatever, its an observation that common lisp _naturally_ builds up to form the language constructs needed in your domain, simply by virtue of providing the tools and syntactic flexibility needed to construct them

another thing that seems to put off newcomers to cl is the parallax between the promise of a smooth, polished dev environment, vs the nuts-and-bolts-exposed nature of the core language itself (eg the infamous eq/eql/equal/equalp situation)- but i think this can be explained as how cl is _not_ a scripting language, and you are expected to paper over these edges as you define the system

cl gives you the best tools in the business to turn itself into a dev interface so clean it might as well be a DSL

Re: What Happened to Perl 7?

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

There is no such thing as a software shop with no local DSLs, in any language. All the in-house abstractions constitute DSLs.

Without syntactic abstraction (function and data only), things are worse, because those abstractions have to be coordinated together into proper usage scenarios, and those are written by hand in multiple places. So you're looking at eye-glazing repetitions.

Oh, and just because a language doesn't have macros doesn't mean you won't see any syntax-level DSL. You may find textual code generation in a project in any language. C++, Go, Java, you name it.

Understanding a large amount of unfamiliar code is a challenge no matter how it is organized. Whether it uses syntactic abstraction is a minor factor, and it is not an iron clad truth one way or the other whether that helps or hurts. If you can learn a complex API where you have to take several kinds of objects through a multi-step workflow, you can probably learn a syntactic construct that does it for you; especially if it is documented and has test cases.

You will never hire anyone who is experienced in the vocabulary of your code base, unless it was someone who was previously laid off.

Re: What Happened to Perl 7?

#194
post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

Python supported piecemeal changes with backported Python 3 features using the future imports. They were essentially the same thing as what Perl 7 is espousing minus the promise of a breaking cutoff.

Re: What Happened to Perl 7?

#195
post #137
post #91

Earlier quoted context omitted.

> Perl never had this kind of traction afaik - yes many scripts were written on Perl but not many .com companies were based on it. Were you around for the first (pre-2000) dotcom boom? From where I was sitting (freelancing in London) it sometimes seemed that all of the first wave of dotcom companies were writing their apps in Perl. In fact, I've often thought that a lot of Perl's current bad reputation stems from thi…

I think Perl lost to Ruby because of Rails. Whilst Perl had a couple of web frameworks - Catalyst, Mojolicious and Dancer - they never gained anywhere near the traction of Rails. I think this was because Perl's early success in the 90s was based on CGI.pm, not frameworks. Catalyst gained a little adoption at a few big companies but it was hobbled by dependence on mod_perl which had a much riskier memory mode for host…

> I think this was because Perl's early success in the 90s was based on CGI.pm, not frameworks.

Exactly, the second wave of dotcom software was largely written using frameworks that built on the mistakes we'd been making in the first wave.

And because, so many programmers had memories of horrible experiences trying to beat Perl/CGI applications into submission, it was probably too late for Perl even then - although a large number of excellent Perl tools (Catalyst, DBIx::Class, Template Toolkit, Moose, PSGI to name just a few) were emerging at about the same time as Ruby on Rails or Django.

Re: What Happened to Perl 7?

#197

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…

Do you remember the title or any other details of Conway’s presentation? I’d like to look for this.

Re: What Happened to Perl 7?

#199
post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> opting in to an experimental feature could be a one-liner

This exists since 2013. https://metacpan.org/pod/experimental

> Probably not much of a problem currently, but might be if releases get more frequent.

Very unlikely. Perl switched to a yearly release in 2010, it has been in use since and there is no indication for this to change. https://lwn.net/Articles/485569/#:~:text=a%20%22timeboxed%22...

> focus on tooling around installation […] install more and more of their binaries into the user’s home directory

Exists. Wouldn't be Perl if one hadn't the choice between multiple solutions.

https://metacpan.org/pod/local::lib https://perlbrew.pl https://github.com/tokuhirom/plenv https://metacpan.org/pod/perlall https://metacpan.org/pod/App::plx https://github.com/stevieb9/berrybrew

> I’m not following Perl that closely anymore

It is evident.

Re: What Happened to Perl 7?

#200
post #19

Earlier quoted context omitted.

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

> How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? AFAIUI you can mix Rust 2015, 2018, and 2021 crates; so a developer can update their own crate to 2021, while not having to completely re-write the dependencies which are still Rust 2015. With Python 2 -> 3, my understanding was that everything had to be updated recursively. That said..…

> With Python 2 -> 3, my understanding was that everything had to be updated recursively.

You can mix "Python 2" and "Python 3" code, but the problem is (was) that the semantics in Python 3 surrounding string handling changed so much that in reality this was tricky to accomplish, and Python's dynamic untyped nature didn't help either.

But it was definitely possible to write libraries that worked with Python 2 and 3; I've made a few. It was pretty tricky though, and often led to bugs.

Post reply on HN