This depends on the language. Common Lisp, for example, has plenty of iteration constructs, including the (IMHO) fabulous loop macro (and Lisp programmers certainly don't shy away from using them). Others generally have fewer iteration constructs, but often they are still there. To what extent one uses iteration vs. recursion is, I'd wager, largely a function of culture and taste for various languages.
Syntax is often minimalistic.
Ever tried to get ML's syntax into your head?:-) I like Lisp myself (which has a fairly simple syntax, although there is some there - you still do need to remember how special forms and macros work individually) because the syntax is minimalistic. Some languages are hairier, though.
Tend to be interpretted, so have the advantaged of being interpretted (altering source at run-time etc)
This is just false. Lisp, for example, is typically compiled, just differently from the way to which people may be accustomed (some modern Lisp systems, e.g. Corman Lisp, don't even have interpreters). Many of these languages, however, are interactive which is a different thing. In the aforementioned Corman Lisp, for example, everything that you type into the read-eval-print loop gets compiled right away on the spot, so you don't notice it the same way you would compiling C, for example. ML, OCaml, Haskell, Clean, etc. all have compilers too, and many implementations are capable of making native executables.
Different philosophy regardling variables, sometimes completely untyped, sometime no variables at all.
Again, this depends on the individual language, and possibly what one means by variables.
Really? I implement most of my code at work in Common Lisp, and I don't seem to recall having to "rebuild every library" I ever wanted. There are three good solutions - use the tools provided by one's lisp environment (this is of course implementation dependent, but a decent enviroment will have a whole raft of tools), find outside code that does what you want (CLOCC or the CMU repository, for example), or, if necessary, use C (or other) libraries (which is nearly trivial in most Lisp implementations that I've seen).
At least one person (Kent Pitman) who was involved in writing the ANSI Common Lisp standard is regularly found in comp.lang.lisp. Perhaps a polite question to him would find him willing to share some of his experiences (also, you can surely find some of that in the archives of c.l.l as well).
Yes, you will write unportable code if you deviate from the standard, which is one of the consequences I suggest that one weigh before doing it.
As far as your example goes, it's clearly one of the canonical examples of undefined behavior in C/C++, but what is a logical way to resolve it, and what consequences does that have for the language as a whole? Is a solution for this (which may involve considerable added complexity - I don't know, but presumably any solution will affect a general class of situations and not just this one particular one) worth enough compared to simply leaving it unspecified and requiring another line of code to force the programmer to more explicitly declare his intent? Again, I don't know - you'd have to ask someone who knows a lot more about language design and implementation (and C/C++'s in particular) than me.:-)
I think this may be true of many languages. I'm not familiar with the C/C++ standards, but the Common Lisp standard also leaves many things undefined. There are reasons for doing this (I think there was some discussion of this recently in comp.lang.lisp, if you'd like to check.) There may be more than one reasonable thing to do; instead of forcing one behavior, it is then left up to the implementation. It may be desired to give implementers some room for experimentation in order to discover what the best thing to do is for inclusion into a later standard. Sometimes it legitimately doesn't matter. Sometimes the committee simply couldn't reach an agreement on what to do.
The best solution (at least in the case of Common Lisp) is to read the standard, not to use things which depend on undefined behavior without very careful consideration and understanding of the potential consequences, and to complain very loudly at one's vendor whenever the standard is not being followed properly.
The preceding post brings to fore an important point in math - there are most often several prominent books for a subject (at least up to the early graduate level), and it's a good idea to find the one best suited to oneself rather than just blindly using what may be assigned for a course. I bring this up because I (unlike the previous poster) prefer Ahlfors to any other complex analysis text that I've seen - however, it's perfectly reasonable that he finds Conway of more use (and others will prefer Churchill, Narasimhan, green Rudin, etc., all of which have different merits and faults that will make them more or less suitable depending on the student).
Normally in the circles I moved in, "Baby Rudin" meant the Principles of Mathematical Analysis, whereas "Green Rudin" and "Blue Rudin" referred to the Real and Complex Analysis book and the Functional Analysis book respectively. I don't think people referred to just "Rudin" without qualification. And there was no nickname for the book on function theory in the unit ball of C^{n}, but then again, not too many people around me were interested in that.:-) So we're probably just coming from slightly different cultures.
The original poster may well have been referring to denser books of Rudin, like say Real and Complex Analysis or Functional Analysis, or even Function Theory in the Unit Ball of C^{n}.:-) (All of which are, nonetheless, fine books.)
I have to do some of my development in Windows, and boy was finding Dolphin Smalltalk a nice thing for me. And no, I'm not some holdover from the 80s - when I started to do programming in the past couple of years (my training is really in mathematics; I wound up here via a winding path), I looked into various languages, tried them out for some of the things that I need to do, and found that two "old-timers" languages (Common Lisp and Smalltalk) fit many of my needs (which, incidentally, are not at all exotic - I do programming for a small trading firm).
It's a shame that so many people have preconceptions about various languages (often formed on the basis of where they were twenty years ago rather than where they've advanced to today) and therefore avoid checking them out to see what good things they can do.
>It's like the Common Lisp "for" loop (macro),which has hundred of possibilities nobody uses in practices.
I'm curious which loop keywords, for example, you think are extraneous. It seems to me that there are pretty good uses for all of them, and I know that I've had occasion to use most of them in some context.
>Also none of the CL libraries are OO.
Really? CLIM looks pretty heavily OO to me (as are other graphics libraries for Lisp, e.g. Lispworks' CAPI). Streams and the condition system are often implemented in CLOS. CommonSQL had both object-oriented and functional interfaces. Etc.
Moreover, Pythoners should easily be able to read Lisp - ignore the parentheses and read it by the indentation (while one is writing Lisp code, a decent editor will take care of most of the details with parentheses). That's what we Lispers do, isn't it? And it's exactly the same argument Pythoners make vis-a-vis reading and writing their language.
And let's not even get into how wonderful CLOS is.:-)
This is probably true. Of course, the statement "X is a good language and can be used for more than it is currently if people would just stop typecasting it." is true for many languages X./p?
Many of them do, although as always, it depends on what you want to do. For Scheme, consider something like DrScheme. For Common Lisp, both Xanalys and Franz have good commercial environments. And these are just examples. Further, it's usually fairly easy to use at least C code from these languages, so the amount of code available is greater than it might look at first. I don't know as much about the statically-typed side of things, but from what digging around I have done there, I think that there is often a reasonable amount of stuff available there too.
At any rate, I certainly find that my Xanalys Lispworks environment gives me everything that I need to do a lot of the programming that I need to do.
Of course no one will deny that GC (as it exists currently) is not ideal for certain uses (e.g. real-time applications, as you mention). The problem is that there are so many things where the small potential penalty for using GC is far outweighed by its benefits, and yet it's still not popular for those things.
Hopefully Java is beginning to open people's eyes to said benefits, though I'd still rather have people come around and work in Lisp and Smalltalk. That's a different war, though.:-)
I'd say that most Lisp and Smalltalk (and many other) systems already do pretty good automatic garbage collection (and not the reference counting type that can cause memory leaks), and have done so for some time. Nor does using this type of strategy for memory management slow things down much (if at all) - that seems to be mostly a myth caused by the state of garbage collection decades ago. While no one will deny that there are places where manual memory management is necessary, I think that for most higher level applications it is not.
Slashdot Mirror
This depends on the language. Common Lisp, for example, has plenty of iteration constructs, including the (IMHO) fabulous loop macro (and Lisp programmers certainly don't shy away from using them). Others generally have fewer iteration constructs, but often they are still there. To what extent one uses iteration vs. recursion is, I'd wager, largely a function of culture and taste for various languages.
Ever tried to get ML's syntax into your head? :-) I like Lisp myself (which has a fairly simple syntax, although there is some there - you still do need to remember how special forms and macros work individually) because the syntax is minimalistic. Some languages are hairier, though.
This is just false. Lisp, for example, is typically compiled, just differently from the way to which people may be accustomed (some modern Lisp systems, e.g. Corman Lisp, don't even have interpreters). Many of these languages, however, are interactive which is a different thing. In the aforementioned Corman Lisp, for example, everything that you type into the read-eval-print loop gets compiled right away on the spot, so you don't notice it the same way you would compiling C, for example. ML, OCaml, Haskell, Clean, etc. all have compilers too, and many implementations are capable of making native executables.
Again, this depends on the individual language, and possibly what one means by variables.
Really? I implement most of my code at work in Common Lisp, and I don't seem to recall having to "rebuild every library" I ever wanted. There are three good solutions - use the tools provided by one's lisp environment (this is of course implementation dependent, but a decent enviroment will have a whole raft of tools), find outside code that does what you want (CLOCC or the CMU repository, for example), or, if necessary, use C (or other) libraries (which is nearly trivial in most Lisp implementations that I've seen).
At least one person (Kent Pitman) who was involved in writing the ANSI Common Lisp standard is regularly found in comp.lang.lisp. Perhaps a polite question to him would find him willing to share some of his experiences (also, you can surely find some of that in the archives of c.l.l as well).
Yes, you will write unportable code if you deviate from the standard, which is one of the consequences I suggest that one weigh before doing it.
As far as your example goes, it's clearly one of the canonical examples of undefined behavior in C/C++, but what is a logical way to resolve it, and what consequences does that have for the language as a whole? Is a solution for this (which may involve considerable added complexity - I don't know, but presumably any solution will affect a general class of situations and not just this one particular one) worth enough compared to simply leaving it unspecified and requiring another line of code to force the programmer to more explicitly declare his intent? Again, I don't know - you'd have to ask someone who knows a lot more about language design and implementation (and C/C++'s in particular) than me. :-)
I think this may be true of many languages. I'm not familiar with the C/C++ standards, but the Common Lisp standard also leaves many things undefined. There are reasons for doing this (I think there was some discussion of this recently in comp.lang.lisp, if you'd like to check.) There may be more than one reasonable thing to do; instead of forcing one behavior, it is then left up to the implementation. It may be desired to give implementers some room for experimentation in order to discover what the best thing to do is for inclusion into a later standard. Sometimes it legitimately doesn't matter. Sometimes the committee simply couldn't reach an agreement on what to do.
The best solution (at least in the case of Common Lisp) is to read the standard, not to use things which depend on undefined behavior without very careful consideration and understanding of the potential consequences, and to complain very loudly at one's vendor whenever the standard is not being followed properly.
The preceding post brings to fore an important point in math - there are most often several prominent books for a subject (at least up to the early graduate level), and it's a good idea to find the one best suited to oneself rather than just blindly using what may be assigned for a course. I bring this up because I (unlike the previous poster) prefer Ahlfors to any other complex analysis text that I've seen - however, it's perfectly reasonable that he finds Conway of more use (and others will prefer Churchill, Narasimhan, green Rudin, etc., all of which have different merits and faults that will make them more or less suitable depending on the student).
Normally in the circles I moved in, "Baby Rudin" meant the Principles of Mathematical Analysis, whereas "Green Rudin" and "Blue Rudin" referred to the Real and Complex Analysis book and the Functional Analysis book respectively. I don't think people referred to just "Rudin" without qualification. And there was no nickname for the book on function theory in the unit ball of C^{n}, but then again, not too many people around me were interested in that. :-) So we're probably just coming from slightly different cultures.
The original poster may well have been referring to denser books of Rudin, like say Real and Complex Analysis or Functional Analysis, or even Function Theory in the Unit Ball of C^{n}. :-) (All of which are, nonetheless, fine books.)
IBM's Visual Age IDE is written in Smalltalk (yes, even the Visual Age for Java IDE, although I believe they are trying to move this to Java).
I have to do some of my development in Windows, and boy was finding Dolphin Smalltalk a nice thing for me. And no, I'm not some holdover from the 80s - when I started to do programming in the past couple of years (my training is really in mathematics; I wound up here via a winding path), I looked into various languages, tried them out for some of the things that I need to do, and found that two "old-timers" languages (Common Lisp and Smalltalk) fit many of my needs (which, incidentally, are not at all exotic - I do programming for a small trading firm).
It's a shame that so many people have preconceptions about various languages (often formed on the basis of where they were twenty years ago rather than where they've advanced to today) and therefore avoid checking them out to see what good things they can do.
>It's like the Common Lisp "for" loop (macro),which has hundred of possibilities nobody uses in practices.
I'm curious which loop keywords, for example, you think are extraneous. It seems to me that there are pretty good uses for all of them, and I know that I've had occasion to use most of them in some context.
>Also none of the CL libraries are OO.
Really? CLIM looks pretty heavily OO to me (as are other graphics libraries for Lisp, e.g. Lispworks' CAPI). Streams and the condition system are often implemented in CLOS. CommonSQL had both object-oriented and functional interfaces. Etc.
>Which language did constructs like '5.times {do this}' come from: Smalltalk? Eiffel?
Smalltalk has such things (with slightly different syntax), but I don't know enough history to tell you if they originated there.
Amen.
Moreover, Pythoners should easily be able to read Lisp - ignore the parentheses and read it by the indentation (while one is writing Lisp code, a decent editor will take care of most of the details with parentheses). That's what we Lispers do, isn't it? And it's exactly the same argument Pythoners make vis-a-vis reading and writing their language.
And let's not even get into how wonderful CLOS is. :-)
Since most Smalltalks interface nicely with C, why not just use both Smalltalk and C as appropriate?
This is probably true. Of course, the statement "X is a good language and can be used for more than it is currently if people would just stop typecasting it." is true for many languages X./p?
Many of them do, although as always, it depends on what you want to do. For Scheme, consider something like DrScheme. For Common Lisp, both Xanalys and Franz have good commercial environments. And these are just examples. Further, it's usually fairly easy to use at least C code from these languages, so the amount of code available is greater than it might look at first. I don't know as much about the statically-typed side of things, but from what digging around I have done there, I think that there is often a reasonable amount of stuff available there too.
At any rate, I certainly find that my Xanalys Lispworks environment gives me everything that I need to do a lot of the programming that I need to do.
Of course no one will deny that GC (as it exists currently) is not ideal for certain uses (e.g. real-time applications, as you mention). The problem is that there are so many things where the small potential penalty for using GC is far outweighed by its benefits, and yet it's still not popular for those things.
Hopefully Java is beginning to open people's eyes to said benefits, though I'd still rather have people come around and work in Lisp and Smalltalk. That's a different war, though. :-)
I'd say that most Lisp and Smalltalk (and many other) systems already do pretty good automatic garbage collection (and not the reference counting type that can cause memory leaks), and have done so for some time. Nor does using this type of strategy for memory management slow things down much (if at all) - that seems to be mostly a myth caused by the state of garbage collection decades ago. While no one will deny that there are places where manual memory management is necessary, I think that for most higher level applications it is not.
A nice page of pointers to more information on this is at: Xanalys' Memory Management page