Subject: Re: On Lisp From: Erik Naggum <erik@naggum.net> Date: Sat, 08 Sep 2001 11:22:46 GMT Newsgroups: comp.lang.lisp Message-ID: <3208936964863906@naggum.net> * Mark Hulme-Jones > Surely part of the point of having a standardised Common Lisp is that I > can reasonably expect to change my vendor without having to change too > much of my source code? Yes, of course, but only that which has been standardized! This is why I want standardized features to be implemented fully everywhere, with no stupid exceptions and reluctance and bugs -- we iron out the standard part and then we move on to new things. As long as vendors and othes retard the common acceptance of the standard and the common trust in its implementation, it is so incredibly hard to move on. As long as someone can sit in a corner and whine about his pet conditional, that means that the bloody _conditionals_ are still an open issue and common agreement on sockets will have to put in a bid for resources along with such stupid and petty issues. The parts are _not_ standardized will have to just as implementation- dependent as people are willing to _accept_ elsewhere. In fact, the reason C and C++ have grown to such successes is that there are lot of implementation-dependent features that come with all systems that use those languages. C and Unix is a veritable treasure trove of special implementation details. C++ and Windows have the same relationship. If people had been whining "this is not in the ANSI standad", neither of these languages would have succeeded at all. > A standard should mean that I differentiate between different vendors > implementations based on factors like efficiency, the usability or the > development environment or the quality of their customer service. Yes, of course, but only for the standardized language. The rest of the environment you need to build real applications cannot actually be fully standardized. Just look around for the other language standards, to see how _little_ they actully standardize. Common Lisp standardizes so much more than most other languages. I refuse to consider the possibility that its high quality has turned Common Lisp programmers into spoiled, demanding brats, but some people make it so damn hard to stand fast on this refusal. > With Perl or Python I'd have to settle for what I get. In practice, you have to settle for what you get in the Common Lisp implementations, too, but for some reason, it is acceptable to be unhappy about it. The only part we have good reason _not_ to be satisfied with, is lack of conformance. If somebody wants to sell me a Common Lisp system, they had better live up to their claims, but I _choose_ them because of the extra-standard features. That is the point of having a standard -- both the specification and conformance should become a non-issue. > For widely-used features like sockets and perhaps regexps, a standard is > going to do much more good than harm, much as the CLIM does for user > interfaces. Well, if you think so, why have you not submitted a specification to the committee? > Non-adherence to such standards would make or break my choice of > implementation, giving vendors an added incentive to co-operate. Real standards turn an issue into a non-issue. You just use whatever is standardized. The fewer questions are asked about the legitimacy of a standard, the more successful it is. If you get a socket implementation that you have to fight when you need system-dependent socket options, have you really gained anything? (Java sockets are fairly crippled in this regard.) > It's just a question of which features you consider 'commoditised' enough > to require a definition that vendors should follow. For CL this means > things like hash tables, vectors, structs and classes. All I'm saying is > that it would be even better if Regexps and Sockets were included too. I hate regular expressions. Not because they are not powerful tools, but because they are too powerful tools, and everybody who makes a regular expression matcher has a different idea what kind of weird features should go in the regular expression syntax, with no way for users to extend this functionality without switching to a different regular expression package. I want to stop this cramming of features into the syntax and get a real pattern-matching _language_ that I can deal with at a much higher level than this character-by-character limitation that all regular expression packackes I have seen enforce. If regular expressions are such a boon to mankind why are they not built for sequences of all sorts of objects? I mean, the standard function search does that. > If by 'standard' you mean a written standard like that for ANSI CL, then > basically none, and I consider this to be a problem (though when and if > Microsoft's submission of C# and it's libraries gets standardised by the > ECMA there might be one). If on the other hand you mean a de-facto > standard, like that dictated by Sun for Java or the implementors of > languages like Rebol, Ruby and Python, then quite a few. By "standard" I mean a document that implementations are required to adhere to and which people other than the implementors have a say in developing. If that document is documentation for an implementation, it is just that, not a standard. There are many kinds of standards, but they have _one_ important thing in common: they are _specifications_. If a "de facto standard" has no specification that it can be held up to, I think it is a misuse of the term. > Unfortunately many, many others do not agree with me, and are prepared to > settle for de-facto standards like Java instead. Creating a written > standard for APIs/implementation of important new features could > conceivably boost the attractiveness of CL in many people's eyes. > Provided that attracting more users of the language is what one is trying > to achieve, of course. Yes, standards are marketing tools, too, but if they become too much of that, they are generally quite horrible as specifications for people who are supposed to implement them faithfully. However, nothing stops you from implementing a Common Sockets library that takes care of presenting a common interface to the various ways people have implemented these things. If you want this, build it. > I'm not trying to hold Common Lisp to a different standard. Perhaps what > I'm really saying is that if you want to make sure that people realise > how much better a standardised CL is than a de-facto standard like Java, > you'd better make sure that CL includes standardised ways of doing the > things that people want to do. You need an authority that people are willing to respect in order to get to this point. When vocal forces in the community cannot even respect an authority on the conditionals, arguably the most important part of the language, forget any chance of respecting an authority on sockets. When some people stick to their legacy ways in numerous trivial areas when they could not get them into the standard and refuse to accept the standard and change their ways in the community interest, there is no reason to expect them to respect something as complex as a socket interface. This is the insidiously infectious effect of quarreling over features in the standard. Psychologically, whoever wants to spend any time and money standardizing new things when grumpy and bitter old farts at the vendors express a very strong disdain for the work you do even before you have started? ///