Damian Conway On Perl 6 and the Philosophy of Programming 132
M-Saunders writes: Perl 6 has been in development since 2000. So why, 14 years later, hasn't it been released yet? Linux Voice caught up with Damian Conway, one of the architects of Perl 6, to find out what's happening. "Perl 6 has all of the same features [as Perl 5] but with the rough edges knocked off of them", he says. Conway also talks about the UK's Year of Code project, and how to get more people interested in programming.
But (Score:1)
Re: (Score:3, Funny)
Will it run on HURD?
That will have to wait.
The HURD developers have just noticed that their code would be more elegant if it were implemented using the new features of a modern programming language, so they're now starting a ground up rewrite of the HURD kernel in Perl 6.
"The real problem..." he explained (Score:1, Funny)
"Was that we wrote Perl 6 in Perl 5. What the hell were we thinking? It's Perl all the way down."
Re:"The real problem..." he explained (Score:5, Insightful)
No. The real problem is that it is not backwards-compatible with Perl 5, making its rate of adoption guaranteed to be almost zero.
Re: (Score:5, Insightful)
See also: Python 3
Re: (Score:1, Insightful)
or even Python 2.6 and Python 2.7, they're different langauges.
that immaturity regarding backward compatibility is the big problem with open source, Linux is even worse with the fluid kernel ABI
Re: (Score:5, Insightful)
or even Python 2.6 and Python 2.7, they're different langauges.
Hyperbole, much? I don't think that I've had to change any of my thousands and thousands of lines of code to accommodate the move from 2.6 to 2.7 (if I did, it was so minor that I can't remember doing it). Adding features does not make them different languages.
Re: (Score:1)
I remember having to make exactly one change: to replace a class with its instance as __enter__ / __exit__ no longer work as class methods.
Re: (Score:3)
Fortran is very good about backwards compatibility...can still compile and run Fortran-77 programs in the newest incarnations...
Finding a working card punch is the problem.
F77 and F90 in GCC, c. 2003 (Score:1)
The last time I dealt with Fortran was second tier support for the GCC compiler in Solaris in 2003. Some of Sun's biggest customers for the compiler were Fortran developers working in science institutes. I tested and routed test cases for customers against bugs for the F90 and F77 compilers. I assure you that there were no punch card decks involved, although when I first used Fortran in the 1960's and '70's they were involved. You can compile fortran sources on most Linux distros, and probably most every O
Re: (Score:1)
I laugh at people who point at all the new Python and C++ numeric stuff whenver Fortran is mentioned, that don't realize 75% of those projects consist of ForTran libraries.
Fortran back-end to C++ and Py bindings? (Score:1)
IBM 1620 FORTRAN IV was the first compiled language I learned back in 1969. I coded Fortran IV and F77 in the decades following, and C after that. Lately I have been learning Ipython Notebook 2.0 and just installed Anacinda with all those libraries for scientific data reduction and graphics/visualization. So it is fine with me if there is some binaries in there that were compiled from FORTRAN sources, what really matters is the integration allowed and if the numerical analysis is tried and true and based o
Re: (Score:2)
Wrong. Linux doesn't need a static ABI, because the device drivers are all distributed as part of the kernel. Only makers of proprietary modules, and sycophants and nay-sayers complain about the Linux kernel not having a static API and ABI for kernel modules.
If you're talking about application code, the kernel is static on that. You can take binaries from 15 years ago and run them on a modern Linux kernel. The problem you'll usually run into is that the libraries that binary links to are not fully backw
Re: (Score:1)
you are wrong and part of the problem, the necessity and issues caused by rewritng drivers constantly causes problems and wastes time that could be better spent on extending features
Re: (Score:2)
There is no time wasted rewriting drivers, and there is no problem. The drivers are part of the kernel; when the interfaces are changed, the drivers are changed accordingly. This doesn't take any time because the changes are fairly trivial (usually adding an argument to a function call). You have no idea what you're talking about, and are obviously not involved in kernel development.
Re: (Score:2)
Only makers of proprietary modules, and sycophants and nay-sayers complain about the Linux kernel not having a static API and ABI for kernel modules.
Ok, so this is going to sound like flaming but its not.. Because _ANYONE_ who has used linux for any extended period of time in a non trivial manner and, who is being honest with themselves has had problems due to the kernel and associated drivers being tied together.
Thats because without fail, the drivers for every single piece of hardware and the kernel/users
Re: (Score:2)
I think you're completely overblowing things. Regressions are rare; once a driver is working properly, what reason is there to go back and muck with the driver? Personally I've never seen any regressions at all on my hardware (or any HW I've worked with); once something's working, it stays working on newer versions. It's not like they need constant maintenance; the only time they need any maintenance is when the kernel interfaces change.
For your bluetooth and backlight drivers, it sounds like you made so
Re: (Score:3)
Precisely. How long have we had Python 3.x now? And almost everyone is still using 2.x
Comment removed (Score:5, Informative)
Re: "The real problem..." he explained (Score:4, Informative)
The statistics do not support your observation. Of the major powerhouse python projects, over 80% have python 3x support. Here [appspot.com] is a site that tracks the top 200 python packages.
Comment removed (Score:5, Informative)
Re: (Score:2)
That's been my impression of Python as well. Fragmentation and stagnation, despite some assurances to the contrary. Granted, impressions don't necessarily equate to reality, but there you go.
It feels like some language devs tend to discount the importance of backward-compatibility for developers, or the longevity of code in general. People complain about all the cruft of C++ (which it does have in spades, of course), but part of the enormous success of C++ was undoubtedly due to the refusal of the standa
Re: "The real problem..." he explained (Score:5, Interesting)
Fragmentation and stagnation, despite some assurances to the contrary
I use Python both professionally and for fun (and C and C++ professionally) and don't get this impression at all. Major upgrades to shipped languages take time. The willingness to impose one-time incompatible changes for the sake of long-term improvements takes guts, and can certainly go wrong, but can very well be worth it.
As someone who worked in C and C++ pre-standardization, I recall (perhaps erroneously) that the new standards broke a fair bit of existing code, albeit in minor ways. And of course Microsoft's broken C++ compiler in Visual Studio 6 resulted in a vast amount of borken code when they finally caught up to the rest of the world.
That said, I haven't moved to Python 3 yet, although I believe all the libraries I really care about have now migrated. I tend toward late-adoption, though, and my sense of the Python community is that everyone accepts we are eventually going to move to 3. Big changes take years, so it's no surprise that lots of developers are still on 2.x. The real watershed will be when a few major libs (wxPython, say) drops 2.x support.
In contrast, my impression of Perl 6 is that it's the language of the future, and always will be. It appears so different from Perl 5 that it's a little weird the same name is being used, and it has mostly resulted in sucking the oxygen out of Perl 5 development.
Re: (Score:2)
As someone who worked in C and C++ pre-standardization, I recall (perhaps erroneously) that the new standards broke a fair bit of existing code, albeit in minor ways. And of course Microsoft's broken C++ compiler in Visual Studio 6 resulted in a vast amount of borken code when they finally caught up to the rest of the world.
Yes, but there's a big difference: C and C++ are compiled languages. So if your application was built with some older compiler, and now C++ has been standardized and your application do
Re: (Score:2)
When an interpreted language breaks backwards compatibility, everyone is affected. Users suddenly can't run the program when their interpreter is updated.
Which is why we have separate /usr/bin/python2 and /usr/bin/python3 interpreters. So that programs can specify which one they use. You can even install e.g. Python 2.6 and Python 2.7 side-by-side if you have an application that is finicky enough to only run on 2.6.
On Windows, the situation is messier, which is why serious Python applications (e.g. Mercurial) bundle Python on Windows.
There's a lot of moaning about Python 2 vs. Python 3, but having worked professionally in Python and with Python applications
Re: (Score:2)
Re: (Score:2)
Well. I do write Python. I have seen no cause for hostility. I still write in Python 2.7 (there is no reason AFAIK to still use 2.5 or 2.6 other than just not bothering; 2.5 is just too old) but intend to switch whenever Linux distros make 3.x the default.
> "if you want to start a Python 3 fork, fine, but you'll get zero recognition or help from me"
That's pretty anecdotal. Here is something a bit more objective.
http://docs.continuum.io/anaco... [continuum.io]
Of the 197 Python 2.7 packages from Anaconda distro, 141 are
Re: (Score:1)
you don't have a few hundred thousand lines of legacy code to worry about, some of us do
Re: (Score:2)
Python 3 is much less of an improvement over 2 than Perl 6 is over 5. For better or worse the changes are much larger. A better comparison is Oak to Java, C++ to C# or VB6 to VB.NET
Re: (Score:2)
Yes, but people don't want to dig up all their older programs and modify them just because the language has changed and is no longer backwards compatible. Inertia is a very powerful thing, and these language developers have really screwed up by forgetting this.
Re: (Score:1)
Just ask around and see how many people still have Windows XP installed, even though Microsoft no longer supports it and says that is is now more vulnerable to hacking than it ever was as a result, and there are versions of Linux that do as much in less space and more efficiently. Yet, it is hard to get people to change.
Re: (Score:2)
We're not talking about resistance to change, we're talking about inertia. Who wants to use a language where you can't run a program on a different system, because it has a different version of the interpreter installed? Or where doing an update can break lots of important programs that your company has been running for years? It's a hindrance to adoption. Not wanting to modify all your in-house programs because of some gratuitous language change is not "resistance to change", it's simple pragmatism. T
Re: (Score:1)
I was around when Star Office appeared as an alternative to Microsoft Office. People said that it couldn't compete with Microsoft Office, but it did. It later became Open Office and then Libre-Office. I am sure that there are many people, whole businesses really, who insist that people use Microsoft Office and pay the fee. But it might to hard to know about how many people chose one of these opensource alternatives because of the zero cost and the high compitability with Microsoft Office. Surely, if your d
Re: (Score:3)
Werl first off Perl6 has a Perl5 mode so it is backwards compatible. But even if that weren't the case Perl may have lost a lot of momentum but I don't see any reason that non backward compatible languages can't thrive. For example neither JavaScript nor ActionScript was backwards compatible with their parent language (ECMAScript) and both languages did rather well. Java was not backwards compatible with Oak. Perl itself was not backwards compatible with awk/sed scripting. Etc... There are a lot of c
Re: (Score:2)
No. The real problem is that it is not backwards-compatible with Perl 5, making its rate of adoption guaranteed to be almost zero.
I believe the intention is to have compatibility, through Parrot. I believe this is also a major reason it hasn't been released yet.
Re: (Score:3)
Re: (Score:2)
What?! No. He Doesn't say that anywhere in the interview, and it's only true for the "v6.pm" implementation of Perl6. Rakudo is implemented in C, Perl6 and NQP. Pugs is written in Haskell. then there's the PGE, and Perlesque, and other stuff too.
Re: (Score:2)
Now I know why it took so long (Score:3, Informative)
syntax (Score:5, Insightful)
Now, the problem with that is that it only works if you know the distinction in the syntax. So people coming into Perl get lost in this sea of ampersands and stars and all sorts of other symbols that we use in the language. And until you get past and it sort of goes into your hind brain and it just translates immediately, âah yes, thatâ(TM)s a scalar variableâ(TM), âah yes, thatâ(TM)s a type blah, blah, blahâ(TM), it doesnâ(TM)t make sense. It looks like line noise, and I fully agree.
and he's quite right, because the alternative is COBOL or Visual Basic where every syntax element is spelled out in big words.
There's a reason Windows developers like C# and not VB.NET (even though its the same thing) and that's the syntax. With C# you get to use a few symbols for various bits that are otherwise spelled out in VB. Perl just takes it to the limit - which means you have to understand what those symbols mean, and if you don't it looks like garbage. Which, I guess, C# looks like to my mum.
So in other words: learn your shit guys, you can't criticise perl for looking like crap unless you have taken the time to learn the language. And then you'll think it looks correct.
Re: (Score:3, Insightful)
wrong, the alternative is not a COBOL or VB like syntax, talk about fallacy of asserting the consequent.
plenty of well designed languages don't have the sigil mess, it's a sign of scatter-brainedness and design by urban sprawl
Re: (Score:3)
rubbish. Each element of a language is something you write down. It can be a symbol or it can be a word (or in Java it can be aReallyLongSetOfDescriptiveWords.In.Namespaces)
The point is that once you've learned the sigils, its no longer a mess, its perfectly understandable and concise. There's no scatter-brainedness there or urban sprawl of design.
Think of it this way - if you took any language and converted it to a set of machine-readable numbers, they'd all look the same. The difference is that you want s
Re:syntax (Score:4, Interesting)
Some languages are simply easier to make mistakes in, thanks to insane syntax.
This is true. But it is not a weakness of the language. And do not confuse "insane syntax" with what Perl is doing.
Perl holds the author responsible for using the correct syntax in the context of the author's intent. It does not hold the author's hand, as if they were some kindergartner just starting out. One of Perl's axioms is that the author must be allowed to do whatever he wants without regard to some imposed notion of what is reasonable, for who but the author can know what his intention is?
That means a lot of shitty scripts are written in Perl. But a lot of shitty verbiage is written in English. Neither language should be judged by the great volume of shitty work that has been done in it. Each language should be judged by the quality of the most elegant work that it can support. There has been some really elegant work done in Perl.
For critical work, Perl should not be used by programmers who do not yet know what they are doing. While it is a great language for studying things like Knuth's work on algorithms (TAOCP [wikipedia.org]), it should not be used in mission critical applications until the student has mastered those studies.
And determining which programmers are sufficiently capable to be allowed to use Perl is a problem for the IT managers and software team leaders. It is not a problem with the language.
Don't try to use Perl in anything that is mission critical until you no longer need the training wheels.
Re:syntax (Score:4)
Yes it is. Programming languages are designed for human beings to use. If it's difficult for human beings to use them, that is 100% a weakness of the programming language.
I don't know what you think programming languages are for if not humans.
Re: (Score:3)
The mass of programming languages are designed for the mediocre mass of programmers. The others make the top tier of cash, and don't find Perl "too hard!" at all.
Re: (Score:2)
That wasn't the parent's complaint.
Re: (Score:1)
If it's difficult for human beings to use them, that is 100% a weakness of the programming language.
In "human beings", you're lumping everyone together. What do these things have in common?
None of them are easy for a rookie to use. They're all very easy to use by people who've learned them thoroughly.
Re: (Score:3)
I notice you don't even tell us what the squiggles are ...
There is a man page for that, do your own homework if you are capable of comprehending the textbook.
Re: (Score:1)
I've done perl development for years, it is a mess
Re: (Score:3)
rubbish. ...if you took any language and converted it to a set of machine-readable numbers, they'd all look the same. The difference is that you want something humans can understand. Perl manages this - _but_ you have to take the time to learn what those symbols mean. In more wordy languages, you get the understanding from the English names they use instead. The trouble with that is that many people read the English words and assume they fully know what they mean, when they don't necessarily do.
Rubbish is a great word.
Your squiggles idea has been thought, tested and practically failed decades ago.
APL much?
Learn the squiggles
sdb
Re: (Score:1)
Re:syntax (Score:4, Insightful)
Everything you just said is easily explained by:
Re: (Score:2)
Except that we know historically Perl was hugely successful it led to the explosion in dynamic languages. It drove the gateway interface and the move towards webforms away from a static web. It became the dominant system admin language....
Re: (Score:2)
Says someone who is posting on a fabulously successful discussion site written in... Perl.
Re: (Score:1)
sadly, with the advent of Slashdot Beta you just lost the argument bringing that up
Re: (Score:2)
Some people criticize any language that doesn't meet some sort of "purity" standard, but languages and programming standards evolve over time, but perhaps they haven't clearly thought through the alternatives. There are only three possibilities that I can see.
1) The language stagnates, stubbornly refusing to fix flaws or grow over time.
2) The language rejects old "mistakes" and breaks backward compatibility in order to change or add new features, fragmenting the community.
3) The language grows to incorpora
Re: (Score:3)
Human brains are finite. The simpler* a language is, the more likely the developer can fit the entire thing in his head and still have room for the actual problem he's trying to solve.
If your programming language is unusable without weeks of rote-memorization, it's a bad language. That's not to say C# or VB.Net are better languages than Perl; just that your argument to the contrary doesn't make sense.
The best, ideal, language would have near-zero cognitive load, so none of the programmer's memory is consume
Re: (Score:3)
TBH I'd rather have a small language that is a lot of small, well defined building blocks and make what I need out of it (maybe I played with lego too much as a kid), than a language that has the kitchen sink in it somewhere - or worse, has 3 kitchen sinks in it because they kept on adding them in different versions. (yes .NET, you)
So I'd say perl or C are better languages than C# because they are small. Once you know the basics, you can do anything in them. With C# I'm forever finding new things I didn't k
Re: (Score:1)
Human brains are finite. The simpler* a language is, the more likely the developer can fit the entire thing in his head and still have room for the actual problem he's trying to solve.
Simple languages for - wait for it - simple developers.
Re: (Score:2)
Right. Because unnecessary complexity is what makes a language great...
Let me guess, you only program in whitespace and brainf*ck?
Re: (Score:1)
Re: (Score:2)
Yeah, but find a keyboard to type it on.
OTOH, the "succesor" (J?) didn't do so well either, even after becoming easier to use on a standard keyboard.
The problem with APL is that it was aimed at a subset of the problem of computing that is vanishingly small. Like any decent computer language you CAN do nearly anything computable in it, but it's target was mathematical matrix manipulation in cases where an interpreter is fast enough. Unfortunately, MathLab came out before it was in common use among the targ
Re: (Score:1)
>So in other words: learn your shit guys, you can't criticise perl for looking like crap unless you have taken the time to learn the language. And then you'll think it looks correct.
I have learnt my shit. Been doing perl off and on for over 10 years in a medium-sized OO code base. I take care to make the code readable and I'm never confused by what I come across.
But when writing new code, I swear I'll probably never get used to those fucking sigils. I still have to refer to old code or perlreftut every o
Re: (Score:1)
I've masterd Perl, and was highly paid developer in it from 1999 to 2008.
that said, the language is poorly designed rubbish.
From Wikipedia (Score:2)
So, there have been releases of Perl 6 but no finalization, but aren't most programming languages like that now?
e.g. C# has 6 versions and Java (12ish, according to Wiki). Languages forever evolving.
I know PERL is old and people except it to be more rigid like Fortran (even with new versions), but Fortran isn't being used for web apps, etc. that see constant technological inno
even more rough edges (Score:4, Funny)
Larry went crazy, incorporating everything and the kitchen sink into Perl 6 and continues even now.
Imagine a swiss army knife with fold-out basketball, urinal, blender, spark plug gap tester, hog nose tag plier, etc.
what a farce, HURD may be still be floundering after a longer time but Perl 6 has gone in more directions
Re: (Score:1)
no, not a design at all, just Larry grabbing whatever cool things he saw in other languages and badly cobbling them together into something so huge and intractable the human brain can't handle it. Perl 5 is whale guts, Perl6 is whales fired from trebuchets into the rotors of sky cranes over New Years party in NYC
Re: (Score:1)
Re: (Score:3)
I honestly fear it may already be too late for perl6.
Let's just look at this like any other software development project. Perl 6 may well be heads and tails above Perl 5, or even other languages, but it has seriously lost momentum to other languages.
It is good to have a roadmap, and good to change, but they should have settled on like the top 5 features that they really wanted, come up with a solution for it, and released it. At this point, they're just in a cycle of taking so long that the innovation cur
The problem is they gave it the wrong name. (Score:1)
They created a language that won't run Perl code and called it Perl. Then they tried to add everything to it at once. Then they created a platform for running interpreted languages to run it on, then they created another one, and then another one, and then another one. So after 14 years Perl 6 is still just a grammar that has no standard working implementation and is of no practical use. And because it is useless no one will invest time in finishing it and no one will ever use it to build anything.
Perl 5 is
Re: (Score:1)
it was too late after a decade had passed, they are just embarassing themselves now
Re: (Score:1)
Imagine a swiss army knife with fold-out basketball, urinal, blender, spark plug gap tester, hog nose tag plier, etc.
If you added in a light saber, jumper cables, and a vibrator, I'd love to have one of those.
Rough edges... (Score:2)
..."Perl 6 has all of the same features [as Perl 5] but with the rough edges knocked off of them"...
Hmmmm... it takes 14 years to remove some rough edges from Perl 5? There must be some really rough edges, Probably why Perl seems to be in decline.
Re: (Score:2)
They were.
1) Not designed all the way for unicode
2) Not designed for parallelism effectively
3) Doesn't have internal access to its own grammar
4) Doesn't have access to a powerful type system
etc... Perl 6 is a huge step up.
Upward incompatible indulgence (Score:2)
Its self-indulgent to design an upward incompatible programming language (and, no, Perl 6 is hardly alone in this as others have pointed out about Python3, etc.) without looking for your keys some distance from the lamp post [slashdot.org].
"...on Perl 6"? Um, no. (Score:1)
A story about Damian... (Score:5, Interesting)
At OSCON 2006 I was sitting in one of the green rooms (the spaces set aside for speakers before presentations). My laptop was open and I was happily hacking away on a project. As I killed a bug and checked the code back in, I muttered under my breath, "Python, I love you. You make the hard stuff so easy."
I noticed a few seconds later the room had gone utterly silent. I looked up, and sitting at the table across from me was Damian Conway, tapping away on his own laptop doing his own thing. I blinked a couple of times and suddenly noticed the entire room was expecting a Perl-vs-Python argument to erupt.
Damian looked up from his work, noticed everyone was looking nervous. He looked over at me, I gave a "I don't know what's up with them, uh, help?" look and a shrug.
Damian then looked back at the crowd and grinned. "Listen, the only thing I love more than Perl is well-written software, even if it's written in Python." He looked back over to me. "Kill a bug, didja?" I nodded. He gave me a smile and a thumbs-up, then returned to his code. I returned to mine, and after a few seconds the room let out his breath.
I love Python. But the only thing I love more than Python is well-written software, even if it's written in Perl. :)
Re: (Score:1)
yes, there is very well written Perl. It was done in the last decade and before. Not used for new projects so much.
Re: (Score:2)
Perl for learning OO (Score:3)
Re:Fourteen years? (Score:4, Funny)
Growing beards.
Re: (Score:2)
More like the baby they had 14 years ago is starting to grow one.
Yes, I know the one about hackers and beards.
Re: (Score:2)
Re: (Score:2)
Since the last 14 years, it's been a lot easier to access porn on the Internet.
Re: (Score:2)
Come on! In fourteen years you can develop your OS from scratch. Bearing in mind that Perl is noting more than a scripting language, what the hell have they been doing?
If I had to make a totally uninformed guess, I'd say they probably read and learnt so much about languages, interpreters and compilers and stuff that they're now totally insecure as to how to proceed.
Re: (Score:1)
they went one step further and threw it all in the spec to be safe. the result is a language that does everything, good for nothing in particular, that can't be implemented