3 ms·
It is a common mistake I've heard from many CL newbies that believe CL is a "FP" language. The best descriptor I can find to date (of CL) is, "programmable pro
by agentultra 13y ago
It is a common mistake I've heard from many CL newbies that believe CL is a "FP" language.
The best descriptor I can find to date (of CL) is, "programmable programming language," which allows it to encompass almost every desired feature one may need; including many that fall under the FP umbrella which may be where the confusion stems from.
However one of the opening points of the talk was that, "FP," is not a rigorously defined term and is subject to interpretation. Which leads to bikeshedding over language features and a lot of hype.
I believe it also leads to a lot of misplaced faith in the purity and completeness of mathematics (it's almost as if the popular notion of FP is being reborn as a modern Principia Mathematica).
CL obviously cannot be called an, "FP," language since its inception seems to predate the popular notion of the term. Scala may suffer in the same way due to its reliance on the JVM and the expression semantics it has carried over from Java. However many of the features one tends to associate with modern FP languages (though not all) are present in both languages.
As for your aside, how so? Perhaps a discussion we can have over email if you're interested. You sound smart. However I don't understand your statement and would like to know more.
- catnaroek 13y ago> As for your aside, how so? CLOS multimethods do not "belong" to an object or even to a class declaration. Particular implementations of generic methods are declared globally, just like Haskell type class instances. Although, as Peaker noted, type classes can dispatch on any part of the type signature. It is impossible to make a CLOS multimethod with signature: (SomeClass a b) => String -> (a, b) > Perhaps a discussion we can have over email if you're interested. Sorry, I never check email. But I am almost always on Freenode. My nick is pyon. > You sound smart. Not really. The regulars in #haskell - now they are frigging smart.
- agentultra 13y agoI think the comparison to type classes is specious and ends there. They look similar but they tackle very different problems. You've actually explained why rather well. > Not really. The regulars in #haskell - now they are frigging smart. Don't sell yourself short.
- Peaker 13y agoIt seems to me type classes have a superset of the features of CL multimethods. Why not compare them?