Slashdot Mirror

← Back to Stories (view on slashdot.org)

Damian Conway On Perl 6 and the Philosophy of Programming

Posted by Soulskill on from the secretly-being-developed-by-blizzard dept.

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.

83 of 132 comments (clear)

  1. "The real problem..." he explained by Anonymous Coward · · 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."

    1. Re:"The real problem..." he explained by jez9999 · · 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.

      --
      == Jez ==
      Do you miss Firefox? Try Pale Moon.
    2. Re:"The real problem..." he explained by xorsyst · · Score: 2

      Precisely. How long have we had Python 3.x now? And almost everyone is still using 2.x

      --
      Get free bitcoins: http://freebitco.in
    3. Re:"The real problem..." he explained by NoNonAlphaCharsHere · · Score: 2

      In other words, even they couldn't maintain a large codebase written in Perl.

    4. Re: "The real problem..." he explained by CRCulver · · Score: 5, Informative

      Wrong been using python3.x for ~12months. some people don't like change and prefer to whine - meanwhile in the real world people like me get on with it - Quietly.

      I'm not a professional developer, but I do meet a lot of Python devs, and I always ask them which version of Python their shop is developing for. The answer so far has always been Python 2, often Python 2.5 or Python 2.6.

      Recently I wanted to write up a new application for something since existing ones don't fit my particular needs, and do it in Python 3 since I prefer its Unicode handling, but virtually all the libraries I could think to use were still Python 2 only, and a look at the mailing lists showed that these libraries' developers were positively hostile to Python 3 ("if you want to start a Python 3 fork, fine, but you'll get zero recognition or help from me").

      Anecdotal? Sure. But still enough to get one down.

    5. Re: "The real problem..." he explained by Anonymous Coward · · Score: 4, Informative

      The statistics do not support your observation. Of the major powerhouse python projects, over 80% have python 3x support. Here is a site that tracks the top 200 python packages.

    6. Re:"The real problem..." he explained by eriks · · Score: 1

      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.

    7. Re: "The real problem..." he explained by CRCulver · · Score: 4, Informative

      My observation consisted of two parts which you have erroneously conflated. When it comes to professional devs, shops may nonetheless continue to work with Python 2 even if major libs are ported to Python 3, because Python 2 is what they are used to and those major libs will continue to support Python 2 for years to come.

      The second paragraph represented only my experience as a casual Python user. Yes, big-name libraries have been converted, but there are still loads of smaller apps and libraries that appeal to hobbyists that are Python 2-only and will remain so until someone outright forks them away from their current, Python 3-hostile administrators.

    8. Re:"The real problem..." he explained by jbolden · · Score: 2

      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 cool ideas in Perl6. If they can get a hearing they might be successful. They just lost a tremendous amount of time.
       

    9. Re:"The real problem..." he explained by jbolden · · Score: 1

      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

    10. Re: "The real problem..." he explained by Dutch+Gun · · Score: 1

      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 standards committee to impose wholesale incompatibilities upon the language, even when that would have made serious improvements, and of course, the original decision to make C++ compatible with C as a starting point. Had they done otherwise, the result likely would have been the stillbirth of the language or the later fragmentation or damn near stagnation you see in Python, where years after the release of 3.x, developers *still* are stuck on 2.x because of the compatibility issues.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    11. Re:"The real problem..." he explained by phantomfive · · Score: 1

      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.

      --
      "First they came for the slanderers and i said nothing."
    12. Re: "The real problem..." he explained by radtea · · 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.

      --
      Blasphemy is a human right. Blasphemophobia kills.
    13. Re:"The real problem..." he explained by Grishnakh · · Score: 1

      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.

    14. Re: "The real problem..." he explained by Grishnakh · · Score: 1

      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 doesn't compile with the new compilers, that's only a problem for you, the developer. Your users won't see it, because they're using the compiled form, which still runs just fine (unless the OS has changed to break it of course).

      When an interpreted language breaks backwards compatibility, everyone is affected. Users suddenly can't run the program when their interpreter is updated.

    15. Re:"The real problem..." he explained by cpghost · · Score: 1

      Perl 6 in Perl 5, as in Lisp in Lisp?

      --
      cpghost at Cordula's Web.
    16. Re: "The real problem..." he explained by jma05 · · Score: 1

      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...
      Of the 197 Python 2.7 packages from Anaconda distro, 141 are there in 3.x. So it is 71.5% there among the more common packages. At large, pypi shows 3.3 at 35% of 2.7 or 50% of 2.6.

    17. Re: "The real problem..." he explained by Kiwikwi · · Score: 1

      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 for years, I have yet to experience problems worse than "oh, it'd be nice if Paramiko supported Python 3, so we could upgrade". (Which it does as of this March, so there's a nice little summer project at work.) Fact is, by now, the Python community is over the hump. All the important libraries support Python 3, and new applications are targeted at Python 3, with Python 2 compatibility being optional. (That's my professional experience, anyway.)

    18. Re: "The real problem..." he explained by DuckDodgers · · Score: 1

      I think that's a fair point. I hate Java - I work in Java :) - but you can use compatibility flags for the compiler and jave.exe to compile and run Java 1.1 code from 1998 on the latest Java SDK. I think that's one of the big reasons the language is so wildly popular in business.

    19. Re: "The real problem..." he explained by rubycodez · · Score: 1

      you don't have a few hundred thousand lines of legacy code to worry about, some of us do

    20. Re:"The real problem..." he explained by bbsalem · · 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.

    21. Re:"The real problem..." he explained by Grishnakh · · Score: 1

      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. This kind of thing wasn't generally a problem in the past, such as with Perl =5. Now, for some odd reason, these language developers seem to think that everyone wants to spend time modifying all their programs to keep up with changes to the languages.

    22. Re:"The real problem..." he explained by bbsalem · · 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 dependency of the details of Microsoft file formats is less rather than more, it is easier to choose the alternative.

      Much of the "Inertia" is institutional. Anyone who has done tech support knows the psychology: customers will pay for a support contract just to have someone to complain to when the product doesn't work as they want it weather of not the support staff can actually do anything about it. So, corporate support of Microsoft Office is a selling point whether or not the support is effective. This is true even if community support of an open source is just as effective and the turnaround to fixing bugs is actually faster. It is quite impressive to see how the opersource alternatives have matured even when Microsoft can claim it inspired them and had a 15 year head start on them, they still brought their alternatives up to snuff faster.

  2. Re:But by Waffle+Iron · · Score: 2, 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.

  3. Re: by Anonymous Coward · · Score: 5, Insightful

    See also: Python 3

  4. Now I know why it took so long by NoNonAlphaCharsHere · · Score: 3, Informative

    When you knock the "rough edges" off of Perl, there's nothing left.

  5. Re:Fourteen years? by broknstrngz · · Score: 3, Funny

    Growing beards.

  6. syntax by gbjbaanb · · Score: 4, 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.

    1. Re:syntax by rubycodez · · 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

    2. Re:syntax by gbjbaanb · · Score: 2

      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 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.

      We've all seen people who'll use a list when an array would be more appropriate. Even though the code works, they haven't learned the difference between the collection classes and so pick the wrong one. In perl you can't accidentally make that mistake because there is no 'array' or 'list' there's just 2 squiggles.
      Learn the squiggles, you learn which one to use, your code becomes correct.

    3. Re:syntax by rubycodez · · Score: 1

      I've done perl development for years, it is a mess

    4. Re:syntax by Anonymous Coward · · 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 once in awhile even though I've done complicated data structures hundreds of times. Perl could still be perl without that dog's breakfast.

    5. Re:syntax by sylvandb · · Score: 2

      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

    6. Re:syntax by Bill_the_Engineer · · Score: 3, Insightful

      Everything you just said is easily explained by:

      I refuse to learn it properly.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    7. Re:syntax by jbolden · · Score: 1

      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....

    8. Re:syntax by Will.Woodhull · · Score: 3, 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), 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.

      --
      Will
    9. Re:syntax by Dutch+Gun · · Score: 1

      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 incorporate new features while retaining backward compatibility, thus becoming "bloated" or "a mess".

      Personally, I think option 3 is the most attractive option of the bunch, and, if I'm not mistaken, this seems to describe Perl fairly well (I'm more familiar with C++, which has a lot of similarities in the "old cruft and baggage" department).

      Obviously, many newer languages have the benefit of design-wise hindsight, but new languages also have an uphill battle to carve out a proper ecosystem and prove to be a long-term viable programming candidate. Some programmers are attracted to new and shiny things (we all are to some degree), but for serious work, devs need a language that can be counted on as a workhorse.

      --
      Irony: Agile development has too much intertia to be abandoned now.
    10. Re:syntax by Blakey+Rat · · Score: 2

      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 consumed for the quirks of the language and all of it is available for the problem being solved.

      *) Simpler being defined as, "easier to fit in your head", which is completely circular definition but you get what I'm getting at I hope. I think nobody would argue that JavaScript is simpler than Perl, for example.

      --
      Comment of the year
    11. Re:syntax by Blakey+Rat · · Score: 3

      This is true. But it is not a weakness of the language

      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.

      --
      Comment of the year
    12. Re:syntax by HiThere · · Score: 1

      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 target population, and MathLab was a lot easier to learn. And can more easily import libraries from other languages.

      Still, if the early keyboards had been a bit more flexible, and APL had been a bit easier to adapt to business use cases, it might have become a dominant language. It would still have both the problems and the benefits of Chinese, however.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    13. Re:syntax by gbjbaanb · · Score: 2

      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 know it could do or things it does if only I had the newer version.

      With a small language, you can build self-contained libraries that fulfil your need for expansion of new features as they are invented, and replace them if needed.

      I think this is the best, a language should be like an kernel, not a full OS with minesweeper, notepad and media player just because they could be added to it.

      So I think I agree with you :-)

    14. Re:syntax by module0000 · · Score: 2

      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.

      --
      Trackball users will be first against the wall.
    15. Re:syntax by module0000 · · Score: 2

      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.

      --
      Trackball users will be first against the wall.
    16. Re:syntax by narcc · · Score: 1

      That wasn't the parent's complaint.

      --
      Required reading for internet skeptics
    17. Re:syntax by narcc · · Score: 1

      Right. Because unnecessary complexity is what makes a language great...

      Let me guess, you only program in whitespace and brainf*ck?

      --
      Required reading for internet skeptics
    18. Re:syntax by mattr · · Score: 1

      Says someone who is posting on a fabulously successful discussion site written in... Perl.

    19. Re:syntax by rubycodez · · Score: 1

      sadly, with the advent of Slashdot Beta you just lost the argument bringing that up

    20. Re:syntax by rubycodez · · 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.

    21. Re:syntax by FreqShow · · 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?

      1. Perl
      2. Vim
      3. a violin
      4. mathematical notation

      None of them are easy for a rookie to use. They're all very easy to use by people who've learned them thoroughly.

    22. Re:syntax by badkarmadayaccount · · Score: 1

      I though those were of the too simple category.

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  7. Re: by rubycodez · · 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

  8. From Wikipedia by FilmedInNoir · · Score: 1

    " As of 2009[dated info], multiple Perl 6 implementations are under development, but none of them are considered "complete". "
    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 innovation.

    --
    Sig. Sig. Sputnik
  9. Re:Fourteen years? by ArcadeMan · · Score: 1

    Since the last 14 years, it's been a lot easier to access porn on the Internet.

    --
    Get free satoshi (Bitcoin) and Dogecoins
  10. Re: by RoccamOccam · · Score: 4, 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.

  11. even more rough edges by rubycodez · · 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

    1. Re:even more rough edges by walkeraj · · Score: 1

      But, it's coming this Christmas!

      --
      Those days are dead and gone and the eulogy was delivered by Perl. --Rob Pike
    2. Re:even more rough edges by tnk1 · · Score: 2

      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 curve is out pacing their development curve and they keep holding back.

      Perhaps they became oversensitive to the criticism that perl wasn't cutting edge enough and so tried to chase some line of purity that would shut everyone up forever, but it has turned it into a death march. Personally, just a few improvements like ditching the sigils and some performance enchancements would have been worth a major version upgrade to me.

      Perl is still relevant only because of the code that already exists in it, and the people who know it. The longer they take to end the uncertainty of perl6, the more people will become comfortable with other languages which are new or have moved on, and the less code there will be in perl, relative to other projects.

      I like perl and I have been waiting for Perl 6 to take off, but at this point, I don't know what I would do with it other than piss off people who are using ruby or python or something else to so sysadmin/DevOps work. If I have to learn to be as good at ruby or python as I am with perl, I'm not going to bother with perl any more.

    3. Re:even more rough edges by rubycodez · · 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

    4. Re:even more rough edges by rubycodez · · Score: 1

      it was too late after a decade had passed, they are just embarassing themselves now

    5. Re:even more rough edges by FreqShow · · 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.

  12. Re:Fourteen years? by jma05 · · Score: 1

    More like the baby they had 14 years ago is starting to grow one.

    Yes, I know the one about hackers and beards.

  13. Re:Fourteen years? by benjfowler · · Score: 1

    More like the baby they had all those years ago, is now old enough to vote and fuck.

  14. Rough edges... by QuietLagoon · · Score: 1

    ..."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.

    1. Re:Rough edges... by jbolden · · Score: 1

      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.

  15. Re:Fourteen years? by multi+io · · Score: 1

    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.

  16. Upward incompatible indulgence by Baldrson · · Score: 1

    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.

    --
    Seastead this.
  17. "...on Perl 6"? Um, no. by walkeraj · · Score: 1

    This title is incorrect. He barely talks about Perl 6 at all! Stick to the facts, Soulskill; you'll end up with less disappointed readers when you don't go for misleading clickbait.

    --
    Those days are dead and gone and the eulogy was delivered by Perl. --Rob Pike
  18. Re: by Anonymous Coward · · 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.

  19. A story about Damian... by rjh · · Score: 4, 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. :)

    1. Re:A story about Damian... by rubycodez · · 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.

  20. Re:Perl 6-the best thing that ever happened to Per by jandrese · · Score: 1

    In some ways Perl 5 is getting the best of both worlds. 10 year old modules still work just fine pretty much every time, but really good features in Perl 6 get backported by people who are tired of waiting.

    --

    I read the internet for the articles.
  21. Perl for learning OO by SpaghettiPattern · · Score: 2

    Conway states Perl isn't the ideal fist language and I sort of agree. I OTOH have found Perl awkwardly useful for learning OO. As in Perl 5 you had to roll your own inheritance, you definitely understood it better as a consequence. I transitioned to Java SE and I actually prefer the strong typing as it makes messing up that little harder. Perl is still in my toolbox and I do advanced system programs with it. You know, stuff that both Bourne and Java are bad at.

    --

    I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
  22. Re: by Grishnakh · · Score: 1

    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 backwards-compatible, including glibc. That's not a kernel issue. In practice, it's rarely an issue at all; even glibc is very stable. The other libraries, OTOH, are a different matter (things like gtk, Qt, and myriad other small libraries). Even here, though, there's a pretty good effort to maintain some backwards compatibility. Most distros have qt3 compatibility packages, for instance, if you need to run applications built with Qt3. But if you've wrote an application 15 years ago that only uses kernel system calls, it should work just fine now.

    The problems with Perl6 and Python are real, though, and I think do hurt their adoption a lot. It's a real PITA if you can't run an older program because the newer versions of its interpreter aren't backwards-compatible.

  23. The problem is they gave it the wrong name. by Anonymous Coward · · 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 useful, because of lots of stuff is written in it, mostly stuff that was cobbled together on the fly. And Perl is a terrible language to maintain because it allows you to everything a dozen different ways, using obscure rules of English grammar as an organising principle, operating on unnamed variables without any readable structure or comments. Which is why they invented Perl 6, except that it doesn't exist. And porting Perl 5 code to Perl 6 ,if it did exist, would be harder than maintaining Perl 5 code.

    They should have just called it Godot.
    “There's no lack of void.”

     

  24. Re: by Smallpond · · Score: 2

    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.

  25. Re: by rubycodez · · 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.

  26. Re: by rubycodez · · 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

  27. Re:Fourteen years? by rubycodez · · 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

  28. Fortran back-end to C++ and Py bindings? by bbsalem · · 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 on the old algorithms crafted back when I was a boy, so much the better.

    Life is a set of trade offs and sometimes we settle for stuff that works for different reasons, ease of use, sometimes, efficiency at other times, and it is good to know which is which, but surely the integration now available was a dream back when we dealt with boxes of punched cards as output from programs. Now, we may have to deal with an inefficient program from time to time, as a trade off, then I welcome your algorithms hat, to tell me that you have a better code or can invent one.

  29. Re: by Grishnakh · · Score: 1

    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.

  30. F77 and F90 in GCC, c. 2003 by bbsalem · · 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 OS out there, right now.

  31. Re: by bored · · Score: 1

    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/userspace API's don't all tend to move at the same speed. This means that when you have a problem with a driver for a particular piece of hardware in your system, being forced to take newer versions of drivers for every other piece of hardware is a recipe for something breaking. I have a pretty functional laptop running a recent distribution, I was pretty estatic when about 90% of my use cases actually worked. Sound, 3d graphics, suspend/wakup, wifi, EFI boot, on and on. But, in the end, i'm not running the latest GL SL, because its not supported, I have to hand modify the bluetooth driver to get my wireless mouse working, and I had to hack KDE and the OS to get the back-light dimmer to work properly. Then every couple weeks/months a new kernel gets rolled out to fix some problem or another and I have to reapply my changes.

    I could write a 1000 page book about driver/kernel problems I've personally seen, and you need only spend a little time on LKML to notice that driver developers on linux don't really appear to be any better than any other OS. They make forward progress most of the time, but they also regularly regress some feature or another resulting in plenty of pain. Expecting the few hundred developers involved in the kernel/drivers for any particular machine to GET IT RIGHT for in any given kernel release is an exercise in fantasy land. Expecting the ten thousand or so involved in every driver in the kernel to GET IT RIGHT for every single machine running linux is even more fantastic.

    So, a problem like this has a solution, ignoring it for religious reasons doesn't.

  32. Re: by Grishnakh · · Score: 1

    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 some fixes, and didn't get those pushed upstream; is that the case? If you push your changes upstream and get them included in the kernel, then you don't need to reapply them.