×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Larry Wall on the Perl Apocalypse

CmdrTaco posted about 13 years ago | from the great-stuff-to-read dept.

Perl 121

raelity writes "Larry Wall provides some insight into the design of Perl 6 on www.perl.com. "People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.) What I will be revealing in these columns will be the design of Perl 6. Or more accurately, the beginnings of that design, since the design process will certainly continue after I've had my initial say in the matter." " This is a really interesting article and worth reading if you're at all into Perl. Full of Wallisms, entertaining and insightful.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

121 comments

we just need a pragma (1)

Anonymous Coward | about 13 years ago | (#317297)

"pragma shutthefuckup", to eradicate those annoyingly mandatory warnings. ;-) I seem to recall that one only needed "use namespace std;" if you wanted to use the STL libraries in C++ btw.

Re:A question for Larry (2)

Anonymous Coward | about 13 years ago | (#317298)

Shoeboy, I love you. -- Heidi

Cool. .net on steroids. (3)

Anonymous Coward | about 13 years ago | (#317299)

Hey, that's cool. It does what Microsoft .net does, but better. At least it might.

One of the major ideas of .net is not SOAP (dunno why MS marketing makes such a hype about that), it's that you can write code in one language and use it in another because all languages use the same framework. So you can write an object in C# and use it (even subclass it) in another .net-enabled language. In .net, data types and class libraries aren't part of a programming language, only syntax and concepts are. Actually the framework is quite powerful, it can even be used for functional programming languages etc. (the downside is that only a limited subset will become a standard). That's Java, but better, if Microsoft gets things right.

How's that related to perl?

First, Perl will support multiple syntaxes that map onto a single semantic model. Second, that single semantic model will in turn map to multiple platforms. [...] It must be able to run in other kinds of virtual machines, such as those supported by Java and C#.

Hmmmm. Now what's that? If the semantic model is powerful enough (i.e. provides enough support to implement different programming language concepts on top of it), that's .net, but better.

I was already worried that a large part of the open source community would ignore .net, but it seems that they're about to accidentally develop an alternative that's even better. I seriously hope the Perl developers realize this possibility :-)

Re:It Could Have Been Worse... (2)

Chip Salzenberg (1124) | about 13 years ago | (#317301)

Actually, the main problem with my Topaz project was that I was limited to reimplenting the same old Perl language, because only Larry can think like a Perl language designer, and I'm not Larry. I'm very, very glad that Larry is revisiting the design of the language, because that needed doing too.

And with the language changing, maybe we can get away from reference counting, and then there won't be any need for the C++ features that led me down that path in the first place.

PS: There are no 't's in my name.

Re:What!!! (1)

WWWWolf (2428) | about 13 years ago | (#317302)

You mean Perl and Python coming together to become Parrot was just a joke??

I mean, come on. I knew it was a joke as soon as I read the stuff on the front page.

"The power of Perl and the sanity of Python."

WHAT sanity? If I ever need to obey the line breaks and whitespace rules of Python when writing Perl code, you'll soon find me at the nearest asylum... =)

(Not intended as a flame bait. Both are good languages. =)

Re:Wow... (2)

Zapman (2662) | about 13 years ago | (#317303)

Having read the article, I didn't get this at all. He is planning on forcing it for those who write modules and classes, but for the quick-n-dirty, it won't be forced.

And I imagine that once you get up to the level of project where you need to write your own modules, you probably would be using strict and -w anyway, for sanity sake if nothing else.

It Could Have Been Worse... (2)

Black Art (3335) | about 13 years ago | (#317304)

Chip Saltzenberg was trying to have Perl 6.0 be in C++.

Think of the disaster that would have been.

"What do you mean, Perl will no longer install on my Solaris box? I don't have space for C++ as well as C. ARGH!"

C++ is still not protable across platforms in any sort of reasonable sense. It would have been nice if it was.

Luckly Chip got talked out of it. (Probably with a big stick.)

Re:Um. Perl6 knows that it is perl 6 because... (1)

Tukla (5899) | about 13 years ago | (#317307)

But wouldn't it make the language a lot more readable to start with a new line like:

perl 6.0

Since when has readability been a priority for Perl?

Re:Cool. .net on steroids. (2)

The Mayor (6048) | about 13 years ago | (#317308)

You are misrepresenting .NET here. SOAP is an XML-based distributed programming protocol that is also cross-language compatible. It is more analogous to DCOM, CORBA, EJB, or RMI. The power and beauty of SOAP is that it will be fully supported by Sun ONE, IBM, and Microsoft .NET. And, of course, it's very easy to use.

Intermediate Language (IL) is what provides the COM-like capabilities to extend classes from one language to another. The two are very distinct. IL does not require a roundtrip conversion to XML. IL is more analogous to Java Bytecodes, except that there will be multiple languages mapped to IL. IL will require "managed" subsets of languages like Visual Basic, Visual C++, and Perl.

As for this comment:

Hmmmm. Now what's that? If the semantic model is powerful enough (i.e. provides enough support to implement different programming language concepts on top of it), that's .net, but better.

I was already worried that a large part of the open source community would ignore .net, but it seems that they're about to accidentally develop an alternative that's even better. I seriously hope the Perl developers realize this possibility :-)

I believe you have this 180 degrees backwards. The idea for the semantic model isn't so that other languages can be mapped to Perl. It's so that Perl can be mapped to other languages (namely, Java Bytecodes and .NET's IL). I'm not really sure what the benefit would be of mapping other languages to Perl, when so much effort is being placed on optimizing the runtime environments for Java and .NET. I think Larry's got the right idea.

Re:Cool. .net on steroids. (2)

The Mayor (6048) | about 13 years ago | (#317309)

The problem is .NET is not the glue. IL is. Or, if you want to really stretch it, SOAP is. .NET includes these technologies. But these technologies are *not* .NET. Furthermore, the goals of Perl aren't to become this said "perfect glue". Quite the contrary. Perl intends to be able to used as another language as part of someone else's "perfect glue" (namely, IL and JVM).

condradictions... (1)

garcia (6573) | about 13 years ago | (#317310)

he talks at length about how Perl 5 code has certain keywords that make it known as Perl 5 and how DEC changed BASIC to use "extend" at the top of all their code to use long variable names (and how this was bad). Well, that's all fine and good.. He seems to want to break from this tradition yet what does he do? He begins talking about "module or class" (same as Perl 5 and DEC BASIC).

The article was great if you are a Camel lover but some of us aren't (I use it for web stuff, but I am not Perl junkie :))

I am glad to see Perl continuing development, but I still think that Perl/Parrot would have been best ;-)

Re:It isn't? (4)

waldoj (8229) | about 13 years ago | (#317311)

I guess I don't understand why people need to call other people "funny" because of they're beleifs.

It's my belief that I should quack like a duck while juggling bowling balls while completely naked, in the middle of Times Square.

That's funny. It might be my belief, but it's still funny. The two are not mutually exclusive.

I also think it's funny to take "apocalypse," which is commonly defined as the end of the world, all living things die, etc., etc., and redefine it to be a good thing. In the strict sense, Larry Wall is right. Merriam-Webster says:

apocalypse
Etymology: Middle English, revelation, Revelation, from Late Latin apocalypsis, from Greek apokalypsis, from apokalyptein to uncover, from apo- + kalyptein to cover -- more at HELL
Date: 13th century
1a: one of the Jewish and Christian writings of 200 B.C. to A.D. 150 marked by pseudonymity, symbolic imagery, and the expectation of an imminent cosmic cataclysm in which God destroys the ruling powers of evil and raises the righteous to life in a messianic kingdom b capitalized: REVELATION 3
2a: something viewed as a prophetic revelation b: ARMAGEDDON


But I think it's funny to take the opportunity to take what everybody thinks of as a bad thing and turn it into a good thing, in the Christian definition. That's the Christian thing to do, I guess, is recruit more Christians. Larry Wall took advantage of an unusual opportunity to do so, and I think it's funny.

-Waldo

Re:Wow... (3)

orabidoo (9806) | about 13 years ago | (#317317)

He's just talking about the defaults; you can always put 'no strict;' after your module or class declaration.

All in all, this first introduction to LW's ideas for perl6 sounds pretty good. I'm looking forward to more details about what he plans to do with references. Blurring the difference between an array and an arrayref, as he proposes, seems like it could be either the biggest fuckup, or the biggest improvement to the perl language. I can't wait to read the proposed new semantics and see how it's going to work.

This probably goes together with giving prototypes and typed arguments to functions and methods; I wonder if perl6 is going to need an 'apply' function, to pass a list of arguments to a function (as opposed to passing the list as a single argument), like Python does. As a perl programmer, at first it sounds bad to me, but I could possibly be convinced that it's worth it.

Finally, I'm a bit skeptical about the idea of compiling perl into jvm or C#/IL. Despite all claims to the contrary, I don't see these bytecodes being generic enough to implement all of perl's functions (including its amazingly extended regexp engine) with reasonable efficiency. The OO side (integrating objects and mapping methods and properties) isn't really the problem, but I just don't see a JVM-compiled perl module using C-based extensions from CPAN, and I don't see all CPAN modules giving up C integration either. All in all, I think the perl interpreter should remain C, with a good C-based extension model (more like SWIG, and losing the "XS" obfuscated lossage), and work together with the JVM and IL interpreters, supplementing them at the C level to run perl code.

Re:Great! (1)

Elian (10270) | about 13 years ago | (#317318)

Even when perl runs on a palm you won't get the whole module set--that's just too darned big. What you'll likely see is a smallish runtime that can execute perl bytecode, and that's it. You'll need to generate the bytecode elsewhere.

Re:Um. Perl6 knows that it is perl 6 because... (1)

toriver (11308) | about 13 years ago | (#317319)

But wouldn't it make the language a lot more readable to start with a new line like:
perl 6.0

I guess you can still do a
require 6.0;
if that's what you're after. Require and version numbers have worked for quite some time, I think.

Re:Um. Perl6 knows that it is perl 6 because... (1)

Black Perl (12686) | about 13 years ago | (#317320)

you grab perl-6.0-i386.rpm and rpm -U it... problem solved

You got the command wrong. It's

apt-get upgrade

:-)

Re:It isn't? (2)

rark (15224) | about 13 years ago | (#317321)

Ah, but they die to be reborn into the kingdom of god/heaven/etc.

I'm not a xtian, I don't play one on TV..I just felt it necessary to point this out -- it *isn't* a bad thing (they way they wrote it)

A question for Larry (1)

Shoeboy (16224) | about 13 years ago | (#317322)

So I know some members of the perl 5 porters list will be reading this, and I'd like you to relay this question to Larry:

Larry,

How do you feel about having me as a son in law? I know that having a troll in the family can be a bit traumatic, and I'd like to know upfront if this will cause any problems. I'd like to work through them before the wedding, so that everything can go smoothly.

I know that you're a little disturbed by Heidi's recent spate of trolling here on /., but that was none of my doing. It wasn't until after she began trolling that we met.

You are probably also thinking that maybe your daughter can do better than a shiftless layabout who got fired from AtomFilms.com for sexual harassment, but c'mon. Think about it. Look at my flowing, golden mane, my high cheekbones, my chiseled jaw and my piercing eyes. Could any young woman possibly do any better? If you're still not convinced, you can look at my broad shoulders, barrel chest, washboard stomach and manly bearing. Now you can go have a cold shower, you probably need it.

Later,
--Shoeboy

Re:Um. Perl6 knows that it is perl 6 because... (1)

delysid-x (18948) | about 13 years ago | (#317323)

>So you would swear about perl a bit and then you give up. That's how it goes pretty much isn't it?

No, then you grab perl-6.0-i386.rpm and rpm -U it... problem solved

Re:Um. Perl6 knows that it is perl 6 because... (1)

Asim (20552) | about 13 years ago | (#317324)

Did you catch Larry's explaination as to why?

Language design is a trade-off. He's trying to avoid instanly breaking 90% of the one-lines out there, and keep the freedom the Perl is famous for, while moving on.
As he himself states, forcing folks to "use perl 5" would break everything. Settling for "use perl 6" (and, understand that there will be ways to get around this -- note his comments about "use policy") lets us get on with the concept of coding, and not with the concept of re-coding. Going to be hard enough to re-write all these modules...

----Woodrow

Wow... (3)

hugg (22953) | about 13 years ago | (#317325)

Does anyone know a person who is both an expert (*complete* fluency) in both C++ and Perl? I have a feeling that these two languages are too large to be contained in a human head at the same time.

Perhaps we will have to evolve super-intelligent Khan-like coder clones in the future, using nanotech, Beowulf clusters, and in-dash Atari 2600 emulators.

use module vs use Perl 6 (1)

Dunx (23729) | about 13 years ago | (#317326)

I think Larry's solution to the problem of flagging Perl 6-ness in a program is pretty clean for modules and included libraries (ie defining a 'module' as a 'package with strict turned on'), but I would be very unhappy about a "use Perl 6" pragma. The problem is that by putting a specific Perl version number in a pragma like that you are tying the features being invoked to the particular version of Perl, which is going to look a bit dumb when we move up to Perl 7.

I know this isn't really any different than requiring a particular version of a library, but it just seems ugly to me. Still, very much looking forward to reading the rest of the Revelations of Larry.
--
Dunx

Re:A question for Larry (1)

rinkjustice (24156) | about 13 years ago | (#317327)

Stay clear of Shoeboy people. The buckshot spray from Larry's shotgun could potentially injure others!

Re:Wow... (5)

EvlG (24576) | about 13 years ago | (#317329)

FINALLY someone who agrees with me about the needless additions to C++

Every time I go into a bookstore to read about C++ (every 4-6 months or so) I find out about more and more "features" that were added since I learned the language in 1995 or so. Stuff like 3 different versions of new and the namespaces.

IMO C++ has grown from being a useful extension of C to becoming a massive, horrible mess with too many features. Lots of people I know and work with talk about C++ in terms of being hard to learn and use well because it is extremely intricate. This is a good thing?

I'm disturbed by some of the more recent proposals for C++. Whitespace overloading?!? ho are we kidding?

I'm just glad that other people find solace from the insanity of C++ in Perl. Sometimes its refreshing to be able to choose your own way to do things, and to know that other people like you just want the damn program to work, with a minimum of futzing with things vaguely related to the problem you are solving (i.e., memory management ala C++ -- just how to exceptions and delete interact in a class hierarchy?) Who cares - every app I have written in the past 2 years has not needed to worry about these sorts of vaguely related things - why FORCE me to? Preaching the "paradogma" (great word Larry :) is just annoying.

There are certainly a number of cases when you NEED to care about those mundane, tedious details. Real-time programming and other systems level work are good examples.

I guess all I am saying is, thank you Larry, for freeing programmers like me from the tedium of malloc and free, sizeof and screwy arrays. You have added 20 years onto my lifespace, at least.

The Perfect Number (2)

qta (28282) | about 13 years ago | (#317330)

In apocalyptic literature, 7 is the number representing perfection, while 6 is the number representing imperfection.

Larry, I think number theorists would crack that, contrary to general belief, the number 6 is one of those most significant and rarest of numbers belong to the perfect number category. Those number have their divisors added up to themselves (6=1+2+3). The other perfect number is 28 (28=1+2+4+7+14). Perhaps someone will be able to point out the others.

But whatever the perfect number, I am sure that Perl 7 will be more pearly than Perl 6 :)

Re:Apocolypse (1)

sidesh0w (32371) | about 13 years ago | (#317331)


Armageddon (the field of Meddigo, site of an especially bloody historical battle) is the location of the final battle. Apocalypse is synonymous with revelation, e.g. Revelation of John == Apocalypse of John in the Bible.

Re:condradictions... (3)

yomahz (35486) | about 13 years ago | (#317332)

he talks at length about how Perl 5 code has certain keywords that make it known as Perl 5 and how DEC changed BASIC to use "extend" at the top of all their code to use long variable names (and how this was bad). Well, that's all fine and good.. He seems to want to break from this tradition yet what does he do? He begins talking about "module or class" (same as Perl 5 and DEC BASIC).


I think you may have read it wrong. He was simply stating the way that perl6 modules would be declared is different than perl5 modules.

Nothing was added, just changed.

The quote follows:


A closely related question is how Perl is going to recognize when it has accidentally been fed Perl 5 code rather than Perl 6 code. It would be rather bad to suddenly give working code a brand new set of semantics. The answer, I believe, is that it has to be impossible by definition to accidentally feed Perl 5 code to Perl 6. That is, Perl 6 must assume it is being fed Perl 5 code until it knows otherwise. And that implies that we must have some declaration that unambiguously declares the code to be Perl 6.

Now, there are right ways to do this, and wrong ways. I was peeved by the approach taken by DEC when they upgraded BASIC/PLUS to handle long variable names. Their solution was to require every program using long variable names to use the command EXTEND at the top. So henceforth and forevermore, every BASIC/PLUS program had EXTEND at the top of it. I don't know whether to call it Bad or Ugly, but it certainly wasn't Good.

A better approach is to modify something that would have to be there anyway. If you go out to CPAN and look at every single module out there, what do you see at the top? Answer: a ``package'' declaration. So we break that.

I hereby declare that a package declaration at the front of a file unambiguously indicates you are parsing Perl 5 code. If you want to write a Perl 6 module or class, it'll start with the keyword module or class. I don't know yet what the exact syntax of a module or a class declaration will be, but one thing I do know is that it'll set the current global namespace much like a package declaration does.

--

A mind is a terrible thing to taste.

Re:Seriously, Perl *is* scary! (1)

MadAhab (40080) | about 13 years ago | (#317333)

Too bad that was anon - it was funny. When I finished the next major revision of my script for rapid porn downloading I would have sent it to you.

It doesn't work right now, because I'm in the middle of revising the core fuzzyfying functions for searching on variants of, for example /yoursisterstits/images/poolbabe1.jpg to find backup files and additional images not listed in the thumbnail gallery, plus revising the user interface for declaring the method of fooling mod_referer, but who am I kidding. I don't have that much time to look at porn.

Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.

Re:Shameless fan mail :-) (1)

hawkestein (41151) | about 13 years ago | (#317334)

I think this article is interesting in that it gives some rare insights into language design. You always hear people complaining about why didn't x (where x is C++, Java, Perl, etc) do this or that? Why this feature or syntax? Here Larry points out some trade off that may not be obvious to "end user". And all written in a easy to understand language called English too ;-)

I'd recommend that you read "The Design and Evolution of C++" by (who else?) Bjarne Stroustrup if you're interested in this kind of non-academic language design. The book's a bit old, so it's missing some of C++'s newer features, but it's a fun read if you like that sort of thing.

Re:Wow... (2)

pos (59949) | about 13 years ago | (#317335)

Right on!

IMHO, they should have been addressing some of the design patterns that are harder to implement in C++.

I mean just look around at what people *want* to do with the language. Look at Qt and their .moc files. Why not add that to the language and save Qt and everyone else some time? Most people who have tried signals and slots agree that it's a pretty good, straigtforward implementation.

just my 2 cents...

-pos

The truth is more important than the facts.

Re:Wow... (1)

idistrust (66924) | about 13 years ago | (#317336)

Well I don't mean to brag but I am completely fluent in C, C++, Delphi, Assembly, Perl, Python, English, Spanish, ...ugh. Who the hell am I kidding...

Mike.

Re:Thanks to Larry and Tim: Paying for the vision (1)

mcjulio (68237) | about 13 years ago | (#317337)

You're cynical. O'Reilly doesn't do what they do just for the money. If that was their only motivation, they'd publish porno and run virtual blackjack tables. Publishing tech books is sometimes profitable, but it's extremely labor-intensive.

This is the right direction for Perl (3)

mcjulio (68237) | about 13 years ago | (#317338)

First of all, it's sad that Slashdot couldn't hold notable members of the Perl community. Makes me a bit wistful to look over the nearly content-free posts on this topic and remember Abigail's scathing and 100% accurate flames, and Tom Christensen's odd and brilliant posts. Assholes, maybe, but their minds are unparalleled and their writing incisive. They're sorely missed in a discussion like this.

In any case, Perl is in good hands. Require strict and warnings for modules makes sense. Leaving room for Perl to grow is a good thing. Making everything an object that is free to return in scalar context adds flexibility while giving functions the freedom to behave as they see fit.

Most of all, these principles are in place before the major work of adding full Unicode support and meta-languaging begins. There's a firm hand on the tiller, and Larry seems as up for the work as he ever has been.

When Perl has a real specification, period. (1)

alispguru (72689) | about 13 years ago | (#317339)

It will be worth people's time to write real compilers for (Perl/Python/Ruby/whatever) when there are real, non-platform-specific specifications of what the languages mean, so compiler writers have something to aim at that won't move out from under them.

This is the fundamental reason why languages defined by portable implementations have problems growing beyond those implementations. The implementation actually specifies too much of the langauge's behavior - a real spec says explicitly what behavior is implementation-dependent, which tells implementors and users both exactly where the boundaries are.

The Common Lisp and Scheme communities wrote real specs for their languages (ANSI and IEEE, respectively). The user communities routinely beat up implementors and vendors who don't conform to the spec. As a result, they can write portable programs that compile to native code, without getting stuck in the C/C++ quagmire.

Someday there may be a way to answer these questions:

Are JPerl and Perl the same language?
How about JPython and Python?

that doesn't boil down to "ask Larry/Guido". A year or two after that, you might see real compilers for those languages.

Re:Wow... (1)

Bassthang (78064) | about 13 years ago | (#317340)

He is planning on forcing it for those who write modules and classes,

No, he is planning (suggesting?) that that should be the default. Perl rarely forces anything.

perldoc -f no

Re:condradictions... (2)

Bassthang (78064) | about 13 years ago | (#317341)

the "module / class / package" thing is very similar to the change in LaTeX [tex.ac.uk] from v2.0.9 to v.2e, where files changed from starting with \documentstyle to starting with \documentclass. It was easy to start using 2e and backwards compatibility was easily maintained

Re:use module vs use Perl 6 (1)

Yer Mom (78107) | about 13 years ago | (#317342)

We have that already, though - require 5.04; will cause pre-5.04 versions to drop dead, while allowing 5.04 and all subsequent versions of perl to carry merrily onwards...
--

Re:Wow... (1)

fanatic (86657) | about 13 years ago | (#317343)

"You must use warnings and strict everywhere except your main module" is not free and fun.

Unless I misunderstand, I think that nothing stops you from saying:

no strict;
no warnings;

after your module or class or whatever statement if you really want to. Frankly, I think "encouraging" module writers to be -w safe is a great idea. One of my favorites is hideously noisy with -w, (unless it's been rewritten recently); every time I use it I have to look at the output and remember whether this means it failed or if it's just the usual noise.

--

Re:PERL MONGERS READ THIS (1)

fanatic (86657) | about 13 years ago | (#317344)

You can't even wait for the *design* to be complete before you flame it? Amazing. Larry was pretty smart for perl5, but dumb for perl6? How did that hapen?

--

Re:Proof that P users are stupid. (2)

fanatic (86657) | about 13 years ago | (#317345)

Example: Perl's pitiful documentation compared to Python's rich, perfect, strait-from-the-mounth-of-god, Guido himself documentation.

Either you jest or you display ignorance. The perl distribution comes with tons of doc. Try issuing perldoc perldoc. You can use perldoc -f function_name_here to get information about any perl function and perldoc module_name_here to get documentation about any module for which the author has provided it (which is most of them if not damn near all of them).

More to the point, try man perl - each of the 70 sections is its own extensive man page, covering references, objects extensions in c - you name it it's probably there.

Oh, and how extensible is Perl? I never heard of an applet written in Perl.

What do these 2 sentences have to do with each other? many meabytes of perl extensions can be found at CPAN [cpan.org] - I don't believe I've ever wanted to do something that wasn't made much easier by something that was already there. What does writing applets have to do with exensibility? perl is quite extensible in both perl and c. And there is a project to compile perl source to java bytecode, tho I'm not sure if it's still active. But client side applets aren't my main concern. I don't think they're flavor of the week anymore, anyhow.

--

Re:Cool. .net on steroids. (1)

gazz (101967) | about 13 years ago | (#317348)

Maybe he/she/it was suggesting that the .NET framework equivalent be built in Perl..perfect glue..
I'd be up for that..
..anyone know of a project going, let me know...

Re:Seriously, Perl *is* scary! (1)

haystor (102186) | about 13 years ago | (#317349)

The essence of Perl is really context sensitivity, not just to syntactic context, but also to semantic, pragmatic, and cultural context.

This is a really big part of Perl for myself. After learning a certain amount of the language, I was able to start guessing at how perl would work, and it would usually work that way. Where the more designed languages seem to have just mandated the way things are done, Perl tries to interpret as many ways as a user might think of doing them. This is not an easy task, and once accomplished can yield some very ugly, bad code.

It goes something like this: I say, "I wonder what would happen if I tried xxx." Perl will do it the way I want. C doesn't work that way. Java will surely have deprecated the useful way of doing it because it wasn't supported on a common architecture like the Timex Indiglo.

Re:condradictions... (1)

andy@petdance.com (114827) | about 13 years ago | (#317350)

He begins talking about "module or class" (same as Perl 5 and DEC BASIC).

I think the point was that the EXTEND keyword at the top of the DEC BASIC programs served no purpose other than to say "I am a new program", whereas the (proposed) Perl 6 method merely replaces the "package" keyword with something else. The keyword has to be there anyway. Changing from "package" to "class" just overloads the meaning.
--

Thanks to Larry and Tim: Paying for the vision (2)

andy@petdance.com (114827) | about 13 years ago | (#317352)

I dropped an email to Larry and to Tim O'Reilly thanking them for the work that Larry's been doing on Perl.

I think it's great that Larry is taking the time to be the visionary and leader on Perl, and providing so much of himself in what goes into Perl 6.

And I think equally important is that O'Reilly [oreilly.com] are basically paying Larry to do it. As far as I know, Larry's been getting a paycheck from ORA for just doing the Perl stuff that he does, not unlike Damian Conway getting a paid year sabbatical to be Damian.

That salary for Larry has to be some of the best investment in the community and infrastructure of software development yet, and I cheer Tim & co. for doing it.
--

Re:Summoning lost spirits (1)

ekidder (121911) | about 13 years ago | (#317353)

Where I work, we use perl for just about everything - and almost none of it is web work. We use perl for most of our database stuff (I just wrote a simply badarsed little program, too.. happy sigh..) using oraperl and it's sweet loving. Frankly, ever since I started using perl for non-web stuff, I can't even imagine using perl for the web. I suppose it's nice, but it just has so much more potential uses.

The perfect language (2)

donglekey (124433) | about 13 years ago | (#317356)

I have thought about this sometimes and haven't come up with a definite solution because there eally isn't one. But I think that most languages in widespread use are good, but have some flaw in them.

I think that java approches being a really great language, but stops short because it is so god awful slow. It is also very verbose and although I like it, it doesn't go as fast as perl,python, or php. What it does have is stability, consitency, and standard libraries that come with every runtime environment. If perl 6 had classes remenicent of pythong, came with a full featured standard GUI (TK is quick,dirty, and fast but doesn't compare to the feature set of swing), standard thread, standard complex sound IO, and standard socket set that's more straightforward, I would never use anything else. I know its alot, but if that was there, then I think the language would be much more complete, then other stuff could be added with modules.

What!!! (3)

washirv (130045) | about 13 years ago | (#317358)

You mean Perl and Python coming together to become Parrot was just a joke?? I had totally believed it seeing as it was on Slashdot and all....

Re:Wow... (1)

rgmoore (133276) | about 13 years ago | (#317359)

I also get the impression that even if using warnings and strict is the default behavior, it will still be possible to turn it off if that's desirable. IIRC somebody suggested that there be something like a use loose pragma that would turn off default strict behavior, and it's already possible to selectively turn off warnings for particular blocks of code. I don't think that anyone has seriously suggested making Perl a Bondage and Discipline language where everything must be done just so.

Re:Proof that P users are stupid. (1)

rgmoore (133276) | about 13 years ago | (#317360)

I never heard of an applet written in Perl.

Which just means that you're not looking. In fact, there is currently a reference to an article on writing Gnome panel applets [perl.com] in the Perl slashbox here on slashdot. Your lack of knowledge does not mean that it isn't being done.

Re:use module vs use Perl 6 (1)

rgmoore (133276) | about 13 years ago | (#317361)

There's already a use [version] pragma that requires that the Perl in use be [version] or higher. IOW, use 6.0.0 would not prevent the code from working in a hypothetical perl7.

Re:Wow... (2)

The Pim (140414) | about 13 years ago | (#317362)

Does anyone know a person who is both an expert (*complete* fluency) in both C++ and Perl?

It just so happens that I know exactly one such person--and he is (without a hint of exaggeration) a mind of genious caliber. Hmm... Well, I guess you've taught me that I should forget about becoming a C++ expert. Thanks!

Not very definite (1)

Mr_Person (162211) | about 13 years ago | (#317364)

Some things aren't good. They should be changed. But some people wouldn't like that and it would break backwards compatibility. Maybe it shouldn't be changed. Who knows?

Is it just me or does that pretty much sum up the article? Not being a troll, but for being articles that are supposed to define what direction Perl will be headed, they don't seem to give any definite answers.

I think that Larry took on a much bigger job than he anticipated when he decided to completely rework the language. Making a language that is entirely perfect, yet all things to all people is impossible and he will have to realize that before any real work will get done!
--
(Mountain Dew == Canned Code)

Seriously, Perl *is* scary! (1)

fm6 (162816) | about 13 years ago | (#317365)

Like most good jokes, this one has a serious side. Wall's article provides us with many examples. Consider:
People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people.
Naturally, Wall uses English the same way he designs Perl language constructs. Few people would use the word "Apocalypse" this way. But Wall's usage makes sense, if you stop, think about it for a few minutes, and maybe go consult a reference book. How many times have you had the same experience while reading Perl code?
The essence of Perl is really context sensitivity, not just to syntactic context, but also to semantic, pragmatic, and cultural context.
Gawd, that's a lot to lay on a simple programming language! But of course this is why so many Perl constructs have complex, subtle behaviors.

In a way, this is a variation on Microsoft's Always-Second-Guess-The-User mentality. The difference is that MS assumes all users are idiots, and Wall assumes all Perl programmers are like him: gifted creative people who prefer non-linear thinking.

OK, this is nothing wrong with this. I'm not part of the Perl culture, but I respect it. Just try to remember that the ultimate purpose of all software is for somebody to use, not just to show how clever you are.

__

Um. Perl6 knows that it is perl 6 because... (2)

WolfWithoutAClause (162946) | about 13 years ago | (#317366)

it starts with non package?

Sure that works. Sure.

But wouldn't it make the language a lot more readable to start with a new line like:

perl 6.0

Then newbies would be more likely to guess why their perl5 compiler/interpreter croaks??

No of course not. That would make no sense. They wouldn't have to buy a book from a certain well known publisher to use Perl...

So I'm cynical. Call me cynical.

Re:Um. Perl6 knows that it is perl 6 because... (2)

WolfWithoutAClause (162946) | about 13 years ago | (#317367)

Yes, but with linux the sys admin usually IS the user. And you download this fantastic neato perl app thing over the internet and... and... it doesn't work.

Of course your perl came bundled with the OS and is a version behind.

So you would swear about perl a bit and then you give up. That's how it goes pretty much isn't it?

Re:Um. Perl6 knows that it is perl 6 because... (2)

WolfWithoutAClause (162946) | about 13 years ago | (#317368)

Yes. So you leave perl 6.0 out and... the system defaults to perl 5.0 syntax or if you're really being crude it just runs perl 5.0 instead. And this is hard because?

To a reasonable approximation either the 6.0 system understands 5.0 syntax or it doesn't. If it doesn't its going to come unstuck anyway when people try to run it on legacy code. If it does, and Larry seems to imply that it does to some extent, then there's no excuse for making this harder for users.

A language should beg people to use it. It sells more books too.

Re:PERL MONGERS READ THIS (2)

mnemex (165180) | about 13 years ago | (#317369)

Man, did you -read- the Apocalypse?

Larry wasn't talking about making functions return the current, bloated implementation of objects -- he was, instead, talking about adding a new implementation of object (based on a C struct) to perl, and having them return those -- implemented well, this shouldn't be much slower than the current (parsed) implementation such things, especially since often what you'll lose in having to make sub calls for stringify and numify you'll win by not having to translate the original structs in the first place.

An object is just a concept, not an implementation.

Josh -- (of NY.pm)

Perl versioning... (1)

Sayjack (181286) | about 13 years ago | (#317371)

I think history shows that Larry will retain as much backward compatibility as he can while producing a truly evolutionary new version of Perl.

Perl is as much a culture as it is a programming language.

I personally do not like the idea of using the existence of "package" as a way to distinguish perl5 from perl6. While this works for the modules, what about non package applications?

There's already a require VERSION convention established. The new version of perl could require that this be supplied to activate perl 6 functionality. Scripts without this would be assumed to be at 5.x.

- Pat

Re:The perfect language (1)

Sayjack (181286) | about 13 years ago | (#317372)

I think that java approches being a really great language, but stops short because it is so god awful slow.

Don't confuse design with implementation. Java is a great language with mediocre implementations and monolithic amounts of class library rushed out the door to feed the ravenous programming public at large. Java has enormous room for improvement in the realm of performance.

The java language itself is rather elegant, right down the the bytecode operations.

However, at the moment, we're talking about Perl.

Before Perl, I would have defined a great language as one with a straightforward and clear design. Java qualifies, however, Perl is none of these in my opinion. Perl can't be described in BNF -- it requires a magical context sensitive tokenizer sprinkled with magic Wall-ian pixie dust. Yet, without question, Perl is a great language too.

Perl has forced me to redefine my definition of a great language as one which effectively fulfills the needs of it's users. This is something which even the angriest python evangelist would have to agree that perl does well.

There are tasks I can accomplish in a 1/2 hour of perl coding which would take me days to accomplish in java. Programming perl is also more fun to me...I don't know why. Perhaps this is due to it's "more than one way to do it" philosophy which provides me with countless options. Perhaps it's the unix based culture that I love. Or perhaps it's the overall goodhearted spirit behind the majority of the Perl community that Larry has carefully fostered.

I wouldn't, however, want to manage a million lines of perl code. One of the things I've noticed is that the better the perl programmer, the harder it is to read their code.

Perl is the language which allows you to do in 1 line, what you should have done in 20.

Re:PERL MONGERS READ THIS (2)

metis (181789) | about 13 years ago | (#317373)

First, since "basic" data types in perl are internally complex data structures, returning objects does not make such a big difference in perl as it does in c++.

Second, Perl5 is already ebject oriented. But the OO stuff is kind of kludgy and particularly unieldy when dealing with class hierarchies. I cannot see how moving OO features to the core, as I understand is planned, and cleaning up the way inheritence is handled based on Perl5 experience can make Perl6 worse than Perl5. This is not adding features, this is correcting suboptimal design.

Re:hrmm, perl is still better than PHP for web wor (1)

groomed (202061) | about 13 years ago | (#317376)

I don't think it is "better for web work, period". What you think of as an advantage (100 ways to do templating) some people think of as a liability.

In any case, I don't care much for the kind of data acquisition slash web proposition you're describing anymore. But if Perl is helping you to develop an exciting application, more power to you.

In fact it might be illuminating to hear, from your application's point of view, what you reckon might be the most exciting new feature in Perl 6.

Re:Summoning lost spirits (1)

groomed (202061) | about 13 years ago | (#317377)

Indeed, who doesn't love Perl for it's ability to churn out simply badarsed little programs!

Still I can't help but feeling that the language has somehow aged (rather than matured) over the last couple of years. People just don't seem to be as enchanted with Perl as they used to be, and "Perl 6" in places seems motivated by a strong sentiment to regain this lost sense of wonder, instead of by concrete applications that Perl could be or should be targetting.

But, I know nothing.

Summoning lost spirits (2)

groomed (202061) | about 13 years ago | (#317378)

At the time when I first encountered Perl, around 1996, I thought it was wonderful. But it was wonderful, because I could easily see, what with it's powerful text processing, easy networking and platform independance, how it could play a major part in doing wonderful things on the budding web.

But nowadays, I'm bored stiff with (programming for) the web, and likewise, my interest in Perl has waned. Also not unimportant, stuff like PHP has basically taken the crown from Perl where it comes to web development.

This is not to say that Perl doesn't have a place. Perl lends itself extremely well to perlish things. It's just that the excitement surrounding Perl seems to have diminished.

And so sometimes I cannot help but wonder whether this longish and rather dramatic prelude to the start of the preliminary design for Perl 6 is really not just a way to try and summon some lost Perl spirit; to try and recapture some of the excitement of yore.

Does the world really need another Perl? And if yes, what should it provide? The answers to that last question seem to oscillate wildly between grand visions of syntax independance and mundane matters such as thread support.

Frankly I think neither answer is very exciting. Grand visions are a dime a dozen, and thread support is just thread support.

The bottom line, I guess, is whether Perl 6 will succeed in targetting an application, or whether it will just succumb to change for the sake of change.

Let's just hope for the former.

PERL MONGERS READ THIS (3)

jfonseca (203760) | about 13 years ago | (#317383)

Larry is out of his mind. He's creating perl++ and he's accepting the anti-UNIX pro-BLOAT RFC's. I confess I never expected that from him.

- Everything will be an object.

This is ridiculous. I always chose C over C++, now I'm choosing perl5 over 6. Period. I'm a perl5 monger(brasilia.pm.org) now. There'll be perl6 mongers. I'll call them the PERL BLOATERS. I can write better perl with perl5.

- 'package' means perl5 otherwise 'use perl6';

A FCKING PATCH. MICROSOFT STYLE, LARRY. Go for it.

- Perl will stay perl.
Uhuh. And we're all stupid and can't tell. Perl 5 is PERL, 6 is PERL++.



Conclusions

Yeah, just like Samba we're going to see 2 perls from now on. I'm sticking with 5. Most will move to 6.

Fine with me. Just glad I dig perl 5. If others agree just show you do by writing better perl 5!!!!

Re:Wow... (1)

BlowCat (216402) | about 13 years ago | (#317386)

Imagine introducing namespaces in Perl and adding "use namespace std;" to every Perl program that uses e.g. printf.

That would be the real Perl Apocalypse.

When will the Perl compiler make real executables? (3)

Schwarzchild (225794) | about 13 years ago | (#317387)

To me, things will get interesting once one of these languages actually starts delivering a non-trivial, high-performance native code compiler. I don't mean the kind of simple translation to C code that exists for Perl and Python, but something that actually genuinely increases performance and figures out stuff about data types. Will anybody be up to the challenge? That remains to be seen.

I am disappointed by the fact that Perl can not deliver compiled code. The help blurb on the Perl executable says that the compiler option is experimental! When will this not be experimental?

Shameless fan mail :-) (4)

Codeala (235477) | about 13 years ago | (#317388)

I think this article is interesting in that it gives some rare insights into language design. You always hear people complaining about why didn't x (where x is C++, Java, Perl, etc) do this or that? Why this feature or syntax? Here Larry points out some trade off that may not be obvious to "end user". And all written in a easy to understand language called English too ;-)

While this is not a complete redesign, it is not everyday you get to see just exactly one design an programming language used by millions of people. Good stuff, definitely stuff that matters. This is a must read for people interestined in programming language. I am really looking forward to the next one.

OT: The design of Perl6 is somewhat similar to the kernel: anyone can submit rfc (patch) and Larry (Linus) has the final say on what goes it. (No, I don't know where I am going with this either :-)

====

There is a perfect language - C (1)

WindowsTroll (243509) | about 13 years ago | (#317389)

C, although often abused and maligned, it the perfect language. It is well suited for writing compilers and device drivers. It is equally well suited to writing full blown applications. Does anyone remember WordPerfect for Dos or Word for Windows that ran in under 300K of memory?

As for classes, they are certainly easier to impliment in C++, but well structured C code can be made to behave very similarly, and without much extra effort. The class implimentation in perl seems rather odd and unintuitive.

Re:we just need a pragma (1)

Dancin_Santa (265275) | about 13 years ago | (#317391)

Just about all useful functions have been moved to the std namespace. sprintf, cout, cin, string, vector, etc have all been moved up. It's possible to write a program without using the standard library, but it's pretty hard.

Dancin Santa

Re:Wow... (1)

Dancin_Santa (265275) | about 13 years ago | (#317392)

That's the impression that I got also, and it has a certain ring to it. However, I find this akin to Java's mandatory exception handling or Python's mandatory code blocks. Nice in theory, but heavy handed in real life (like a large program with many modules). Perl's motto has always been TIMTOWDI, but this change makes Perl a little Rubyesque - there's a better way to do it.

Dancin Santa

Re:Wow... (1)

Dancin_Santa (265275) | about 13 years ago | (#317394)

No one stops you from opting out of Spam mailing lists either, but it's something that I'd rather not do. If I want to play with something, I'll explicitly say so.

As far as your favorite module, it would be helpful for you to make it -w quiet yourself or to ask the module author to do it. This is why Open Source works, isn't it?

Dancin Santa

Re:It Could Have Been Worse... (1)

Dancin_Santa (265275) | about 13 years ago | (#317395)

A Perl interpreter built from the ground up might be fairly interesting. I imagine that if LW were to start the Perl project today he might use C++ as the implementation language. I think Topaz just got too big too fast for Chip to handle by himself. If he had had a C++ source base, though, I think we'd be looking at a somewhat cleaner design.

Dancin Santa

Re:Wow... (5)

Dancin_Santa (265275) | about 13 years ago | (#317397)

I have to agree. The amount of extra baggage thrown into C++ in its last rev is enormous and much of it is extraneous, IMO.

The most notable, for me, is the addition of namespaces. While I understand and agree with the idea that unused functions shouldn't pollute the global namespace, I find that moving all of C++'s standard functions into a separate namespace overkill. It isn't like C++ programmers were having trouble coming up with function names that clashed with strcmp(), for example. What this leads to is the extra line

use namespace std;

in many programs. In essence, the moving of all these functions into a separate namespace just forced developers to create a rote workaround, not unlike the issue Larry brought up with class or module.

Perl itself has grown over the years, and while many changes have benefitted the programmers and opened up many doors (references, objects, etc) the core language has changed little. Larry seems to be moving away from the spirit of TIMTOWTDI and more towards the BSDM style of language exemplified by Java (or insert a language you love to hate). "You must use warnings and strict everywhere except your main module" is not free and fun.

There is no doubting the efficacy of -w and use strict;. I use it in all my own Perl programs, but many don't. This used to be okay. When I used to answer questions on clpm, I always chided querents for not using them. It was good advice (just turning on warnings can help nail a problem in many cases), but they could always take it or leave it. Now in Perl 6 it seems that this attitude that what goes on between programmers and the language is none of our business is done away with, and a school marm with a quick ruler is the new paradigm.

I grew up in Perl during Perl 5 and always laughed at the backwardness of those who touted Perl 4's abilities (Alaskan electrician, Purl Gurl, etc.), but now I find myself wondering if I am exhibiting the same stubbornness. If I am, am I right in this? Perhaps I need to change with the language?

Dancin Santa

Re:Perl is an ugly horror (1)

duskus_maximus (310094) | about 13 years ago | (#317400)

Mhmm. Your insolence is amusing/irritating. Maybe you should get a clue and bow before St. Larry, you heretic.

Perl 6 (4)

duskus_maximus (310094) | about 13 years ago | (#317401)

As a perl scripter, I should probably keep up on perl development. A few `features' I hope I find in Perl 6 are:

Threading - MP3::Napster, a popular module written by Lincoln Stein requires a threaded perl interpreter; I happen to use this module for my project [no-ip.com] (spam, spam [grin]).

More perl ports - I would like to see perl ported to PalmOS; some nodes on PerlMonks [perlmonks.org] reveal that there is a lot of interest in this; Although I sometimes wish they would take a look at the projects on handhelds.org [handhelds.org] .

Dusk begins to realize that he is ranting....

Anyway, I am sure that I will be pleased with the results; Saint Larry will not let us [perlmonks.org] down :)

Great! (5)

Anna Mouse Cowherder (323205) | about 13 years ago | (#317402)

Hopefully the rewrite will make it possible to port Perl to Palm devices (that outta be a tongue twister.) The core install of modules that come with Perl this days are far too large to fit into the memory footprint, and I'm looking forward to the day when I'll be able to script on a Palm device (using a foldout keyboard of course.)

My guess it that Python porters were able to overcome this obstacle by writing much of Python in Python itself, hence Pippy. [endeavors.com]

Once Perl 6 is released, though, the Perl community will be able to quickly play catch up, and get a port out rapidly. Woohoo!

the world is full of scripting languages (1)

janpod66 (323734) | about 13 years ago | (#317403)

Yes, I realize lots of people get really attached to Perl and particular other scripting languages. But the world is full of scripting languages like that. Overall, they offer roughly the same performance and they offer similar functionality. Some of them have slightly better libraries, others have somewhat better error detection, and yet others are somewhat easier to embed in C/C++ programs. Writing one of those byte-code interpreters isn't particularly hard, which is probably while there are so many of them around (Perl, Python, Tcl, Ruby, Lua, awk, etc.).

To me, things will get interesting once one of these languages actually starts delivering a non-trivial, high-performance native code compiler. I don't mean the kind of simple translation to C code that exists for Perl and Python, but something that actually genuinely increases performance and figures out stuff about data types. Will anybody be up to the challenge? That remains to be seen.

Until then, I won't hold my breath for Perl6. In fact, I don't much care. Perl5 is good enough for what I use it for, and there are lots of other choices around when Perl5 isn't good for the task.

Re:It's called Dylan. (1)

janpod66 (323734) | about 13 years ago | (#317404)

By "these languages", I mean languages that are used like Perl and Python in the UNIX and Linux world.

Dylan is in the same boat with Smalltalk, CommonLisp, Scheme, and Self: great languages with great technology, but they are little used among UNIX and Linux users to do the kinds of things Perl or Python are used for.

Re: It's called Dylan. (2)

janpod66 (323734) | about 13 years ago | (#317405)

I think there are other reasons as well. CommonLisp is a real mess in some areas and some of its designers had such disdain for UNIX that it seems to try hard not to live well in a UNIX environment. Both CommonLisp and Smalltalk were pushed along for many years by greedy companies with big dollar signs in their eyes, killing any possibility of grassroots adoption. Dylan and Self missed the boat compared to Java and Python because they did try to be so much more.

I have to say, though: of the currently popular scripting languages, Python seems to closest to becoming a real programming language, and it's still retaining its original utility and simplicity. What Python is missing at this point is a new implementation that provides incremental compilation to efficient native code, plus a few language cleanups to go with that.

*Engineered* versatility!!! (1)

oodl (398345) | about 13 years ago | (#317406)

> You don't have to use the same language to write a device
> driver that you do for a web app, or GUI db front end, or
> client side HTML form validation, etc.
>
> If you think you do you're a jackass
> There is no all-encompassing perfect langauge, just a perfect language
> for the job at hand. Sometimes you need to put out an application quickly,
> sometimes you need to put out an application that runs quickly.

WRONG! Versatility CAN be designed into a language. Take the Dylan programming language for example. It allows a broad range of dynamism vs. staticism... at the discretion of the programmer. Take for example Dylan's use of optional typing that can be used by the compiler for optimization of code. You can write a prototype version of application without any types, and then just sprinkle in typing info where needed to improve the performance of bottlenecks. With Dylan you can put out an application quickly and then make it run quickly... not re-write it in a different language. See http://www.gwydiondylan.org and http://www.functionobjects.com
for more details.

And Dylan is better than Python and Ruby (1)

oodl (398345) | about 13 years ago | (#317407)

And Dylan is smarter, faster, better than Python or Ruby (unless you just want to embed a language interpreter in your app).

Dylan compilers are written in Dylan!

Self-extending languages (1)

oodl (398345) | about 13 years ago | (#317408)

I forgot to mention that the Dylan programming languages is self-extensible via its hygenic macro system.

I'm sorry, but I think a serious general-purpose language without hygenic macros is just lame in this year of 2001.

It's called Dylan. (1)

oodl (398345) | about 13 years ago | (#317409)

To me, things will get interesting once one of these languages actually starts delivering a non-trivial, high-performance native code compiler
That language exists, and it's called Dylan. Dylan is highly abstract and flexible but can be efficiently compiled. There are two good native code compiler Dylan implementions already (one is really excellent).

Re: It's called Dylan. (2)

oodl (398345) | about 13 years ago | (#317410)

And the sad reason that the great technically superior languages aren't used by more people is basically because not many other people using them. Face it, the average programmer is basically a herd animal. With the adoption of new languages we have the chicken and the egg problem... which is very hard to escape from (except through superior marketing (as in the case of Java) or with an 800 kilogram gorilla promoting the language (i.e. Microsoft and their ridiculous languages). To paraphrase Guido "Dylan is like Python, but so much more".

Re:Great! (1)

darrick (413403) | about 13 years ago | (#317413)

>I'm looking forward to the day when I'll be able
>to script on a Palm device (using a foldout
>keyboard of course.)
Yea, the keyboard would help. It gets really tiring trying to do #, $, >, %, &, and ! in Graffiti all the time, over and over.

Re:Proof that P users are stupid. (1)

virtig01 (414328) | about 13 years ago | (#317415)

Or maybe this just proves that PerlPeople just can't communicate. Example: Perl's pitiful documentation compared to Python's rich, perfect, strait-from-the-mounth-of-god, Guido himself documentation.

Oh, and how extensible is Perl? I never heard of an applet written in Perl. Sure there is Jython, but no Jerl (it sounds too stupid).

I believe someone else mentioned Perl on a Palm, and how it doesn't exist. But Python is mighty Pippy on a Palm.

Re:The perfect language (1)

virtig01 (414328) | about 13 years ago | (#317416)

You hit the nail on the head. I especially support your comment on Swing being a superior GUI. One thing I do like about TK though, are those cool tear-off menus. The only thing I don't like about Java, besides the slowness, is its size. It's too big to be a scripting language, and it wasn't designed to be.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...