Exegesis 6 (Perl 6 Subroutines) Released

chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."

Comments

GNAA EARLY POST!

[Anonymous Coward]

GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the first organization which
gathers GAY NIGGERS from all over America and abroad for one common goal - being GAY NIGGERS.

Are you GAY ?
Are you a NIGGER ?
Are you a GAY NIGGER ?

If you answered "Yes" to any of the above questions, then GNAA (GAY NIGGER ASSOCIATION OF AMERICA) might be exactly what you've been looking for!
Join GNAA (GAY NIGGER ASSOCIATION OF AMERICA) today, and enjoy all the benefits of being a full-time GNAA member.
GNAA (GAY NIGGER ASSOCIATION OF AMERICA) is the fastest-growing GAY NIGGER community with THOUSANDS of members all over United States of America. You, too, can be a part of GNAA if you join today!

Why not? It's quick and easy - only 3 simple steps!

First, you have to obtain a copy of GAY NIGGERS FROM OUTER SPACE THE MOVIE and watch it.

Second, you need to succeed in posting a GNAA "first post" on slashdot.org, a popular "news for trolls" website

Third, you need to join the official GNAA irc channel #GNAA on EFNet, and apply for membership.
Talk to one of the ops or any of the other members in the channel to sign up today!

If you are having trouble locating #GNAA, the official GAY NIGGER ASSOCIATION OF AMERICA irc channel, you might be on a wrong irc network. The correct network is EFNet, and you can connect to irc.secsup.org or irc.isprime.com as one of the EFNet servers.
If you do not have an IRC client handy, you are free to use the GNAA Java IRC client by clicking here.

If you have mod points and would like to support GNAA, please moderate this post up.

This post brought to you by Penisbird , a proud member of the GNAA

G_____________________________________naann_______ ________G
N_____________________________nnnaa__nanaaa_______ ________A
A____________________aanana__nannaa_nna_an________ ________Y
A_____________annna_nnnnnan_aan_aa__na__aa________ ________*
G____________nnaana_nnn__nn_aa__nn__na_anaann_MERI CA______N
N___________ana__nn_an___an_aa_anaaannnanaa_______ ________I
A___________aa__ana_nn___nn_nnnnaa___ana__________ ________G
A__________nna__an__na___nn__nnn___SSOCIATION_of__ ________G
G__________ana_naa__an___nnn______________________ ________E
N__________ananan___nn___aan_IGGER________________ ________R
A__________nnna____naa____________________________ ________S
A________nnaa_____anan____________________________ ________*
G________anaannana________________________________ ________A
N________ananaannn_AY_____________________________ ________S
A________ana____nn_________IRC-EFNET-#GNAA________ ________S
A_______nn_____na_________________________________ ________O
*_______aaaan_____________________________________ ________C
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam mollis, libero non facilisis vehicula, quam sem fermentum urna, at porttitor neque odio nec purus. Morbi felis. Mauris arcu turpis, dignissim sed, tristique sit amet, euismod ac, tellus. Pellentesque sit amet nulla. Vestibulum volutpat. Fusce viverra mattis orci. Phasellus sed ante. Vivamus nu

Re:GNAA EARLY POST!

[Anonymous Coward]

Now look i don't want to start a holy war here, but what is the deal with you Perl fanatics?
I've been sitting here at my freelance gig in front of a 2GHz Pentium 4 box (1 Gig of RAM) for about 20 minutes trying to understand this Perl program. 20 minutes !. Using Python on my Pentium Pro 233 running Win98ME , the same program would take about 2 minutes to understand. If that.
In addition, my brain has ground to a halt trying to understand this regular expression:

s/ (?![]})\w.])'[^'\n]*(?:''[^'\n]*)*'/ '' /gx;

I won't bore you with the laundry list of other problems that I've encountered while working with Perl, but suffice it to say there have been many, not the least of which is I've never seen a Perl program that's easier to understand than it's Python counterpart, despite the fact Perl's been around longer. From a productivity standpoint, I don't get how people can claim that Perl is a superior programming language.

Perl addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use Perl over a faster, easier, more stable, proper object orientated language.

Re:GNAA EARLY POST!

[smittyoneeach]

Regular expressions look like the north end of a south-bound mule in any environment.
Blame not Perl for the fact that your predecessor neglected to type:

#Here is a wild, experimental regex that I thugged off the internet.
#It worked with my simple test file, but who knows if this dog will hunt on prodution.

Re:GNAA EARLY POST!

[cowens]

well, in short it replaces single quoted strings with an empty sinqle quoted strings. Why your program wants to do this I don't know.

The only thing that bothers me is the zero-width negative look-ahead clause: (?![]})\w.]). It seems to be useless since it is at the beggining of the match.

f you are looking for a "bar" that isn't preceded by a "foo", /(?!foo)bar/ will not do what you want. That's because the (?!foo) is just saying that the next thing cannot be "foo"--and it's not, it's a "bar", so "foobar" will match.

I would hardly blame Perl for this piece of work though. Whoever wrote it should have left a comment to explain what was going on.

There's a long way to go

[Dancin_Santa]

I mean, whitespace hasn't even been made meaningful yet.

Where's $\space and $\tab ?

Re:There's a long way to go

[TedCheshireAcad]

Oh lord, variable names/function calls with whitespace.

That would truly make perl executable line noise.

Re:There's a long way to go

[luugi]

Check this out. :)

New Whitespace-Only Programming Language

Re:There's a long way to go

[szap]

whitespace hasn't even been made meaningful yet.

Funny you should mention that, because Damian Conway, the author of the article here, is also the author of Acme::Bleach, the perl code to whitespace only code convertor.

Check it out if you haven't already -- Acme::Bleach showcases the best and worse of perl: very short code (83 lines, including documentation you see in the link above), humorous (with subroutine names like whiten, brighten, dirty and dress) and does absolutely nothing Useful(tm). It's a cool perl hack.

Urgent message

[Anonymous Coward]

Here is the response you requested, tripple encrypted. Once you decrypt it, respond to this message as indicated.

begin-base64 644 urgent
OKITFfHxmUXspDkKbrTedSueNvz9XanfPlQ9mT5H/G h+HRocZy aPq/TNrzyf
CJ0Z5DRVWlfMYx8Z2DrljoGl6OVEm9zGb0L0kv Kg4gYpMFqQ5y qJBbJF5C1A
xZABC4xQIAmJje5R9kgwtveHofw0rFqfyo9XQI Lnwa5EkYLqXh 2l8kRTDvxC
taWKKCaEVpiVNbp/QqU9/EF+vYUGFjmchc3nds 6/NB7HDFLZ9Q kFiXcoqWmu
c3J4vXnl73TJx34/0dg/3p36v0UsWafv4Vrdw6 NGAWdv2HWCKH NAM9Jlunpy
eXmN5Q2m64N+l71RdB94Ea0QuikITdcKdWKniB Quc3AdKGW6eq 7BHRkl6XZZ
oKhmLFdYA/LNMBvmxvtRNguFHky4FLsR8I7YOc 9odM8O5YxvpM v8XlVVJQK+
YNFPp++Z3QGsI79tcBobs7s1rfvD3KpeAo3HEL I5x9OhLL8uZP 3eUGwM1UKa
61ChIA4NzPZZrnpVTT51WMyM7wwAOpzVUXaU3m EDRVLGThebIJ qLTwxe658L
L2g+Qyhnfa6PMTqhMTmrOqCmPr64ZKpKopFKHQ j0avXYb5VnX1 8LFAc7VOWh
NQBmCsg3x/3wSyLPhD6eXUjYHSx9YejA2A6wL6 Lab3fEC1sQSZ lD1HkRbhbo
Rf15NUmW4+AvCGvaOmlK39iKjuWgqHCz5VTEA0 4O7nq2P6egGi rhC+Rai/6o
pw8oU8SXOxWZ9uSB6/yzBziQly4Zg/Za2pIb2D Nvj2XjQiO6An W6wgCE159W
yqVb0tCngAcAVfZhR5YpYKgP/i5XqYcbtrzcJr P5b/scWsVzOX IfhqD5MD9O
BiM+v8h8j3sboZFjw04Fuc2qB2fha9qNJ6EbOz bosgv2Q6D0wc oacMZwXcDS
flCVA/c0eKBRn5TAhWlmfVbhvrWIC5AECUfMl0 IwagYV/ZPReW F3dvEXhM39
A1+KzUUAnDDr3qFXc0S0W2Ormbu5wh6w2gZV+u F5e9/gxQ6pSZ K/KhozloS3
96dbxA34tY7Lks7bVusL7tEaumpwSXxeSD31yS wjbefczshwth xVqahpw2Mf
EIkICIPyb3hcvWmjb2FvvwBHEtg+d05muSoIax SHltnl85H6fa mYjfhZyFU2
USXGRvJDz9Ki+nw1LN4K45WaAL8uuQKjtKbmiS 3TGNhw+4m3FF WDpOWbdAEX
HzOnSP2bdN7gexAwInDaboiJzBFwFdHLdjNJm0 JUPbxMlskJqD E0Fi1Kr7Mj
vNvioaim9dBqhOeCCDZGseBEZ3wiMLhErRu8CF +fpfyCYp+g9T u2SiedwPtL
QeGTHBg/pOMWLkeL8EtRf0CQp1/djScHPUzPAh kv6h/wIydd3e P5H3sQJvKm
WdjVvuTwwHJcSXsDaoWL8srvMxh+d3Skc0+WBS B3y6KV3qpRq4 lbvaaMKtai
pqmDlWn21UdgILddshv55BCftI9E0XRtcA6NRM oZGqZJU1QpKy VyL2u8cuP4
Alw7pkjIYGSsuzfI9vYvJDOyPEwZ3KcJZsQaEs NzmOfuvagg1p +QdYQ8jZxV
Ak6kBXtMqkUfS50dIeE5MNVT03pq5BFHgRZgx5 J4yJF8DsNFlW wV/dGioc1v
spw4pEPb07ws2x2tyzwUKQLKy1K73epvt7FbsJ DwgcI+ATBTwo e5as4StUJL
pfis3njVpVMNEtfdTo6ADXR7Zrz3thxIjOfKS2 gmOmy9TySQ80 hFiPkFR68b
kk5Ta+DMnyYWrXGzKVWhJBlpCzMso+FThwEEji DwNDziqUHRhF YODxgoP7vm
PDbWrBphPexHVL2Of3QykZPCF63jSV5g/0+Q62 fGoWkSArfTth 8mHhrN5fq8
4TLbY+zuEoXhUIrwn8AwhkUjhrN0uFLoy+hEJd 95PKvqIzuKdI q7UgSBhRbj /8HXlBlq34BFVFuU6Vgth+w8C1mVFWIB2UwlYIMDNeEYbm5tDH MHugvqUp36
SlcsXGHINxMmO4zUAqdLDtkg608lXoPbnb1yiZ DJH2CtdDfuAv A7LMprN5Ei
4EkItd/487wxxD5uw6sXP0RwRaxmvrmZmG9iQT bkjqspDZx5TX r78tr0aYy0
8rkQnM5aeW9OjNTDrP/H9iiOAWE0J4szmooOYR fc/m3FNKot01 q9OuxH+GXK
iCPXO0qPLWKfx0m+DjAktpXa/AjfA9ODYkQIo0 EfxMsLDP/ukF DP4/J7HM0G
EQBsOv4FRtNSh8DotFI7Qc/MCoYEOCCMt3wLpB /ombHGbvQWb0 jqlqEkhZUO
KcG0P7giLnMXMpPC9dSycKAE7DgzQe4IIXfvl0 j9vsz0tCoKbB BnZ9x3+O0H
JnoYH6NCvPR2tRD1fSz/FC/+t4wGpZ73o94XPd XyMTHNCdMjc3 zFpvgrCTuZ /3qRE7SKcKL7hX8u58kcJwxrddS2UUsEZnRxaL+IRsRxiI1Z+3 RElNhcsF2G
BDfrx65TZPsfBgPfIK+8Gn3LHBGAT9kz/QyqxY lv7Hx2sEPD0V L08f2V5teY
9z2sQUcpPQFSGbewOjDwmXnN/r9AlpWKFytbRm L+cUOGiD9xWO HWuKmfF+Lk
ruNpk4nViKoqyeiBoK6YqPGW8tlpuIt3liF8bu yG/6SCw3VlKW xTyZy5DEfO
8DS5cKbpjqrNFRmlRsCmcVBkl0TtgVZLstPiWl 677XWTqd7p/W QvhNgQSOak
HBzTw22rmInAeuFMpkBKScTytw/V6wrOhPKUJW QZtYwm/yxheF y3Vk9Eu+Lf
RY/JegNHYLXzWPD8g/HpGGIHBCbGotaXgrCm/P

Re:Urgent message

[Anonymous Coward]

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.2.2 (GNU/Linux)

jA0EAwMCGknsaXfmRK9gyS+Ah93kn+XcxhNZWEKR2tdpzcB1 /x 9qIKOMa586Ew10
b0Hkg2tnVkrJcyuh+DuVGA==
=zRma
- ----END PGP MESSAGE-----

Passphrase is foo

First?

[Anonymous Coward]

Fristy Pist? PLS? A/S/L?

Frost on my post

[Anonymous Coward]

Copyright (c) 1993 The Regents of the University of California. All rights reserved.

This software was developed by the Computer Systems Engineering group at Lawrence Berkeley Laboratory under DARPA contract BG 91-66 and contributed to Berkeley.

All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Lawrence Berkeley Laboratory.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
• All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors.
• Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Perl is teh sux0r

[Anonymous Coward]

PHP is m0re l337, nigaz

you c0de p3rl you aer teh ghey

larry wall w0uld get his ass beat by rasmus lerdorf

Re:Perl is teh sux0r

[shaklee]

always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities

If you're looking for a good Perl book...

[Sir Haxalot]

Learning Perl
When it comes to working a little "behind the scenes" magic for a Web site or putting together a UNIX script which interrogate databases and produce reports based on the information they contain, there are few better languages to do the job than Perl.
Learning Perl draws on the expertise of two of the major supporters of this highly flexible language, Randal Schwatrz and Tom Christiansen, to produce an introductory manual which manages to be concise yet informative throughout.
Weighing in at a mere (for a computer manual) 271 pages it achieves admirably what it sets out to do--teach Perl basics and no more. From the introduction to the different variable types through hash arrays, file access, process management and coding for the World Wide Web, it's a well-paced easy-to-understand book which assumes a rudimentary knowledge of programming but no more.
With its multitude of clear examples which help to hammer home the many points made and set exercises at the end of each chapter, it builds knowledge rather than drowning the reader with information as many other books seem to do.
This is the first in a series of books on the subject from O'Reilly Publishing, the others being Programming Perl, Advanced Perl Programming and the Perl Cookbook and it truly is a great introduction to a language which is enthusiastically supported by developers and Web coders worldwide. Well worth a read.

Re:If you're looking for a good Perl book...

[Anonymous Coward]

$IR HAXALOT IS A MONEY TROLL. He posts book links all day long because HE HAS A REFERRAL PARTNER ACCOUNT WITH AMAZON. $irHaxalot should be MODDED DOWN ON SIGHT. He DOES NOT READ the books he is recommending.

Keywords

[Gortbusters.org]

The one thing that I always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities there or are the perl gurus guiding us through their path of enlightenment?

Re:Keywords

[Anonymous Coward]

The one thing that I always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities there or are the perl gurus guiding us through their path of enlightenment?

Python syntax is close enough to C, C++, Java et cetera not to cause most people any problem - except in the few places where it isn't, of course!

John Roth

Re:Keywords

[ajs]

Perl has keywords picked up from C (for, if, while, int, printf, etc.); BASIC (substr); Modula (module); CPP (defined); and many other sources. It's very much a post-modern language in the sense that it seeks to deconstruct all other languages and re-build itself in their images without actually being just a collage of their parts.

HOWEVER, that being said Perl has a huge advantage over the keyword restrictions of most languages. I'll show you a sample of some code, and you tell me if you can see what the advantage is:

$time = time();
$localtime = localtime();
print "UNIX timestamp $time is $localtime\n";

The same goes (to a slightly lesser extent, since you don't *have* to use the prefix-sigle &) for subroutines and all of the other miscelaneous Perl data types that can be named (obviously those that cannot be named like stashes never conflict with a keyword).

Re:Keywords

[TheFlyingGoat]

I've found that Perl syntax is more like C++ than Java is. Similarily, if you know PHP, you basically know Perl.

I learned Perl quite a few years ago, and use it on a daily basis. When I needed to use PHP for some large projects, I was able to learn it on-the-fly in under a week. Sure there's a few PHP functions I still don't know, but I'll probably never use them.

The way I see the development of Perl is that they're making it backward-compatible enough for people to make an easy transition, while having it advance enough to make the transition worthwhile. They've even switched to calling Perl regex's "rules" so people don't confuse true regex's or even what other computer software refers to as regex's.

Re:Keywords

[smallpaul]

I've found other languages have the same advantage. vtime = time() vlocaltime = localtime() print "UNIX timestamp " + time + " is " + localtime This isn't any language's syntax in particular...but you get the idea.

Re:Keywords

[grennis]

Having a weakly typed language is not an advantage. Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever. .NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?

int a=1;
WriteLine("a is type {0} and has value {1}", a.GetType().ToString(), a.ToString());


The beauty of it is when you translate the text. The translator now has option of moving parameters around inside the text. Awesome.

Now go ahead and mod me down for saying something positive about .NET :(

Re:Keywords

[Cyno]

WTF!?!

Hahahahaha..

Re:Keywords

[ajs]

You gave the example:

vtime = time()

Actually, that's a great example! Let's say you write that in C. Then, a year later ANSI C 0x is published and lo, "vtime" is now a keyword!

In Perl, you are guaranteed that your variables will never conflict with keywords. Not ever. Not even if you try.

Re:Keywords

[jandrese]

I thought the point was that most of the time we don't care if it is an int or a float, we just want it to work correctly. Obviously if you try to do something like (note, the . operator concatenates strings):
$foo = "bar";
$foo++;
Perl is still going to stop you, but when you do:
$foo = 123;
$bar = "Foo is $foo";
Perl does the right thing and automatically stringifies the number for you. You don't have to worry about converting your numbers to strings and back. You can even do things like:
$foo = 123;
$foo = $foo . "456";
$foo++;
print "$foo\n";
Perl will print out 123457, just like you'd expect. When you do stuff like that in a strongly typed language, you spend a whole lot of time converting types manually, which is annoying.

Re:Keywords

[Anonymous Coward]

ToString is not a pure virtual, it has a default implementation. The default implementation returns the fully qualified name of the type.

And it is even more powerful than you mention, for example, for an instance of the Double class whose value is zero, the implementation of Double.ToString might return "0.00" or "0,00" depending on the current UI culture.

Re:Keywords

[Waffle Iron]

Can you see the advantage here?

int a=1;
WriteLine("a is type {0} and has value {1}", a.GetType().ToString(), a.ToString());

What's the big deal about that? In Python, for example, you can do the same thing with much less fuss:

a = 1
print 'a is type %s and has value %s' % (type(a), a)

or with your positional parameters:

a = 1
print 'a is type %(1)s and has value %(2)s' % { '1': type(a), '2': a }

The same string conversions happen. 'a' is still an integer, and the language knows it. You just don't have to keep typing 'int' and 'toFoo()' over and over.

Re:Keywords

[ajs]

Having a weakly typed language is not an advantage

You're confusing variable glyphs with typing. While variable glyphs in Perl do indicate something about the typing, they are not type identifiers.

I was pointing out the advantages of glyphs, not types.

Apparently, script programmers cant deal with specifying that something is an 'int' or 'float' or whatever

Script is a misused word here, since the term litterally means a collection of commands as a user would have typed them, and while you can write Perl code that looks kind of like that, it's certainly not the way Perl is used). Shell programs aren't even always scripts (just look at your average configure program). Don't contribute to watering down the word, especially if you're just doing so to make the "what makes us real programmers special" weak assertion.

Ok, that said, Perl does offer typing, but only when you really need it. Since strong typing isn't needed in perl by default (Perl 5 and under have no real compilation mechanism, so the performance gains would be minimal), all you really need is to type *data* not *variables*.

You can type data using any number of tools in Perl including pack, unpack, sprintf and vec.

In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler. This introduces the need to access system types in a more rigorous way, and Perl 6 has typing features such as you would find in any other language. Of course, $x = $y will still work regardless of types (though it could cause a compile or run-time error if they are excplicitly incompatible, but that's not going to happen unless you really mean for it to). .NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing. Can you see the advantage here?

That's the approach of about 5-10 DOZEN languages (literally) over the last 10-20 years. Let's not credit C# with the "innovation" of objects as the only first-class data types (I assume you mean C#, since .Net isn't actually a language, but a Microsoft product that encompasses the .Net runtime, which in turn encompases C#... kind of like calling Java JSP).

Perl 6 is going down the same route as did Python (long before C#).

Perl 5 has fairly primative roots, and given those roots its typing system made sense at the time. Perl 5 does also have a universal base-class for all objects, but not all types are objects in Perl 5. They will be in Perl 6.

Re:Keywords

[smallpaul]

There is absolutely no chance that either time or vtime would be keywords in any version of C. C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny. Perl's solution is, in my opinion, like taking a baseball bat to a cockroach.

Re:Keywords

[grennis]

I assume you mean C#, since .Net isn't actually a language

I meant any language that .NET supports... VB.NET, C#, J#, etc. Can you see the beauty in THAT?

Anyway, it looks like *somebody* is getting defensive about being a script programmer ;). Sorry I touched a nerve there ;)

Re:Keywords

[chromatic]

In Perl 6, there will be a just in time compiler, and eventually a stand-alone binary compiler.

Parrot has both today. (Okay, it just picked up the standalone binary compiler a couple of days ago.)

Re:Keywords

[ajs]

There is absolutely no chance that either time or vtime would be keywords in any version of C

You make this assertion (which I can't understand the origin of), but then say:

C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny

Um... so, it's not "absolutely no chance", but "tiny".

You're sort of thinking about this backwards. The question is not "when a new keyword is added, will my variable name be one of them", but "in my giant project and all of the myriad libraries on which it depends, will any of that code break, when a new version of C introudces a keyword." From my prior experience in fixing code with exactly this problem, I can say "yes" with a high degree of certainty.

Perl's solution is, in my opinion, like taking a baseball bat to a cockroach

Bad metaphore, and again, you're looking at it upside down. How dangerous is it to add a keyword in C? Pretty huge, right? So the result is that you don't add keywords very often.

In Perl however, it's much less painful because of this "baseball bat", so Perl adds keywords where they are needed, rather than where they are unavoidable.

Keep in mind, I'm a fan of C (not C++) and Perl both, so this is not a language war, I'm just pointint out a relative merit of Perl's way of doing things. C has its own merits in sufficient quantity to make it the single most widely use language in history.

Re:Keywords

[Q2Serpent]

When they say "keywords", I'm sure they meant "functions in the global namespace".

Re:Keywords

[Horny Smurf]

ok, so perl variable will never conflict with keywords, score 1 for perl.

But if/when you switch to perl 6, $hash{'key'} is now %hash{'key'}. And it gets uglier for arrays of hashes, etc. And $length = @array is now $length = @array.length;

But at least keywords won't conflict with variables!

Re:Keywords

[ajs]

Anyway, it looks like *somebody* is getting defensive about being a script programmer

Not at all. I'm simply not.

When I spend most of my day working on libraries that are used by a suite of tools, each of which is as modular and re-usable as possible, I find it hard to refer to that as "script programming".

The gulf between those two jobs is about as wide as the gulf between Web Master and C# programmer.

I meant any language that .NET supports... VB.NET, C#, J#, etc.

Then you are incorrect, since .Net also supports many languages which do not share this typing system. The .Net libraries may use that typing system internally, but that's because they are written in, or at least primarily written for C#.

Again, you are making a broad an inaccurate comparison between vastly different scopes.

Re:Keywords

[nograz]

Just for the sake of completeness: The concept of a "single rooted hierarchy" is not new. We can find the most prominent implementation in Java and the .NET implementation is almost a "clone" of it (including the toString() Method). What's new in .NET is that they include primitives ...

Re:Keywords

[moonbender]

But the Python version contains lots of special characters and special syntax, especially the positional one ("%(1)s", wow!), which make it hard to read for anyone not accustomed to the printf format string. I think the version of the original poster is very convenient to read and understand, even though I am more accustomed to the style of your code since I know some Python and a lot PHP.

Obviously, this is a matter of taste and familiarization, though.

Re:Keywords

[los furtive]

Perl's solution is, in my opinion, like taking a baseball bat to a cockroach.

Sounds like a good solution to me!

Re:Keywords

[Anonymous Coward]

There is no advantage. You're carrying type-information around everywhere you go, because you think it allows you to add keywords. Do you know why C doesn't add new keywords? Take a few guesses, and it has nothing to do with any difficulty you presume there to be.

Re:Keywords

[msuzio]

Actually, the following code (in Perl 5):

$foo = "bar";
$foo++;

Result in $foo holding the string "bas" right now ;-). I haven't puzzled out the Perl 6 stuff enough to know what would happen then (probably a compile time error in assigning "bar" to $foo if $foo is declared as holding only numerical types).

Re:Keywords

[grennis]

You modded yourself up didn't you ;).

Anyway, you are totally wrong, every object in C# is derived from 'object'. Same as VB.NET. Same as Managed C++. Etc., etc. How can you argue this point? It is a fact. I still stand by my statements.

Re:Keywords

[Billy the Mountain]

What's wrong whacking a cockroach with a baseball bat? Here in Houston, carrying a baseball bat as protection against cockroaches is common sense, plain and simple.

BTM

Re:Keywords

[Anonymous Coward]

Yes, that's great! I'd much rather spend large portions of my day worrying about manual type conversions, instead of actually writing the business logic for my application.

Re:Keywords

[Simon]

C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny

Um... so, it's not "absolutely no chance", but "tiny".

A couple of points:

* The chance really is tiny. Keywords are rarely added, and when they are they are chosen carefully.

* Code refactoring tools exist for the case when a clash occurs. Use them.

* Having manditory prefixes for all variables is a terrible price to pay in terms of readability (and not to mention typing). It's overkill on a massive scale.

* Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.

It's just a really bad trade-off allround, and like program line numbers, it's a concept that should be left to die.

--
Simon

Re:Keywords

[ajs]

Anyway, you are totally wrong, every object in C# is derived from 'object'. Same as VB.NET. Same as Managed C++

I think you're talking about the object model of the .Net runtime, and that's fine, but .Net runtime is not a language, and its objects are not language primatives.

To give an example of C++, and then discuss what is effectively an RPC-based library's object model is way, way beyond the scope of the original conversation.

Like I said before, this is not a unique feature to one, or even a dozen toolkits, languages, etc in the last 10 years. You're not citing something that originated with the example that you are citing. I was responding to an assertion of yours that you seem not to really be talking about any more, so I'm going to drop this thread.

Re:Keywords

[Anonymous Coward]

3 - 1 for you! Brilliant!

Re:Keywords

[beat.bolli]

C has its own merits in sufficient quantity to make it the single most widely use language in history.

Are you really sure about this? I mean, how many lines of Fortran and Cobol do you think have been written in the 20 years before C even existed (and are still being written today!)?

Not that I wanted to speak in favour of these languages, but I can't let your statement stay as is...

Re:Keywords

[bnenning]

.NET has really solved this problem, but making it strongly typed, but every typed is derived from 'object', which has a pure virtual 'ToString' which allows you to easily convert anything to a string suitable for printing.

Java solved that problem many years ago, and Smalltalk solved it many years before that.

Re:Keywords

[n1vux]

Tiny chance? Try certainty.

C99 added the keyword 'boolean'. Very carefully.

No matter how carefully, it still breaks a lot of libraries which had been using that word as a typedef with that or similar spellings. It's not a tiny chance, it's guaranteed ... unless you've already upgraded your compiller and all libraries to full ANSI/ISO C99 compatibility, which some vendors only started shipping recently, and aren't adding any 3rd party libraries in the next 5 years. (I'm hoping to finish the C++98 conversion soon. People keep discovering legacy code!)

Sigils/prefixes is a religious issue. Mentioning them with line numbers in the same graf suggests someone hasn't fully recovered from initial exposure to BASIC back before we had lower case. Dijskstra overstated the perniciousness of Basic, but ... branching out into other languages _early_ combined with _early_ theory exposure seems to be the best predictor for a full, healthy recovery.

Re:Keywords

[Anonymous Coward]

(defun description (obj)
(format t "Object ~A is of type ~A.~%"
obj (type-of obj)))

Keep trying. You guys will have a language as nice as Common Lisp in a few decades.

Re:Keywords

[jbolden]

Nice try but no. See apocolypse 1, you need a keyword to be in Perl 6 syntax otherwise it falls back to Perl 5 for the entire file. So absolutely nothing happens.

Re:Keywords

[Lozzer]

You do realise that cockroaches can put themselves back together after a good pasting with a baseball bat. Napalm does a far better job, so I've been told. Liquid nitrogen stops older models.

Re:Keywords

[Anonymous Coward]

P# == Parrot of Perl or Python in .NET?

hehehehe

open4free

Re:Keywords

[RevAaron]

Heh- perl, the postmodern language... A common excuse for its appearance of being a rubbishy collage.

"Oh no good sir- what you see before you isn't a child's mess, it is in fact ART! High Art! Postmodern, abstract! If you can't understand it, well, you must be some sort of stunted freak with no appreciation for anything of intelligence in life."

That said, I enjoy perl on occasion, to that I'll admit. However, I have a big number of annoyances with Perl 5. Part of it is with Wall's assertions about perl being postmodern- not a mess; how it naturally follows the way the human mind thinks- perhaps his, but not mine and a great many others; that perl resembles english- no more than most languages concieved by english speakers.

Ok, done ranting. :)

Re:Keywords

[ajs]

Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.

Oh so?

$complex{data}{structure}{of}[$n]{hashes}[2]{array s}{and}{an}->object(); = "Stuff";

That does not seem very nighmarish to me. What's more, manipulating complex data on the fly is trivial in Perl:

$struct = [1, 2, 3, { a => [5, 6, 7], b => [8, 9, 10]}]

which would be an array of 4 elements, of which the fifth element is a hash of two elements, the values of which are themselves arrays. Not that hard is it?

There is the container-access syntax that I find rather messy, but even that's not so bad, and it goes away in Perl 6 entirely, again without impacting that very clean way of identifying variables that lets you do things like

$foo = "dogs";
$bar = "cats and $foo";
$baz = qr{($bar)+};
while(<>) {
if (/$baz/i) {
print;
}
}

with one, uniform syntax.

Re:Keywords

[ajs]

Speak in favor of Fortran, please do. It was a language that was hobbled by some of the physical limitations of the day, but still it was a wonderful language.

COBOL was a product of its environment, and could never have been a good language. If it had been, that would have defeated the point :-(

But, no. C has become SO widely used in the world that it has eclipsed even COBOL at this point. Just your avergage Open Source distribution has more C code than what was produced at 90% of the banks out there (of course, those 10% cranked out some amazingly vast code). The various C-based software for embedded systems, etc keep the pace going, and then you have other free operating systems, proprietary OSes, content management systems, telementry data managers for satellites, elevator control systems, mathematical simulation systems, payroll management software, etc, etc.

About the only think I could imagine coming close at this point is JavaScript, and that's only because there are so many page generators out there that spit out HTML with JavaScript embedded....

Re:Keywords

[ajs]

There is no advantage

No, I pointed out a few already, and there are others. You simply happen to disagree. That's fine too. Perl is about accomodating disagreement in a single language, and that's hard to do with a limited keyword set.

You're carrying type-information around everywhere you go, because you think it allows you to add keywords

I've pointed out elsewhere that type information and variable glyphs are different. They do have an association to type, but it's a loose one.

For example:

$x = 1;
$y = [ 1, 2, 3];
$z = new IO::Socket::INET
PeerAddr => 'yahoo.com',
PeerPort => 'http(80)',
Proto => 'tcp';

Here you have three variables. One is a simple scalar. One is a reference to an array. One is an object that represents a socket, connected to the HTTP port of a remote server. The $ doesn't tell you a whole lot about type, it just indicates a scalar access-mode.

Do you know why C doesn't add new keywords

*I do*, but I wonder if you do....

C does not add new keywords because it is a syntactically simple language, and that's part of its attraction. Any attempt to change that (e.g. the way C++ did) would destroy that, and would need to justify such a change against the benefit.

I think that Perl does justify this increase in complexity, though to most outsiders that's not obvious. You really need to be able to think in Perl before you understand just how valuable all of that syntax is.

At one point, I knew C so well that I thought in it. That was long ago, but I still remember how powerful that was.

When I learned Perl well enough to think in it, I was introduced to a new kind of programming. I was suddenly able to write in a few lines of code, what would have taken pages and pages of C, even with a good set of libraries. Just the ability to say:

@foo = sort map {"$y{$_} $x{$_}"} grep {$_ > 0} @bar;

dwarfs the abilities of C.

That's not to say C is useless. I still use it from Perl all the time, via XS. If I had to write a device driver or any other low-level code, I would still use C. But for your run-of-the-mill software, Perl is leaves low-level languages, and even most high-level languages far behind... at least from my, admittedly limited, point of view.

Re:Keywords

[ajs]

No, you're mis-reading A1.

You can define syntax on the fly. What *will* happen for backward-compatibility is that certain Perl 5 features will be searched for, and those features will initiate a Perl 5 mode. For libraries this is easy ("package foo" is the first thing in every Perl 5 module), but in general-purpose code you have to get a little more context-sensitive.

However, there will of coruse be a command-line flag for "just do Perl 6", so you might write

#!/usr/bin/perl -6
use syntax::bash;
if [ -e /etc/passwd ]; then
echo "passwd looks good."
else
echo "erorr: no passwd" 2>&1
exit 1
fi

Re:Keywords

[ajs]

You're comparing apples and oranges.

This has been an advantage of Perl since it's very first release.

What you're talking about (compatiblity betwen 5 and 6) is neither mitigated by, nor a result of that feature.

Re:Keywords

[ajs]

In Perl 6, it would depend on what type $foo was. If it was an integer, then your initial assignment would set it to zero, and then the second statement would make it one.

If you never assign it a type, then it defaults to a fully-functional scalar and behaves much as a Perl 5 scalar would.

Re:Keywords

[crucini]

Actually, you could make your point more strongly by omitting the parentheses after the function calls:

$time = time;

etc.
And doesn't that line kind of warrant the comment:

#Dread at control, mon, an' I an' I come a Freeside when I an' I come.

Re:Keywords

[crucini]

Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.

It's pretty easy, actually. If @x is a list of hashes of objects of class foobar, which is what I think you mean, you can:

• Get one element: my $local_foobar = $x[21]{ purple };
  
• Invoke a method on one element: $x[1]{ green }->print();
  
• Index an element by variables: $x[$n]{ $color };
  
• Get one complete hash of foobar: my %h = %{ $x[3] };
  

Far from being a nightmare, the ease of such manipulations is one of the nicest things about Perl.

What's happened to autopr0n.com?!

[Anonymous Coward]

I need my fix!!

Low Turnouts

[mfivis]

Not a lot of comments on the past several posts. Need a little more mainstream flavor injection again.

Damian Conway

[Anonymous Coward]

Didya know that you can't say "a con mind away" without "Damian Conway"?

Also released..

[Anonymous Coward]

A large nematode crawled out from my ass.

seriously, slashdot

[Anonymous Coward]

what is this doing on the front page? you know no one cares about this. please pull your weight.

http://www.thesmokinggun.com/archive/fword1.html

[Anonymous Coward]

FUCK

For those who don't know....

[ajs]

The way Perl 6 is being developed is thus:

• Everyone in the world had a chance to submit RFCs
• Larry is taking each section of the 3rd edition Programming Perl and turning it into a white-paper on the way Perl 6 will work, using the RFCs that touch on that section of Perl as a sort of shopping list, and accepting, modifying or rejecting them as needed. These are called the Apocalypses.
• After an Apocolypse is out, Damian starts working on some real-world examples to make it all more concrete. These are called the Exegeses. Sometimes these also have examples of syntax and semantics that have been worked out via the mailing lists
• Eventually, this will lead to the Design Documents

Hope that helps clear this up for those who aren't sure what's going on when they see a new Apocolypse or Exegesis come forth.

ok

[Anonymous Coward]

Why would someone who is reading an article about Perl 6 Subroutines need a copy of Learning Perl?

Why did you post the Amazon review without giving credit?

Why will your post be moderated up nonetheless?

Re:ok

[Anonymous Coward]

And even when that moderator modded Troll you know he/she'll get screwed by Meta Moderation :)

sami: kew-wordless language

[Anonymous Coward]

There's an interesting language called sami (after the scandanavian "laplander" people)...there's an interesting write-up of it over at tubgirl tech archive

Tell me about it!

[Anonymous Coward]

I had to wank to this yesterday!

My First .NET App

[Anonymous Coward]

namespace gay
{
class gayness
{
public static void Main(string[] args)
{
while(true)
Console.WriteLine("Slashdot is gay");
}
}
}

Re:For those who don't know....

[CoolVibe]

Thank you thank you thank you thank you thank you. No, really. Thanks. That was the _one_ missing piece of insight that I was missing.

Well, it seems like I have to re-learn lots of stuff about perl. Although I somewhat like the new syntax. Finally, perl has call by value and call by reference. Now, when will we get _real_ pointers? *ducks away to dodge the pelting of rocks in my direction* ;)

Exegeis

[Anonymous Coward]

Join SHAA Today, a moral organization! We have a TOLL FREE 800 number:

1-800-759-0700.

Call today to sign up over the phone!

SHAA (STRAIGHT HUMAN ASSOCIATION of AMERICA) is the first organization which

gathers people from all over America and abroad for one common goal - being moral.

Are you moral?

Are you a human?

Are you a moral human?

If you answered "Yes" to any of the above questions, then SHAA might be exactly what you've been looking for!

Join SHAA (STRAIGHT HUMAN ASSOCIATION of AMERICA) today, and enjoy all the benefits of being a full-time SHAA member.

SHAA is the fastest-growing moral community with THOUSANDS of members
all over United States of America. You, too, can be a part of SHAA if you join today!

Why not? It's quick and easy - only 2 simple steps!

First, call us! 1-800-759-0700. Ask us the secret passcode "Why should I believe?" We'll give you some instructions and send you literature and a book free of charge.

Second, if you want to chat with us, you can connect to irc.MOZILLA.org and join #SHAA

If you have mod points and would like to support morality, please moderate this post up.

This post brought to you by a proud member of SHAA

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.1 (GNU/Linux)

mQGiBD5dIFQRBADB31WinbXdaGk/8RNkpnZclu1w3Xmd5ItA CD LB2FhOhArw35EA
MOYzxI0gRtDNWN4pn9n74q4HbFzyRWElTh WRtBTYLEpImzrk7H YVCjMxjw5A0fTr
88aiHOth5aS0vPAoq+3TYn6JDSipf2bR03 G2JVwgj3Iu066pX4 naivNm8wCgldHG
F3y9vT3UPYh3QFgEUlCalt0D/3n6NopRYy 0hMN6BPu+NarXwv6 NQ9g0GV5FNjEEr
igkrD/htqCyWAUl8zyCKKUFZZx4UGBRZ5g uCdNzwgYH3yn3aVM hJYQ6tcSlLsj3f
JIz4LAZ3+rI77rbn7gHHdp7CSAuV+QHv3a NanUD/KGz5SPSvF4 w+5qRM4PfPNT1h
LMV8BACzxiyX7vzeE4ZxNYvcuCtv0mvEHl 9yD66NFA35RvXaO0 QiRVYeoUa5JOQZ
gwq+fIB0zgsEYDhXFkC1hM/QL4NccMRk8C 09nFn4eiz4dAEnwK t4rLCJKhkLl1DW
TSoXHe/dOXaLnFyLzB1J8hEYmUvw3SwPt/ /wMqDiVBLeZfFcdL QwU2xhY2t3YXJl
IExpbnV4IFByb2plY3QgPHNlY3VyaXR5QH NsYWNrd2FyZS5jb2 0+iF8EExECAB8F
Aj5dIFQFCRJ3owAECwcDAgMVAgMDFgIBAh 4BAheAAAoJEGpEY8 BAECIzee0An3My
boalJ5nLePD0HCzMuf8Ix8gPAJ9lnU1wqN VGza0t89ACTurDop pQ2rkBDQQ+XSBV
EAQA3VYlpPyRKdOKoM6t1SwNG0YgVFSvxy /eiratBf7misDBsJ eH86Pf8H9OfVHO
cqscLiC+iqvDgqeTUX9vASjlnvcoS/3H5T DPlxiifIDggqd2eu NtJ8+lyXRBV6yP
sBIA6zki9cR4zphe48hKpSsDfj7uL5sfyc 2UmKKboSu3x7cAAw UD/1jmoLQs9bIt
bTosoy+5+Uzrl0ShRlv+iZV8RPzAMFuRJN xUJkUmmThowtXRaP KFI9AVd+pP44aA
J+zxCPtS2isiW20AxubJoBPpXcVatJWi4s G+TM5Z5VRoLg7tID NVWsyHGXPAhIG2
Y8Z1kyWwb4P8A/W2b1ZCqS7Fx4yEhTikiE wEGBECAAwFAj5dIF UFCRJ3owAACgkQ
akRjwEAQIjM1uwCdE7V4mPCqdby/nV699N xKX0iW/OsAniaVhE ip8Ptff74Sv4JV
tb+Sth2l
=H5uu
-----END PGP PUBLIC KEY BLOCK-----

Re:Exegeis

[Anonymous Coward]

this is a welcome relief

Re:Exegeis

[Anonymous Coward]

i went to #SHAA and found that it was empty, damn you

oh yeah

[tomstdenis]

sub Fahrenheit_to_Kelvin (Num $temp is rw) {

Verbosity in coding, yeah that will go over well with people who are used to

int lbn, rax, ... ; :-)

Don't get me wrong I'm a big fan of Perl, but not for its completeness as a language but for the ability to quickly write small utils to parse text.

But I suppose whatever floats peoples boats.

Tom

Re:oh yeah

[Anonymous Coward]

Don't get me wrong I'm a big fan of Perl..

Yeah, 'cause you're an asshat!

Re:oh yeah

[chromatic]

Signatures and types are completely optional. If you're writing a small utility to parse text, you don't have to use them.

Re:oh yeah

[Anonymous Coward]

But I suppose whatever floats peoples boats

And in YOUR case, we all know exactly what that is...

Re:oh yeah

[tomstdenis]

Yeah, it's skeeball!

Tom

Re:oh yeah

[Anonymous Coward]

Is that some sort of fisting reference?

Re:oh yeah

[Anonymous Coward]

Skeeball is a carnie sport. Why not ask your parents [er. cousins, er...sibblings, ah they're all the same]?

Fuck ass. I hope you die in a car fire! [well since you probably don't own a car, a tricycle fire!]

Asshat loser!

Re:oh yeah

[Anonymous Coward]

Somebody woke up on the wrong side of the FUCK OFF AND DIE.

Re:oh yeah

[Anonymous Coward]

umm... uhh...
cat? can? canning!
Canning the mangoo!
Wait... right, I remember it now.
CANNING THE MANHAM!

Re:oh yeah

[Anonymous Coward]

That gives me an idea!

Tom stdenis bottles the mangoo!

Re:For those who don't know....

[Anonymous Coward]

• Eventually, this will lead to the Design Documents

And everyone will then use Python.

Problems

[stratjakt]

Conflict resolutions and namespace collisions will ultimately make this the final revision of the language before it dies a slow death.

Execution will be drastically slowed with the new subroutine semantics, and interoperability with other components will get harder and harder.

Re:Problems

[mr_luc]

Or, to paraphrase:

The ridged top surface and the nondescript gray color will ultimately make this the final revision of duct tape before it dies a slow death. Execution will be drastically slowed by the difficulty in ripping the tape by hand, and the gray color will make it blend in with metal components, making interoperability harder and harder.

I mean, come on. Everyone whose job description involves building entire apps in Perl, please raise your hand. Then bring it down sharply into your groin, because you should not reproduce.

Perl is still the best damn duct tape money can buy, and will be for years to come.

Re:Problems

[ekidder]

Ow! My groin! I've been doing perl applications development for telecommunications for about three years. Lots of TN3270 screen scraping. Lots of painful TN3270 screen scraping.

Wow!

[Anonymous Coward]

17 posts at -1, 10 posts above -1 - this story is 0WN3D by TR0LLZ (not including this one)

Perl6 is a mistake

[keesh]

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.

Re:Perl6 is a mistake

[Anonymous Coward]

This troll was plagiarized from http://www.rubygarden.org/article.php?sid=256.

Re:Perl6 is a mistake

[keesh]

Wrong! I wrote the above ages ago and posted it here. The RubyGarden post was a copy of that.

Re:Perl6 is a mistake

[DNS-and-BIND]

So you admit it's not original...

Re:Perl6 is a mistake

[Ed Avis]

Parent post said:

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.

I think you should reserve judgement until there is an implementation. Otherwise sweeping statements like 'perl6 won't make development any faster' are pretty hard to justify or to disprove.

By all means attack perl5, or dismiss perl6 as vapourware.

FWIW, the huge ugly monster that is Mozilla seems to have turned out rather well in the end - it just took far too long to get there. It's not perfect, but it has succeeded in its own aims (be a portable web browser suited for everyday use).

Re:Perl6 is a mistake

[Ed Avis]

BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).

Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete.

Re:Perl6 is a mistake

[Anonymous Coward]

I just wish they were *Turing* complete... *hmm* ...

I'm surprised there isn't a Barnes Noble link

[Mayak]

for affiliate sales of this publication. Anyone else notice the /. editors didn't let anyone post for some time with the book review yesterday. Guess they want to suck up all the Barnes and Noble affiliate sales they can before people can let others know where to get it cheaper.

Guess what?

[Anonymous Coward]

Slashdot sucks

Slashdot Post-o-trolls

[Anonymous Coward]

/. editors - didn't you know that a thread about PERL would lead to TROLLS? aerobic aerodynamic aerofoil aerogene aeronautic aerosol aerospace Aeschylus Aesop aesthete aesthetic a far affable affair affect affectate affectionate afferent affiance affidavit affiliate af fine affirm affirmation affirmative affix afflict affluent afford afforest aff orestation affricate affront Afghan Afghanistan aficionado afield afire aflame afloat afoot afor ementioned aforesaid aforethought afraid afreet afresh Africa Afrikaans Afrikaner afro aft afterbirth after effect afterglow afterimage afterlife aftermath afternoon afterthought afterward afterword again agains t Agamemnon agar agate Agatha agave age Agee agenda agent agglome rate agglutinate agglutinin aggravate aggregate aggression aggressive aggressor aggrieve aghast agile agitate agleam Agnes Agnew agnomen agnostic ago agog agone agony agouti agrarian agree agreeable agreeing agribusiness Agricola agricultural agriculture agrimony agronomist agronom y ague Agway ah ahead ahem Ahmedabad ahoy aid Aida aide Aides Aiken ail ailanthus aile aileron aim ain't Ainu air airborne airbrush aircraft airdrop aire dale Aires airfare airfield airflow airframe airlift airline airlock airmail airman airmass airmen airpa rk airplane airport airspeed airstrip airtight airway airy aisle Aitken ajar Ajax AK Akers akin Akron AL ala Alabama Alabamian alabaster alacrity Aladdin alai Alameda Alamo alan alarm Alasdair Alaska Alastair alb alba albacore Albania Albany albatross albeit Alber ich Albert Alberta Alberto albino Albrecht Albright album albumin Albuquerque Alcestis alchemist alchemy Alcmena Alcoa alcohol alcoholic Alcott alcove Aldebaran aldehyde Alden alder alderman aldermen Aldrich aldrin ale Alec Aleck aleph alert Aleutian alewife Alex Alexander Alexandra Alexandre Alexandria Alexei Alexis alfal fa alfonso Alfred Alfredo alfresco alga algae algaecide algal algebra algebraic Algenib Alger Algeria Algiers alginate Algol Algonquian Algonquin algorithm algori- Cowboy Neal-thmic Alhambra Ali alia alias alibi Alice Alicia alien alienate alight align alike alimentary alimony aliphatic aliquot Alison Alistair alive alizarin alkali alkaline

M$, Where are they going tomorrow? More???

[Anonymous Coward]

So what do we have:

Longhorn intergration of directx or at least one type of install option.
Microsoft and aol, microsoft is locked in, aol is still free to shop.
Pailituim
New file system (huge security flaws-not sure what their thinking other then pass the buck on TCPA)
If linux fails, much more agressive licensing agreements and absolute enforcement.

BTW-I like lesbians.

Allowed

[Anonymous Coward]

Allowed HTML: # Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about.F+vYUGFjmchc3nds6/NB7HDFLZ9Q kFiXcoqWmu c3J4vXnl73TJx34/0dg/3p36v0UsWafv4Vrdw6NGAWdv2HWCKH NAM9Jlunpy eXmN5Q2m64N+l71RdB94Ea0QuikITdcKdWKniBQuc3AdKGW6eq 7BHRkl6XZZ oKhmLFdYA/LNMBvmxvtRNguFHky4FLsR8I7YOc9odM8O5YxvpM v8XlVVJQK+ YNFPp++Z3QGsI79tcBobs7s1rfvD3KpeAo3HELI5x9OhLL8uZP 3eUGwM1UKa 61ChIA4NzPZZrnpVTT51WMyM7wwAOpzVUXaU3mEDRVLGThebIJ qLTwxe658L L2g+Qyhnfa6PMTqhMTmrOqCmPr64ZKpKopFKHQj0avXYb5VnX1 8LFAc7VOWh NQBmCsg3x/3wSyLPhD6eXUjYHSx9YejA2A6wL6Lab3fEC1sQSZ lD1HkRbhbo Rf15NUmW4+AvCGvaOmlK39iKjuWgqHCz5VTEA04O7nq2P6egGi rhC+Rai/6o pw8oU8SXOxWZ9uSB6/yzBziQly4Zg/Za2pIb2DNvj2XjQiO6An W6wgCE159W yqVb0tCngAcAVfZhR5YpYKgP/i5XqYcbtrzcJrP5b/scWsVzOX IfhqD5MD9O BiM+v8h8j3sboZFjw04Fuc2qB2fha9qNJ6EbOzbosgv2Q6D0wc oacMZwXcDS flCVA/c0eKBRn5TAhWlmfVbhvrWIC5AECUfMl0IwagYV/ZPReW F3d # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might b e moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) Problems regarding accountF+vYUGFjmchc3nds6/NB7HDFLZ9Q kFiXcoqWmu c3J4vXnl73TJx34/0dg/3p36v0UsWafv4Vrdw6NGAWdv2HWCKH NAM9Jlunpy eXmN5Q2m64N+l71RdB94Ea0QuikITdcKdWKniBQuc3AdKGW6eq 7BHRkl6XZZ oKhmLFdYA/LNMBvmxvtRNguFHky4FLsR8I7YOc9odM8O5YxvpM v8XlVVJQK+ YNFPp++Z3QGsI79tcBobs7s1rfvD3KpeAo3HELI5x9OhLL8uZP 3eUGwM1UKa 61ChIA4NzPZZrnpVTT51WMyM7wwAOpzVUXaU3mEDRVLGThebIJ qLTwxe658L L2g+Qyhnfa6PMTqhMTmrOqCmPr64ZKpKopFKHQj0avXYb5VnX1 8LFAc7VOWh NQBmCsg3x/3wSyLPhD6eXUjYHSx9YejA2A6wL6Lab3fEC1sQSZ lD1HkRbhbo Rf15NUmW4+AvCGvaOmlK39iKjuWgqHCz5VTEA04O7nq2P6egGi rhC+Rai/6o pw8oU8SXOxWZ9uSB6/yzBziQly4Zg/Za2pIb2DNvj2XjQiO6An W6wgCE159W yqVb0tCngAcAVfZhR5YpYKgP/i5XqYcbtrzcJrP5b/scWsVzOX IfhqD5MD9O BiM+v8h8j3sboZFjw04Fuc2qB2fed HTML:

1. • 
     BLha9qNJ6EbOzbosgv2Q6D0wc oacMZwXcDS flCVA/c0eKBRn5TAhWlmfVbhvrWIC5AECUfMl0IwagYV/ZPReW F3ds or comment posting should be sent to CowboyNeal.

Re:For those who don't know....

[absolut_kurant]

Thank God Damian isn't working on the Apocalypses...

What's the licensing for that code?

[siskbc]

Would you please GPL that code so that I might use it in my applications? It would be useful to have an applet that informs my users that Slashdot is, in fact, gay.

Re:What's the licensing for that code?

[Anonymous Coward]

will you be starting a sourceforge project? I think a 'slashdot is gay' gnome panel would be useful to go along with my 'linux still sucks'-meter.

Perl licensing issues

[Anonymous Coward]

See section 301(c)

to Attorney General

-STATUTE-
(a) It shall be the duty and responsibility of each Inspector
General, with respect to the establishment within which his Office
is established -
(1) to provide policy direction for and to conduct, supervise,
and coordinate audits and investigations relating to the programs
and operations of such establishment;
(2) to review existing and proposed legislation and regulations
relating to programs and operations of such establishment and to
make recommendations in the semiannual reports required by
section 5(a) concerning the impact of such legislation or
regulations on the economy and efficiency in the administration
of programs and operations administered or financed by such
establishment or the prevention and detection of fraud and abuse
in such programs and operations;
(3) to recommend policies for, and to conduct, supervise, or
coordinate other activities carried out or financed by such
establishment for the purpose of promoting economy and efficiency
in the administration of, or preventing and detecting fraud and
abuse in, its programs and operations;
(4) to recommend policies for, and to conduct, supervise, or
coordinate relationships between such establishment and other
Federal agencies, State and local governmental agencies, and
nongovernmental entities with respect to (A) all matters relating
to the promotion of economy and efficiency in the administration
of, or the prevention and detection of fraud and abuse in,
programs and operations administered or financed by such
establishment, or (B) the identification and prosecution of
participants in such fraud or abuse; and
(5) to keep the head of such establishment and the Congress
fully and currently informed, by means of the reports required by
section 5 and otherwise, concerning fraud and other serious
problems, abuses, and deficiencies relating to the administration
of programs and operations administered or financed by such
establishment, to recommend corrective action concerning such
problems, abuses, and deficiencies, and to report on the progress
made in implementing such corrective action.
(b)(1) In carrying out the responsibilities specified in
subsection (a)(1), each Inspector General shall -
(A) comply with standards established by the Comptroller
General of the United States for audits of Federal
establishments, organizations, programs, activities, and
functions;
(B) establish guidelines for determining when it shall be
appropriate to use non-Federal auditors; and
(C) take appropriate steps to assure that any work performed by
non-Federal auditors complies with the standards established by
the Comptroller General as described in paragraph (1).
(2) For purposes of determining compliance with paragraph (1)(A)
with respect to whether internal quality controls are in place and
operating and whether established audit standards, policies, and
procedures are being followed by Offices of Inspector General of
establishments defined under section 11(2), Offices of Inspector
General of designated Federal entities defined under section
8F(a)(2), (FOOTNOTE 1) and any audit office established within a
Federal entity defined under section 8F(a)(1), (FOOTNOTE 1) reviews
shall be performed exclusively by an audit entity in the Federal
Government, including the General Accounting Office or the Office
of Inspector General of each establishment defined under section
11(2), or the Office of Inspector General of each designated
Federal entity defined under section 8F(a)(2). (FOOTNOTE 1)
(FOOTNOTE 1) See References in Text note below.
(c) In carrying out the duties and responsibilities established
under this Act, each Inspector General shall give particular regard
to the activities of the Comptroller General of the United States
with a view toward avoiding duplication and insuring effective
coordination and cooperatio

Perl floats *all* boats

[flicken]

That's the point of Perl. If you don't want to use the verbosity of:

sub Fahrenheit_to_Kelvin (Num $temp is rw) {

You don't have to! You could just as well use:

sub f2k ($temp) {

Perl will allow either. It's your choice. You can do the quick one-off-hack-it-up-at-3am-after-two-large-pots-of- coffee, and you can have a large programming project that must be maintained for years to come.

You have the choice. Pick whichever method fits the task at hand.

Re:Perl floats *all* boats

[Marx_Mrvelous]

Actually the parent is wrong. The bahavior os f2k($temp) is different than f2k($temp is rw) in that Perl will assume a constant variable by default. So no, you don't *have* do, unless you want to make your parameters read-write. Which could lead to less lines and variables later on.

Re:Perl floats *all* boats

[groomed]

The problem is that it'll be the one-off-hack that'll have to be maintained for years to come, while the large programming project will just sit and collect dust in a closet.

The US Law System

[Anonymous Coward]

TITLE 50 - WAR AND NATIONAL DEFENSE
CHAPTER 35 - INTERNATIONAL EMERGENCY ECONOMIC POWERS

-HEAD-
Sec. 1701. Unusual and extraordinary threat; declaration of
national emergency; exercise of Presidential authorities

-STATUTE-
(a) Any authority granted to the President by section 1702 of
this title may be exercised to deal with any unusual and
extraordinary threat, which has its source in whole or substantial
part outside the United States, to the national security, foreign
policy, or economy of the United States, if the President declares
a national emergency with respect to such threat.
(b) The authorities granted to the President by section 1702 of
this title may only be exercised to deal with an unusual and
extraordinary threat with respect to which a national emergency has
been declared for purposes of this chapter and may not be exercised
for any other purpose. Any exercise of such authorities to deal
with any new threat shall be based on a new declaration of national
emergency which must be with respect to such threat.

-SOURCE-
(Pub. L. 95-223, title II, Sec. 202, Dec. 28, 1977, 91 Stat. 1626.)

-MISC1-
SHORT TITLE
Section 201 of title II of Pub. L. 95-223 provided that: ''This
title (enacting this chapter) may be cited as the 'International
Emergency Economic Powers Act'.''
SEPARABILITY
Section 208 of Pub. L. 95-223 provided that: ''If any provision
of this Act (enacting this chapter) is held invalid, the remainder
of the Act shall not be affected thereby.''
ASSISTANCE EFFORTS IN SUDAN
Pub. L. 106-570, title V, Sec. 501, Dec. 27, 2000, 114 Stat.
3050, provided that:
''(a) Additional Authorities. - Notwithstanding any other
provision of law, the President is authorized to undertake
appropriate programs using Federal agencies, contractual
arrangements, or direct support of indigenous groups, agencies, or
organizations in areas outside of control of the Government of
Sudan in an effort to provide emergency relief, promote economic
self-sufficiency, build civil authority, provide education, enhance
rule of law and the development of judicial and legal frameworks,
support people-to-people reconciliation efforts, or implement any
program in support of any viable peace agreement at the local,
regional, or national level in Sudan.
''(b) Exception to Export Prohibitions. - Notwithstanding any
other provision of law, the prohibitions set forth with respect to
Sudan in Executive Order No. 13067 of November 3, 1997 (62 Fed.
Register 59989) (set out below) shall not apply to any export from
an area in Sudan outside of control of the Government of Sudan, or
to any necessary transaction directly related to that export, if
the President determines that the export or related transaction, as
the case may be, would directly benefit the economic development of
that area and its people.''
IRAN NONPROLIFERATION
Pub. L. 106-178, Mar. 14, 2000, 114 Stat. 38, provided that:
''SECTION 1. SHORT TITLE.
''This Act may be cited as the 'Iran Nonproliferation Act of
2000'.
''SEC. 2. REPORTS ON PROLIFERATION TO IRAN.
''(a) Reports. - The President shall, at the times specified in
subsection (b), submit to the Committee on International Relations
of the House of Representatives and the Committee on Foreign
Relations of the Senate a report identifying every foreign person
with respect to whom there is credible information indicating that
that person, on or after January 1, 1999, transferred to Iran -
''(1) goods, services, or technology listed on -
''(A) the Nuclear Suppliers Group Guidelines for the Export
of Nuclear Material, Equipment and Technology (published by the
International Atomic Energy Agency as Information Circular
INFCIRC/254/ Rev.3/ Part 1, and subsequent revisions) and
Guidelines for Transfers of Nuclear-Related Dual-Use Equipment,
Material, and Related Technology (published by the
International Atomic E

Troll-by-reference

[BigGerman]

It seems like any posting that is NOT pro-Linux, pro-Perl or IS pro-Java, pro-Mono is automatically moderated as Troll recently.
Now, the guy:

obviously knows what he is talking about (even if he (horror!) pasted from his own posting from other website).

has something to say

Why don't you people listen and learn even if you do not agree with the poster?

Re:Troll-by-reference

[Anonymous Coward]

He posts it on every Perl story, unchanged, without evidence of reading anything beyond the world "Perl" in the blurb. That's not insight. That's obsession.

Re:Troll-by-reference

[Anonymous Coward]

Probably because he doesn't know what he's talking about, and there are numerous errors in his post.

For example, he claims that each variable has its own prefix in Perl 5. That is completely false. A "variable" in perl is a reference to a typeglob, which contains memory slots for each type of value a "name" ( variable ) in perl can store: a scalar, a hash, an array, a filehandle, and a subroutine. The prefixes before a name in perl determine which slot you access ( it is the context you are calling the variable in ).

For instance, @var for the array slot, $var for the scalar slot, %var for the hash slot, &var for subref, etc.

Each "variable type" does NOT have its own prefix. The prefixes specify the context that the variable is being called in.

By the way, *var references the entire "typeglob" at once, allowing you to do things like:

$var1 = "name";
@var1 = (1,2,3);

*anothervar = *var;

print $var1
name
print $var1[1]
2

Maybe if the person actually knew anything at all about perl, then his post would actually be worth paying attention to.

Re:Troll-by-reference

[Ed Avis]

Your terminology, using 'variable' to refer to a whole typeglob slot, is nonstandard in the Perl world. Most programmers (and Larry himself AFAIK) would say that $x is a scalar variable and @x is an array variable. They are both variables and both different.

Referring to the whole typeglob with *var is rather esoteric (not saying it's never used, just it is used far far less often than accessing variables normally), and when you do use it, you talk about typeglobs not variables. *var is a typeglob, which brings together several different variables of the same name.

At least, that is the terminology almost everyone uses.

SURPRISE

[Anonymous Coward]

this is the 1 reply beneath your current threshold

TMTOWDI

[redunzl]

There's More Than One-thousand Ways To Do It

i will perl no more forever -- and i've never been happier.

Try...

[Anonymous Coward]

a web search...

seems like

[butane_bob2003]

the language is becoming more obtuse if thats possible. The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax. Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either. I guess they don't go for re-use much in perl progging. I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

Re:seems like

[chromatic]

the language is becoming more obtuse if thats possible.

Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.

The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax.

See the Inline modules on the CPAN.

I've never met a perl programmer who could tell me what a design pattern is either.

See Perl Design Paterns, an article on Perl.com.

I guess they don't go for re-use much in perl progging.

See the CPAN.

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

I've read the Perl parser. You're right about this one.

Re:seems like

[jandrese]

No, once a Perl programmer notices a design pattern they codify the whole process into a CPAN module. :)

Actually, design patterns are the kind of thing you think about on large projects with groups of coders, design documents, and managers, not on smaller text parsing scripts.

Re:seems like

[Aadain2001]

Exactly. I'm currently doing a very nice sized project in Perl (currently over 3,000 lines of code, inline documentation(thanks POD!), and debug lines), and I am adhering to a very strict design pattern because I know that I am not going to be the one to maintain this for the next several years. Perl is great at quick little hacks that help make your life simpler without thinking too hard. But that doesn't prevent Perl from being used in a full blown project just like any other language such as C, C++, Java, etc. It all boils down to what the programmers are like. If they were the kind that would make variables names like "hg56sss_str", then they will continue to do so in Perl, and to an even more maddening extent since Perl gives them greater freedom to be creative.

Re:seems like

[RelentlessWeevilHowl]

Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.

That particular piece of Perl 6 functionality would have to be expressed as that particular chunk of Perl 5 code to get a comparable effect. Fine.

My personal concern is in how in the preceeding 10 pages, he describes another umpteen "simpler and clearer" ways of achieving the same effect (most of which seem to have subtle gotchas).

Re:seems like

[chromatic]

That's a fair concern.

Damian intended to demonstrate as many of the new features as possible while reusing one example and progressing through more and more powerful techniques. He thought it'd be simpler and easier to understand. It's a difficult article to write, no matter how you approach it, since it summarizes to a list of "Here's another way to do that, having these advantages and these disadvantages:" statements.

I think he suceeded, but it's also possible that I'm too close to the material to judge this accurately.

Re:seems like

[Anonymous Coward]

there's a saying... 'only perl can parse perl'.

Re:seems like

[mshiltonj]

it's also possible that I'm too close to the material to judge this accurately.

chromatic? close to perl? say it ain't so!

Re:seems like

[chromatic]

Heh, true. I meant the Exegesis, though.

Re:seems like

[jdavidb]

I viewed a presentation about design patterns at YAPC::NA::2002.

I once had a software engineering professor who over a period of several weeks refused to believe me that Perl was an object-oriented language (like C++, not like Java or Smalltalk). He was finally convinced when he taught design patterns, giving the factory class as an example, and I said, "I did that this morning in Perl." His jaw dropped.

I still consider myself a Perl programmer, but I was laid off last November and moved to a new job that is primarily Oracle PL/SQL programming. I only knew the bare minimum of PL/SQL, but already I am one of the guys people go to in this office when they have PL/SQL questions. I've helped about six people more experienced than me through fixing mutating table problems, and I'm learning more constantly through reading and experience.

I credit my experience with Perl extensively for helping me to be a good PL/SQL programmer. In my experience, good Perl programmers (the ones you're likely to see speaking at a conference or writing a book) use the right tool for the job, constantly pick up new languages (Ruby and Python are pretty popular), and do a better job programming in those languages because of their Perl experience.

Re:seems like

[Anonymous Coward]

So, basically, you know some lousy programmers who use Perl and you are making generalizations based on that. I know some truly awful programmers who use Java, but I don't go around blaming Java for this. At my current job, we build tests for every component, use CPAN modules extensively, refactor when appropriate, and follow established principles of good OO design, all in Perl. You need to get out more.

Re:seems like

[n1vux]

The perl programmers I know ... I've never met a perl programmer who could tell me what a design pattern is either.

Maybe you need to get out more? The intersection of Perl-fanatics and readers of Alexander (not just GOF, but the original, architecture of bricks and mortar) is not a null set. I'll be happy to be met next time you're in Boston. You're buying the beer.

[SOJ] Why would Perl programmers need to learn a new language, when Perl is a living language that will always be new? [EOJ] :-)

Hmm. Why am I answering a troll from someone named "butane bob"?

Writing a Perl parser without YACC should be reasonable with Perl 6. ;-)

require sig 1.3

Re:seems like

[Angst Badger]

Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language).

I came from C (not that I exactly left it) and I didn't find Perl unnatural, and it hasn't crippled me for other purposes, unless you count involuntarily prepending '$' to variable names in C after a long session of Perl coding. As far as I am concerned, there are only three major problems with Perl:

1. Type sigils. The underlying theory necessary to implement variables without special leading characters dates back, oh, thirty years or so. (This is particularly egregious with PHP, where there is only one generic sigil for all types rendering them pointless anyway, but that's a separate gripe.) The '$' notation for shell scripts existed to simplify the ad hoc parsers most shells use; it has no place in a full-blown language.

2. Complex data structures. Even C syntax for deeply nested pointers is cleaner than Perl. Mostly because of 1, above.

3. Writing large applications in Perl depends totally on intense self-discipline as a programmer, and everything about Perl actively encourages you to break that discipline. TMTOWTDI, past a certain point, is a liability, especially with large development teams.

Obviously, Larry and Co. feel differently about these things, but they drive me up the fnarking wall.

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

If Satan really wanted to put the screws to you, he'd require yacc. (The inside joke, for those who aren't deeply into compiler design, is that Perl can't be parsed by a yacc parser because it's not even remotely context-free. Whether that's a good idea or not is a debate that goes back to the days of the ALGOL design committee. The practical effect is that the syntax of Perl is described not by a formal grammar but by the implementation itself, which makes it all but impossible to validate a competing implementation.)

Re:seems like

[Magius_AR]

I've never met a perl programmer who could tell me what a design pattern is either

Then would you like to go out for a beer?

A design pattern is basically a code solution engineered to solve problems that occur over and over in software design.
It's a basic precept of reusable object-oriented code.

In fact, most people use them while they code without even realizing it. I own a copy of the Gamma/Helm/Johnson/Vlissides Design Patterns book. I'm fully versed in C++/C (it was my first language). I use design patterns extensively in my C++ code, which I love coding in btw (my favorite object oriented language)...oodles and oodles of Singletons, Flyweights, Prototypes, and Abstract Factories just to name some of the primaries. Additionally, I consider myself a Perl veteran. Given the choice between the two, I prefer Perl for both readability and flexibility. Somehow it just makes more sense to say:

&parse if ($is_true) or exit(1);

then it is to say

if ($is_true) { parse(); } else { exit(1); }

The first flows, like poetry, like reading a book.
The C code is choppy and mechanical.
You may have whatever presumptions you want about the language, but a good Perl programmer can write some amazing code. It's just alot easier to write spaghetti Perl code than C. That doesn't mean you can't make Perl code look and perform nice.

As for code re-use, ever heard of CPAN?

Oh yeah, since Perl I've learned 3 new languages, including Java, Javascript, and SQL. And no I don't believe it was any harder learning them.

I'm shocked how many Perl hating trolls can get modded up on Slashdot.

Re:seems like

[larry bagina]

Actually, C allows:

if (is_true) parse(); else exit(0);

perl's statement if (condition) is nice, but I feel it only exists to make up for the lame if/elsif/else support.

Honestly, I wonder why if/else/elsif blocks need to be enclosed with {}. C has shift/reduce error, but perl is context-sensitive, so it can't be explained by language purity.

Re:seems like

[bsartist]

Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either.

I write Cocoa apps in Perl every day; in doing so, I use delegation, observer, and MVC design patterns, among others, on a regular basis. I picked up the habit after - wait for it - learning Objective-C. What's more, I wrote and maintain an open source project that's approaching 10k lines of mixed Perl, Objective-C, and C.

I will grant you this - I don't think we've met. ;-)

Re:seems like

[Dog and Pony]

I'm not sure if I agree with you that those are problems. Different, yes, but not necessary problems. I came from C and Java mainly, when I encountered Perl, and at first I thought it looked butt ugly and a bit hard to read, yes. But the benefits can be immense.

The sigils really help code being readable, you always know what to expect from the variable. Although, good naming and good programming practices is enough in most other languages.

Then, like someone else pointed out in some other post up there, you can always be sure that $vtime is a variable, while you never know if vtime might be a reserved keyword in the next version of the language.

But one of the greatest wins are the ease of use that comes with:

print "My name is $name.\n"

Ruby does this like this:

print "My name is #{name}.\n"

(though most use puts) - I find this not really as clear, and a bit more typing. But it allows any expression, which is nice. That kind of magic exists in Perl too, but not easier.

Compared to Java (and others)

System.println("My name is " + name + ".");

It is a winner hands down.

2. I think the complex data structuers are really easy to read and grok in Perl. It is easy to obfuscate these parts of course, but really, there are only a few short rules, and once you have those down, you only need to read left to right. See References quick reference. And creating them is really easy. Just write the structure as you want it.

Writing large applications in Perl depends totally on intense self-discipline as a programmer, and everything about Perl actively encourages you to break that discipline.

This is almost total bullshit. Only bad programmers write bad Perl code, and bad programmers can write bad code in any language. Badly disciplined, inexperienced or just "bad lazy" coders write unmaintainable messes in any language, and I can tell you that they are no easier to untangle in Java or other languages either. I worked in a Java shop for a bit over two years, and the unholy mess some people could create in a coffee break is worse than most things I ever seen in Perl. And at least in those days, Java was the be-all hype language where everything would be so nice, because it was OO. Bullshit.

The thing is that you need to know what you do in any language. And you need discipline in any language. The difference is that the mess does not look the same when you mess up in Perl as in for example Java. But the long compact blocks of code that some people is a Perl trademark is not one of those, I've seen those in most any language. I've seen people write almost complete applications in one method, in one class in Java.

Take advantage of your language, whichever it might be, know what you are doing, and don't cheat (other than in good ways ;-) and you'll be fine.

Re:seems like

[Magius_AR]

Honestly, I wonder why if/else/elsif blocks need to be enclosed with {}

I've always preferred it...I hate "if" one-liners. Aside from being a pain in the ass to modify if you need to turn it into a multi-line block, it makes reading coding even more annoying, can't even do searches on braces to move between blocks.

Re:seems like

[butane_bob2003]

That's an interesting bit about yacc and Perl. I had forgotten that perl could probably only be parsed by perl itself. One thing I have found perl good for is writing quick and dirty hard coded parsers, which is close to it's original intent in the first place.

Re:seems like

[butane_bob2003]

Thanks for the info, esp. the design patterns page. (I'll have to forward that on to some folks I work with)

Perl does have clear ways of expressing things, it's just the 9 other ways of expressing an idea that can make an it unclear (well, at least until you have seen them all a few times).
Quoting from the last page:

The vast majority of [new features and alternatives] are special-purpose, power-user techniques that you may well never need to use or even know about.

So everyone who is just getting their feet wet will have No Idea what the Power Coders are thinking, right? Maybe the intent is to build out every limitation.

The last time I wrote perl, it was to re-write portions of Bugzilla to add functionality and clean up the interface a bit. (this was 3 or 4 years ago) The state of the Bugzilla sources at the time might have _something_ to do with my apprehension to perl. Since then I think Bugzilla was re-engineer'd at least once. It seems like constant change in a language would be a bad thing, right?

Re:seems like

[butane_bob2003]

True, these are generalizations. We have two camps here at work, the perl guys and the OO guys. There are some who walk the fine line between, but for critical projects and rapid development, they stick to Java. I agree that it's not the fault of the language, it's the choices a programmer makes that can make code stink. Perl just gives you many more choices to choose from. I'd get out more if I didn't have to work all the time...

Re:seems like

[butane_bob2003]

Maybe, like me, you are avoiding work? I can think of no other reason why I would choose to troll on an article about Perl. I really have no hard feelings toward the language or its honorable users, as long as I'm not duty bound to use it myself.
The name 'butane_bob', for anyone interested, comes from a favorite song of mine by Aphex Twin, "Laughable Butane Bob" from the 12" titled "Hangable Autobulb". which can be heard somewhere in this mix: http://www.brucewang.com/071501.jsp

Re:seems like

[butane_bob2003]

Oh no! I dont hate Perl. I have no strong religous beliefs at all! I was trolling a bit. I was expecting to get modded off into oblivion. Just trying to start trouble.

Re:seems like

[butane_bob2003]

Just be glad it does not require closing if(coditions) with an 'fi' statement. Christ. I could complain all day about shell languages.

Re:seems like

[chromatic]

So everyone who is just getting their feet wet will have No Idea what the Power Coders are thinking, right?

That's true of any programming language. The question is where you put the simplicity and where you put the complexity. (I've written about this before -- though see Schuyler's take for a better explanation).

Unless you have a really, really simple language that has no libraries and no chance to grow, odds are you'll have to adapt to something that's different in someone else's code, if you ever read code from someone else. Larry's really good about hiding complexity and allowing people to be productive while knowing a small fraction of what's available in Perl. I believe Perl 6 will make it easier to encapsulate this complexity where you don't have to see it unless you really really need to see it.

What you describe sounds like a standard maintenance program. I don't write Perl code that anyone off of the street can read without knowing Perl. I write code that competent developers can maintain. A big part of that is self-discipline, which no language worth using can enforce.

It seems like constant change in a language would be a bad thing, right?

It certainly can be. I'm willing to go on record that the problems in Bugzilla were more lack of discipline on the part of its developers than any systemic problem. Consider how often any open source project is rewritten and redesigned (not refactored). This is a problem that afflicts every language.

Re:seems like

[butane_bob2003]

Have to agree. Libraries are one thing, and more will always appear to provide solutions to new problems. One of the fundamental differnces in philosophy between Perl and (more or less) OO languages is the desire to allow globalized access to variables and functions. There are many arguments for and against this. I dont LIKE it, but I think in the context of a scripting language it's acceptable. You probably use namespace imports and keep everything fully qualified and readable for your own sanity and mercy towards others. This is good practice, but the language does not enforce it. Therein lies another difference: Perl enforces almost nothing. If something can be done, folks are going to do it.

Re:seems like

[chromatic]

I fear this thread is about to die, but you might be interested in a Lamba the Ultimate thread about macros in Java. Designing a language well means finding a balance between power and flexibility. I'm personally very much against taking out features that might confuse new programmers or that can be misused, but I do believe in managing complexity well.

Very few languages that completely prevent beginners from doing stupid things allow experienced users to do very clever things. I hate that.

I wonder how many mod points the editors get?

[Mayak]

Probably enough to mod this down. Probably unlimited enough to mod down anything un-Slashdot.

GNAA LIKE PERL FOR GAY NIGGER SCRIPTS

[Anonymous Coward]

The Gay Nigger Association of America (GNAA) is the group that represents the world's Gay Nigger population as well as those non gay, non nigger patrons that support it. Its mission is to foster a gay and free-loving climate that supports and promotes our members' creative and financial vitality. Its members are the gay niggers that comprise the most vibrant national gay nigger conglomerate in the world. GNAA members create, manufacture and/or distribute approximately 90% of all legitimate pro-homosexual propaganda and blue, rubber dicks produced and sold in the United States.

We strongly urge you to join the GNAA and support our cause. Gay Niggers everywhere need your help!

BE NIGGER!

BE GAY!

JOIN THE GNAA!!

Join #GNAA on the EFNet IRC Network today! (irc.secsup.org, irc.easynews.com, irc.servercentral.net)

________________________________________________
| ______________________________________._a,____ |
| _______a_._______a_______aj#0s_____aWY!400.___ |
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ |
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ |
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ |
| ________"#,___*@`__-N#____`___-!^_____________ |
| _________#1__________?________________________ |
| _________j1___________________________________ |
| ____a,___jk_ GAY_NIGGER_ASSOCIATION_OF_AMERICA_|
| ____!4yaa#l___________________________________ |
| ______-"!^____________________________________ |
` _______________________________________________'
-posted by GNAA member Penisbird

Re:For those who don't know....

[ajs]

And everyone will then use Python

Normally, I would not reply to a troll, but this one allows me to bring up an interesting point for those polarists that think Perl and Python are somehow diametrically opposed.

While they certainly have different approaches to language design, Parrot (the Perl 6 back-end) will have front-ends for many languages. One of them will, in fact, be Python.

So, will everyone "then use Python", well perhaps, but if they do, they'll be using Perl 6 ;-)

DONT MOD THE GNAA DOWN AS OVERRATED

[Anonymous Coward]

cuz I'll just post the same shit again

The Gay Nigger Association of America (GNAA) is the group that represents the world's Gay Nigger population as well as those non gay, non nigger patrons that support it. Its mission is to foster a gay and free-loving climate that supports and promotes our members' creative and financial vitality. Its members are the gay niggers that comprise the most vibrant national gay nigger conglomerate in the world. GNAA members create, manufacture and/or distribute approximately 90% of all legitimate pro-homosexual propaganda and blue, rubber dicks produced and sold in the United States.

We strongly urge you to join the GNAA and support our cause. Gay Niggers everywhere need your help!

BE NIGGER!

BE GAY!

JOIN THE GNAA!!

Join #GNAA on the EFNet IRC Network today! (irc.secsup.org, irc.easynews.com, irc.servercentral.net)

________________________________________________
| ______________________________________._a,____ |
| _______a_._______a_______aj#0s_____aWY!400.___ |
| __ad#7!!*P____a.d#0a____#!-_#0i___.#!__W#0#___ |
| _j#'_.00#,___4#dP_"#,__j#,__0#Wi___*00P!_"#L,_ |
| _"#ga#9!01___"#01__40,_"4Lj#!_4#g_________"01_ |
| ________"#,___*@`__-N#____`___-!^_____________ |
| _________#1__________?________________________ |
| _________j1___________________________________ |
| ____a,___jk_ GAY_NIGGER_ASSOCIATION_OF_AMERICA_|
| ____!4yaa#l___________________________________ |
| ______-"!^____________________________________ |
` _______________________________________________'
-posted by GNAA member Penisbird

Release on the long road to nowhere

[amightywind]

This guy is not trolling. He makes several valid points. Perl 5 is a good thing if you need to transform text or write a CGI program. For anything longer than a few hundred lines you should probably use something else. That is the way its been and the way it will be. Perl reached the limits of its usefulness a long ago. Perl 6 and its rabid following are on the long road to nowhere.

Re:Release on the long road to nowhere

[keesh]

This guy is not trolling

Erm, yes I was...

Re:Release on the long road to nowhere

[Mike Schiraldi]

Okay, that comment just made me change your little color dealie from red to green.

Re:Release on the long road to nowhere

[Ed Avis]

This guy is not trolling. He makes several valid points.

The two are not mutually exclusive, you know...

FWIW I strongly disagree with your assertion that Perl should not be used for anything longer than a few hundred lines. For longer programs you do need more discipline and a more structured approach. That is as true in Perl as in any language. Writing clear and well-separated code does not have to mean UML diagrams. (Though you can have those with Perl, if you really insist.)

Holy syntax overload batman!

[jtdubs]

I've never seen a language with so much syntax. Perl 5 had more than enough, now they've more than doubled it.

You have { } for blocks, and for automatically parameterized blocks (ie. anonymous functions).

You have =, := and ::=, ~=, ~~, .... = does assignment, := does binding and ::= works at compile time and is normally used to define types and such, ~= is pattern matching, and I have no idea what ~~ does.

You have the new <== and ==> pipeline operators. They are dataflow operators. Like so:

$foo ==> my_func ==> $bar;
is the same as
$bar <== my_func <== $foo
is the same as
$bar = my_func($foo);
is the same as ...

You already had the $,@,%,& to prefix variables with.

You have more uses for * now, as in slurpy arrays and splicing. As in, the * can make an array parameter slurp up all the remaining arguments, or it can make an argument flatten into a list of arguments.

They've added some wierd << foo >> syntax that I didn't even bother to read about as I was in syntax shock.

They've added ^ which indicates that a variable in a block is actually a parameter and therefore the blocks is actually a parameterized blocks (ie. anonymous function). So, now you can't tell if something surrounded by { }'s is just a block of code or whether it's an anonymous function. Although, I don't think this is a problem as it's usually obvious from the context.

And I didn't even read to the end of the paper!

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

Justin Dubs

Re:Holy syntax overload batman!

[MagikSlinger]

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

See? My Modified Godwin's law is right!

On a serious note, you could always write Lisp like programs in Perl and thus get the flexibility of Lisp (including having Perl build functions which are then called by the code). I've done it.

It's just that Larry is using syntax to provide ever more expressibility and pre-defined cases. Whether or not this is a good thing depends on your biases.

I always feel like my head is going to explode after reading an Apocalypse.

Re:Holy syntax overload batman!

[ajs]

if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

Ok, first off... Perl 6 will use Unicode by default, of course, and yes there is some talk of using things like the dot-product symbol to mean roughly what you would expect it to mean. However, that is limited by the practicality of entering and viewing Unicode characters with modern equipment. Perhaps in another 10 years....

Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).

You already had the $,@,%,& to prefix variables with.

But in Perl 6, they are rationalized a great deal, and made simpler to use (e.g. Perl used to use the glyph to indicate the type of operation being performed on a variable, no the type of the variable. In Perl 6, that has been changed to reflect what most programmers expect, so @foo[0] is the correct notation for accessing the zeroth element of an array, not Perl 5's $foo[0]).

Perl 6 is going ot be hard for outsiders to jump into at this stage because it doesn't exist yet. If you're not steeped in the culture of Perl 6's design, you won't be able to see where it's going, so everything looks kind of scary.

However, in about 10 years, I expect Perl 6 to be seen as the starting point of a new kind of programming and a level of symbolic abstraction that allows us to start looking at code in a much more constructive way.

Re:Holy syntax overload batman!

[CanSpice]

Makes me want to go write some Lisp, which is perhaps the antithesis of Perl. Lisp has the maximum possibile flexibility through having the minimum possible syntax. Perl originally had little flexibility, now they are trying to add more by adding more syntax. The problem is, if they want to get anywhere near Lisp-level flexibility with this method they'll need to move to Unicode for the syntax!

But, you see, the problem with writing in Lisp is you're writing in Lisp.

Re:Holy syntax overload batman!

[imnoteddy]

Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility.

I disagree. Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions) which lets you build a data structure and then pass it to one of Lisp's EVAL family. Perl's eval(), while useful, is a poor cousin of Lisp's facilities.

Execute data, not code.

Re:Holy syntax overload batman!

[MoxFulder]

You have more uses for * now, as in slurpy arrays and splicing. As in, the * can make an array parameter slurp up all the remaining arguments, or it can make an argument flatten into a list of arguments.

Wo betide the fool who still wants to use * for multiplication!

Re:Holy syntax overload batman!

[ajs]

Much of Lisp's flexibility comes from having programs represented in the same form as data (S-expressions)

That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can). However, most Lisp code really doesn't benefit from this fact as much as it does from its side effects.

Let me give you an example. One side effect of what you describe is lambda functions, and a cool feature distinguishes lambda functions from simple function pointers in C is closures.

Perl provides the equivalent of Lambda functions in the form of anonymous subroutines, and they are also closures.

So, while you are correct that much of the flexibility of lisp falls out of S-expressions, it's not true that you cannot have that flexibility WITHOUT S-expressions.

What Lisp *does* have that Perl 5 does not is an excellent macro mechanism (which also falls out of S-expressions).

That is probably the one major thing that Perl 6 will need in order to truely surpass Lisp's flexibility for general purpose tasks, and while it has been much discussed on the mailing lists, it won't be realistic to decide on it, and nail it down fully for a few itterations of the apocolypses. But it's certainly clear that Perl needs some form of macro system that is at least very nearly as flexible as Lisp's.

Perl's eval is a red-herring. It's really a totally different (pair of) functions from Lisp's eval, acting as either parser or exception-handler. Lisp's eval is much more comparable to Perl 5's ->() operator which dereferences and executes a code reference which can be a reference to an anonymous or named closure, a subroutine or a regular method.

You can also build CVs, which are just data-structures, in C and present them to Perl as a code reference. That does give you all of the power of Lisp, but you have to drop down to C to do it, so it isn't at all trivial or useful for routine use.

Re:Holy syntax overload batman!

[Fastolfe]

Is this "macro system" different than the one presented in this article? Damian's showcasing a macro syntax on some of the later pages of the article that involves evaluating Perl code (similarly to a Perl 5 BEGIN block) and injecting the returned string directly into the code where the macro is called, where it is immediately parsed as the parser picks up where it left off.

I admit that I'm not completely familiar with how Lisp does things, but is this a sufficient macro system for your needs, or are you suggesting that something better is needed?

Re:Holy syntax overload batman!

[Ed Avis]

Fppt. C has * for multiplication, pointer dereference, and as part of the comment syntax, but it doesn't seem to be confusing. It all depends on the context in which the operator appears. There's nothing wrong with context-dependency in a language, provided it doesn't get counterintuitive.

Re:Holy syntax overload batman!

[Ed Avis]

Lisp has the minimum possible syntax? You sure about that? I'm no Lisp hacker, but it seems that the language has at least two ways of defining functions, at least three different kinds of quoting (plus anti-quoting), and a reasonable number of syntactic shortcuts like ; for constructing pairs. In terms of total punctuation per line of code, Lisp and Perl probably come out about equal.

Re:Holy syntax overload batman!

[Anonymous Coward]

Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility.

Muhahaha, hilarious! Try 59%. But argue away, man.

Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use

Nah, they just took a small step closer.

Re:Holy syntax overload batman!

[Trilaka]

Ok, I must clarify a few things:

(though Perl 6 comes as close as a truely compiled language reasonably can)

I can't believe I even read that. Perhaps you are just trolling, but for the sake of those who do not know better, lisp is actually more of a truly compiled language than perl. Perl is interpretted by the perl interpreter (aptly named perl). Lisp is compiled down to machine code.

Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually. Granted, my personal feeling is that it is easier to have a program write a program that is written in s-exps than in Perl 6, but Perl 6 does provide the capability.

The options mentioned in this Exegesis point out that macros in Perl 6 can return either blocks or strings. If a block is returned, its syntax tree is injected into the place occupied by the call to the macro. If a string is returned, it replaces the macro call, and then the resulting expression is parsed and compiled. All of this is done at compile-time, of course.

Secondly, and very interestingly, macros can define their own syntax using Rules (regexps) to pull parameters from free-form program text, rather than relying in the comma-separated Perl6 expression default.

All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me, they've just moved the parsing code from the programmer's brain (since you are effectively writing parse trees rather than syntax when programming in lisp) to a parsing module within the code.

Remember though folks, if you don't want to deal with this complexity, you don't need to. But if you do need to, its good to know that its there.

Re:Holy syntax overload batman!

[Anonymous Coward]

Any day over fucking Perl, man. Any day!

Re:Holy syntax overload batman!

[sig cop]

Don't forget that '*' is used in C for pointer declarations, which is distinct from pointer dereferencing. Also, '*=' which is related to '*' as multiplier, but distinct, too. 5 different uses for the same character, 3 uses for the plain '*' operator.

Re:Holy syntax overload batman!

[Anonymous Coward]

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

--jwz

Re:Holy syntax overload batman!

[jtdubs]

Having multiple functions that do the same thing is not the same as having more syntax. You could view the amount of syntax a language has as a parallel to how hard it is to describe its tokenizer. That's a rough generalization, but gets the point across.

In Lisp the only way to define a function is with lambda. The other ways are all macros that expand to include a call to lambda.

(defun foo (x y) (+ x y))
is a macro that expands to something similar to
(set (symbol-function 'foo) (lambda (x y) (+ x y)))

Perl uses {} for blocks, () for lists, [] for arrays, {} for hashes, ; to delimit statements, $ for scalars, @ for arrays, % for hashes, & for functions, \ for references, <== and ==> for pipelines, -> for anonymous subs, => within hashes, = for assignment, := for binding, ::= for compile-time binding, m// for matching, s/// for substitutions, tr/// for translations, . for member access, :: for package access, {...} for function declarations, <<>> for labels, * for other kinds of lists, <> for file reading, [] for array slicing, and # for comments.

And I haven't even mentioned the plethora of keywords in Perl, such as my, our, of, sub, ....

Lisp has () for lists, #() for vectors, ' for quoting, ` for backquoting, , and ,@ for unquoting, #. for read-time processing, : and :: for package access. The semi-colon in Lisp is used for comments, not for making pairs.

That's all I can think of for Lisp, offhand.

Justin Dubs

Re:Holy syntax overload batman!

[ajs]

lisp is actually more of a truly compiled language than perl

Yes, and no. First off, don't assume that I don't know Lisp. I try to hide it at work because I have so many co-workers working in Lisp, and a basic working knowledge is actually more of a handicap in this crowd than ignorance....

Lisp is never truely compiled. It can be compiled down to machine code, but you always have to keep the S-expressions around, just as you keep a non-static inline function around in C or C++, except in C and C++ that copy that you keep is compiled. In Lisp it must not be!

Hence, my comment about Perl 6 (not Perl, BTW, which I use generically to refer to any version of Perl that has actually been released, and I say Perl 5 when I mean Perl 5) getting as close as any truly compiled language reasonably can. Perl 6 will not retain its syntax tree post compilation, and *that* is why I call it a truely compiled language. There *may* be byte-code, but that's a function of the back-end depending on if you're using a VM like parrot or compiling to machine code.

If you re-read my comment, you'll find that it was not a slam against Lisp. I like and respect Lisp. If you can only see languages as polar extremes, then I don't think you'll enjoy Perl 6.

Secondly, this Exegesis covered Perl6's macro capabilities. It works very much like lisps, actually.

No, not really. It looks similar, and in as far as most people will use them, they will be similar.

I had not actually realized that A6 had snuck macros in. I thought that Larry said he was defering them for later. Then again, I've been off the list for a while, concentrating on work, so it's good to see so much happened.

Still, macros in Perl 6 are a feature of Perl 6's built-in parser generator features (the replacement for regular expressions, and a first in general purpose programming languages, as far as I know, but there may be an expert system shell that provided something like this level of integration with the core language).

In Lisp, macros are expression constructors that return a lambda. Very, very different, though similar in application.

All in all, if this can be implemented as they have described, in an efficient manner, I will be impressed. It seems very lispy to me

Not really, like I say, it's more like SNOBOL or Prolog than Lisp.

The ability to say

rule comment {
/\* .*? \*/
| \s+
}
rule expression {
<comment>?
(\d+ | <expression> \+ <expression> )
<comment>?
}
rule program {
<expression> ( \; <expression> )*
| # Nothing....
}
while <>->$_ {
if /^ <program> $/ {
print "Valid code\n";
}
}

Will be quite interesting....

Re:Holy syntax overload batman!

[ajs]

As I said in the other reply, I thought macros were being held off until the grammer building system in Perl 6 was better fleshed-out. I haven't read A6 yet, only the stuff that Larry wrote leading up to it and a little bit of the chatter after, so I wasn't aware that had snuck in.

Re:Holy syntax overload batman!

[Anonymous Coward]

Of those, only LAMBDA, CONS, and QUOTE are truly axiomatic; all that other stuff is merely syntactic sugar. Lisp is particularly good at letting you make your own more appropriate syntax, which is actually how things like QUASIQUOTE/UNQUOTE came about (for those who haven't heard of these, think of interpolating an expression's value into a data structure instead of into a string).

Re:Holy syntax overload batman!

[_ska]

''Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).''

Ok, thats funny. I can't speak to the flexibility of Perl 6, but you are on some serious chemicals if you argue that perl5 has 99% of Lisps flexibility.

Perl has some real strengths (and real weaknesses, of course), but it is pushing it to claim it even approaches 50% of the flexibility of lisp. I would put it closer to 20%, but perhaps could be argued upward a bit. We are talking about *flexibility* here, not best-language-cause, so
here are just a few of the reasons perl is way behind lisp (let alone 20 years ago lisp (cltl1)) in flexibility:

'defmacro (there goes 30% right there)

'defgeneric & 'defclass (don't talk to me about perls alleged object system.)

'compile

closures
introspection
semantic sanity
read/write symmetry
applicative programming that works
decent numerics

the list goes and on....

Re:Holy syntax overload batman!

[Anonymous Coward]

"Consider it a "live" language, instead of a dead one. Pity Larry is the only native speaker... I think...

At some point, I'll probably write something that looks like line noise and yet is a functional program. Or something.

" =~ s/p?[to](b).?a\1ly/will/

Re:Holy syntax overload batman!

[smallpaul]

Remember though folks, if you don't want to deal with this complexity, you don't need to.

Sure, as long as you never need to maintain code that deals with it.

Re:Holy syntax overload batman!

[jasoegaard]

> Lisp is never truely compiled.
Yes it is.

> It can be compiled down to machine code, but you > always have to keep the S-expressions around,

No.

> In Lisp, macros are expression constructors that
> return a lambda.

No. A macro rewrites one expression to another.
No need to talk about lambda here.

Re:Holy syntax overload batman!

[_ska]

That's the part that Perl does not have, and never will (though Perl 6 comes as close as a truely compiled language reasonably can)

Ah. ajs, you do know that most lisp's compile to machine code these days (actually, they have for decades), don't you? In fact there are some very, very good optimizing lisp compilers.

So, while you are correct that much of the flexibility of lisp falls out of S-expressions, it's not true that you cannot have that flexibility WITHOUT S-expressions.

This is probably not true. Many languages have tried, and failed. I don't know enough about perl6 to be sure, but it is probably just another in a long line of attempts...

What Lisp *does* have that Perl 5 does not is an excellent macro mechanism (which also falls out of S-expressions).

A fair bit of lisps flexibility and power comes from the macro system, so your statements are fairly reasonable; however there is no a-priori reason to accept that perl6 will be as flexible or as powerful as lisp --- perl5 isn't even close.

Re:Holy syntax overload batman!

[Anonymous Coward]

Just keep in mind that Perl6 regexes will have the /x behavior by default, so that last line could be less line-noise-ish. :-)

Re:Holy syntax overload batman!

[ajs]

You have a good point at the end about expressions. I was being a bit too restrictive. I disagree with you elsewhere. Perhaps some compilers do what you suggest, but GCC allows for FILE* to iostream conversion in ways that ANSI C++ does not, and I don't call that C++ either.

You seem to only focus on where we disagree, so I'm going to let this one go for now. I do agree with you that Lisp is a flexible and powerful language. I think it was a shame that Perl only started to adopt some Lispisms as of version 5, and will have to wait until version 6 to "go all the way" as it were.

As of Perl 6, I don't think Perl and Lisp will have any major differences that don't result from the choice of syntax. The flexibility and functionality is all there.

P.S. -- sorry.

[mr_luc]

oh, and sorry about the Perl applications thing. That is for my friend, who has stopped responding to instant messenger or email because he's mad at me. I'm pretty sure he Slashdot, though. ;)

He was always talking about how he would be a Perl application developer, because Perl was so leet. I think it's leet, but only really shines for duct tape work.

Jeremy, if you are reading this -- stop being such a little bitch and respond to my emails, dammit! :) We gotta set something up the next time I'm in the area, a LAN or something.

bleh - *cough*moron*cough*

[Ender Ryan]

j/k :P

You don't know what you're talking about. Weakly typed languages have nothing to do with script programmers not being able to specify types(what is that supposed to mean?), it is purely a convenience, and helps reduce the number of variables and lines of code required to get a job done. Really, it does.

Someone else already posted an example.

int a=1; WriteLine("a is type {0} and has value {1}", a.GetType().ToString(), a.ToString());

The beauty of it is when you translate the text. The translator now has option of moving parameters around inside the text. Awesome.

I admit, that is pretty cool.

great

[imipak]

there goes my evening...

perl?

[trybywrench]

they have perl on computers now? thats unpossible!

Any Sufficiently Advanced Language...

[Vagary]

A disclaimer: I used to program Perl for a living, but we had a falling out some years ago (around 5.0?). So if you don't think there's any merit to what I'm saying, then feel free to consider this a troll:

Shortly after I started reading Exegesis 6 I was somewhat frightened by how complex Perl had become since I stopped keeping track of updates. Of course scripting languages have always been known for borrowing the best from other programming languages, so I kept reading in the hopes that I'd recognise something. I saw some features like the is constant declaration and started worrying that maybe they'd decided to borrow some features from the very popular but insanely evil Visual Basic. But then I saw this:

type Selector ::= Code | Class | Rule | Hash;

and realised that, just as Python is (alleged to be?) adding Lisp-like features, Perl is adding ML-like features! That line above is (minus the '::' and ';') straight out of a Haskell program. Then I started to notice more Haskell-like syntax:

• Anonymous function declaration syntax: -> $animal { $animal.size < $breadbox } would be (\animal -> animal.size < breadbox) in Haskell
• Multisubs are like pattern matching: multi sub feed(Cat $c) {...} multi sub feed(Lion $l) {...} would be
  feed (Cat c) = ...
  feed (Lion l) = ...
• New infix operator definitions: infix:~|_|~ would be the function named (~|_|~)
• Junctions are like list comprehensions: all(newvals) would be [x | x <- newvals] (it almost seems like junctions are lazy from the way Damian talks about them?!)

And I'm sure a more thorough reading would turn up even more. (For example, the smart-match operator reminds me of the type inferences done in a Hindley-Milner type system.) So it appears that any sufficiently advanced language contains an implementation of a purely functional language, not specifically Scheme. :) Has Damian (who certainly has Haskell exposure) or Larry ever mentioned any of these influences?

Forgot Currying!

[Vagary]

One more thing:
I'm really happy to see Perl include currying, I can't think of a programming language that I would be completely happy using without it.

Dear gods, they've finally done it...

[then, it was nigh]

"all(<<your base>>) are Belong("to us");" is now a legal Perl 6 statement. I'm fairly certain that's one of the signs of the impending Apocalypse (umm... pun not intended).

Hahaha... um... no.

[mobileskimo]

If you're gonna troll, atleast do it well. Or just don't.

There's more than one way to do it?

[MoxFulder]

Perhaps the Perl motto should be changed from TMTOWTDI to TAMODVPCWDSSAAMSTWDI:

"There's a multitude of different visually pleasing constructions with deceptively subtle syntax and auto-magical semantics that will do it."

Okay, I love Perl 5... Perl 6 looks really cool but overwhelming. I'm glad they're adding the options for stricter type-checking and such, but remembering the syntactic shortcuts is gonna be even harder. I don't even want to know what the parser code looks like...

Re:There's more than one way to do it?

[rmohr02]

Perl 6 looks really cool but overwhelming.... I don't even want to know what the parser code looks like...

Well, you don't want to know what the parser code looks like in Perl 5 either.

Anyway, they're adding a bunch of weird stuff, but I'm fine as long as I can still use normal syntax.

Re:There's more than one way to do it?

[Anonymous Coward]

I agree, but I'm not sure Perl has "normal syntax" :-) Have you ever tried to use ()'s for arithmetic precedence, and then had to track down a bug due to the fact that you induced list context?? That kinda thing...

eval @ in scalar context != size of @? What?

[embobo]

@date_and_time is evaluated in the scalar context imposed by $date, and the resulting array reference is bound to $date.

Huh? This seems wrong. Evaluating an array in a scalar context should return the size of the array, not an array reference.

Re:eval @ in scalar context != size of @? What?

[Fastolfe]

In Perl6, the "context" of a variable actually gets a little more specific. In a vague "scalar" context, yes, an array will resolve to a reference to itself.

However, you can examine either in a numeric context and obtain the number of elements within it. So things will work as you expect, you just have to realize that "scalar" is now a real vague term.

The World Needs Idealised Perl

[Vagary]

In the denotational semantics community it was long ago decided that real programming languages are too messy and too much of moving targets for serious theoretical research. As a result, the most popular language is known as Idealised Algol which is a simplified and cleaned-up version of Algol-60 (I'm told Algol-W is the closest implementation).

Now that Perl 6 has a rich operator definition system*, we can look forward to Idealised Perl (IP). IP would be a version of Perl stripped down to only the necessary syntactic building-blocks. Even if much of Perl 6 were implemented in C, it'd be possible to define all the syntax in terms of IP. If you're writing code for maintainability instead of prototyping, using IP as much as possible will ensure a smaller learning curve for non-gurus. IP will be simple enough to actually allow teaching Perl in universities.

IP could be the elegant yet expressive language we all (whether we like Perl or not) wish Perl would be.

* This is, IMO, the only really neat and elegant thing to come out of Perl 6 so far. If operators can be defined to the point where most mathematical formulae are executable, Perl will become a revolutionary tool.

Re:The World Needs Idealised Perl

[axxackall]

At the beginning there was LISP, the language with the biggest language report. You don't like various Perl assignments? How about various Lisp quotes?

Then they decided to idealize it and created Scheme - the language with the smallest language report. Both languages are good, but both language have lost their popularity to first imperative and then OOP ones.

I think the length of the language report won't help Perl either. People are already re-writing Perl code to Python. Why? Perhaps because they don't like to hack, they rather wanna design their programs. Perl coding style is hacking.

Perl 6 \not\in Perl ?

[Vagary]

Is it just me, or is Perl 6 so different from Perl 5 that they probably should have given it another name? Especially since Perl 5 will continue to be updated after Perl 6 becomes stable?

Perl 6 has so little backwards compatibility, it'd probably be better if they just through out all the legacy syntax and started from scratch with a new language. Not that Perl ever was elegant, but I'm starting to worry that things are getting out of hand...

Re:Perl 6 \not\in Perl ?

[chromatic]

It's not just you, but about 80% of the syntax stays the same. Much of the rest requires a few parser rule overrides. See ... And Now For Something Completely Similar, also by Damian.

Backwards compatibility is a huge concern. That's why Ponie exists and why Dan's so careful about supporting Perl 5 semantics on Parrot. (As well, I expect 80% of the core Perl 5 tests will port to Perl 6 with surprisingly little work.)

Re:Perl 6 \not\in Perl ?

[Ed Avis]

I don't think it is any more different from Perl 5 than Perl 5 is from Perl 4. Huge amounts of extra stuff (most importantly objects and nested data structures) were added from 4 to 5, together with quite a few syntax changes.

However, backwards compatibility will be more of a gap, because perl 5 is pretty much source-compatible with perl 4, but it doesn't seem that 5 -> 6 will be the same. (No, having a separate interpreter specially built to run older scripts doesn't mean source-compatible in this sense - I'm talking about the language itself.)

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

What facts do you base your estimates upon?
Why do you have so much blind faith in Parrot considering it still can't run Perl after 3 years of effort?

Re:Perl 6 \not\in Perl ?

[chromatic]

Would that everyone were so blind!

• I have had code in Parrot for years. I have commit access.
• I've taken hundreds of kilobytes of notes during Perl 6 design meetings.
• I read the Apocalypses, Synopses, and Exegeses as they're being written and revised, weeks and months before they're released.
• I helped quadruple the number of tests in the core test suite between Perl 5.6 and Perl 5.8.

I think I have a pretty good sense of Perl 5, Perl 6, and Parrot.

I also know how many Perl Foundation dollars have been spent to get Parrot where it is today. It might be enough to hire one of the top .NET folks for most of a year. For the money, Parrot's a bargain.

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

You failed to answer why doesn't Parrot run Perl code after 3 years of effort?
As for the money spent on Parrot development - I won't bother with that statement. I see no evidence of Parrot advancing the Perl 6 cause at all. It is just a distraction.
Mono and DotGNU/Portable.Net in the same time frame have concrete results. No external money funded Rhys' work on Portable.Net, as far as I know.

Re:Perl 6 \not\in Perl ?

[chromatic]

Parrot's been around two years, not three. The oldest Perl 6 code I can find running on Parrot goes back one year.

Perl 6 isn't completely implemented on Parrot because Perl 6 isn't completely designed yet. Perl 5 isn't completely implemented on Parrot because no one's had the right combination of time, talent, and funding to implement it yet. The same goes for any combination of Perl and Parrot you care to mention. As of last month or so, there had been somewhere around five man years of Perl 6 and Parrot work funded.

Paying one developer to work on Parrot for a year and a half would double the amount of full-time contributions.

The parallels to Mono and DotGNU are inappropriate. Not only are they reimplementing something that's already been designed and implemented once by legions of funded developers at Microsoft, Ximian pays people to hack on Mono.

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

What's with all this talk of paying people to work on open source? If the Parrot/Perl6 project were compelling enough to work on - a multitude of developers would gladly freely work on it. The original Python, Perl and Ruby languages were written in exactly this way - and all of KDE, GNOME and CPAN, for that matter. So please give that tired "someone should fund Perl6 development to get a timely quality release" argument.

Re:Perl 6 \not\in Perl ?

[Anonymous Coward]

- So please give that tired "someone should fund Perl6 development to get a timely quality release" argument.
+ So please give that tired "someone should fund Perl6 development to get a timely quality release" argument a rest.

Re:Perl 6 \not\in Perl ?

[chromatic]

I'm answering the question why hasn't Parrot made more progress?. I believe the answer to that is, because it's been mostly a volunteer effort. There are lots of people who contribute what time and skills they have, and I think they've done a fantastic job. There are also more people contributing all the time.

As for Perl 5, Python, and Ruby, you should check out how many of the original developers are or were paid to work on those languages full-time. I'm not sure about Matz, but I know Guido has been doing half- or full-time Python development for several years now. Until a couple of years ago, so had Larry.

I'm sorry if you don't like the answer, but finishing software takes time. Sure, volunteers help, but I'm not sure that forty people giving one hour a week is even half as useful as one of the top people giving forty hours a week.

Please don't misunderstand. I'm happy to see people who can give an hour a week. The pay is lousy, a few people on Slashdot will take every chance they can get to gripe about your work, and it's a big project, but you'll be helping build software for millions of people to use. There's lots to do, though, and plenty of room for anyone who'd like to help.

A sharp detour from past Perls

[Junks Jerzey]

I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.

That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,

In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.

Re:A sharp detour from past Perls

[Jerf]

The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,

This thought keeps occurring to me. Actually, without any intent to devolve into a Perl vs. Python flamewar, I've been thinking that a lot with quite a few of these Exegesises. Python certainly doesn't have all of what's supposed to go into Perl 6, but it has a lot of it already there, and a lot of the other stuff isn't necessary because that's just not the way things work in Python.

To be fair, Perl is letting you limit the incoming parameters via code, whereas Python limits them via philosophy ("Better to ask forgiveness")... but for all that verbiage, that's about all Perl 6 can do with parameter passing that Python can't.

(Anyone adding pipelines to code I have to subsequently maintain will be shot without trial. I don't care how nifty the feature is, you're better off writing it longhand under nearly all circumstances for maintainability.)

Some nifty ideas here, though; I'm tempted to see if I can't implement "any" and "all" in terms of Python, at least for in-program comparisions. (Although Python is clean... I wonder how many of the cute tricks would subsequently propogate correctly and work correctly as well...?)

Re:A sharp detour from past Perls

[demi]

...but it has a lot of it already there,

I'm curious what you think is coming in Perl6 that Python already has. The exception mechanism I suppose, and mixed positional, named and optional parameters. Anything else?

and a lot of the other stuff isn't necessary because that's just not the way things work in Python.

The reason people get into flamewars over Python vs. Perl is because of this philosophy: if Python doesn't do (or doesn't do well) what you want it to do, there must be something wrong with you. I use both, and I can't tell you how many times I've pointed out something I didn't like in Python, only to be told by a Pythonista that therefore I must be doing it wrong. Can't find the block end? Your blocks must be too long! Want more than a simple statement in lambda? That's not its purpose! Want declarative syntax? You don't need it!

To be fair, Perl is letting you limit the incoming parameters via code, whereas Python limits them via philosophy ("Better to ask forgiveness")... but for all that verbiage, that's about all Perl 6 can do with parameter passing that Python can't.

Could you clarify? Because I can't grasp what you're saying here. Are you saying that the only thing you can do with parameters in Perl over Python is "everything Python doesn't want you to do"? Or what?

Anyone adding pipelines to code I have to subsequently maintain will be shot without trial.

I actually think Damian's article does a pretty good job of showing the opposite: sometimes, a pipeline would be much easier to read than rabid nesting.

I'm not 100% on board with all the Perl6 stuff either (in particular, I'm not sure I'm down with all the punctuation-based modifiers to the parameter list--there are a lot of them in the Apocalypse that aren't covered in the Exegesis).

Increasingly difficult tasks...

[MoxFulder]

(1) Draw a complete operator precedence chart for C.
(2) Draw a complete operator precedence chart for C++.
(3) Draw a complete operator precedence chart for Perl 5.
(4) Draw a complete operator precedence chart for Perl 6.

Perl's ability to express complicated things concisely is nothing short of astonishing, but it's gotten to the point where I can hardly parse code written by someone else...

Re:Increasingly difficult tasks...

[Ed Avis]

(5) Profit!!!

Seriously, though, the 'someone else' surely ought to take care to express things in the simplest way possible so that other people can read it easily. The choice of whether to use

f() if $cond;

$cond && f();

if ($cond) { f() }

is a matter of style and what part you want to emphasize as important. Just as in English you have a choice of how to arrange a sentence and normally put the more important things last.

Plenty of minimal languages make it just as easy to write unreadable code... I've seen plenty of obfuscated Java. A richer language like Perl lets you write code in the style that is clearest for the task at hand, and that can only be a good thing.

Good god...

[Anonymous Coward]

What a monster of a language!

YHBT, YHL, HAND (n/t)

[Anonymous Coward]

Speaking as a Perl programmer...

[metamatic]

...will someone please hurry up and add Unicode support to Ruby so that I don't have to learn Perl 6?

Re:Speaking as a Perl programmer...

[GnuVince]

You do realize Ruby is open-source? Let that someone be you maybe?

Re:Speaking as a Perl programmer...

[metamatic]

Not knowing Ruby makes me far from ideal as the person to fit it with Unicode.

Re:For those who don't know....

[n1vux]

In addition to the Apocalypses and Exegeses, Damian and Allison have produced two

• Synopses, which are shorter and quicker to market.

The names are a running gag on church-latin, that interconnects Larry's linguisticism, Damian's eclecticism, and the monastic themery of the Perl Monks' alternate retroynm for .PM. Larry's Apocalypses are not apocalyptic in the common figurative sense (although the neo-Luddites who think the only improvement on Perl5 is PHP or Python may think so), but are the Revelations of the gur, which is the original sense of the word, before it came to be used to refer to the particularly apocalyptic content of St.John's Revelations also called Apocalypse in the latin. The churchly Exegeses are non-canonical explanations of the deeper meanings of the canonical texts. And of course, synopses are shorter summaries, like Cliff Notes (TM) or Master-Plots (TM), and were originally applied to religious writings of course.

require sig 1.3;

SENSE OF HUMOR

[Anonymous Coward]

You moderators are all ass-ponies, aren't you?

...and in Ruby

[MenTaLguY]

a = 1
print "a is type #{a.type} and has value #{a}"

(in case you're wondering, you can put arbitrarily complex expressions inside those curly brackets)

Re:...and in Ruby

[Anonymous Coward]

Can you read that string out of a message file (for localization) and still interpolate the values of expressions involving local variables?

Re:...and in Ruby

[MenTaLguY]

That's a good point, actually. I don't think so, currently. I'm not even sure that's desirable, since that'd mean having to put chunks of code in the message file.

In cases involving a message file, you'd probably end up having to use Ruby's sprintf (which is no better than C's).

Thanks for pointing that out; I've been digging myself in here doing that type of string interpolation in some fairly inappropriate places if I wanted to care about i10n later...

Please take the time to read the WHOLE article

[Anonymous Coward]

Before folks die of heart failure, or start using this to praise the superior abilities of their favourite language over perl.

Read and understand the WHOLE article.

My initial reaction to most of the apocalypse/exegesis articles has been "WTF, this is so complicated they're going to destroy perl".

BUT, when you read the articles carefully and think about them, it becomes clear how powerful, and easy to read (yes, really) most perl 6 code will be in comparison with perl 5.

The apocalypse/exegesis articles by their very nature tend to dwell on difficult and complex issues and, true to its history, perl 6 will be taking ideas from many other languages which may be initially alien to perl 5 programmers. So, yes, we'll need some effort to get the hang of the new syntax, but I'm now 99% convinced it will be very similar to work with.

Lets also not forget the work on parrot - having an open source, fast VM should benefit other languages such as Ruby, Tcl and Python - it's been built with that in mind from day 1. If it comes off - yes its slow going, but the signs are still good - I hope this will help to silence the endlessly purile "my language's better than yours" that clutter up these pages (ok, I admit it wouldn't be as much fun!).

Parrot progress

[Anonymous Coward]

Two years of Parrot development and it still cannot run Perl. And as for this talk of Parrot running Python and Ruby - it's just talk.
Here is what a Python guru said about Parrot when he tried to port Python to it:

Parrot development is stalled

The VM hasn't yet been shown to be useful as a language target. The main list for Parrot development, perl6-internals, was started in September 2000. Over two years later, in March 2003, there are still no real languages running on the VM. There are only a few toy languages such as Befunge and Jako, and fragments of Perl, BASIC, and Scheme compilers that are far from being able to run any percentage of the Perl and Scheme programs out there. (They're at about the same level as parrot-gen.py; if you pick a random example from a book or a random program found on a web page, the chance of being able to successfully run it is essentially zero.) To some degree this is because Parrot is closely tied to the development of Perl 6, and Perl 6 development is also proceeding very slowly.
No obvious benefit from using Parrot

What new possibilities does Parrot provide for Python? Stacklessness? Better GC? A new I/O layer? Interoperability with other languages? None of these is more than mildly interesting to me, and none, I suspect, will be viewed as a killer application by the Python community in general.

Most of the claimed benefits, such as better performance, haven't been actually demonstrated at this point. There are no real languages running on Parrot, so you can't compare the standard implementation of language X to the Parrot version of language X. Instead it's simply stated that Parrot will be faster than existing language implementations, but proof-by-assertion isn't very convincing.

Re:Parrot progress

[Anonymous Coward]

That quote is frankly pointless - folks are pi**ed that parrot is taking a long time to develop. By that kind of logic, if it only took 6 months to develop but was useless, would it be better?

Course not. I would be much happier if that "Python guru" had just said something like, "at the moment, its too early to say if Parrot will be useful" instead of bitching (albeit mildly).

Are there many Python, Ruby (favourite language) developers helping with Parrot? If the answer is, as I suspect, not many (any?), then there's no real justification for complaining about the speed of development.

The whole point is that if parrot works as expected, it will be a huge bonus to languages beyond perl 6, and folks should be grateful to the parrot developers for that instead of posting cheap comments writing Parrot off before its even arrived.

Re:Parrot progress

[Anonymous Coward]

You are missing the point entirely. In short: Perl 6 - good. Parrot - bad.
Perl 6 does not need Parrot to be implemented. Perl 6 can be prototyped in the original C-based Perl 5 and when it is done a module can be written to generate code for any number of existing backends and interpreters. Parrot is just a wasted exercise in premature optimization.

Re:Parrot progress

[chromatic]

Perl 6 can be prototyped in the original C-based Perl 5 and when it is done a module can be written to generate code for any number of existing backends and interpreters.

I look forward to seeing your Perl6::Continuations, Perl6::Rules, and Perl6::Types modules on the CPAN.

Re:Parrot progress

[Anonymous Coward]

That quote is frankly pointless

Yes, information countering your argument can be quite irritating.
Anyway, Portable.Net has also made an effort to also use Parrot without success.
Shouldn't Parrot simply concentrate on running some form of Perl?

Are there many Python, Ruby (favourite language) developers helping with Parrot? If the answer is, as I suspect, not many (any?), then there's no real justification for complaining about the speed of development.

Is there any point about bragging about Parrot's theoretical support for Python and Ruby if there are no people working on it?

Re:Parrot progress

[Anonymous Coward]

>Is there any point about bragging about Parrot's
>theoretical support for Python and Ruby if there are no
>people working on it?

Well, I wasn't bragging - my original statment was (excerpt):

"Lets also not forget the work on parrot - having an open source, fast VM should benefit other languages such as Ruby, Tcl and Python - it's been built with that in mind from day 1"

That's a pretty reasonable statement, and accurately reflects the fact that parrot has been designed with other languages in mind as well as perl - the fact that development has been slow does not change that.

I'm as frustrated as anyone about how slow the initial development work was, but perl6 and parrot combined are pretty ambitious, and we're just going to have to wait.

>Shouldn't Parrot simply concentrate on running some form of Perl?

Well what the heck do you think's going on - perl 6 is in development ATM, and I believe ponie is designed to get perl 5 running on parrot - these are works in progress.

So I'll rephrase my previous post - I therefore presume that if parrot is a success (and that's IF, not when), I assume all these folks bad mouthing it will put their money where their mouths are and NOT use it :)

blech - don't make perl syntax look like vb

[galacticdruid]

regarding this syntax:

--

(Num $temp is rw)

--

ick - this type of syntax is why I don't like VB. anyone with me here?

Re:For those who don't know....

[Feztaa]

* Eventually, this will lead to the Design Documents

That's all well and good, but how far into the actual development have they gotten? I mean, it's kind of cool that they're saying "Perl 6 will do this, that, and the other thing", but how much actual work have they done?

All this time, I've sort of thought that Perl 6 development was well under way and that they were nearing completion, but your post makes it sound like Perl 6 is nothing but talk right now.

Flame War....

[Tsali]

I don't know which gets more trolls... Perl or VB6... or VB.Net or C# or Java or Python.

I think it merits a poll.

My vote: Perl.

Most languages have regular expression components now to help with text processing.... so can someone tell me why you would pick up Perl when other languages are prototypical (VB/Python), strongly OOP (Java/C#), or need to be around forever because people have been coding them for decades(COBOL, C, C++)?

Note: Personal preference is Java, Python, and VB.Net in that order. I am now entering the bunker to avoid thermonuclear flaming.

(waits)

perl attack

[Anonymous Coward]

please see http://xahlee.org/UnixResource_dir/perlr.html xah lee

Perl 6 is a pantheon...

[LoveMe2Times]

I see Perl 6 as kind of a pantheon of programming gurus, and you can subscribe to whichever you like (or tell them all to screw off). The most important thing about Perl 6 is you can use whatever programming style suits you best. In a corporate environment, that style can even be dictated down by the powers that be, too. If you're one of those people that thinks that Lisp (et all) is (or is not) understandable, or thinks Java is a brain-dead C++, or that C++ is error prone Java, then Perl 6 may not be for you. You let (percieved) flaws obscure the important benefits, and as a result you miss out. Objectively, you would be examining the trade off between learning curve and increased efficiency over the time period of the project. In many cases, it is in fact better to stick with the tool you know, even if a different tool would be twice as effecient. Since it's just not possible to learn every single tool available, as professionals, we have to pick the most effective set of tools that we care to know given our interests and other expertise. This brings us around to the great thing about Perl 6: in one cohesive, sensible framework, it gives you really broad coverage. You don't have to learn it all at once--you start out using Perl 6 like Perl 5; then when you decide you want to do some lispy type things, you don't have to learn Lisp and a whole new toolchain, you can learn to do lispy types things in Perl. If you want to do things that would be well suited for C++ templates, you can learn the Perl 6 mechanisms for it instead of undertaking C++. And what is really, amazingly cool is that Perl 6 is shaping up to be a cohesive, well considered framework; it's not a jumble of competing ideas that don't play nicely with each other.

If you've worked with C++ templates and metaprogramming, then you certainly understand the benefits being offered by a lot of the Perl 6 constructs. But the Perl 6 way is much more comprehensive, direct, clear, and intentional. Everything with blocks, anonymous subs, closures, multi methods, named parameters, operator overloading, and macors offers unbelievable oportunities for meta-programming. Once Perl 6 gets rolling and starts developing its own equivalent of Boost, then programming will never be the same. Boost changed everything already, but you've probably never heard of it; but Perl 6 will have mainstream appeal, acceptance, and use that Boost will never have.

Use what you need

[Prince Caspian]

There have been quite a few comments about Perl 6 gaining too much syntax, but I can't help but think that you could make the same argument about the English language. There are many words out there that most of us don't need, but for some people, they greatly simplify communicating within their field. I think Perl 6 will actually be easier to learn than Perl 5, because a Learning Perl book would not need to even touch on some of the more advanced areas, and the simple areas have been, well, simplified.