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

Replies are listed 'Best First'.
Re^3: Slow evolution of Perl = Perl is a closed Word (thread decade) by tye (Sage) on Sep 01, 2007 at 05:05 UTC
5 years? People have been trying to get decent threading into Perl at least twice that long. Bolting threading onto the side of a language that was developed in a way that is rather antithetical to threading is an extremely ugly task. I doubt you'll ever see reasonable threading in Perl 5 because I haven't seen over that decade the will to initiate the rather fundamental rewrite that would be required Perl 6 makes such a fundamental rewrite within Perl 5 even less likely A decent threading model was attempted for many years and eventually abandoned as impossible and replaced by a horrid threading model that had a better hope of one day becoming stable, if no hope of ever becoming a particularly good way of doing threading. So the hope for decent thread support in Perl is simply Perl 6. - tye	[reply]
Re^4: Slow evolution of Perl = Perl is a closed Word (thread decade) by Joost (Canon) on Sep 03, 2007 at 21:38 UTC
My gut feeling is that perl 5's threading model is probably the best possible, given all the constraints (i.e. backward compatibility). The problem with it, as far as I can see, is that the API is quite terrible (especially the perl side of things; it's probably easier to write complex pieces of a threaded perl application in C/C++). My main problem with it is that there is no common way of creating shared/shareable, object oriented libraries. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^5: Slow evolution of Perl = Perl is a closed Word (thread decade) by BrowserUk (Patriarch) on Sep 03, 2007 at 21:53 UTC
My main problem with it is that there is no common way of creating shared/shareable, object oriented libraries. Two questions to ponder: Why is sharing objects in perl verbotten? What could be done to alleviate that restriction? If I told you that there is a simple mechanism that allows most form of perl OO to work as shared objects, without imposing the high cost of proxy object solutions, would you be interested? Would it change your mind about the efficacy of threading in Perl 5? Or would some other reason to dislike them come to the fore? 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^6: Slow evolution of Perl = Perl is a closed Word (thread decade) by Joost (Canon) on Sep 03, 2007 at 22:12 UTC
Re^7: Slow evolution of Perl = Perl is a closed Word (thread decade) by BrowserUk (Patriarch) on Sep 03, 2007 at 22:24 UTC
Some notes below your chosen depth have not been shown here
Re^3: Slow evolution of Perl = Perl is a closed Word by Joost (Canon) on Sep 03, 2007 at 21:57 UTC
As I said, Perl 5 in my opinion is impossible to be really parsed without run the code. This is way I still wait Perl 6, that is not so dependent of runtime states to define code. Perl - like many other "dynamic languages" - is just too flexible to be statically analyzed with certainty. This is not a parsing problem. LISP (which famously has "no syntax" and is completely trivial to parse) has the same issues. Consider this: `my $method = "method_name"; for my $class (qw(Class1 Class2 Class3)) { my $object = $class->$method(shift (@arguments)); }` [download] Now consider that all the string literals in this code are just strings, and can come from anywhere else, including files, databases, user input etc. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l]