[Israel.pm] Some articles about the curse of code reuse.

Erez Schatz moonbuzz at gmail.com
Sun Jan 1 02:56:16 PST 2012

On 30 December 2011 21:47, Shlomi Fish <shlomif at shlomifish.org> wrote:
> Hi all,
> The way a lot of programming goes today isn’t any fun because it’s just plugging in magic incantations—combine somebody else’s software and start it up. It doesn’t have much creativity. I’m worried that it’s becoming too boring because you don’t have a chance to do anything much new. Your kick comes out of seeing fun results coming out of the machine, but not the kind of kick that I always got by creating something new. The kick now is after you’ve done your boring work then all of a sudden you get a great image. But the work didn’t used to be boring. (page 594)

That's quite correct, although with two glaring caveats, one, the
amount of moving parts a programmer needs to deal with these days is
several orders of magnitude larger than the one they needed to deal
with 20, 30 and 40+ years ago. At those times, you had a machine,
maybe a time-sharing mainframe or similar, and everything was handled
by that machine, and all coding was done on that machine, and every
workstation was using the power of that machine. You would write your
own persistence layer that was closely matching your business logic
and would be able to optimize your code to handle just that, almost
without redundancies.

Now, you want to create software that needs to handle different
outputs from many different machines, across the internet. You have to
deal with different databases, code bases, network protocols, clients,
backends, etc. There is no way you can actually write all that from
scratch and still create a working application in a competitive,
practical time frame. You need frameworks, you need external
libraries. At Knuth's time, programmers wrote systems, today we write

Think of it as Linux Distros. Installing a debian/redhat package is
much less efficient than compiling it from source, as it is usually
pre-compiled to meet the largest common denominators and is, as
result, much more redundant and less optimised to work on the specific
machine it runs on, but, as we all know, the benefits of using the
package-distros outway the cons of it. And you can make the same
distinction between writing in Perl to writing in C, or even assembly.

Aside, the whole "this isn't fun anymore, this is boring" is not
exactly an objective term, I could think of many programmers whose
idea of "fun, not boring" programming is *not* having to reinvent the
wheel, maintain the tires, implement a half-assed tube system and
patch every hole caused because you were writing the outer tube in
crunch mode. And remember, Knuth is the one who commented on his books
"Beware of bugs in the above code; I have only proved it correct, not
tried it." So there's fun for you.

> Ten years ago, to write code, you needed to know a programming language, and you needed to know a library of maybe 50 functions that you used regularly. And those functions worked, every time, although some of them (gets) could not be used without creating security bugs.
> Today, you need to know how to work with libraries of thousands of functions, representing buggy code written by other people. You can't possibly learn them all, and the documentation is never good enough to write solid code, so you learn to use online resources like Google, DejaNews, MSDN. (I became much more productive after a coworker at Google showed me that you're better off using Google to search Microsoft's knowledge base rather than the pathetic search engine Microsoft supplies). In this new world, you're better off using common languages like Visual Basic and common libraries like WinInet, because so many other people are using them it's easier to find bug fixes and sample code on the Web. Last week, Michael added a feature to CityDesk to check the installed version of Internet Explorer. It's not hard code to write, but why bother? It only took him a few seconds to find the code, in VB, on the Web and cut and paste it.
> We used to write algorithms. Now we call APIs.
> Nowadays a good programmer spends a lot of time doing defensive coding, working around other people's bugs. It's not uncommon to set up an exception handler to prevent your code from crashing when your crap library crashes.

First, in Spolski's world, those libraries he use are black-boxed .NET
classes which he has no idea about what the hell goes inside them. I
use CPAN, where every module can be scrutinized and analysed, picked
apart, gutted, patched, forked, cloned or re-implemented. I can look
at the internals as well as the Documentation and API. This is a part
of why I can't read Spolski, because he blamed the short-comings of
his technology of choice on "programming these days", while blatantly
ignoring other solutions to these problems.

And speaking of "programming these days", every progression in the
programming world since whenever has been towards this "unfun"
direction. Every new language implements memory-management tools,
higher-level abstractions layers, easier pluggability, stuff like
object-models, functional calls etc. A lot of people praise LISP, one
of the most abstract, high-level languages as "the most elegant/pure",
and not as "unfun and boring". And why not? The basic tools are still
there for anyone to use. Alternatively, solving problems in a fun,
challenging way did not disappear, regardless of your choice of


Stop software patents

More information about the Perl mailing list