Re^4: regarding intolerance to perl which I observe

[curiousmonk]

That note from Paul Graham, is not about using 'Perl' in specific. He seems to be trying to point out the fact that technically oriented people, will tend to use the current set of non-mainstream technologies against the current enterprise trends even if they are relatively new. If you apply that line of thinking. Python/Perl are the new C++/Java of our times. C++/Java have graduated to COBOL level ancientness by now.

Yes, Perl is still awesome. But the world now takes many things we offer for granted, Because nearly every half decent language these days has those features. The situation is not like what it was 20 years back. We have some marginal advantages over other languages, in the exact same way they have some other advantages over us. But its not like what it was 20 years back, where Perl was the only alternative available.

The situation with many other languages like Python is no different. And they too losing users to languages like Go and Scala. But just like how CGI, gave Perl some breathing time. So will Django and Rails give Python and Ruby some breathing time.

We have nothing radically new to offer for years now. There is incremental development. But that is that. This is really the reason why Perl 6 is all the more so important for Perl.

[Your Mother]

What do you see as the radically new features Go and Scala have? And what do you see as possible with Perl6, in theory, that isn't possible with Perl5?

[fisher]

well, I think I can answer that question of yours since I agree with what previous orator has stated.

I personally don't know Go nor Scala, but I know Erlang and a bit of Haskell. Well, everything you can do in Erlang you can also do in perl, but! But some things will be easier to do in erlang, for example, to spawn a pool of thousands of processes for almost every client.

If you need an example of the radically new feature -- how about the well-known statement that 'if it compiles, it works'? This became possible because of strict typing plus pure functional approach in haskell. And in perl we still teaching newcomers to append those silly 'use strict; use warnings' lines in every single script.

I personally feel the lack of pure functions in perl. I like the idea of *guaranteed* absense of side-effects when it is not otherwise stated. I like to spawn a lot of isolated workers as simple as a *click* by two fingers. And no worries about threads and shared data and all that scary stuff -- we have actors communicating with each other by sending messages to each other. 'Everything is a process' can be a motto for erlang.

But despite of all that said above there's still a niche for perl. When I want, for example, to analyze the web server's output, or gather some data from logfile or even do some sketch on 'how it should work' using FCGI + nginx -- I don't know the better tool than perl for these kind of task.

Well, soething like that.

[Your Mother]

The operative term in the original statement and the follow-up question being "new." Haskell is almost the same age as Perl, as is Python and Ruby is just a few years younger. Either these things were always a better choice than Perl and Perl's success is just some bizarre aberration or Perl is still just as valid a choice. And Erlang is optimized for a very specific use case. I wouldn't attempt to use perl to parse client side DOM either. I looked at Scala the smallest bit a couple years ago and nothing leapt out to distinguish it. On the contrary, it seemed Perl-like without as much flexibility. Which obviously some feel is a strength. I disagree.

Use Perl for what you want. Call it a niche tool if you prefer. If you find general attitudes to Perl to be "it's no good," don't expect your attitude to do anything but cement the views. Well, sure it's okay for prototyping web stuff but why go to all the trouble to learn such a messy, goddawful language just do hello world in a webpage? I mean, you can parse a log file with awk."

I use strictures or equivalent in scripts. I also write one-liners all day. If I had to qualify variables and namespaces and return values and… for them, I'd start looking for another tool. Perl lets you be a lousy hacker without complaint, it's true, but it also doesn't get in your way at all when you know what you're doing. Professional tools have fewer safety features than kids’ toys and institutional, packer-oriented workflows.

Happened across this yesterday right after commenting in this thread and it seemed very pointed to me–

With regard to the “wrong equipment” … Unlike most musicians, Josh Homme doesn’t just dabble in a bit of engineering when necessary, but has a genuine love for the métier. “I love [music] engineering… …I found over the years that if everyone is using something, it can’t be that good!” soundonsound.com/sos/feb10/articles/homme.htm

[tobyink]

"If it compiles, it works" is a pipe dream. "If it compiles, then it will do something" is probably the best we can hope for. Strong typing isn't enough to prevent logic errors.

[curiousmonk]

In theory anything possible in one language is possible in other languages too. But by that argument you could also say anything possible in perl, can be done in C. Going by this line of argument, we may have to settle with using NAND gates.

Given how much the JVM has become important in the enterprise, something like Scala makes a perfect fit for a Java replacement. And those people who have used Scala generally say it preserves the spirit of 'TIMTOWDI' while staying good at strong typing, OO and functional paradigms.

Languages never really drop dead! But they slowly drift into getting irrelevant by the day.

[Anonymous Monk]

I rather read his article as "if you choose tools/programming languages that are the industry standard, you get industry-standard employees and industry-standard (=average) code; if you choose tools/languages that are the exception, you might get exceptional code."

Basically, one type of employer is playing it safe and the other is taking a gamble.

[Your Mother]

His language was clearly pushing for the opposite: not a gamble or an experiment but evidence suggesting the competition might have their hackt together. No one is afraid of experiments in the private sector (unless they are backed by a good lobbyist and the funds to make everyone a loser). They are costly and terrible, terrible odds.