Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

masak (6289)

masak
  (email not shown publicly)
http://masak.org/carl

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Sunday December 27, 2009
01:39 PM

Notation, and the 'business case' for Perl 6

[ #40052 ]

A few days before Christmas, I was sitting in the car with my father. I decided to try to explain why I'm spending time doing Perl 6.

I compared the evolution of programming languages with the evolution of mathematical notation. In maths, it was tricky to imagine the concept of zero before it was formalized down to a number; the idea of derivatives was tossed around in vague forms before Newton and Leibniz made notations for it; we slowly but surely got a standard way of saying "is equal to". And so on.

I was just about to connect this back to how each new programming language can be seen as a contribution to an ongoing, open debate about notation within the programming world, one that has only been going on in earnest for half a century or so. But I never got that far, because my father interrupted me and asked what the business case is for Perl 6.

I was half stumped, half amused by this interjection. I didn't have a good answer for him, besides trying to explain FOSS and the fact that we're not developing Perl 6 with the expectation that someone will buy it from us. But I still felt he had a point; so, earlier today, I took the question to #perl6, and got a set of good replies and musings by Su-Shee++, moritz++, vorner++ and mdxi++. If you have time, do read it.

I'll have to give the 'business case' train-of-thought a lot more time to mature before I can say anything coherent about it myself. But I'd like to say a bit more about notations.

Perl 6 isn't truly revolutionary in a lot of respects. It's mostly lots and lots of minor improvements. (The exception being, I think, things surrounding grammars. Those are truly revolutionary.)

What Perl 6 does do, is provide a 'strangely consistent' notation where a lot of thoughts, with practice, are easy to express. This is very much in the Perl spirit, and the main reason (according to me) to still call Perl 6 a language in the Perl family.

The notational convenience really consists of a thousand little things, but here are a few haphazardly chosen examples:

  • The prefix symbols ?, + and ~ have been co-opted to signify conversion to the 'contexts' Bool, Num and Str, respectively. This parallels their use in binary (infix) operators specific to those contexts, such as +, ~, ?&, +&, and ~&
  • The three short and common verbs is, has and does all do useful work in the OO system. Not only that, but they are a good fit for what they do, and summarize both established and modern OO research.
  • Some syntactic/semantic features are re-used where you least expect it, reducing the total number of independent components in the language. The left-hand side of a list assignment uses the same signature mechanism as do routines. (I.e. the (Bool $a, Int $b, Str $c) in my (Bool $a, Int $b, Str $c) = True, 42, 'foo'; is the same kind of beast as in sub foo(Bool $a, Int $b, Str $c) { ... }.) Smartmatching with ~~ is implicitly re-used in when expressions, and the given/when construct is re-used as the CATCH exception handling mechanism. And so on.

It's things like these that I think make Perl 6 a convenient, attractive notation for thinking about programming. Seeing that notation come alive, and seeing people use it in cool new ways for amazing ends, is the main reason I spend time helping with Perl 6.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I've used Perl professionally since 1995 or so. I saw someone (Damian maybe?) give a presentation on Perl 6 back in 2004 (I think) and was instantly hooked -- it was just obviously better than Perl 5 on a number of issues important to me. So I'm pitching in to help get a Perl 6 compiler to the point where I can start using it everywhere I use Perl! But also, it is a great pleasure to work on a system with good tests and where small changes can accomplish useful things. My $work all too frequently invol
  • A good physical analogy of programming languages are bridges. Getting over a river without getting wet can save your health (getting sick is pricy and ppl that use terms like business plan hate pricy). In bridge-terms providing Perl (awesome) 6 free of charge is like making tools to make bridges available to anybody who likes building bridges. Ofc, you could just build the bridge yourself and therefore could keep Perl (awesome) 6 all to yourself. But with the free as in beer thingy and a bit of time you mig
    • A good physical analogy of programming languages are bridges. Getting over a river without getting wet can save your health (getting sick is pricy and ppl that use terms like business plan hate pricy). In bridge-terms providing Perl (awesome) 6 free of charge is like making tools to make bridges available to anybody who likes building bridges. Ofc, you could just build the bridge yourself and therefore could keep Perl (awesome) 6 all to yourself. But with the free as in beer thingy and a bit of time you might end up being able to cross _all_ rivers because you give power to the (slightly strange) ppl.

      Hm. But I imagine bridge-building tools aren't free of charge, so I'm not sure if the analogy helps me. It tells me more about how building programs is not like building bridges...

      This explanation might suit your dad who is of cause worried about your financial situation.

      I'm going to read that as 'mindful of' rather than 'worried about', because the latter sounds like you know something about my financial situation (or my father) that I don't. :)

      And as many stories-for-parents it's complete and utter cow poo.

      Hm. That ('complete and utter cow poo') would be a step down from what I was aiming for: to put what I'm doing in terms that he can understand without dis

      • Hm. But I imagine bridge-building tools aren't free of charge, so I'm not sure if the analogy helps me. It tells me more about how building programs is not like building bridges...

        If we put the same amount of afford into bridge building tools then we did invest into information transportation tools (think of all the miners that minded all the copper that was used to make the cables that where needed to power the routers that make it possible that you can read my words right now) it might get possible to provide bridge building tools by everybody to everyone who is willing to play 15 EUR per month.

        I'm going to read that as 'mindful of' rather than 'worried about', because the latter sounds like you know something about my financial situation (or my father) that I don't. :)

        Do you have children of your own? If you do and you are not in the constant state of mil

    • I would say that Perl 6 is itself a bridge.

      If you put a bridge across a river in the right place, even if that spot was previously deserted, you’ll suddenly get a lot of people passing through. And with them, you get opportunities – lots of different opportunities, small and big. You don’t know what they will be when you build the bridge, but they will happen.

      You are enabling serendipity.

      In some sense Perl 6 is a classic Microsoft strategy – it’s a platform play.

  • Perhaps I am even more retarded than usual, but I think mazak senior's question was perfectly reasonable and the meta-answer pretty obvious.

    The 'business case' for something is a demonstration than spending whatever it costs to do something, is less than the 'benefit' gained by doing it. It usually quantifies costs and benefits in $ terms since most decision makers are responsible for the cost of their activities and just about anyone understands partial orders in the cash domain.

    The business case for Per

    • tsk tsk ! s/mazak/masak/g ; sorry

      Notational superiority is a quantifiable benefit. As well as your excellent examples, you could also add that adequate expression of a problem is an important step in both understanding the problem and solving it (see http://en.wikipedia.org/wiki/How_to_Solve_It [wikipedia.org]).

      Cheers !

  • Perl6 almost certainly will dominate the professional software environment within a few years of the first practical implementation. The business case for using perl6 as the primary development language in a business or software house are as follows:
    1. Perl6 is inherently parallel. Junctions (and other innovative language contructs) offer programmers an intellectually easy method for writing programs with parallelism. Multiple cores already are required to increase computer performance, so languages that of
    • If [Perl 6] software is too slow, it will be impractical.

      That's too simplistic. Plenty of projects do just fine with languages and runtimes and environments considered "too slow" for other projects.

      A language without an IDE and visual debuggers cannot be considered modern or effective.

      That's too simplistic too, depending on your definition of "modern" and "effective". I never use the Perl 5 debugger and I wouldn't likely use it if I had an IDE with a visual debugger. I believe I can write very effect