when science can’t live up to the popular part

April 18, 2011

Sometimes the part of popular science that’s the most difficult isn’t the science, but the word preceding it, the indication that what you’re writing should somehow be in the realm of popular interest. Sure, this often results in omissions and sensationalism in headlines and conclusions, but the point is that at least people do care, at least reading the articles and trying to think about scientific problems. But with some disciplines, it’s rather difficult to make something that ordinarily makes people snore exciting, and computer science is usually one of these topics, despite what the occasional robot demonstration would have you believe. Behind the scenes of an acrobatic flight or a coordinated robot shuffle are millions of lines of code, all pruned by people who will have to painstakingly analyze the time complexity of each algorithm, what tasks are being distributed to what processors, and how. This is why most robot sports are boring. The calculations take way too much time and while the Singularitarians and transhumanists are busy looking for robotic souls and machine bodies, rooms of the nerds they task with doing all the actual work, worry about time complexity and algorithm designs.

Hardly exciting huh? Were you to look at a computer science paper, you’d see a flood of discreet math in long and complex pseudocode, periodically followed by proofs of its estimated time complexity, a pseudocode that often tackles a problem that the vast majority of programmers really don’t have because they can always just scale up their hardware and cut down on the graphic components of the output. No need to implement some esoteric or complex workaround to boost performance by up to 15% when installing a new server could do an even better job of speeding up the application and eliminate the need to write a lot of new automated tests for the newly implemented code. Doesn’t exactly sound like front page material for Popular Science, right? Nerds argue about the best way to boost performance of applications running on a distributed network, click here for more details and to learn about asymptotic notation and proofs! Why do you think tech sites are a euphemism for gadget reviews and news, or breathless coverage of how some self-appointed grand guru of social media made a social startup that’s totally social and incubating social media friendly social spinoffs? Say, did I use the word “social” enough times in that sentence? It’s a really, really hot keyword for tech news searches, and my editor, who was just briefed by Huffington herself, said I need to use more keywords in my posts.

Or here’s another topic from actual computer science affairs. Using stored procedures to retrieve data from a database or an ORM, an object-relational mapping. Stored procedures are usually faster to execute and give you more control over what gets brought back since you write the SQL commands and they’re compiled in the database engine you’re using. Problem is that if you have a big system, you may find yourself writing lots and lots of stored procedures, and if you change database vendors, you might have to rewrite them all. ORM tools let you work with data from your code, but because the code is compiled in the application layer and goes to a database, retrieves the data you need, then sends it back, it imposes an overhead you could avoid with just a simple stored procedure. You’re also locking yourself into a tool to work with your database rather than a very basic management client which lets you customize what you want to do. Some programmers love abstracting the database mechanics into an ORM and feel relieved that they don’t have to write nearly as much SQL script in the future. Others like the control they get by specifying exactly what gets brought back and how, squeezing as much performance as we can out of existing tools, without buying new hardware or more bandwidth to let the processes of the ORM do their job without the slightest risk of network congestion, which can still happen even with lazy loading, a feature that tries to limit the ORM tools’ overhead during database hits.

Exciting, huh? But those are questions computer science tackles. Speed, performance, design, solving large and complex problems through an application of certain proven patterns and creating variations of an existing paradigm, often a slight tweak to make things easier to debug or code. Technophiles with their hearts set on the glorious future where machines a million times smarter than humans run everything should sit down with a computer scientist one day and talk about something as simple as mapping and let us know how close we are to the Nerd Rapture and the descent of the Great Machine after finding out how much it takes to teach any machine the difference between right and left. They don’t just memorize it like we do, they have to perform an elaborate set of simple calculations and a little trigonometry every time they’re faced with a fork in the road. To give a simple robot its bearings in a known environment takes hundreds of lines of code, code that’s parsed, scrutinized, and encoded in pages of asymptotic notations and pseudocodes, then possibly never used since it relies of some system or framework-specific trick to improve performance. And again, none of this is of any interest to the vast majority of popular science blog readers. It’s certainly of consequence, but the details just aren’t all that fun to discuss, and even for those who are amateur coders and who would certainly enjoy it, the academic formalism they’ll encounter and the quirks of their future workplaces which insist that something is to be done one way because that’s either the way they’ve always done it, or because it’s “a cutting edge tool a company on the cutting edge like us has to use,” take a toll on how excited they’ll be about what they do.

Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedInShare on Google+Share on StumbleUpon
  • Jordan

    So do computers not “remeber things?” I once heard Kurzweil say that computers since computers “never forget” they’ll make us look stupid once they get that littkle patter-recognition thing down. But from your post it sounds like the computer has to read the code ever time it does something (albeit it reads very fast).

    On a related note, the whole Kurzweil /Singularity fantasy give new meaning to the phrase duex et machina, doesn’t it?

  • Greg Fish

    “So do computers not ‘remember things?'”

    No. Memory as far as an application is concerned consists of looking up whatever is in a persistent store like a binary file or a database and looking through the information to retrieve the desired piece of data. As far as computers themselves go, they reconstruct data from tables which keep track where the different bits are on the drive.

    So I’d suppose if you consider the equivalent of looking at your notes as remembering things, then yes, computers never forget. You could argue about how much they act like humans assembling memories from whatever is stored in their neurons, but then we’ll be having a philosophical discussion rather than a technical one…

    “it sounds like the computer has to read the code ever time it does something”

    It has to read some instruction, otherwise it doesn’t know what to do. There’s a reason why operating systems have millions of lines of code dealing with abstractions of every part of the computer and managing the resources used by the applications you run.

  • Jordan


    Some people tend to anthropomorphize technology a little too much. The brain as a computer metaphor only goes so far. I find it interesting that we have always assumed our brain works just like the most advanced device of the day. First it was clockwork, then a steam engine, now computers. It will be interesting if and when we finally figure out how the brain works.

  • I agree with the sentiment but wouldn’t exactly call the problems discussed here “Computer Science”. In the case of stored procedures vs. ORM, that’s purely an implementation detail for particular programs. The Computer Science behind it was mostly finished over by the 70s, with the rest being “just” engineering details of the implementation. Likewise with the left and right problem for maps, yes it involves trigonometric calculations, but they’ve been known for thousands of years, so once again it’s “just” an implementation detail. Of course, “just” is in quotes because it’s the same “just” that says ‘we’ve known Special Relativity for a century so asymptotically approaching lightspeed is “just” a matter of building the engine.’

    The distinction between software engineering and computer science is indistinct, as with many fields, but as a programmer I regularly come across problems like those you’ve described in my day-to-day work. They’re pretty quick to surmount, writing pseudocode is easy (since that’s the point of pseudocode) and roughly estimating time complexity is usually trivial, even with deeply recursive functions.

    In terms of the “real” Computer Science that I follow as an amateur, there’s far too much research going on for anyone to know in-depth, as with anything, but there are truly innovative, interesting things going on which have nothing to do with the tedious humdrum of client-server systems, databases or GUIs. For example, in the areas I follow, mainly programming languages, there’s fascinating stuff going on with concurrency paradigms, type-level computation, game semantics, category theory, non-deterministic code rewriting (eg. via genetic algorithms) and so on (a couple of good sources for this stuff are lambda-the-ultimate.org and the VPRI mailing list http://www.mail-archive.com/fonc@vpri.org/info.html ).

    The point of this blog post still stands, that this stuff is really boring for a pop-sci medium, but I consider the examples used to be like judging the state-of-the-art in cosmology by reading patents.