What he, and now I, mean, is not Perl as a "dynamic language" with some general ideas found in many other languages like Python, Ruby, JavaScript et al, but the idea of Perl as a "Post-Modern" programming language, that encompass ideas of Natural Languages. In this sense, Perl is unlike any other language I know. There have been elements that were borrowed, inherited, or lifted lock, stock and barrel from other languages (shell, awk, C, python), and there have been elements or features that have been borrowed from Perl (regexp and PCRE, to name one). I also am not referring here to CPAN, either as a Perl feature, or to ideas implemented in CPAN modules here, but to the core Perl 5 as it is implemented in the perl program.
I raised the question in identi.ca (and Twitter), and found... not much. Marcus Ramberg suggested Objective-C as being "just as ugly and just as awesome as Perl". Dotan Dimet found Qore that "Looks like perl with a java accent". Others suggested, again, Python, which, in this context, could be seen as an "anti-perl", and Ruby, that I'm not very familiar with, but have the feeling borrowed features from Perl, rather than philosophy.
That made me think. Is Perl really a one-off, a, ahem, pearl of language design, formed from the beautiful mind of Larry Wall, but never before, or since, have been implemented in the design of a programming language? Or have there been other attempts in a similar vein that I have missed, what with there being 20 or 30 gazillion programming languages out there?
]]>For example, you start the development process by writing a design doc? Design Driven Development.
You create a list of features? Feature Driven Development.
How about compiling a list of tickets, requests and bugs in a tracker? Bug Driven Development.
You write the interface first? API Driven Development (Probably better abbreviated APIDD)
Just search for "Driven Development" and you'll find Domain DD, Database DD, Model DD, Component DD, Behaviour DD, Prototype DD and even, my personal favourite, Readme Driven Development.
I say: enough. Whatever methodology you use to "drive" your development, you'll still end up writing source code, compiling, running, QAing it, judging it according to whatever spec you initially (or ultimately, or medianly) wrote. The work is the same, the result is the same. You can name it however you like. Call it "Development Driven Development" for all I care, it doesn't matter, and only stops cross-pollination of ideas seeing as "your" X Driven Development isn't "my" XDD.
And while on the subject of snowclones,
Fortunately, the argument stuck. Goto is now reviled among programmers, if only for its reputation. Unfortunately, the headline also stuck, and is now one of the most abused terms in programming (and technical) blogging. And for a good reason. It's catchy. It's well known. It has an authoritative air to it. Programmers have, by now, conditioned to consider the term a definite argument, in the same vein that "best practices" are usually considered "laws" rather than "sensible suggestions". It definitely sounds much better than "Why I think this idea isn't good" (or, heavens forbid, "The Case against ...").
It should cease to exist. Nothing in programming is definite. There is no single element that is either a silver bullet or the Antichrist. It cheapens the argument, Glenn Beck style, by reducing it to a war of slogans. (see also Eric Meyers' "Considered Harmful" Essays Considered Harmful).
Dijkstra himself, in later articles and speeches, have shown he learned the lesson Wirth taught him, and substituted well described arguments with a short, catchy, provocative one-liners, such as calling FORTRAN "the infantile disorder", and arguing that "[COBOL] teaching should ... be regarded as a criminal offence." ("How do we tell truths that might hurt?"
I take a cue from Jeff Waugh, who jokingly suggested that LAMP should mean "Linux, Apache, Most of our cool scripting languages start with P, PostgreSQL" (What does LAMP stand for?), and suggest we now re-explain LAMP to *actually* mean: Linux, Apache, Modern-perl, and a Persistence layer (to each his own).
This would've been glazed over as yet another evidence that corporate IT is brain-dead, if it wasn't for the idea that the Perl community need to win over corporate IT to become the key player it once was.
Sadly, catering to one's insanity can only cause even more insanity.
And so, trying to find logic in the madness has brought forth the irrational thinking that "all we need to do is drop the 5 and 6 from Perl 5 and 6".
Now, this might be the silver bullet, it's so crazy it might work. But you don't have to actually do anything.
Take Java for example. According to the java.com page, the current version is "Version 6 Update 26". Only it isn't. It's 1.6.0_26. A few years ago, Sun decided that the move from version 1.1 to 1.2 of Java was significant enough that it was actually "Java 2", hence the J2SE/EE/ME acronym. In this sense, Perl could easily refer to its recent iteration as "Perl 14" or refer to Perl 5.10 as "Modern Perl" and call 5.14 "Modern Perl 3" or something similar.
But you don't need to go that far. A safer, less "in-your-face" route is using a codename. It has the benefit of giving each release a different marketing brand while keeping the actual version numbering sane. The best example are Apple's MacOS X, and, to a degree, Microsoft's Windows releases.
Apple's latest Mac OS X is getting ready for its "Lion" release. "Lion" is 10.7. 10.0, "Cheetah" was released 10 years ago. Yep, 10 years and no Mac OS X 11 (OS XI?). Does anyone care? Of course not.
Microsoft are no strangers to this practice, for example, releasing Windows NT 5.1 as "Windows XP". However, the guffaw that NT 6 "Windows Vista" was, forced them to use the false numbering technique and release NT 6.1 as "Windows 7" in what was one of their greatest marketing moves.
In summation, I suggest to call Perl 5.8 "Camel" (or maybe 5.6 even), in lieu of it being the version described in the canonical book. Then call 5.10 "Perl Onion", 5.12 "Perl Butterfly", and 5.14 "Perl Raptor", and Perl 5.16... whatever you like. Then stop referring to them with their version, and just use the names.
The Perl 6 guys already do that with Perl Rakudo, and Perl 6 could be referred to as Perl Camelia.
Or we could just stop catering to the corporate IT.
]]>In a recent poll conducted by Elizabeth Naramore people were asked why they don't contribute to open source projects?
He also linked, at the bottom, to Shlomi Fish's article about How to start contributing to or using Open Source Software.
Both articles are a mouthful, and try to be very thorough in the advices and ideas they present. Sadly, both miss the point completely by assuming that "contributing" means "committing code". And this is not only wrong, its part of the reason people hesitate to contribute
For starters, "Open Source" projects tend to be seen as a hard-core programmers-only club, where you have to know how to program (mainly in C/C++), or you have no reason to be there. Seeing that the high profile projects are such complex systems, I can understand how did this image.
I would even point to the whole concept of nomenclature (Free Software/Open Source) as another clue to this "hackers only" image. When new users ask about what is FOSS, they are given a confusing lecture about the freedom of reading the code, changing the code, etc. They read articles about Open source and realise they need to learn about build systems and about version control, and get scared away.
This is sad because, as I said before, contribution to FOSS project is never limited only to committing code. Ask many project leaders about what they need and the will tell you that other than code, documentation is the number 1 issue in almost any FLOSS project, starting from user-manuals to API and design documentation. Other fields that are traditionally lacking include community management, community support, creating a web-presence, graphical design, coordination, packaging, testing, and I'm probably missing another half a dozen.
In all actuality, centring your recruitment efforts around those areas will benefit your project in the more technical oriented areas, as projects that make good progress in those fields will be more visible, new-comers friendly and will end up attracting more programmers who will see it as a thriving project that they could jump into and not get entangled with undocumented, untested cruft, or need to face puzzled, annoyed users. Solid community management and shiny web presence give the feeling of a stable project, which is what most developers seek.
Not only that, but a lot of projects that focus on getting more developers, do end up neglecting the other parts of the package, and might end up losing the community of contributors they already have, since programmers don't want to do web design, mailing list moderation, or other non-programming things.
Not all projects are GNU/Linux, who were a technical, no eye-candy affair, and whose community developed as a meritocracy of programmers. Most projects do need to clean up the façade, replace the door mattress, wipe the windows and dust up the attic to get builders and architects interested.
]]>I would like a second level todo list that will collect several tasks that need to be accomplished before I can mark an item completed. Most of these are common for each job, but some are not. For instance, I want to tick off "merge from master before pushing" for every task, but "write POD" might not apply for pure-GUI (Template::Toolkit, HTML and JavaScript) jobs. Naturally, I want those to be available every time I add a task, and selecting from those should be as simple as possible.
Sadly, I found that, for all the plethora of solutions available, none gives me what I actually need.
I was using vimtodo, a simple todo list for Vim, which allowed me to add tasks and checklists, but there was no way to actually automate this process, which meant a lot of copy/paste work for every item, and it had no online component. Getting Things Gnome has sub-tasks and can be synched via Remember the Milk, but tasks, again, need to be entered manually every time. Other web solutions had parts of what I wanted, but not all. The closest I got was Pivotal Tracker that allowed me to add tasks to each job, but, again, manually.
While at it, there were other features I thought as "nice to have". There should be a "start/pause/end" button that I could toggle, and a way to tell me how long I actually worked (In a more robust way than started on/ended on).
I've decided to work with Hiveminder as a back-end, I used it once, and remember it as flexible and reliable. It's also written in Perl and has a nice interface via Net::Hiveminder, and a very clear API.
It also has a feature that allows you to link another task as a "But first..." or "And then..." which I'll use to link the todo's to the tasks. I'm not sure about the exact interface I'll use, so for the meanwhile, I'll focus on the functionality.
Next: linking Hiveminder and hacking around it.
]]>Now, for the record, netiquette was invented by a bunch of nerdy snobs who really wanted something to use when explaining why others are not worthy of their time. The less people obey them, the faster we can get to a point where corporations are willing to listen to what "geeks" have to offer, since every time an "Enterprise" guy is looking in a Perl mailing list, all they see are bunch of petty "you do not follow rule 23 of how I want the world to act".
It's also hard to explain the benefit of the "Unix culture" to anyone who just was told to "RTFM means read the FUCKING manual, FUCKER" on #DBIx-Class. It's even harder when said someone is the owner of the leading Perl/Catalyst company.
OTOH, DHH is also known to be an F-bomb terrorist so maybe it's a prerequisite or something.
“Last year Microsoft released a new web framework called MVC. It’s not new by web standards … Yet people were waiting for it. People were waiting for Microsoft to deliver it to them.”
“Microsoft themselves … are so cleverly changing just fast enough to keep developers from solving problems themselves.”
And this also goes for faulty “standards”. Some half-baked ideas (like the Microsoft .NET remoting framework) are getting implemented into core systems before someone, Microsoft or else, realises that these are the technical equivalent of horse manure that spent several days in the sun, and now, not only that they are stuck with it, but Microsoft is no longer providing support for their festering framework of scum and villainy.
This is not to say the world of open-community/open-source development is all made out of shiny bits and bytes, but I think we can see how the community leverage the bad parts and enforce standards that other communities can only be envious of, like the way CPAN modules are released along with full documentation and a test suite, the way Git was embraced by the community, how Moose and Catalyst became the forerunners of web and OO development, and how perl itself is now being rapidly developed and released. Unlike the .NET attempt at community, the Perl ecosystem is very healthy and is strong on maintaining its health, in many great ways.
]]>Another project I overlooked is KiokuDB. I was looking around for a non-relational/Object-based/Document-based Database (aka NoSQL), and kept overlooking KiokuDB for two reasons; first, KiokuDB is a front-end to several different back-ends, including RDBMS like MySQL and Postgresql, making me unsure whether it is a true object-based DB, or just a glorified ORM, and second, it has a silly name.
It's not that I judge projects by their names, but in the rich plethora of solutions that is CPAN, most searches will bring in such an abundance of results, that if any of those have a silly name, I would probably overlook them first, and return to them only if others fail to meet my needs. And, Larry help me, Perl programmers have a tendency to really hit the silly when naming their work.
From the usual tongue-in-cheek puns (cpanminus, Config::JFDI), to the odd obsession geeks have with Japan (Rakudo, KiokuDB, Kaizendo, to name a few), to downright obscureness (Mojolicious, Dist::Zilla, Starman, Twiggy). It reminds me the time I tried to install LiveJournal through CPAN, and after installing a major continent of modules, the project complained that it can't find "TheSchwartz". I didn't even bother looking that one up.
Mind you, this habit is not reserved to Perl, and is a well-known Unix hackers' tradition of selecting "names that make marketeers wince", but once in a while, I would like to actually know what something does just by its name.
]]>One of my first assignment, back when I was a technical supporter, was to "refactor" a Perl script, which turned out to be more of a glorified shell script riddled with back-ticked system calls to wget, grep, et al. After rewriting those as actual Perl, I was left with the last element of the script that I wanted, upper-casing text in the files the script downloaded. The problem wasn't of how to perform the upper-casing, but how to perform it under specific terms, but before I got to that, I thought the best way would be to grab the text I needed using a regexp, then maybe substituting it using s///, now, what is the best way to uppercase text with a regexp?
I can only imaging what would've happened had I attempted to post that question to a PerlMonks thread, or an IRC channel. While it does look like a sort of Perl beginner course assignment, It wasn't. Perl is like that. The amount of things to know before you can hack some baby-Perl script is amazingly minimal, and Perl's DWIM design doesn't enforce you to understand why do things work the way they do, so the learning curve is shallow, and no-one can really say whether a question is from a course, or a real-world I-need-this-for-my-job question.
And even if it is homework, what of it? Why not just help the guy out, and allow him to progress faster to the more interesting parts of Perl?
]]>My main work method in creating this talk was two-fold. One, I jotted down ideas I had on the most immediate means, paper or electric (I found Google Wave to be an excellent tool for this, the only actual use I found for it). Two, I edited those ideas to a LaTeX document until they actually formed what seemed (at the time) a sensible narration. I also tend to follow the idea that if you can understand the talk by just reading the slides then the talk has no value. This actually means you may not understand much of what I'm talking about by just reading the slides.
That's OK, because I intend to use that as a base for several posts here.
First thing I want to mention, is that one of the main ideas I tried to push forward was that of context. That is, you don't address people in a meeting like you do on a "water-cooler chat" or like you do when you're giving a speech, etc. I was a bit guilty of violating that rule when I gave my talk in a manner I was more accustomed to from my job, which is "get in, get on with it, get out". Hardly suitable for a Perl Mongers meeting. And part of the reason for me wanting to expand on that subject here.
]]>This is why I was very excited about the re-emergence of Haifa.pm, which was exactly what I was thinking about, a non-formal, friendly gathering of like-minded people that wanted to share their affection for Perl. And for that I want to thank both Uri Bruck and Shmuel Fomberg for organizing this event, and for inviting me to speak, which I always love and dread to do.
I will also use this as an opportunity to launch this blog more officially. During the next days I'll post the slides and source of the presentation, with some personal post-mortem about it. Most of what I touch there were just points, that I'll expand on during the following weeks.
Finally, if anyone reading this lives in the vicinity of Haifa (Israel), and is a perl enthusiast, has a topic they want to share, or are interested in meeting folks from the local Perlosphere, please comment here and I'll make sure to pass the word to Uri and Shmuel for the next meeting.
]]>Unlike most here, I don't make my living by programming in Perl, but rather by working on several unconnected Microsoft frameworks that have a .NET in their brand name. I do use Perl for my pet projects and tools I work on my space time. In this sense I'm a hobbyist Perl programmer.
I think this gives me a unique look on the world of Perl, one of an outsider looking inside. Now, this is quite an oversimplification of the matter, as I should make clear. I frequent the different Perl online presences, such as PerlMonks, use.Perl, blogs.perl.org and planetperl. But I do all that as an enthusiast rather than as a professional.
]]>