Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile." From: Erik Naggum <erik@naggum.no> Date: 29 Sep 2002 17:04:58 +0000 Newsgroups: comp.lang.lisp Message-ID: <3242307898188612@naggum.no> * Tim Bradshaw | A related point, it seems to me, is that reinvention is more-or-less | inevitable if the existing art is so bad that coping with it is too hard. This can be a good reason for re-invention, but then the smart re-inventor knows the past and what he needs to be better than. If re-invention only means that one treads the same old path all over again, it is very bad. And of course knowing the past is going to be hard. That is why psychologists have to study so many completely bogus psychological theories -- left to their own devices, past psychologists have invented all these wacky ideas, and future psychological inventors please take note: they were discarded. | So one escape from the wheel of reinvention is to try and come up with | systems that are well designed in the first place. The force of genious lies behind a significant shift in perspective more than in new ways to perform old tasks. We humans are pretty annoyingly limited when it comes to getting stuck in a well-known pattern and those who are not, tend to be more wacky than genius. | 1. Anyone who's read my previous article(s?) in this thread knows I | think redoing emacs in scheme *or CL*[1] is insane. I once started down that path, but having spent a couple hundred hours on a Common Lisp-based Emacs, decided that it was going to take a couple thousand hours before I had a system I would use myself and would be able to attract others to join in building. I still wonder what would have happened had I not gotten fed up, but the better system would also be harder to maintain than to build. Emacs moves on, and if I were to build another Emacs, would have to duplicate a /lot/ of effort. It would, in brief, be what I would do for the next few years. | 2. Anyone who has read the drivel I write for a bit longer knows my feelings | about XML. Every time I have to do something for which XML might seem | suitable, I just invent something else, largely so that I don't have to | cope with the ideas behind XML - other people's ideas. What can I say? I wasted 6 years of my life on SGML and related technologies only to find that when I wanted to translate my experience and knowledge and significant grasp of this technology into a book that would teach what I had found to others, I had to look real hard at all the braindamaged things that I had been willing to sweep under the carpet and found, to my horror, that SGML, once understood, could not possibly be worse implemented than SGML itself -- if you get the very valuable core ideas behind SGML, SGML was self- defeating because it had to cater to a huge number of idiotic requests and requirements that took away from its ability to express what it wanted to express, and it became such a horribly application-dependent language that you would have to retarded to write anything worse. I could not publish this in a book that would be a conceptual introduction to SGML and abandoned the whole language and my investment in time. Once every two weeks or so, I get mail from somebody else who have discovered the same thing after actually having tried to use SGML for something other than a stupid markup language. | XML and its encrustations seem to me to be classic examples of the existing | art being just too bad to deal with. I takes considerable time to understand this, however. If you do /not/ grasp the core ideas behind SGML and XML, you will probabl invent something worse, such as an ad-hoc binary format, and since most people would rather die than think (in fact they do), XML is better than what a braindead ignorant fool would invent from scratch. | So I think that in order to avoid endless reinvention it's *critical* to use | systems which are good enough[2] in the first place. There are rather few of | those around in IT, because they are *very* hard to produce. The C/Unix pair | is possibly one (but I think probably not), Emacs/elisp is, I think, one. | Common Lisp is the only system that I am pretty sure is one. I think Common Lisp is the only fundamental IT system that is better than just Good Enough. I am, however, dismayed at what every single vendor does with the language when it comes to presenting Common Lisp to "modern" stock computers. For instance, the lack of the full range of hardware integers really, really bugs me. I got a suggestion in the mail to look at the 8 new xmm<n> (128-bit) and mm<n> (64-bit) registers in the IA32 platform, and found that after spending a lot of time on programming specifically for these, there is absolutely no reason to stick to 32-bit integers on IA32. The too few legacy registers should be used for interaction with memory, and the mmx registers should be used for integer arithmetic. Not doing this is not using the Intel platform for what it's worth. However, this is not done in any of the Common Lisps available for the Intel platform, although it would give the compiler writer 8 64-bit integer registers and 8 128-bit numeric registers that could both be split into smaller registers if need be, and this would solve so many of the register starvation issues on that platform. This is the kind of thing that bugs the hell out of me. Then there is the Unix integration, which is abysmal and forces people to use other languages to do anything resembling systems programming. Dsspite all I know about Unix and Common Lisp, I do not feel that I write Common Lisp programs /under/ Unix. It is as if the Common Lisp programs run on a separate machine somewhere. And given that "feel", why not exploit the work in virtual machines and JIT compilers and related efforts in the Java and even the .NET community and let Common Lisp code become interchangeable and portable between all the implementations so that there could be a component market and you could actually develop on one platform and deploy on any number of others. These are the developments in a significant part of the software market these days, and it bugs the hell out of me that I have to choose whether to continue to use Common Lisp if I want to be a part of this. The effort to make a JVM run inside Common Lisp, for instance, is a really good idea. Now we need a CLVM that actually supports CLOS. Notice that these are not "user land" things, they require vendor support and just as much "develop a new system to use the new ideas" as any other revolution, but at least the programming language does not need to change, and we should be able to leverage off of all the existing Common Lisp skills, the standard behind it, textbooks, courses, and the long experience with the language to get things right. However, it takes people who actually /like/ Common Lisp to do this and who are professional enough to set aside their personal issues when implementing the standard faithfully so others can trust that the specification will be sufficient and they can concentrate on their application and not have to waste time on subtle incompatibilities. This would be slightly more interesting than a Common Lisp Emacs, but I actually think a Common Lisp Emacs would be so much easier to build once such a system was in place. -- Erik Naggum, Oslo, Norway Today, the sum total of the money I would retain from the offers in the more than 7500 Nigerian 419 scam letters received in the past 33 months would have exceeded USD 100,000,000,000. You can stop sending me more offers, now.