Hacker News Reader

Comment by gumby | Hacker News Reader

This title sounds like an homage to Lazebnik's famous essay "Can a biologist fix a radio?" (http://www.ncbi.nlm.nih.gov/pubmed/12242150)

View on HN

For the lazy (saves some searching on the page and two clicks), the direct link to the full text:

http://www.cell.com/cancer-cell/fulltext/S1535-6108(02)00133...

I'll bookmark both those papers - and I rarely bookmark anything (instead relying on Google and the eternal onslaught of ever newer links and issues).

That paper is real fun to read, an excerpt:

> How would we begin? First, we would secure funds to obtain a large supply of identical functioning radios in order to dissect and compare them to the one that is broken. We would eventually find how to open the radios and will find objects of various shape, color, and size (Figure 2). We would describe and classify them into families according to their appearance. We would describe a family of square metal objects, a family of round brightly colored objects with two legs, round-shaped objects with three legs and so on. Because the objects would vary in color, we would investigate whether changing the colors affects the radio's performance. Although changing the colors would have only attenuating effects (the music is still playing but a trained ear of some can discern some distortion) this approach will produce many publications and result in a lively debate.

If you need a real good laugh, do read it now, it gets even more funny after the quoted paragraph! It's almost as good as that (much shorter) paper on PubMed where they examined the sterility of farts in operating rooms (http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1121900/).

One night I had a dream a biologist not knowing what a computer is would spend hours describing that mysterious non uniform squarelet mater engraved with latin letters. What a curious organ.

Laugh all you want, but if ever an UFO crashes on Earth and we find a mysterious alien computer, we will need people with that mindset to reverse-engineer it... ;).

We need finer reverse engineering that mapping in IMO.

Also, here's the PDF, which I find to be a better format for this particular content: https://www.cmu.edu/biolphys/deserno/pdf/can_a_biologist_fix...

Great paper:

>"Even if a diagram makes overall sense (Figure 3A), it is usually useless for a quantitative analysis, which limits its predictive or investigative value to a very narrow range. The language used by biologists for verbal communications is not better and is not unlike that used by stock market analysts. Both are vague (e.g., “a balance between pro- and antiapoptotic Bcl-2 proteins appears to control the cell viability, and seems to correlate in the long term with the ability to form tumors”) and avoid clear predictions."

Exactly! As soon as you start trying to attach numbers to this stuff you realize we haven't figured out much of anything about it, and these "theories" haven't ever really been tested. It is honestly a waste of time to approach the problem like that. Even assuming the info is accurate (yet vague), future generations will have to redo all of it anyway to see what is is really going on. In reality it seems to be both inaccurate and vague...

One lesson I took from that paper was just how immature the modern software industry is. If you ask a software engineer to describe a system graphically they'll produce diagrams that look like the biologist's, not like the electrical engineer's. There's a general lack of standardized, accurate, and useful terminology or even models to describe the high-level structure of software. The best we have are a few analogies, some described design patterns, and low-level data structures and algorithms. We can describe things on the level of gears or resistors but we don't have a good vocabulary for things on the level of transmissions, engines, ALUs, or switch-mode power supplies.

Worse, we don't seem to care a lot about this lack, largely because it isn't perceived. A lot of devs think that we're in the space age when it comes to software, instead of virtually the stone age. And then we wonder why our software tends towards the "big ball of mud" model oh so often.

I agree that software lacks this visual language -- I always find English a better architectural description language than UML, though I am not particularly happy with either.

I think the reason is that computer programs are documents -- things constructed in a language. Someone might conceivably write a good summary of, say, _War and Peace_, but a diagram of the book would only be useful for illuminating certain aspects of the story.

We do have those words, servers, ports, IPs, CPUs, disks, databases, sockets, protocols, HTTP, etc.

It's not immature, it's delivering serious value to most of the world.

Describe in, say, five thousand words or less the architecture of nginx in a way such that if implemented it would have demonstrably the same characteristics as the existing version.

Is it even possible to compress it down tha much?

If one wrote such a description, it would form the source code for nginx. The source code for a program is a description of the program's architecture, in all of its details.

Do not mistake the source code, for the program itself! The documents programmers spend all our time working on are really just specs; the actual program is an artifact produced by a compiler.

This isn't entirely true, you could compress the source code which would generate a dictionary (vocabulary) which could be used with the description (compressed output) to recreate the source code.

You see comp sci is so advanced we don't even bother writing descriptions of our creations, we allow the software we've written previously create those descriptions for us, along with the dictionary used to understand the description, and then use another program to understand that description for us.

Nice.

The reason why we use words like 'web server' is so that we don't need to carry around a 5000 word description of a 'web server'.

Just as when building a car one would use a word like 'engine' rather than carry around a 5000 word description of an 'engine'.

By compressing highly complex machines into single words we're able to build much large machines by treating that complex machine as a single component of the much large machine.

Furthermore, I fail to see how whether one can describe nginx in 5000 words or less means that our industry lacks the vocabulary to describe components of more complex machines built from those components.

If your developer requires a 5000 word description of nginx to type

  apt-get install nginx

then they are a tool and need to be fired.

Most of the problems with our industry stem from exactly this kind of problem, rather than look at the vast array of components that do the exact same thing they are about to implement, they use something like nginx to make nginx, except instead of installing nginx they made a 5000 line nginx config file to reimplement most of what nginx already does.

If you've ever seen

  { "key" : "23", "value": "Michael Jordan" }

then you know what I'm talking about in regards to the stupidity of this industry using components to make the component it already is.

This question is like when someone says they are intelligent then someone gives them a wrote memorization test about the agreed upon symbols we use to encode those words on paper. While memory is required for intelligence, not having memorized a particular encoding of a particular word is not an indication that one does not possess intelligence.

That essay is fun but supremely unfair to biologists. The reason that we engineers can "unambiguously understand a diagram describing the radio", "identify familiar patterns or modules in a diagram of an unfamiliar device," or "[use a] formal language that successfully unites the efforts of many individuals" - is because we created all of those things from first principles. We - people - invented radios and all of the parts in them, of course we know how they (and other man-made devices) work. The engineer doesn't have some special mindset that allows him to fix the radio. He just has a lot of knowledge about how the system works, because it was written down by the people that created it, all the way back to simple combinations of common matter.

It's easy to have a formal language and tools when you start with the language and build everything on top of that. When you're trying to look at a complex system that was entirely built by some unknown process, according to unknown rules, and you have to figure out the language from observation, it's obviously going to be a very different ballgame.

It totally is! I read the original Lazebnik paper when I was young and it had quite an impact.

Reply on news.ycombinator.com