Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

51–60 of 157 posts

Re: Why Perl Didn't Win

#51

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)

But in those languages, the equivalent to ($x == "foo") will return false (almost) all of the time. The poster here says that this expression is true (almost) all of the time in Perl. Why?

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?

Re: Why Perl Didn't Win

#52

Earlier quoted context omitted.

> For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Great straw-man there. I didn't realise that javac required 500 line methods before compilation. > In which case, the language of mandate doesn't matter much. It's a lot easier to pass two collections to a method in Java than to a sub in Perl.

--- Java --- List aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably missing some more type stuff in Map aMap = new HashMap (); aMap.put( "name", "Joe"); aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la Groovy... doSomething( aList, aMap); ... void doSomething( List aList, Map aMap) { System.out.println( "First: " + aList.get( 0) + ", Name: " + aMap.get( "name") ); } --- Perl --- &do…

> List aList = Arrays.asList( new int [] { 1, 3, 5 });

You can drop the inner array, asList takes variable number of arguments.

> // I need to check if Java 8 has map literals a la Groovy...

Sadly not, IIRC they've backed off from literals towards a Guava style static factory methods, which I'm not thrilled about.

> I'm not seeing that much of a difference in parameter passing, other than the explicit reference/dereference syntax.

So let's say I'm a newbie Perl developer just exploring subs.

  sub stuff {
      my ($a, $b) = @_;
      print "$a and $b\n";
  }

  my $a = 1;
  my $b = 2;

  stuff($a, $b);
It works! Hurrah. Feeling clever, I move onto collections.

  sub stuff {
      my (@a, %b) = @_;
      print "$a[0] and $b{A}\n";
  }

  my @a = (1);
  my %b = (A => 2);

  stuff(@a, %b);
And it doesn't work at all. @a has some additional values, and %b is undef.

So yes, let's use references.

  sub stuff {
      my ($a, $b) = @_;
      print "${$a}[0] and ${$b}{A}\n";
  }

  my @a = (1);
  my %b = (A => 2);

  stuff(\@a, \%b);
Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections.

The difference I see, as a Perl newbie only working with it out of necessity, is that having (because you need it because of earlier design choices) more than one way of operating on data structures, violates the principle of least surprise.

Re: Why Perl Didn't Win

#53

Earlier quoted context omitted.

Your reply makes no sense to me I'm afraid. > And I didn't realize the well written Perl code compiles equally better. Equally better? > And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class. Come on, seriously. Here's how I open files in Java: import com.google.common.io.Files; List lines = Files.readLines(new File…

On the one hand, that's a pretty cool library. (with a function to emulate back-tick into an array) On the other hand, now I have to go to the Enterprise Committee with a Permission To Install Library Form to get it, since it's not part of the base language. It might well be worth it to use Google's jar, but it's a delaying nuisance.

> On the other hand, now I have to go to the Enterprise Committee with a Permission To Install Library Form to get it, since it's not part of the base language. It might well be worth it to use Google's jar, but it's a delaying nuisance.

Argh, same straw-man again mate.

Re: Why Perl Didn't Win

#54

Earlier quoted context omitted.

Ahd in Common Lisp, EQ, EQL, EQUAL, and EQUALP. See http://www.nhplace.com/kent/PS/EQUAL.html for an explanation of why.

Mistakes from other languages are still mistakes. One could try to call them tradeoffs rather than mistakes, but then you'd have to explain why the programmer benefits from such circuitous thinking.

I don't think that one is a mistake. At least, if it's a mistake, it's not a mistake in the equals operator. PHP attempted to use one set of comparison operators and the fallout has been far worse: there have been security problems due to the semantics of PHP's == operator attempting to guess whether to perform string or numeric comparison when doing password comparisons.

The mistake, if any, is that numbers and strings are unified into one scalar type in Perl. This allows some tricks, such as being able to use sprintf to perform rounding, but it has fallout in other places in the language, such as here. Given that numbers and strings are unified, having two operators for comparison is the correct decision: it makes the semantics much simpler by having the language not guess which kind of comparison to perform.

Re: Why Perl Didn't Win

#55
post #37

Earlier quoted context omitted.

Your reply makes no sense to me I'm afraid. > And I didn't realize the well written Perl code compiles equally better. Equally better? > And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class. Come on, seriously. Here's how I open files in Java: import com.google.common.io.Files; List lines = Files.readLines(new File…

[deleted]

1) It's a library, there's no need for One True Library. Especially not in a Perl thread (CPAN is awesome). You use whatever works best for you. 2) Caught and re-thrown as a RuntimeException by the library. 3) No idea, but if I need that low level of control, I wouldn't be using a readLines convenience method. 4) Like you can pass files as a parameter, and create lists of them to iterate over.

5 - 8 are a different problem domain. But I was merely answering your hundreds of lines to read a file straw-man. I never suggested Java be used as a scripting language, if you really want to script on the JVM, use Scala, Groovy, Clojure or Kotlin.

But personally, I script in Python. Let's resurrect that old pissing match with Perl. ;)

Re: Why Perl Didn't Win

#56
post #37

Earlier quoted context omitted.

Your reply makes no sense to me I'm afraid. > And I didn't realize the well written Perl code compiles equally better. Equally better? > And its certainly a lot easier to open files and do things in Perl than writing several hundreds of lines just to set and get variables for one single class. Come on, seriously. Here's how I open files in Java: import com.google.common.io.Files; List lines = Files.readLines(new File…

[deleted]

So, I actually have no love for Java, and am greatly enjoying the higher proportion of scripting irb been up to lately. But I had to comment on a couple things:

> Why only that library...? I've seen it all when a Perl developer is calling out a Java developer regarding TMTOWTDI. Nice library though.

>I would like to execute some shell commands Not sure comparing to a language with an explicit complicit compilation step is fair.

Re: Why Perl Didn't Win

#57
post #36

I suspect that all the languages that are "winning" right now will have "lost" 10-20 years from now too. What's the longest lived language out there right now that's actually still in heavy use? I'd say C. But C has clearly fallen from its position of complete dominance when every new project was written in C (because it was much easier than writing assembly). C++ had its day as well and lives on in many places, but…

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 used in many places just because of hardware or time constraints -- drivers, micro-controllers, optimized fast parses, low level socket handling code. It just got specialized. Not used probably for business or back-end systems.

I don't think PERL can claim that same. It seems to me its role has been replaced by Python, maybe Ruby, Java (for web server back-ends).

C++ still winning. None of the current languages including the new contenders like Rust and Go can eat its lunch (as they say) when it comes to performance. Things like games or signal processing. Anything requiring low latency responses will still see C++ being picked. And with C++11 and C++14 it is getting a new breath of fresh air. Whoever is going to contend with, will have a steep hill to climb.

Java? Java still winning. Now if you think of Java as JVM it is winning even more. Java itself if just a very average language that is also fairly performant, explicit, IDE friendly. If you had a lot of money and could hire potentially lots of average or below average programmers to throw at a problem (which I think often is the wrong approach, but if you did), Java is your language. And Android. Don't forget Android. If anything it is winning just because of that.

> Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect we'll see a "Why Ruby Didn't Win" in 10-15 years too.

I think it replaced PERL by in large and but now it is feeling the heat in a lot of areas where it was being used. Scientific community has Julia as a new kid. Server back-ends have Go and Javascript. Not one big threat but little paper cuts here and there.

Ruby, I am not familiar with it much, from my outside perspective it looks like a one-trick-pony = Rails. If something replaces or obsoletes Rails, I don't see Ruby rising and finding a niche. I could be wrong, so anyone please correct me here.

Re: Why Perl Didn't Win

#58

Earlier quoted context omitted.

--- Java --- List aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably missing some more type stuff in Map aMap = new HashMap (); aMap.put( "name", "Joe"); aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la Groovy... doSomething( aList, aMap); ... void doSomething( List aList, Map aMap) { System.out.println( "First: " + aList.get( 0) + ", Name: " + aMap.get( "name") ); } --- Perl --- &do…

I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier. No final "right" or "wrong" choice for all use cases.

> I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier.

I would agree. It's the same issue Scala faces IMO - it doesn't have to be a complex maze of types and implicit conversions and implicit values, you can, if disciplined, write very understandable and clear Scala.

Sadly though, it seems a lot of developers aren't disciplined.

Re: Why Perl Didn't Win

#59
post #51

Earlier quoted context omitted.

But in those languages, the equivalent to ($x == "foo") will return false (almost) all of the time. The poster here says that this expression is true (almost) all of the time in Perl. Why?

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?

After learning Haskell, I'm not sure what the benefits of dynamic typing are anymore.

Re: Why Perl Didn't Win

#60
post #57
post #36

I suspect that all the languages that are "winning" right now will have "lost" 10-20 years from now too. What's the longest lived language out there right now that's actually still in heavy use? I'd say C. But C has clearly fallen from its position of complete dominance when every new project was written in C (because it was much easier than writing assembly). C++ had its day as well and lives on in many places, but…

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 'Whatever happened to X which was famous $current_years - 5 years back?'

Please note all the focus is around the new technology. Some one is writing a new library around this new DB technology some one is using and is writing about it. Some one just gave a talk on how some scalability problem was solved by a specific feature in the language. Some one just talked about how testing got easier, some one writes about how maintenance efforts got reduced because of a new way in which language deals with type declarations, Or some programming forum is full of questions and the Google auto suggests can tell you your question as you are typing it.

Meanwhile some where in a MegaCorp, your maven can't see beyond the company in house repo. And using a different library takes 3 months of permission cycles. People sitting in there don't get interview calls and hear about people saying that the old technology isn't hip any more.

Only thing that is buying Java some time is the large quantities of enterprise code, which no one has the money to replace.

Post reply on HN