From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.43.194.69!fr.clara.net!heighliner.fr.clara.net!hamster.europeonline.net!newsfeed.europeonline.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: MD5 in LISP and abstraction inversions References: <87lmhrznup.fsf@Samaris.tunes.org> Mail-Copies-To: never From: Erik Naggum Message-ID: <3213559409134408@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 80 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Oct 2001 23:23:32 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader2.kpnqwest.net 1004570612 193.71.66.49 (Thu, 01 Nov 2001 00:23:32 MET) NNTP-Posting-Date: Thu, 01 Nov 2001 00:23:32 MET Xref: archiver1.google.com comp.lang.lisp:18957 * Francois-Rene Rideau | I was looking for a Common LISP implementation of MD5, but found none. Several implementations are available for those who ask, some as fast as those written in C, and about as low-level as C versions, too. | Horrible things that get in the way: CL characters, and lack of builtin | modular operators. Huh? You probably mean that you open a file with element-type character and since you get what you asked for, but not what you wanted, you blame the language instead of your own incompetence at expressing your wishes. If you really want to read a file of 8-bit bytes, specify it, and you get exactly what you want. | The problem is that CL purports to be a high-level language, but actually | provides gratuitously incompatible and subtly unusable access to what is | ought to be low-level constructs. Huh? This sounds like a disgruntled programmer more than a language problem. Perhaps we would be able to judge for ourselves if you posted the actual _code_ you wrote to arrive at these weird conclusions? | The world has standardized on low-level byte streams as the universal | medium for communication of data, including text. Which is a mistake, since they run into an enormous amount of trouble with supporting more than one character encoding. The Unix model is one of those "simpler than possible" models that do not actually work when pushed too hard. That some operations require punning on the lowest level of representation and that this is not only possible, but easy in C, is not necessarily a good thing. Such representational issues should be explicit. Even C++ has discovered the truth in this, these days. What has stopped you from using "low-level byte streams" in _your_ code? | Yet, CL strings are based on a pseudo-high-level characters that are not | portably interoperable with worldly text, much less efficiently. Whatever that means. I think you are simply seriously confused and would have come a lot further if you had asked for help or read _all_ the fine documentation before you became so frustrated, but that seems to be incompatible with the tunes to which some people's egos play. | That there can be direct support for >8 bit characters and for character | attributes is great, but, particularly when efficient portable | text-processing is meant, the only way is using (unsigned-byte 8), and | suddenly, all builtin support for any text-processing at all vanish. The myopia suffered by people who think 8 bits is sufficient is probably never going to be discovered as long as they stare at their data from a distance of only 1 inch. Just because you think you need a byte for a particular operation does not mean that you do, nor that anything else should conform to this particular requirement. Look, you are not doing text processing when you process bytes. It works in some environments and under some assumptions, but if you are dealing with text, you deal with characters, not their coding, and if you deal with bytes, you are not dealing with characters. It is that simple. Since the C mindset is so insidious and unconscious with those who suffer frm it, including some long-time (not Common) Lisp programmers, | CommonLISPers often diss Scheme for being such a small language, which | forces development of incompatible implementation-specific extensions for | any interesting work. Well, we have to face the fact that in today's | world, CL is also a small language by this criterion. Much much smaller | than C, SML, OCAML, Haskell, Mercury, Oz, Perl, Python, or whatever. What does this mean? Your conclusions seem to be drawn from a lot of bad experiernce, but there is no way to determine whether that is due to your incompetence or to whatever it is you conclude it must have been, blaming the language for your problems. Just post the evidence: The code and let people help you figure out what the real problem is. /// -- 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.