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.
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.
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.
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.
Abigail
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
|
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.
Abigail
| [reply] [Watch: Dir/Any] |
|
|
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?
| [reply] [Watch: Dir/Any] |
|
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).
Abigail | [reply] [Watch: Dir/Any] [d/l] |
|
|
|
|
|
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
| [reply] [Watch: Dir/Any] |
|
|
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.
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
|
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.
Abigail
| [reply] [Watch: Dir/Any] |
|
| [reply] [Watch: Dir/Any] |
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. | [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] [d/l] |
|
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.
| [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
|
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
| [reply] [Watch: Dir/Any] [d/l] |
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 CGI.pm 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!
| [reply] [Watch: Dir/Any] |
|
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.
| [reply] [Watch: Dir/Any] |
|
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!
| [reply] [Watch: Dir/Any] |
|
|
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 CGI.pm 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
| [reply] [Watch: Dir/Any] [d/l] |
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
| [reply] [Watch: Dir/Any] |
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!
Cheers,
John
p.s. - its been a while since I looked at Perl 6 so it has probably gotten better than I described... | [reply] [Watch: Dir/Any] |
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
| [reply] [Watch: Dir/Any] |
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?
| [reply] [Watch: Dir/Any] |
|
|