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

Erez Schatz moonbuzz at gmail.com
Mon Jan 2 04:25:38 PST 2012

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.

> 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.

> 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.

> 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.


Stop software patents

More information about the Perl mailing list