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

Why Perl Didn't Win

outspeaking.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Why Perl Didn't Win

#71

Post by pjmlp »

kamaal wrote: post #60
rdtsc wrote: post #57

Earlier quoted context omitted.

So maybe winning is more like winning for a time period. PERL did win. It won up until early 2000s, then lost. I am guessing it is not getting picked much for new, greenfield projects. I think that is a cut-off metric. One way get there is to find a niche. Maybe it isn't the new use-for-everything language. But at least can become the "ok, use for this one area" language. C -- still winning in that respect. It is use…

I think the definition of 'winning' people use around here is, if start ups think its a trendy technology to use. So you will see all these new companies stop using a particular language, and then when some conference happens you will see talks around the older technologies have dried out, while people are giving talks on the newer set of technologies. Its then when you see articles/rants/blog posts on the lines 'Wha…

> ...and then when some conference happens you will see talks around the older technologies have dried out...

So I must live in another planet as the European Java (Devoxx, Jax,...) and C++ conferences keep getting fully booked.

NDC 2014 just had a record count of C++ talks.

Re: Why Perl Didn't Win

#72

Post by SilasX »

crahrah wrote: post #23
bane wrote: post #7

Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain. Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to…

""non-standard" bits of the language start leaking into your code" I work on a small team (C++), so this has never been an issue. If you break coding guidelines someone will notice and let you know. But this really should be integrated into work-flows. (ie/ into Gitlab, Jira, etc.) There should be some kind of step - before you are allowed to merge code - that checks that you are withing coding guidelines.

Yes, those are called linters: http://en.wikipedia.org/wiki/Lint_%28software%29

Re: Why Perl Didn't Win

#73

Post by winter_blue »

At the end of the article, he/she says "the Swift programming language has been public for less than a week and already has more users than Perl 6, and Swift is entirely built on technologies which have been invented since the Perl 6 announcement".

That's simply false; anyone who's been in the programming languages field for a while knows that...

Re: Why Perl Didn't Win

#74

Post by aaronbrethorst »

winter_blue wrote: post #73

At the end of the article, he/she says "the Swift programming language has been public for less than a week and already has more users than Perl 6, and Swift is entirely built on technologies which have been invented since the Perl 6 announcement ". That's simply false; anyone who's been in the programming languages field for a while knows that...

I interpreted that as 'Perl 6 dates back to 2000, while LLVM (upon which Swift is built) dates back to slightly later in the year in 2000.' (although, to be fair, the LLVM website first appeared in 2002.)

Re: Why Perl Didn't Win

#75

Post by davewood »

dmckeon wrote: post #42

As a Perl and Modern/PBP fan, I have to suggest that CPAN has become a poorer resource over time: > In the olden days, you could expect to find a Perl module for most anything you wanted to do but also: Having 57 modules all called Sort will not make life easy for anyone (though having 23 called Sort::Quick is only marginally better and it seems that every time I look for a useful module on CPAN I find myself in a tw…

There are a few things to consider when trying to pick a good/the best module for a problem.

- ask in irc.perl.org. it is very likely to get pointers from very experienced people.

- use metacpan.org and pay attention to the votes/likes it got. and read the reviews.

- each and every CPAN module is automatically tested. look at the stats to weed out problematic modules.

- check out the release frequency and when the last release occurred.

- read the Changes file

- take a look at the tests for the module, is it well tested? are there alot of tests?

If you are past a certain point in your life as a Perl programmer this comes very natural and does not take alot of time.

Re: Why Perl Didn't Win

#76

Post by AlexanderDhoore »

keypusher wrote: post #62
kamaal wrote: post #51

Earlier quoted context omitted.

But what is $x? Integer? String? Character? Some_Object? How do you evaluate this, depends on the context. Wasn't that the whole point of a dynamic language anyway?

No, not at all. Type coercion is orthogonal to type safety.

Amen, brother! I call this "weak typing". But some others use weak typing to mean different things (like "unsafe typing") [1].

Javascript, PHP and Perl are weakly typed. Smalltalk, Lisp, Python, Ruby... are strong typed. But all of them are dynamic.

[1] http://en.wikipedia.org/wiki/Strong_and_weak_typing#Predicta...

Re: Why Perl Didn't Win

#77

Post by stormbrew »

overgard wrote: post #25

Perl is sort of like trying to read someone else's brain (in this case Larry Wall's). You get themes and kind of the gist of where it's going, but it never quite adds up to some sort of coherent whole. The defense has always been that Perl is designed more like natural language than programming language, ok, but: natural languages are a LOT harder to learn than programming languages. Put me in a room with Haskell and…

> Put me in a room with Haskell and I'll learn it in a month. Give me a month of training in french and I'll maybe be able to not make an entire ass of myself if I try to get from point A to point B. Human languages are hard.

To be fair, I don't think this is actually because human languages are all that hard to become competent (note: not fluent) in. It's just that with computer languages you have an endlessly patient practice partner to work with. In particular, I think the complexity of competent Haskell is definitely higher than most spoken languages.

Re: Why Perl Didn't Win

#78

Post by aphexairlines »

amenbrother wrote: post #47
shadowfox wrote: post #35

Earlier quoted context omitted.

This sort of distinction exists in other languages though: Java has == and equals. OCaml has = and == etc. (Not that Perl doesn't have its issues; but this is very low in that list imho)

Those languages are far more maintainable and their communities have far more respect for practices which prevent programming errors. I don't particularly care how many forms of equality or comparison a language has as long as the compiler or runtime is capable of telling me the particular one I'm using is probably wrong. If == can't be used with strings the damn interpreter should tell me so instead of silently and…

The interpreter does tell you.

    $ perl -e 'use warnings; use strict; print "content" == "foo", "\n"'
    Argument "foo" isn't numeric in numeric eq (==) at -e line 1.
    Argument "content" isn't numeric in numeric eq (==) at -e line 1.
    1

Re: Why Perl Didn't Win

#79

Post by mst »

amenbrother wrote: post #15
bane wrote: post #7

Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain. Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to…

I was recently asked to add some trivial code to the end of an existing unmaintained Perl script written long ago. Something along the lines of $x = `cat FOO 2>/dev/null`; if ($x == "foo") { system("BAR"); } When I tested it I found BAR was executed no matter what FOO contained without any errors or warnings. WTF? After a little more searching I found the problem was that I should have written $x = `cat FOO 2>/dev/nu…

I guess you've never written any bash either, wherein the exact same problem exists except that == and eq are the other way around, for reasons I can't quite remember.

Plus, of course, if you'd enabled perl's warnings system, via 'use warnings;', it would have complained at the use of == on a non-numeric value.

If you don't enable the compiler features that catch problems, then, yes, you can run into problems. Welcome to programming.

Edited to add: I got downvoted within five minutes. If you disagree that my bash analogy is inaccurate, I'd love to hear why.

Re: Why Perl Didn't Win

#80

Post by tracker1 »

kephra wrote: post #67

> You need large absolute numbers of users to grow a library. That's why library ecosystems like that of Python, Ruby, and Node.js have grown large in recent years. Thats where the author missed an important point. None of those library archives have the culture of PAUSE+CPAN to constrain a minimal code quality when it comes to configuration, documentation, regression test and installation. This minimal code quality…

I have pretty mixed feelings on this... I feel that there are more than a few great uses of modules in npm that would never fly in cpan. My biggest issue with node today is that it still relies on python 2.7 for many binary modules.
Post reply on HN