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?
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.
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
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
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.
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
are they mad!? are they...
.NET?!
*GASP*
trying to compete with
--
Peace,
Lord Omlette
ICQ# 77863057
[o]_O
Could we have a mechanism to dynamically translate any language code, into perl. Forget Java, this is true write once, run anywhere.
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.
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
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.
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).
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.