On 1 January 2012 22:10, Shlomi Fish <[email protected]> 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. -- Erez Stop software patents _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
