Subject: Re: size of executables? From: Erik Naggum <erik@naggum.net> Date: Mon, 17 Sep 2001 17:34:17 GMT Newsgroups: comp.lang.lisp Message-ID: <3209736856918331@naggum.net> * Aleksandr Skobelev <2269@mail.ru> > An any concept is not valid in absolute sense. It is only valid in > context of current discussion after all sides who take part in that > discussion came to agree about the meaning of that concept and until the > end of discussion. That is basically what I said. Please get rid of the silly arguments assuming anyone here are stupid enough here to argue about "valid in an absolute sense". Nobody has even given you cause to believe they think in such retarded terms. We all _know_ what context means and does to the validity of concepts and ideas. Please assume that people here are not lamebrained, OK? Let me repeat myself: Therefore, the _concept_ "standalone executable" is no longer valid. _You_ are, in other words, trying to abuse the context of the validity of the concept "standalone executable" beyond what it once was able to withstand. Standandalone executables no longer exist, except those in embedded systems. Everything else depends on a lot of supporting software around them that you simply cannot ignore. (I was wrong about boot loaders -- they depend on the BIOS, which are not standalone, either.) It is a very good idea to rid yourself of the whole notion of "standalone" in dealing with executables. It marks you as completely outdated in the modern computer world. > Computer's programs are intendent to be used but not debugged by users. That depends on what you consider "debug". I consider the famous DOS query "Abort, Retry, Ignore" to be a debugger interface, for instance. _Really_ good programs actually allow users to decide the fate of the system in face of unhandled exceptional situations, not just _die_, like crappy software does. It is highly unlikely that really complex software will not encounter unhandled situtations. If they turn into disasters, you have bugs. If they turn into a query to an operator, they are not bugs. The former requires static-style debugging by an off-site crew. The latter allows an on-site operator to handle the situation nicely and get the system back up and running. This is what we have system admins for these days. I thus consider your views of what computer programs are intended to do alarmingly outdated. You argue as if you work on an embedded system in isolation from everything else. If you do, please say so in explicit terms, do not drag in all the old, invalid concepts from that mode of operation for computers -- it is _truly_ outdated. > Debugging of broken programs is a task for programmers but not for users. Your view of what debugging consists of reveals a lack of willingness to listen to what people are telling you. Please drop this arrogance and start to listen. That _is_ why you came to this newsgroup, is it not? > As far as I remember in this thread I only expressed my opinion, that it > would be good for me and, probably, for Lisp, if some feature existed. You have asked us to help you with more information. Your "opinions" are the vehicles on which we try to deliver the answers your questions, because they constitute the context in which communication with you can take place. Therefore, they are not _just_ your opinions, but the whole framework of your mind when you come here to receive information. If it is clear that you are not able or willing to listen to information that says that your "opinions" are misguided (i.e, that your context needs to be expanded), you will not learn anything and only frustrate everybody. This is not mere suspicion. All newsgroups have "newbies" who come and ask questions in a context they are familiar with and refuse to listen to anything that does not work in their original context. It is one of the most annoying features of USENET. I actually expect people to _listen_ before they take the time to express any "opinions". A good USENET rule is to read a newsgroup for a couple weeks before you post anything. This may be too hard to do in some cases, but it is definitely not bad advice. ///