Subject: Re: MD5 in LISP and abstraction inversions
From: Erik Naggum <>
Date: Fri, 02 Nov 2001 00:43:19 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* Francois-Rene Rideau <>
| Ok. Do you (or someone else in this newsgroup) have some MD5 code
| that you (they) are willing to publish without any licensing issues?

  No.  Part of the reason I do not publish my code anymore is that there
  are too many incompetents and assholes out there that I specifically do
  _not_ want to get access to my work if they do not compensate me for it.
  After all, you are whining and complaining and posting a bunch of crap
  because you are unwilling to do the work on your own, so giving _you_
  this code without any licensing terms seems like a really bad idea.

| You seem to be looking for things to argue over.

  Wrong.  For some people who think it is their birthright to be imprecise
  and sloppy and disrespectful, being taken seriously and expected to be
  precise is sometimes extremely provocative.  You seem to be one of those.

| [Skipped ad-hominem attacks]

  Well, gee, your own are apparently OK, while you have a problem with
  mine.  That kind of double standard _really_ annoys me.  If you do not
  want what you call ad hominem attacks (but you are still imprecise --
  look it up), simply avoid them yourself -- if _you_ cannot do this or do
  now _want_ to do it, shut the fuck up about what anyone else does, OK?

| I suppose I could have also written a FFI to C for CMUCL or CLISP, but I
| didn't feel like doing both of it, and wanted my code to run on both, as
| well as on Genera, ThinLisp, etc.

  So design a common FFI framework!  I have designed and implemented one
  for my own needs, but I find the number of disgusting losers who would
  benefit from it if I published my code to be too high.  Sharing should be
  rewarding, not felt as a loss.  I choose to withhold what I do from the
  public because of the number of assholes who would never respect my
  rights as an owner, but fortunately, they are honest enough to scream
  bloody murder if someone wants them to sign a license agreement.
  Withholding from the general public is in fact the _only_ option an
  author has in these days of "open source" and "free software".  I find
  that many of the problems people have are in fact solved in an hour or
  two, but I have great fun solving problems for their own sake (and anyone
  who enjoys mathematics knows what I mean), but the fun that used to be
  found in seeing somebody else use my code vanished years ago with the
  agressiveness of the demands of the consumers of open source and free
  software -- there used to be a sense of gratitude and respect towards
  those who solved your problems for you and gave you code, but this is
  replaced by lazy fucks who demand that others solve their problems for
  them and get pissed off if somebody else refuse to give them their work
  for free.  This gives me solid reason to believe that certain problems
  are problems only to incompetents and it also gives me a good way to
  determine if certain "problems" are posted by trolls who do not really
  want a solution to them.  There are lots of people on the Net who only
  want to get sympathy for their plight, not actually solve their problems.
  That kind of whining wimps tick me off, and if I can help one of them
  lose their job or fail an exam by not answering their stupid requests for
  somebody else's work, that is good!

| In other words, I purported to support the (maybe illusive) idea that
| there is a usable portable Common LISP language.

  There is, and you have not been betrayed because you need to do some hard
  work to get something you want.  In fact, that sense of betrayal you feel
  is that same irrational attitude problem that comes from believing in a
  "perfection" that somebody else owes to you.

| >   You really need to clue in that MD5 does not operate on characters.

| Who said it did?

  You did, when you complained about the character concept.

| Still, it operates on streams that I also have to interpret as
| characters, in a different context (notably so as to use, e.g. WRITE,
| FORMAT, and all those text processing libraries).

  Well, considering that I have actually done precisely the same thing and
  did not have _any_ or your problems, what does that tell me about you?
  Sometimes, the only problem _is_ the person, but you do not believe me,
  and _stupidly_ think everything is an ad hominem attack.  Clue in, dude,
  an ad hominem attack is an attack on the arguments via the person, it is
  _not_ an attack on the person for something that person does wrong.
  Arguing tha you cannot trust someone because he has a bad credit record
  is ad hominem, sending his unpaid bills to a collection agency is not.
  Using the fact that somebody has been caught with a Swiss Army pocket
  knife in Oslo against them in a debate over efficienty Java is ad
  hominem, arguing that it was not particularly nice to lie to the police
  about the reason he carried it so he would not get into serious trouble
  is not.  But because you are not very precise, you will probably not
  understand this difference.  So I do not argue that you cannot be trusted
  or your arguments suck because you are not very precise or pay much
  attention to detail -- I simply point out that you are imprecise and do
  not pay much attention to detail, and then I expect you to _fix_ that,
  but since you are that stupid antagonistic, imprecise dude who seems to
  think that "you seem to be looking for things to argue over" is a much
  better approach to the criticism, you will not quite grasp what you are
  being told in any case.  That kind of arrogance is something that those
  who suffer from it will exhibit in many ways, and the belief that their
  code is perfect (or any flaws somebody else's fault) goes with it.

| CL forces me to do double buffering (actually, treble, or more), which
| sucks because of coding nightmares even more than for the slowness.

  No, the language does _not_ force you to do that, damnit.  Your very own
  incompetence and extremely annoying _arrogance_ forces you to do that.
  Just be smarter.  Think more, whine less, work better.

| >   That some languages have no idea what a character is, but treat it
| >   like a small integer is really not something you can blame either MD5
| >   or Common Lisp for.
| I actually don't blame languages that treat characters as small integers.

  Huh?  Nobody said you did, either.  Do you argue against straw men, now?

| I do blame CL for providing an implementation-dependent notion of
| character that is both too low-level to portably do any interesting thing
| with it, and too high-level to allow for portable interaction with
| standard low-level protocols.

  I think you need to explain your understanding of the character type,
  because this sounds like the rantings of an incredibly incompetent person
  who has not paid a lot of attention to detail in his life.  The _fact_ is
  that the implementation-dependent aspects of the character are precisely
  those that manifest itself in the coding and representation which you
  want to get access to directly.  How you can fail to understand this is
  truly amazing.  I wonder when you were satisfied with your bogus belief
  in "character flaw" as a good explanation for your problems.  (If you
  pardon the pun -- I simply could not resist. :)
| That's why I was talking about double, treble, whatever, buffering, which
| is overhead in programming time as well as in running time and space, and
| qualifying that as "clumsy, inefficient, not portable, and
| underspecified".

  That is how you would implement them.  Your implementation is only partly
  a consequence of the language, and only a small part, because you have
  contributed a lot more than the language has.  I get really annoyed by
  people who think that their algorithm and implementation is perfect and
  if it does not work the way they want, it is somebody else's fault.  You
  are obviously that kind of person, and there is a serious flaw with your
  thinking that you need to fix before you are willing and able to listen
  to counter-arguments.  As long as you protect your notion of perfect
  implementation, you will never get anywhere.

| Sure I can. (Well, someone else seems to be doing that for CMUCL).
| However, so it would be no more portable CL, and so that it remains
| "ported CL", I'd have to do it on each of the implementations I use
| (although most of it could hopefully be done in portable CL).

  Yes, it seems that you are one of those perennially dissatisfied people
  who do not understand that the _only_ way you can arrive at portable
  _interfaces_ to some common functionality is to write non-portable,
  implementation-dependent code that implements them efficiently in a
  particular Common Lisp system.  In fact, I am frankly _stunned_ by the
  lack of insight among people who want _both_ portable interfaces _and_
  portable implementations of such interfaces.  That is simply not how
  things work.  Common Lisp itself is a prime example: It is a supremely
  portable language, yet requires massively implementation-dependent code
  to implement correctly.  Actually, it seems that it takes a particular
  willingness to think things through that many people lack to figure out
  that what comes out elegant and beautiful at the other end of a long
  production line has been through a very _dirty_ process.  Like, do you
  think the factory that makes office furniture is as clean as the offices
  their furniture is sold to, or that writing an elegant poem about love
  and happiness did not require the usual incredible amount of pain that
  getting a poem "right" requires?  No, creating something beautiful takes
  a lot of ugly, painful work.  If you are not up to that, you really have
  no business _demanding_ that other people do it for you, or complaining
  that they have or do not.  It is that demanding attitude that makes me
  _not_ want to give people like you an easy way out of your problems.

| >   but for MD5, just break the 32-bit integers in half and operate on 16-bit
| >   values, instead.
| Yes, I have thought about this. However, I began with 32-bit because it
| was more natural, and hoped CMUCL could do well with it. It could do better.
| I was happy enough with the implementation so as to decide to publish it
| before to optimize it, if I ever do it (but then instead of writing ugly
| implementation-specific LISP - some of my friends call that "bugware" -
| I'd rather write efficient assembly and FFI code, and/or develop
| a special-purpose subLISP compiler that would do that for me).

  Well, if you have friends like that, no wonder you have problems choosing
  good engineering practices.  Using implementation-specific things to
  implement a common/standard interface to some functionality is not wrong,
  it is in fact right, and a very good way to move forward and _get_ that
  functionality, but if people do not want the functionality because they
  cannot get it their perfect way, which it seems that the several Lisp
  communities suffer from to a frighteningly high degree, they will not
  _get_ that functionality, either.

| It is small by for a code file (700 lines, including lots of comments),
| but I consider it large and noisy by USENET post standards.

  700 lines!?  Geez.  Using implementation-specific features in Allegro CL,
  the core algorithm is 100 lines.  Setting up and preparing for this short
  and fast algorithm takes another 150 lines.

| My code is not perfect, and part of the reason it isn't is that the
| language has deficiencies.

  You ridiculous idiot.  You probably even _believe_ this bullshit.

| But I don't want to do it for CMUCL, SBCL, CLISP, Genera, ACL, ThinLisp,
| and every other implementation.

  Have you ever wondered how all these implementations sprung into being
  from nowhere when people like you do not want to implement things they
  say they want?  Ever wondered how all of this "free software" depends on
  people's willingness to implement things that sometimes are _boring_ and
  which some lazy fuck like yourself does not want to do?  

| In other words, if I pick one implementation and stick to it, I'd be fine
| - but then, so would I picking a Scheme implementation, OCAML, or a system

  It is not a question of picking one implementation and sticking with it,
  but of actually using an implementation to get what you want.  If you are
  so inept that you cannot design and implement something with an interface
  that does not expose the implementation-dependent features, that is not
  the fault of any language.  Whether to "stick with" an implementation is
  an orthogonal issue to whether you use implementation-specific features.
  If you want to make something really useful that needs to be portable or
  the foundation for something portable, you will probably need to use some
  implementation-specific features.  If not, you could have done it fully
  portably, right?

  Then there is the issue of how _often_ you need to use such featuers to
  implement common/standard things and how hard it is to do so.  You seem
  to believe that as soon as it is necessary to do something like this, you
  have found a flaw in the language.  This is fantastically misguided.

| But each system does its own non-weird magic, in an incompatible way.
| That's called non-portability.

  If you use one implementation's internal stuff and expect it to work
  elsewhere, yes, but it is the assumption that you can do that that is
  flawed.  If you use another implementation's internal stuff to provide
  the same interface to the same functionality, you have done a good thing.
  This is how smart programmers design both compatibility layers and pave
  the ground for new standards.

| I'm just criticizing CL, and there unhappily seems to be no one to ask
| about fixing that.  (Well, actually, raising the problem in c.l.l will
| hopefully attract the attention of implementers on the problem and its
| known solutions, so they might provide efficient APIs to multivalent
| strings/streams and modular integer operations).

  So if I understand you right, you think it is perfectly OK for a vendor
  to use internal, implementation-specific features to implement a common
  or standard specification (or, in case you are not quite up that level of
  quality, just fix things your way), that is perfectly OK, but if you do
  it yourself, it is _not_ OK?  Just _why_ is it that you cannot do this
  yourself?  What makes it so important to you that somebody else do the
  dirty work that you do not want to do yourself?

| >   You have to get at the bytes where they are actually found, just
| >   after they have been read, and just before they are written.
| >   Anything else is pretty damn stupid.

| Sure. Who said otherwise?

  You have strongly implied "otherwise", you insuffable numbnut.

| This just means more buffering to handle (costs development, performance,
| space, semantic gap, etc.)

  ... and this is where you say it!  This "more buffering" crap that _you_
  think is necessary is in fact _not_ necessary for your particular needs.
  As you well know, the MD5 algorithm uses 64-byte blocks and it does not
  care one hoot where they are.  If you use the _same_ buffer that you just
  read data into from the external source, you can actually get at the raw
  bytes _before_ they are interpreted as characters.  This is not hard to
  do.  This is not even difficult.  This is _not_ rocket science.  All this
  requires is that you are willing to study your implementation or talk to
  the vendor and get at the underlying buffer.  You are really annoying in
  the way you keep thinking that no better solution than your own can exist.

| Actually, it calls for doing everything with bytes, and nothing with
| characters (unless wrapped in a macro for immediate conversion), in any
| portable program sensitive to such problems -- except that this precludes
| the use of many text-processing libraries, which is the abstraction
| inversion.

  Wrong, you insufferable numbnut.

| Your claim all throughout was that text-processing was not about bytes.
| Well, it isn't about characters either, you know.

  Sigh.  Quit your stupid game-playing, will you?

  I think you are no more than another stupid troll who will never be
  satisfied no matter what anyone provides you with, and who will certainly
  never do any decent work on your own to get what you claim to want.

  Norway is now run by a priest from the fundamentalist Christian People's
  Party, the fifth largest party representing one eighth of the electorate.
  Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.