Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: NO PERL 6

by BrowserUk (Pope)
on Dec 09, 2002 at 05:39 UTC ( #218454=note: print w/ replies, xml ) Need Help??


in reply to NO PERL 6

It's a real shame you didn't take the time to express your doubts regarding the Perl6 proposals so far in a more coherent fashion.

You are not the first person I have heard who has their doubts, and some of them are people with considerable knowledge and experience of Perl-to-date and many of the other languages upon which it draws. Had your start been more coherent, it might have brought out some of the concerns which others have alluded to but not fully expressed, at least not on this site that I have seen.

If you know anything about the Perl language history, you would realise that it already draws upon many other languages for its syntax. From Dec Basic Plus from way back when, to C, Lisp(ish) stuff, to shell scripts and utilities like Awk and SED and many more. What makes perl the language it is today, is the rational approach that has been taken down the years to include those features that are useful, adapting them where possible to fit the general feel of the rest of the language, but not getting bogged down with trying to become the "perfect language"; be totally orthoganal; be complete in some academic way (like Pascal and its Backaus-Naur language definition, smalltalk with it "everythings an object" or Java with its strong typing).

The thing that makes Perl unique among all of these are the basic premises upon which it combines all these seemingly disperate features.

You yourself note that there is room "...to improve perl5...". I think that most people that use perl 5 have there own set of improvements that they would like to make. I do. For some it would be to remove some of the scarier DWIM features, others to increase the orthoganality of the built-in routines. Some would like to the ability to curtail its propensity for trading space for speed. And yet others would like to discard some of it legacy features or improve its built-in support for OO.

From what I've read, most of these points and many more have been raised for consideration in the development of Perl 6, and its now up to Larry Wall and his team to sift through these RFC's and sort out which ones should be taken forward and which ones are best discarded. I seriously doubt that if you put any 10 Perl people in the same room and asked them to put ticks or crosses against the RFC's being considered that you would get any 2 that would agree, never mind a concensus. Given all the different directions that the language could be pulled in, it is going to be a monumental task to sift through them and arrive at a cohesive end product that remains true to the basic premise of Perl. However, given that LW got the language thus far, it seems impertanent to pre-suppose that he will do any less good a job than he has done till now.

You say that "It should be started from scratch...". It has been hasn't it?

Personally speaking, if Perl 6 aquires some features from either or both Python and/or VB, I would not be at all disappointed. Both languages have some features that I think could be useful additions to Perl. Especially if they are adapted to fit with the DWIM nature of existing perl constructs and features.

For me, the thing that sets perl apart from most of the other languages I have used is that with very few exceptions, whatever I try to do with it, once I find the right one, it seems to have a feature, construct or idiom that seems to be specifically designed to deal with my particular problem in a concise and efficient manner. A few notable exceptions are

  1. A case statement.
  2. A mechanism for constructing portable, standalone applications
  3. A concise and transparent mechanism and syntax for defining and constructing objects.
  4. I'd also like to be able to nest statement modifiers. This was possible in Basic Plus II which was the successor to the original insiration for the modifier forms of if, while, and for.
  5. I'd also like to see the ability to use anonymous code blocks as the first argument to a sub extended to the general case for all arguments, and in other situations.

I'm sure others would argue against some of these, and would add their own. Some of the above are muted for inclusion. Others may just be to far of the scale. Whatever the final decisions are, I'll make my judgement on whether I think they were the right one's once they have been made. You might like to try the same tack.


Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.


Comment on Re: NO PERL 6
Re^2: NO PERL 6
by Aristotle (Chancellor) on Dec 09, 2002 at 10:05 UTC
    One thing most everyone with objections to Perl 6 seems to overlook is that it will allow the programmer to actively interfere with the parsing and compilation: the Perl 6 grammar will be available as a built-in Perl 6 pattern grammar and we'll be able to work on the underlying Parrot VM level. It may be awkward at first, but so was source filtering in Perl 5, and that has been addressed by way of modules, some of which made it into the 5.8 core.

    I am wary indeed of the possibilities for abuse this opens up, much like define macros offer in C, but on the other hand I shiver (with anticipation) to think what the likes of TheDamian will be able to do this way.

    In addition, I'm fairly certain that if Perl 6 gets something wrong in a way most of us dislike and which is fixable by way of such low level interaction, then a module or several will sooner or later be written and, if they meet expectations, be widely adopted by the community.

    I am, surprise surprise, not 100% satisfied with all of the proposed changes for Perl 6 myself but I quickly got over my fear. For one thing, I realized that many features in Perl 5 must have looked just as bizarre to the Perl 4 crowd, meaning I will likely get used to the "strange" stuff and eventually take them for given. And ever since Apocalypse 5, I'm absolutely optimistic that if there's anything I feel is really awful, I will be able to fix it for myself - the sky is the limit. That, and your imagination.

    Makeshifts last the longest.

      It's my understanding that Perl 6's syntax mutation capabilities will be a good deal safer than using C #defines. In fact, I'd argue that the current state of the Perl syntax munging art, Source Filters, are more like C macros than Perl 6 rules will be. Perl 6 rules are so much safer, they take away the need to do your own (possibly fallible) parsing of Perl source code, you just modify the rules at the appropriate level in the grammar and away you go. Also, rule based syntax modification is lexically scoped, which is definitely handy...

        I was referring to abuse, not robustness. Like any other form of syntax or semantics alteration (operator overloading comes to mind), there are good reasons to have the opportunity (operator overloading comes to mind), but making use of it just because you can will easily create a maintenance nightmare (operator overloading comes to mind). And operator overloading is a relatively mild form of this. Perl 6 will allow really drastic interventions.

        I am excited about the possibilities, but I hope people use the opportunity carefully. It'll most likely turn out to be one of those things you should not do unless you know why you not.

        Makeshifts last the longest.

        Also, rule based syntax modification is lexically scoped, which is definitely handy...

        How exactly is that supposed to work? It seems a bit paradoxical to me. Allowing lexical modification of the parser would have to happen at run-time; the only problem being that run-time is after compile-time :) I was under the impression that the process would be more like:

        1. The code must be in a BEGIN block or be use'd (same thing).
        2. The BEGIN block is parsed, compiled, and run with the current parser.
        3. When it is evident that parser rules are being overwritten, a copy of the parser is made.
        4. Modifications to the parser are actually made on the copy.
        5. When the BEGIN block exits, the modified parser becomes the real parser.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://218454]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (4)
As of 2014-09-22 02:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (177 votes), past polls