The purpose of this essay is to explain why I believe Perl 6, the way it currently seems to progress, is the wrong thing at the wrong time, and why I predict (with all the expected caveats of predicting something) that it won’t be successful. I will also suggest a better alternative for the future of Perl which makes more sense at this point.
I mostly agree with the author but one thing he misses is that
Perl 6 is actually a very good language if you start fresh, its more homogeen and readable and maintainable than previous Perls and should be easier and faster to learn.
I never did like Perl but it good to see that they are trying to setup a new and solid base.
1. The author doesn’t understand the contents of the Apocolypse documents, and concludes that this makes Perl 6 too complex because others will understand them even less. A lot of people do not tend to even understand Perl 5 very thoroughly, but that doesn’t seem to impede its progress.
2. Ponie (which the author mentions) is already posed to implement Perl 5 for Parrot permitting interoperability between Perl 6 and Perl 5.
3. The author insists that because Perl 5 is “good enough” that Perl 6 is unnecessary, but could nevertheless be an adequate evolution of Perl in a period of ten years. The author doesn’t indicate why Perl 5 makes Perl 6 superfluous, nor why in ten years it would be more suitable. In ten years, there will be much more crufty code written in this regrettable language, and departures that broke backward-compatability would cause even more whining.
4. The author implies that the learning the changes made in the construction of Perl 6 will be a large detriment. Depending on how thoroughly one intends to learn the language, the changes could be sufficiently unintrusive as to seem trivial to a prospective learner. Just the same, programmers tend to learn several programming languages, and if legacy Perl 5 code can be deployed along with Perl 6 the transition will be simple for any reasonably-intelligent developer. VB.NET departed significantly from the traditional Visual BASIC, and people have managed with becoming proficient with both to solve problems.
5. The author argues from authority with Joel quotes. Joel is an opinionated loudmouth, not the god of software engineering. One could just as easily pick some words from Larry Wall to support the existence of Perl 6, and Larry Wall is undeniably more successful than Joel. It would still be retarded to do so, but one can see where this road goes.
6. I wasn’t certain if the author really meant Perl’s man pages or perldoc. Either way, there is certainly no shortage of documentation for Perl available.
Overall I was largely unconvinced by the article and thought it was a somewhat arrogant and a bit whiny. No one really cares about the name some random person gives to a theoretical fork of Perl 5. Don’t like Perl 6? Well that’s ok, it’s not even ready for use yet. It turns you that perl5 interpreter on your computer still works just fine, and all of the people not uninterested in Perl 6 can continue to use it and its revisions for the forseeable future. Want Perl 5 with all of the whizbang features of Parrot? Contribute to Ponie.
I don’t think Perl 6 will be as successful as Perl 5, because, frankly, Perl is a nasty language that peaked during the dot bomb and has been declining in popularity. Perl 6 is complex, as was Perl 5, and it is different enough from Perl 5 that I can imagine many Perl 5 users resenting the differences enough to not learn it just to spite its existence. However there will undoubtedly be many users of Perl 6, and whatever new users that turn to Perl when Perl 6 is extant will probably prefer Perl 6 to Perl 5, and find it to be just what they need and just when they need it.
the wrong thing at the wrong time
does that make it the right thing?
I won’t say whether or not this guy’s arguments have merit (although I’m leaning in the “no” direction), but I will say that I think he’s very wrong about Perl 6 not being accepted.
With enough time, everyone (that uses Perl 5) will switch … its that timeframe that is the gray area. Eventually Perl5 will just stop being worked on / updated, and Perl6 will be given the golden seal of compatibility with Perl 5, and CPAN will have the whole Perl5/Perl6 thing worked out.
Believe me, many people out there will be writing in Perl 6. As someone that loves Perl 5, I’ll be one of them. 🙂
the ahuthor suffers of an ugly case of BLUB syndrome (cfr: blub paradox, paul graham).
He does not understand perl6 so he can only think it sux.
You can try to imaginate him standing at a hyde park corner, shouting “I said this problem is a nail! we have to use our hammer!”
Also, he does not understand that if you have old perl5 code, and wnt to extend.. well, you can just user the same code on parrot and extend it in perl6 or perl5.
But, the author thinks that everybody is stupid and they will suddenly make perl5 disappear. Then he thinks “let’s break some code at any time, instead of all togheter!”
More, he thinks perl6 is complex.
Perl6 is the simplest perl out there, cause *everything* is just a simple method call or a macro.
Also, citing Joel is really useless. Say, dave thomas prefers ruby over perl6. And tim peters prefers python over perl6. Oh my god, now what is going to happen? big names colliding!
Language design is somewhat of a guilty pleasure of mine, although I’m not very good at it. I had a few “Waaaah?” moments while reading the article.
What is “The Perl Family of Languages”; and why oh why is Ruby there? I’m not familiar with Ruby’s history, but I know that it looks and feels much more like Python than Perl.
But here’s what I see from the article. User of Perl(5) sees deficiencies in Perl(5), but doesn’t think they are defeating. User does not come to terms with the fact that Perl(6) redesign is in an attempt to achieve some of these features and not hurt Perl(5) programmers.
Why do you think that Python became so popular? Why do you think Ruby is gaining popularity? Anonymous poster of comment #2 was dead on in his assessment; Perl is a nasty hack of a language. Its niche is in system scripting where using bash would be a hassle or more speed is desired (other popular languages are not nearly as good as perl for scripting a-la shell scripting).
But in order for a language to survive, it has to do many things well. The new language on the block has to prove that it is *very* desireable before it reaches any kind of an install base; and once it achieves that ubiquity, resting simply on that will only keep it around for so long. The improvements in Perl(6) are a testament to the fact that Wall has already waited quite a while.
The lack of threading kept it out of the past 3 years gui programming phase; although you could probably argue that its unwieldy syntax also helped. However, since Python provied something that Perl(5) did not (threads), it has gained a certain ammount of ubiquity for that area.
This all relates a lot to what was talked about in the essay; especially when dealing with ubiquity (so many modules already written for Perl(5), or the iceberg principle). How long do you want to keep Perl(5) on life-support? How long before someone takes some other similar (in power) and nearly ubiquitous language (like Python is becomming, or maybe someday soon Ruby) and re-do their scripts so they can kill Perl(5)? How long can you stall, scrapping projects together, as other things with better features take over your install base?
Not liking Perl6 is one thing, but not seeing it for what it is (the only logical step that keeps perl from fading or falling out of favor 10 years down the line) because you like the syntax of 5 better is just silly.
..and jpoel is not saying “dont’ use perl6” anyway
I wonder if in an ironic twist, Parrot could be the deathnail for Perl. And what I mean by that is if Parrot becomes a good runtime for dynamic typed languages and the reason for the popularity of Perl is because of CPAN, and you can have automagic bindings between languages, then why use Perl when you can use Ruby or Python if they have 99% of the regex power of Perl and a much cleaner syntax.
Longhorn will have the CLR at its core, and most Linux systems will follow suit with some type of managed runtime system eventually. Does this change the dynamics of the situation?
I was trying to get at this point in my comment; but you were able to get to it much more concisely and clearly. However, I wasn’t even considering requiring to bind CPAN modules; as a language develops it grows its own libraries. Python and Ruby both have pretty developed libraries of their own; the step from perl5 to perl6 is a *necessity* to make sure that perl is used *at all* anymore, after what you forsee with parrot innevitably happens (or one scripting language is chosen to ‘rule them all’).
I guess is that of “it is more important to write than to read” and of TIMTWOTDI. On the other side you have the bondage& discipline Ada family.
Probably ruby and python are near to the middle in the continuum.
I read pieces like this, and I’m left to wonder if this isn’t an attempt to grab mind-share, like a <insert TV personality here> having a sex tape show up on the internet.
As a recent delver into Open Source, I chose Python over Perl due to a gentler learning curve, and the fact that Perl6 would be re-inventing many wheels (presumably rounder).
While the ‘Second System’ charge is well considered, for Perl6 to be relevant, it needs bold ideas like Parrot behind it. While it may not be complete next week, I daresay that it is gonna be worth the wait.
The article seems to read as “don’t use Perl 6, because I can’t understand it and hence it won’t be widely used because Joel says so”.
Right.
Incrementally changing Perl5 into Perl 6 seems silly as it would yeild not one language, not two language, but a shitload of languages.
Perl 5
Perl 5 with “->” replaced by “.”
…
Perl 5 = Perl 6
Better to have a clean cut and let shops migrate to perl 6 when they feel like it. If the author can’t understand Larry Walls ramblings, fine. That doesn’t make “What is for certain is that Perl 6 isn’t better” true.
I though the whole point of the Parrot virtual machine was multiple languages and interoperation (initially between Perl and Python). I don’t think anyone ever said that perl 5 was going away either.
C didn’t go away when C++ came along. Even Perl 4 didn’t go away when Perl 5 came along. Python, Ruby etc haven’t destroyed Perl, and it seems unlikely that C# or any of its numerous spawn will make any of these languages disappear in a hurry. Finally, I believe that there are still people using COBOL.
From what I’ve read of the Apocalypes and Exigeses (however they’re spelt) Perl6 is attempting to make a powerful, productive and easy to use language for the current era. My major worry is that it will never be finished, not that it won’t be a major improvement over Perl5 (Which is already a pretty awsome language for getting stuff done).
What I always have loved about Perl(5) is that it allows me to translate algorithms into code transparently. For example, iterating a loop is as easy as thinking “let’s see, for each value in the list – (do something)”. Translated into code:
foreach $value (@list) { … }
Now, I think that the following construct
for @xxx; @yyy; @zzz -> $x; $y; $z { … }
hardly can be translated from natural language. What is that? “For each of the following lists xxx, yyy and zzz put into the values of x,y and z …” – that’s doesn’t sound like a natural way of thinking to me! Something like
for $x, $y, $z (@xxx, @yyy, @zzz) { … }
had been much better – it conforms better with the established semantics of
for <scalar> <list>
I don’t like the direction Perl is heading into, that’s all I can say..
I’m looking forward to Perl 6, and also IR compability between Python and Parrot. I’d much rather see development in this direction than Java/.Net/Mono. Yet, I also see the possiblity that Mono and Perl 6 and Python can find some level of compatibility. At any rate, Perl 6 is a major achievement, perhaps one of the greatest for open source, but we’ll see for sure how it all turns out some time next year.
Perl is one of those languages you can write, but you can’t read. Am I the only one who finds reading Perl code arcane? It took me a few minutes to figure out what the code in the article was expounding. That’s right, I’m not a Perl guru.
What is “The Perl Family of Languages”; and why oh why is Ruby there? I’m not familiar with Ruby’s history, but I know that it looks and feels much more like Python than Perl.
Most certainly not. Ruby is in more ways akin to Perl and less to Python. There are several operators, many command line options, and the majority of special variables that are borrowed from Perl. Matz idolized Larry Wall and he is (was) a heavy Perl user too. Ruby is also more about making programming fun, which is like Perl and less like Python. (Python is more about simplicity, orthogonality, and easy to learn and all that).
About the look: yes Ruby looks cleaner (like Python) mostly due to the absence of semicolons and local variables not having to be prefixed. But that’s about it. There is certainly no required whitespace indentation in Python.
In fact, for every aspect Ruby is similar to Python, I can name you two or three aspects in which Ruby is similar to Perl.
All of the above are reasons which make many Perl programmers (such as myself) are more attracted and feel more at home to Ruby than to Python.
>> the wrong thing at the wrong time
> does that make it the right thing?
no. didn’t your parents ever teach you that “two wrongs don’t make a right”.
Perl is one of those languages you can write, but you can’t read. Am I the only one who finds reading Perl code arcane? It took me a few minutes to figure out what the code in the article was expounding. That’s right, I’m not a Perl guru.
No, you’re not the only one. But many people don’t have serious difficulty reading Perl code either.
Perl is certainly not a _write-only_ language. Sadly this meme just won’t die.
Woah, Python more about simplicity than ruby?
I don’t think so. One major reason why I orininally dumped python and went to ruby several years ago was because of the inconsistent API when dealing with simple types vs objects. I found python to be almost as annoying as perl because of the quirks.
Ruby isn’t anywhere near perl, except that it borrowed the most useful text and file syntax from perl and still kept the language OO.
Under the hood ruby and perl are vastly different languages. Ruby is closer to smalltalk than it is to perl
Just that it was too different from the current Perl to be effective as the next step in the future of Perl.
I think a big point of his (right or wrong) was that there will be a strong reluctance to change based on Perl5’s current popularity, the existing knowledgebase and the huge amounts of code already written. A more legacy compatible upgrade would prove to be more successful.
I do not code in Perl so cannot comment whether or not this is an accurate view of the community and/or the proposed changes. From a business perspective it would seem to make sense to be able to support legacy stuff so you could leverage your existing IT while enhancing your capabilities for future work.
Just my “2 Cents” of course…
E.
brain,
One major reason why I orininally dumped python and went to ruby several years ago was because of the inconsistent API when dealing with simple types vs objects.
I hate to nitpick, but I didn’t understand that statement. It is my understanding that everything in Python is an object, at least superficially. I agree that the standard Python library needs an overhaul, but I don’t quite understand the ‘inconsistent API/simple types/objects’ reason in your statement. Could you expantiate?
That *entirely* depends on person who wrote the code…
You can make any perl code w/o any bunch of mixed spaghetti. On the other hand, you can also write perl code with whole load of mysterious esoteric shortcut codes, which can cause raw terror to any perl newbies and intermediates.
Also, with ANY LANGUAGE, you can make whole dish of spaghetti out of program. I think our honorable Mr. Larry Wall once said something like “You can make a program looks almost same as assembly language with any language!!!”
I’ve been working with Perl5 since May 2000. In fact, I started with Perl 5, and never had to make the transition from Perl 4, nor learn much about it. I spent much time lingering in nntp:comp.lang.perl.misc watching other people’s questions and learning from the answers (and their mistakes) and viewing the aftermath of the changeover from Perl4 -> Perl5 but, importantly to my point, never had to make that transition myself in learning Perl 5. Thus, I had virtually nothing to unlearn.
(The more interesting transition for me, was from ‘common programming’ (c-style for loops, if-then-else, etc) to ‘idiomatic perl’, which lets you do the same or similar things in simpler and more flexible ways. A creative programmer can do some seriously cool things once this transition has been made, away from the traditional styles of getting there.)
There will almost certainly be people like myself, coming in late to the whole argument, and who think to themselves, “Well, this is where Perl is heading, so rather than load myself up with a ton of crufty practices, I’ll start fresh here, and learn how to program with Perl6, and use the emulation layers (or simply perl5, which can be simultaneously installed) for any legacy scripts I need to communicate with.
It is unbelievable to me, the sheer levels of pure awfulness, that is the style of coding of Perl4 and cgi-lib.pl. And yet I still see these in use all the time in purportedly modernized things in common use today (such as Webmin, which I refused to install on my system once I saw the code in it’s Perl4-styled “after two cups of coffee and a bran muffin and stuck in rush hour traffic sort of terror-inducing” cruft.)
I too have had a hard time understanding some of the Apocalypses, but for the most part the Exegesis that followed did a good job of exemplifying the cool and interesting things you can do with the new styling. Yes, I’d probably have a bit to unlearn, but not so much as those who have made the transition from Perl4 to Perl 5 (or still haven’t, more to the point =:P ). Nor do I think that this inevitable growth and change in Perl is a bad thing. In fact, I can’t wait for it.
I don’t think all the recent rapid upgrades of Perl 5 (what are we at now, 5.8.5? wasn’t 5.6.0 released not that long ago?) are a bad thing either, and may (in case no one has noticed) already be doing some things towards that coming transition.
I certainly don’t want to wait another 10 years for a serious upgrade to Perl. Not if it means we’ll be still dealing with Perl 4 and Perl 5 cruft from legacy apps for twice that long. It’s bad enough that we have that problem NOW. Cut the ties, man, I can’t wait to move forward.
Oh yes, and lest I forget…
Yes it’s possible to write unreadable code in any language.
I spent much of my ‘learning Perl5’ process learning how to write readable code for maintainability. I wish this were focused on more, and that there weren’t so many sources of god-awful code out there for people to learn from (Matt’s Script Archive being one of them. Thank god there’s NMS [ http://nms-cgi.sourceforge.net/ ] replacements for things like FormMail.pl which is near pure in its horrifyingly bad practices.)
If you’re having a hard time reading badly written Perl, I would say to you that I wasn’t surprised, and that if that is code you are currently actively using, it is long past time you refactored it or replaced it. Do you have any problem reading Perl code that I’ve written (and released publicly on my website?)
For someone who claims to be a “programmer”, I found it extremely funny that he does not know the difference between a programming language and a scripting language. This whole article is by a news reporter and NOT a programmer, as obvious by reading every paragraph he wrote.
What’s the difference between a “scripting” language and a “programming” language?
The Perl6 effort is already three years old. They are getting code to alpha stages. The RFC period has come and gone a LONG time ago.
With all due respect, I believe the author is missing some important points:
1- Perl6 is a completely different language from Perl1-5. Larry even contemplated naming it something different. So the backward compatibility argument is void.
2- Perl5 was not abandoned. Its development is still going strong, and will continue as long as there is need for it. Larry said that.
3- The apocalypses and exegeses are aimed at demonstrating the *differences* in Perl6. Both Larry and Damian mentioned that. They are a bit long, and somewhat hard to understand, especially with so much information crammed into them, but they are NOT meant as introductions to the language. Other books will surely fill this gap.
4- Parrot.
5- Parrot.
6- Did I mention Parrot?
Shannara:
For someone who claims to be a “programmer”, I found it extremely funny that he does not know the difference between a programming language and a scripting language
Mystilleef:
What’s the difference between a “scripting” language and a “programming” language?
Indeed, I have to say I find Shannara’s comments ‘extremely funny’..
Anonymous:
1. Perl 5 is not understood very thoroughly but it is understood enough. On the other hand, in Perl 6 many things would be different, and I don’t understand things throughout the entire language, some of which are very basic. I and most other Perl 5 programmers out there are already used to Perl 5. Perl 6 will break a lot of the old habits, and introduce many new incompatibities. People understand enough of Perl 5 to do their work and can gradually learn more. But I don’t understand enough of Perl 6 even to translate my simplest Perl 5 scripts to it.
2. While Perl 5 and Perl 6 would be able to run over Parrot, it is not clear whether interoperability will be straightforward. Perl 5, Perl 6 (as well as Python, Ruby, PHP, Scheme, etc) have different semantics and it is not clear whether Parrot can bridge them in a simple manner. A programmer I talked to said, he spends most of his time in API writing for high-level languages in making sure that the API corresponds to the language’s conventions, rather than making the bindings themselves.
3. I did not say Perl 6 would be an adequate evolution of Perl 5. In 10 years, Fifer (the language derived from Perl 5) may be more similar to Perl 6. However, it will probably be very different from what Perl 6 is today, as well. Nevertheless, the gradual evolution will give people time to adapt their code instead of having to do so in one big swoop. We can add more features without breaking compatibility, or at least without breaking it all at once.
5. I didn’t give Joel Spolsky as an authority. I gave one quote to indicate that if you don’t understand a specification no-one else will. This is something I personally agree with. Afterwards, I referenced the reader to his article about the growing complexity of software engineering, which I also happen to agree with.
None of these articles were written with Perl 6 in particular in mind. But they do support this. If you think they are wrong, please say so, but don’t attack the source. A given source is irrelevant for the assessment of a claim.
6. By the Perl documentation, I meant all the documentation that can be downloaded for Perl. The perl* (perlsyn, perlop, etc.) documents, etc. There is a lot of such documentation available, but a lot of it is not very accessible to beginning programmers, who just want a good reference documentation. And I explained why.
“Perl is a nasty language that peaked during the dot bomb and has been declining in popularity.”
Perl is not declining in Popularity. While some languages are becoming more popular as well, Perl still has a large body of programmers, that is loyal and growing. And I completely disagree that it’s “nasty”.
How, exactly, can C be considered limited?
> How, exactly, can C be considered limited?
It can’t do everything asm can; note that some parts of, for example, kernels, are written in asm.
Beyond that, the core language is small, which is a good thing, but you either need to write a lot of code or use a lot of libraries to match capabilities that are shipped with many environments. The usual C string libraries are pretty poor, while good string handling is something that Perl excels in. Etc.
C isn’t garbage collected, generally speaking.
The first can be overcome by inlining asm with C, or just linking to it. The last 3 aren’t exactly limits of C, but they may be practical considerations; you can work around each of them, but it does take extra work.
C also is very easy to write insecure code in; it’s arguable whether that’s a limitation of the language.
I use and like Perl 5.8.
I’ve read with some interest about the development of Perl 6. There’s no way I can object to the work being done. After all it’s free and doesn’t have to be used. Reminds me of the complaints about the current Gnome.
But I have considered that I will find the language so different to what I’m using now that I might not move to it when it’s available. A language is only defined by it’s syntax. How much can that be changed before it is something else altogether. Maybe a new name for this language would be appropriate.
I have been really looking forward to Perl 6. I will readily admit that I don’t understand everything going on in the Apocalypses and even some of the Exegeses (a lot of it seems to presume a familiarity with “inside talk” in the Perl developer community.). Of course, I’m sure if I spent more time, and kept another couple Firefox tabs open to Google and Google Groups, I could probably figure it out eventually. But, what I do already understand of it really looks great.
Meanwhile, I really *don’t* understand some of the author’s complaints. Yes, Perl 6 will allow for some very complex esoteric stuff, but from what I read it will also allow the simple stuff to be even simpler. So I don’t think the problem is complexity. I agree there will have to be discussion in many development shops about whether, where and when to use Perl 6, but even then, there is no closed door. Perl 6 programs will easily be able to incorporate libraries from Perl 5, (and as I understand, even vice-versa, via Parrot and Ponie). Other than those complaints, it seems like Perl 6 addresses many, many valid complaints about Perl.
I think its fairly well understood that version 6 is not supposed to be part of the progression of Perl 4, 5, etc… but a new language. In the article I see “Here’s a better idea: Let’s continue to develop Perl 5…”. Umm… that’s not a “better” idea; that’s in fact what they are doing. Larry Wall himself said several times that he doesn’t expect Perl 5 to go away for many years. So where’s the problem? They can keep incrementing points all they want from 5.8.x onward, making the increments smaller and smaller, because that in fact represents the reality of how much Perl 5 would change to stay recognizable. If The Perl project falls into the (author-recommended) trap of relentlessly incrementing Perl 5 until it becomes what Perl 6 intends, over the period of 10 years, that means 10 years of headaches, small paradign shifts, and minor incompatibilities along the way. No thanks.
The whole point of this exercise was to make a clean break of things, and inject some new life into the world of programming, while still not closing the door on the existing world of Perl 5. I personally admire the guts it took to do this, and I think the programming world in general will be the better off for this. Perl has always been driven by a certain amount of fun and playfulness, and I think Perl 6 is perfectly in keeping with that spirit. I have actually put off studying Perl 5 because I am looking forward to Perl 6. Since I never was much of a Perl 5 hacker anyway, I figure moving to Perl 6 won’t be too much of a headache. So, while the diehard Perl users can stick with 5.x all they want, Perl 6 stands to win a lot of new converts from people who like the newer scripting languages, and from people genuinely interested in advanced programming concepts.
I have used Perl 5 occasionally, but in the end there were just so many… oddities. I still think Perl is a fun language, but I tended to lean more towards simpler (PHP) or more sophisticated (Python). But Perl 6 looks to me like many of the oddities are cleaned up: it will allow one to choose all the simplicity of a PHP-like approach or the sophistication of a Python/Ruby/functional of language.
“It can’t do everything asm can; note that some parts of, for example, kernels, are written in asm”
But this is often because of technical limitations involving hardware. For exampe on an x86 BIOS, your first stage bootstrap code has to fit entirely in the first 256 bytes of the hard disk, because that is where the BIOS expects to find it. The only way to write a first stage bootstrap is in ASM.
Personally, I think Perl may be on its way out. It is being somewhat superceeded by Python. If you look at survey results, there is a fairly large migration of Perl developers to Python. The bad news for Perl is that there is zero migration in the other direction. So Python is gaining mindshare at Perl’s expense.
Combine this with the fact that Perl 6 seems to lack direction. It’s as if the developers simply can’t decide where to go with it. The early stages of Perl 6 development were being considered all they way back in 2000. Today, we still don’t even have alpha versions of Perl 6. There have been several failed attempts at starting to develop Perl 6, which have all been scrapped and the developers have started over.
Yes, because of some decisions made in the original design of Perl, the language has reached a limit in what it can support, and this practically necessitates a complete redesign that abandons backward portability. But even with this, it seems that Perl 6 simply lacks much direction. No one seems to want to know where to take it. Hence all the failed attempts and starting Perl 6 which have been abandoned.
It’s ok for you to feel ashamed of making such an idiotic comment that even the slashdweebs would laugh at.
What’s even funnier is that Richard Dale is more of a programmer than your sorry ass ever will be.
http://dot.kde.org/983311036/ – this is from back in 2001 and I’m sure he’s done a lot more since then and before that.
Maybe its time for you take up salmon fishing up there in Alaska and leave programming to people who actually know what they’re talking about.
Funny, while I enjoyed your flames and racist remarks, next time leave the conversation to adults who know what they are talking about.
For someone who claims to be a “mechanic”, I found it extremely funny that he does not know the difference between a car and a Chevy. This whole article is by a news reporter and NOT a mechanic, as obvious by reading every paragraph he wrote.
————–
Also, about the readability of Perl compared to other languages, ever heard of the obfuscated C contest? Remember, C’s one of the few languages that actually still has a “goto” statement. The only reason that most Python code is actually readable is because the language spanks you with a ruler if you don’t indent properly.
If you want to see some readable and maintainable Perl code, download the following piece of code:
http://keep.sourceforge.net/
(Yes, I wrote it myself. Yes, you can achieve the same thing with arcane bash and zsh syntax.)
Shannara: As someone who studies CS at a university and programs for a hobby, I still have no idea what you mean .. How about explaning it?
“Shannara: As someone who studies CS at a university and programs for a hobby, I still have no idea what you mean .. How about explaning it?”
He doesn’t know what he means. He’s one of those people who has little or no programming experience and gets hung up on the false idea that a scripting language is not a real programming language.
This may have been true 10 years ago. But today, “scripting languages” such as Python, offer all of the features of a full programming language. And in some ways, they are even more powerful. Because of their dynamic binding and loose typing, they can implement data structures with a few lines of code that require a great deal of work to implement in C and such.
“Scripting language” is really just a hold out because no one has come up with a better name, although “dynamic language” as opposed to “static language” has been suggested.
So basically, Shannara is just one of those people who tried to make himself look intelligent, and ultimately in so doing, only proved he doesn’t have a clue what he is talking about.
Well said Simba!
Yeah, I’m very racist against Alaskans.
ROFL
Do you take the short bus to programming school?
Richard:
Indeed, I have to say I find Shannara’s comments ‘extremely funny’..
Shannara:
Funny, while I enjoyed your flames and racist remarks, next time leave the conversation to adults who know what they are talking about.
Get a grip.
I only used the term ‘extremely funny’ because you used it to describe the author of the piece on perl 6. Who as far as I can see knows exactly what he is talking about. He is a perfectly good programmer, who can write, and he includes interesting snippets of code comparing perl 5 with perl 6.
For instance, you assert that perl isn’t a programming language, which left myself and Mystilleef a bit baffled. Perhaps you might care to explain why you think there is a difference between a ‘scripting language’ and a ‘programming language’, rather than ranting away like this.
— Richard
I quite thoroughly disagree with your assertion that Perl6 is the wrong way for the Perl community to be heading, but, if you’re going to make that argument, you need to be able to demonstrate that you’ve done your research.
You complain about the lack of the . operator being available for string concatenation, and the fact that _ has been designated for that purpose. This was debated quite a bit in the mailing list, and the conclusion was that the ~ operator, which already has some connection to strings in the minds of Perl programmers (via =~), would be used instead. The _ operator was particulary onerous because _ is a valid character in an identifier. Does “foo_bar” mean the variable “foo_bar” or is it really “foo _ bar”? That ambiguity, and the fact that it would necessitate mandatory spacing killed it.
Secondly, you provide a comparison of a bit of Perl6 code with Perl5 code. Yet you’re Perl6 code is better Perl6 code than your Perl5 code is Perl5 code. If you want to make a point about Perl5 being better than Perl6, you should write good Perl5 code, or people are less likely to take you seriously.
In the Perl5 code you never declare $is_ok using “my”. Instead you simply assign to it. If you “use strict”, as you should, your program won’t run.
It should be noted that it was a rhetorical question. I was not asking. I was telling.
C has no inherit limitations other than those imposed by hardware. If you can’t do it in C, it probably isn’t possible. The only reason you would need inline assembly is to directly issue an instruction to the cpu. Such as when one needs to disable the bus for an atomic read-write to a semaphore.
You are also confusing a programming language with a programming platform. C is a language and typically you target system specific API’s when writing in C; hence the term systems programming.
C doesn’t do anything from you, and it doesn’t hide anything from you. That’s a strength not a weakness.
Lumbergh:
Yeah, I’m very racist against Alaskans.
ROFL
Do you take the short bus to programming school?
If I wanted to listen to children, I would hang out at the elementry school, or on SlashDot. Maybe you should have your posting abilities taken away until you have grown up into an adult? [/i]
Richard:
My apologies for putting my reply to the child above, under a quite from you
That was not meant to happen, and I apologize. My reply was to the child in my previous paragraph.
Anyways, the difference between a programming language and a scripting language is fairly simple. One actually compiles to machine code while the other one leaves the code wide open for anybody to see. A prime example would be comparing the two microsoft suites. Visual Studio 6 and Visual Studio 7. While one is a programming suite, the other is a scripting suite (minus VC++ 7 unmanaged option).
We’re also not talking about 3rd party compilers (real compilers, not fake translaters), but of the language’s native interpreter. Thus Perl is well known for being a scripting language as the author intended, so is Python, PHP, vbscript, etc. While programming languages, VC++ 7 (unmanaged) and below, ASM, Delphi, etc are not as slow nor easy to steal (the code) as the scripting side.
Then there are those languages that sit somewhere inbetween. (The VB6 and below series for example), has a huge runtime required in order to run such programs. They are not fully compiled and are not pure scripts either. So basically, the worse of both worlds
I hope this answers your question.
In the future, I’ll double-check to make sure I am not replying to the wrong person
Today there are lots and lots of programming languages that have active developers already knowing the language. Unless
perl6 doesn’t offer some new paradigm on how to create software, it have very little chance of success. There are already to many ways to do “if”, “then”, “else” and “repeat” to motivate developers spending time learning to do it in yet another way.
Well, I’ll give you credit for having the balls to put your foot in your mouth again while you’re way behind.
Anyways, the difference between a programming language and a scripting language is fairly simple. One actually compiles to machine code while the other one leaves the code wide open for anybody to see.
So by your definition unless there is machine code on disk it’s a scripting language and not a programming language…..uhhhmmm, NOT.
A prime example would be comparing the two microsoft suites. Visual Studio 6 and Visual Studio 7. While one is a programming suite, the other is a scripting suite (minus VC++ 7 unmanaged option).
HAHA, ROFL.
We’re also not talking about 3rd party compilers (real compilers, not fake translaters), but of the language’s native interpreter.
Ahh, ok. So these “scripting” languages “fake” translate.
So, let’s sum up your post. Languages like Java and C# are “scripting” languages and not real programming languages because they emit bytecode and unless the “native” compiler dumps machine code to disk its a scripting language.
You are probably the only person in the world that holds that definition.
Anyways, the difference between a programming language and a scripting language is fairly simple. One actually compiles to machine code while the other one leaves the code wide open for anybody to see. A prime example would be comparing the two microsoft suites. Visual Studio 6 and Visual Studio 7. While one is a programming suite, the other is a scripting suite (minus VC++ 7 unmanaged option).
It seems to me this has more to do with not showing the code to the end user, and it allows you to write closed source software. Maybe the fact your always have to release perl as source is a closed source vs. open source issue. What if you could release perl source code encrypted, and only the users who had bought it off you could decrypt it – would that make perl a proper programming language? I think you can compile python already, and so it must qualify as a ‘programming language’ under those terms.
Then what if you can compile a ‘scripting language’ to machine code on the fly via a jit, and you never need to generate CLR bytecodes. Does that make a scripting language more of a ‘proper language’ than C#? It is easier to decompile CLR byte codes than it is strong encryption + machine code..
— Richard
Woah, Python more about simplicity than ruby?
I don’t think so. One major reason why I orininally dumped python and went to ruby several years ago was because of the inconsistent API when dealing with simple types vs objects. I found python to be almost as annoying as perl because of the quirks.
The dichotomy between type and class in Python was a limitation of the implementation, not part of the language specification, and it is being (already?) fixed. Python also had other quirks like not being able to transparently convert between int and bigint, this is also an implementation issue and is already fixed.
I still hold that Python is more about simplicity than Ruby. You can expect someone to be sufficiently adept in Python in less time than in Ruby. In particular, Ruby’s OO is more complex/advanced/has more options (though overall the model is still elegant). There’s module nesting, aliases, hooks, ObjectSpace, object freezing, extending individual objects, protected/private/public as in C++ (Python doesn’t have protected IIRC), etc.
Ruby isn’t anywhere near perl, except that it borrowed the most useful text and file syntax from perl and still kept the language OO.
I’m not saying that Ruby is _most_ similar to Perl, just that it’s much more similar to Perl than to Python. Syntaxes are part of the language too (Matz says “Syntax matters.”).
Under the hood ruby and perl are vastly different languages. Ruby is closer to smalltalk than it is to perl.
Many people like to say this, but Matz himself says he copied the most from Lisp, not Smalltalk.
“Anyways, the difference between a programming language and a scripting language is fairly simple. One actually compiles to machine code while the other one leaves the code wide open for anybody to see. A prime example would be comparing the two microsoft suites. Visual Studio 6 and Visual Studio 7. While one is a programming suite, the other is a scripting suite (minus VC++ 7 unmanaged option). ”
This is rediculous, according to this definition Java, which uses a virtual machine, is a scripting language, while many scripting languages such as Unix’s Bourne Shell are not because they are interpreted rather than byte-compiled like .Net.
May I suggest an article by the author of the scripting language Tcl, a former professor of Computer Science at UC Berkeley and Distinguished Engineer at Sun Microsystems, Dr. John Ousterhout, on the subject of what a scripting language is?
http://www.tcl.tk/doc/scripting.html
Totally Offtopic, but I came across your blog. Good stuff. I liked the discussion on parrot/mono and dynamic languages. The Psychology of Computer Programming is an interesting book that I read many years ago.
No.
Scripting is a subcategory of programming, but you can’t extend that relationship to say “scripting languages” are a subset of “programming languages”.
It’s all about the use of a language.
For insance, we commonly consider bash a scripting language because it is most frequently used to control (or “script”) the actions of other applications. If we were to write a shell script, the majority of the logic should be taking place transparently in those other applications.
This of course is where we get the perception that anything that allows a relatively small amount to get a lot of things done comes from.
If we want to unzip a file in the course of accomplishing a larger computing task, we don’t write a huge C program to do all of that work. Instead we write a tiny shell script which lets something like gunzip do all of the heavy lifting.
Of course, then we get into the realm of languages that simply have huge libraries and the difference between “scripting” and “programming” becomes more ambiguous.
Are we writing a “program”, or just scripting the underlying libraries? After all, we’re writing ever more concise programs which hand off ever more of the heavy logic to some library.
Not sure how much this matters wrt Perl6, but Perl5 has the best written (in dead-tree form) docs I’ve ever seen for a software project:
Learning Perl, Schwartz & Phoenix
Programming Perl, Wall, Christiansen, & Orwant
Perl Cookbook, Christiansen & Torkington
With books of that calibre available, it’s no wonder Perl5 is so popular.
matz actually said “some people say ruby is a bad ripoff of lispo and smalltalk, and I admit it”.
It actually rips off much more from ST than it does from lis.
BTW I don’t think python offers much more simplicity, it is more complex under the hood.
You have strange constructs such as for/else anbd while/else, some things are duplicated (just think of: map(f,lst);map(lambda..,lst);list(f(x) for x in lst); [f(x) for x in lst]) and some thing are somewhat hard to grasp for noobs (thinking of metaclasses, descriptors, __slots__, _setattribute vs setattr in new style vs old style classes).
And module nesting, reflection, and extending individual objects is there even in python, luckily
When python3000 comes some of this things will disappear, making python *again* the simpler language out there. Till then I don’t think it really is, better to look out for Io or JavaScript.
Totally Offtopic, but I came across your blog. Good stuff. I liked the discussion on parrot/mono and dynamic languages. The Psychology of Computer Programming is an interesting book that I read many years ago.
Thanks, but umm, I not sure which of my blog’s you mean.. My most recent blog is entitled http://www.kdedevelopers.org/node/view/676 ‘Bollocks R Us’ it links to an excellent article by Alistair Cockburn. Two of my big heroes in observing professional computer programmers are Gerald Weinberg and Tom DeMarco, and I think Alistair has made an excellent contribution in that tradition.
Anyway, as a non-academic full-on Hacker I love the idea of being quoted as Richard Dale’s ‘Bollocks R Us’ blog..
— Richard
“There’s module nesting, aliases, hooks, ObjectSpace, object “freezing, extending individual objects, protected/private/public as in C++ (Python doesn’t have protected IIRC), etc.”
Well, some would argue that “Protected” violates encapsulation. Of course, the flip side of this is that without Protected, folks usually result to making things Public rather then do the additional programming required for them to work as Private.
I don’t know that much about Ruby, but does it support the functional programming aspects that you can do in Python? For example, does it have lambdas and generators?
The parrot talks Perl 5 and Perl 6. Its even rumored that we will be able to use Perl 5 objects, modules and functions from within Perl 6 and the other way around. But the interesting stuff is how one might be able to use methods from C++, python or java code from within a Perl 5 or 6 script. As well as parrots cross-platform assembly style language.
I look forward to exploring all of this technology. I’d also like to learn ocaml, python, C, objective C, C++, C#, python and maybe java if its still around when I finally get the time to look at it.
Perl 6 adds a lot of features that I will find useful if I need that much organization and complexity in my code. But Perl 5 has everything I want right now. I’m just writing objects and simple methods to handle most of my stuff. I don’t need complex methods that process data differently depending on how its called or what datatypes are passed to it and I don’t need complex datatypes atm. In the future I’d love to have the power Perl 6 has to offer for when I might need it and I love the idea that I can make use of all this Perl 5 code I’ve been writing without rewriting it. What more could I ask for? Well, compiled binaries, but I’ll deal with that later. Perl 6 is one step closer to native binaries, IMO.
But I guess that is why I feel the need to learn C and stuff.
I will mention though that Python OOP does have several problems. Compared to Java, OOP in Python is pretty unsafe from a security standpoint.
In Java, a Private variable is enforced in such a way that it is pretty much impossible for someone to violate the encapsulation and access it from outside the class. Python, however, uses a simple name mangling method to prevent access to a private variable, and that name mangling is extremely predictable. So it is simple in Python to violate the encapsulation and pull something out of a private variable that you are not supposed to see. So unlike Java Private variables, Private variables in Python offer absolutely no security against attacks from intentionally malicious code.
almost always in java you can still access private stuff:
http://www.samspublishing.com/articles/article.asp?p=174217&seqNum=…
Not that the ugly mangling trick in python is in my liking, but it is good enough to prevent users to shoot them in the foot.
“almost always in java you can still access private stuff:”
With a standalone app, sure you can do this. But there are few guarantees when dealing with stand alone apps since I can just as easily write a trojan horse in Java that will read any file the user running it has access to, or delete every file in the user’s My Documents directory, or something else malicious.
But where the most potential for dangerous content comes from, is dynamically loadable applications such as applets or Web Start applications. and with applets and Web Start, the security manager will not allow reflection by default.
Python’s name mangling does prevent you from shooting yourself in the foot. But it doesn’t prevent someone else from shooting you in the foot. There are various ways in Python to perform tasks similar in Python to what is done with Java. But in Python, there is no safe way to have a module from an untrusted source interact with your own modules.
In Java, however, if you are having an unstrusted class interact with your own classes, you will usually be using a security manager that will not allow thinugs such as reflection and such.
Private variables are intended for information hiding which is to keep you from creating bugs not to be used as a security feature.
There isn’t any public and private in python classes; what you mention are just naming conventions to give programmers a heads up that: “Hey, the writer of this class does *NOT* want you touching this.”
But its pretty explicit that nothing is ever going to be “private” or even “protected”, as in java/c++.
But they CAN be used a security feature in Java, as long as reflection is not allowed.
Actually, it’s more than just a naming convention. Using the private naming convention in Python will cause the name to be mangled so that you cannot call it or access it outside the class (unless you specically use the mangled name.)
However, nothing in C++ is really private either. There is nothing to stop me from forging a pointer into a private data member of a class and then accessing it directly.
Mystilleef
Perl is one of those languages you can write, but you can’t read.
Really? Perhaps you are reading code by people who can’t
write Perl properly.
C:
void hello ( int count ) {
int i;
for ( i = 1; i <= count; ++i ) {
printf( “[%d] Hello, world!
“, $i );
}
}
Perl:
sub hello {
my $count = shift;
for my $i ( 1 .. $count ) {
print “[$i] Hello, world!
“;
}
}
Alternative Perl:
sub hello {
print “[$_] Hello, world!
” for 1 .. shift;
}
Trivial code, I admit, but also equally readable. In fact I think Perl has the edge in this simple example.
As someone who writes Perl and maintains Perl programs written by other people, I find readability an important, even critical, feature of a program, and I make sure that all my programs are neatly laid out and easily understandable.
Sure, it’s easy to write code in Perl that’s difficult to understand (search for JAPHs and see what I mean!), but it’s also easy to write clear, concise programs.
Just MHO.
Ha! It’s ironic that my post under the subject “readability matters” isn’t very readable. The preview showed those s as spaces …
Nice one OSNews!
I don’t understand what is so great about Parrot. ( btw, I’m not a seasoned Perl programmer. )
I’ve recently overlooked the code to get some “inspiration” for the VM of a language I’m currently creating ( or maybe switching the VM to Parrot )
I’ve seen :
– Parrot was initally a register based VM with 32 integer registers, 32 float, and many others.
– They have implemented some JIT system to transform the VM code into native code on many targets.
– They have built an assembler, which is now deprecated.
– They have created several [ mostly toy ] language frontends.
– One of the toy language has been transformed into a “intermediate level” language that shall be generated by the real language frontend instead of generating directly Parrot assembly. That IL compiler does registers allocation.
– Many signifiant changes have been made to the VM, like switching to continuation style calls ( I’m not sure ).
IMHO :
– The Parrot VM is squeezed between the IL code and the JIT compiler. For example, no real hardware has 32 integer registers available simultaneously for user code ( and most common HW has only 8 integer registers, you seen what I mean ? ). The IL compiler maps locals to 32 registers whereas the JIT needs to reduce the effective number of registers to map into hardware.
– They have chosen a register based architecture that is supposed to be more efficient than stack computers. I’m not sure it’s always true for VMs. I think that register allocation would be simpler for the JIT compiler with an arbitrary length stack VM.
– For me, a VM shall be kept virtual. If your VM looks too much like an ordinary microprocessor, you miss most of the outstanding benefits of a VM ( for example, my language’ VM has only 20 opcodes, and half of them have no direct HW equivalent ). With so many statically typed VM registers you can’t play easily with advanced concepts like continuations, coroutines…
– Basically, when you design a VM, the way the Machine works is an unimportant detail. For example, memory allocation is more complex. The virtual machine is an interpreter and not a processor, and, in that aspect, I think that the Java VM is not abstract enough. A “higher level” VM may be slower in interpretative mode but you can make it more versatile and, in the end, as you will need a JIT compiler, you need something more abstract than a simple processor for better optimisations, you can even add to the code some optimisation hinting like : {that parameter won’t be used afterwards} {that local doesn’t need initialisation} {you can inline that function} {doesn’t call subs} {it’s tail recursive} …
For resource limited targets the VM shall be very simple. For more powerful computers, you have plenty of time and memory to do JIT compilation.
Parrot seems to be a bad solution to a nonexistant problem.
Now, who can tell me where am I wrong ?
( No flames, please )
BTW, Perl 7 exists already, it’s called Ruby ! <grin>