From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!news2.kpn.net!news.kpn.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: What obstacles do Common Lisp programmers face? References: Mail-Copies-To: never From: Erik Naggum Message-ID: <3219783396565211@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 101 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Jan 2002 00:16:40 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader2.kpnqwest.net 1010794600 193.71.66.49 (Sat, 12 Jan 2002 01:16:40 MET) NNTP-Posting-Date: Sat, 12 Jan 2002 01:16:40 MET Xref: archiver1.google.com comp.lang.lisp:24079 * cubicle584@mailandnews.com (Software Scavenger) | In the past most of us used other programming languages, and usually poor | implementations of those languages. We spent vast portions of our time | fighting bugs and limitations in our programming languages and | development environments. It seemed like those obstacles were the main | reasons why we didn't get our work done almost as soon as it was assigned | to us. Even those who used Common Lisp in the past faced obstacles of | imperfect implementations and weak hardware. But now those obstacles are | gone, and we can all proceed full speed with Common Lisp on modern | hardware. Really? Which is the fully conforming, bug-free implementation of ANSI X3.226-1994 Common Lisp? I keep finding annoying discrepncies all the time, leading me to believe it is safe to depend only on a small subset of Common Lisp unless you install a direct line to your vendor's support department _and_ you get their attention when you say "conformance", the one word which leads some of them to ignore your bug report completely if they can think up a work-around or another way to accomplish your goal, but that is precisely what I do _not_ want, as it means different ways of doing the same thing in different implementations when we have a single specification that the vendors purport to implement. If car manufacturers made cars according to spec the same way software vendors make software according to spec, all five wheels would be of widely differing sizes, it would take one person to steer and another to work the pedals and yet another to operate the user-friendly menu-driven dashboard, and if it would not drive straight ahead without a lot of effort, civil engineers would respond by building spiraling roads around each city. I know I am in the small minority that reads documentation and standards and the like, but the operational definition of "conformance" can be stated very simply: If you read about something in the standard or in an accurate textbook and you can trust that it is always your own fault if it does not work as expected, the system is fully conforming. But this is predicated on people reading the standard or that someone has written similarly accurate textbooks and that readers of either pay attention to the details, are willing to _listen_ and _understand_ | Thus it seems that we should now get our work done the same hour we | decide to do it. If not, why not? What obstacles do Common Lisp | programmers still face, which make the work continue to take longer than | that? The fact that writing robust Common Lisp code in the Common Lisp spirit still takes considerable effort. Let me give an example. Suppose you develop a socket interface and think it is of sufficiently high quality that you want to share it. You could develop a class, service, that contained a host (with name, address family, address) and a port and a protocol (tcp or udp at this point), decide on a syntax and write functions to read and write objects of this class, and then include some easy-to-use designators like strings in this syntax, but internally, you always use your class. You would therefore develop a solid framework to refer to network services instead of, say, just using integers for IP addresses and ports, and these more complex things would be the end points of your socket interface, rather than more or less magic integers. This would offer something substantial above the "everything is really a machine integer" view that C and Unix has foisted upon the world and would afford an abstraction that allows people to refer to these services uniformly regardless of changes in the underlying implementation, such as we face when transitioning from IPv4 to IPv6, which some socket code has made more than painful. This would require some thought and more code, but it would produce a fully reusable piece of code, with a specification that would be worthy of standardization. But suppose instead you are the kind of engineer who really do not really believe in the value of Common Lisp, but just like its syntax while you still think in basic C terms and prefer meaningless integers instead of typed objects. Then you would force the user to engage in a tremendous amount of silly work, just like you would in C, but maybe half as much just to be nice, to refer to and use, not to mention set up, a network service. It would appear "nice" to those used to the bare-bones C stuff, but it would still suck relative to other Common Lisp functionality. This would take _much_ less time to write than Common Lisp standard-like functionality, and it may be "documented" enough to be useful for others, but it is not the kind of code you write specifications for. That is, you would be inclined to _re-implement_ something that was not written to specification quality rather than read the specification and use it as specified. Lots of code is written like this in languages that have fairly bad specifications in themselves, communities that do not care much about their specifications in the first place, and whose code sharing traditions usually are at the "it works for me" level, but Common Lisp has a specification that sets a standard for what new contributions should look like, as well. Good library design in C++ is said to be 25 times more expensive and complex than a simple user-level implementation that should be thrown away and re-implemented the next time it is needed. I would estimate that good library design in Common Lisp is about 10 times more expensive and complex than throw-away implementations, but that it is possible to make throw-away implementations "reusable" in Common Lisp with considerable effort, while it is not possible not in C++, so those who have not _designed_ for standard-library quality will think that additional libraries for Common Lisp need not be different from user code with documentation. This, again, unfortunately means that the ability to use other people's code in Common Lisp is much lower than that in other languages -- ironically because the effort to create good code is so much lower than in other languages that the extra effort to design top-notch quality does not seem worth it to many. /// --