* Bagheera, the jungle scout <baghe...@my-dejanews.com> | I think what josh is getting at is that in C++, it prevents you from | stuffing an 8byte value into a two byte parameter. If you don't have | type checking for this sort of thing, you can easily overflow your | calling stack, which is a bad no-no. Basically it is a matter of the | program protecting itself from the programmer.
this is not what static types are about. having static types _allows_ a compiler to skimp on (some) run-time type checking in the belief that all or most of the necessary type checking can be performed compile-time. this is, of course, as ridiculous a desire as wanting the compiler to prove the program free of any other bug, and has confused people to no end about what types are.
the important property of static types is not what would happen if you took it away, but what happens when you introduce it: you can take away some fences that you presume the compiler took care of, but the only actual consequence is that you leave open the whole area of precisely the kind of bugs you mistakenly associate with languages and compilers with dynamic types. even in the machine language, there are types and associated operations on them. some of the types may look very much the same when stored as bits in machine memory, but that is really an artifact of a context-dropping human viewer -- the archetypical example is the C notion of a pointer and its interchangeability with integers of some size. the stored pointer doesn't become an integer any more than a parked car becomes a source of money when broken into by a thief -- in both cases, it's how you use it that matters, and we have laws and regulations that say that parked cars are just that and not sources of money. if you willfully transgress these laws, you can turn a parked car into a source of money, but most people know they're doing something wrong when they do this, and even the lowliest thief who knows this is morally superior to the C programmer who abuses the bits of a pointer as an integer and takes it for granted.
any form of representation is subject to interpretation by a conscious mind that imputes meaning to the inherently meaningless. if, however, you partition the otherwise confusing representation space into various categories and make certain that you know which category something is of even at run-time, you don't get into the kinds of silly troubles that C/C++ fans think static typing got them out of: they never happen in the first place. or, to be more precise, any powerful system will allow you to break the rules, but it has to be on purpose, not by silly mistake, which is, unfortunately, what C/C++ give you absent static type checks.
so, "if you don't have type checking for this sort of thing", you move that type checking into the run-time, instead, and you _can't_ overflow your calling stack. I'd argue that _dynamic_ typing is how a program protects itself from the programmer, and static typing that makes a whole lot of errors and problems _arise_.
| I'm sure there are lots of ways to shoot yourself in the foot with Lisp.
how did you acquire your certainty about this who know nothing about what to do if you don't do static typing? (hint: if you want to destroy the world through Lisp, you have to work hard at it. if you want to destroy the world through C/C++, simply derefence a stray pointer or _forget_ to check for NULL, which is _manual_ run-time type checking.)
| C++ is a concerted effort to reduce that possibility of self-destruction.
it must be Slobodan Milosovic's favorite programming language, then.
| True, Lisp gives you the option of run-time program correction... but | sometimes requirements don't allow that comfort.
you know, I'm a little irritated by the ignorant newbies who come here and on other lists and aske all sorts of inane questions, but it beats having to deal with ignorants who think they now enough to make blanket statements.
>.... >| C++ is a concerted effort to reduce that possibility of self-destruction.
> it must be Slobodan Milosovic's favorite programming language, then.
Oh, grow up.
>| True, Lisp gives you the option of run-time program correction... but >| sometimes requirements don't allow that comfort.
> you know, I'm a little irritated by the ignorant newbies who come here > and on other lists and aske all sorts of inane questions, but it beats > having to deal with ignorants who think they now enough to make blanket > statements.
> I've never seen an expression like this. Perhaps I misunderstand, but > it looks to me like you're fighting the language in order to get > anonymous functions, FORGET ANONYMITY!
I don't think using standard library functions and idioms could be called 'fighting the language'. With the exception of 'compose' of course. 'compose' never made it into the standard but was in the original STL and is provided by the SGI STL libraries. 'bind2nd', 'mem_fun' and 'equal_to' are in the standard and the sort of code above is a reasonably common idiom in standard C++ - certainly not 'fighting the language'.
> You're sacrificing readable syntax just in order to not name > something - that's a rip off. So the function needs a name, so > what?
The amount of overhead in writing a function or class member to perform small operations can be larger than you realise. Every time I want to do something like the above i'd have to write a function, give it a name, pollute some namespace somewhere to do it. It also removes locality of code. The function to do the comparison for the specific string won't be located near where it is done. If I want to add one to every item in a vector I don't want to write a new function just to do this. I want to be able to 'inline' some code to make it easier to read:
I could write an iterative loop to do the above but there is more likelyhood of error (getting loop termination incorrect, etc). Better to reuse the standard library components.
for(vector<int>::iterator it = source.begin(); it != source.end(); ++it) { destination.push_back(*it + 1);
}
But getting back to the main subject. You mentioned in a previous post that you didn't see a use for closures. Yet you have the counted pointer and closure classes that you've created to try and emulate some of the functionality. This sort of thing is much easier to use and much more general if it is provided by the language itself. In Dylan the transform code above is:
it is amusing to give simple people something trivial to hold on to and watch them completely miss everything more challenging than kindergarten responses. you were tested, Joshua, and you failed, unsurprisingly. next time, do yourself a favor and consider getting the jokes and the ridicule and respond to the issues you now conveniently elided. that would _show_ us that you have yourself grown up.
it appears that you belong in comp.ai, still. followups redirected.
jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes: > Well Bagheera didn't state the problem quite right. The overall point > is that type checking saves you from tons and tons of late night typos > and logic errors.
Nothing in CL forbids you from type-declaring every variable. Knock yourself out. Don't forget to send bug reports when the compiler fails to use them well or flag problems, so your vendor will know you care.
But the language itself already supports this. It's simply up to the market to decide if this is what stands between it and success. I doubt it is, but you're welcome to make the case otherwise.
> And the time is when you have to deliver working code in the morning > and there isn't enough budget for more than a week more of testing! > So any error that gets into the code is far too many. It happens all > the time in the game business.
This is a pure engineering choice. To the extent you want to make it, you're right. But there are many things in the world that you don't know well enough at code-writing time and still have to code up. If the very same compiler won't compile until the code is type-safe, that code can't be delivered. What is right depends on your need (based on your personal requirements, project requirements, and customer needs).
I won't try to tell you not to write declarations if you won't try to tell me that I must write them. As to the question of how they are used, the language is designed in a way that it doesn't affect the semantics--it's purely a performance issue, to be sorted out by individual vendors as they see fit. There are a lot of vendors. Surely one of them will care. Or grab CMU CL and start from there. It cared a lot about declarations.
> <evil voice> WELCOME TO MY WORLD. HA HA HA HA HA! </evil voice>
> Passing the wrong parameter, parameters in the wrong order, the wrong > subfield etc. are common typos and often caught by the compiler -
Yes, already done. But remember also that passing the wrong parameter may not be fatal. Error handlers may catch it. The code may be going to get updated before it's run. The caller may be wrong or the callee. I would not like to see any of these flexibilities removed.
> especially if you design your class interfaces to catch as much as > possible.
Lisp is a language for being flexible. That is why it has survived all these years. I think it's fine for you to give up your flexibility on a case by case basis, but please don't confuse your personal need with a design theory. None of the things you're saying are false but neither are they "uniquely determined points of view".
> In code that rarely runs or isn't expected to run under > normal conditions, this sort of correctness checking is very > important.
You don't say what your point is.
This sounds like fodder for bug reports. IMO, There is nothing wrong with the language in this regard. You're welcome to disagree, but please be specific about what you'd like to see done instead so that people (including myself) can evaluate whether your perfect world infringes theirs.
* jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) | The overall point is that type checking saves you from tons and tons of | late night typos and logic errors.
well, type checking is necessary, but it appears that you don't know the difference between compile-time and run-time type checking, and assume that without compile-time type checking, there wouldn't be any. _that_ would be a source of tons and tons of typos and logic errors. however, the ridiculously simple-minded static type checking in C++ restrict you to a single line of inheritance, has no universal supertype, and offers no way to know the type of an object at run-time except by embedding it in a class and using RTTI. that is sufficiently inconvenient that the customary way to deal with multiple types of return values is to use an "invalid value", like the infamous NULL pointer.
| Passing the wrong parameter, parameters in the wrong order, the wrong | subfield etc. are common typos and often caught by the compiler - | especially if you design your class interfaces to catch as much as | possible. In code that rarely runs or isn't expected to run under normal | conditions, this sort of correctness checking is very important.
it sounds like you think you're telling people something new. why? this is so obvious it's been taken care of in much better than to require the programmer to declare the types of _all_ objects _explicitly_, which is, unsurprisingly, a major source of typos and logic errors, not to mention recompilation and header file (interface) changes that need to propagate to other team members.
oh, by the way, since I see your favorite argument coming: knowing C++ is part of growing up. discarding C++ is a matter of course once you have grown up. explicit type declarations is useful for new programmers the same way bicycles for kids have support wheels. few kids argue against their removal.
I want to make it clear that I haven't been trying to argue that C++ is better than LISP.
What happened is that I stumbled into a thread on comp.ai where a few people, a couple of whom I know enough about to respect, were arguing that LISP is more appropriate than C++ for AI.
Now in my work (game programming) I don't really have a choice, I more or less have to use C++.
What I wanted to find out is what exactly were the reasons that some preferred LISP so that I could abstract those strengths or methods into my work, under the limitations I work under.
Unfortunately I got sidetracked by an evangelist who was more interested in convincing me to use a specific language than in talking about programming techniques and I also ended up trying to defend and explain the limitations I work under - none of which is actually an attack on the usefulness of LISP. The strongest thing I have to say is that my company is not going to be willing to let its programmers use LISP, that some of the reasons for this are quite valid and that I haven't been given enough ammunition to challenge anyone's opinion on the matter.
So everyone who thinks been defending LISP from a detractor, you can calm down, that's not what is going on.
On 04 May 1999 13:30:47 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>* Philip Morant wrote: >> C and C++ map more closely to the Chicken Pulley Unit's >> instruction set than any other high-level landwich. You could write a >> LISP compiler in C, but you'd have quite a problem if you wanted to >> write a C compiler using LISP.
>Symbolics had C, Fortran and I think pascal compilers written in, erm, >Lisp.
>I was really disappointed when I found they had an X implementation, >only to discover when looking at the source that it was just MIT X, >compiled with their C compiler.
An X implementation written in a Lisp would indeed be extremely interesting. Definitely would need some interesting compilation techniques to stay fast; it would doubtless trample some bugs out of existence. -- "Microsoft builds product loyalty on the part of network administrators and consultants, [these are] the only people who really count in the Microsoft scheme of things. Users are an expendable commodity." -- Mitch Stone 1997 cbbro...@hex.net- <http://www.hex.net/~cbbrowne/lsf.html>
jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes: > What I wanted to find out is what exactly were the reasons that some > preferred LISP so that I could abstract those strengths or methods > into my work, under the limitations I work under.
It's not a full list, but it might be helpful to you.
(Someone noted after I wrote this article, that I'd failed to mention automatic storage management (gc) in the article; kind of a glaring omission. Oh well..)
< I miss closures and lambda functions the most when using some of the < stl algorithms. For example: < < class Person < { < string getName(); < }; < < vector<Person*> people = ...; < < // Find a person with the name 'John': < vector<Person*>::iterator it = find_if( < people.begin(), < people.end(), < compose( < bind2nd(equal_to<string>(), string("John")). < mem_fun(&Person::getName))); < < I would much prefer writing an anonymous function inline: < < vector<Person*>::iterator it = find_if( < people.begin(), < people.end(), < method(Person* p) { return p->getName() == "John"; } ); < < Excuse the ugly syntax. < < The main problem with closure simulators in C++ is the memory < management and providing access to the local variables without having < to create a class which copies and stores them. < < Chris.
You can get local functions with gcc. Can't imagine what I would do without them.
* Joshua Scholar wrote: > Passing the wrong parameter, parameters in the wrong order, the wrong > subfield etc. are common typos and often caught by the compiler - > especially if you design your class interfaces to catch as much as > possible. In code that rarely runs or isn't expected to run under > normal conditions, this sort of correctness checking is very > important.
This is a good argument. It would be more convincing if there was empirical evidence that C++ systems are more robust than CL ones developed in similar circumstances. Although I'm working from small samples, I'd say the evidence is that C++ systems are several orders of magnitude less robust than CL ones.
Also, of course, CL supports type declarations considerably more precise than C++, and compilers are free to check those at compile time. They typically don't, I guess because it turns out empirically that this stuff doesn't help you much.
On 05 May 1999 08:09:48 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>* Joshua Scholar wrote:
>> Passing the wrong parameter, parameters in the wrong order, the wrong >> subfield etc. are common typos and often caught by the compiler - >> especially if you design your class interfaces to catch as much as >> possible. In code that rarely runs or isn't expected to run under >> normal conditions, this sort of correctness checking is very >> important.
>This is a good argument. It would be more convincing if there was >empirical evidence that C++ systems are more robust than CL ones >developed in similar circumstances. Although I'm working from small >samples, I'd say the evidence is that C++ systems are several orders >of magnitude less robust than CL ones.
Well, as I said in my last message, this whole subject is a sort of deceptive detour away from my actual question. I wasn't trying to say that CL is inferior in general, I was just sidetracked into defending the limitations I have in my job as a game programmer - when that wasn't my original question at all.
C++ has quite enough power to support all kinds of robust paradigms, you just need to have the right tools and practices. My own personal programming style emphasizes keeping myself out of trouble and building the tools it takes to represent my problems abstractly. Many programmers, for instance, find writing templates to be a forbiddingly hard process - it was hard for me too for the first few years, but I kept forcing myself to do it until it became second nature.
So I don't need empirical evidence that average programmers can write robust C++, all I need to know is that the three programmers in my office can.
You understood that my point was that when you don't have time to test all of your control paths, having even a weak form of automatic code verification is much more of a necessity than luxury. I keep hearing that LISP supports building extensive layers on top of the language. Perhaps you can build an advanced compile-time type checking and constraint verification system on CL. Lint for CL.
If you want to support low level programmers (like Game programmers and device driver programmers) then you could also add: 1. More limited extension to the object system that supports inline methods (and therefor static linking) 2. A Modula like section of unsafe operations and memory management. Sometime you need to get away from Nanny. This part you would probably need the compiler source for.
I hear people say you should use the right tool for the job, but there is no reason that one language couldn't be eventually extended to cover all needs. And since the LISP community has always played with features that the rest of the world considered too exotic or too dangerous, it doesn't sound impossible that you'all could extend LISP again. This time, for once, it would involve extending LISP downward toward meeting the lower level languages instead of upward toward the experimental horizons. It wouldn't do any harm, right?
Oh, and while you're at it, why not define a standard parser for mathematical notation input. Lots of people are used to mathematical notations and want to be able to program with them.
>>>>> "Christopher" == Christopher Browne <cbbro...@news.hex.net> writes:
Christopher> An X implementation written in a Lisp ... would doubtless Christopher> trample some bugs out of existence.
But wouldn't such a thing (a bug free X) render non-trivial amounts of C programs useless :-)
As it has been said: you can promote a bug to a feature by documenting it.
---------------------------+----------------------------------------------- --- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrikvej 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: c...@tbit.dk --- URL: http://www.telebit.dk ---------------------------+----------------------------------------------- --- Hit the philistines three times over the head with the Elisp reference manual. - peto...@hal.com (Michael A. Petonic)
cbbro...@news.hex.net (Christopher Browne) writes: > On 04 May 1999 13:30:47 +0100, Tim Bradshaw <t...@tfeb.org> wrote: > >* Philip Morant wrote: > >> C and C++ map more closely to the Chicken Pulley Unit's > >> instruction set than any other high-level landwich. You could write a > >> LISP compiler in C, but you'd have quite a problem if you wanted to > >> write a C compiler using LISP.
> >Symbolics had C, Fortran and I think pascal compilers written in, erm, > >Lisp.
> >I was really disappointed when I found they had an X implementation, > >only to discover when looking at the source that it was just MIT X, > >compiled with their C compiler.
> An X implementation written in a Lisp would indeed be extremely > interesting. Definitely would need some interesting compilation > techniques to stay fast; it would doubtless trample some bugs out of > existence.
Ahem! CLX? Remember that in the beginning there were TWO implementations of X, C/Xlib and CL/CLX.
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
On Wed, 05 May 1999 07:54:24 GMT, "Joshua" == Joshua Scholar <jo...@removethisbeforesending.cetasoft.com> writes:
Joshua> I was just sidetracked into defending the limitations I have in my Joshua> job as a game programmer - when that wasn't my original question at Joshua> all.
sorry to continue the side-track, and maybe this has been mentioned before, but I seem to remember that Super Mario was developed/prototyped using a Lisp system written/sold/resold? by Allegro Inc. And I would imagine that in general Lisp is the perfect match for the games area, due to its immense flexibility. You would have your high level code spit out assembler or so.
Joshua> C++ has quite enough power to support all kinds of robust paradigms, Joshua> you just need to have the right tools and practices.
Many programs/programmers seem to do this by building there own dynamic typing systems etc. into C or C++, which sounds like a bad case of re-use to me.
Joshua> Many programmers, for instance, find writing templates to be a Joshua> forbiddingly hard process - it was hard for me too for the first few Joshua> years, but I kept forcing myself to do it until it became second Joshua> nature.
(is C++ the right language if you need a few years to master it? Hell, even lambda, mapcar, and closures are easier)
Joshua> Oh, and while you're at it, why not define a standard parser for Joshua> mathematical notation input. Lots of people are used to mathematical Joshua> notations and want to be able to program with them.
I remember seeing one a while ago on this newsgroup (or comp.lang.scheme); I'm sure it's floating around somewhere, I'll try and see if I can find it.
Cheers, Philip -- The mail transport agent is not liable for any coffee stains in this message --------------------------------------------------------------------------- -- Philip Lijnzaad, lijnz...@ebi.ac.uk | European Bioinformatics Institute +44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
> Swapping Control_L and Caps_Lock is extremely common. If you want to > do that, then [copy and paste from the xmodmap manpage]:
^^^^^^^^^^^^^^^ *blush*, and I always complain when people stick to their prejudices instead of investigating the possiblities ;-) (my prejudice being the false assumption that the caps lock key is "different")
Thank you! (now let's see what my left little finger thinks of this).
>>>>> "Tim" == Tim Bradshaw <t...@tfeb.org> writes:
Tim> Also, of course, CL supports type declarations considerably more Tim> precise than C++, and compilers are free to check those at compile Tim> time. They typically don't, I guess because it turns out empirically Tim> that this stuff doesn't help you much.
CMUCL can handle these precise type declarations, and I've found that it can help out quite a bit. If you declare something as, say, (integer 0 42), it might be possible for the compiler to deduce that all operations always result in a fixnum, and therefore use only fixnum operators instead of resorting to a generic integer arithmetic routine.
jo...@removethisbeforesending.cetasoft.com (Joshua Scholar) writes: > Oh, and while you're at it, why not define a standard parser for > mathematical notation input. Lots of people are used to mathematical > notations and want to be able to program with them.
lisp has infix syntax. while this may seem to be catering to the machine, it is a small price to pay in order to reap the benefits of a regular syntax. (writing the reader/parser is easier with infix, but that's not the reason for using it.) you can make your own `operators' (since they're all functions).
C++ restricts you to overloading the existing set of operators or making functions (which are infix in C++ too). what if *two* (or more) kinds of multiplication make sense? e.g., let A and B be 3x3 matrices. you might want to multiply them as matrices, or you may wish to multiply element-wise. matlab has * and .* operators to handle this. you can overload the * operator in C++ but good luck in introducing a .* operator. ok, so you make a function or cast the matrices to element-wise beasts and * away on that.
so far it's just silly notations, but what happens when you want to scale up and use templates or macros? it is here that the *everything* is infix in lisp that makes a big difference. the function/operator occupies the same slot (i.e., first in a list) no matter what it does. the lack of myriad special cases and syntax contortions really pays off in the end since the macros can be more ambitions in power and scope.
the annoymous functions and closures are also part of this. it's not a matter of namespace pollution so much as awkward syntax. immagine a C dialect in which you had no direct number constants, but were obligated to first making a constant before you could use them.
instead of
int x,y;
....
y += x + 3
you had to do
const int three = 3; int x,y;
....
y += x + three;
it works the same. but it's awkward. the definition of three wanders away from the point you need it. and what if someone else made
const double three = 3.0;
somewhere else?
why shouldn't you be able to just write a function in the same way you can just stick in a regular number constant? having to name every function is just as tedious as having to name every numerical constant. it's exactly the same.
in C and C++, functions are very much second class citizens. in lisp they are bandied about just like any other kind of data. this allows a level of abstraction - you can program at a higher level.
in mathematical notation, you can just introduce a function. many times you operate on the functions as if they were mere elements. consider, for example, functional analysis (to say nothing about more esoteric abstraction such as you find in algebraic topology).
we could turn right around and ask of C++, why not define a standard parser for mathematical notation input - like arbitrary functions. Lots of people are used to mathematical notations - like functions - and want to be able to program with them - just as easily as with numbers or arrays of numbers.
Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes: > Ahem! CLX? Remember that in the beginning there were TWO > implementations of X, C/Xlib and CL/CLX.
Weren't we talking about the server side of X? Or have I again missed something important?
> > Well Bagheera didn't state the problem quite right. The overall > > point is that type checking saves you from tons and tons of late > > night typos and logic errors.
> Nothing in CL forbids you from type-declaring every variable. Knock > yourself out. Don't forget to send bug reports when the compiler > fails to use them well or flag problems, so your vendor will know > you care.
It is true that one cannot fault the language for this. Nevertheless, until vendors listen to and act on these 'bug reports' the problem persists in practise. I agree strongly with Joshua that lack of static type checking is one on the main disadvantages of (at least) the commercial Common Lisp implementation I am familiar with.
> But the language itself already supports this. It's simply up to > the market to decide if this is what stands between it and > success. I doubt it is, but you're welcome to make the case > otherwise.
Well, I tend to disagree. Adding static type checking (optional of course) would go a long way towards convincing experienced C++/Java programmers to take another look at Lisp. Of course, I can be certain only about my own opinion, others may disagree. I have heard a representative of a Lisp vendor seriously argue that Lisp code must look as simple as Java code to be competitive. IMHO, static type checking is an order of magnitude more important than that. :-)
> I won't try to tell you not to write declarations if you won't try > to tell me that I must write them.
Sure, there is no need to take away this flexibility.
> > In code that rarely runs or isn't expected to run under > > normal conditions, this sort of correctness checking is very > > important.
> You don't say what your point is.
The point is probably this: A C++/Java compiler cannot catch all errors, especially not design or logical errors, but at least it catches most simple errors like typos, passing the wrong number of arguments, passing a wrong argument, etc. With existing Lisp implementations many such errors are detected only at runtime even when declarations are used. This is less problematic with mainline code which is likely to be run by the developer anyway, but typos in sections of the source code that are less frequently run have the habit of crashing in the hands of a user, or the QA department if you're lucky. Yes, you should test all your code, but the kind of bug we're talking about is often introduced by changes that are so 'obvious' that many developers don't imagine a bug may have been introduced.
Joachim Achtzehnter <joac...@kraut.bc.ca> writes: > > > Well Bagheera didn't state the problem quite right. The overall > > > point is that type checking saves you from tons and tons of late > > > night typos and logic errors.
> > Nothing in CL forbids you from type-declaring every variable. Knock > > yourself out. Don't forget to send bug reports when the compiler > > fails to use them well or flag problems, so your vendor will know > > you care.
> It is true that one cannot fault the language for this. Nevertheless, > until vendors listen to and act on these 'bug reports' the problem > persists in practise. I agree strongly with Joshua that lack of static > type checking is one on the main disadvantages of (at least) the > commercial Common Lisp implementation I am familiar with.
Then you should use the power of the marketplace. If you cannot get enough people together to say that this is more important than other things, then perhaps it is not. I mean this seriously. It is very easy for people to complain about things CL doesn't do. I believe it is helpful if you make a list of the things that are promised in the next release of your favorite vendor and tell the vendor your decision to purchase future copies is premised on their doing this thing instead of something they've promised. I think most people either say this and then purchase anyway (meaning they weren't really serious) or aren't willing to say what they'd give up (meaning they think the system has infinite resources).
> > But the language itself already supports this. It's simply up to > > the market to decide if this is what stands between it and > > success. I doubt it is, but you're welcome to make the case > > otherwise.
> Well, I tend to disagree. Adding static type checking (optional of > course) would go a long way towards convincing experienced C++/Java > programmers to take another look at Lisp.
I really honestly and not facetiously think that if you believe this with certainty, then you might consider getting a Lisp and putting your own money and reputation on the line over this. Because the Lisp vendors are doing this day in and day out, and they do not casually assign their resources away from the thing you describe. They might be wrong, of course, but if you really believe that there is a time-tested way to demonstrate that.
Thought:
Nothing in the world is "important" or "unimportant". Things are only "more important" and "less important" than other things. Say what you think is less important and you'll know what your leverage is to get this so-called more important thing.
> Of course, I can be certain > only about my own opinion, others may disagree. I have heard a > representative of a Lisp vendor seriously argue that Lisp code must > look as simple as Java code to be competitive. IMHO, static type > checking is an order of magnitude more important than that. :-)
So you mean you'd pay an order of magnitude more money? Or what do you mean by that?
> > I won't try to tell you not to write declarations if you won't try > > to tell me that I must write them.
> Sure, there is no need to take away this flexibility.
> > > In code that rarely runs or isn't expected to run under > > > normal conditions, this sort of correctness checking is very > > > important.
> > You don't say what your point is.
> The point is probably this: A C++/Java compiler cannot catch all > errors, especially not design or logical errors, but at least it > catches most simple errors like typos, passing the wrong number of > arguments, passing a wrong argument, etc. With existing Lisp > implementations many such errors are detected only at runtime even > when declarations are used. This is less problematic with mainline > code which is likely to be run by the developer anyway, but typos in > sections of the source code that are less frequently run have the > habit of crashing in the hands of a user, or the QA department if > you're lucky. Yes, you should test all your code, but the kind of bug > we're talking about is often introduced by changes that are so > 'obvious' that many developers don't imagine a bug may have been > introduced.
Then maybe you should switch vendors. Tell other vendors that's what it would take to get you to swtich. But making this checking a requirement of the language would just mean there are fewer implementations (since it would define some implementations not to be valid). It would not suddenly create more resources to do these changes. Standards are about codifying de facto practice, not about forcing practice. The marketplace is where to make your feelings known, either as a choosy purchaser or an aggressive vendor with a vision. If you are willing to be neither, then I suggest you might ask yourself what it means to say you hold these beliefs strongly. If you think you are being one of those things (probably the choosy customer) and you are finding it doesn't help, then perhaps you should think about how to create a customer organization that better represents your market segment, or think about whether there are enough people for you really to be a market segment.
Markets are elusive. Just because you can't prove one is there doesn't mean it's not--I'm not saying it's an easy business. But what I'm saying is that wishing as you are doing doesn't make it so. The game is all about resources. What resources vendors have and what products people give financial resources in exchange for. If you don't affect that, you will affect nothing. That is how markets work (and don't).
I apologize for the somewhat strained tone of this message. I don't mean to jump on you personally. But this is kind of an exemplar of something I hear from people from time to time that I never quite get around to responding to and this was a good chance.
> Then you should use the power of the marketplace.
Agreed. By posting my opinion about this matter I hope to influence my current vendor who may have an interest in my continued interest in their product, as well as my vendor's competitors who may want to get my business.
> If you cannot get enough people together to say that this is more > important than other things, then perhaps it is not.
Certainly. But this is no reason to refrain form expressing ones opinion.
> I mean this seriously. It is very easy for people to complain about > things CL doesn't do.
Well, sorry for coming across as somebody who is whining. I am critical of all programming languages that I've come across so far. This doesn't mean one can't get work done with them. But being able to get work done with a programming language is also no reason not to try improving it (or its implementations). I am currently using Lisp and appreciate its advantages. Don't see why I should not express my opinion about its weaknesses.
> > I have heard a representative of a Lisp vendor seriously argue > > that Lisp code must look as simple as Java code to be > > competitive. IMHO, static type checking is an order of magnitude > > more important than that. :-) > So you mean you'd pay an order of magnitude more money? Or what do > you mean by that?
The decision to use Lisp, and to pay money for an implementation and how much, wasn't for me to make in this case. In any case I am talking here about mindshare. How can Lisp grow its user base? This is not simply a question of who is willing to pay how much for which features. It is more a question of how many potential developers are comfortable with the idea of developing in Lisp. The static typing issue is important in my opinion, others may disagree.
> I apologize for the somewhat strained tone of this message.
No need to apologize, your response contained useful thoughts and was quite civilized. But if I may say so, the same can't be said about certain other posters in this thread. This is another point which can easily put off some developers from considering a non-mainstream language like Lisp. In C++ newsgroups one can have serious discussions about possible language improvements, here one is attacked and called an 'ignorant newbie' and worse names. Of course, one cannot blame the language for this either... :-)
>>>>> "Joachim" == Joachim Achtzehnter <joac...@kraut.bc.ca> writes:
Joachim> persists in practise. I agree strongly with Joshua that lack of static Joachim> type checking is one on the main disadvantages of (at least) the Joachim> commercial Common Lisp implementation I am familiar with.
Get another implementation? I'm not that familiar with commercial implementations on this topic, but certainly CMUCL can do a lot of static type checking, roughly equivalent to any C/C++ compiler, and, in some ways, a lot more.
Joachim> Well, I tend to disagree. Adding static type checking (optional of Joachim> course) would go a long way towards convincing experienced C++/Java Joachim> programmers to take another look at Lisp. Of course, I can be certain Joachim> only about my own opinion, others may disagree. I have heard a
I always thought C++/Java programmers were turned off by the syntax, not the lack of type checking. As a C/C++ programmer, I rather enjoy not having to type everything when writing in Lisp.
Joachim> arguments, passing a wrong argument, etc. With existing Lisp Joachim> implementations many such errors are detected only at runtime even Joachim> when declarations are used. This is less problematic with mainline
Get a better implementation?
Joachim> you're lucky. Yes, you should test all your code, but the kind of bug Joachim> we're talking about is often introduced by changes that are so Joachim> 'obvious' that many developers don't imagine a bug may have been Joachim> introduced.
I would say your software engineering process is broken in this case, and no language will protect you from this kind of problem.
On 05 May 1999 18:44:31 -0400, Raymond Toy <t...@rtp.ericsson.se> wrote:
> Joachim> you're lucky. Yes, you should test all your code, but the kind of bug > Joachim> we're talking about is often introduced by changes that are so > Joachim> 'obvious' that many developers don't imagine a bug may have been > Joachim> introduced.
It's not about 'obviousness' so much as pressure an lack of time.
>I would say your software engineering process is broken in this case,
Welcome to the real world. The only time I've ever seen an office where the programmers had all the time they needed for designing, documenting, debugging and other 'engineering' process tasks was in a government job. But then I work in the games industry which is entertainment after all - flakiness and ego are expected to be main ingredients of both management and engineering here. Not that I'm complaining - for one thing I fit right in :)
>and no language will protect you from this kind of problem.
>Ray
Oh, a language can help by making testing less necessary. It's a good thing for it to be doing in any case.
