From ... Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!134.222.94.5!npeer.kpnqwest.net!nreader2.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Common Lisp, the one true religion! References: <9nc1vu$6a2ng$1@ID-60069.news.dfncis.de> <3B9A68B6.4AF52FE0@isomedia.com> <3208966756647218@naggum.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3209007891180601@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 63 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Sep 2001 07:04:52 GMT X-Complaints-To: newsmaster@Norway.EU.net X-Trace: nreader2.kpnqwest.net 1000019092 193.90.206.67 (Sun, 09 Sep 2001 09:04:52 MET DST) NNTP-Posting-Date: Sun, 09 Sep 2001 09:04:52 MET DST Xref: archiver1.google.com comp.lang.lisp:15998 * Erik Naggum > Not to mention the fact that these guys are taught from day one that they > cannot be trusted to remember the types of their variables and now they > are asked to relinquish their one safety net: type checking in the > compiler. * Ray Blaak > Well, they can't be trusted. Or, if they can, other users of their code > cannot. Or, they do remember, but mistype things. The point is that > mistakes happen, and extra safety nets provide useful value in the > appropriate situations. OK, I should have elaborated, but the point is that the appear to lose their safety nets because all they know about is static typing. They do not realize that when you have dynamic types, you cannot just use the binary values, you have to do runtime type checking, instead, but to make people with "binary" written on their foreheads understand this, you have to tell them about how you represent your type-tagged binary values and how inexpensive and painless your type checking really is on modern hardware. My underlying point was that to get a C head to think Lisp, you have to give him a lot of nitty-gritty implementation details to re-establish his feelings of safety and trust which you took away from him several times. > The issue of static type checking is orthogonal to the syntax style of > Lisp. One can easily imagine a Lisp extended to have decent static > checking (perhaps optionally) enabled for it (or at least a CL in which > declare forms could be relied on to give decent warnings or errors on > mistaches). I would just _love_ to be able to write code that used the hardware for what it was worth in Common Lisp. In fact, I have been thinking about this and implementing various things for this over many years. A friend of mine took one of my embryonic sets of ideas at one time and tinkered with the gcc backend, but by the time he was finished with it, it had lost all its Lispiness, but at least it was quite possible to thinker with the gcc backend. If this could be done well, it would be possible to enter a new era of foreign-function interfacing and writing code in Common Lisp that would be usable by other programs. Due to our very different ABI, we live in a separate world, and using some other language to do some of the work for us is way expensive compared to most other languages that work well with each others, both in programmer time and at runtime. > That static type checking is not as necessary in Lisp as compared to many > compiled languages does not nullify its utility as another tool in the > programmer's toolkit. Precisely. And since static typing is most frequently exloited to allow compilation of code that uses hardware types efficiently, I think the lack of direct access to hardware types is one of the things that make the transition from other languages much harder. The types you are taught to think in tend to influence how you think, to paraphrase the Sapir-Whorf hypothesis. > Taken to the extreme, the "real programmers don't make mistakes" idea > would have us forgo language support for any error detection. I have never even implied that real programmers do not make mistakes. They just make _other_ mistakes. ///