At 11:59 PM 12/22/2003 +0100, Elizabeth Mattijsen wrote:events or whatever, are an integral part of the system. What Perl, Python and Ruby programs do now, should carry less weight than what all of these systems, and who knows what other languages that want to build on top of Parrot, want to be able to do in the future.I don't see how you can decide to attribute less "weight" to what Perl, Python and Ruby programs do now.
Well, that argument goes the other way as well. I don't see how Dan can decide to attribute more "weight" to single threaded applications. Apart from the fact that Dan can and will do that, if he feels so. ;-)
Most programmers I know rank speed-of-prototyping and reduced line-count as their favorite things about
the aforementioned languages.
No argument here.
People will not migrate from Perl 5 to Perl 6 because it will be able to run the same application faster. If that iis the goal, you get bigger hardware and your done with much less fear of migration problems. People _will_ want to move from Perl 5 to Perl 6 because of:Lots of companies are still developing on the same hardware they were before Y2K. I'd bet they would welcome a
Perl implementation that got them 3-4x speedup for free for new code. I will agree with you on legacy Perl apps, as most
of my clients are exactly as paranoid as you describe.
And rightfully so. Which in my book means that they will not migrate to Perl 6. Hell, they even haven't migrated from Perl 5.00503 yet. You expect them to migrate to Perl 6? On a brand new VM?
I think it is unbalanced to regard threads & context-switching as the most important aspect when dealing with languages that- good threads support - good signalling support - good event handling support All of these more or less need a system that can quickly switch context.
do not lend themselves to optimization and static compilation.
And I think that would be exactly the reason why Parrot would stand out in the crowd.
If you really want reliable signal handling (to the point of worrying about context switch overhead, we begin to sound
like we want a real-time OS and language), then you (at least currently) don't write it in Perl/Python and _especially_
not Ruby. You write it in C/C++/Java/Objective-C, take yer pick.
And it's the "currently" I would like to see change. We're working for the future here, right?
I think we need a change of mindset. Instead of seeing threaded programs as the special case, we would need to see that the single threaded program is the special case. See how many people use POE for event handling, and through what hoops (Perl) Tk needs to jump through to get proper event handling.I don't think we are of the mindset that threading is so special and rare that we will force threading programs to suffer in pain.
I don't see optimization like that. When Dan says we optimize for a common case, it doesn't mean the uncommon case
won't be greatly improved as well. I expect any implementation of Parrot to run single & multi-threaded programs many times
faster than the Perl5 engine.
I have no doubt about that. Running threaded applications faster than Perl 5's ithreads, is however not a big target ;-). Perl 5's ithreads are great for turning applications with a fork() mindset to using threads. They are _lousy_ when trying to run applications with a threaded mindset.
Ever tried starting more than 100 threads with ithreads? It takes several _seconds_ on state-of-art hardware with any kind of real setup. Which is basicallly what is killing mod_perl with other than prefork MPM's.
I think I agree with you in spirit, that we should have high expectations for Parrot and hopefully make the scripting
languages that we are running more realistic as all-around programming languages.
Eh, I think you should cross out the "hopefully". It is Larry's intention for Perl 6 to be a language for the next 30 years (IIRC). I doubt he meant it as just another "scripting" language.
I see Parrot as an effort to
close the gap between Perl/Python/Ruby and C#/Java on the exact same hardware, since significant advancements in
execution speed by the Java and C# implementations are pretty unlikely. (They are already pretty fast)
I think you are thinking too short term in that respect. ;-)
Liz
