Re: Slow evolution of Perl = Perl is a closed Word

in reply to Slow evolution of Perl = Perl is a closed Word

A good IDE, like Eclipse for Java.
Good multi-threading.
Standard and rich GUI.

These are very superficial reasons against a language. IDEs are a matter of personal choice. Multi-threading is being worked on, and is of limited use for web apps anyway (even on multi-core processors). GTK2 is pretty good for GUIs and works pretty well across platforms, with a few other choices beyond that.

If I was going to bother moving to a new primary language, it'd better offer something clearly superior to Perl. The kind of stuff that's been kicking around CS departments for a long time, but has barely registered in mainstream languages. Stuff like type inferencing or operators in RPN notation. If the language isn't going to challenge me to learn new concepts, it's hardly worth learning.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Comment on Re: Slow evolution of Perl = Perl is a closed Word

Replies are listed 'Best First'.
Re^2: Slow evolution of Perl = Perl is a closed Word by Anonymous Monk on Sep 01, 2007 at 03:37 UTC
"Multi-threading is being worked" Is in working progress for years! How many years we will need to wait to have a good multi-threading model on Perl? I just have waited to much!	[reply]
Re^3: Slow evolution of Perl = Perl is a closed Word by erroneousBollock (Curate) on Sep 01, 2007 at 04:09 UTC
Is in working progress for years! How many years we will need to wait to have a good multi-threading model on Perl? I just have waited to much! I won't pretend that support for robust threading is well implemented in perl5... it's just not. However, Java's concurrency is not exactly all that. I'd say that Java's concurrency primitives (and the design patterns programmers build on them) are the state-of-the-art circa 1997. There are wonderful new ways to think about (and express in code) concurrency that are only really supported well by languages like Erlang, Haskell and Scheme (please let's not have an argument about Scheme). Java's concurrency primitives are concise, robust and orthogonal for the Java language but do not necessarily map well to languages with (encouraged) abstraction techniques based around closures and/or first-class functions. I (and many others) agree that perl5's support for threading needs serious work (looks like progress in Parrot/Pugs is good in that area) and that increasingly, folks will focus on concurrency as a dealbreaker, what with 4, 8 and more cores becoming the norm any-time-now. If you're concerned about writing good, concurrent, perl5 code today, you might try designing your code around message-passing (look at Thread::Queue) as in Erlang, as this works well in practice. -David	[reply]
Re^3: Slow evolution of Perl = Perl is a closed Word by chromatic (Archbishop) on Sep 01, 2007 at 06:28 UTC
How many years we will need to wait... I suppose that depends on how many more years you're willing not to contribute somehow to getting a good multi-threading model in Perl. Things don't get done unless someone does them. Sometimes that means people that want them have to take some initiative in getting them done.	[reply]
Re^4: Slow evolution of Perl = Perl is a closed Word by BrowserUk (Pope) on Sep 01, 2007 at 07:24 UTC
I suppose that depends on how many more years you're willing not to contribute somehow to getting a good multi-threading model in Perl. The first step in achieving a good threading model is understanding the limitations of the existing one. And the first few steps in doing that is realising that: the pthreads api has its own set of limitations and is far too low-level to use as the basis for threading in a HLL. fork is a piss poor model for threading. Copy On Write (COW) has little or no benefit when the C-level data structures representing Perl-level read-only variables are themselves routinely, internally mutated. for threading to be fully effective in a high level language, you need both kernel-space (pre-emptive) threading and user-space (cooperative) threading. Software Transaction Memory (STM) only works for undoable (re-startable) operations. If STM is the only state-sharing mechanism, then a very high proportion of the situations and algorithms that most benefit from threading can no longer be coded! You can't undo changes to the file-system, so copy, move, rename, delete etc. Whilst it is conceivable to wrap these FS primitives such that they might be undone if the STM requires rollback, other processes may have noticed and acted upon the changes You might attempt buffering reads and writes to files internally, until the STM commits? What do you do for pipe and socket operations? STM promises an efficient solution to shared-state memory operations which can benefit some classes of algorithm (the kinds of things PDL does for instance), but it holds little promise for a huge range of other threading scenarios. Did you ever visit one of those Echo Canyons, yell, and wonder if anyone is listening? Did you ever stick your head into a lion's cage to try and pursuade it to become a vegetarian? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^5: Slow evolution of Perl = Perl is a closed Word by chromatic (Archbishop) on Sep 04, 2007 at 04:53 UTC
Re^6: Slow evolution of Perl = Perl is a closed Word by BrowserUk (Pope) on Sep 04, 2007 at 09:31 UTC
Some notes below your chosen depth have not been shown here
Re^4: Slow evolution of Perl = Perl is a closed Word by spx2 (Deacon) on May 07, 2009 at 16:49 UTC
I disagree , some people don't have nearly enough knowledge to implement threads into Perl , telling anyone who wants threads that they should simply implement them is rather dangerous and possibly disastrous(considering that person may not be an expert on the subject , and maybe some people want to write industrial-strength code using Perl threads and don't need amateurish implementations of them ). From another point of view , many people just want to use threads , they don't need to implement them for that , they just want to USE them. It's a basic language feature for any decent language ( yes we're in 2009 ) and it's only normal to expect that Perl should have them . It seems most of the times , this is countered by an argument of the form "you don't really need threads, use POE" , which is ok , but that was not was asked in the first place .	[reply]

In Section Meditations