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

Shlomi Fish shlomif at shlomifish.org
Mon Jan 2 05:30:12 PST 2012


Hi Erez,

On Mon, 2 Jan 2012 14:25:38 +0200
Erez Schatz <moonbuzz at gmail.com> wrote:

> On 1 January 2012 22:10, Shlomi Fish <shlomif at shlomifish.org> wrote:
> > Hi Erez,
> 
> >
> > Well, some of my Assembly code turned out to be slower than the one
> > generated by the equivalent gcc code, but I get your point.
> 
> That's another point, the idea that "those functions worked, every
> time" and other libraries are "buggy", falls short when the gcc
> optimized code performs better than your hand-crafted solution.

How so? I don't understand.

> 
> > There are differences in the behaviour
> > of Mono and the Microsoft .NET stack, and Mono is still incomplete (or was the
> > last time I checked).
> 
> Mainly because one is chasing the other, the .NET release cycle
> manages to release new features fast enough for any project to match,
> especially Mono that now has a lot of other issues.

True.

> 
> > Well, I agree that availability of the source (under a suitable licence) is a
> > necessary condition for having the bugs fixed, but I disagree that it is
> > sufficient. Even if you have the source, you may not be able to understand it.
> > Even if you understand it, you may not be able to debug it or fix it.
> 
> Which, again, goes back to the same idea of "my code is better". For a
> Knuth, or even a Spolsky, their code is probably 100% perfect, but us
> lesser beings might not be as perfect, and for those measures, might
> be better using 3rd party modules that were written by someone with a
> much better understanding of the problem space.

I have yet to hear of a software developer whose code is 100% defect-free. The
code of some people come quite close, but practically everyone has bugs in
their code. A lot of the software engineering literature is about reducing the
number of defects in one's code, and the posts on Joel on Software routinely
discussed fixing bugs or mitigating them, so I assume that Spolsky introduced
some bugs in his code. There were also some bugs discovered in TeX, which is
Knuth's work (although for the record, not all of its code was written by
Knuth).

Moreover, even if the code you write is going to be flawless, then writing it
would be time-consuming, so usually it would be quicker to use a pre-made
solution. There is such thing as a time-to-market.

Also see:

http://zgp.org/pipermail/linux-elitists/2007-October/012249.html

> 
> > Well, we should distinguish between language extensions that are APIs
> > ( http://en.wikipedia.org/wiki/Application_programming_interface ) and between
> > such that are meta-syntactical (or maybe also meta-semantical) abstractions. For
> > example, Moose is not an API per-se, because you still need to write the
> > business logic using it (but naturally, it may be easier and the result be more
> > elegant).
> 
> I would love to see modules/libraries that prevent me from having to
> write the business logic that use it. Also, Moose is very much of an
> API to the whole MOP underneath it. I don't need to roll my own MOP or
> do any fancy stuff other than calling "use" and then using the "has
> =>" attributes to it, which are (part of) the program's interface -
> the API. Which is the same in most of programming. I could even say
> that Perl's syntax is the API of perl - the C program.
> 
> In the world of Java/.NET, this is much simpler, since every library
> is being imported (e.g. "using foo.bar.magicstuffhere") then
> instantiated "MagicStuff mstuff = new MagicStuff()" then called
> "Fooable foo = mstuff.getFooed()" regardless of what it's being used
> to, as or for, so you can look at it less as "language extension" and
> more as a strict "API". Perl, as usual, falls less to a strict
> import-instantiate-use structure, and tends to behave more like a big
> ball of wibbly wobbly API-mey wimey... stuff.

Heh, OK.

What I meant that if I use XML-LibXML (or a different XML parser), then it is an
API, because I spend less time writing an XML parser, which is something that
perl is capable of doing without any CPAN modules. Naturally, I still need to
write some of the business logic above it, but sometimes I have modules
for it too, and need only some glue-code. However, in Lisp for example, I can
define macros that do not implement business logic, but instead facilitate and
accelerate writing more future code.

So I hope you understand my diagnosis and why the ranting in the articles was
not directed at higher-level languages and language features with better
abstractions, but rather at the availability of APIs that abstract away
certain domain-specific tasks that you may run into.  

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
http://www.shlomifish.org/humour/ways_to_do_it.html

“I simply hate, detest, loathe, despise, and abhor redundancy.”
    — http://uncyclopedia.org/wiki/Redundancy

Please reply to list if it's a mailing list post - http://shlom.in/reply .


More information about the Perl mailing list