> Maybe it is terrible for you...

It is. I know of the examples you mention (and some of them like planning may not really involve much numerical work) but the fact is that unless you're doing things by scratch (like starting from GEMM), numerical libraries are often badly documented, slow or otherwise incomplete (or a mixture thereof). You can disagree with me, but Tamas Papp who maintained a bunch CL libraries seems to have moved over to Julia entirely.

> As for the "type system being weak",

I meant weak in the sense that it's not very expressive, so as to allow better static type inference. I'm not saying CL should be static for "correctness" reasons, but for removing the user from having to have declarations all over the place.

Let's reify. If I were to create a bunch of matrix classes (matrix-float, matrix-double, ignoring the lack of sugar), CL provides no way to declare a generic method 'mref' to be intelligent enough to know what the output will be, given the input type. Even getting the type in the compiler-macro is implementation dependent. In C++ this is extremely easy with templates, and in Haskell you do it via a type declaration (AFAIK).

Yes, you can get around it via lots of macro magic, but this is so fundamental that you might as well create a new language (like Qi/Shen).

> Let's reify. If I were to create a bunch of matrix classes (matrix-float, matrix-double, ignoring the lack of sugar), CL provides no way to declare a generic method 'mref' to be intelligent enough to know what the output will be, given the input type.

I am not sure if I follow you.

If you have "matrix-float, matrix-double" you are perfectly able to define a "mref" generic method that acts smartly depending on the input type. This is one of the most basic features of the CLOS OOP system. Maybe there is something missing on your explanation?

Have done exactly that using GOOPS which is Guile's equivalent of CLOS:

  scheme@(guile-user)> (use-modules (aiscm sequence) (aiscm element))
  scheme@(guile-user)> (define a (arr (1 2 3) (4 5 6)))
  scheme@(guile-user)> (get a)
  $1 = #<sequence<sequence<int<8,unsigned>>>>:
  ((1 2 3)
   (4 5 6))
  scheme@(guile-user)> (get a 1)
  $2 = #<sequence<int<8,unsigned>>>:
  (4 5 6)
  scheme@(guile-user)> (get a 0 1)
  $3 = 4
  scheme@(guile-user)> (get (get a 1) 0)
  $4 = 4

That's the whole point of macros: To be able to create embedded domain specific (mini) languages.

[1]: https://github.com/wedesoft/aiscm

I don't dispute the effectiveness of Common Lisp, but

> There is an automatic correspondence between objects and types

is almost never what is meant by a "strong type system" -- it more commonly means that types are checked at compile time, rather than run time. I don't doubt that any given lisp hacker could slap together a type inference system on top of CLOS, but as far as I can tell it's not built in.

So, on the strong-to-weak type system spectrum, I would say:

* Idris (lawful good, first-class dependent types)

* Haskell (very strong, some support for dependent types)

* Java (strong, some generics)

* Julia (hybrid, code is analyzed for type inference during JIT, invariant types)

* Common Lisp (weak by default, afaict)

* Python (very weak)

* Javascript (weakest)

* PHP5, Perl (chaotic evil)

Types checked at compile time is called "static".

Strong has various meanings. Ada is "strong" versus C being "weak" though the basic Algol-like model is not so different, and if we don't count tagged types, neither language is dynamically typed in any way. (So if "strong" means "static", we would not be able to use the strong/weak terminology to contrast these languages!)

"Strong" in this context mean various things, ranging from C having holes in the type system that allow punning and bad memory references, to C having automatic conversions that are unsafe: for instance assigning a floating-point value to an integer location without an explicit conversion operator which handles situations when the conversion is impossible. Or not having a character type distinguished from an integer type.

C++ has more "strongly typed" enums than C; and what that means is that you can't assign an integer value to an enum object without a cast.

ANSI Lisp is fairly strong, but allows some relaxations: car on an empty list, integers usable where floating-point values expected (a bit like C) and such.

You are confusing "strong/weak" typing with "static/dynamic" typing.

CL is for the most part strongly typed. Python too. In CL there are almost no automatic typecasts.

Javascript and PHP and Perl are textbook examples of weakly typed systems. The interpreter (or compiler) can even allow things like 1 == "1".

With implementations like SBCL, CL also allows for static type checking with the "declare" and "proclaim" keywords, this checks types before runtime, if they can be inferred before executing the code.

Common Lisp is strongly typed (type mismatches result in a sensible error), but is by default dynamically typed, unless you annotate.

The type system is not capable of useful, extensible polymorphic types, though.