Re^6: The current state of Perl6

[BrowserUk]

I see no aplicability for scale, speed or technical feasibility here

If the Mahattan Project had use Waterfall, it would never have started, because you cannot specify that which you do not know how to do. Or even know if it is possible; eg. its technical feasibility.

You have to experiment (prototype), and feed what you learn back into the spec, and use it to choose the direction of your next level of experiment. Waterfall doesn't allow that. Waterfall is useless. Period.

Just in case, as seems likely from your rather incoherent post, you've misunderstood my post to which you replied, I was supporting the P6 cabal against the notion that they should have finished the spec before starting implementation.

And to put this firmly into the world of reality rather than speculative theory, here are a couple of unknowns from the more tentative parts of the P6 spec, that simply cannot be answered. Neither from the existing knowledge within the designers/programmers heads, nor from the existing research literature:

• What is the likely net affect upon application code efficiency, of multiple user-space, cooperative concurrency schedulers, interacting with the kernel space pre-emptive scheduler?
• Can Software Transactional Memory be successfully and efficiently implemented in an on-the-fly compile & interpret environment?

  Ie. Outside of the auspices of the deep analysis available to compile-to-native code, strongly & statically typed, pure functional language compilers.

Whilst both those concepts are named in the Parrot/Perl6 specifications, they are, as yet, absent from the implementations, because there are no answers to those questions in the existing body of knowledge.

One can speculate on the basis of knowledge of existing similar concepts, but until someone actually tries to implement them, and use them in a real-world environment, all such speculation is just that, and nothing more.

As such, Waterfall's only answer to these parts of the requirements, would be to omit them completely from the specification.

[Anonymous Monk]

yes I would completely omit those. because I'm not sure how rewarding it would be after 5 more years of Perl 6 coding to see that the time spent proves to be worthless.

The idea is, let the people who have money to invest and spend in stuff like Haskell and Java compilers experiment all they want, learn from their mistakes (which you cannot possibly reproduce in a useful timeframe with a handful of people who are developing today on Perl6) and use what you've learned so far in your compiler.

Since it is year 2010 I doubt that each and every feature of what you mentioned is novel. Actually, I'm sure it has been implemented in some compiler somewhere. The Perl6 team needs to find all of those and see how succesful they have been without the effort of implementing them. This is all a question of time, if you waste the precious time on useless things the failure will be of epic proportions.

[BrowserUk]

yes I would completely omit those.

And how important, successful, long-lived do you think a language will be in 2010+--the age of 4/6/8/12 core commodity hardware--without the ability to make use of concurrency?

[Anonymous Monk]

I question your belief that concurrency implies the success of a language. Let's consider the case of Erlang. It has the strongest implementation of concurrency. I do not think it has been very succesful. I do not see Erlang adopted everywhere just because it can do concurrency well. In fact, C and C++ are still widely used for it.

There is a well-known myth in the Perl community that threads are the worst possible thing, however that is because Perl programmers which deal mostly with web programming don't study threads well enough so of course they cannot use them. As a retreat, they use POE instead which is not real concurrency.

They hide behind excuses of the form "threads are too complicated for the human brain". That is of course complete nonsense because threads are well studied and can be learned, but what can you ask of web developers who deal with CSS , Javascript, HTML. They concentrate on completely different things.

But let's return to Perl 6, Parrot does not support concurrency. Let us suppose that concurrency will be implemented. Who would use it ? Since most Perl programmers already have the prejudice that threads are evil and bad.

Let's also consider another aspect. As it stands today Perl is mostly used by sysadmins(although I do not like to say this), what use would sysadmins have for concurrency. Most sysadmins are not well-trained programmers.

I think you should not assume oppinions of people who evangelize a language or the other. Instead you should judge them with your own mind and see for yourself if they have been adopted or not.