He lost me when he claims that "Lisp culture is hostile to mathematics". I mean, has he heard of Maxima? Axiom?
On the other hand, Haskell culture is more like "let's try to find the most general possible unifying principles that work for everyone, and let's use universal algebra / category theory / etc. to ensure our abstractions do not leak". And the type system is great help in this department. Algebraic data types make it harder to forget to account for all cases. Type system extensions allow the programmer to express more program properties statically, leveraging the compiler as a correctness verification tool. And all the categorical constructs expressed primarily as type classes (besides the already known Functor, Monad, Category, Arrow, etc., check Hackage for everything Edward Kmett has uploaded) are general patterns that arise everywhere, both in mathematics and in programming. Which is no surprise, because programming is mathematics.
So, back to the main point of my comment, while I would agree that "Lisp culture is hostile to mathematics" is unnecessarily too strong a statement, I would also say that most Lispers do not leverage mathematics to the extent one would expect from functional programmers.
The fact that you can name two math-related Lisp projects doesn't mean that those play a big role in "Lisp culture" in general.
How important are Maxima and Axiom for the average Lisper?
Are they pillars of the Lisp culture or outliers? There very well might be a thriving 1% math-loving Lisp community and a 99% who are hostile to math.
Those are the right questions to ask, not if counter-examples merely exist.
"Modern racecars are designed with high performance CAD / simulation software - race mechanic culture is therefore inseparable from this software culture" - that would be the absurdity
A similar example would be AI, which used to tightly connected with Lisp, but it's something that modern Lisp practicioners (post-AI Winter) don't care much for.
Macsyma for example was one of the first big and very useful Lisp applications which brought down Mainframes and Minicomputers of that time.
Macsyma led to: optimizing compilers with good maths performance in Lisp, the addition of many numeric data types to Lisp (bignums, floats, complex, ratios, ...), Lisp-based workstations, ports of Lisp to many architectures just to run Macsyma, ... Common Lisp then was standardized with an extensive numeric tower - which was reused for other languages like Scheme or Haskell. Even today a free version of Macsyma, called Maxima is used and maintained.
> Are they pillars of the Lisp culture or outliers? There very well might be a thriving 1% math-loving Lisp community and a 99% who are hostile to math.
Many Lisp users apply mathematics. Traditionally either directly with Mathematics applications (even RPL on the HP calculator stands for Reverse Polish Lisp) or in application domains like AI (signal processing, image processing, machine learning, etc etc.).
Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower.
What? There are several different numeric types. It's there to implement more advanced mathematics capabilities.
Like in Axiom, which runs on top of Common Lisp.
> Haskell's relatively fine-grained distinctions between numeric types is nothing like Lisp's numeric tower.
Haskell's numeric capabilities were in part copied from Common Lisp.
There is no such thing as multiple types in Common Lisp.
> Haskell's numeric capabilities were in part copied from Common Lisp.
Haskell's standard type classes include the notions of ring (Num), field (Fractional* ) and integer (Integral). (Notably absent is the notion of semiring, which would be useful for a type of natural numbers, though.) The importance of making these distinctions is that you can statically ensure that you are using certain algebraic structures but not others.
* Somehow floating points were invited to the party, but, hey! I guess no standard library can be perfect.
All in all, I did not intend to overly diss Common Lisp. It is a very flexible, expressive and powerful language. I am just saying that, at least from my point of view, Common Lisp does not look particularly inspired by mathematics.
Ugh; we're not calling out Haskell's numeric hierarchy as a good example, are we?
(Well, maybe it's a good example of how to handle numbers—although I find the lack of a positive-integer type a pain—but it's certainly not a good example of how to handle general algebraic structures, which is what it seems to pretend to be. What in the world is `sign` doing in there, for example?)
In another subthread I mentioned the absence of a Semiring type class, which should be a superclass of Ring (Haskell's Num) and provide addition, multiplication and fromNatural. So, yeah, I am not entirely happy with Haskell's standard library either, but the situation in other (general-purpose) programming languages is even worse.
> but it's certainly not a good example of how to handle general algebraic structures, which is what it seems to pretend to be.
How so? The standard library may be flawed, but the core language is perfectly capable of handling general algebraic structures. The only legitimate point of pain I can see is that a type or tuple of types can only be an instance of a type class in at most one way, for which the solution (admittedly, rather ugly) is to use newtype. A non-ugly solution would be to use something like Standard ML's module system, but in no way it would improve the situation to move closer to Common Lisp.
I mean algebraic structures in the mathematical sense you mentioned (rings, groups, &c.), not in the computer-science sense of algebraic data types.
I know you meant those. And I meant those as well.