Subject: Re: MD5 in LISP and abstraction inversions From: Erik Naggum <erik@naggum.net> Date: Fri, 02 Nov 2001 00:43:19 GMT Newsgroups: comp.lang.lisp Message-ID: <3213650592348094@naggum.net> * Francois-Rene Rideau <fare+NOSPAM@tunes.org> | 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.