Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
There's more than one way to do things

(A6) Perl 6, a general-purpose language?

by crenz (Priest)
on Mar 10, 2003 at 22:48 UTC ( #241865=perlmeditation: print w/ replies, xml ) Need Help??

The most reassuring sentence of A6 IMHO is

You're not expected to understand all of that yet.

;-) Some of the syntax Larry presents looks quite frightening, but it is good to remind yourself that a lot of it is optional. I guess for 80% of bread-and-butter scripts, we're going to use 20% of the material in A6. But it is good to see that Perl 6 will allow me to write anything from Lispish to C++-ish code.

I admit that I haven't followed the process behind parrot too closely. But I am getting the impression now that Perl 6 is strongly headed towards becoming a general-purpose language, like C/C++/Java. The two most important indicators for that are IMHO code optimization and JIT compilation in parrot (see python bet :)) and detailed type system and subroutine signatures in Perl 6 (which means that "XS" will probably directly be implemented in Perl 6). Of course, at the same time, Perl 6 tries to cover niches as well, for example with it's new regex syntax.

Am I too hopeful in assuming that the Perl 6/Parrot guys are actually creating something that will be in many areas as fast and flexible as the abovementioned languages or better? Will we be writing KDE apps, kernel-mode drivers, COM objects and web browsers in Perl 6? Or is this something so blatantly obvious I should have noticed it a long time ago?

Let me restate my original thought: The one thing that really excites and keeps me from despairing when seeing all that syntax is that essentially, Perl 6 will still be a simple language. You'll be able to use just what you need, just like with Perl 5. I like that.

Comment on (A6) Perl 6, a general-purpose language?
Re: (A6) Perl 6, a general-purpose language?
by chromatic (Archbishop) on Mar 10, 2003 at 23:09 UTC

    I'm not sure I understand you correctly. You explained that optimization counts. C and C++ don't have JIT in their most common forms, as far as I can see. Do you mean that Perl isn't as fast as C and C++ in some domains?

    Detailed typing is harder to understand. If anything, I think the type system in C and C++ is one of the worst features of the language. To do anything useful, you're forced to cast willy-nilly. The templating system in C++ is a symptom of the problem. It's a combinatorial explosion based on exposing low-level implementation details. (I think this may be an example of premature optimization -- by forcing you to commit to an int early on, you're restricted in what you can do in many other places around the source code. You can guess at what you'll need later, but if you guess wrong, you have to make a lot of changes, so you'll end up hedging your bets or editing a lot of code or sucking it up and living with your limitations.)

    Java's even worse -- it suffered along without templates for years and years. How long did it take before you could put an object in a container without having to upcast? You could also look at all of the work you need to do with the Reflection API to do something like a Factory pattern.

    This is turning into a rant on a subject which many people have strong feelings (and I really don't want to debate the benefits of strong versus weak, static versus dynamic typing here!). I'll try to sum up.

    In my opinion, Perl is already a general purpose language. There are several benefits of Perl 6 that improve its position: easier distribution of code, easier embedding and extending semantics, improved performance through Parrot, and higher-level programming constructs.

    If anything, I'd much rather use a dynamically typed language as a general purpose language.


      Well, yes. There was yet another discussion about it recently (Confirming what we already knew). A6 made me wonder whether debates like that one might actually go away (well, they never will, but they might become more pointless).

      Update: C/C++ already does produce optimized native assembly code. Java IMHO becomes more useful through JIT compilers. I hope the same thing for Perl 6.

      Detailed typing is harder to understand.

      I'm not saying that I like the type system in C++ or Java. And if you got the impression I want Perl 6 to be like that, I certainly expressed myself in an utterly obfu way :). What I mean is that things like interfacing with system libraries usually require strict and detailed typing. So far, there was always a need for C to do it. I wonder whether the goal is actually to eliminate the need for C for these purposes and do it all in pure Perl 6.

      In my opinion, Perl is already a general purpose language.

      Well, we still see a lot of software nobody would care to write in Perl. (I mentioned some examples.) I'm not really saying that Perl should become a language you can write an OS in, I'm just wondering where we are heading.


      I agree. Strict typing (hopefully) is going to be the exception. But sometimes, you need the exception.


        Good, because anything you can write a half-decent operating system in is NOT a general purpose programming language. It would be far too low-level to be useful.

        Perl, on the other hand, is definately general purpose. If you want evidence of this, look at the CPAN. Image/audio manipulation to web crawling to processing hundreds of file formats to cgi scripts to mod_perl to natural language processing and back again. If that isn't general purpose, what is?

      You should not take the 30 years old "type system" you get with C++ or Java as an example of a strict type system. There are much much better ones. Look at ML or Haskel or ... These are general enough that you do not need to bend backwards (ie. typecast) all the time to get anything done.

      If Perl6 stole from those, including stuff like type inference, you would not even notice it's suddenly strict. (Well until you'd do something spicy with eval"" of course.)


        I'd like to think my criticisms were just specific enough to leave the door open for a good strong typing system. Of course, I did write Class::ActsLike. :)

by pg (Canon) on Mar 11, 2003 at 04:36 UTC
    To me, Perl is a general-purpose language, if you look at the coverage of its function, and the coverage of CPAN modules. I see general-purpose language as a concept against specific purpose language. (Let's don't get into the discussion of the definition of general-purpose language, that could lead to lengthy but pointless discussion ;-)

    The real point is that every language has its own strength and weakness, regardless whether it is Perl, c, c++, Java, or whatever.

    As I said, Perl+CPAN already has a very wide coverage, but that does not mean Perl is the best choice for everything it covers. Whether a language covers something is totally different from whether it is the best tool to deal with that thing.

    Perl 6 will be quite different from Perl 5, and it will have a longer list of major strength, and a shorter list of major weakness. That's for sure.

    As Perl monks, obviously we appreciate Perl's strength more than anyone else does, but we should also have a clear picture of Perl's weakness, so that we are able to make the right use of Perl, and avoid forcing it into the corner.

      I can see we probably have very different definitions of "general-purpose language" :-). You referred me to CPAN. I do audio processing with perl myself, but I keep it to MIDI data. I don't think perl is fast enough to do Wave data processing in real-time, or image processing. Well, there are image processing modules on CPAN, but these are written in C, with perl glue code.

      Maybe the real problem is that I am expecting things of Perl it was not originally meant to do. For me, one of my dreams is to write well-performing desktop apps in perl*. Yes, I know about WxPerl, PerlTk etc., but I wouldn't want to use them for a major project (I know others do). I find the startup time and performance not up to what I would want it to be. The point is probably moot with modern 3-Ghz machines, but I am still working mostly on 200-500 Mhz Pentiums or G4s these days.

      *and I realize most people here aren't interested in that at all.

        Have you looked into AutoLoader or SelfLoader? Startup time of perl itself is rarely an issue - it's mainly the compilation that may take a while. Delayed loading should cure most of the problem.

        Makeshifts last the longest.

        yep, i see this as one of the weakest parts and one of the ways to boost perl usage.. I havent seen many standalone-graphic apps written in perl even that there is ports of gtk,qt,wxWindows or so...
        Probably 'cause of the lack of integrated IDE similar like Delphi/Kylix ...
        probably adding some primitives directly available into parrot can boost the thing a bit.. dont understand these things so that just mumbling :")
by pdcawley (Hermit) on Mar 11, 2003 at 10:34 UTC
    I have the feeling that I'm going to be repeating this for some time to come...

    There is a very important distinction to be drawn between typed values and typed variables. C only has typed variables; you can't look at an arbitrary C value and know its type. You can do this in Perl, that's what bless and friends are for. In Perl 6 we'll be getting a richer set of value types out of the box and I applaud that. We're also getting typed variables in Perl 6, and that's good too, for several different reasons:

    • You will be able to define 'struct' in Perl that matches an equivalent C struct, which makes life so much easier for 'Glue' writers.
    • If you want it (and I can't imagine why you would) you can go the whole bondage and discipline route and adopt strict typing throughout your code.
    • Optimizers can make use of type declarations to improve performance, so you can opt to take B&D flexibility hit only in your inner loops (or at other points where a profiler shows you have speed issues)
    Perl 6 also introduces a concept that I'll call, for the nonce, 'storage typing', which allows you to specify that a particular variable that looks like, say, a Scalar, is actually implemented by some arbitrary type that responds to the same interface as a Perl Scalar. This looks like being Perl 6's replacement for tying, and very nice it looks too.
by Anonymous Monk on Mar 11, 2003 at 14:11 UTC
    As a newcomer to Perl, I have found the language to be much easier to write and read than C, C++ or Java. I program as a hobby (was in a CS program at college, but that didn't pan out). At first I couldn't grasp some of the things (like an array, @list, being used in a scalar context as $list$i, with the dollar sign). Now, after a couple of months programming, I understand and appreciate these things. They give a contextual meaning to expressions and as long as you understand the context in whuch you're using a variable, it makes perfect sense and conveys much information to the reader. I am afraid they will change Perl to make it more 'user friendly', esp. for novices, and that it will lose some of these quirks that make it so meaningful.
      I will be grieving the loss of contextual sigils a long time, too. It's the one thing I'll dearly miss about Perl 5. However, even in Perl 5, they are not as useful as you might think - they work for all the simple cases, but unfortunately break down once you start working with references and especially with references to functions.

      Makeshifts last the longest.

by l2kashe (Deacon) on Mar 11, 2003 at 14:41 UTC
    Personally I am excited by Perl6, and a little frightened, but then again who isn't? (well maybe Larry, merlyn, chromatic, et all ;) aren't).. I think the real power of the next gen of Perl will be Parrot. That may be slightly blasphemous, but *shrug*. I haven't done my reasearch, but it would be interesting if within your perl code, instead of going to C for speed, it would be interesting if you could do something like

    use Parrot::Native; $fast_loop = sub { parrot_asm( asm_code_here; ); };
    Or something to that effect... I mean Perl can only get better as we go along. We talked about the differences for awhile now, and honestly it simply doesn't matter until we have something we can play with and work on (read bang our collective heads until the proverbial lightbulb brightens).. I have faith in the people developing the language. I truly appreciate the RFCs in the Apocalypses, because you can peer directly into Larry's thought process in regards to issues that we deal with day in and day out writing perl code. Granted the issues I run into will be entirely different than say BrowserUK, xmath, merlyn, diotalevi, ChemBoy, BazB, etc.. because I do different things with perl than they do. But all of our collective issues are being dealt with and acknowledged. Its not like they are sitting on high, banging code, and saying "O, we should do this like that" and leaving it there. They are saying, "OK, what up next? Oh, regular expressions. Ok, what RFCs do we have for this? Hrm.. Well this one addresses this, and that one that" *span of X time with indepth discussion* "Ok, this is what regexes will look like, and this is how they relate to the issues you raised, and issues that came up during our discussions"...

    </ramble> Ok so the bottom line is, Perl6 will be faster than perl5. It will provide, if you want it, better casting, and syntax notation. Alot of the issues that "real programmers" point at Perl and say "Its lousy because of X, Y, or Z" are going away or being cleaned to the point of being non-issues. Provided Parrot has been ported over to architecture A, you dont even need to use Perl6, and you will still be in good hands (provided the lang you are coding in can be translated to Parrot bytecode).. You will not have to use the new features, but you can. You don't have to give hints to the optimizer, but you can. You don't have to even write your code in the new style, as IIRC you can alter how Perl6 will read your source. So if you are really cool, read want quasi unmaintainability, you can write P5 code, but parse and convert it to P6 code during runtime...

    I mean, if they are thinking about things like being able to do that, then why be afraid they will limit the language in some other way? We have always been in good hands, and I for one will continue to have faith.

    /* And the Creator, against his better judgement, wrote man.c */

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://241865]
Approved by mjeaton
Front-paged by data64
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (2)
As of 2014-03-16 09:00 GMT
Find Nodes?
    Voting Booth?

    Have you used a cryptocurrency?

    Results (326 votes), past polls