Larry Wall Announces Perl 6 228
The following was written by Chris "Pudge" Nandor... Perl Guru, Slashcode Guru, and all around swell guy.
Perl 6 To Be Complete Rewrite (But Not What You Think)
Larry Wall and other active Perl porters and Perl helpers met on Tuesday afternoon at Perl Conference 4.0 and mapped out a what is planned to become a complete rewrite of Perl that will become Perl 6 in 18 to 24 months, with a prerelease targeted for next year's conference.
Perl 5 will not be abandoned, but will primarily be concerned with bugfixes both major and minor.
The meeting for members of the perl5-porters mailing list was the result of an earlier, smaller meeting of Wall, Nathan Torkington, Chip Salzenberg, and others who basically decided that Perl needed to be fixed in certain ways, and that a rewrite was the best way to do it. Salzenberg started the Topaz project two years ago, to reimplement Perl in C++. Though Topaz itself will not be the basis for Perl 6, Salzenberg noted that the lessons learned in the experience will be very helpful to the new effort.
Torkington led the three-hour meeting, starting off by saying what was wrong with Perl. Much of the focus on the problems with Perl centered around how increasingly difficult it was to improve, extend, and embed Perl. A rewrite and redesign are needed, he said, and maybe it is time for a hard change. So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.
Some of the primary (and still vague) goals of the effort will be to reimplement the core so it is better, stronger, and faster; improve syntax; add new features where appropriate; have better version and installation management for perl and its modules; and have a clear and automated migration path, which may include a backward compatibility mode. Some old features may be removed, like typeglobs. Others will be improved.
The group hopes to re-shape Perl community, too. Instead of one all-encompassing perl5-porters list, tightly focused mailing lists with a terminal lifespan will be formed. To start off, the mailing list bootstrap at perl.org will be for discussion of the beginnings of the project. Like most, if not all, other new lists, when it has fulfilled its purpose, it will be closed.
Wall said, "Perl 5 was my rewrite of perl ... I think this should be the community's rewrite of perl, and the community's rewrite of the community."
Specifics have not yet been ironed out. A group has been formed to begin the work, which will primarily consist of planning the work to be done. No coding is to be done at this stage, only planning and support. Roles were determined for the group, and then they were filled. They now include the perl 5 maintainer (Jarkko Hietaniemi and Nick Ing-Simmons), the language design pumpking (Larry Wall), the internals design pumpking (Dan Sugalski), the documentation manager (Adam Turoff), the system administrator (Ask Bjoern Hansen), the quality assurance bloke (Michael Schwern), the spokesdroid (brian d foy), the customer relations person (Dick Hardt), and the project manager himself, Nathan Torkington. Other porters, such as Chip Salzenberg, volunteered to consult when needed.
Some of the short term goals of this group are to draft a language specification, start an RFC channel, get feedback, and set up mailing lists, a documentation repository, and a web site. Hansen will be setting up the mailing lists. The bootstrap list will be open to the public, while the list for the intial small group of people will be closed for posting by anyone not on the list. All lists will be readable by the public, through the web, and perhaps through email. Turoff is going to be preparing the notes for the morning meeting, and foy will be posting the notes and the mailing list links on the www.perl.org web site.
Hot new feature in Perl 6 (Score:5)
In keeping with the spirit of Perl, heavy use will be made of default variables in this new system. So for example, the commonly used "print" command will be replaced by:
And the almost-as-common "if" will become:
Instead of "foreach" it will be possible to use:
And lastly, any reference to "$_" or "($_)" can be replaced by:
So a typical Perl 6 program segment might look like this.
#!/usr/bin/perl
;
(@_){
{
}
}
Larry has expressed his gratitude to the Python developers for their initial work in this area.
Re:Perl makes regexps easier to understand (Score:2)
I feel...a module coming on. Except that I'm certain that somebody else has already written a chunk of perl code to slashguard (new verb?) an arbitrary chunk of perl code. And then they probably used slashguard.pl to post the contents of slashguard.pl onto slashdot.
So, anybody got that URL handy? :-)
Re:Programming language design (Score:3)
Sounds typically hacker factionist (Score:2)
Just coming off of a large project written in C++, I'm not sure I would do it again. C++ used lightly (variable declarations in for statements), or used with full Object Oriented Design can be a boon, but is just so much rope for you to hang yourself if just look at C++ as a language with lots more features.
This is irrelevant, of course, and I see myself starting a C vs. C++ battle, so I'll shut up. The bottom line is that rewriting an existing, working, and reliable program in another language--for no real reason--doesn't make sense.
Perl makes regexps easier to understand (Score:2)
s#<(?!$okay_tags)([^>]*>)##gi;
The problem isn't so much Perl as the syntax for regular expressions. They are designed to describe patterns of characters in as little space as possible. Perl actually helps things. For example:
# Remove any HTML tag in the submitted code
# that is not in the list of okay HTML tags.
$submitted_code =~ s
# search for
{
< # start of HTML tag
(?!$okay_tags) # do NOT match $okay_tags
[^>]* # any number of characters EXCEPT the HTML close
> # end of HTML tag
}
#
{}
# globally, ignore case, eXtended regexps
gix;
You can write bad code in any language. Perl is just about the only place you can write clear, well-commented regexps.
[Note: There may well be syntax errors in the above, as it took me forever just to get everything formatted right. (If you think Perl's bad, try translating Perl into guarded HTML!) I certainly can't run it all through the interpreter to check my translation. And I know there's at least one logic bug in the code.]
Re:Perl appears to me to be a "dirty" language. (Score:2)
Now if your concerns are aestetic and are bothered by the overuse of symbols I doubt there will be any change in Perl 6 that will convince you.
For example the data type differentiators ($,%,@) are kinda central to the language. And like almost any unfamiliar language dialect, it looks odd at first glance. Symbols are symbols and all languages are built from symbols. Take an uninitiate and give them some C++ code, Perl code, Pascal Code and and maybe some Greek and ask them which is more intuitive and aestetic - to them it would all look like line noise.
You could look at this way Python enforces indention style with mandatory whitespaces. Perl enforces variable nameing style with a built in variable naming convention ( $ -> scalar data, @ -> arrays, % -> hashes).
BTW, your original complaint about Perl's loose typing is also true with Python. For alot of programming chores its a feature not a deficiency.
Re:Perl appears to me to be a "dirty" language. (Score:2)
Fortunately, I'm not, so I don't write the same code over and over again. I write it once, and make use of it for years on end. It's called good program design - maybe you should try it.
Re:Perl appears to me to be a "dirty" language. (Score:2)
That isn't because of the type system being too strong in Java, it is the lack of the concept of a tuple, or of multiple return values and simaltanious assignment.
The language Dis is very strongly typed, but it has a tuple type, and you could do this:
int z, z;
string y
x,y,z = function();
Or you could so long as 'function' was declared to return 'tuple(int,string,int)'.
Yes, that would require a 'rowFetch' for each kind of row, but I'm not sure that is a bad idea.
There are other strongly typed languages with 'vartype' escape hatches, which let you have the advantages of strong types when you want them, and the advantages of weak types when you want them, with the disadvantage that the compiler is more complex, and you might have to maintian code from someone who used weak types everywhere....
P.S. Dis is really a cool language. It has full GC so objects with cycles won't hurt it (like they do Perl, at least Perl5), but reference counts so non-circularly referenced objects have a predictable destruct time allowing you to use the C++ style "resource allocation is object creation" idom which makes exception handling and the like so much less painful. Alef is similar in some ways, and has some other intresting concepts.
Re:why i love perl (Score:3)
sub foo { "bar" }
This is actually how "use constant" works internally: it fakes up a subroutine that (implicitly) returns the requested value.
Since the subroutine is defined at compile time, and the compiler sees that it returns a constant value, the constant value is inlined in place of the subroutine call.
So, constants work and are exactly as fast as you'd expect, even though it may seem odd to people without backgrounds in functional languages that a constant is really a special case of a function, but with a built-in performance hack.
Wasting time on speed (Score:2)
If a "preview release should be available by next summer," significant amounts of production software can't be expected until 2002 at the earliest. By that time, current software will perform 3-5x faster on equivalent hardware.
Given Perl's huge installed base, I have no doubt that there are dozens, hundreds, maybe even a few thousand programmers who could benefit from a faster Perl two years from now. But for the majority of the world, the speed that matters is programmer productivity. I hope the Perl 6 team focuses on that.
Re:sitting in the office (Score:4)
wow... (Score:2)
The problem I have is that Perl interpreters seem to be pretty low on most companies' upgrade lists. My current employer still runs 5.005, on both AIX and Solaris. If I can't convince them to upgrade to 5.6, 6.0 seems right out. "There's a chance of older scripts breaking, right? 5.005 works for us now, right? So why bother?" Bah. It sucks that businesses are run by businesspeople. ;) Oh well, I've seen worse... a web hosting company (which advertises on Slashdot, btw) runs 5.004 on Linux boxen. It somehow seems worse that Linux people not be up-to-date on this stuff.
Question for anyone who knows: which version does /. use?
It sucks that any cool new things I could do with Perl 6 are pointless if I can't use them at sites with older interpreters. I think the next Slashdot poll should be,
---------///----------
Re:Rewriting Unix commands in Perl? (Score:2)
print while <>;
A script language, barely alive... (Score:2)
Now all I want to know is if those funky Lee Majors sound effects are going to happen any time I access a page with a .cgi extension...
You mean Perl Power Tools? (Score:4)
The " Doneness [perl.com]" listing indicates that virtually all of the commands are done, and the last date that something was updated was in June 1999.
It may well be effectively complete. I don't think PPT has taken the world by storm, though...
Re:This might finally cause me to learn Perl (Score:4)
This is a myth. You can right perfectly readable and maintainable perl. I currently prototype web pages in perl using cgi.pm and hand it off to an asp developer who translates it into VBscript asp's and cleans up the user interface. The guy had close to zero perl experience when he started, but was able to read an understand my perl almost immediately.
You can write unreadable perl, and that's a godsend for 1 shot scripts, but you can also write very readable perl. It's a language of acceptable subsets.
--Shoeboy
Re:Perl appears to me to be a "dirty" language. (Score:5)
A PERFECT example of this is the DBI library. In Perl, it's simple. You can even do
($id, $firstname, $lastname) = $sth->fetch_row();
In Java, with the JDBC, you have to do this:
(assuming rs is a ResultSet object)
int id = rs.getInteger(1);
String firstname = rs.getString(2);
String lastname = rs.getString(3);
(forgive the syntax if it isn't 100% correct; you should be able to understand the point though.)
The point? Because of Perl's lack of strong typing, it's a hell of a lot simpler to get what I need done: extract a userid, first and last name from a database.
Lots of other modules are like this as well. The result? A looseky bound language that makes it really simple to put different modules together to get something done. In my years of experience in using C++, this is pretty difficult to do: everyone does the data storage differently, leading to a variety of problems. This is still true in Java, but to a much lesser degree.
This is why Perl will never be burdened with strong typing.
Re:Perl appears to me to be a "dirty" language. (Score:2)
I guess I should really qualify these things. Every other person asks me this. Yes I've used mod_perl, and I've even found better solutions ( such as FastCGI ). This was really the type of general purpose solution I was talking about. The PHP comment had to do with how quickly you get get a dynamic web site up. A Cold Fusion engine referred to a potentially higher throughput engine.
-Michael
Structures and n dimensional arrays (Score:2)
Also, structures would be nice. It's easy to do using hashes, but it's a pain to type. I'd suggest the dot notation, but it would break concatenation. Are there any symbols left for this?
You don't want to upgrade to 5.6.0 (Score:2)
Wait for 5.6.1 (which will be out fairly shortly).
If you must use the new features, then figure out how to get the current development version of Perl and use that.
Otherwise you will get burned.
(Hint to the wise. Saying that *.0 releases are stable is a marketing label. This is definitely the case with 5.6.0.)
Ben
Well... (Score:2)
Re:Perl appears to me to be a "dirty" language. (Score:3)
Also, strong typing can be more efficient. When you say getInteger(), the compiler doesn't have to waste cycles trying to figure out if it's an integer, string, float, etc.
BTW, C++ allows you to emulate weak typing where it's appropriate, using operator overloading. Say I've created a SpecialInt class that contains an int, plus does some other special stuff I need for some reason, I can make it interchangeable with an int, like this:
Re:Perl appears to me to be a "dirty" language. (Score:2)
It's simple: Perl parses and compiles regular expressions at compile time. In C it has to be done at runtime. Now, compiletime == runtime in Perl for the most part ... except if the script persists, as in mod_perl or fast_cgi or any daemon for that matter, as opposed to plain old CGIs and commands.
Change... (Score:3)
Sure... (Score:2)
Perl uses smarter text algorithms than most people (Score:2)
Original on: use.perl.org (Score:3)
why i love perl (Score:3)
1) The lack of constants: The only way to do constants is to create a subroutine that returns whatever value you want to be constant, ie: sub foo{ return "bar";}
Re:This might finally cause me to learn Perl (Score:4)
s#<(?!$okay_tags)([^>]*>)##gi;
Think it's unreadable? What about this sentence:
"Cette phrase en francais est difficile a traduire en anglais." (From Douglas Hofstader's "Metamagical Themas")
The point is, it's impossible to read anything until you know the language. I know that the above perl reads "zap all html tags not in the list of ok tags. " (Of course, I have the benefit of knowing what the context for the line was).
So, yeah - perl is ugly unless you know it.... just like any other language. Also, I think C++ uses all the punctiation that perl does, just not as often
-Dave Turner.
Re:Perl appears to me to be a "dirty" language. (Score:2)
I am going to assume that you've dealt with the perl core code, so I'm not going to debate with you. But to defend myself to others, let me say this: Scalars are a dynamic type which encompases integers ( in optimized cases ), floating point, strings and references ( which are the basis of most perl complex datatypes, including objects ). When in doubt, perl makes something a string. To my knowledge, DBI reads come in as strings ( I could do a test, but frankly I don't care enough ). Flags in the scalar object specify if it is currently in int/float/string/pointer form, and it's possible to flip flop around in most directions ( even from a pointer ). Because of this, you can always treat the scalar as a string. Hense my comment.
I think your biggest reaction had to deal with the defamation of perl sophistication, perhaps likening it onto something like COBOL, which uses pseudo-ASCII numbers ( 4 bit digits, if I recall ).
-Michael
Re:Rewriting Unix commands in Perl? (Score:2)
print while <>;
How about one better?
print <>;
Re:Lack of grammer (Score:2)
Wrong, Perl excels at text manipulation and the web is mainly...text. Try doing text manipulation in C or Java and see how much more quickly it can be done in Perl.
C does'nt really have to suck at string manipulation, it just happens to, thanks (or no thanks at all) to the crappy, insecure, C library.
It's a shame nobody cared to spec out a standard text handling library in C? Or it has been done but I'm not aware of it. I know of DJB's effort ... as used in Qmail ... it's funky though, and not exactly standard by any means.
C++ is k3wl in that respect, but I used to get a bit alarmed at the the ASM code I was getting ... oh wait that was a long time ago. 68k assembler. Duh. Nobody does that anymore. Oh forget it.
Re:Perl appears to me to be a "dirty" language. (Score:2)
-- Abigail
Re:Recipe for disaster... (Score:3)
If you put export PERL5OPT='-Mstrict' in your profile, then it will already happen.
-- Abigail
Re:M$ supports ActiveState (Perl for Win32) (Score:3)
-- Abigail
Besides... (Score:2)
-thomas
Re:Come on; Read Me, Please... (Score:2)
--
Straight From Larry Wall's Mouth (Score:3)
Re:Perl appears to me to be a "dirty" language. (Score:2)
Hmm... I like it. When the language has built in support for complex datatypes it's useful. Take T-SQL for example:
DECLARE @bob varchar(255)
SELECT @bob = max(bob) FROM tbl_bob
It's unfathomably useful to be able to tell at a glance whether you're dealing with a variable or an attribute of a tuple.
Perl is the same way. I find it nice to be able to tell at a glance whether I'm using a scalar or a list.
--Shoeboy
Re:Hot new feature in Perl 6 (Score:2)
Hmmmm... funny, that looks just like Perl 5.
:)
---------///----------
Re:Perl appears to me to be a "dirty" language. (Score:2)
> about a kajillion different ways to do the same
> thing
Otherwise known as "There's More Than One Way To Do It", one of the central mantras of Perl
The way I see Perl is that if you have a messy mind, you'll create crappy perl. If you've got a focussed mind, you'll create focussed perl. You impose the discipline on perl, it doesn't impose the discipline on you. It's the most direct and natural way I've ever seen for transferring thoughts to real code. (Painting By Numbers doesn't count).
> language-based improvements
I don't see what improvements there could be.
When I learnt to program in BASIC, I felt there were things missing, although I only had a vague idea of what they were. I moved on to C and found lots of the gaps filled, but still that nagging feeling something was missing.
I found perl, and I've *never* thought "Hrm, I wish Perl did " or "Why does it do it like that? It'd be much better like ?" about Perl...
Re:why i love perl (Score:2)
And neither does C for that matter, but you never hear someone complain about that. Pascal does have constants though.
Of course, you might argue that C has
well, that isn't C, that's the C preproccessor. And you can use the same C preproccessor with Perl; just use the -P option.-- Abigail
Re:Perl appears to me to be a "dirty" language. (Score:2)
--
Re:Perl appears to me to be a "dirty" language. (Score:2)
Don't complicate the language with functionality that belongs in the class/object browser.
Class/object browser? My copy of vi doesn't have this thing.
--Shoeboy
Re:Larry Wall background (Score:2)
Rewrite allready done... (Score:2)
Re:Besides... (Score:2)
Perl background (Score:5)
Enjoy!
Re:This might finally cause me to learn Perl (Score:2)
Recipe for disaster... (Score:2)
String ssn = rs.getFloat(4);
String firstname = rs.getString(2);
String lastname = rs.getString(3);
float cash = rs.getString(1);
I will get an error or thrown Exception for trying to convert a float to a string without a cast while in Perl this error will be allowed to silently propagate through the system causing wasted time later glancing at line-noise-like syntax trying to track down a bug that is due to the typelessness of the language.
PS: Automatic initialization of variables thus causing typos to be treated as variables is another pet peeve of mine. Besides that Perl is really good at quick-and-dirty text manipulation which is what it excels in.
Re:Perl appears to me to be a "dirty" language. (Score:2)
The way I've expressed this thought is:
"Perl is APL on LSD"
Re:Well... (Score:3)
Re:why i love perl (Score:2)
print foo; # or foo() under strict 'subs'
--
Re:why i love perl (Score:3)
use constant FOO => 1;
I believe the following also works. Check out "Advanced perl Programming" from the only Publisher out there for more info.
*PI = \3.1415927;
I've had probs with the last though.
IS
Re:This might finally cause me to learn Perl (Score:2)
Re:Perl appears to me to be a "dirty" language. (Score:2)
Re:Change... (Score:2)
call it something else...please
Wasn't it just a few months ago that Larry Wall was saying he was going to leave Perl alone for a while? I welcomed that, this is a bit more ominous. Great to develop a 'new thing inspired by perl' but if it's not perl, don't call it perl...
WWJD -- What Would Jimi Do?
Re:TO MODERATORS (Score:2)
--Enoch Root, the Human Karma Torch
Re:This might finally cause me to learn Perl (Score:2)
s{
< (?# Match the beginning of the tag)
(?!$okay_tags) (?# Match all non-ok tags)
?> (?# But only until the first >)
}{}gxi;
Re:Compatibility. (Score:2)
For example.. The new regular expression package can only be used by typing
use re;
Most likely there will be a requirement to say
use 6.0;
To make sure of the new engine. The older engine will probably be linked out for use in compatibility scripts. For example. the use of '&' in a reg ex makes the entire perl engine react differently; Likewise, finding a module that makes use of the new syntax would affect which interpreter / library is loaded in memory.
I hope that they find a clean way of doing this. A rewrite really should not feel like bolted on code.
Re:Perl appears to me to be a "dirty" language. (Score:2)
# Class A; Class B inherits Class A
my A $obj1 = new B;
my B $obj2 = $obj1;
I liked it because of the supposed optimization of the pseudo hashes, but I found myself typing 3 times as much to do incredibly simple tasks. Personally I like building OO libraries ( makes my work easier down the road ), but the "bolted on" perl OO model takes a lot more work when an attempt is made to be clean and concise, which you need to do every now and again.
That said, I definately agree with you about how powerful perl is when it comes to data manipulation such as in databases. I can throw together a complete CGI/DBI web site in minutes, for prototyping, then go back later and structure all the function calls when there's time.
-Michael
Re:A script language, barely alive... (Score:2)
---
Just like libc (Score:2)
Re:Perl appears to me to be a "dirty" language. (Score:2)
My point was, I just don't find Perl to be particularly aesthetic, and was wondering if anything is going to be done to fix that in the rewrite...
Larry Wall background (Score:2)
Grand prize in most well-rounded in confusion (1986/wall.c)
Most Useful Obfuscation (1987/wall.c)
From ioccc.org [ioccc.org]
And you people WONDER why it's hard to read PERL code?
And yes, I have written readable PERL code. I have also written a regex script to parse my VB code and alter function parameters as a global find and replace... If you can't read regex, you won't be able to read well written PERL code that uses it. I find that most people who accuse PERL of being dirty and hard to read simply can't read regex.
Re:Perl appears to me to be a "dirty" language. (Score:2)
This is a good point, well received.
M$ supports ActiveState (Perl for Win32) (Score:3)
As another aside, I'd say this is a Good Thing (tm) for those of us that have to admin PC's running Linux, Solaris, Win2K, WinNT, and Win98, Sun boxen, and Mac's all in the same campus. That's the advantage of Perl. And thanks to M$ for finally supporting something that someone else wrote without trying to take it over. They should get credit where credit is due.
Re:sitting in the office (Score:3)
Depends on what you mean here. I use PHP scripts to present information drawn from my mysql database as webpages definitely. But I also use it to publish static html pages, create text files, ftp files from one server to another, verify data values in my database etc - all tasks that could have been done in Perl (and perhaps more effectively) but which I have done using PHP simply because I am more familiar with it than I am with Perl. In this sense, it is a competitor with Perl, in the sense that most sysadmins will not be writing their maintenance scripts in PHP, no it is probably not in competition with Perl.
Overall I find PHP scripts are easier to decipher when you return to them 6 months later to make a change, I think it has a simpler syntax and some very logical improvements over some aspects of Perl, and for these reasons I prefer it. Mind you there are some older scripts written in Perl that I still occasionally have to tweak, but most of these have been replaced by PHP scripts whenever the need arose.
Re:Perl appears to me to be a "dirty" language. (Score:2)
Still, Slashdot did post a "benchmark comparison" study a couple months ago, which found that text parsing "as written by experienced, competent programmers" in C didn't hold up against Perl's text parsing.
I agree that it's a little weird to benchmark something against its parent. Maybe what they meant is "PERL handles text better than YOU."
Compatibility. (Score:3)
The impression I get from the article is "mostly compatible":
So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.
You'll probably be ok, but no promises, assuming they don't change their minds during the next year or so (remember, they're just _entering_ the planning stage now).
Perl appears to me to be a "dirty" language. (Score:2)
It always comes off to me as being a sort of a 'dirty' language in that there are about a kajillion different ways to do the same thing - and I've never much cared for the way variables are declared and used in Perl (scalars?). Too much use of symbols, not enough grammar.
The limited Perl I have written has filled me with nothing short of a maniacal desire to become a darned good Python programmer.
I understand that Perl ties a lot of the web together, and it definitely has its uses, but my initial reaction to the news that Perl was getting a rewrite was "about time, coz it's a gnarly language"
What language-based improvements will this rewrite address, any of you Perlverts know?
Larry Wall DOES NOT Announce Perl 6 (Score:4)
Re:Perl appears to me to be a "dirty" language. (Score:2)
My point is that perl had a nich back in it's day, and that way string parsing. It's libraries were optimized to do so. Many of the types of optimizations ( such as self modifying code, in the case of variable substitutions for reg-ex's or even the eval '' statement ) are hard to do in a low level language. Not that it isn't possible, but just that to do so would take an enormous amount development effort, which doesn't fit into the web-model.
Perl isn't really the best web-model for most situations either. A heavily loaded web site would be better used by a massive C-engine with customizable pages. Or a PHP/ASP setup might get pages out the door faster ( especially with new developers ). But Perl is a very good general purpose tool for text processing ( as well as other fields ).
Re:Choose two (Score:2)
Re:Rewriting Unix commands in Perl? (Score:2)
If you need perl on a rescue disk, you can replace the commands with perl scripts (since perl is there anyway) and save some space.
And yes, I know I'm reaching.
Re:Recipe for disaster... (Score:2)
Another point of view is that because strings are so versitle in perl. It wouldn't matter if you read it in as a string, float or int, since it could easily internally type-cast to the appropriate type when used. The worst that would happen is that you'd convert a string to a zero, which should signal a warning somewhere.
As for initialization.. YOU MAKE BAD PERL JUJU, since you obviously don't use -w. If you did, then you'd know that it's impossible to use a variable without first initializing it. Perl allows you to make the command line -e '...' without any type checking, but allows you to be anal man with -w and "use strict". Trust me, when I started using -w, I'd get really pissy because I loved the default case of undef becomming an empty string. Now I have to
$str ||= "";
everything that I know is printable even when null.
-May you do good things with Perl
Re:Perl appears to me to be a "dirty" language. (Score:3)
And since the web's content is so heavily text-based (because plain text is a universal standard, HTML is text-based, and because most pages' content is text), it's easy to see why PERL dominates.
Different tools for different jobs. If you want to write a first-person shooter or operating system, use C. If you want to write a script that converts newlines in text files between \r\n and \n, PERL would probably be the best choice. If you want to write an ASCII game, I'd go with QuickBasic 5.
In conclusion, PERL rules, and if this upgrade is good, that's cool, and if it isn't, no one is going to force us to upgrade our interpreters.
Re:Change... (Score:2)
Re:sitting in the office (Score:2)
you could more accurately say that CGI has been losing its reputation as the best (or normal) way to do dynamic webpages, and *that* is a great thing in itself, since CGI (one fork/exec per page, yay!) sucks rocks. Perl has very good support for the CGI model, wiht the CGI.pm module, and mod_perl for Apache has two very good CGI emulations (Registry and PerlRun, with different tradeoffs in how much faster they are, and how much cleaner they require your code to be). However, emulating CGI is *NOT* the only, or the best way to use build dynamic pages with Perl.
The web-dev world has already pretty much come to the conclusion that URLs must be mapped to their content, not to a directory of scripts. As usual with Perl, There Is More Than Way To Do It; you have modules to embed stright Perl code into html pages (Embperl), modules that implement a higher-level componentized model (HTML::Mason, Apache::ASP, the Templating Toolkit, and others), and buzzword-compliant modules that go the XML/XSL way (AxKit).
As for perl6, I don't think it'll have a very direct impact in the way people do web development with perl. Perl 6 is going to be a complete rewrite and cleanup of the language, possibly with changes as fundamental and far-reaching as those between perl 4 and perl5. It will reorganize the whole perl world, not just the "perl on the web" part of it.
Re:Community's perl? (Score:2)
Re:Recipe for disaster... (Score:2)
Always, always, always, use strict; and run with -w, at least for anything more than 20-100 lines long. What'd be really great is if 'use strict;' were the norm, and 'no strict;' were the exception, in Perl6... but then probably only 20% of older code would fly, and -e would be horrid.
---
Programming language design (Score:3)
It seems that the past has shown that language by committee ends up over-burdoning the language. Are they're any previous examples of language design by committee that worked? It seems that all of the successes programming languages have made have been because of one or two evil geniuses who were able to see a project to completion, design to code.
I wonder if it's just revisionist history, but weren't c, c++, python, perl, and tcl all works of very small teams (excluding the standardization committees).
This should prove to be a great example for university programming language courses.
-js
Upgrade path (Score:2)
Re:Perl appears to me to be a "dirty" language. (Score:2)
For the FORTH case, the 'faster' result would come where you had a program that consisted almost entirely of lots of calls to short subroutines That's what FORTH (as a threaded language) is all about. In standard assembler it would normally be implemented as:
In forth, as a threaded language, it would be implemented as a list:( &sub1, &sub2, &sub3
In 'standard' assembly, each subroutine would return to the main routine which would then call the next subN. In forth, each subroutine would simply Jump to the next subroutine in the list:
JMP [REG:Call_list++]
On the 6809, this would be implemented by pointing the secondary stack pointer at the threaded list, and doing a
RET SP2 (secondary stack)
This effectively saves the one instruction per subroutine call (!!!!). Not much of a savings, but if you're calling lots of short subroutines, it can add up.
Similarly, perl does lots of string manipulation-type work in ways that are fundamentally different than the way that 'standard' C does them. Just like the 6809 example, there's nothing to stop you from doing things the PERL way, it would simply take
- a rethinking of the way you do things,
- being willing to risk confusing any maintainer who looked at your code.
- a willingness to abandon all/much of the standard code base built up over time
- a willingnes/ability to train everybody who came after you.
As somebody else said -- by the time you do all that, you'd be programming perl in C. In that case, why bother to do it in C at all?Re:Perl appears to me to be a "dirty" language. (Score:2)
But that's the whole point of PERL..
Re:Compatibility. (Score:2)
Re:wow... (Score:2)
Re:Perl appears to me to be a "dirty" language. (Score:2)
Re:First Ilya, now Tom? (Score:2)
Re:Recipe for disaster... (Score:2)
but that would be both inefficient and probably wrong. I say "probably" because unless you have an $rs[0] element your variables are all going to be off by one position -- a mistake you could just as easily make in C. This should become evident as soon as you start seeing people with no (actually, undefined) cash with social security numbers of "Fred" and names like "Flintstone 225.62". And it's inefficient because it'd be much easier to say
No subscripts to worry about there, and I may have been staring at Perl code too long, but to me it doesn't look like line noise.
If you're relying on typing as a first check of the validity of your data, admittedly that's something that Perl doesn't do. However it would probably take about ten minutes of looking at the regular expression of Programming Perl to see that, for instance, you could check the validity of a Social Security number with
assuming that the database application you're getting the SSN from isn't already doing it for you.
--
Re:This might finally cause me to learn Perl (Score:3)
s|<(?!$okay_tags).*?>||gi;
should do the same thing, and is more readable. You can make any language obfuscated, especially when the language is flexible.
I mean, honestly, can you think of a faster way to "zap all html tags not in the list of ok tags"? It may be a little hard to read when you are done, but if you put a comment next to it saying what it does, it's not hard to understand.
Re:Perl appears to me to be a "dirty" language. (Score:2)
The argument isn't for a better DB interface but how to handle arbitrary data-types. A good reasoning for this is that I might not care how the database was designed. Was it a 32bit int or 64bit ( possibly 32/64 bit date stamp, etc ). Changing the database means changing the Java / C code. In Perl, I don't think I've ever had to change a line of code because I've redefined types for table columns.
This allows me to quickly get a proto-type database up ( possibly with all text fields ), then later optimize the row lengths. More importantly, if the DBA needs to lengthen a VARCHAR, he can do so without risk of affecting the perl code. The only issue that should ever come up is the formatting of the resultant HTML.
Arguably, you could create a Java DB interface that returned everything as a pointer to type "Object", then use to_string for display purposes. I think that we'd all agree, however, that this would be undermining Java and bad programming practice.
Re:Well... (Score:2)
--
A mind is a terrible thing to taste.
Re:wow... (Score:2)
Yeah - he's lazy enough to have the public do most of the work as far as figuring out what to keep, get rid of, modify, etc. He's letting us do the harder work of figuring out what to change, while in his laziness, he and other developers will actually only do the implementation. Seems like a perfect lazy-man's plan to me
--
TheDude
Smokedot [baked.net]
Drug Info, Rights, Laws, and Discussion
Re:Perl dirty? Use Unicon! (Score:2)
Something to digest this evening.
Don't be fooled! It is a trick! (Score:3)
Perl is fine without compiler type-checking (Score:2)
String ssn = rs.getFloat(4);
float cash = rs.getString(1);
These are the errors? You're still thinking in Java if you can't see that the perl equivalent would simply be
($ssn, $cash) = @results;
which presents no float / string conversion problems.
in Perl this error will be allowed to silently propagate through the system causing wasted time later glancing at line-noise-like syntax trying to track down a bug that is due to the typelessness of the language.
The only way this bug (confusing the order of results returned by the SELECT) will creep up to get you is if you don't unit test your methods...
Re:Larry Wall DOES Announce Perl 6 (Score:2)
Re:Compatibility. (Score:2)
open my $fh, $path or die $!;
Formats, well, formats might go away entirely from the core and move to a more manageable, easy-to-use, sensical module.
This might finally cause me to learn Perl (Score:4)
I'm really hoping Perl 6 will give us some more readable syntax. Hey, I like my C++ short and terse too, but I don't care for entire subroutines mostly written in punctuation.
Yeah, I know that syntax is a lame reason to like or not like a language, but I'm the one who has to stare at it. It's the little things that make the difference.