Subject: Re: Java is really convenient. Re: Sun thinks about switching Java to S-expression syntax: Lava From: Erik Naggum <erik@naggum.no> Date: 1999/02/17 Newsgroups: comp.lang.lisp Message-ID: <3128223210845958@naggum.no> * cbarry@2xtreme.net (Christopher R. Barry) | The specification for C's "int" and CL's "FIXNUM" are virtually identical. I'm baffled. have you _read_ the specifications? a fixnum is simply a more efficient integer, and some implementation-defined limits are less than or equal to MOST-POSITIVE-FIXNUM, but you have know your compiler real well before (+ fixnum fixnum) does not cause a bignum when needed. what, precisely, is you gripe with the size of FIXNUM, anyway? methinks you just have a fixation that you're trying blame Common Lisp for. | > | Why can't Lisp become more popular? | > | > why can't opera be more popular? why can't football be less popular? | | I think your analogy is not the most suitable one. I think using Lisp | over C or Java boils down to more than just personal taste and factors | analogous to your analogy. my point was that you ask a useless question that has no useful answer. it is rare that you can explain why something is popular at any given time. (and "marketing" begets the question "why did it work?", which all marketing people will tell you is not something you sit down and predict.) | > | What's stopping it? | > | > people like you. | | Okay, what can I realistically do to make it more popular? you can stop posting drivel and actually go read the specification and ask questions instead of posting wrong answers to questions people don't ask. you see, people are _detracted_ from a gravitation towards Lisp as they gain experience in their field and want self-improvement. this is not at all the path you get if you ask about or measure popularity. | Has anyone done this already? Can I download a pre-done layer of | documented macro definitions from somewhere that will at least work | across CMUCL and Allegro CL? If I have to do it myself, not a huge deal | as long as I only do it for functions I use and not everything, but | standardization just makes it *that* much easier. I think your doing it yourself is a valuable exercise in understanding (1) how this stuff should have been implemented, (2) the effort that goes into standardization, and (3) the effort that goes into sharing quality code with other people. maybe then you will realize what you're asking for when you want everything for free. | A little while back before my homework caught up with me I actually kinda | started to work on making a uniform interface between the ext: and excl: | file operation functions of Allegro and CMU Common Lisp which provide a | lot of the same functionality so that I could write some intelligent | Debian package management utilities for my personal use to make up for | where Apt and dpkg don't get it right for my purposes. I don't want to | commit to using only CMUCL or Allegro CL for this or anything else just | yet. this at least explains your problems. what you're doing is a waste of time, although the purpose and goal is clear, so consider this: what you sit down and design because CMUCL and Allegro CL do not agree on some interface design is something you barely know how works and what you will actually need from it once it does work. once it works well enough for you to build something on top of, you will need to redesign it after you have started to build something. only if you chose one implementation and got enough stuff working to start feeding data back into the design process can you hope to get the design right. what you're doign is premature abstraction without an actual purpose or goal. "to make it work in both Allegro CL and CMUCL" should not be a goal, it should fall out your efforts as a result. | It's just *that* much more of an (IMO) unnecessary inconvenience. programming is all _about_ "unnecessary inconveniences", and every step of progress tries to reduce their number. that's why good programmers choose languages that have less unnecessary inconveniences than other languages, but if you think you can avoid unnecessary inconveniences, I think you should consider death and taxation first. | Wasn't the whole point of Common Lisp that a lot of implementations were | providing largely equivalent functionality with a slightly different | interface? yes, historically, this was the motivation for the standardization, as it is with most good standardization, incidentally. | Everyone does sockets and threads these days and a lot of the extension | functions across implementations do almost the exact same stuff. also true, but standards are basically removing functionality from the market. the issue changes from "do you support FOO" to "do you conform to the specification of FOO". the former is a feature if true, but otherwise draws a blank. the latter draws a blank if true, and is otherwise a reportable bug. to make standards work, all vendors must agree to stop considering their features features, and start viewing them as requirements. incidentally, this process parallels your Java vs CL attitude: you argue against CL because you regard features in Java as requirements of CL. this is, to put it mildly, hopelessly naive. | Are there any large, sophisticated, real-world apps that are written | these days in CL that don't do threads? I cannot imagine otherwise. why do you? | I should mention that CL-HTTP includes a lot of functions and macros that | unite some of the extension features found in all the CLs and I've found | it very useful and it's saved me a lot of time already. It was obviously | a lot of work to put all of that together and it would be nice if this | stuff could just always be relied upon to be there. well, you have the CL-HTTP sources, and it is apparently not a problem for you that you cannot use it commercially (which was a gripe you had with Common Lisp implementations, so I have a minor problem understanding what your actual and real concerns are). #:Erik