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:
?, + 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 ~& 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.(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 (Score:1)
what might be your case (Score:1)
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:1)
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 ? (Score:1)
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
Re: (Score:1)
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 !
More is better, less is more. (Score:1)
Re: (Score:1)
That's too simplistic. Plenty of projects do just fine with languages and runtimes and environments considered "too slow" for other projects.
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