NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
making hard things easier (Score:1)
I tend to think of this along the lines of "making hard things easy and impossible things merely hard". With that in mind, the frontier has shifted since Perl was developing rapidly.
My gut feeling is that the "wow" factor has become harder for Perl to achieve because what wows people isn't insanely great string, dataset and administrative task manipulation. People want to see results quickly. That's not just about the learning curve -- it's the end-to-end process.
Part of the advantage of Java in an educa
Re: (Score:2)
On parallel processing:
No dynamic language has found it yet. Even 2 full time Google engineers have failed to find it for Python [google.com]
CPython has a Global Interpreter Lock, single threads the interpreter, and hence single threads compute intensive task. [C]Ruby has "green threads" (i.e. it does the thread scheduling). There's no prior art. There's no proof that the problem even has a solution.
Re: (Score:1)
Re: (Score:2)
Sorry, I wasn't clear enough. My fault. Prior art for a dynamic language implemented in C. Clojure is a dynamic programming language that targets the Java Virtual Machine. (To the best of my knowledge) Jython does threads just fine - it's CPython that can't, and even the folks at Google working on Unladen Swallow can't see how to take that Jython know-how and port it to the C implementation.
Re: (Score:1)
Re:making hard things easier (Score:2)
Good point.
Sadly, once again the punchline from the "Irishman giving directions" joke bites:
Reply to This
Parent