Notation, and the 'business case' for Perl 6

masak on 2009-12-27T18:39:27

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.


My case

colomon on 2009-12-28T01:25:28

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 involves arcane changes to complicated things leading to 8+ hour test runs on a fast quad core machine and then reading the tea leaves to try to figure out if the system actually performs better after the changes. It's nice to remember that programming can actually be fun...

what might be your case

gfldex on 2009-12-28T14:24:48

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.

This explanation might suit your dad who is of cause worried about your financial situation. And as many stories-for-parents it's complete and utter cow poo.

The Real Thing is that with helping Perl (awesome) 6 to get to birth you increase the speed of the speed of the growth of your personal phase space of shinies. How cool is that!

Ohh, while we are on it. Is anybody working on bindings for clutter for Parrot/Perl6? And if there is nobody, where can I read up about making such bindings?

Re:what might be your case

masak on 2009-12-28T15:33:27

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 distorting them unnecessarily for the purposes of simplicity. My dad's a smart cookie, albeit with little direct experience of FOSS development.

The Real Thing is that with helping Perl (awesome) 6 to get to birth you increase the speed of the speed of the growth of your personal phase space of shinies. How cool is that!

I like the phase space analogy, and I've used it in a few of my own talks. But that wasn't really what I was aiming for here... the notational convenience is more like a better vehicle for navigating the phase space, taking you further than before, and in shorter time.

Ohh, while we are on it. Is anybody working on bindings for clutter for Parrot/Perl6? And if there is nobody, where can I read up about making such bindings?

I hear such things mentioned now and then, but I don't think anyone's working on anything like that. #perl6 at irc.freenode.net would be the ultimate source of such information, though.

Re:what might be your case

gfldex on 2009-12-28T16:17:31

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 mild worryness you are not very close to the average parent and quite lucky :).

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 distorting them unnecessarily for the purposes of simplicity. My dad's a smart cookie, albeit with little direct experience of FOSS development.

That's the catch. You can't understand FOSS if you don't understand that the interwebs have turned our world up side down. Until about 100 years ago moving information from A to B was hard and involved a lot walking and riding. Is some cases you had to wait a few months for all the snow to go away. Getting food instead was easy. (well, compared to traveling) You went outside and collected or hunted some and you where fine. Try to do the same in a modern City without getting the police after you. Ofc, money will solve that problem but a proper war would cause problems for anybody that lives in a big city. That might be the reason why we don't have any big wars close to mega cities anymore.

Another thing that has changed and are needed to allow you to give software away for free is the frightening increase of efficiency of farmers (or food maker in general). In the western world a single farmer can make the food for hundreds of ppl. If I would be a farmer I would be a tiny little wee bit angry of ppl that get rich with software. I would even go so far to demand getting software for (nearly) free. But here in Europe only french farmers are allowed to be demanding, so I properly wouldn't anyways.

The whole FOSS thingy tells you more about the society we live in that it does about software.

I like the phase space analogy, and I've used it in a few of my own talks. But that wasn't really what I was aiming for here... the notational convenience is more like a better vehicle for navigating the phase space, taking you further than before, and in shorter time.

The whole point of information is that it can grow and accumulate (Thanks DNA!). You are not just getting further then before, you create the tools to be used by ppl to build a whole new continent for you to explore. FOSS is a lot more selfish then it might look to the untrained eye.

Re:what might be your case

Aristotle on 2009-12-28T17:57:02

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.

uuh ?

thickas on 2009-12-29T06:30:01

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 Perl 6 is surely along the lines that it does this this and this more cheaply than Java, C#, Powershell, Perl 5 whatever.

Over nearly 10 years of listening in on some P6 discussions the reasons for '6 probably could be summed up by "pending decease of '5 caused by lack of developers, insufficient OO support or its got gangrene", or "'5 on steroids".

There are vastly more clever people here, so I'll just shut up now.

Re:uuh ?

thickas on 2009-12-29T06:40:05

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

Cheers !

More is better, less is more.

finanalyst on 2009-12-29T08:49:52

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 offer high-level support for parallelism will have advantages over "single-track" languages.

    More is better.

  2. Perl6 is elegant to program in. The fewer lines needed to implement functionality, the easier it is to comprehend. Every time I look at Java or Basic, I wonder at the 'word magic' beliefs of their language designers, viz., more words, more magic.

    Comprehensibility of program expression is essential in the business world because extension and maintenance are always handled by different people from the initial implementors.

    Less is more.

  3. Perl6 is being designed and built in a way an engineer, not a theoretician, approaches a solution. Specifications first, then tests, then implementation, then an iteration back to specifications and tests. By the time a production version of perl6 is released, its reliability will be documented. This provides a very strong argument for a business deciding which of several options to use as its primary language base.

    A theoretician has a single goal - however that may be expressed - and everything else is superfluous. The languages typically produced by the computer science world are difficult to use beyond a narrow domain because the extra work to provide flexibility and strength get in the way of the narrowly defined theoretical aims.

    More is better.

Evidence for each of the above can already be found in the way significant modules have been rapidly developed and maintained, even though the language itself remains in flux.

There are my top three strengths for Perl6; I'll not mention others for brevity.

Weaknesses Currently the bugbear is speed. The first "practical" implementation would need to ensure rapid runtime and good compilation speeds. If perl6 software is too slow, it will be impractical.

Caveat A language without an IDE and visual debuggers cannot be considered modern or effective. So far, the omens are good and Padre already provides for syntax coloring.

Since the business case for the complete language is strong, the business case for those individuals who are investing their personal resources of time and talent to bring perl6 to a practical implementation is correspondingly strong. Essentially, the uptake of perl6 by the professional software community will create a premium for those who have a deep understanding of the language and how to access its strengths.

Re:More is better, less is more.

chromatic on 2009-12-29T21:47:57

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 effective, modern Perl despite my stubbornness -- and I don't see how an IDE or a visual Perl 5 debugger would add much productivity.

I do use a C debugger.