Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

121–130 of 187 posts

Re: Why Perl Didn't Win

#121
post #109

Earlier quoted context omitted.

There is a common theme to early Java discussions and discussions about golang right now. I'll sum it up as "All that power/functionality/expressivness of language x is really a distraction from getting stuff done . Further it complicates the software development model of large disparate groups." I'm not sure that theme is wrong even, but to many of us who lived through early java, golang's least common denominator a…

I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code. IMHO, it failed epically at this, and today we would basically laugh at the idea that Java is good at that, but it was in fact a design criterion back in the day. One could make the case that it sort of succeeded at the iso…

> I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code.

Wind back 35 years or so and you could have said the exact same thing about COBOL.

Re: Why Perl Didn't Win

#123

Earlier quoted context omitted.

Perl was dead long before Ruby on Rails was a big thing (Ruby itself was effectively moribund until Rails).

> Ruby itself was effectively moribund until Rails I think you might mean "unknown" rather than "moribund", but just in case: no it wasn't, it was quite successful, RAA wasn't CPAN but was quite rich, there were steady improvements to the language and the community outside japan was growing (i.e. most of the european ruby user groups started before ruby on rails). It was just growing slowly, rather than skyrocketing.

Which is to say: in pretty much the same position Perl is in now.

Re: Why Perl Didn't Win

#124

[probably shameless plug] I first intended to write this as an answer, but I ended up with a complete blog post: http://programming.tudorconstantin.com/2015/01/perl-already-...

Watch out for whoever says that Perl is an ancient technology, because they're either ignorant and completely clueless about what's really happening in the world of computer programming, or they have hidden agendas.

That's a strong statement. Are you quite sure those are the only two possibilities?

Re: Why Perl Didn't Win

#125
post #6

I'd disagree with the assessment of Python3 somehow being sunset in 2020. This 2020 End of Life stuff is a marketing tactic to sell it. There are companies with 500K line codebases of Python that won't be on Python3 in 2020, if ever. It's just not feasible when new features have to be shipped. Expect pain (not for the companies in question, for Python3), in the form of a fork. The book isn't closed on this one yet. I…

While you may end up being right, Perl6 is a much larger departure from Perl5 (than Python3 is from Python2). Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)?

> Can one even use CPAN with Perl6?

Yes.

At a Perl conference in October last year Stefan Seifert decided it was time for him to have a go at something Perl 6 related. He had never written Perl 6 code before, let alone participated in the project, but within 24 hours he had Perl 6 calling Perl 5 calling Python[1].

That was just a few months ago. Now the Inline::Perl5 module[2] allows folk to use Perl 5 modules, even ones that do C level guts poking in to the Perl 5 interpreter, and to pass data back and forth, do callbacks back and forth, handle exceptions raised by Perl 5 in Perl 6 and vice-versa, use Perl 6 to call methods on Perl 5 objects and vice-versa, and use Perl 6 to subclass Perl 5 classes. Thus he's been able to, for example, create apps in Perl 6 using a leading Perl 5 web framework called Catalyst.[3] He's also having fun with calling Python libs from Perl 6.[4]

There's a lot more going on related to interop between Perl 6 and Perl 5, and more generally between Perl 6 and other languages, but the above is obviously a biggie.

> Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time

As is hopefully clear, with Inline::Perl5 there's no need to convert.

(Some folk will still want to rewrite some Perl 5 code in to Perl 6, and there are fledgling tools to assist, but they aren't necessary, just a nice option to have.)

[1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM...

[2] https://github.com/niner/Inline-Perl5

[3] http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk...

[4] http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121...

Re: Why Perl Didn't Win

#126

Earlier quoted context omitted.

To avoid str() calls with concatenation, use % formatting: '%s %s' % ('hello', 'world') Avoiding these implicit behaviors helps avoid bugs; it's worth it. I'd recommend going for Python 3 unless there's a specific reason (library) keeping you on 2.

I'd recommend: '{} {}'.format('hello', 'world') But yes - either way - it solves the need to do str() when concatenating.

I never understood the need for the new style of formatting, or the advantage. Fortunately % formatting is no longer getting deprecated.

Re: Why Perl Didn't Win

#127
post #104

Earlier quoted context omitted.

As someone that cares about performance I don't use Python any longer, except on cases where customers require me to do so. I don't need to convince others to join any kind of cause.

I don't follow. I am not talking about any kind of cause. However, you made a specific prediction, that "Python will be beaten", and I'm saying you haven't made a proper argument why that is so. As someone who cares about performance I still use Python for the non-performance critical parts of code, which is the vast majority. I'm pretty sure that in the end this is just a matter of personal preference, but you make…

My line of thought while replying to the parent is that if a rewrite is needed, those that are more performance minded, are likely to use a language that doesn't suffer from GIL or a pure interpreter as canonical implementation.

Somehow you can already see it on the interwebs. The majority of Go and Julia users come from Python and Ruby, not from languages that have AOT/JIT compilers on their toolchains.[0]

This is just my gut feeling from almost 30 years watching similar technology transitions.

I have no data to back it up and may be completly wrong.

[0] There is PyPy, but I never saw it being deployed in production systems.

Re: Why Perl Didn't Win

#128
post #109

Earlier quoted context omitted.

I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code. IMHO, it failed epically at this, and today we would basically laugh at the idea that Java is good at that, but it was in fact a design criterion back in the day. One could make the case that it sort of succeeded at the iso…

> I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code. Wind back 35 years or so and you could have said the exact same thing about COBOL.

Wasn't COBOL more about "your accountants can understand this"?

Re: Why Perl Didn't Win

#129

Earlier quoted context omitted.

> I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code. Wind back 35 years or so and you could have said the exact same thing about COBOL.

Wasn't COBOL more about "your accountants can understand this"?

I'd always heard "manager", but I think "accountants" is actually a stronger case.

Re: Why Perl Didn't Win

#130

Earlier quoted context omitted.

Tcl was and still is undiscovered gold.

I'm very glad that only game writers are using Tcl for scripting their games. It's a godawful language I'd never want to maintain any real software in. Python and Ruby are bad, but Tcl is a degenerate joke. Let's please leave it undiscovered.

Sentiments like this please me greatly. Out of curiosity, what do you prefer?
Post reply on HN