Comment by coriny | Hacker News Reader

Comment by coriny | Hacker News Reader

Parent Full thread

Absolutely, with any serious application, it takes time to break it down and understand it. But the majority of perl generated in bioinformatics are basically advanced shell scripts and should be immediately comprehensible. This is rarely true, mostly because there's so many ways to do things that everyone uses their own personal conventions. Learning perl 5 is a bit like collecting pokemon.

As for the Perl 6 features, I had already looked at the list and was hoping you may have some insight as to why these might be killer features for bioinformatics in particular. e.g I know what currying is, but I don't think most computational biologists will care. I actually can't see anything there that says, "Science, do it here".

Julia is a very promising language due to its focus on mathematics, readability & performance and seems to be gaining traction. R has an unbeatable set of statistical libraries. Python is now deeply embedded and has IPython, and links back end to web very nicely. C/C++ & Fortran are are miles out in front for number crunching. Java is excellent for reusable code and distributed development, and can be used in almost any layer and has proven very difficult to dislodge as the general purpose language. At the moment I don't see a niche being available to Perl 6, unless something really useful for scientists (like IPython notebooks) is brought to the table. If they really backed it as a parsing language, and provided some really sweet tools for handling biological data files - e.g. something more like an interactive IDE rather than having to write out a script in emacs. Actually give me that, I'd be very happy. But I honestly think it's the associated tools & ecosystem which will determine if Perl 6 can succeed, not a laundry list of features.

And will it ever come out? :) I remember going to a Perl learning course in 2002 where the instructor was very excited about the new version 6, which was going to be out by 2004.

Ermmm I wrote a whole blogpost on some of the killer features for Perl 6 in bioinformatics :P There are a lot of primitive types that are useful for scientific programming. A lot of my bioinformatics work at least gets reduces to bag models and set operations on big files quite often. On the computational side the stuff with native arrays is being built right now, so it remains to be seen how well that will pan out. But in theory you will get an array of native types that will be about as efficient as C. So that's like numpy included as a core part of the language. I left out the nice concurrency/parallel model and native code integration too which are really killer features in general. The ability to write first class domain specific languages that integrate fully into the compiler is kind of incredible. An example is the recent SQL Slang someone hacked together https://github.com/tony-o/perl6-slang-sql/ . You can just inline write a SQL statement and it acts like a for loop over the results returned. Kind of cool!

Thanks for the interesting reply. At the moment I guess it's a case of wait and see. I think it's fair enough to have some non-specific skepticism about Perl 6 given the history, however it's clear the designers are putting a lot of thought and love into it. And I can see how it will provide a powerful means of generating pipeline-type analysis tools.

However, it actually makes it seem to me that even more so Perl 6 makes the same "mistake" as Perl 5. The surface area of the language now seems fractal in complexity, and unless rigorous discipline & best practices are applied it's going to be very hard to build working complex projects. So great for individuals, very powerful for highly disciplined teams, but not good for the below average programmer - as 90% of biologists are. Perl 5 was full of magic, but in the hands of most biologists & less disciplined bioinformaticians that was a bad thing.

Take that SQL Slang example, great for quick scripts, but it's seems a long long way from a production ready library that can be used in a complex application. And maybe I just don't see the great advantage in being able to hide a couple of lines that make it exactly clear about what you're doing. If I'm maintaining code I want to see those explicit statements if possible. And really it's not exactly a big win over "&sql($statement)".

Anyway, it's interesting and luckily I can observe from a distance now.

Reply on news.ycombinator.com