[unz]

Lisp is a dangerous language that shouldn't be taught or used these days. There are plenty of superior programming techniques.

Mathematical programming - linear programming, finite domain constraint programming, constraint logic programming, logic programming, relational programming

Static functional programming - ml, haskell

A good modern introduction to programming is Concepts, Techniques, and Models of Computer Programming, by Peter Van Roy and Saif Haridi. It's far superior to the commonly mentioned lisp book Structure and Interpretation of Computer Programs.

[pmelendez]

>"Mathematical programming - linear programming, finite domain constraint programming"

Huh? I am not sure if you are trolling or if you copied and pasted that without further investigation, but comparing operation research algorithms (such as linear and finite domain constraint programming) with a programming language is at the very least... disingenuous.

> "Lisp is a dangerous language"

That's a very strong and weird statement, would you mind to explain? because to me is completely the opposite.

[unz]

(putting aside the rudenss and cluelessness of your comment ...)

Operations research type algorithms can be thought of as forward chaining compared to prolog's backward chaining. Prolog implementations usually integrate them in because they are more efficient in many cases.

Lisp's dangerousness was why ML was invented by Robin Milner.

[drcode]

Sounds like you're an "anything that doesn't have static compile-time typing is dangerous" kind of guy.

[krichman]

Static typing is greatly beneficial, with HM it doesn't require a lot of annotation (people that use it find type annotations to be beneficial anyway). Languages that don't offer strong typing and GADTs are blub languages.

[PuercoPop]

Common lisp is strongly typed, everything is of type t[1]

[1]: http://www.xach.com/naggum/articles/3284289178877169KL2065E@...

[unz]

That's basically the consensus among professional academics on the matter. Also among well respected programmers in senior roles like Joshua Bloch and John Carmack.

[drcode]

The problem is static typing is applicable to only a subset of any particular programming task (in other words, even a Haskell or ML program that compiles is not necessarily guaranteed to be correct, insofar as it still may not produce the output desired by the programmer.)

Because of this, it introduces incidental complexity into a program, because it subdivides the programming task into a part that can be addressed via static typing and a part which is not purely an issue of typing.

Admittedly, in most cases this extra complexity is worth the cost (especially with the type of high performance code written by Bloch/Carmack) but at the end of the day the job of a modern computer is to make things easy for humans and not make things easy for the computer, so in the long run it's foolish to say humans need to "think like a computer" and use a static type system, instead of allowing humans to use a more natural, dynamic programming model that is more natural for us to use.

[FreeFull]

Sorry for the long rant ahead.

This is anecdotal, but I find that in general a static, strongly typed language actually helps me when I am writing the program. One quarter of the time, I find that the code I just wrote doesn't make sense and end up having a conversation with the compiler and REPL until it works.

One important place where I find types help me is error handling. I typically prefer to have Maybe/Option, Either, or similar types for normal errors, and to have exceptions reserved for when the program enters an unrecoverable state and needs to crash.

There are also cases where a dynamically typed language will error during runtime, and where a statically typed language would have instead errored during compile time. It is possible to encode invariants into types, for example to force all red-black trees to be balanced.

I haven't found a case yet where such an error wasn't due to flawed reasoning on my part, and depending on the language implementation it is possible to optionally defer type errors to runtime. The language I tend to use the most also has an escape hatch to allow dynamic types if you want them (implemented as a library).

Regarding incidental complexity, in a Hilney-Milner language, most code can be written without any type annotations whatsoever, although in my language of choice (Haskell), it is standard practice to include type annotations anyway to help readability.

Encoding invariants into the code does increase the complexity, and you'll see most library writers strike a balance between complexity and correctness. If you go for an even stronger type system than Haskell's (such as Coq's, Agda's or Idris's) then it is possible to encode all invariants using the types, although type inference doesn't work as well anymore.

Static, strong typing is there to help the programmer, and typing a dynamically-typed language is probably easier. Haskell's type system helps automatic unit testing libraries such as quickcheck and hunit work better. Computer hardware doesn't care about types, but rather where the bits and bytes are and what points to them. Static typing is there purely for the programmer's benefit, rather than the computer's.

I can't say that writing software in a language that has a weak type system is anywhere as enjoyable, and I find myself having to debug my code.

[nnq]

Just upvoted you for "Lisp is a dangerous language that shouldn't be taught or used these days.". You just made a huge number of people curious and willing to learn more about Lisp by saying that :)

Jokes aside, the Van Roy book is something to add to my "to read" list. Try posting it again in a comment that doesn't get downvoted to hell, maybe others will notice it too.

[nickik]

What kind of argument is this.

> constraint logic programming, logic programming

The book you comment on actually implments a logic programming system.

Both common lisp and clojure have implmentations of high performance logic systems.

> Static functional programming

Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do. Its arguable that some of this (in the CL) are even more powerful then what haskell has.

Im not sure on what the other types of programming are but the do not at sound like things that a library can not do. Can you give a example of something that you can not do in clojure or commen lisp that is possible without in these other languages that you have not actually provieded.

> Concepts, Techniques, and Models of Computer Programming

It is a very good book. However 99.99% of programming today are not done with these modern concepts. It are actually langauges like clojure that push some of the technics like constraint logic programming more into the mainstream. Check out core.logic.

[freyrs3]

> Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do.

I don't know about that, Haskell has quite a few very non-trivial extensions in it's type system that I have yet to see replicated outside of research languages. ( Rank-N Types, GADTs, Kind polymorphism, etc).

[nickik]

See things, like this http://en.wikipedia.org/wiki/Qi_%28programming_language%29 or https://github.com/clojure/core.typed

[freyrs3]

Both of those projects implement fairly simple type systems, they both even look simpler than even ML. Having at least outer rank-1 quantification is what I consider a "modern" typing system.

[nickik]

Im not a expoert. But I think at least Qi is as advanced as haskell or ml. The clojure one is relativly new and not jet full featured.

[iopq]

> Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do.

Except they let you do MORE, which is often bad. For example, in Haskell STM you have a static guarantee that you don't have mutation or IO inside of a transaction. How are you going to guarantee that with Clojure STM?

[nickik]

That is absolutly possible with a static type system.

[unz]

But that's not the main style of programming. If you teach someone lisp he'll hack around with functions and macros and not realize that his problem could be elegantly written in constraint programming.

Most of the time the majority of code (written by good programmers) is in constraints or relations, so why encase that in a functional language with parenthesis everywhere (I've programmed a fair bit in lisp and don't mind parenthesis at all, but it get's annoying after you're used to the elegance of prolog syntax).

[nickik]

People who have problems need to know about diffrent solutions. Just forcing everybody to use some langauge that supports some of these from the ground up want change that.

You want a language that is flexible to expand into new fields.

Also you have still not provided with these magical programming languages you are talking about. Is there any language you yourself would use?

As far as I know many concepts like contraind logical programming is not really ready for prime time, in most cases.

[unz]

(you tamp down a little with your rudeness - why would multiple decades old tech be 'magical')

Prolog with clpfd and chr, Mozart/Oz, Sql, Clips. Libraries like gecode, java choco.

There aren't any new ways of programming that have been invented. There's basically the mathematical programming (constraint/logic/relational/linear), functional, procedural, oo, concurrent, stack. You're not going to come up with something new during a session of lisp hacking. You'll just reinvent the above multiple times.

[nickik]

I never said I invent something new. Lisp is a flexible languages that can incorparate new concepts better then other langauges. How nice is it to work if a logic programming system implmented within java compared with the same within clojure.