etal

Right, which is why the novel parts should get more attention and undergo code review, which is the goal of the Bioinformatics Testing Consortium.

To be clear, I'm all for open science and even open notebooks where it's a good fit for the project. I just don't think a pile of single-use scripts is a sufficient replacement for a clear English description of the analysis workflow and the reasons for each step. If I can't understand how an analysis was done from the article itself and the documentation for any associated software, I would not trust the article. Including more code, particularly the code further down the Pareto curve of relevance to the final article, does not make the article more correct -- most journal articles are wrong or flawed in some way, even if the code works as advertized.

That's why we write papers. Plain English can be more coherent than a pile of code.

We should be clear which of two kinds of scientific code we're talking about:

1. A program that implements a new technique which forms an important part of a research project. Maybe a program that is the research project, which will be described in a paper.

No doubt this code should be included with the publication, no matter how "ugly" it is. Some journals, e.g. Bioinformatics, already require that an article about software must include the software itself. This is the stuff the Bioinformatics Testing Consortium would run a smoke test on, because amazingly, a lot of programs that have been written up as journal articles just don't compile or work at all on somebody else's machine; many articles don't include the source code, and some don't even say how to get a redistributable binary. That's wrong, and we can fix it.

2. The mountain of single-use scripts and shell commands that are used in a research project that's not really about software at all, only a small fraction of which produce some output that the scientist follows up on.

Key points: (1) this code is very unlikely to work on anyone else's machine as-is; (2) crucial parts of these pipelines are lost in the Bash history, or were executed on a 3rd-party web server, or depend on a data set on loan from a collaborator who is not ready to release the data yet; (3) almost all of the code is dead; (4) whatever comments or notes exist are usually misleading or completely wrong.

As an example of what can go wrong when this code is released as-is, remember when the East Anglia Climate Research Unit "hide the decline" stuff hit the fan? It wasn't clear which code was dead, the comments made no sense, and people freaked because they couldn't be sure how the published results came out of that godawful mess. The eventual solution, way too late, was to make a proper open-source, openly developed software project out of the important bits. That, in a nutshell, is why scientists won't release ALL the code -- even the hard drive itself is not the whole story; the scientist still needs to be available to explain it and navigate over the red herrings. And getting code into a state where it's self-explanatory takes time.

If pre-publication peer review goes out of fashion, then another possibility if that the brand of major journals becomes more important. We still need a quick gauge of the quality of an article, other than its Google rank or number of page views. Nature can retract popular articles that are later proven flawed; I don't think Google would attempt to wield that kind of authority.

Relevant example: You published these two posts in TechCrunch to get a wide audience. (And I'm glad you did!) I read them partly because they appeared in TechCrunch.

The major non-governmental funding agencies recently banded together to solve the problem roughly the way you suggest, by creating their own open-access journal which they will enourage their grantees to submit their work to. It will be called eLife:

http://www.hhmi.org/news/elife20111107.html

It would probably be considered dubious/anti-competitive if NIH and NSF launched their own journals, but because of the Open Access Initiative (which RWA attempts to reverse), NIH is able to host articles that have already been released to the public via PubMed Central.

Apparently it brought NPG back to the negotiating table:

http://blogs.nature.com/news/2010/08/nature_and_california_m...

Unclear on the details, but presumably UC got a somewhat better price. (Note that UC was getting a better price than most libraries to begin with.)

It's probably being poor, which also correlates with worse working environments. Remember, "drive until you qualify."

Unladen Swallow isn't dead, actually -- it just merged into the main CPython code base. The first few quarters of optimizations are in Python 2.7 (it's noticeably faster than Python2.6) and the more adventurous bits are on separate branches in SVN.

This is also called "flow" or being "in the zone" -- focusing on one thing, intensely, without interruptions. It's one more reason to lump programming in with the other creative arts.

It looks like Wayland isn't quite aiming to replace X, but it's close -- X will run on top of Wayland (one day).

More about the architecture:

http://wayland.freedesktop.org/architecture.html

LTS versions have stable patch-level releases every 6 months while they're supported (e.g. 10.04.1 was released in July, and there will probably be a 10.04.2 in January), so they're able to add drivers to the installer when they become available.

The word you probably want is "truthiness".

If there's a fundamental difference between the weaselly narratives constructed by Fox News and the psychedelic screeds Thompson put out, it's that most reporters aren't making it explicit that their stories are fully personal, opinionated interpretations of true events -- they record some isolated facts, sample a few quotes and make vague references to public sentiment to back up any narrative they need. But they present all of this as objective information. This was happening well before H.S.T. (see "yellow journalism") and happens outside the U.S. too (see Daily Mail).

Thompson's approach was (1) a veil of entertaining literary showmanship over (2) complete, self-accountable interpretations of the events being covered. He was clear that his stories were subjective, and that freed him to explain exactly why he felt the way he did about Nixon, drug laws, Southern culture, etc.

It would if it were true, but it's not.

Still an interesting question, though. I've seen cats focus pretty hard on certain things.

It's easier for students. When I'm on that schedule, I wake up around 7 a.m. (naturally), nap around 4:30 or 5 p.m., and go to bed around 1 a.m. It's maintainable when I don't have regular late-afternoon meetings, and very helpful during "death march"-type projects because it feels like having two days in one.

As a side effect, dinner shifts later in the day. This is noticeable in places where siestas are common, like Spain -- early breakfast, nothing happening in the mid-afternoon, and then everyone emerges for dinner and night life around 8-10 p.m.

I'm deeply curious where Clojure would fall in this comparison. Is Compojure as suave as Hunchentoot? Is string formatting just as flexible? In practice, is it a pain to have to fail over to Java library documentation when Clojure doesn't suffice, versus having plentiful but scattered docs for a single language?

1. In the middle of a long flight, compare pilots' reaction times just before the nap to just after the nap. Result: After the nap, reaction times are 16% shorter.

2. Over the entirety of a long flight, test pilot reaction times initially, then at regular intervals until the end of the flight. Result: Without a nap, final reaction times are 34% slower than initial reaction times.

Yes, it's a little bit of a factoid soup, and citations would have been nice.

Ruby, Perl and Python packages usually come with a README that says:

  This depends on these external packages: ...

Java programs usually come with a bunch of .jar files which were once independent packages, but have been dropped into the release itself. No dependency problems!

Then, if someone wants to package a Java application for Debian, the process is:

1. Look through the collection of .jar files in the release

2. Do you recognize one of these as already being packaged for Debian?

3. Work with upstream to delete that .jar from Debian's copy and depend on the system's version instead

4. Repeat for every other .jar in the release, until you hit a wall

5. Upload the package to Debian with an acceptably small number of bundled .jars

6. Time permitting, get someone to package the other .jars that aren't available in Debian yet

That said, you can cause a similar amount of trouble in other languages, it's just not the convention (thanks to the success of gems, CPAN, PyPI). For example, Ubuntu appears to have deleted the sagemath package because upstream keeps their own patched copies of dozens of libraries they depend on:

http://packages.ubuntu.com/search?keywords=sagemath&sear...

If pip/Distribute eventually works as smoothly as apt-get, I'll be a happy guy.

Another way is to pick a top-notch library or framework in your target language, and learn to use that. For Clojure, I'd try making some clever charts with Incanter:

http://incanter.org/

(Incidentally, the only new language I've been able to stick with after learning Python is R, because it solves completely different problems. Which means R is now my Blub for stuff that I'd like to, given some free time, try with Clojure/Incanter...)

This problem is different from the Python issue Zed Shaw wrote about.

In Java, developers will bundle dozens of random .jar files with their application. Other versions of these libraries may exist in a Linux distribution already, but specific Java apps aren't linking to those and carefully documenting how to install all the dependencies (or which ones are optional). Instead, from the distro's point of view, these Java apps are being released with a bunch of binary blobs that may or may not contain bugs that need patching later. Which partly defeats the purpose of package management.

Python programmers don't do this. Distros love Python, which is why so many of their system administration/automation scripts depend on it. This puts some tension between packagers, who use it as a bash/perl replacement, and developers like Zed, who want to treat it like an up-to-date library -- but realize that the Java solution of just bundling the whole thing with the main app is ugly. That tension exists because Python developers haven't run amok the way Java developers have.

Force upstream to fix a bug and release a new version? And what if they don't? Quite a few packages in Debian have somewhat dormant upstream authors - the packages work, perhaps needing a few patches to compile with the latest versions of common libraries, but the original author has essentially moved on.

Consider:

libfoobar has a bug in at least one version seen in the wild. Is my system safe?

If your distro packages just one or two stable versions of libfoobar, any package that depends on libfoobar is either OK or not OK, and if it's not OK, you can patch the bug in one place and you're safe again. If upstream is dormant, perhaps the current package maintainer can fix it.

If there are various versions of libfoobar being linked by individual apps, you need to check every app for the flaw and work with both the app author and libfoobar's author to determine whether the flaw exists and how to fix it. Upstream libfoobar might say the bug has been fixed in the latest release, so just upgrade to that. Upstream app then has more work to do, and may be in denial about the importance of the bug. And if the source isn't available for the precise libfoobar bundled with the app, the package maintainer would have to either (a) rework the app to work with a stable system version of libfoobar, (b) package the odd version of libfoobar separately, and link that, or (c) delete the package from the distribution.

I tried a few LaTeX templates on CTAN awhile ago and settled on simplecv:

http://www.ctan.org/tex-archive/macros/latex/contrib/simplec...

It's fairly boring, but simple to use and flexible. Best, it makes good use of the space on the page without looking too cluttered.

Maybe (I don't study this) but at least some of this pathway is also used in embryonic cells, so it's pretty fundamental. More often, cancer cells will evolve resistance to whatever inhibitor molecule is targeting them, i.e. mutate so the ligand doesn't bind as well.

Here's the original article/abstract:

http://www.sciencemag.org/cgi/content/abstract/329/5998/1492

And in the old days, to hide dirt and especially to mask the yellow sweat ring that develops around the collar after many days of hard labor, companies issued blue shirts to their workers as a uniform. Hence, "blue collar" work.

Don't despair. Engineering is a nice lifestyle -- you can work at any size company, you can travel if you want, and you can switch to independent consulting or join a consultancy if you want. You can do a startup at any time, too; engineers create things people want. I don't know of any other background that will give you as much flexibility with your career.

Sudden jumps in income tend to stress people out; the key to happiness is a gradual lifelong rise in income, so you're always comfortable. Engineering will accomplish that for you. Personally, I felt like I'd solved the "money problem" with my first two engineering jobs -- there was nothing I wanted that I couldn't easily afford, and I liked the ratio of business trips to staying at home.

The U.S., especially the southeast.