Great example, indeed. We've been seeing a few pop up recently, and with a lot of our team coming from Rackspace/OpenStack, it's been fun to see the application used like this :)
Although YC advocates talking to users, few founders use HN to talk to users/potential users - so I'd love to use this opportunity to get feedback on the viability of crowdfunding for smaller open source projects on a platform like Crowdtilt... Is it worth exploring features for (a 'tilt'or bounty once the community feels it's been completed sufficiently, etc)?
Fun fact and off topic: "pinto" in portuguese means something like "cock" (in reference to the male sex organ) but is also a very common surname in Brazil, which may cause funny situations (or not).
Perl seems to have gotten left behind as a language. The entire lost decade of Perl 6 is crazy. Sure, Perl can say that it has more modules and it might be a little better as a glue language, but for me I think it's time to adopt Ruby or Python. Except, of course, for when perl -ane '...' is needed in a pinch. :-)
Seriously, developers are dividing their efforts three different ways with three different scripting languages. It's probably better for everyone to learn Ruby and Python rather than have a third.
While all three are scripting languages, and they do have some similarities, there are absolutely huge differences between their respective communities. It's critical not to ignore these differences.
Python developers are generally more focused on building maintainable, robust, and reliable software. Being somewhat conservative, they usually don't buy into the latest fads or unnecessary hype. This leads to pragmatic software, without hype and without drama.
Ruby developers are often more willing to experiment, even if this means trading away quality and the long-term maintainability of their code. They tend to be more community-oriented, and far more emotional than other developers. While this leads to a vibrant community, it is often rife with harmful drama and some fixation on certain idolized individuals.
Perl developers often care more about short-term efficiency. Many of them aren't really interested in developing software itself; they just need custom software to ease some system administration task, or to process some data. While the community is vibrant, it tends to be more mature than the Ruby community, yet somewhat more conservative than even the Python community.
While these don't hold true for every individual programmer of each of those languages, they are true in general. As a whole, understanding these communal traits makes it more obvious why each of those scripting languages is how it is, and what they can best be used for.
The Crowdtilt site is written in Perl using the Dancer web framework. Perl may no longer be the default choice as a scripting language for those new to programming, but it's just as capable as Ruby and Python.
If you think Perl 5 is still where it was a decade ago when Perl 6 got started, you might be interested in looking at Moose. It's an awesome, robust OO system, with a fully thought-out MOP and quite clean syntax. It's pretty mature, but still evolving. It's also managed to preserve the ability to play nicely with existing Perl class hierarchies.
Not to mention that every package on CPAN gets it unit tests run against every version of Perl, on a bunch of different OSes (Linux, OS/X, Windows, Cygwin, several flavors of BSD, Solaris, once in a while more obscure Unices), with the test results all readily browsable several ways (see the "CPAN Testers" line, for example on http://search.cpan.org/~ether/Moose-2.0801/). It's not just "more modules", it's being able to read reviews of them, look at their unit test results, even a dependency browser (http://deps.cpantesters.org/?module=Moose;perl=latest) that will combine the unit test stats for all of a module's dependencies.
Compare this with Rubygems - the only test results I see for that ecosystem are the many recent remote shell exploits showing up on seclists.org.
Even Pypi doesn't really compare with CPAN. They've done good work there but the simple idea of author names and source archives on a file server you can builds tools around has proved more robust and extensible than a focus on the web services and tools upfront.
12 comments
[ 0.21 ms ] story [ 35.3 ms ] threadThis is a great example of small scale open source initiative.
Although YC advocates talking to users, few founders use HN to talk to users/potential users - so I'd love to use this opportunity to get feedback on the viability of crowdfunding for smaller open source projects on a platform like Crowdtilt... Is it worth exploring features for (a 'tilt'or bounty once the community feels it's been completed sufficiently, etc)?
Seriously, developers are dividing their efforts three different ways with three different scripting languages. It's probably better for everyone to learn Ruby and Python rather than have a third.
Python developers are generally more focused on building maintainable, robust, and reliable software. Being somewhat conservative, they usually don't buy into the latest fads or unnecessary hype. This leads to pragmatic software, without hype and without drama.
Ruby developers are often more willing to experiment, even if this means trading away quality and the long-term maintainability of their code. They tend to be more community-oriented, and far more emotional than other developers. While this leads to a vibrant community, it is often rife with harmful drama and some fixation on certain idolized individuals.
Perl developers often care more about short-term efficiency. Many of them aren't really interested in developing software itself; they just need custom software to ease some system administration task, or to process some data. While the community is vibrant, it tends to be more mature than the Ruby community, yet somewhat more conservative than even the Python community.
While these don't hold true for every individual programmer of each of those languages, they are true in general. As a whole, understanding these communal traits makes it more obvious why each of those scripting languages is how it is, and what they can best be used for.
Not to mention that every package on CPAN gets it unit tests run against every version of Perl, on a bunch of different OSes (Linux, OS/X, Windows, Cygwin, several flavors of BSD, Solaris, once in a while more obscure Unices), with the test results all readily browsable several ways (see the "CPAN Testers" line, for example on http://search.cpan.org/~ether/Moose-2.0801/). It's not just "more modules", it's being able to read reviews of them, look at their unit test results, even a dependency browser (http://deps.cpantesters.org/?module=Moose;perl=latest) that will combine the unit test stats for all of a module's dependencies.
</fanboy>
Even Pypi doesn't really compare with CPAN. They've done good work there but the simple idea of author names and source archives on a file server you can builds tools around has proved more robust and extensible than a focus on the web services and tools upfront.
(edit: typo)