Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Perl Programming

Perl 6 Showcase 98

maraist writes: "Larry Wall's Altanta Linux Showcase Talk on Perl 6 is now available. Highlights: Perl will be interpreted by Perl (syntax can look like any language), variables will be more localized and OO, more support of both low level and high level constructs, and the core will be streamlined."
This discussion has been archived. No new comments can be posted.

Perl 6 Showcase

Comments Filter:
  • by codepunk ( 167897 ) on Monday October 30, 2000 @07:05PM (#663790)
    It may be that every idiot that I have seen today has written shitty code. But on the other hand I have never seen python code that was not clear and understandable. My opinion is based very much on experience and not by looking at just one persons code. I would be willing to bet that I could write stuff in perl that would look very readable but I would have to go really out of my way to do it.
  • Or perl as a bastardization. Better be careful or you end up with a catch-all like PL/1 and who wants to go through that again?




    --

  • Although the examples thrown out in the article (writing code in Perl that looks like Python, Java, etc) is kind of lame, I think the idea behind the feature is to allow the easy creation of "little" languages. For example, if your project requires more extensibility than just a static config file, but you'd like to make the extensibility simpler than actually modifying the code for the program. You could create a simplistic configuration language.

    For example, a future version of MRTG (which is already written in Perl), could have a simple configuration scripting language to automate monitoring.

    Or a Perl based game engine (yuck??) could have a little language that defines the rules of the game.

    In theory you could do this now with Perl, but it would require you to write an interpreter.
  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Monday October 30, 2000 @07:05PM (#663793)
    You run into linguistic difficulties, unfortunately. While everything boils down to Turing machines in the end, certain language constructs are far easier and far more efficient in one language than another. While you might be able to write a _loop macro in C, I dare you to write one in JCL. :)

    (For those who've never experienced the horror of JCL, JCL is the only language I'm aware of which has no loop constructs. None. I won't even go into how much fun it is to program in... blargh.)

    Meta-programming (as you call it) already exists today in the form of generic programming; except there, the data is generic instead of the program itself. While meta-programming could be useful, it forces a lowest-common-denominator approach to programming. The JCL problem is just a very obvious one; many more subtle problems exist.
  • If you hate Perl.. Don't use it. Geesh!!

    Seriously, I can't stand Tcl, but I don't go off on huge rants about how much it sucks. Some people like it. Some people like Pepsi (which I also can't stand).

    My drinking a soda you don't like would probably never send you into rant mode about how much my soda sucks and how cool yours is. But if, god forbid, I use a programming language you hate......

    Geesh people.. It's not the end of the frigging world...
  • I was at this session and there was a very interesting reaction to it from the people I talked to after it was done. It seemed that half were all pumped about perl 6 and the other half left resolved to switch to something else (python being the most mentioned). This surprised me a little.

    Before anyone gets all hyper about this let me state that this was not any kind of scientific poll (I didn't talk to everyone) but it was a sample greater than four. Some of whom were long time perl users.

    You can make of this what you will.

    ---

  • Seriously if you want to defend perl that's fine but do it logically and not emotionally(So? I'm a hypocrite).

    I prefer controlled chaos, but ok...

    a special perpose language that does a few things *very* well and does everything else the best that it can.

    I'm a sysadmin, not a *software architect*. I have little/no time to put out a fire on 4 disparate OS's. Gimme a tool that can do that. Umm, Perl. And how do you get "special purpose"? Perl has the ability to be the most generalized language available. Are you trolling me you trickster!?

    Fucking assembly language is cleaner and easier to read.

    Perhaps you don't know asm? Perhaps you gave up learning Perl? It makes sense to me and quite a number of other folks. To be honest I think closer to Perl than any other language.

    take a cue from m$ and add some more features then everyone will love perl.

    Are you trolling me you trickster? All of the listed possible enhancements for 6 are an extension of what Perl is supposed to be: What Ever You Want It To Be. By extension I mean that Perl will now satisfy even you. You like C but don't want to port your source to the innumerable environments the users may have? Pipe that puppy through the new and improved Perl interpreter! Have offices in 32 different countries? Unicode is now insignificant. Run a large code shop with geeks from every backround? Enforce house coding style regs with your very own corporate "macros". Are these bad things?

  • But why would anyone want to interpret Python in Perl

    You're not "interpreting" python in Perl.. You're taking Python Syntax and parsing it into Perl Byte-code. Just like Python can be compiled into Java byte-code or, heaven forbid, Python byte-code.

    The idea was that Perl had this great regular expression package (bar none), but it's not actually used _by_ perl. So, they're going to chuck the old yacc-based parser and use raw perl reg-ex's with a rec-descent parser (as opposed to a bottom up yacc parser), so that _any_ syntax could conceivably be used.. More importantly, the parser itself can be dynamically extended. The best part is that each module could use it's own syntax independantly of other modules (scope-based parsing). So I could literraly load in Java source-code or Python source code through a use statement.. Now, that is vapor-ware.. The more realistic result will be that you can load perl 4 or 5 modules without compatibility head-aches. Any going from C# or Python to Perl should not be too troublesome.

    Other features that were cool were that the garbage collector was going to be abstracted. Partly to try and avoid the current pitfalls with memoryleaks, and partly so that Perl could be ploped right on top of a Java VM using a Java garbage collector. Though the following wasn't mentioned, what this could give you would be immediate access to most every desktop in the world.. i.e. Write perl code that runs inside an MS Java VM after being pre-compiled into java byte-code with a potential perl-translator layer.

    The specifics are all up in the air.. This was just a directions discussion.

    -Michael
  • Maybe the complainers have to work with shitty programmers. It does you a lot of good to write good code if everyone you work with writes crap. Some languages [perl.com] make it easer to write crap than others [python.org].
  • Ah! What are we supposed to do without typeglobs?!


    Live a happy and fullfilled life...

    I will not miss green eggs and spam,
    I will not miss type globs said sam I am.

    p.s. See OO-based variables, where generic scalars inherit the earth.
  • oh how horrible. how very horrible. take it away.

    I got an IBM PCjr, 8088, when I was 5 or so, with a 128k addon card, and it had a Microsoft BASIC cartridge. I rememeber doing very simple things with that--like probably a good fraction of Slashdotters, my first exposure to computer language was BASIC.

    But it STUCK. And I had a very heavy BASIC class in high school.

    And NOW I'm taking C++, and some of the less-computer-literate people in the class who can program a lot better than I, barely are able to maintain their own Windows machines. I run Linux and BSD, and here I am, completely crippled as a programmer.

    I can't remember how to do a class implementation for more than 20 minutes. Then it's gone and I see this grey-on-blue screen with line numbers and endless GOTO statements in my mind...

    It hurts. It hurts a lot.

    Edsger W. Dijkstra observed in "Selected Writings on Computing: A Personal Perspective" that "It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

    I should show that to my CS prof and tell him I'm exempt.

  • Oh goodie goodie goodie I get to code in a language that looks like something spit out from a hex editor. Fucking assembly language is cleaner and easier to read.

    Goodness. A |diety| with an inability to read Perl. How will mere mortals evolve?

    The fact is that you are a hypocrite. Fine, you don't have a use for perl, but it has uses that few other languages do. Don't run down any tool that is useful (even if it is not to you).

  • by divec ( 48748 ) on Monday October 30, 2000 @10:49PM (#663802) Homepage
    It never whines about not doing something if it can do anything at all

    Try putting "!/usr/bin/perl -w" at the top of your programs - y'get a lot more ``suspicion'' error messages.
    just try printing a hashref for an example

    That one's quite easy to pick up just by spotting the output, though.
    BTW try this if you really want to print a hash: "use Data::Dumper; print Dumper($hashref);"
  • by maraist ( 68387 ) <michael.maraistN ... m ['AMg' in gap]> on Monday October 30, 2000 @09:04PM (#663803) Homepage

    So, what else can Perl 6 do that is new as far as applications go? I assume there is more new functionality.


    Well, you can read the transcript or just the summary.

    This wasn't an outline of the language.. Larry hasn't even finished reading all the suggestions about what should go into the language.. He's no where near ready to give an outline. Try another 1,2 or 3 years before we start to see stable releases included with Red Hat.


    BTW, why doesn't he just use the term 'macro' for that 'great' new capability of looking like other languages? IMHO, if I want to do Perl, I will write Perl.


    Well, thats easy.. Because they're NOT macros... That's the beauty of it. Basically you have the abilty to write your own PARSER for perl... OR, extend an existing one.. On the fly.. Basically, it's the equivalent to using Perl's Parser::RecDescent.. Larry even said he wanted a rec-descent parser instead of a bottom up (LR something or other).

    The _real_ advantage of this (even if you love perl and Hate python) is that if I'm a mathematician, I can use Unicode to define my own syntax for mathematical operators.. They will have the net effect of being function calls, _but_ the source code will look _exactly_ like it would on a trusty HP calculator in graphical equation mode. Once I or my peers fully define the mathematical superset language for perl, I just use it as is..

    The idea was to extend the power of perl's regular expressions by actually using them for once instead of just handing off the job of compilation to a yacc - lexer.


    It seems stupid to write Perl with a Java look-a-like because features of the Perl syntax are what makes it good at what it does. For example, just how much spring processing do you do in a Java program? Probably none.


    Well, we're not interpreting Java here.. I don't know that we'd be able to even run pure Java code (nor that we'd even want to). But to paraphrase.. If you like the structure that Java syntax provides, you can write a front end parser that restricts your code just like Java.. If you like white-space-sensative code (forcing coding sytle), then you could easily write a python-look-and-feel.

    Perl6 will be heavily OO on the inside. Additionally, there will be support for low level datatypes (like arrays of raw int's), so Python, Java and C# should easily fit the mold (these languages came up numerous times).

    To answer that last question, however, you would still be using perl regular expressions, not Java's simple c-like string manipulators... You'd just be calling them like you would a normal Java method. The goal for that would be to allow Java programmers to more easily understand the code.. Likewise with C coders (with a C front-end).

    Another beauty is that there will be multiple back-end disassemblers. Currently Perl allows you to compile source code to byte code, and you can even take the byte-code and reconstruct source code (though you obviously lose comments and other things). So with multiple back-ends, you could disassemble back into Java or C or Python or Perl5 or even perl6...

    -Michael
  • from a maintainability and "purity of the language" point of view, it's a potential nightmare.

    Well, C has a macro structure which makes it pretty easy to obfuscate code. For example, don't distribute or execute the following example, and especially not with high numbers:



    #include <stdio.h>
    #define f(x) x ## x
    #define k(x) ((x % 2) ? (x = 3 * x + 1) : (x /= 2));
    #define or(a, b) if (!(a)) {b}
    #define die(die, do) do ## or ## die
    #define error(m, a) printf(m, a); die((k(a);), a)
    int main(void) {
    int f = 43;
    do {
    printf("%d ", f);
    k(f);
    or(f 1);
    printf("\n");
    exit (0);
    }
  • I think you're maintainability problem is one that process fixes, not one that language fixes.

    With this in place, you could literally design your own style guide, and code the way your group wants, the way it needs, without any problems, because Perl is so flexible.

    Right now coders all over the world don't adhere to the same conventions. Everyone has their own styles, naming conventions, etc. This won't change that. What it does mean, though, is that because Perl would be a meta language, it could convceivably spit out clean code from various diverse code, as long as it could parse it properly!



    The nick is a joke! Really!
  • JCL is (or at least was) macro assembler. Heavy on the macro, light on the assembler, essentially a total absense of functions or functionality. Prior to PL/I, IBM seems to have been very anti-recursion.
  • I may not be correct here, but my take on "logic programming" is that Larry is referring to logic programming languages such as prolog. This is a language that uses a sort of predicate logic to form logical statements and conditions which are then examined for truthfulness. Sorry I'm not being real clear here. Logic programming does that to you :P

    If you're really keen, a link to some info on Prolog is here [mff.cuni.cz].

    I think it is true that Prolog is also neither "complete" or "correct", so caveat emptor. Oh, and you'll probably get the error "out of local stack" often - stupid infinite trees :P


    Cheers,
    SuperG

  • [...] so that _any_ syntax could conceivably be used.. More importantly, the parser itself can be dynamically extended. The best part is that each module could use it's own syntax independantly of other modules (scope-based parsing). So I could literraly load in Java source-code or Python source code through a use statement..

    Perl's weakest point is already that it is a write-only language. To write Perl, you must know just one, say, if-like construct. To read somebody else's code, you have to know all the constructs (s)he used. In effect, to read Perl you have to know every if-like construct, every semibizarre loop syntax, the entire language.

    And now, to make things better, every single Perl programmer is to be given the option of easily creating his own syntax for the programs he writes?!

    This is not an improvement.

    /Viktor...

  • by q000921 ( 235076 ) on Tuesday October 31, 2000 @12:44AM (#663809)
    20 years ago, there was a great programming language called "Lisp". It had lexical scoping, was both interpreted and compiled, allowed its syntax to be extended arbitrarily, had optional type declarations, and had multiple syntactic front-ends written in itself. In fact, its credo was to let people write "domain specific 'little' languages".

    So, this leaves me wondering: why should Perl succeed where Lisp failed? What distinguishes the Perl6 goals from those of Lisp? And why start from scratch? Why not use use one of the many CommonLisp implementations, implementations that have already addressed most of the hard problems (generational garbage collection, native code generation, compilation to C, debuggers, etc.)?

    Maybe someone can explain to me what I'm missing.

  • To me, the biggest difference between Perl and other languages is that Perl, even with "use strict" and "-w", still returns defaults or converts objects to strings where languages like Python or Tcl would raise an error. That seems to appeal to many Perl users, but I find it a big inconvenience for larger projects: it makes it harder to track down bugs. I don't see that being addressed by Perl6. I hope it will be.
  • You can't whore for karma if you're above the karma cap. I actually lose karma for posting most of the time anyway, even if it's modded up , because inevitably someone wastes a point on a (-1, Overrated) mod. Like I care or anything.

    --Joe
    --
    Program Intellivision! [schells.com]
  • Maybe he's a mutant cross between Weird Al and Ned Flanders. Pathologically Ecclectic Recombinant Larry.

    --Joe
    --
    Program Intellivision! [schells.com]
  • Very true, but the market place of computer languages is structured by economics as mach if not more than by computer science.

    The more computers are ubiquitous the more programmers you need. And the more programmers you need the more you must do with not very bright programmers, and the more you restrict yourself to the brightest programers the more your production costs soar.

    and so, there is no escape from the conclusion that the killer language of the future will be judged by one feature above all else: how much it allows mediocre coders to write reasonable code reasonably fast.

    BTW, I think perl already wins on this criteria for write-once code.

  • Reminds me of junior high kids fighting of game consoles, you know?

    Perl is an interesting language because it comes from a decidedly different philosophy than most languages. Language designers and zealots usually give the highest priority to (1) elegance, (2) ability to build very high levels of abstraction, and sometimes (3) minimalism. Larry has the approach of designing for usefulness. You can get off track very quickly in language design by trying to be too pretty or leaning too hard on pet abstractions. If you get nothing else out of his paper, read the section on common language design mistakes.

    Perl is too over the top on some areas, certainly. References and OOP features sure clogged up the language in a weird way. But it looks like some interesting changes for the better are in the queue. And you can always ignore what you don't like or need.
  • It's a valid concern, but it only serves to frustrate the conservative - it fully lies within the stated goals of the language.

    If you are an organization, then it is _your_ responsibility to define standards for your developers. You can write very unreadible code in _any_ language..

    As for making use of other's works, that's what Perl documentation and OO are for.. Hide the complexities, and publish the interfaces.. Perl works the way Humans do.. We don't understand the complexities of our bosses or employees, and we don't need to - we just need to understand how to interface with them to get desirable results. Let me write my chunk of code in my group's dialect.. Let us debug and have peer review so that we have clean code. Then you only need be concerned with a trivial interface... If someone new comes into the group, then they must be introduced to our style. I've worked with many groups that have successfully accomplished this (In more languages than just Perl).

    -Michael

  • Does that make them non-macros? Lisp hackers would certainly disagree.


    Well, then maybe I'm a little fuzzy on the difference between a macro and a compiler. To me, a macro has historically been a named reference to a collection of code (really just more human readible text). M4 and CPP macros translate a name and arguments to some other rearranged set of text.

    A compiler, to my knowledge translates human readible code into optimal machine language (though not always assembly code).

    What Perl6 looks to do is have multiple front-ends that translate some form of human readible code into [v]machine-readible code. Though I've written a macro processor that translates human text straight to binary assembly, I would hardly call that a compiler. A real compiler will take into account different symantics - it will attempt to assertain the logical meaning of a statement and determine how best to represent it in machine code. If all we did was translate human code to machine code, then yeah, we'd be a macro "lexer". But Perl6 will allow you to write your own -intermediate- code within the dynamic parser to perform the one-time compilation.

    If this doesn't resolve the issue, then you'll have to point me to some literature that better describes the distinction.

    -Michael
  • Ho hum. Tao [tao-group.com]/Amiga [amiga.com] generalised VM. Runs Java, C, C++, various scripting languages + shells, and native virtual processor assembler.

  • That can't be it. Lisp is as procedural as Perl (most data structures can be changed, there are syntactic primitives for looping, etc.), and Perl is as functional as Lisp (it has lexical closures, anonymous subroutines, higher order primitives like "map" and "grep").
  • Unicode for mathematical operators? Does that mean we can at last bring back APL?

  • However, Perl is a very bad language when compared to a clean and simple programming languages like Python, C, and Scheme. And yes, C++ is a pile of bloated crap. That's why I don't use it.

    As for VB, that is the beginning language for many people in the *Winblows* world. Perl is the beginning programming language for a lot of kiddies in the Unix/Linux world.

    Yes, human stupidity does result in bad programming. However, the way functions are done in Perl is cumbersome and generally bad.

    Perl does promote the use of global variables because variables in Perl are global in scope by default. It is better practice to force people to declare stuff as global (like in Python) than to force people to declare stuff local.

    I also really dislike Perl. Perl is a badly designed mutant hybrid of bourne shell, sed, awk, and C. Python is a far better scripting language than Perl - it is far cleaner and simpler, it promotes good programming practice, it was well designed from the start instead of being a mishappen pile of hacks, and it IMHO just sucks. I've tried to program nontrivial programs in Perl and it was a major pain in the ass. There are a lot of things which are simple in Python which are a pain in Perl. Object orientation in Perl is poorly designed, function syntax and handling is badly designed, error handling is badly designed, and so on.
  • I don't think that "splintering" is what you want to call it. Think of Perl as a "backbone". Now, wouldn't it be handy if you could access the power of Perl by using whatever syntax you felt like using? Since Perl is so good at parsingother text, there is no reason why you couldn't code in another language and have Perl translate that language into Perl. Just tell Perl how, and it'll do it.

    Now, maintainability nightmare?? I defy you to show me one non-trivial Perl script that is not practicaly read-only. If you are hired to maintain perl, realize that they hired you because you can maintain this read-only code garbage.

    Of course, since the Sanskrit garbage that the person wrote in the first place can be easily translated into readable, basic Perl by using the same module that just did the translation in the first place.

    Sanskrit -> Perl code -> Interpreter

    Instead of sending it all the way to the interpreter, just stop it after the perl conversion stage. Tada! You have perl.

    -inq
  • The stuff is plain not maintainable - period. It has nothing to do with the power of the language. Perl is a powerful lanugage but to write to look clean is another issue all together. I have time and time again been handed perl that others have written. Every single time I just end up re-engineering the whole app start to finish. In a corporate setting I have to produce code that others can maintain and perl just does not foot the bill.
  • What about recursive functions? Are they possible in JCL?
  • That sounds like what "everyone" said would happen to Linux.....Every thing is a potential nightmare if it is not done correctly...
  • That's the point. Let's say that you like what Perl can do. You like to program in Python better. If Perl is the metalanguage, a small module can be written in Perl that would parse Python syntax and dynamically translate that Python syntax into Perl. Tada! YGP! (You've Got Perl!)

    Practical Extraction and Reporting Language... it's what it was originally made for. Perl as a metalanguage is a natural evolution.

    -inq
  • What the hell does that got to do with .NET idiot. .NET has nothing to do with a language you dork. It is nothing more that a fancy name for SOAP. When are people going to relize that .NET is nothing special, XML-RPC has been doing it for years.
  • You know, that sould like a programmer issues. The perl code that I have written is easy to maintain and easy to read/understand. It is just as easy to write ugly/unmaintaniable code in almost any other language.

  • The idea that the syntax can look like any language reminds me of the guile scheme interpreter. The idea was to have an engine for scripting languages that you can embed in applications -- without requiring that the extension language be a specific language. The author could, by embedding guile, simultaneously give the use the capability to script in scheme, tcl, python, perl, or whatever. Is this similar to what we can expect in Perl 6?


    Nobody knows what we're going to get. Larry is still tossing around ideas, and he's making comments based on first impressions.. The motivation and inspiration for perl6 is still very new, so consider most of this vapor-ware until we really start seeing road-maps.

    Check out my other comment [slashdot.org] for more information.

    -Michael
  • But why would anyone want to interpret Python in Perl?! It would be slower than using real Python or even JPython, and it would convey no advantages. Anyways, why would you want to convert your Python code into Perl. Python is a much nicer language than Perl - I don't think that much would be gained from converting it to Perl.
  • >Give me a reason to like perl when it
    >encourages programmers to write ugly unreadable
    >unmaintanable code.

    Because it's fun.
  • by Anonymous Coward on Monday October 30, 2000 @09:15PM (#663831)

    I've worked on (and am working on) large projects written in Perl. We avoid the 'unreadable' aspect by having a fairly well-defined set of coding standards; use OO syntax, use strict, etc.

    The reason I find the meta-language aspect of Perl6 exciting is the ability to implement coding standards as simple compile-time pragmas. Define your environment, and now your coding standards look like use Javaese;, or whatever.

    Perl has always excelled at allowing us the flexibility to do some nifty things other languages couldn't (at least not without having to write a significantly larger amount of code). Being able to define your Perl is pretty darned nifty, I would say.

    predictive

  • ummmm.. it can spit out C# code.

    Now, C# may be as much of a "standard" language as M$ claims that it is, but so far the only place that I've heard of it being used is in....

    You guessed it, .Net


  • I was at this session and there was a very interesting reaction to it from the people I talked to after it was done. It seemed that half were all pumped about perl 6 and the other half left resolved to switch to something else (python being the most mentioned). This surprised me a little.


    I got the feeling from Larry's speech that there were desperate measures to be taken. In particular, that conference with the jar throwing because people weren't being excited as much as they use to caught my eye. On the one hand, Perl had it's time in the sun, and things like XML (this [xml.com] article suggests that XML removes a problem that makes perl so useful) and PHP are taking away steam.

    On the other, this is an attempt to allow Perl's philosophy to transcend a niche.. Perl is more than string processing.. It's an artists language. But it only is useful so long as people continue solving problems with it (and share those solutions with others).

    Personally, I'm going to keep making my pet projects out of Perl, because I'm in love with the language. Recently, I have found myself deviating towards Python because of the clean-ness of OO, exception handling, and generally beautiful syntax. I almost strayed to PHP till I determined that it's horrible for large scale design (completely ignoring performance issues). The idea of super-setting perl restores my faith, however.. Since we have the opportunity to write an entirely new syntax if we choose.. Personalize it to our or our company's needs, and be able to transparently intermix with neighbors.

    When Perl6 was first announced, I read on slashdot some that said that they were appauled by various activities.. We're actually losing developers, I'm sure.. And I can't imagine that we're gaining too many (we're still not taught much in academic circles). Still, it was encouraging to hear Larry say that there were a lot of young faces. Perl almost seems to me an older-person's language. It was hip just about the time that I went through school, and to a great extent, it still is.

    Let's hope that making working on the perl core is more fun now that they're stream-lining it. Let's hope that perl can reinvent itself.. And for those perl-haters out there (it's all right.. You can admit it openly. :), competition helps evolution of all languages.. Yes, you may gripe when a piece of perl code comes across your desk, but have you never done shell programming? Have you never tried to modify an /etc/... script? You can't tell me that bash is _any_ cleaner of a language than perl.. Or maybe you're part of the MS crowd?

    -Michael
  • To follow this through to it's conclusion, if a Perl programmer turned up at a PHP shop, would it be expected for him to learn PHP, for him to just carry on writing in Perl, or for a hideous (in terms of software engineering) little program to be used to translate between his Perl and your PHP.

    If you do it one way, then it should be possible to do it the other way. Not only are there better things for people to be spending their time on in developing languages, but it would be more cost-effective to produce a meta-language that can be converted into whatever is required.

    Funnily enough, we have something like that already in existence. It's called a compiler. If I write a program in C using standard library calls, chances are it's going to compile just as easily on an x86 box running 'nix as it will on an alpha running the same 'nix - the machine code is different, but I've taken one base and been able to produce versions written in two different [machine] languages.

    I have to say, this thread has to be a candidate for "least thought out still-born pathetic excuse for an idea" I've seen on slashdot this year, but don't take it personally. On the surface it sounds like a really cool idea, but when you actually think about it, it just doesn't have any real integrity in concept. Sorry, but that's my 2p worth.
  • Hrm, even Babbage's Analytical Engine had loops..

    --
  • Soon enough, you've got every organization, or every open source hacker, coming up with their own "little language" on top of Perl, and you've splintered the language into an unlimited number of different languages. Imagine the horror of being hired to maintain the Perl code of someone who just quit, only to find out the entire thing is written in, say, some combination of C#, Sanskrit, and Pig Latin.

    I've encounterd this at my workplace at the moment. I've been made back up for a wierd interface program. It's something that I've never seen before, or nor has anyone else I know or asked. I think that they've done it this way to lock you into thier propriority dev tools (which suck). You could go into vi and type it by hand, but the thing is more verbose than COBOL, and has a wierd fetish for "(" and ")".

    Talk about job security.

  • This is what Guile originally aimed to do by writing translators from Tcl/Python/Perl to Scheme, yet where are the translators today? People already using their Python interpreter, which is a well-tested and stable hunk of code by now, don't want to chuck it and start using a translator on top of an entirely different execution engine. The problem is that specifying a general VM is a difficult job. Java didn't manage it (can't implement Scheme's continuations on the JVM), Microsoft's CLR didn't (no multiple inheritance, so Eiffel# had to have MI stripped out of it), and it seems quite likely that the Perl engine will similarly make it possible to write code in vague amalgams of Perl's semantics and some other language's syntax, but capturing the semantics of the other language will prove impossible, since Perl's view of the world will permeate the VM in subtle ways.
  • It the programmer does not know what the hell he is doing he will write bad code in ANY language!

    The problem isn't with programmers who have no idea what they're doing. They don't get the job done at all, and get fired.

    It's the guys who know enough Perl to write something useful, but don't know it well enough to make it maintainable by others. Surely there are a lot more of these people out there than completely ignorant coders. I'm probably one of them, and that may well be why I don't like Perl.

  • I got an IBM PCjr, 8088, when I was 5 or so, with a 128k addon card, and it had a Microsoft BASIC cartridge. I rememeber doing very simple things with that--like probably a good fraction of Slashdotters, my first exposure to computer language was BASIC. But it STUCK. And I had a very heavy BASIC class in high school.

    Actually I liked the BASIC cartridge. You should of tried to pull the cartridge and using the built-in PCjr BASIC. It was much worse. With 256 colors and multiple graphic buffers, (SCREEN 5) It was quite bleeding edge. (The AT and XT could only do 16 colors)

    I don't knock BASIC - It serves a good purpose even today.

  • Moderators - Score 4 Insightfull??! Where's the insight? |deity| rants about not liking Perl but doesn't offer anything other than *I thinks perl sux*

    perigeeV likes perl. it makes him/her/it happy. if you don't like perl (i don't think you do), then don't use it (i don't think you do).

  • Try another 1,2 or 3 years before we start to see stable releases included with Red Hat.

    And a year earlier to see unstable releases included with Red Hat? :-)

  • I may not be correct here, but my take on "logic programming" is that Larry is referring to logic programming languages such as prolog.

    Yes, and logic variables are a way of implementing what is known as "AND parallelism" in logic programming.

    AND parallelism differs from OR parallelism in that separate execution threads are created within the same conjunction. Logic variables let you get away with this by deferring binding until further evaluation would prove unpragmatic for whatever reason.

    OR parallelism is more familiar and more widely implemented -- and simply involves forking a different thread for every rule that might unify a given term in a conjunction.

  • by flynt ( 248848 )
    Perl 6 should enhance my coding abilities, I can't wait.
  • by Lord Omlette ( 124579 ) on Monday October 30, 2000 @06:33PM (#663844) Homepage
    are they mad!? are they...

    *GASP*

    trying to compete with .NET?!
    --
    Peace,
    Lord Omlette
    ICQ# 77863057
  • I agree... and I am glad this was said. It's a shame it was moderated down.

    Point taken.


    Michael Labbe
  • by dadisman ( 235713 ) on Monday October 30, 2000 @06:33PM (#663846)
    Could we have a mechanism to dynamically translate any language code, into perl. Forget Java, this is true write once, run anywhere.
  • there is no escape from the conclusion that the killer language of the future will be judged by one feature above all else: how much it allows mediocre coders to write reasonable code reasonably fast.

    Good point. I think this explains the popularity of Java. It's a typesafe language with support for cool features like exceptions. I like how Java exceptions are part of a function's signature, that is a function must either catch an exception or declare that the exception is thrown. Unhandled exceptions can be detected at compile-time. C++ is stupid about exceptions, even if you specify a throw() clause in your function prototype. :-(

  • Richard Stallman. Larry Wall. Are they the same man? You be the judge...

    --
  • If Perl.sucks then goto python end if Looks like the perfect language construct.....
  • The idea that the syntax can look like any language reminds me of the guile scheme interpreter. The idea was to have an engine for scripting languages that you can embed in applications -- without requiring that the extension language be a specific language. The author could, by embedding guile, simultaneously give the use the capability to script in scheme, tcl, python, perl, or whatever. Is this similar to what we can expect in Perl 6?
  • Ah! What are we supposed to do without typeglobs?!

    MyopicProwls

  • That's what makes Python Python. It is very structured. That enforced structure makes it at once beautiful to look at and quite inflexible.

    Somewhere I read about the slogans for the two languages, and I think that those slogans state the situation quite nicely:

    Perl: "There's more than one way to do it!"
    Python: "There's a right way to do it."

    Case in point: you can write functional Perl code in several different ways. You can write Perl like you write Python, perfectly structured and pretty. you can also make Perl look like complete TRASH.

    Try to write python that looks as bad as the worst Perl. Good luck :)

    -inq
  • by Anonymous Coward
    *siiiigh* Yeah. Perl6's great ambition is to run Python, or whatever dialect you want, given a translation system. You know.. Because Perl is /so/ much faster than compiling to C, or Java bytecode. Wheel reinvention, anyone?
  • Sure you didn't mean TECO instead of Emacs?
  • The point is, why not? As computers get faster, the overhead of te interpretation operation will get smaller and smaller. Compare this loss of productivity (if I may call it that) with the gain in productivity realized by not having to make a programmer LEARN Perl if he wants to USE Perl. Or C++. Or Java. Or PHP. If I know PHP, and the shop I work in uses Perl to do the same task, it would be easier to load up the little interpretation module and program everything I wanted to do in PHP rather than pick up a whole new language.

    Think of it as code reuse. Why learn another language when you don't have to? As long as a translation module is written, why learn another language?

    -inq
  • by perigeeV ( 115833 ) on Monday October 30, 2000 @07:35PM (#663856)

    All these negatives! Perl's particular idiom is that it is the most flexible language around. That list of goodies for Perl 6 is wonderful.

    I think a good bit of the flack tossed at Perl is due to the fact that coding it comes in two distinct flavors: Keeper and Throwaway. 80% of Perl I pound out is extinct when the process dies. If I can code closer to the way I think and save a few seconds per line of code, that's more time for my daughters. Are my Keeper scripts readable and maintainable? You bet. If there's a slim chance it might come in handy later the first thing you see is a use strict and a bunch of POD.

    Every Item on that list made me tingle!

  • Yeah, but it is much easier to write unmaintainable and generally bad code in Perl than in other languages, such as Python and Scheme.
  • Yeah, but it is much easier to write unmaintainable and generally bad code in C/C++ than in other languages...

    See how stupid that sounds???

    It the programmer does not know what the hell he is doing he will write bad code in ANY language!
  • Perl: the BASIC of the 90s and the 00s. People should start to learn to program in Python - it is a much better language than Perl and doesn't destroy the minds of beginning coders who hack in it. I'm one of the lucky ones who programmed in old Applesoft BASIC and didn't get their code skills wrecked from the start.

    See now.. My first language was TI99A [Extended] BASIC.. Then Apple Basic, then GW Basic, then Apple Pascal, then finally C. Apple Basic was my first formal language.. Our professor was very good.. He hounded us on good programming techniques.. Garbage In Garbage Out, spagetti code, etc.

    The language means nothing.. The training means everything.. It's very similar one's role models in life.. If you exclusively adore Rock stars, guess what direction your life is going to turn out.. If you adore Einstein, then you're going to fall in love with learning. If you simply taught yourself to program and never had any good examples to work with.. Nor had the occasion of peer influence over your syle, then of course you're going to be undisciplined...

    I started with BASIC, and I don't think that killed my programming mentality at all. I program in Perl almost exclusively now, and I can still pump out highly structure code that puts even Java to shame... But that's me and my years of being involved with languages. Today's trend is to get half-rate newbie programmers and put them to work. I don't even want to think of the percentages of non-collage graduates (which includes people that dropped out for that tempting hefty pay-check) that write code that my life depends on.

    -Michael
  • by Anonymous Coward
    The stuff is plain not maintainable - period. It has nothing to do with the power of the language. Perl is a powerful lanugage but to write to look clean is another issue all together. I have time and time again been handed perl that others have written. Every single time I just end up re-engineering the whole app start to finish.

    Perl is a powerful language, in my opinion, because of the addage: There Is More Than One Way To Do It. This can, and does in many instances, result in code that can be incredibly unreadable and unmaintainable. However, it does not prevent you from writing clear and maintainable code.

    Personally, I have my own perl coding style, it's what is the most readable and understanable for me; Perl handily lets me code the way that works the best for me. When I'm writing up quick little scripts or programs in which I will be the only maintainer, I use my own style. When I'm writing scripts/programs that others are likely to be involved in, I tend to follow the guidelines layed out in perlstyle(1). Which, as it turns out, is the policy for all software developed in our company. We have yet to have any major readability/clairty problems, and we have some perl-based projects which contain 15,000+ lines of code and receieve many updates by many different groups of employees.

    In a corporate setting I have to produce code that others can maintain and perl just does not foot the bill.

    I really fail to see any basis for this comment. Perl isn't going to force you to write clear and maintainable code, this is something that you're going to have to do for yourself. However, this is generally a matter of preference or experience with a given language. There are plenty of languages that I find difficult to write/find readable code in; however, I realize that this is mostly due to my own inexperience with the language and not a fault with the language itself. I use what works for me.

  • But why would someone want to convert something to Perl if it is written in a language which is already implemented in a good compiled language like C?
  • That's ridiculous; no "translator" is going to produce nice, clean, readable code that other people want to work with. And what about round-trip? You think it can then convert that Perl back into Python for you to edit?

    Personally I don't think it's intended to be used as a language translator, but rather let you add a few macros/stylistic conventions so you can continue writing code which nobody else can read.

  • by maraist ( 68387 ) <michael.maraistN ... m ['AMg' in gap]> on Monday October 30, 2000 @10:02PM (#663863) Homepage
    Rob, when are you going to understand that intelligent slashdot readers don't give a shit about Perl?

    Sorry for replying to an obvious flame, but I'm opinionated, what can I say. See any one the dozens of posts as to why the world is filled with different types of people and different types of problems.. And how people use different tools to solve problems. Perl DOES solve a certain class of problems exceedingly well. Take what anything bash or most any other shell-script does, for example, and try to do it on a large scale, and you would definately appretiate the power of perl.

    If you're not of the class of people that regularly manipulates UNIX environments, then you don't have to care.. But, seeing as how there is a very large group of Linux advocates on slashdot, then logic would suggest that there is a need to manipulate UNIX environments in our midst. Given that, bash, awk, sed, python and yes, even Perl are tools that WE would be interested in. Personally I don't care about the Playstation 2 (I personally hope it dies a painful death), but I have absolutely no problem reading the one paragaph blurb.

    Course I also don't hate minorities or deviants with a religious passion.

    -Michael
  • by raistlinne ( 13725 ) <`lansdoct' `at' `cs.alfred.edu'> on Monday October 30, 2000 @10:03PM (#663864) Homepage
    what exactly is wrong with perl's function syntax?

    Oh, btw, you're probably right that Perl is the first language of a lot of linux people and as a result a lot of the perl scripts around are pretty lousy. I'll give you three guesses what will happen if python becomes people's first languages.

    The very nature of programming allows people to write bad programs.

    What you are describing, btw, was experienced by Bjourne Strousap (sp?) with C++. At first the people on the mailing lists were courteous and intelligent, etc. He later learned that this wasn't a feature of C++ as he had hoped, but a feature of C++ not being as popular at the time. Once it moved away from the small group who initially used it, it started accumulating idiots in the standard proportions.

    Python is in the same state - it's still used by a relatively small group of people (from what I understand of what are available as numbers, there are about an order of magnitude more perl programmers than python programmers). If python ever gets big, bad python code will proliferate. If whitespace delimeters are configurable (which I've been told they are), I guarantee you that you will eventually run accross a python program where the delimeter is a single space, and that's just the start.

    Of course, the most unreadable part of a program is it's logic, not it's syntax (if you know the syntax). I heard about one guy who was theoretically programming in perl. He farmed every regular expression in his program out to sed. I defy you to come up with a language that makes something like that more understandable.

    I know people who write programs that do the same thing three times in slightly different ways. Debugging that is quite difficult, and they're using a really easy syntax.

    Perl programs are not particularly harder to read than any other type of programs, the key is that you have to know as much (or more) perl than the person who wrote the program.

    Btw, I've written non-trivial programs in perl and marvelled at how easy they are. And while perl doesn't do classes very well, it's object orientation is rather nice to work with if you're an OO user rather than an OO bigot.

    Oh, and the use of : and whitepsace rather than {} is really stupid and quite a bad language flaw. The overuse of objects is another design flaw, as is the overbearing attitude of python zealots.

    And let's not get started on the fact that you need to use \ to continue lines in conditionals.

    Anyhow, I will agree with you that C is quite nice. Whenever I'm not using perl, I'll generally use C, though a friend of mine is slowly convincing me to try C++. It does have a lot of nice features, if they are improperly used by people sometimes.

  • It bears mentioning that the syntax of the language takes you all of a day to learn if you've ever done any programming at all. What takes you time to learn are the libraries, conventions, ideologies, and so on. I think this meta-parser will be nice if you like to write your if/then statements a certain way, but it won't take any of the work out of learning Perl, and it certainly won't make code instantly portable between languages. We're talking SYNTAX, people.
  • What makes Python better than Perl?

    I hear that Python code is more maintainable. Why? Does the enforced indentation style make it easier to read than 1 liners within {}?
    The syntax is said to be more elegant than Perl (which isn't pretty). Is it more elegant or less hard? e.g. easier to learn
    Does it somehow prevent the use of bad logic or obsfucated variables?

    The common bitch from the Python camp is about the ability to write bad Perl. I guess I'm missing how a "language" can prevent a bad programmer from programming badly.

  • This sounds like it's taking some ideas of .NET to me as well. .NET is a move to one runtime (whether it is a jvm or not) where any language can be used. I heard like about 25 or so languages can be used with .NET and which all give about the same results. Perl is attempting to take this 'many languages' through 'one compile' method as well. And being able to import pieces of other languages into your program is very .NET because that is what you can do with it. You can import a c# class into any other working project, or even a perl module (through the .net perl). .NET is more than you think.
  • Well, IMHO, there's a simple answer to this question. Lisp is functional. Perl is essentially procedural (well, you can code functionally, etc, but most don't...). Why is this an issue? Well, your average joe started coding in Basic or Pascal or what have you, and these are procedural. So, despite all the advantages Lisp has, it's a bitch to learn to code in (hell, a lot of 3rd year CS students don't get recursion). So, if you can put all those wonderful features Lisp has into a procedural language like Perl, you immediately have a leg up on Lisp, simply from an ease-of-use stand point. Thus you're more likely to indoctrinate new programmers into your language.
  • Perople get tendinitis from having to type too many parenthesis characters!

  • also really dislike Perl. Perl is a badly designed mutant hybrid of bourne shell, sed, awk, and C. Python is a far better scripting language than Perl - it is far cleaner and simpler, it promotes good programming practice, it was well designed from the start instead of being a mishappen pile of hacks, and it IMHO just sucks. I've tried to program nontrivial programs in Perl and it was a major pain in the ass. There are a lot of things which are simple in Python which are a pain in Perl. Object orientation in Perl is poorly designed, function syntax and handling is badly designed, error handling is badly designed, and so on.

    Aw, you big lug! It sounds like you've been hurt by Perl. Maybe you need a hug.

    Perl's OO is different that other languages. You clearly don't like it and you should use the tool that's best for you. Perl works very well for me even with complex programs. It doesn't put a gun to my head. It always lets me express myself in a natural way, like English. Also like english, I often have to revise and clarify Perl code because the first thing I write down isn't always the best way to say it. This isn't unique to Perl. All programming languages need editing. It's a shame that Comp Sci classes don't encourage the "one to throw away" model more enthusiastically.

    Perl respects the programmer. The programmer, not the language, is responsible for source code maintainability. Bad code isn't a Perl Problem.

    Let's look at C. A perfectly respectable language. It's got stronger type checking than Perl. Clean C code should abound. Yet, it doesn't.

    Perl is a whimsical language. You can create truly bizarre phrases like:

    print (map "$_ => $h{$_}\n" keys %h)

    or you can write the more conservative:

    while( my( $key, $value ) = each %hash ){ print "$key => $value\n"; }

    I do agree with your dislike of Global variables. Especially with the special globals, like $_, programming can get hairy. There is talk about isolating these variable. That would be a Good Thing.

  • So, what else can Perl 6 do that is new as far as applications go? I assume there is more new functionality.

    BTW, why doesn't he just use the term 'macro' for that 'great' new capability of looking like other languages? IMHO, if I want to do Perl, I will write Perl.

    It seems stupid to write Perl with a Java look-a-like because features of the Perl syntax are what makes it good at what it does. For example, just how much spring processing do you do in a Java program? Probably none.
  • by Sludge ( 1234 ) <[gro.dessot] [ta] [todhsals]> on Monday October 30, 2000 @06:44PM (#663872) Homepage

    Around a year ago I picked up a copy of Learning GNU Emacs by O'Reilly. One part of this excellent book describes using a mini-mode called abbrev-mode, which expands things you type. When I discovered this, I became overzealous and started to create different abbreviations for each major mode.

    When I programmed in C++, I would make _loop expand to:

    int count;
    for ( count = 0; count < x; count++ )

    I would then write a _loop macro for Perl which would do the same thing for the Perl minimode. After a short while, I realised where this was going. I started to program in a short form that enabled me to not understand the detailed syntax of the language, and to get by in simple situations with a superficial understanding.

    My next experiment was to play around with the idea of a MetaLanguage. It turns out that such a thing may actually be able to output different languages based a generic input language.

    It seems that Larry Wall is interested in doing something similar. While there are those who would be against Perl for it's confusing syntax- It never whines about not doing something if it can do anything at all- just try printing a hashref for an example- Perl has done something very interesting over the years.

    Perl has shown us how much we are sacrificing by making language syntax simple, unifying and easy to understand. (No, this shouldn't be +1 funny)

    Michael Labbe

  • Yep you are right I never have done SPRING processing with perl. As a matter of fact I would never even consider using perl in a production environment.
  • by Baldrson ( 78598 ) on Monday October 30, 2000 @07:52PM (#663874) Homepage Journal
    Perl will also support many types of high-level programming, adding more support for functional programming (the reduce operator), logic programming (???), and the little languages.

    and

    There's another threading model, ithreads, which is more like a fork inside the process. That could be inefficient, but I think if we do what we're thinking of doing with copy-on-write semantics then it will not be as inefficient as all that to clone a new thread, and I think in some ways it's more safer to assume that all your global variables are not shared and make you specifically declare all the things that you want shared and how you want them shared. So that's my leaning.

    If by "logic programming" Wall means he will include logic variables, then he can dramatically simplify the thread model while also enabling cleaner distributed applications by implementing logic variables the way the Mozart guys do [mozart-oz.org].

    IMNSHO, there really needs to be some serious outreach from the Perl6 team to the Mozart team [mozart-oz.org].

  • Sorry. I use perl for utilities. Short and sweet stuff. If I need web stuff, I'll do java server pages. If I need big or fast apps, it's c.

    A tool for each purpose, a purpose for each tool.


    --

  • years ago, there was a great programming language called "Lisp". It had lexical scoping, was both interpreted and compiled ...
    and maybe more importantly: interactive (like Python is; perl is only interactive if you run it inside the debugger !?).

    why should Perl succeed where Lisp failed?
    Uhr ... lisp failed? As far as I can see, Lisp (in different forms, including Scheme), is more alive than ever. This includes, by the way, some fancy robotics stuff in the Deep Space 2 mission (but I fear it won't be long before perl is in space too ...)

    It may not be used as widely as other languages, but why is that 'failure' ? Hey, apparently only 0.2% of the world is of Judaist belief. Bit of a failure, that. (What a bollocks).

    Lastly, I do agree with the author that this 'different syntaxes for perl' thing prolly going to fail: for most code, the aim is not just functionality, but readability to others. Inventing your own 'little language' is all nice and well, but things only really start to take of if this 'little language' is spoken by more than person. And BTW, this is nothing new, we've had this 'little language' thing before: they are called API's and libraries.

    E.g., even if you have written some brilliant library that does cgi stuff in perl, it 'd prolly have little chance against CGI.pm: everybody knows it, and even if it has rough edges, IT'S BETTER BECAUSE MANY MORE PEOPLE KNOW IT. . (And also, why bother?)

  • 20 years ago, there was a great programming language called "Lisp". It had lexical scoping, was both interpreted and compiled, allowed its syntax to be extended arbitrarily, had optional type declarations, and had multiple syntactic front-ends written in itself.

    I'm afraid there is a bit of wish-casting going on here. Some dialects of Lisp had lexical scoping, some dialects had good compilers, world-beating macros eventually became the norm... The problem with lisp is that when it had its best chance to take over, it was twisty little maze of dialects, all different, most at least somewhat proprietary, and few of them had execution speeds anything like the then conventional languages.

    Then Common Lisp started to happen, but that took years, and the eventual product was a language so large and complex that many companies died trying to get it up, fast, and on stock hardware. The lisp community, if you remember, was deeply into the specialized hardware game, which meant that they had a built-in price disadvantage and couldn't free-ride as easily on the advances in stock microprocessors.

    Don't get me wrong, LISP is beautiful. But we know all the reasons why it never took over back then. Some things are different now, and there are some very nice, free Common Lisp implementations out there these days. Moreover, processing power has grown so much that Lisp can go about as fast as most people care about for a wide variety of applications. What it doesn't have now, because it lost so spectacularly in the 80s, is developer mindshare, university teaching course space, and the kind of visibility that something like Perl has now.

    Yes, it could have all been different, but it wasn't. Yes, lisp might come back, but it will probably look and feel more like ML. Yes, people could and should learn a lot more of the lessons of lisp then they seem to have. But let's not fool ourselves: there were many reasons that Lisp lost that have not very much to do with elegance or fine ideas. If Perl is now in a position to adopt more of those good ideas, then I, for one, can only be happy about that fact.

  • no perl;

    for ($you) {
    $year = 1;
    }
  • by Fas Attarac ( 163334 ) on Tuesday October 31, 2000 @07:10AM (#663879)
    Wow, I don't think I've ever met anybody as anti-Perl as you.. I think the main problem you have with it is the fact that the syntax can be so varied. This allows for very elegant and efficient code, but at the same time, inexperienced programmers can abuse that lack of strict syntax and write something that's very difficult to read.

    Find a good Perl programmer, and not somebody that's just learned Perl and likes to tinker with it (there are thousands of these!), and you will find some very readable Perl code. Sounds like you've been bitten by a poor Perl programmer and asked to maintain his code perhaps?

    Seriously, a bad programmer in any language is going to write a badly written program. The code will be difficult to read and maintain. In many other languages, though, stricter syntax forces the programmer into a certain style, so you mitigate the amount of damage they can do (a badly written piece of code simply may not compile). Perl is enormously flexible, with syntax and modules to do anything, which means poor/beginner programmers can Get Stuff Done with little knowledge, effort, and sadly, little programming abilities.

    Perhaps you should be working to better educate the developers around you (or hire better ones) instead of dissing a language that obviously is not going away and obviously has a very practical and valid use in just about any field.
  • why should Perl succeed where Lisp failed?

    A gerbil could learn the Lisp syntax in about a half hour. I don't think I've ever met anyone who was aware of all the Perl syntax. (And I've met some smart people who use Perl a lot. If you think you understand Perl syntax, would you please annotate some of the more interesting perl poetry and abigail sigs, then explain it all to me?) So, naturally, Perl has a huge advantage over Lisp.

    Let me explain. I get a warm fuzzy feeling every time I learn a new thing. Since I like to learn a lot of programming languages, its relatively easy for me to learn new syntax, and get that warm fuzzy feeling fairly often. For a language like Perl, I'm still getting that warm fuzzy feeling a few times a month, and its still suprisingly easy to get that glow.

    Conversely, since Lisp pretty much has no syntax to speak of, I can only get that warm fuzzy glow by learning ideas much more complicated than syntax. I think I can safely say that anything is more complicated to learn than syntax -- anyone who knows more than a half dozen programming languages has almost undoubtedly taught him or herself how to learn new syntax very easily and quickly. The complicated stuff that Lisp makes possible to learn almost immediately is difficult and painful to learn. I personally can never learn more than one or two difficult ideas a week, and I the difficulty of learning it often overshadows that warm fuzzy glow I get from finally learning it.

    In short, Perl is rewarding to learn, Lisp is not.

    And before anyone mods me down as a troll or flamebait, understand that I am 100% serious about everything I've written here. I really do believe that most people learn new things for the intrinsic reward for learning it, and certain programming languages are popular precisely because they are so rewarding to learn. Similarly, many languages are unpopular because they aren't very rewarding to learn at all. But, what makes a language rewarding to learn often has suprisingly little to do with how elegant or powerful a language is.
  • Perl's function syntax?? What are you smoking?

    some_function($argument1, $argument2);

    What exactly is so difficult to use or understand about that? Likewise with OO methods:

    $some_object->some_method($argument1, $argument2);

    Anyone from any OO camp will instantly be able to recognize that and understand what it's doing. I fail to see what you are trying to bash here.

    As far as Perl's global variable issue, this is a necessity brought on by the fact that Perl isn't just built to write large scripts/applications. It's built to handle small one-liners as well. Forcing strict variable declarations (which is highly recommended with any medium to large script, and enforced with the use strict; pragma, would completely solve the problem you're ranting about) would prevent readable one- and two-line-style scripts. Ever seen the "RSA in 3 lines of Perl" type .signatures?

    chdir($dir) or die "Couldn't chdir to $dir: $!"

    What is so difficult to read or understand about this? Any programmer that has never seen Perl before should be able to understand the above. This is an example of a stock Perl function and stock Perl error handling. The only thing that may not be apparent is the $! variable, but it's pretty easy to see what it is just by looking at context. What is the problem with this?

    Finally, if you dislike Perl, don't use it! Why are you even reading a Perl forum? Why are you going in depths of comments and why, for God's sake, are you participating? Do you just like conflict? Are you trying to get people angry with you so you can get angrier back at them? Why?
  • FORTRAN I through IV have no loop constructs (only GOTO).
  • Why would you not consider using Perl in a producton environment???
  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Monday October 30, 2000 @06:57PM (#663884)
    The language is horrible and unmaintainable.

    The same has been said about Pascal, C++, Ada95 and many other very successful languages. The C++ language spec takes up over a foot of space on my bookshelf, and yet C++ is my favorite language for serious programming. Perl, by comparison, is slim.

    It's the first language of most new programmers and it shows.

    Statistically, that honor belongs to Visual Basic. In college CompSci courses, Java is replacing the C family as the first-taught language.

    Most every idiot I seen write perl web apps forget how to write simple function call

    That's a problem of lousy programmers, not a lousy language. Don't blame Perl for human stupidity; the latter existed far before the former ever did.

    probably because perl does not even supprot that well.

    Perl supports functions just fine, thank you very much. Coming from a background of LISP, C, C++, Ada83, Ada95, PROLOG, Java and Fortran-95, I've got to say that Perl doesn't strike me as any more or less sensible than those languages.

    Idiots manipulating globals and strings on the stack and such, what crap.

    You can manipulate globals just as easily in C as you can with Perl. Again, this is a problem of lousy programmers, not a lousy language.

    Interestingly enough, I don't like Perl very much. I can code in it, but it's not something I enjoy. Just because it doesn't float my boat, though, doesn't mean I'm going to baselessly slander it (and make myself look like an idiot in the process).
  • Perl: the BASIC of the 90s and the 00s. People should start to learn to program in Python - it is a much better language than Perl and doesn't destroy the minds of beginning coders who hack in it. I'm one of the lucky ones who programmed in old Applesoft BASIC and didn't get their code skills wrecked from the start.
  • No, Larry Wall [linuxjournal.com] is "Weird Al" Yankovic [weirdal.com] without the hair.

    --Joe
    --
    Program Intellivision! [schells.com]
  • by eln ( 21727 ) on Monday October 30, 2000 @07:01PM (#663887)
    I may just be misunderstanding what he's talking about here, but the idea of being able to code Perl, so to speak, to look like any language (like an extremely overzealous use of macros) is worrisome from a maintainability point of view, and from a non-splintering point of view.

    Soon enough, you've got every organization, or every open source hacker, coming up with their own "little language" on top of Perl, and you've splintered the language into an unlimited number of different languages. Imagine the horror of being hired to maintain the Perl code of someone who just quit, only to find out the entire thing is written in, say, some combination of C#, Sanskrit, and Pig Latin.

    The idea is exciting from a linguist's point of view, but from a maintainability and "purity of the language" point of view, it's a potential nightmare.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...