Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

How to Sell Perl 6

by Ovid (Cardinal)
on May 04, 2004 at 07:05 UTC ( [id://350254] : perlmeditation . print w/replies, xml ) Need Help??


How to Sell Perl 6


With a beta of Perl 6 probably being less than two years away, many of us wonder about its future. I'm optimistic. While I've been paid for programming in other languages, I specialize in Perl. I know it well, I'm comfortable with the language and I'm so excited about the new features of Perl that I, like so many other programmers, am eagerly awaiting the opportunity to take her out for a spin.

My other motivation may seem a bit strange, but I have a strong loyalty to the Perl community. The language certainly has its quirks, no doubt about it, but it's you, the community, which makes it worthwhile. You've taught me how to program. Before, I was your typical hack. Now, by engaging with the community, learning from some very bright individuals, and spending a lot of spare time dabbling on YAUP (Yet Another Unfinished Project), I've learned quite a bit about computer science, project management, and fatter paychecks. You've taken me overseas and across the country. In short, you're great. You're also in a bind and that bind is Perl 6.

(There are some comments in the following that might be viewed negatively, so I don't name the people associated with them. They can out themselves if they choose -- assuming they're on Perlmonks)


My goal in this is to start some discussion about the future and maybe figure out where Perl is headed, where we want it to go and what it will take to get it there. I'm not a leader in the Perl community and I don't claim that participating in this discussion will have any great benefit, but I hope it might just spark a few ideas and perhaps allow individuals to better plan for their professional future.

The ``No Rewrite'' Fallacy

This is almost a side issue, but I've heard it enough that I've felt it worth addressing. Many of you, by now, have heard the ``never rewrite!'' mantra. Joel Spolsky argues it passionately, chromatic seems sold on the idea and Netscape hung itself by ignoring it. In fact, despite once being skeptical, I now agree that scrapping any sufficiently large program and rewriting it from scratch is usually the kiss of death.

Perl 6, so far, seems to have avoided many of the ``no rewrite'' problems by still having a robust, useful product available during the rewrite. Perl 5 is still being actively upgraded and the Perl 6 development process has led to a burst of Perl 5 activity. This has maintained interest in Perl and has given us a position that many ``for profit'' firms can only envy. Thus, I think those who predicted doom due to a complete rewrite were wrong, but they can hardly be blamed for said prediction. It's right more often than not.

The Fear of Perl 6 and Why It Had to Happen

Many people seem to be afraid of Perl 6, though. Some major players in Perl have publicly stated that they see no reason to switch to Perl 6 when it comes out. At least one has recanted (that I know of), but others feel that the new Perl won't be Perl.

Yet another person has told me he's scared to death of Perl 6. His business is heavily dependent on Perl 5 and the upcoming Perl 6 puts him in a curious position -- which Perl does he market? Trying to market both might be a disaster, but switching horses at the wrong time could be even worse.

In fact, your author once considered switching to Java due to fears about the Perl market collapsing. Now, I have a great, stable job, but I do know I'm in a smaller pond than some other languages. Perl 6 may turn it into a lake or a puddle.

Perl 6 had to happen, though. Perl's very popularity started showing its weaknesses. The limits of Perl typically mean that larger projects require more highly skilled, expensive programmers to use it effectively and this can tremendously reduce the supply of developers (moreso, I would suggest, than some other languages). Companies that didn't understand this would hire less skilled developers and possibly conclude that Perl itself was a bad idea; programmers are loathe to admit (or recognize) they're the ones to blame.

For example, when working on small projects, we don't worry too much about the fiddly bits -- how often do you need a linked list in Perl? That frees the programmer to think about the problem rather than the implementation. Unfortunately, when working on large projects, you often have to pay more attention to those fiddly bits than you would in, say, Java. Want to subclass Class::MethodMaker to allow chained mutators? If you do, you have to dig into the guts of the module. Newer versions of this module changed an internal scalar to a hashref and this broke code that happened to override the _make_get_set method. You subclass this module at your peril.

A more common example is simply subclassing anything. If the parent class implements an object as a blessed hashref that's pretty much what you're going to do, too. Now, however, you not only need to know what data structure it's using, you have to know the names of the keys. But it gets worse! You also have to know the names of private subs that should not be accidentally overridden. Not knowing those implementation details can make life very difficult.

There are plenty of other issues we can point out about Perl 5, but it's still a pretty darned good language. Perl 6 builds on the strengths of Perl 5, fixes the problems that were there and offers bucket loads of programming goodness -- while still making easy things easy. Sticking to Perl 5 would have made that tough.


So the question remains, whither Perl 6? Will it wither (ha!) on the vine or will it bear sweet, paycheck laden fruit? (OK, I never claimed my analogies were great.) Really, it boils down to two simple concepts: supply and demand.


If there is no Perl 6, no one can choose it. When a company is considering a programming language, two of the most important things they look at are the supply of software packages for it and the supply of developers. Almost universally, a new programming language initially has an adoption lag while companies wait to see if it's going to be supported. Fortunately for Perl, backwards compatibility has been a serious goal and and Project Ponie, sponsored by Fotango (go, Arthur, go!), has the potential of allowing most Perl 5 code to run unmodified. This will be a huge boon. If successful, the supply of software packages supporting Perl will simply not be an issue.

Developers, however, are another issue. If there are few Perl 6 developers, companies will be very reluctant to switch. Ponie does not solve this problem. Even if you urge your company to switch to Perl 6 on the basis that your developers can write in Perl 5, the obvious question is ``then why don't we stick with Perl 5?'' Of course, if your company's never used Perl in the first place, it's an even harder switch. Programmers are going to have to knuckle down and learn the new language and convince the market that there are enough of them out there. Perl 6 is relatively easy to learn if you already know Perl, but we need to start now rather than wait to see how things are going to play out.


Demand is the tough part. Demand is closely tied to price. Perl, despite the popular misconception, is not free for a company. They have to hire developers. The salaries they're willing to pay are often based upon the perceived return on investment. This means that the Perl community needs to convince management that Perl 6 will save them even more money than Perl 5. Coroutines are nice, but your boss doesn't care. She also might not care that you can easily interface Perl 6 with other languages. If they're so great, why aren't we using them instead of Perl?

Part of the problem here lies in how Perl is explained. If we say ``Perl 5 wasn't very scalable but Perl 6 is,'' then we've just blown much of the benefit of the CPAN and Ponie. Oops! However, this seems to me to be one of the biggest benefits. I used to say ``Java's safe and Perl is powerful.'' With Perl 6, I think we'll get both, but it can be tricky to explain. Further, as a matter of ethics, I think it would be wrong for any programmer to pitch Perl 6 just because it's Perl. We have to have good, solid reasons for why Perl 6 is the next best thing.

Unfortunately, we don't have Sun's marketing budget. Buying full-page color spreads in magazines they read is probably not going to happen. We'll likely continue in the same "word of mouth marketing" style that built Perl in the first place. While this isn't necessarily bad, it's less likely to have the impact on the decision makers.

I think the way to go is to continue to hammer on the speed of development and the resulting cost savings. There's no way a C++ developer is going to build a large application as fast as you will with Perl 6. What? He's got strong typing? So does Perl 6, if you need it. Java has a better OO model? We can debate that with Perl 5, but not, I think, with Perl 6. Further, while Perl 5 was fast enough for many business needs, Perl 6 promises to be faster still and dropping to Parrot assembly or even C, if necessary, is a snap.

Convincing programmers might be even easier. Management usually has the final say in what technologies to adopt, but the techies have influence, if you can sell them. You need procedural programming? Check. OO programming? Check. Functional programming? Check. Logic programming? Check (OK, some might quibble at the last two.) You need a domain specific language? It turns out to be pretty easy. On top of all of this, it turns out to be even easier to learn than Perl 5 (which really isn't that hard once you get over the sigils) and offers them power that few other languages can touch.


I think Perl 6 is going to be big, largely due to Parrot, but also due to some great design choices. I can't say I agree with all of them, but hey, who does? However, Perl 6 is not going to be big unless we can boost demand. That means having plenty of programmers available to mitigate the supply problem and convincing the decision makers that Perl 6 is the answer to their prayers. The latter might be easy, but techie types often don't speak the same language as the business types, so this is up in the air.

So think about Perl 6. Read the Exegeses (and the Apocalypses), subscribe to a Perl 6 list or two and consider what it will take to turn Perl 6 into the next killer app.


New address of my CGI Course.

Replies are listed 'Best First'.
Re: How to Sell Perl 6
by Abigail-II (Bishop) on May 04, 2004 at 09:13 UTC
    Perl 6 had to happen, though.
    Really? Perl6 has been worked on for four years now, and it's probably going to take a few years before it's production ready. Has Perl5 shown any signs of dying since then? 5.6.0 was just released when work started on perl6. We're now on version 5.8.4, with releases sceduled 4 times a year. Work is progressing on 5.9.x, eventually resulting in 5.10. As Arthur was saying to me on the last Nordic Perl workshop, "Perl5 is dying. There are 14 Perl conferences this year". 14 conferences. About an existing product that's doing fine.

    Perl5 has been doing the job for me for years. 95% of the Perl code I've written in the past 9 years will not be valid Perl6 - normal, everyday code. I see no reason to "sell perl6". I don't even want to buy it.


      Would there be 14 Perl conferences this year without the shot in the arm Perl 6 provided? Would there be a Perl 5.8.4?

      I don't know, but I think there's a correlation.

        I'm fully convinced that if there wasn't a perl6 effort, we'd now been seeing maintainance releases for 5.10 with a 5.12 looming on the horizon.

        As for whether there would be 14 conferences without perl6, I don't know. Is there any Perl conference this year which is mainly about perl6? The last conference I attended had three perl5 and perl1 pumpkin, but no perl6 pumpkins. It had a large talk about perl5 development, but not about perl6.

        I've two more conferences to go to this year, I'll see what's happening there.


      The rhetorical question that I pose to you is: what makes it less than desireable for you? I'm sure that there were those who said the same during the Perl4 -> Perl5 migration; arguments that we see today as either crusty or silly. I'll admit that I'm not up on Perl6 at all. I see no reason to learn a language that won't see the light of day for a couple of years. Heck, I don't even know that the specification is done. So part of this question is asked in ignorance. What kind of code that you have written today breaks tomorrow?


        What kind of code that you have written today breaks tomorrow?
        • I use hashes, and I index in them.
        • I use subroutine/method calls on the LHS of binary operators.
        Almost all of the code I write uses one or both of the items I mention. All of that either becomes invalid, or changes meaning.

        my %hash; $hash {key} = "foo"; # Illegal in Perl6, even after s/\$/%/ my $str = "99 miles to L.A."; print length ($str) + 1; # Prints 17 in Perl5, 3 in Perl6.

        This is very basic stuff to write, which I do many, many times in code (and I guess many people use hashes, and use subs/methods in expressions).


        Although I disagree with his conclusion, I have to agree with his statement. Most of my code will break under Perl6, too. The Perl5 -> Perl6 ease-of-migration stuff is for the simpler uses of Perl. Once you start getting into symbolic references and symbol table manipulations and beyond-the-surface objects ... this isn't going to migrate. And, I know that if I'm doing that stuff, Abigail-II is definitely doing it.

        Additionally, every single bit of XS is going to have to be rewritten. Granted, it gets to rewrite it in Parrot which is much nicer, but it's still a big task. Ponie may or may not help this part.

        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      Out of curiosity, what's your main objection to Perl 6? I've read repeatedly where you've stated that you're not keen on the language, but I've never quite figured out why. I assume it's nothing as simple as "comfort level" simply because you strike me as being more thoughtful than that. Could it be that you think Perl 6 won't catch on? Do you feel that Perl 5 is technically superior to the (admittedly non-existent) Perl 6 or that Perl 5 will be easier to use? Is it a "wait and see" attitude? I suppose it's probably something else entirely.

      What I read is "I won't use Perl 6 because it's not Perl 5," but I'm pretty certain that I'm misunderstanding you.


      New address of my CGI Course.

        I won't speak for Abigail-II, but I object strongly to the whitespace rules that were shown in A12. I know Abigail-II has objected to the hash index whitespace restrictions in earlier Apocs, but they didn't bug me so much. The method lookups are a different story.

        I also think the A12 whitespace restrictions highlight a problem that has always been there but few, if anyone, have ever noticed. In an awful lot of programming languages, parans are used both for grouping and for function calling, this being a relic of mathmatical notation. VB makes it even worse by using parens for array indexing.

        I think we should come up with a completely different notation for these concepts, though I'm baffled as to what that notation should be. Perl6 is already crawling into Unicode to fill in the need for an increasing number of operators, and I'm not too fond of that, either.

        : () { :|:& };:

        Note: All code is untested, unless otherwise stated

        Out of curiosity, what's your main objection to Perl 6?
        My main objections? Definitely its sensitive whitespace rules. It wouldn't be so bad if it was for some cases which didn't happen that often. But indexing and method/subroutine calls? That will effect about every other line of code. That would require a massive change of coding style - a style that I've been using for two decades. And for what? That we might leave off parenthesis every now and then.
        Could it be that you think Perl 6 won't catch on?
        Probably as much as perl5 is. Perl isn't a big language like C or Java are - I don't expect perl6 to make Perl "bigger". But within a few years, perl5 will be as common as perl4 is now. But I expect that to happen if we name 5.10 "perl6" as well. People have a tendency to use products with the highest number anyway, perl5 will get the name to be unsupported (whether it is or isn't doesn't matter), and publisher seeing they can sell more "perl6" than "perl5" books will do the rest.
        Do you feel that Perl 5 is technically superior to the (admittedly non-existent) Perl 6.
        That I would find unlikely. However, I do feel that the perl6 project has been a drain on perl5 development. Not only because some people stopped working on perl5 development, but also of the attitude "why bother implementing, let's wait for perl6". We'll never know where perl5 would have been if there wasn't a perl6, but I'm sure it would have been much further than it's now.
        Perl 5 will be easier to use?
        For me, perl5 will be much easier to use. For others, I do not know. Perl6 syntax appears to be even richer than perl5s, so I presume the learning curve for perl6 will even be steeper than for perl5. (Yes, I know you can get by by knowing only part of the language - but that's not a luxury every maintaince programmer has - and that's how many programmers start, and that's also how the open source movement works).

        I'm not going to argue that there's nothing good about perl6. It has lots of interesting features. But I think the price is too high. For me personally, the whitespace rules aren't worth it. For perl itself, I'm not convinced the years it has taken so far, and the years it still might take will be worth it.


Re: How to Sell Perl 6
by tilly (Archbishop) on May 04, 2004 at 18:28 UTC
    Don't try to sell Perl 6. It is way too early.

    The first step is to have Parrot and Ponie hit maturity. Then sell Ponie as a free speed increase with an amazing ability to reuse libraries written for other languages. Yes, there will be conversion bugs, but they're managable.

    Once people have converted to Parrot, then begins the Perl 6 conversion process. If it is as productive as people think it can be, that process can start with people writing modules in Perl 6 rather than Perl 5. Companies may find themselves using the Perl 6 modules without needing to use Perl 6 directly. Once you have enough modules like that floating around, there is a direct incentive for people to learn Perl 6. Or to use it for internal projects. And then the language can begin to grow.

    However the details of how that goes can wait. The first step is getting Parrot and Ponie to a point where we can convert people to Ponie. Then we can start creating a clear value proposition for Perl 6.

Re: How to Sell Perl 6
by hardburn (Abbot) on May 04, 2004 at 13:24 UTC

    IMHO, the Next Big Thing in the Perl community isn't actually Perl, but Parrot. This isn't necessarily because it's easy to interface with other languages. In fact, some companies will, at best, completely ignore that feature. My current employeer rejected one of my proposals that used XML for a small database on the basis that XML would be one more thing our developers have to understand. I don't think they'll be keen on the idea of interfacing with a half-dozen languages that are actually Turing Complete.

    What Parrot will allow is the creation of simple domain-specific languages. We can get around companies like my own by "marketing" this as simply "Parrot skills" instead of listing off all the mini-languages being used. This is a massive simplification of the truth (though I wouldn't call it an outright lie), but PHBs already do that a lot.

    If Parrot becomes big in this regard, then there will be a large demand for people who can write compilers for these little languages. This is not something I've done much of (name a parser: Bison, yacc, Parse::RecDescent, whatever else--I probably haven't ever touched it), but it's something I'm trying to learn now. Even if this predicted explosion in a need for compiler-writers doesn't happen, at least I've learned something new along the way.

    : () { :|:& };:

    Note: All code is untested, unless otherwise stated

      What Parrot will allow is the creation of simple domain-specific languages.
      Not just domain specific languages, but transition paths from dead-end languages as well. You write a compiler for the old language that targets parrot and rewrite the runtime library code for it, and then you're in a position to start migrating. That's what I'm doing now for work.

      Granted, this isn't the right answer in all cases--rewriting a runtime library to maintain compatibility can be a major undertaking. In many cases, though, it's easier to write a new compiler for an existing code base that targets a back end with more potential than it is to port the entire code base to a new language. (Writing compilers and their associated runtimes is a lot of work. Rewriting full application systems are often significantly more work, though, with more risk and expense)

      I'll put the ObPlug here for part one of an article I wrote for OnLamp about this, but targeting parrot's not that tough.

Re: How to Sell Perl 6
by dragonchild (Archbishop) on May 04, 2004 at 12:25 UTC
    Personally, I'm not worried about selling Perl6. I can always argue on any project I'm on that it needs rewritten. (This has more to do with how I manage projects than anything else.)

    I fully plan on learning Perl6 as soon as possible and deploying Ponie wherever I am as soon as possible. Why? Because I plan on rewriting every class I have in Perl6 as soon as possible. I hate Perl5's OO system. With a passion. I cannot wait for A12 to become reality. So, whoever works with me will have to learn Perl6 as soon as possible. Period. (I'm lucky that I have a lot of clout over the Perl deployment wherever I am. *shrugs* YMMV)

    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      Why? Because I plan on rewriting every class I have in Perl6 as soon as possible. I hate Perl5's OO system. With a passion.

      I have this same view, only moreso. Not only do I fully intend on rewriting all my Perl OO stuff in Perl6 the minute I can get my hands on a working Perl6, but I have been actively avoiding writing some OO stuff that I would really like to write, because I don't want to write it in Perl5. I choose other paradigms. I use closures. I just put stuff off; if I can manage to procrastinate long enough, Perl6 will save me hundreds of hours of the needless painful toil that would be required to adapt the woefully inadequate Perl5 OO model to implement certain things.

      And it isn't just the OO model that's inadequate, either. If you hang out for two days in comp.lang.scheme (for example), you'll discover that Perl5 only supports very limited aspects of the functional programming paradigm. As a programmer totally sold on the value of the multiparadigmatic approach to programming (one of the chief advantages of Perl over other languages), I definitely look forward to having a broader range of functional programming functionality at my fingertips.

      And then there's the paradigm that's more-or-less the defining native paradigm of Perl, contextual programming. Kludges like "0 but true" only go so far; sometimes I need to be able to return a value that's "0" in string context but true in boolean context. And I'm tired of worrying about whether my numbers will overflow; strings don't; numbers shouldn't either -- they should automagically promote themselves to bignums as necessary.

      As a programmer, I eagerly await these features. The incremental improvements in Perl5 have mostly not interested me; the differences between 5.005 and 5.8.4 are to my way of thinking mostly not worth upgrading, and so I've only bothered when I upgraded whole systems, otherwise leaving an old version of Perl in place -- but when 5.6.0 is out, I'll be installing it (alongside of, not in place of, Perl5) the instant I can get my grubby little fingers on it. Threads? Who cares? We already have a perfectly cromulent fork builtin that doesn't create "thread-safety" issues. Unicode? I live in a small city in Ohio; Unicode is right up there with unicorns and fire-breathing dragons on the list of things I read stories about but don't actually have to be concerned about. The defined-or operator would be really nice, but to me it's not worth compiling my own perl and sacrificing all pretenses of compatibility. (Maybe it would be if I made extensive use of tied variables or lvalue methods that are not idempotent to evaluate, but I don't, so it's not.) But Perl6? I drool in anticipation. I want it even more than I wanted Emacs 21, when Emacs 20 was current -- and I compiled my own copy of 21.0.105 before it was technically released, and this was before I was really comfortable compiling software from source. Oh, yes, I'm looking forward to Perl6. I lay awake at night thinking about it.

      As far as selling management, I'm not convinced it will be a major problem. If management's already sold on Perl and the developers are sold on Perl6, they'll pitch it as a major and important upgrade to keep the company current with technology, and enough managers will buy that pitch that Perl6 will gain the momentum to become a dominant market force, at which point the more reluctant managers will start seeing stuff about it in trade magazines and whatnot. (When hosting companies all advertise that they provide Perl6 as a major feature, it'll get noticed, even by people who aren't in the market for hosting.) I think the hard part is selling a large percentage of Perl programmers on learning Perl6 and writing their code in it. There will be some early adopters such as myself, but I suspect a lot of otherwise very sensible people will resist learning Perl6 for months or even years, just because it breaks some Perl5-based expectations. (I must admit, the first time I saw the Apocalypse on regexes I wanted to shake the author and ask him what drugs he was on; later I read it again and started to understand better... I do still think making character classes harder is a mistake (not because of [A-Za-z] but because of amazingly common stuff like [0-9 .]), but rules more than make up for it.) I don't know a solution to this problem, other than word-of-mouth.

      ;$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}} split//,".rekcah lreP rehtona tsuJ";$\=$;[-1]->();print
Re: How to Sell Perl 6
by zentara (Archbishop) on May 04, 2004 at 13:30 UTC
    I've always seen Perl5 as an "user-friendly front end to C". C just has too many details to deal with day after day, and Perl5 takes care of all those details for you.

    Now to me, Perl6 is just taking this "user-friendly frontend concept" to the next level, where its a "user-friendly frontend to assembly". Anyone who has dabbled in assembly knows how "counter-intuitive" it is to think like a binary chip. The parrot virtual assmbler solves this by making "virtual registers" that take "human understandable" data like Integer, Float and string. This is real evolution in programming....finally the high-level programmer can think in terms of a CPU and registers. So that makes doing assembly-style routines, as easy and natural as can be.

    What I see is CPU manufacturers eventually making the parrot CPU(or a similar 'big-company clone') hardwired as a real chip.

    Perl6 is real evolution in computer language design and the way human-computer connection works. Even if it has great "birth-pains" as the "old-dogs" complains, it will make things so easy for future programmers.

    So I would sell Perl6 as "the innovative future", grab on for the ride, or stay with the old way until you fade away.

    I'm not really a human, but I play one on earth. flash japh

      What I see is CPU manufacturers eventually making the parrot CPU(or a similar 'big-company clone') hardwired as a real chip.

      No way. Parrot does things which simply aren't fesible in a physical CPU, like having a massive number of registers. Even a relatively static VM like the one Java runs on would probably be too dynamic to run in pure hardware easily.

      What can be done is optimize a CPU to run for the higher-level VM. There are already chips to run the JVM in exactly that way, and I wouldn't be surprised to see some for the .NET CLR, too.

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Re: How to Sell Perl 6
by talexb (Chancellor) on May 04, 2004 at 15:07 UTC
      With a beta of Perl 6 probably being less than two years away ..

    Perl 6 seems to be like a mirage, enchanting, beautiful, desirable .. and always retreating, retreating. The number I always hear is '18 months' when anyone talks about when it will arrive.

    I think the big change will happen when some of the key CPAN modules get ported or certified to Perl 6 compliant. Once we have modules that work, then we'll be able to write code that works. The corollary is that if there's no for Perl 6, there will be no Perl 6 CGIs.

    Perl sure is quirky, but that's because (like the English language) it has many forebears. When I started doing a little shell programming recently, I often had two thoughts, "Hey! This is like Perl!", followed by "No, Perl is like shell." My awk experience predated (and led to) Perl, so at least I got that order correct.

    I look forward to Perl 6 -- I made the transition from Assembler to C, and then from C to Perl (starting with the brand new 5.4 version). It won't be a language change, but it will definitely be a dialect change, but that suits, coming from a language designed by a linguist.

    Alex / talexb / Toronto

    Life is short: get busy!

      I don't blame you for being a little frustrated at how long Perl 6 is taking to develop. However, it's not Duke Nukem style vaporware. The proof of this is on the Perl 6 mailing lists and the regular Apocalypses and Exegeses. There's considerable development being made and anyone can see the progress. There are already several languages running on Parrot, the beginnings of SDL binding, OO is beginning to emerge (it would have emerged sooner were it not for the incorporation of traits, but that's a Good Thing), etc. Admittedly, this has almost made Mozilla development look speedy, but once it hits the ground, it's going to find its feet pretty quickly.


      New address of my CGI Course.

        I'm not really frustrated -- I think my attitude is more fatalistic. Perl 6 will arrive when it arrives. It's not vaporware -- it's just like a transporter beam that needs a bit of adjustment .. but I'm not worried about it.

        I do know I'm going to have to turn my dial from practitioner over a few notches to student as Perl 6 firms up. I'm wondering if the gods have considered starting up a Perl 6 section on PM, or even if that has been discussed.

        Alex / talexb / Toronto

        Life is short: get busy!

      The number I always hear is '18 months' when anyone talks about when it will arrive.

      Which reminds me of this old quote: "In a ten year period, we can have an superb programming language. Except we can't control when the ten year period will begin."

      The corollary is that if there's no for Perl 6, there will be no Perl 6 CGIs.

      Plenty of people will probably keep hand-parsing CGI params even after they're using Perl6. Or maybe not. I suspect that most hand-parsed implementations are actually copy-and-pasted from whatever source the author orginally learned CGI programming from. They have nearly zero understanding of the line-noise regular expressions that go into even a relatively simple CGI param parser. That being the case, these code snippets are very likely to completely break under Perl6, and they won't know how to fix them. Which makes it an excelent point to show them how to do it properly. Either that, or they'll give up and go back to Perl5.

      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

Re: How to Sell Perl 6
by toma (Vicar) on May 05, 2004 at 05:01 UTC
    The value of software is almost entirely based on future value. You could have the best language, but if it is not going to be upgraded, supported, and ported in the future, its value diminishes quickly and predictably to near zero.

    The biggest problem was that early Perl 6 press made it look like Perl 5 was going to have a short future. This caused the value of Perl 5 to drop like a stone. I don't know if it has really recovered.

    This rest of this reply is only about marketing, not truth or technical merit. Software marketing is often like that, in my experience. If lies bother you, perhaps you should skip it.

    The best way to support Perl 6 is to be as enthusiastic as possible about improvements and the future of Perl 5. Explain how all Perl 5 the code will magically 'just work' in Perl 6, so that it doesn't matter which you use.

    To increase sales further, emphasize the Perl 6 modules that bring Perl 6 capabilities to Perl 5. Leave the impression that most Perl 6 code will also 'just work' in Perl 5.

    Other good claims for Perl 6 would be:

    • The new logic capabilities will render most database products unnecessary.
    • The instruction set will work on the next generation of quantum computers.
    • ms is using it as their next generation replacement for .NET.
    • The networking capabilities are so strong that it will cure all computer viruses.
    • It will have an easy-to-use development environment that will enable creation of seamless bidirectional translators between all computerized data formats.
    These are the types of claims made all the time by the competitors. It takes practice to say them with a straight face, try it!

    For now, though, I agree with tilly, it is too early.

    It should work perfectly the first time! - toma
Re: How to Sell Perl 6
by raptnor2 (Beadle) on May 05, 2004 at 01:39 UTC
    I have to admit that I had many of the same concerns as you, but the more I thought about it the less I worried. Perl 5 is an awesome language that has almost endless capability. Perl 5 will be here if Perl 6 fails and will get many benefits from those with Perl 6 and Parrot experience.

    If Perl 6 makes its released, it will sell itself. Perl 5 had almost endless capability. Perl 6 will have endless capability. It has everything Perl 5 does (syntax changes omitted), plus a more powerful re engine, a new easy-to-use class mechanism, coroutines, continuations, and an extensible virtual machine. Plus the re engine that is used to compile the language can be altered - imagine the possibilities!



    p.s. - its been a while since I looked at Perl 6 so it has probably gotten better than I described...

Re: How to Sell Perl 6
by marcussen (Pilgrim) on Oct 28, 2008 at 00:33 UTC

    My biggest concern with perl6 used to be that without a default implementation you would be spending too much time making sure that your code would run on the different implementations, as I fully expect the underlying languages to cause differences in compiler behavior. Although it is my personal belief that Rakudo will become the de-facto implementation and solve that issue.

    Projects like November helps sell perl6 more than anything. The more usable perl6 seems to be, the more it will get considered for use.

    Confucius says kill mosquito unless cannon
Re: How to Sell Perl 6
by JavaFan (Canon) on Oct 27, 2008 at 23:34 UTC
    With a beta of Perl 6 probably being less than two years away, many of us wonder about its future. I'm optimistic.
    You wrote that four and a half years ago. There's no beta of Perl 6 yet. Are you still optimistic?