Critique of Where Perl 6 is Heading
 by Shlomi Fish, in Editorials - Sat, Oct 16th 2004 00:00 UTC

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.

Overview of the Current Design of Perl 6

The design of Perl 6 is progressively laid out in the Perl 6 Apocalypses which are written by Larry Wall (the original creator and designer of Perl versions 1 through 5), and exemplified in the Exegeses by Damian Conway and others. There's a more progressive design which has been shared among the members of the perl6-language Mailing List, but hasn't been formulated into a specification yet, and/or has not finally been decided upon by Larry.

It is evident from the Apocalypses and Exegeses that Perl 6 will break compatibility with Perl 5 in many ways (usually deliberately). Furthermore, it incorporates a lot of features and paradigms from different languages that are not common in most languages in common use today.

Why Perl 5 is Good

Perl 5 has seen incredible popularity. There are now millions of lines of code written in Perl by thousands of programmers. (Possibly even milliards of lines of code, written by hundreds of thousands of programmers.) The so-called Perl 5 Man Pages are (or at least used to be) intended for experienced Unix system administrators and programmers who are already familiar with either Perl 4 or with the Unix toolset of shells, awk, and sed. The Web Revolution wanted something else. Many programmers who were new to Unix (or even to programming in general) learned Perl because it was the most suitable tool for the job, often using it in situations in which writing a shell script would have been better. Thousands of CGI scripts have already been written in Perl, and new ones are constantly being written. Perl has also seen wide deployment in other areas -- bio-informatics, for example, and programming UIs. MandrakeSoft has written the Mandrake Linux installer in Perl, and also many of the distribution system tools. And Mandrake is a very popular distribution.

CPAN has provided programmers with a great number of modules that can be easily installed and used to solve most tasks much more easily. CPAN's convenience and coverage is the envy of all other languages, and even accounts for some people using Perl despite liking a different language better.

One thing that has to be remembered is that Perl exhibits the Iceberg Effect: for every piece of code that is distributed (either on CPAN or otherwise), there's much more code that is kept in-house or in private. Many CPAN modules have many equivalent ad-hoc routines doing similar things written in Perl that are actively in use in many software shops and were never released to the public, nor are going to be released. (I know I wrote such things when I began programming in Perl)

Perl 5 is a modern, powerful language which can be used to write code that either incorporates many different paradigms or even emulates many other languages. As Larry Wall once noted: "You can write Perl programs that resemble sed, or awk, or C, or Lisp, or Python." (Or BASIC/Visual Basic for Applications, Pascal, a great deal of Haskell code, PHP, etc.) Most people can write a lot of Perl 5 code and won't encounter a place where they think that it is inadequate. Thus, Perl 5 is good enough not only for today, but also for the future ahead. ANSI C is a much more limited language than Perl 5, and still, many people are actively using it and writing new code in it. They also often like doing so. If ANSI C is good enough, there's no reason to assume Perl 5 isn't.

Why Perl 6 is Bad?

No one Understands Perl 6

Having read this title, you are probably thinking to yourself: "So you don't understand Perl 6. What makes you think everyone else doesn't? How do you justify this inductive thinking?" Let me tell you a little story:

One day, I met with a good friend of mine (whom I highly appreciate both as a person and as a software engineer), and I asked him if he reads the Apocalypses. He said he does, but that he doesn't understand them. This eventually made me realize that I also read them, and also did not understand many things. And neither he nor I are particularly stupid people. And here's an interesting quote from the famous Weblog "Joel on Software": "Whenever somebody gives you a spec for some new technology, if you can't understand the spec, don't worry too much. Nobody else is going to understand it, either, and it's probably not going to be important." (Read more at the link).

Granted, my editor told me that the Apocalypses are sort of Larry Wall's braindumps, notes on design notes using a lot of jargon from the Perl mailing lists and summarizing a lot of discussion that took place there in one condensed article. However, they do indicate that a lot of new things will be added that most people are not familiar with and will need a lot of time to understand because they haven't encountered them before.

It even takes Damian Conway, Allison Randal, et al. a lot of time to prepare the Exegesis after the latest Apocalypse is published. Perhaps a different, more accessible format of the Apocalypses is needed. Perhaps, eventually, such accessible documentation will be made available, teaching people new to Perl 6 or even Perl in general how to learn Perl 6. (I do hope it will fare better than the original Perl 5 man pages, which were a positively awful resource for beginning Perl programmers.)

I'm pretty sure my friend and I are not dumb people. I know people who will have even more difficulty, and they're not dumb either. Who is going to take all of these people by the hand and teach them Perl 6?

Perl 6 is not Backwards-Compatible with Perl 5

You probably think: "Ha! Backwards-Compatibility is the curse of software design. Let's break it now so we'll get something manageable." That's very nice, but backwards-compatibility is also something you need to make sure people can have some amount of confidence in writing code that makes use of the language or API. Breaking it on purpose, without a good enough reason, is bound to cause resentment among the users, who may opt to convert to something that is known to be more backwards-compatible or stay with the old version.

Perl 6 breaks a lot of compatibility on purpose. In fact, most of the Perl 5 code out there won't compile with it (unless Perl 6 will run in some backwards-compatibility mode.) Naturally and hopefully, this Perl 5 code can be re-used from within Perl 6. That's better than nothing.

As an example of breaking things on purpose, here's some Perl 5 code I wrote:

for my $t (0 .. 6)
  {
  if (abs($new[$t]-$new[$t+1]) > 3)
  {
  $is_ok = 0;
  last;
  }
  }
  if ($is_ok)
  {
  push @moves, [$i,$j];
  }

And here's the equivalent Perl 6 code:

my $is_ok = 1;
  for 0..6 -> $t {
  if abs(@new[$t] - @new[$t+1]) > 3 {
  $is_ok = 0;
  last;
  }
  }
  if $is_ok {
  push @moves: [$i, $j];
  }

Recognizable, but completely different! Furthermore, the dereferencing and method invocation in Perl 6 changes from "->" to "." (just because that's the way it's done in languages such as Java and Python), so the good old string concatenation operator is now "_".

So imagine you have a large body of Perl 5 code which you need to extend with more code. Are you going to write the new code in Perl 6? Well, if you want other Perl 5 programmers (of which there are now several hundreds of thousands) to be able to understand it without getting on their nerves, forcing them to learn a new language, forcing them to understand Perl 6, etc., then Perl 5 is the only option. I predict that most software shops are going to stay a clear mile away from Perl 6, and mandate all of their programmers to use Perl 5 exclusively.

Writing new code in Perl 6 while having to maintain old code in Perl 5 is going to be confusing, and will require the developers working for your project to know both and to actively use both. Most Unix shops just settle on either Perl, Python, or a similar Agile language, and may even have strict style and use guidelines on how to write the code in these languages. They're not going to like having a dual Perl 6/Perl 5 codebase.

While software enthusiasts, who like to write code for fun, may learn Perl 6 because many of them like to learn new languages, they will probably be told to use Perl 5 (or Python, or PHP) at their workplace. Perl (1 to 4) grew as a language to get some Unix jobs done better. Perl 5 was intended as a revamp to eliminate many of the Perl 4 shortcomings, and even to direct Perl for writing large applications. Both of these goals were achieved, but what should still be remembered is that most people use Perl for in-house use, and this is what "pays the Perl developers' rent", so to speak.

Perl 6 may be a good language to design 10 or 20 years from now, but it's certainly not one for this moment. Perl 5 is a good language today already, and if we want people to adopt a new dialect of Perl, we need to start from it, not from a completely new page.

Perl 6 is too Complex

Before we go on, I ask you to make sure you've read what Joel Spolsky has to say about the growing complexity of programming. Yes, programming is becoming more complex, and IT workers find themselves having to (at least temporarily) specialize in a certain field or limited set of fields. However, it is still important that the framework designers try to reduce unnecessary complexity.

A good example are the Unix mail servers. Sendmail used to be the most popular solution, but its configuration is incredibly complex (which is just one of its many shortcomings). As a result, a new crop of mail servers came about: qmail, Postfix, and others. These all sported an easier configuration that even mere mortals could do.

Another good example are languages like Java or PHP. These are highly successful languages, in part because the rules, grammar, and syntax of them were kept as simple as possible. While their standard libraries are very comprehensive and complex, the language as a language is very simple. (I don't suggest that Perl 5 follow this lead -- a complicated core language is one of the things that makes it sexy -- I'm just noting this fact).

The Perl 5 core language is already very complex. Part of this complexity is justified, and the rest is a result of either legacy features or things that some programmers like to use. Nevertheless, Perl 6 will be much more complex than that, too complex for the present level of Perl programmers.

When Perl 5 was created, people expected its programmers to be experienced Unix sysadmins or programmers, probably with some working knowledge of Perl 4 (the Perl 5 man pages originally reflected this). The WWW boom wanted something else, and a great many Web programmers learned it because that's what their job required, sometimes even using it for writing "shell" scripts because Perl was all they knew at the time. Further developments, like the growing popularity of Linux and the bio-informatics boom, have made Perl even more popular. Some people even learn Perl as their first real programming language.

So, Perl 6 will be too complex for them. Much too complex. If I and my friend (who now eats hardcore scientific documents for lunch, and got a reputation for himself as the local Linux kernel guru) could not understand the Perl 6 Apocalypses, I expect much less of the many everyday Perl workers, who are just using Perl to get their jobs done and could not care less about all the extraneous Perl 6 features.

A lot of what Perl 6 integrates will probably turn out to be linguistic fads that no one will want to use. Integrating everything at this point is not going to be beneficial, especially for a language like Perl 5 that aims to be a no-nonsense language for everyday use.

Analogy with the Perl 4 to Perl 5 Conversion

A question that needs to be asked is whether this is analogous to the Perl 4 to Perl 5 conversion that took place circa 1993 and also broke a lot of compatibility, and required people to adapt or even rewrite a lot of their code. There is a place for comparison, but nevertheless, the situation today is very different. Perl 4 was heavily lacking in many respects and justified a good redesign that would make it more up-to-par with the powerful languages of then and now like Common LISP, Smalltalk, C++, and Python.

Perl 5, on the other hand, can serve us well in the foreseeable future. Another thing to note is that Perl 4 was a niche language that was used by various Unix workers to write support scripts and the occasional large-scale application, but not much else. Perl 5, on the other hand, is much more commonly used. There are many more Perl 5 programmers, much more Perl 5 code out there, and much more collective knowledge and love of Perl 5. Also, the Perl "market" of programmers that can learn it is much more saturated today than it was when Perl 4 started.

The Language Formerly Known as Perl 5

Here's a better idea: Let's continue to develop Perl 5 (either using the Perl 5 backend, PONIE, or something else), making incremental improvements, and so make sure it keeps with the pace of technology. Sometimes, compatibility can be broken, or features removed, but not in one big swoop, and always informing people about it first.

We need a new name, because Perl 6 bounds us with its upper digit, leading us to eventually have Perl 5.666. I'll use the name Fifer here, simply because it is an awful name that I don't intend to use. (I'll let the Perl community pick a better name from the list of new names, one of which I'm going to advocate). Fifer would be the language formerly known as Perl 5. It would belong to the Perl Family of Languages, which includes such languages as Perl 4, Perl 5, Perl 6, Ruby, and even PHP.

10 years from now, Fifer will probably be more similar to what Perl 6 is today. However, at that point, there would be plenty of Rindolf code that is perfectly working and modern, as people will have plenty of time to gradually adapt their code.

In a way, I think this is what will happen regardless of whether people read this article or not, but I like to make this prediction clear because I think a programmer eventually needs to make such predictions if he wants to make sure his work lasts for a long time. I see Perl 6 as a dead end, and so don't intend to try to understand it further, and don't intend to learn how to program in it, unless I actually have to maintain some Perl 6 code. (which I don't expect to happen). And I suggest you do the same.

The standing issues in Perl 5 (some of the major ones will be covered shortly) can be resolved without a complete redesign of the language. While a backend change may be in order (like switching to PONIE instead of perl5), or at least a heavy revamp of the original perl5 one, overhauling the language is not needed. The time calls for a gradual evolution instead of a complete revolution.

Standing Problems in Perl 5 and their Solutions

Perl 5 is a good language, all in all. Nevertheless, it has some standing problems which should be resolved. Perl 6 is the wrong way to resolve them. Here is the list of the most major ones as I see them, with suggestions on how to resolve them. Other people may have different views.

Lack of Good Accessible Reference Documentation

The Perl 5 Man Pages are the official reference documentation for Perl 5. Nevertheless, they:

1. Are quite disorganized. Many things are documented in very obscure places.
2. Rely on a lot of knowledge of other technologies (many of them pretty obscure or largely superseded by Perl 5 now).
3. Give many examples that give a common use, instead of trying to illustrate the point. Usually, they cannot be fluently read.
4. Are generally very hard for a person without a good background in what they talk about to understand.

The Camel Book is much better in this regard, but it is not freely redistributable or modifiable, and not even available online except as part of the pay-per-month Safari, or in various illegitimate online copies. It is, thus, also inadequate.

A good core reference documentation needs to be written, especially taking into account the fact that the ones for Python or PHP are excellent. The easiest way for the community to resolve this is that the authors of the Camel Book make its text available online, preferably with its POD sources. This will not hurt the book sales much, as many people buy it to read before going to bed, or to give as a present to their co-workers, or to keep at their workplace for everyone to enjoy.

If this is not going to be done, then either the Perl 5 Core Documentation will need to be heavily revamped, or an entirely new documentation ought to be written. This will mean much more work on the part of the contributors volunteering to do it, but it is quite necessary.

Perl 6 would be a non-solution to this problem because it gives an entirely new language for which new core documentation has to be written.

(Note that I'm not referring to Perl 5 tutorials, which help a beginner get started. There are quite a lot available, and some of them are reportedly good enough.)

A More Unified Object System

The Perl 5 Object-Oriented Programming system is quite powerful, and adequate for most needs. Nevertheless, to extend it whenever possible, developers wrote a great deal of userland Perl modules on CPAN. However, it is not perfectly clear whether it is possible to make active use of several of these modules or all of them in one applications.

A good idea may be to create a new OOP system which features everything these modules have to offer. This may be possible to do in userland, while requiring people to choose between this or the original Perl 5 way of doing things. It can actually model the Perl 6 OOP framework, without requiring people to adopt Perl 6 entirely. Or it can be something completely new that attempts to be more Perl 5-ish.

Regardless, it can be done in Perl 5.

Better Garbage Collection

The current perl5 garbage collection, which doesn't work well if there are circular references, is incredibly limiting in the choice of the application design. We need a better one. I believe Parrot and PONIE will give it to us for free, but I may be wrong. In any case, perl5 can probably be tweaked to adopt such a system.

Multi-Threading

The current iThreads threading model is very resource intensive, and goes against most of the multi-threading tradition used before Perl 5 adopted it. We need a better threading model in which each thread simply shares the same memory space and variables as the other threads. This is similar to what happens with POSIX Threads on Unix, Win32 Threads on Windows, and the threading model of Java or Python. It also was the old Perl 5.005 threading model.

It is possible that the perl5 backend cannot support this very well. If Parrot (or an entirely different backend) does, then a change of backend may be in order.

Other Issues

I have outlined some of the things I found pressing in Perl 5 in the Rindolf Spec (version 0.3.5). Since then, I neglected working on the specification (much less started working on a suitable implementation), partly because I concluded that Perl 5 was already good enough for me. Nevertheless, the specification may be studied to search for nice additions to the language, all of them possible without breaking compatibility.

Other people may have other things that bother them. I am happy to be informed of any things that they feel are missing.

Conclusion

Perl 6 will probably not be widely adopted. The future of Perl lies within Perl 5 and Fifer, i.e., the language powered by perl5, PONIE, or perhaps a different backend. Any time invested in working on Perl 6 or learning about it can probably give you new insights about programming, but don't expect your efforts to have any day-to-day useful value.

People want a language that gets the job done, is fun to program in, and which they love. Different people have different ideas of what this language is, and they also use different languages for different tasks. To quote my good friend (a different one), "How can you make a programming language that is good for every purpose, if you can't even make such a screwdriver?"

Perl 6 is the wrong thing at the wrong time. Perl 5 is already good enough and will be so for the foreseeable future. We can evolve Perl 5 and gradually make it even better and more suitable for our needs, as we see these needs coming. There is no reason to break every last bit of compatibility, create an incredibly complex language which even experts find difficult to understand, and integrate every last feature from every other language in existence today, just because it is conjectured that some people may find it useful.

A gradual evolution of Perl 5 would be a better idea. Fifer will be a language of the present, instead of a very crude prediction of what new languages will look like 10 or 20 years from now. In twenty years, Fifer will probably be more similar to Perl 6. However, it will still be very different, as things in the software world don't always develop the way people expect them to. And it will also be able to run most of the Perl 5/Fifer code that has already been written (and possibly adapted to the new changes).

Let's continue to work on Perl 5 and just make it an even better language (and technology and culture) than it already is. What is for certain is that Perl 6 isn't better.

Author's bio:

Shlomi Fish once defined himself as a "Programmer, Writer, Amateur Mathematician, Wannabe Philosopher, and someone who studied in the Technion in the vain hope of becoming an Electrical Engineer". He does not consider himself a sane person, but is quite certain that only makes him more interesting.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories Topic :: Software Development :: Interpreters

Referenced projects Perl - A high-level, general-purpose programming language.

 Comments

[»] OK, now talking about some real numbers
by Nirav - Apr 3rd 2007 10:44:00

Shlomi Fish, I don't use Perl but you have pressed very sensitive nerve of many Perl advocates.

Anyhow, here are some real-time statistics from a premium job board.

Java : 1 - 30 of 16216 jobs
C# : 1 - 30 of 6625 jobs
.NET : 1 - 30 of9080 jobs
Perl : 1 - 30 of 5368 jobs
Python : 1 - 30 of 1022 jobs
Ruby: 1 - 30 of 439 jobs
Ruby on Rails : 1 - 30 of 223 jobs
TCL: 1 - 30 of 407 jobs

Well, Perl is still holding up good but who knows for how long.

[reply] [top]

[»] A few comments
by Hector Luis Gimbatti - Nov 23rd 2004 22:47:23

a) No one Understands Perl 6.
Who you mean by `No one'?. If no one understand
perl 6, no one will ever program in perl 6. I see some
ppl programming with perl 6. So the sentence: No one
Understands Perl 6 is false.

b) Perl 6 is not Backwards-Compatible with Perl 5.
Why it has to be Backward-Compatible?.
If you think perl 6 as a new programming language,
then, tommorrow you will pretend that C would be
compatible with intercal.
If you think perl 6 as a new version of perl, then you
have to analize one thing (maybe more):
1) You will have to rewrite all your piece of software,
because of Perl 6?.

c) Perl 6 is too Complex.
Maybe .But even Lisp is complex. And there's a lot of
people programming in Lisp.
You have to define the word Complex. And then ask
yourself: This complexity is always bad, or have some
good stuff?.

d)Perl 6 is the wrong thing at the wrong time. Perl 5 is
already good enough and will be so for the
foreseeable future.
Well. There's something interesting about that.
If Perl 5 is good enough, then you can keep
programming in perl 5. If you want to continue
developing perl 5 you can do, too.
The other thing... Perl 6 is the wrong thing .... time.
Are you sure?. Why do you said that?
Follow me:
If all people program in C. C is good enough. Then
why to develop another Programming Language?.
If we decided to develop another Programming
Language, then we have to have a good motivation,
or reason. So, Perl 6 is only a new syntax, and a lot of
crap, or maybe is doing things that improves and
makes perl a better language?.
If Perl 6 is completely study, no one programs (really)
in Perl 6.. so larry would stop developing Perl 6, no
one will ever program in Perl 6, and everyone will start
programming (or continue) in perl 5.
But, if Perl 6 is better than perl 5 in some aspects, and
one or two brains understand it, and exploit it, then
Perl 6 would be the better solution to one problem.

As a final conclusion, you don't have to think about a
programming language, as a solution for every
problem. You have to think about it, as another way to
do things.

I'm sure that Perl 6, even if few ppl understand it,
would be the solution for a lot of problems.

--
HLG.-

[reply] [top]

[»] Here's a tip on writing better Perl5:
by Aristotle Pagaltzis - Nov 19th 2004 07:04:59

  MOVE_CHECK: {
      for my $t ( 0 .. 6 ) {
          last MOVE_CHECK
              if abs( $new[ $t ] - $new[ $t + 1 ] ) > 3;
      }
      push @moves, [ $i, $j ];
  }

Cheers.

[reply] [top]

[»] no excuses
by Guido Draheim - Oct 18th 2004 14:12:01

As the discussion went, I think that betting on a parrot or some kind of multi-language approach is a false excuse. As already said, in a multi-developer environment there will be a standardization on source style even going beyond basic syntax elements. Anyway, there is a saying that for some new technology to find a breakthrough it needs to have *two* additional useful features over existing ones. And sure it does not make it easier to add some pain to the mix like some syntax that looks familiar but which means a different thing now. So there is still the argument why to do such a thing when one can have just as well a feature upgrade on the good ol' stuff.

[reply] [top]

[»] This article is crap
by . - Oct 18th 2004 10:07:40

Jesus. It's been a while since i have read such an unimaginitive diatribe from somebody who is patently dull and lazy.

Big yawns all round.

[reply] [top]

[»] False
by Frank Wiles - Oct 18th 2004 08:06:05

Just wanted to agree with most of all of the comments here. This article was not very well researched and leads people to believe the wrong things.
I confess to only skimming the Perl 6 works by Larry and Damian, but even with just a skimming I know most of this article is false and in some cases FUD.
I hope this author's lack of research and understanding do not end up hurting Perl as much as these types of things can.
Please everyone, do yourselves a favor and disregard this article.

[reply] [top]

[»] Re: False
by yeupou - Nov 5th 2004 10:38:12


> Just wanted to agree with most of all of

> the comments here. This article was not

> very well researched and leads people to

> believe the wrong things.

>

> I confess to only skimming the Perl 6

> works by Larry and Damian, but even with

> just a skimming I know most of this

> article is false and in some cases FUD.

>

> I hope this author's lack of research

> and understanding do not end up hurting

> Perl as much as these types of things

> can.

>

> Please everyone, do yourselves a favor

> and disregard this article.


I would be happy to follow your recommendations.
But why one should believe you more than the
author of the article? At least, he brought
arguments. You did not.

--
Mathieu Roy General Homepage: http://yeupou.coleumes.org/ Computing Homepage: http://alberich.coleumes.org/

[reply] [top]

---

[»] Re: False
by Frank Wiles - Nov 8th 2004 07:25:15


> I would be happy to follow your

> recommendations.

> But why one should believe you more than

> the

> author of the article? At least, he

> brought

> arguments. You did not.

I didn't feel the need to argue against mostly incorrect facts. His arguments are ok, it's just that all of them were refuted below, and aren't even issues in Perl 6. Everything he stated is already being taken care of.

His article is like arguing about the proper way to get Bush elected, a week after the race is over and having Bush win. My point in commenting was I wanted everyone to know that the "issues" he brought up are not in fact "issues".


[reply] [top]

---

[»] If it's good enough...
by Marek "Baczek" Baczyński - Oct 18th 2004 02:04:17

...just use it. Nobody will force you to use Perl 6 and nobody expects you to use it.

Perl 5 will be here forever, and it's very likely that you'll be able to mix Perl 5 and Perl 6 together. Check out Parrot.

[reply] [top]

[»] So should there be two versions of Perl?
by fraktalisman - Oct 17th 2004 07:48:57

I am personally quite happy with Perl 5, using it for web development, and still continually learning to use it and how to use it better.
I don't want to be forced to switch to Perl 6 just because it's new. Until now I didn't take the time to read about its new concepts and possible advantages. Maybe there would be a reason for me to switch to Perl 6.
Comparing the situation with Flash: although the current versions have great advantages, but I often used Flash 4 - for backward compatibility, but also because I'm still used to the program. It seems that it would be nice to be able to stick to Perl 5, and use Perl 6 where necessary.
Now 5 and 6 are not compatible? That would be a pity. There is so many working software written in Perl 5, developed, tested and corrected over the years. There is no need to change that. Keep it running! My conclusion: there needs to be a - quite long - time for transition, where both languages can and should be used. Thus, some kind of continuous development of Perl 5 will be needed even when version 6 is around. Is this any problem? Not necessarily. Webservers can be configured to recognize both version appropriately, I hope. Local computers likewise.

[reply] [top]

[»] Re: So should there be two versions of Perl?
by Aristotle Pagaltzis - Nov 19th 2004 09:23:31

But there's noone forcing you to use throw Perl 5 off your system to install Perl 6. The two can happily coexist, much like you work with Flash 4 at the same time as with newer versions.

[reply] [top]

---

[»] Re: So should there be two versions of Perl?
by Chaddaï Fouché - Jul 9th 2006 12:54:24

Even better, the interpreter for perl6 will silently run Perl5 scripts (the perl6 mode require a "v6;" at the beginning of the script) and you'll be able to use Perl5 modules in your Perl6 scripts.

Contrary to the objections of the author of this article, Perl 6 won't really break compatibility, it will just offer a much better and much clearer (function signature... if anyone here thinks the Perl5 model is correct I would like to know his arguments ?!) way to write your Perl script (yes, the Perl 6 scripts give a very perlish feeling, just check Pugs for examples).


--
Jedaï

[reply] [top]

---

[»] Mixed feelings
by imipak - Oct 16th 2004 23:42:16

Although this starts off sounding like a criticism of Perl 6, please read a little further before deciding.

Given that I've never minced words when people have made drastic API changes to other languages, I don't feel I can exactly endorse the same thing in Perl. Often, such changes aren't necessary, their only function to beautify the language or to conform to some (often transient) "ideal" in Software Engineering. You could achieve exactly the same effect by many other means.

I consider such practices "lazy" for two reasons. Firstly, redesigning the language is a very small portion of the work involved. The bulk of the actual labour has to be put in by application developers, who then have to divert time and energy from improving their software to merely making it consistant with the new environment.

Secondly, and perhaps more importantly, if the language genuinely has enough structural flaws, design errors and syntactical weaknesses that a redesign is actually necessary, it probably indicates that the foundations aren't holding up. In that case, you can build what you like on the foundations and it'll still not stand the test of time. Under such conditions, it might be better to make use of your experience but basically start from scratch.

Now we get to the real meat of this post. Although Perl 6 shows some signs of being reworked (which I freely admit I'm not crazy about), I'm not seeing any huge changes. From what I understand, and from what other posters have said, Perl 5 code will work with Perl 6. The changes in, say, Java between the alpha, beta, 1.x and 2.x releases, or between Python 1.x and 2.x were far more drastic and really did break a lot of code. I'm not seeing that here.

As for the design documents and specifications - well, nobody is ever going to agree on things like that. I happen to like Z, but I can guarantee that if I posted a Z specification to a public forum (unless it was the Z newsgroup) fewer than 1% of those reading it would understand it. Z maybe an international standard, but that doesn't mean anyone learns it.

Will there be a code fork, caused by Perl 5 vs. Perl 6? It is possible. Some people still write in the K&R dialect of C, too. In fact, it could be considered a failure, if code forks didn't happen. Think about it. The only reason for everybody - every vendor, every programmer, every reimplementor - switching is if Perl 5 was inferior in every regard.

If there is a single area in which Perl 5 beats Perl 6, then those catering to that area are going to stick with Perl 5. Voila, code fork. But if Perl 6 beats Perl 5 on every imaginable test, under every possible condition, then Perl 5 went down the wrong path entirely. Sometimes that happens.

Far more often, programming languages evolve. In the process of evolving, however, certain compromises in the design occur. Usually, languages gain strengths in areas that turn out to be often used, at the cost of not being quite so good in areas that aren't as useful. When this happens, there's usually a fork in either the design or the implementation, and different interest groups go their own way.

In some cases, one of the forks survives and the others die off. Of all the many hundreds of dialects of BASIC, for example, only Visual Basic is much used.

In other cases, forks evolve separately and distinctly, catering to groups with so little overlap that there is little reason for one fork to be preferred overall. Again, using the example of BASIC, the language is a design fork from BCPL and Fortran. Thirty years of development has resulted in considerable divergence. Fortran and BASIC quite happily coexist today, in mainstream use, with little evidence that either will "replace" the other. Even BCPL still holds a corner of the language market.

Finally, I'd like to conclude that certain evolutionary steps can be expected to die out. OpenMP is no more likely to survive than any other "parallel C" or "parallel Fortran" has in the past. Often, such extensions are proprietary, non-portable or simply unnecessary. If you can get about the same results without an extension as you can with the extension, unless there is a considerable benefit in keeping it, the extension won't survive. The added resources needed in maintaining the extension and the code that uses it, not to mention getting programmers over the learning-curve, are often significant. If the total benefits are less than the total costs, nobody is going to bother.

So far, the total benefits of each iteration of Perl have been worth the costs involved in keeping up. The only way anyone'll be certain this will be true of Perl 6 is by seeing what happens. Even if Perl 6 catches on, it might never supplant Perl 5, because different people will see different costs and different benefits. As I said before, that could even be seen as a Good Thing.

Interpreted languages are going through a reneissance, with languages such as Perl, Tcl/Tk, Python, Ruby, ML, Scheme and PHP carving quite substantial markets for themselves. That won't last forever, but for now, it's more than capable of handling any changes Larry Wall might make.

[reply] [top]

[»] Re: Mixed feelings
by Schwern - Oct 17th 2004 01:12:11


> From what I understand, and from

> what other posters have said, Perl 5

> code will work with Perl 6.

Not quite. Perl 6 will not be compatible with Perl 5 in that Perl 6 is not just additional features on top of Perl 5. They are different languages. You will not be able to cut & paste Perl 5 code into a Perl 6 program and expect it to work.

What is meant by Perl 5 code working with Perl 6 is that Perl 5 (via PONIE [Perl On New Internal Engine]) and Perl 6 will both run on the Parrot virtual machine and compile down to Parrot bytecode. It is a goal of the Parrot project that languages running on Parrot will be able to interoperate. In this way you will be able to have a Perl 6 program calling functions from a Perl 5 module and vice-versa.

In this way you should be able to mix Perl 5 and Perl 6 code. This will allow you to use existing modules and libraries and slowly transition your code one piece at a time from Perl 5 to Perl 6. Or if you find there's things Perl 5 continues to do better than 6 you can keep writing those portions in Perl 5 much like how you can write parts of a Perl 5 program in C.



[reply] [top]

---

[»] Here's a good refinement of Perl 5 OO syntax
by Mark Aufflick - Oct 16th 2004 23:38:31

And it's implemented for Perl 5 IN Perl 5:

reformed-perl

[reply] [top]

[»] This is wrong in so many ways.
by Ovid - Oct 16th 2004 20:59:32

I don't want to sound too harsh, but this criticism is misguided. OK, so he and a friend have problems understanding the Apocalypses. So do I. So do a lot of people. However, when I read Exegeses, all of a sudden, things make sense. The only reason I don't feel comfortable with Perl 6 is that I am not (yet) regularly programming in it. When people start to use it regularly, they'll appreciate its power. It solves many of the problems that are hampering Perl 5's growth.

He also points out that it's not backwards compatible with Perl 5. Ignoring the Ponie project for a moment, I have to ask "so what?" I can't put a Ferrari's motor in a Ford Pinto. That doesn't mean that there's something fundamentally wrong with Ferraris. If all you need is a Pinto, fine. Drive the Pinto. If you need a Ferrari, a Pinto won't cut it. I work on large scale systems that frequently butt up against the limitations of Perl. A Ferrari would be very handy.

If Ponie pans out, Shlomi Fish is dead wrong about backwards compatibility. If Ponie doesn't pan out, we can think "Perl 6 is to Perl 5 what C# is to Java." (Only more so and without the proprietary platform issues.)

And let's take a look at the comparison code snippet he produced (minus the curious formatting):

# Perl 5
my $is_ok = 1;
for my $t (0 .. 6) {
    if (abs($new[$t]-$new[$t+1]) > 3) {
        $is_ok = 0;
        last;
    }
}
if ($is_ok) {
    push @moves, [$i,$j];
}

# Perl 6

my $is_ok = 1;
for 0..6 -> $t {
    if abs(@new[$t] - @new[$t+1]) > 3 {
        $is_ok = 0;
        last;
    }
}
if $is_ok {
    push @moves: [$i, $j];
}

He states the the Perl 6 is "recognizable, but completely different!" I'm curious to know how he defines "completely different." The sigils are now part of the variable name, clearing up one of the greatest sources of confusion for new Perl programmers. The for 1 .. 6 -> looks different but it's hardly obfuscated. Ooh, and look! Fewer parentheses are needed.

He also complains about arrows being eliminated in favor of the dot operator. I don't understand his complaint here. It's such a common operator that Huffman encoding suggests that it should be shorter and, conveniently, there's already an operator that's practically an industry standard. How handy. Personally, I always thought the arrow operator was for C programmers who were used to dereferencing structs. The encapsulation violation this implies is a Bad Thing.

Frankly, I am solidly in the "we need a new Perl" camp. Of course, many argue that Perl 6 is too complex. However, when you look at the big picture of Perl 5 you could make the same argument ... until you realize that everyday coding tends to use an easy-to-learn subset of Perl. That's what we're going to see in Perl 6. The easy things will be easy and the hard things will be possible. Now that's not so strange, is it?

And looking at his follow-up comments, I noticed this interesting snippet:

> Not really, no. What's wrong with:

> my ($self, $name, $family_name, $street) = @_;

Followed by the question "What's MMD?"

MMD is multi-method dispatch. One of the serious limitations of Perl is its poor argument handling. By allowing multiple methods with the same name to take different arguments, you can automatically dispatch to the correct method and let the language take care of it, rather than force the programmer to write a bunch of bug-prone code to handle the dispatching. Frankly, I'm tired of fixing an entire class of bugs that languages such as Java or SmallTalk simply don't have. For someone who is writing a language critique to fail to appreciate such a fundamental feature speaks volumes about the quality of such critique.

Cheers,
Ovid (And my apologies if my formatting is messed up. I've never posted here before.)

[reply] [top]

[»] You've read the fantasy. Here's the reality.
by Schwern - Oct 16th 2004 17:35:46

This article is written from a point of near ignorance of what is really going on inside Perl 5. Except the author has had this pointed out to him time and time again so he can't really hide behind simple ignorance. He makes statements about ideas he considers "simple" without any idea of the extreme complixity in implementing any of them in the reality of Perl 5. He has demonstrated a marked lack of understanding of the guts of Perl 5 or the design of Perl 6.

So I would like to simply say: please ignore this article. The article is not a troll, because I know Shlomi is sincere, but it is very wrongheaded. Its sorry that Freshmeat allows such things to be published, I wish they would do some basic editorial checks before publishing. For those that know of me hopefully that's enough explaination. For the rest, read on.


I write this not as a rebutal to the article but to prevent its spurious assumptions and erroneous conclusions to spread.

I'm going to only briefly talk about the documentation issue and get it out of the way because its such an old and tired argument. Documentation is hard. Documentation is always in need of improvement. Everybody knows this.

In fact, we know it so well that we've been writing lots of new introductory Perl man pags. perlintro, perlretut, perlreftut, perlrequick, perlboot, perlbot, perldebtut, perlopentut, perlpacktut, perlthrtut, perluniintro are all fairly new tutorial man pages.

And look, there's learn.perl.org. A whole site devoted to learning Perl. And several beginner's mailing lists. And an entire book generously made freely available online by Simon Cozens, one of the better Perl developers out there.
http://learn.perl.org/library/beginning_perl/

Shlomi has waved around two magic fixes to the Perl documentation problem for a long time. Make "Programming Perl" free or rewrite everything. Its questionable if the Camel would solve all our documentation problems since its derived from the man pages, but it doesn't matter. The authors and they have said no. Their decision should be respected, everyone's allowed to make money off their own work if they like.

So what about rewriting everything? I personally believe in incremental fixes but sure, go for it. Why not? Maybe something better will come of it. But I'll tell you what won't work: Writing articles about how other people should rewrite the documentation or give away their work. Shlomi's been doing this for years and frankly its gotten tiresome. Direct all that energy at more documentation patches please.

Perl 6 actually is a solution to the documentation problem. Emotional attachment to the existing doc layout doesn't exist so we can fix long standing problems. More importantly, Perl 6 is being completely documented as its being designed. Therefore the documentation will not grow piecemeal as the Perl 5 docs did but we can lay it all out sensibly up front. Finally, we've come along way in knowledge and culture about documentation in the last 10 years.

And besides, wasn't he just proposing rewriting the docs anyway?

That's all I have to say about the docs.


Now for Perl 6. Rather than take the article point by point let's just lay out some simple realities. The article is sorely lacking in knowledge about what is really involved in developing Perl.

We'll start with some simple truths. The sky is not falling.

* Perl 5 is not going away.

Perl 5 is still actively maintained and shows no signs of slowing down. In fact, new stable releases are coming out faster and more regularly than ever. Parrot and Perl 6 have not resulted in a brain drain from Perl 5. Instead the community expanded to fill the new needs.


* Perl 5 is NOT GOING AWAY!

The PONIE project is an attempt to incrementally replace the guts of Perl 5 with pieces of Parrot. This will result in a better bug-for-bug compatibility with Perl 5 than a complete rewrite. Eventually PONIE will become Perl 5. So far it works, you can download an alpha from CPAN right now.


* Perl 5 will work with Perl 6.

If all goes as planned with PONIE and Parrot, Perl 5 code will be able to interoperate with Perl 6 code by virtue of their both compiling down into Parrot bytecode. This means the huge bulk of existing modules out there (such as CPAN) will still work with Perl 6 to ease the shock of the intial transition.

Nobody's forcing anybody to learn Perl 6. In fact, we're bending over backwards so they won't have to.


* Parts of Perl 6 are being backported into Perl 5.

There is a whole host of Perl 6 features that have been implemented in Perl 5. Here's some of them.
http://search.cpan.org/search?query=Perl6&mode=all

Some are just proofs of concept. Some, like the grammar parser, are intended for eventual production use. Some, like the defined-or operator, will appear in the Perl 5 core. Perl 5 will continue to absorb whatever it can from Perl 6 without breaking backwards compatibility.


Let's talk about the current state of Perl 5.

* Perl is old.

Perl 5 will be 10 years old tommorrow (11 if you count from the first alpha). Perl itself is pushing 17. A lot has changed in 17 years. A lot has changed in 10 years. A lot has changed even in just 5 years. And I'm not just talking about technology I'm talking about the Perl community. Its grown from a bunch of sysadmins avoiding shell scripting to a bunch of half-educated .com CGI programmers and is now a community of seasoned veterans using Perl for large applications.

Perl 5 is having trouble keeping up. Here's why.


* The internals of Perl 5 are a disaster.

Layers upon layers of C macros and ifdefs. Code dating directly back to Perl 1. Hacks made to support TWO threading models. Hacks made to support every OS under the sun. Hacks made to support buggy libraries. Buggy compilers.

As a consequence some very powerful techniques are avoided because they are slow. Tying is slow. Overloading is slow. Threads are slow and fraught with bugs. Hell, function calls are slow which is disasterous to modern programming.

And its becoming increasingly difficult to change or optimize anything without breaking something.

This alone is reason enough to rewrite the code. But what about the language?


* Nobody knows how its supposed to work.

There is no specification for Perl 5. Features are "discovered" all the time. XS is largely undocumented. There are tons of "accidental" features that people rely upon all the time. The renewed interest in regression testing has helped but any rewrite is going to get subtle things wrong.

This means when you try to add in a new feature, or fix an old one, much more often than not the patch will be shot down for esoteric reasons of backwards compatibility. This means improving the Perl 5 language becomes very, very difficult.


* The grammar is undefinable.

Not only is there no grammar definition for Perl 5, parsing Perl 5 code without running it has been proven to be impossible. Many modules can alter the way the code behaves. From the somewhat extreme filtering modules like Lingua::Romana::Perligata to the simple and commonly used strict.pm.

This means no automated programming tools for Perl 5. This means no refactoring browsers. This means one of the most powerful programming tools of this decade will remain unavailable to Perl programmers.


Now, lets consider some things about the Perl 6 design.

* It has to live a long time.

As mentioned, Perl itself is pushing 17. Perl 5 is 10. If you're the sort of person that has to play with the Perl 5 internals or write advanced CPAN modules you know its already showing its age.

Perl 6 has a planned lifetime in decades. The point was made that "Perl 6 may be a good language to [sic] design 10 or 20 years from now". This is true. The hope is to make the design flexible enough to be competative in 10, 20, even 30 years. The only language which has remained respectable that long is C and arguablely not because its a good language but because its the fastest thing out there.

It was also said that Perl 6 is "certainly not [a good language] for this moment." That is also true. However, it is not a language for this moment. There's another year or two before an alpha is released and I'd be surprised if a truly stable release came out before 2008. When you look at what Perl programmers were doing in 2000 (sysadmining, basic web stuff) vs what they're doing now (pretty much everything) you can see why the Perl 6 design is sticking to the bleeding edge.

I've been a Perl programmer for nearly eight years now. I'd like to be a Perl programmer for another 10 or 20 years at least. I'd rather some short-term pain now in transitioning to Perl 6 than long-term chronic pain with a limping Perl 5.


* Perl 6 is not changing as much as it seems.

People who read the Perl 6 materials are often overwhelmed by all the change and new features. What's often forgotten is how much is not being changed. Or how many of the changes are superficial. It is better to read Damian's Synopsis and Exegisis than Larry's Apocalypses to get an idea of what using Perl 6 will really be like. Larry is writing a language spec. Damian is writing user documentation. Consider them like "Learning Perl" vs "Programming Perl".


* Perl 6 is actually simpler than Perl 5.

Perl 6 is trying to remove as much of the unnecessary complexity and exceptions from Perl as possible. The grammar is simpler and easier to parse. There's less exceptions. Operator precedence is simpler. Scoping is simpler. Writing OO code is more explicit and regular. Rules (ie. new the regexes) are simpler and its easier to write and modify complex expressions.

And the same will be true of Perl 5 as Perl 6: You don't have to learn the entire language to get things done. Personally in eight years of programming Perl I've never learned how to use formats, pack or XS in Perl 5. Much of the really interesting/complex stuff will be hidden inside modules. Modules written by the top 1% of Perl programmers but used by everybody else. Modules allow you to hide complexity but still take advantage of it.


* Perl 6 will retain the Perl 5 class system in addition to its new one.

"This [a new OOP system] may be possible to do in userland, while requiring people to choose between this or the original Perl 5 way of doing things."

Yes, Perl 6 is doing exactly that. We're making the Perl 5 regex engine available, too. Please do more research next time.


With all the backround information in place, let's look at some of the propositions and why they won't work.

* Just bolt the new features onto Perl 5!

I've already shown why the existing Perl 5 code is becoming impossible to work with. I've already shown why the language is too brittle to accept new changes. If we're going to hang onto backwards compatibility there's little in the way of large changes that can be made.

As an example, to get a firm idea of the order of magnitude of work involved in something like fixing the garbage collection and threading systems take a look at the effort being made in the PONIE project. Taking advantage of Parrot's GC and threading is one of the major reasons for PONIE. This is not something you just wave your hands at.

iThreads, as another example, took years to even bring into the usable state they are now. And this is over the ashes of the first attempt at threading (the 5.005 threads). The fact that the article blithely states that we should now go back to 5.005-style which was tried and failed tells me he has absolutely no idea what's involved.


* Just do it all as modules.

The article offhandedly states that "a good idea may be to create a new OOP system which features everything [advanced CPAN OOP modules] have to offer" and lets us know that "it can be done in Perl 5". As an author of several of the sorts of modules he's talking about I can say this is fantasy. In order to get advanced OOP stuff done in Perl 5 you often have to do very perverse and mutually incompatible things. Syntax filters. Symbol table hacking. Global autoloaders. Just getting the magic working is hard enough without worrying about other people's magic.

I'm not saying its impossible, I'm just saying its really, really, really, really hard.


* Fifer: Add incompatibilities a few at a time.

This is the worst of all possible worlds. Could you imagine what would happen if every release deliberately broke compatibility? For every new release of Perl you'd have to check over all your existing code to see if anything broke. Anyone wanting to ship Perl code would have to ship different source for each version of Perl. CPAN would become useless. No one would ever want to upgrade, and we have enough trouble getting people to go from 5.6 to 5.8 as it is, and we're anal about backwards compatibility. Perl would become balkanized and useless.


* Rindolf

Shlomi has been pushing Rindolf for years. It puts forth some shallow improvements to Perl 5 and doesn't really address any of the real problems. Its priorities are somewhat bizzare and detached from reality. It doesn't even bring Perl 5 up to the level of other existing languages.

Rindolf is vaporware. There has never been any code for it and having seen how the author works over the years I doubt there ever will be. He seems to be expecting someone else to pick up his ball and run with it. Something I tell people time and time again about free software is this: if you want something done do it yourself!


So that's that and I wasted too much time writing all this.

[reply] [top]

[»] Re: You've read the fantasy. Here's the reality.
by gt3 - Oct 17th 2004 16:06:52

Most people don't live in reality in general, why expect their opinions about programming to be based in reality

[reply] [top]

---

[»] Re: You've read the fantasy. Here's the reality.
by Eric Garland - Oct 18th 2004 06:24:29

Thank you for writing that, it saved me a lot of time.

I've done some XS work in Perl 5 and I have to say the parent post is absolutely correct, Perl 5 is straining against a horribly messy underbelly and the only reasonable way around it is to start over the way they are doing.

Proper threading is impossible to do gracefully with the current Perl 5 underbelly. Perl 5's threading is a mess. It's not safe to use in mod_perl. It's horribly memory intensive. It's cumbersome to use. Optimizing it makes you do really ugly things. Objects can't be shared (the data can but the blessing doesn't get copied into new threads.) The only method of fixing the memory problems that seems remotely possible is a copy-on-write scheme which, to me, doesn't fix much. A rewrite of Perl (the platform) is desperately needed.

I'll repeat what the parent said for good measure: Perl 6 will run Perl 5 code. Perl 6 (the platform) will be a good place to run Perl 5 (the language) code. Also, Perl 6 (the language) will be worth learning.

Changing -> to . is important. Most people who get to code in one language exclusively, don't get to code in Perl. Currently you have to retrain yourself to interperate ->'s as .'s or vice versa when switching to/from any other language. Switching that will help people who know other languages use perl and people who know perl use other languages. Perl has always tried to do that.

Being able to name and store regex's is important. All too often non-perl coders see a regex and run away from perl screaming. If we can name the regex with something describing what it does, it becomes much easier to read.

There are lots of other really cool things I see in Perl 6 (the language) that I really like. At first I didn't like the idea and I was angry they were changing it in incompatible ways. Now I'm happy they broke compatibility. The things that aren't compatible, needed to be changed.

I've been programming in Perl for over 10 years (started in 4 and moved to 5) and it's been my primary language the whole time. I've loved Perl 5 but I can't wait for Perl 6.

Bring on the changes. It's about time!

[reply] [top]

---

[»] Re: You've read the fantasy. Here's the reality.
by Andrew Cattau - Oct 18th 2004 13:59:02



> Changing -> to . is important. Most

> people who get to code in one language

> exclusively, don't get to code in Perl.

> Currently you have to retrain yourself

> to interperate ->'s as .'s or vice versa

> when switching to/from any other

> language. Switching that will help

> people who know other languages use perl

> and people who know perl use other

> languages. Perl has always tried to do

> that.

while i agree with you and the parent on every other point, this one seems ridiculous. I have developed intensively in c, c++, javascript, perl, and php and never had any problems switching from . to -> and vice versa. every language has features that distinguish it from every other language, and anyone who regularly switches between languages learns to adapt. if they are concerned about making things easier for programmers from other languages, why _? no other language (that i know) uses _ for concatentation. ||, +, and . are all used for concatenation by other langagues, why not use one of those? And if perl has "always" tried to help users of other languages, why is there still no switch statement? (actually, i suspect the parent's post already answered that for me. sorry. just one of my perl peeves.)

that said, i am really loking forward to perl 6; the perl langugage is long overdue for an overhaul.

[reply] [top]

---

[»] Re: You've read the fantasy. Here's the reality.
by Paul Hebble - Nov 6th 2004 11:59:37

MUMPS uses underscore for concatenation. Which, IMHO, is a good enough reason to be skeptical. :)

[reply] [top]

---

[»] Perl is dying, reinventing it is the only solution
by mattiasw - Oct 22nd 2004 00:46:54

There are lot of people out there that like me used Perl 5-10 years ago, but stopped using it due to is write-once-read-zero times approach.
Understanding old Perl programs has always been awful.
If you look at usage statistics, Perl is today is way behind modern languages like Java, C#, VB.NET, PHP. It has been marginalized.
So inventing a new simpler Perl is the only solution, otherwise Perl will be totally dead in a few years.

[reply] [top]

---

[»] Re: Perl is dying, reinventing it is the only solution
by Sam - Oct 24th 2004 01:07:17

Care to site your mysterious usage statistics Or do you just make it up as you go? The freshmeat browse by language appears to show a different universe of software to the one you live in.

[reply] [top]

---

[»] Re: Perl is dying, reinventing it is the only solution
by yeupou - Nov 5th 2004 10:46:19

Sam already pointed out the strange usage you do of statistics. But I'd like to point out that write-once-read-zero approach is more a matter of developer than language. The fact is that perl allows developers to do write-only programs. But are developers forced to do that with perl? How so?

--
Mathieu Roy General Homepage: http://yeupou.coleumes.org/ Computing Homepage: http://alberich.coleumes.org/

[reply] [top]

---

[»] Re: Perl is dying, reinventing it is the only solution
by Aristotle Pagaltzis - Nov 19th 2004 09:18:38

Just to reinforce what has been said, I've never had any trouble re-reading my old Perl code, except when I mucked with overly complex data structures I didn't document. The code itself has always been a downright pleasure to read. I can't say that about Java. But then, I spend a lot of time actually using the linguistic freedom Perl grants me, trying to express things in such a way as is closest to how I think about the problem I'm solving. I don't just throw down the first construct that comes to mind. I also spend a lot of time arranging and rearranging code to properly divide it into self-sufficient functions and modules that do everything they should, but not more.

I see a lot of code in all kinds of languages that is horribly written, because the authors seem to simply have taken the first thing that came to mind which they thought would work and then ran with it. Too little abstraction, too much abstraction, bizarre distribution of responsibilities — most code is a mess. Questioning your first approach before you start and then questioning your chosen approach as you go about, breaking the problem down properly, possibly over and over again as you learn more about it, is vital. Refactor mercilessly or choke on your own spout.

Now Perl does not protect you from yourself as other languages try to. As a result, people hurt themselves. It's a poor craftsman who blames his tools, though. Most other languages “protect” you from expressing yourself too well, also. As someone who is extraordinarily particular about concise and coherent expression, I deeply resent that. And even so they still can't prevent +42 pretzel logic of extreme perplexity, as anyone who has seen large VBA macros can testify.

[reply] [top]

---

[»] perl 6.. day late.. dollar short
by Hohlraum - Oct 16th 2004 14:48:17

I wish perl was still a viable programming language. I've been doing nothing but perl programming (web application development) for the last 8yrs. I'm ready to say good bye. Maybe I'll come back once perl 6 is stable and attempts to offer stuff on the same playing level as Java.

I really think (as sad as I am to say that) that perl has seen its end in enterprise web application development. I think it comes down to perl's lack dependable frameworks. The ones that are out there, I don't even really consider all that professional. Mason, not a framework, you have to do 90% of the work yourself. Maypole, where is the documentation and have you looked at the templates? Dear lord. Another thing is finding people to hire to do the work. Its taken progressively longer everytime we've had to hire a new programmer. No one programs in it anymore.

I am lazy, i hate learning new programming languages. Java is bloated and slow and we're going to have to completely rework our architecture to support java. What other choice do we have? Right now it looks as though we'll probably move to Struts.

[reply] [top]

[»] Re: perl 6.. day late.. dollar short
by Warren Young - Oct 18th 2004 17:45:44


> I think it comes down to perl's lack
> dependable frameworks.

Apache::ASP.


> Another
> thing is finding people to hire to do
> the work. Its taken progressively
> longer everytime we've had to hire a new
> programmer. No one programs in it
> anymore.

Translation: we're unwilling to train people.

Though I must say, if you use Apache::ASP, retraining a VB ASP user shouldn't be a major deal.

[reply] [top]

---

[»] Re: perl 6.. day late.. dollar short
by Moe Aboulkheir - Nov 4th 2004 04:15:15


> Java is bloated

> and slow and we're going to have to

> completely rework our architecture to

> support java. What other choice do we

> have?

Python?
Bloated? Nope
Slow? Nope
as powerful as java and perl without the performance issues, and the ridiculous syntax, respectively

[reply] [top]

---

[»] Re: perl 6.. day late.. dollar short
by Aristotle Pagaltzis - Nov 19th 2004 07:57:37


> Another thing is finding people to hire to do
> the work. Its taken progressively
> longer everytime we've had to hire a new
> programmer. No one programs in it
> anymore.

Start hiring people, not technologies.


> I am lazy, i hate learning new programming languages.

Maybe you should. Good programmers learn a new language every year or so and write a piece of non-trivial code in it, just to keep sharp. If you don't know at least a half-dozen very dissimilar languages (no, Java, C, C++ and Pascal do not qualify as different, they're all ALGOL descendents) then your programming horizon is pretty narrow. You should at least know declarative and functional programming besides imperative. (OOP is a style on top of the programming paradigma, not a paradigma of its own.)

[reply] [top]

---

[»] Perl 6 is needed
by Alien Science - Oct 16th 2004 09:10:13

I've been programming perl for the last 8 years (maybe longer, I can't remember) and while I am very happy with the language I'm seeing it being displaced by Java in a very big way and perl is now becoming a niche language for sysadmins. I'm my opinion this is a shame because perl 5 is a very powerful language that allows a careful programmer to come up with very solid, maintable solutions.
However, perl 5 has issues (for some people) and perl 5 lacks some really cool features. I have played with ocaml and lisp and have been won over by the usefulness of language features that I didn't understand at first. Other perl programmers are raving on about ruby and like the consistancy of that.
Perl 5 is going leave the mainstream -- I am certain of this. Perl 5 + extras does not stand a chance. I would like to see perl 6 take its place as it is something that is developed by the community, moves language design forward and answers some of the criticisms of perl 5. Combined with the ecosystem that is parrot and the ability to share modules between languages, I am hopeful that this will actually happen or that a better language will evolve. My biggest worry isn't that perl 6 will be too radical, its that perl 6 will be too late.

[reply] [top]

[»] I've never seen such a stupid and short-sighted article before in my life
by Christophorus - Oct 16th 2004 06:14:20

Cleary the author is a troll who never wrote a computer program certain that he wouldn't need "all this programming crap" for his "real job". That is, assuming he got a degree in something remotely technical, which I very much doubt. Go back to tech support buddy.

[reply] [top]

[»] Re: I've never seen such a stupid and short-sighted article before in my life
by CropCircleSystems - Oct 16th 2004 14:49:59

i second that. i couldnt have put it better myself. this guy obviously is an amateur perl tinkerer at best. while i agree that perl5 is an awesome, powerful language with a billion and one uses and years and years and years of life left in it, but to ignore its shortcomings is plain ignorant. this guy may hack USING perl, but he obviously has never hacked ON perl (by which i mean modifying/extending perl itself), which i cant say i have either, but then again you dont hear me whining about things i dont understand, and claiming i know how perl should evolve better than larry does. and while i dont hack on perl itself, i have used perl enough to have experienced and understand the shortcomings for which people believe it should be overhauled rather than augmented, and why it is loosing ground to some of today's modern languages. perl6 will be sweet. i am keeping an eye on it and will thoroughly study its once it solidifies more/is released. and i will gladly spend company money to have my programmers learning it on the clock. (i find that a good programmer should always spend half or more of his time learning, and enforce that with my team. otherwise they get rusty, and/or only try and capitalize on what they already know or get closed minded about what they dont understand. <clears throat loudly while glaring at author of said article>)

[reply] [top]

---

[»] Re: Perl should be kept simpler
by Melvin - Oct 17th 2004 20:12:46

I think the article has some good points I Agree on like Perl 5 is complex enough to be making it worse, the sendmail analogy is perfect example of a software being replace by simpler apps, there should be a rule most programmers should remember: Keep it simple

In fact, I remember I stared at Perl for the need of CGI for the web but now I rather use an embedded language like PHP or ASP.Net for this job cause Perl is way too complex for some tasks (obviously more powerful, but in many cases unneeded).

In other hands, who cares if I don't understand at first Perl 6 (which in fact doesn't look this way), in most cases I didn't understand languages like C++ or Java when I first was them, but the best part was getting to know them and making my own libraries.

Backwards-Compatibility is maybe a "curse of software design" but not only programming languages have to be written from scratch, also in many cases the applications made with them too. I think there is something really wrong about the way we are getting programming languages if every time a major one comes up, is not compatible at 100% with the previous one. Maybe is something we should live with but it sure bites me.

I think also, that if Perl 5 can live on the same machine with Perl 6, we can have a powerful environment with more tools.

[reply] [top]

---

[»] It doesn't matter!
by Per Wigren - Oct 16th 2004 05:46:39

Most of the things you are complaining about doesn't matter because of Parrot. Parrot will let you use Perl5-modules in Perl6, Perl6-modules in Perl5, and even modules from Ruby, Python, PHP or any other language supported by Parrot in Perl5/6 and vice versa.

I think this is wonderful! You can go straight to the IMHO most beautiful language Ruby instead of Perl 6, and still use your old Perl-code with no need to rewrite.

--
hippie2k:~$ sed s/war/love/g

[reply] [top]

[»] You didn't give enough emphasis on Parrot.
by zentara - Oct 16th 2004 03:37:01

It's hard to "teach old dogs new tricks". I'm one of them. I've learned Perl5, and dread the coming change over. But I can see the benefit of switching to the Parrot Virtual Machine at http://www.parrotcode.org. The Parrot virtual machine, is sort of a virtual assembler which is cross platform. This will allow the programmer to think in new , cleaner ways about pushing data around with a processor. It is the future.

Perl6 will have a backwards compatibility mode for Perl5, and there will be nothing keeping you from using Perl5 for the rest of your life. Perl5 and Perl6 can be run on the same machine together. Perl5 will be around and will be continually developed for years. So don't worry about being forced into using it.

Perl6 ( and Parrot) will make it possible to write code which mixes languages in the same script, like Perl with some Python thrown in, or Python with some Perl thrown in.

Finally, there is nothing stopping you from making a separate branch of Perl6, and if people see it's benefit.....you may become the next Larry Wall.

[reply] [top]

[»] second system syndrome
by geoff lane - Oct 16th 2004 02:03:02

Although it's called perl6, to an outsider who occasonally reads the reports on Perl.Com, the perl developers seem to be suffering from "second system syndrome". That occurs when a successful project moves on to develop a major new release where they can "fix" all the mistakes of the previous project and expand into new areas.

It's often an expensive mistake.

[reply] [top]

[»] My feeling
by verbat - Oct 16th 2004 01:59:15

Is that you don't understand perl6.
You really can't see why having named arguments is better than using @_ ?
You don't see MMD as useful so you don't want it. You don't want a seriuos OOP framework cause you don't have a clue on how to use it. perl6 regexen are something new (not harder then perl5's but new) so you'd prefer the others.

But imo this is just an example of blub paradox, is like writing "I mean, perl5 does not really need closures let's all use perl4"

[reply] [top]

[»] Re: My feeling
by Shlomi Fish - Oct 16th 2004 04:44:41


> Is that you don't understand perl6.

You are right - I don't understand a great deal of the Perl 6 apocalypses and Exegesisa. And I'm not ashamed to admit it, because I know most other people don't.


> You really can't see why having named

> arguments is better than using @_ ?

Not really, no. What's wrong with:

my ($self, $name, $family_name, $street) = @_;

Besides, if we want to add these things, I don't think we should start with a clean page, but rather add them to Perl 5 incrementally while maintaining backward compatibility.


> You don't see MMD as useful so you don't

> want it.

What's MMD?


> You don't want a seriuos OOP

> framework cause you don't have a clue on

> how to use it.

Actually, I specifically said a better OOP framework is in order, just that it does not justify an entirely new language with . for dereferencing and _ for concatenation.


> perl6 regexen are

> something new (not harder then perl5's

> but new) so you'd prefer the others.

>

They're new and they are incompatbile. That's the problem.


> But imo this is just an example of blub

> paradox, is like writing "I mean,

> perl5 does not really need closures

> let's all use perl4"

Perl 4 was problematic from several reasons. Perl 5 is much better. However, nothing justifies Perl 6 right now, because Perl 5 is good enough.

There isn't a need to revolve Perl at the moment. You can add all these things to Perl 5 without revolving it.


[reply] [top]

---

[»] Re: My feeling
by michal_321 - Oct 16th 2004 06:05:39

%

> You are right - I don't understand a

> great deal of the Perl 6 apocalypses and

> Exegesisa. And I'm not ashamed to admit

> it, because I know most other people

> don't.


It's just Larry. That's the way he presents things. I personally think that he's got a really good grip on it.
I'd recommend reading Apos with Exegesisa companion.


> Not really, no. What's wrong with:

>

> my ($self, $name, $family_name, $street)

> = @_;


An easy one. To quote Larry:

Perl 5's subroutines have a number of issues that need to be dealt with. First of all, they're just awfully slow, for various reasons:

Construction of the @_ array
Needless prepping of potential lvalues
General model that forces lots of run-time processing
Difficulty of optimization
Storage of unneeded context
Lack of tail recursion optimization
Named params that aren't really
Object model that forces double dispatch in some cases

Quite apart from performance, however, there are a number of problems with usability:

Not easy to detect type errors at compile time
Not possible to specify the signatures of certain built-in functions
Not possible to define control structures as subroutines
Not possible to type-check any variadic args other than as a list
Not possible to have a variadic list providing scalar context to its elements
Not possible to have lazy parameters
Not possible to define immediate subroutines (macros)
Not possible to define subroutines with special syntax
Not enough contextual information available at run time.
Not enough contextual information available at compile time.



> Besides, if we want to add these things,

> I don't think we should start with a

> clean page, but rather add them to Perl

> 5 incrementally while maintaining

> backward compatibility.


Perl6 is a new language. Andf there will a backward compatibility mode.


> What's MMD?


Multi method dispatch.
See somedictionary


> Actually, I specifically said a better

> OOP framework is in order, just that it

> does not justify an entirely new

> language with . for dereferencing and _

> for concatenation.


OK. But that's "syntactic sugar", that's what it is ;-)


> Perl 4 was problematic from several

> reasons. Perl 5 is much better. However,

> nothing justifies Perl 6 right now,

> because Perl 5 is good enough.


Mostly. But starts to be obsolete rig th now.


> There isn't a need to revolve Perl at

> the moment. You can add all these things

> to Perl 5 without revolving it.


No. Perl5 won't match capabilities of python and/or java in near future.


[reply] [top]

---

[»] Re: My feeling
by Ambrose - Oct 16th 2004 08:51:13


> % There isn't a need to revolve Perl at

> % the moment. You can add all these

> things

> % to Perl 5 without revolving it.

>

>

> No. Perl5 won't match capabilities of

> python and/or java in near future.

>

Now this is a mysterious statement. In what way is Java more capable than Perl5?



[reply] [top]

---

[»] Re: My feeling
by Ted Zlatanov - Oct 18th 2004 10:10:40


> Now this is a mysterious statement. In

> what way is Java more capable than

> Perl5?

>

Introspection.

[reply] [top]

---

[»] Re: My feeling
by perlvr - Oct 17th 2004 08:11:37


Honestly, I think PERL 5 is just fine the way it is. Yes, parrot is sexy, but I groaned when I saw the syntax changes. The old "for notation" has grown on me. And, in math, the "element of" symbol is always on the lhs. The new notation reminds me of my TI calculator which uses "store this into" rather than "store this in."

As far as speed is concerned, that's something that I don't care much about since it's "fast enough."

I recently wrote a custom COFF linker in PERL and it worked just great and more than fast enough.

My favorite function is pack and unpack and along with PERL 5 I'm quite happy.

If people want to use a different syntax, I have no problem with having them place "use perl6;" at the top of their PERL code. Otherwise, the PERL6 compiler, IMO, should be backwards compatible with PERL5 from the viewpoint of the user.

I like PERL because it's quick and I can rapidly prototype. If PERL6 adds baggage, then we'd want something like this: "use nobaggage;"

I program in C++ a lot and have just as many run time problems as PERL.

C++ programmers think they can save themselves with auto pointers, and the such, but at the end of the day, that sort of thing only leaves me with a headache and yelling at the people who use expections as a way to avoid real error checking.


>

> An easy one. To quote Larry:

>

> Perl 5's subroutines have a number of

> issues that need to be dealt with. First

> of all, they're just awfully slow, for

> various reasons:

>

> Construction of the @_ array

> Needless prepping of potential lvalues

> General model that forces lots of

> run-time processing

> Difficulty of optimization

> Storage of unneeded context

> Lack of tail recursion optimization

> Named params that aren't really

> Object model that forces double dispatch

> in some cases

>

> Quite apart from performance, however,

> there are a number of problems with

> usability:

>

> Not easy to detect type errors at

> compile time

> Not possible to specify the signatures

> of certain built-in functions

> Not possible to define control

> structures as subroutines

> Not possible to type-check any variadic

> args other than as a list

> Not possible to have a variadic list

> providing scalar context to its

> elements

> Not possible to have lazy parameters

> Not possible to define immediate

> subroutines (macros)

> Not possible to define subroutines with

> special syntax

> Not enough contextual information

> available at run time.

> Not enough contextual information

> available at compile time.

>



[reply] [top]

---

[»] Re: My feeling
by Kreiger - Oct 19th 2004 08:43:04

The language is "Perl" or "perl", not "PERL". It is not an acronym.

[reply] [top]

---

[»] Re: My feeling
by Humberto Massa - Oct 22nd 2004 08:37:43


> The language is "Perl" or "perl", not

> "PERL". It is not an acronym.

>

You mean it's not Practical Extraction and Reporting Language?

[reply] [top]

---

[»] Re: My feeling
by Sam - Oct 24th 2004 01:02:44

No it's not as a cursary look at the perlfaq documentation would tell you.

[reply] [top]

---

[»] Re: My feeling
by motivator - Oct 16th 2004 14:45:01


>

> Perl 4 was problematic from several

> reasons. Perl 5 is much better. However,

> nothing justifies Perl 6 right now,

> because Perl 5 is good enough.

>

i think you're ignoring the major point already made in one of the responses. you can use perl5 and perl6 on the same machine until the end of time, if you like, so what's the problem with creating perl6. just because you think perl5 is "good enough" doesn't mean perl6 isn't worth creating.

[reply] [top]

---

[»] Re: My feeling
by CropCircleSystems - Oct 16th 2004 15:02:53


> Not really, no. What's wrong with:

>

> my ($self, $name, $family_name, $street)

> = @_;

well for one, you are copying variables when all you want to
do is label your parameters.


> Perl 4 was problematic from several

> reasons. Perl 5 is much better. However,

> nothing justifies Perl 6 right now,

> because Perl 5 is good enough.

"good enough"??? yeah. thats the attitude that promotes
greatness and makes things happen in the world. go back to
being a small cog of the machine to which you are a slave.

but seriously though, i agree with you that changing . to _
and -> to . was pointless, and i agree with you that it may
deserve a whole new name rather than saying its the 6th
major version of perl, as it is an entirely new language.
however, i believe the implications of the naming have
already been considered more than i am considering them,
and i really dont care what you call it. a rose by any other
name...

[reply] [top]

---

[»] Re: My feeling
by Juerd - Oct 30th 2004 12:33:57


> but seriously though, i agree with you

> that changing . to _

> and -> to . was pointless

The string glue is now called ~, not _.

-> to . makes sense in many ways. Dot is easier to type (it's only a third of the key presses), and is nicer when used without a LHS. Besides that, -> is now a neat new operator that you will learn to appreciate. It creates a closure with named parameters, and is not just syntactic sugar for loops.

The underscore is a great tool for telling apart people who read some early documents and couldn't get over the initial shock and people who are really interested in the new language.

--
Blaaat :)

[reply] [top]

---

[»] Re: My feeling
by perlysoames - Jan 6th 2007 22:27:51

Well, we're in 2007 now. Perl6 still isn't finished and if you take a look at the discussions it pretty obvious that it has a loooong way to go. The people working on it (at least some of them) are pretty smart -- that they can't make progress is an indication that the language is too complicated and early decisions were ill-informed.

No one wanted parrot, we wanted simple, well-understood, mainstream language features like functions with named parameter lists.

Against my better judgment, on the advice of a true believer I've been waiting five years for Perl 6. No more. Larry Wall promised us something by Christmas but all we've had is silence.

It's time to throw in the towel guys. Cut your losses, add a few badly needed features to Perl 5, call it Perl 6, and be done with it. I wish I could make this come across better; the Perl 6 people are a bright bunch trying to do a great thing, but it just isn't happening and there comes a point when a change in course is necessary.

[reply] [top]

---

[»] Re: My feeling
by FernandoGonzalez - Mar 23rd 2007 22:00:13

Yes, it does have a long way to go but consider where it's heading. Some of the things that will be incorporated into the language are still being researched and developed. Make no mistake, when it's done it'll be the most advanced language ever seen.

"Will it be complex?"

Sure, some things will be different. But as many of you have pointed out, writing some real apps with a language straightens out all the kinks in your brain, or at least, goes a long way.

Take Haskell, a very powerful language with which the Pugs perl6 interpreter is being built. Oooh, monads, type classes ... Believe me, that stuff is scary at first, especially with all the people going around whining, "What are monads? What's category theory? Do I need to study math to code?". Just write some code. No math required. Monads: no big deal. The let you keep track of what's going on and when. Type classes: you'll love these, they're a nice generics mechanism. Believe me, you'll get it and you'll love it.

The clarity and coherency of Haskell's design will shine through after an indeterminate number of lines of code. I suspect the same will happen to those choosing to move to perl6. Reading a spec 20 times won't make you grok any language. It's mileage on the keyboard that really counts.

"So, uh, will it be complex?"

No.
The whole point of the new language is to take what was perl5 and make it cleaner, more powerful and beautiful.

"Should I wait for perl6?"

What the Hell? What kind of self-respecting hacker waits for anything?

You've got perl5, right? If you like it, use it. If you think it should be better, contribute.

As for perl6: If it's taking too long for you, go to the pugs website and lend a hand.

Simple. If you don't contribute, don't complain. Perl can be what you want it to be.

Fernando

[reply] [top]

---