Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

Post reply on HN
Print view View original

111–120 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#111

Post by nchelluri »

ed25519FUUU wrote: post #91
nchelluri wrote: post #45

Earlier quoted context omitted.

I've been writing (Modern) Perl for about 3.5 years and I disagree that Perl necessarily tends to unreadable code. I really don't think that's true at all. To quote myself from a recent discussion: I think some languages do make it easy to write convoluted code, but through judicious use of coding standards (including a helping of common sense [don't be clever where you can at all avoid it, which IME is ~~almost~~ al…

Under that standard it’s true, but it’s also true for virtually any language and is therefore not a good defense of whether or not a language lends itself to unreadable code.

There are a couple of points in there:

1. You can use virtually any language to write clean code

Not sure if I agree with this, though it may well be true. I just know there are some things like Brainfuck where it's designed to be impossible. I realize that language is created specifically for the purpose of making a coder say "WTF", but perhaps there are other languages that are not designed to be so that are really nearly impossible to write good code in.

2. Perl lends itself to unreadable code

If you stick to Modern Perl you still might end up with things like `wantarray` in your code so I guess this is kind of true. You need to be judicious in your use of code.

Some languages lend themselves more easily to writing clean code, like I feel about Go or if you hate the Go type system, Ruby. Even in Ruby I feel like metaprogramming is ripe for misuse.

It's a tough thing to talk about. I don't feel like I wholeheartedly disagree with your sentiment which seems to be "some languages lend themselves to bad code" and subsequently that Perl lends itself to bad code but there is plenty of ambiguity in these thoughts.

Re: Perl 7 is going to be Perl 5.32, mostly

#112

Post by staycoolboy »

sumanthvepa wrote: post #24

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

I was on one of several CAD teams at Intel in the 90's and huge parts of pre and post-silicon Itanium simulation flows for timing, layout and verification were written in Perl. (Not even Perl 5.6 so we hit the 2GB file limit often!) ... Not the tools themselves, but the control flows and asset managers. The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.

Re: Perl 7 is going to be Perl 5.32, mostly

#113

Post by cutler »

_sbrk wrote: post #92
papito wrote: post #82

Earlier quoted context omitted.

Perl was a great fun scripting language back in the day of CGI and "webmaster@". It died a noble, honorable death. RIP.

It's not even close to dead.

True. If you search Indeed.co.uk there are more jobs which mention Perl than Golang.

Re: Perl 7 is going to be Perl 5.32, mostly

#114

Post by SuspiciousSwan »

jes5199 wrote: post #48
sumanthvepa wrote: post #24

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…

I think you should revisit perl.

My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages.

I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd been using previously, the game was to fit the problem into what the language wanted you to do. HOP would likely be boring to you now, and wouldn't do much for me, but at the time, it showed me that perl was a language in which the same problem could be solved in multiple different ways, and both be just as right as the other.

Fetishizing that freedom, just like anything else, leads to self indulgent trash. I've seen it in every language, but perl allows for so much freedom it is easy to misuse.

It clicked with me that the best perl code was code that did what I intuitively thought it should do when I used it, and did what I thought it would do when I looked at it. Perl, compared to every other language that I've used, gave me tools to accomplish that.

Perl's object system is Python's, just in its raw parts. I still miss aspects of Moose that are impossible or ugly to use in other languages. Regexps are easy to misuse, but grammars allowed me to cleanly express what something did better than I've been able to in any other language. Mixing in functional ideas, where appropriate, made my code easier to reason about, instead of the debugging hell that I've seen it add to languages like Java. When I learned the concepts from perl, I learned when to use them in other languages.

I don't use perl much anymore, and I don't think I would push it on a team, and I really don't think that it is a good language for beginning programmers, unless there are good mentors around. Most of the beautiful code that I've ever written has been in perl.

Re: Perl 7 is going to be Perl 5.32, mostly

#115

Post by ksec »

kbenson wrote: post #28
continuational wrote: post #17

Earlier quoted context omitted.

What do you mean by efficient and cheap? It doesn't fare well in https://benchmarksgame-team.pages.debian.net/benchmarksgame/... at least.

Nodejs is very fast, because it uses an an engine that has had multiple millions of dollars thrown at it to make it fast. Most interpreted languages don't fare well against it. Perl fares somewhat favorably against Python, Ruby and PHP though. Those are what I would consider equivalent languages to compare against to get a general idea of its speed.

>multiple millions of dollars

I can pretty much assure you the accumulated dollars invested over the years in making JS fast is likely to be closer to multiple billions combined.

Re: Perl 7 is going to be Perl 5.32, mostly

#116

Post by staycoolboy »

jes5199 wrote: post #48
sumanthvepa wrote: post #24

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…

Perl was my first encounter with regular expressions. To this day, no language I've used does it better and cleaner. This includes Python, Boost/C++, Java, JavaScript, LISP, Go and Rust.

Re: Perl 7 is going to be Perl 5.32, mostly

#117

Post by dhosek »

earthboundkid wrote: post #98
cutler wrote: post #77

Earlier quoted context omitted.

Ruby also has this.

Ruby really is Perl done right. I can't really see any argument for Perl over Ruby as a language.

use strict. In Perl you can prevent something like the following from compiling. You can't with Ruby (unless they've finally addressed that).

   $foo = 2;
   if (some_test()) {
      $fooo = 3;
   }

Re: Perl 7 is going to be Perl 5.32, mostly

#118

Post by marksomnian »

peterwwillis wrote: post #85
jes5199 wrote: post #48

Earlier quoted context omitted.

huh. I spent a couple years writing perl professionally, I guess that was around 2006, and I couldn't agree less. Its object system is so bizarre compared to any other language - it's like it doesn't really have an object system, it has parts of a system that you can try to assemble, but no matter what you do you end up with something weird. And on top of that, the sigils, refs, and `wantarray` systems means that fig…

> You learn perl, and you've learned nothing but Larry Wall. Yes, this is why it's nice. You don't have to worship at the foot of an industry which slavishly tries to implement a misunderstanding of a system some dude made up 40 years ago to get around problems in other systems some other dudes made up before that. It's weird on purpose. And it's backwards-compatible-crufty on purpose. Today I can run Perl code writt…

JavaScript probably can, or at least mostly. That's where a lot of its problems come from, historical baggage.

Re: Perl 7 is going to be Perl 5.32, mostly

#119

Post by zeveb »

staycoolboy wrote: post #112
sumanthvepa wrote: post #24

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

I was on one of several CAD teams at Intel in the 90's and huge parts of pre and post-silicon Itanium simulation flows for timing, layout and verification were written in Perl. (Not even Perl 5.6 so we hit the 2GB file limit often!) ... Not the tools themselves, but the control flows and asset managers. The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.

> The other processors still used Tcl on HPUX/Solaris/AIX so Perl on Linux was like nice warm sheets by comparison.

I would agree, but I don't think you meant it the same way I would: I prefer nice cold sheets when I sleep, and I much prefer Tcl to Perl!

Re: Perl 7 is going to be Perl 5.32, mostly

#120

Post by jlokier »

jqcoffey wrote: post #40
sumanthvepa wrote: post #24

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

Ok, so I wrote tons of Perl and am to this day a fan, but I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_. It is flexible and fun and I do miss it. True story: years of passing functions to other functions and map/greps made the switch to FP Scala (another language I fear will die) a lot easier!

> I don’t think one can call a blessed hash (or scalar for the fancy folks) an object _system_.

Perl first, then JavaScript.

Did you know JavaScript classes are blessed hashes?

They even take about the same amount of syntax. ("__proto__" vs "blessed", "prototype" vs "bless").

Old JavaScript made the blessing crude and obvious.

Modern JavaScript lets you hide it in a "class" decleration. Which you can also do in Perl if you want (though you'll need to choose a module for this, and people generally prefer a different approach to dressing up objects in Perl.)

There's still a blessed hash under the hood which you can see and kind of have to be aware of... in both languages.

Post reply on HN