Slashdot Mirror
Perl 6 Showcase
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."
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.
Got Code?
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.
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.
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.
---
--
If I actually could spell I'd have spelled it right in the first place.
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
-Michael
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.
-Michael
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.
Angry IT woman in big clompy boots. And talking lint!.
Try putting "!/usr/bin/perl -w" at the top of your programs - y'get a lot more ``suspicion'' error messages.
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);"
perl -e 'fork||print for split//,"hahahaha"'
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
-Michael
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:
perl -e 'fork||print for split//,"hahahaha"'
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!
GPL Deconstructed
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.
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
-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
-Michael
Ho hum. Tao/Amiga generalised VM. Runs Java, C, C++, various scripting languages + shells, and native virtual processor assembler.
Choice of masters is not freedom.
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 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 for more information.
-Michael
-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.
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
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.
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.
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.
Seastead this.
are they mad!? are they...
.NET?!
*GASP*
trying to compete with
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O
I agree... and I am glad this was said. It's a shame it was moderated down.
Point taken.
Michael Labbe
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.
cpeterso
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?
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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!
There's a spider on your shoulder.
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
-Michael
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
-Michael
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.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
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.
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
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.
IMNSHO, there really needs to be some serious outreach from the Perl6 team to the Mozart team.
Seastead this.
Perl's function syntax?? What are you smoking?
.signatures?
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
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?
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).
No, Larry Wall is "Weird Al" Yankovic without the hair.
--Joe--
Program Intellivision!
Program Intellivision!
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.