a potential lisp convert, and interpreting the shootout
in [Lisp]
|
Prev: Pocket Lisp Machine
Next: Next Generation of Language
From: Jon Harrop on 8 Oct 2006 10:29 Stefan Nobis wrote: > That's what Thomas tried to say: In these cases there are so many ways > to put errors in your code of which only (very) few can be caught be a > static type system. In my experience, the vast majority are caught by the static type system. This is really what the static vs dynamic debate boils down to: a difference in belief. > Lisp is much more flexible and fun What makes Lisp more flexible and fun compared to OCaml? -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists
From: Pascal Costanza on 8 Oct 2006 10:43 Jon Harrop wrote: > Stefan Nobis wrote: >> That's what Thomas tried to say: In these cases there are so many ways >> to put errors in your code of which only (very) few can be caught be a >> static type system. > > In my experience, the vast majority are caught by the static type system. How do you know that? Do you write all your programs both in dynamically- and statically-typed languages, and keep a log of how many errors have been caught in which way? > This is really what the static vs dynamic debate boils down to: a > difference in belief. So what is it? Experience or belief? Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Jon Harrop on 9 Oct 2006 00:26 Pascal Costanza wrote: > Jon Harrop wrote: >> Stefan Nobis wrote: >>> That's what Thomas tried to say: In these cases there are so many ways >>> to put errors in your code of which only (very) few can be caught be a >>> static type system. >> >> In my experience, the vast majority are caught by the static type system. > > How do you know that? Do you write all your programs both in > dynamically- and statically-typed languages, and keep a log of how many > errors have been caught in which way? When I moved from dynamically typed languages to statically typed ones, I noticed the compiler picking up lots of errors that I would have had to debug at runtime (and hope that I happened to stumble upon them before selling the software). >> This is really what the static vs dynamic debate boils down to: a >> difference in belief. > > So what is it? Experience or belief? Both I guess. In my experience, this is quite task specific. Certain tasks (e.g. GUI work) are quite dynamic by nature, so static typing is less useful and dynamic typing is likely to be more concise. -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists
From: Ken Tilton on 9 Oct 2006 13:49 Jon Harrop wrote: > Pascal Costanza wrote: > >>Jon Harrop wrote: >> >>>Stefan Nobis wrote: >>> >>>>That's what Thomas tried to say: In these cases there are so many ways >>>>to put errors in your code of which only (very) few can be caught be a >>>>static type system. >>> >>>In my experience, the vast majority are caught by the static type system. >> >>How do you know that? Do you write all your programs both in >>dynamically- and statically-typed languages, and keep a log of how many >>errors have been caught in which way? > > > When I moved from dynamically typed languages to statically typed ones, I > noticed the compiler picking up lots of errors that I would have had to > debug at runtime Unresponsive! Of /course/ C++ (for example) nags you to death at compile-time, of /course/ CL frequently has to tell me '+ does not know what do with "your mama!"'. We knooooooowwwwww /that/. The question is specifically about bugs that make it into production. Of those that do in a Lisp app, how many would have been caught by a C++-like compiler. And vice versa: how often do C++ apps fail /because of/ type rigidity (see "Ariane 5"). And then we can look at trade-offs, bugs caught-not-caught vs cost of development, and consider how Lisp's overall lower cost of development leaves more $$$ for testing, and how Lisp's superior reflectivity makes possible better testing. Now I concede that that would be a terribly difficult research undertaking, so it is probably easier to find a really good programmer and just ask them which language is better. Hi. I am Kenny. Lisp is better. I did enjoy having C++ slap me around when I ported Cells to C++, such that by the time I got a clean compile the thing worked, so I see the advantage. But that was porting something, not inventing/discovering it. The "discovering" is important. I simply would not have stumbled onto Cells (and stumble I did) in anything other than Lisp. And that is why Lisp is better. hth, kt -- Cells: http://common-lisp.net/project/cells/ "I'll say I'm losing my grip, and it feels terrific." -- Smiling husband to scowling wife, New Yorker cartoon
From: jayessay on 9 Oct 2006 16:03
Ken Tilton <kentilton(a)gmail.com> writes: > production. Of those that do in a Lisp app, how many would have been > caught by a C++-like compiler. Or even *ML compilers. IME, such logic bugs are not caught at all by type systems. The two are orthogonal. > And vice versa: how often do C++ apps fail /because of/ type > rigidity (see "Ariane 5"). I agree with your basic position, but this is a category error in a couple ways... BTW: How 'bout those Yankees? <cough cough - choke> ;-) /Jon -- 'j' - a n t h o n y at romeo/charley/november com |