This article seems to put Lisp on a bit of a pedestal when it comes to types, but languages like Haskell blow Lisp out of the water with respect to expressiveness. There's also a lot in this article that's plainly implying the wrong things about what Lisp is capable of doing.
If we are to talk about types, I'd hope people would look at languages like Haskell or Standard ML—or maybe even ATS, Agda, or Coq—for future direction, not Lisp.
Unlike Lisp, C++ lets one write efficient, generic algorithms that can operate on several types of data. Lisp cannot, and falls back to dynamic type testing, which makes for slower code[1]. Basically your only option in Lisp is to specialize everything manually, or inline everything. Both approaches are extremely poor. As I hinted, Haskell and Standard ML do an even better job than both C++ or Lisp. This is talked about a good bit in this article [2].
(Also, for the record, Lisp has no concept of information hiding, interfaces, or APIs. And no, Lisp's packages are just convenient structures for grouping somehow related symbols together.)
The article talked about declaring function types in Lisp. Many implementations plainly ignore those and they provide no value. It doesn't help that idiomatic Lisp code usually doesn't include such declarations.
Lastly, a lot of the things in this article were SBCL specific, and had little to do with the Lisp language itself.
Like others have said, I don't think any points demonstrate that C++ is converging to Lisp. And if it were, that's probably a bad direction anyway, given the author's initial statements about heading toward an algorithmic language.
[1] No implementation of Lisp has true, flexible compile-time polymorphism or any type-algebraic structure; all inferred types must be concretely realized during the inference.
What is up with Haskellers starting these irrelevant Lisp vs Haskell arguments? OP made no mention or implication that Lisp is better than Haskell. It's petty and counterproductive.
This isn't a Lisp versus Haskell argument. It's a matter of fact that the expressiveness of Haskell's (and others') type systems are more expressive than Lisp's, practically (and almost theoretically).
Also, I'm not a "Haskeller". I do program in Haskell occasionally, though. I'm actually, at this time, a professional Common Lisp programmer.
My bringing up of Haskell and friends wasn't there to counter, but to merely observe that there are better things surrounding type systems than what is provided by even Lisp. And I wished to add that if one is to look for inspiration on building expressive type systems, then Haskell should be the place to look, not Lisp.
I also wanted to provide Haskell as a kind of system which provides an inference engine that is much stronger than Lisp's. I don't want anyone to get the idea that Lisp implementations' inference engines is even commensurable to what exists elsewhere.
> Also, for the record, Lisp has no concept of information hiding, interfaces, or APIs. And no, Lisp's packages are just convenient structures for grouping somehow related symbols together.
Dude was talking about Common Lisp which has (IMO) one of the best object-oriented systems in history, from the I-get-so-happy-when-I-can-use-it perspective.
Common Lisp's object system, CLOS, is indeed a rich and expressive system. But you'll also notice that CLOS does not provide any of the above points. It is an implicit contract between the programmer who developed the code and the programmer consuming the code to (1) not use information that is supposed to be hidden, (2) understand that exported methods are those that make up the "interface" to a class, and (3) understand that the API is that which is written in documentation.
I rarely need to dig into the implementation details of a class but when I do, if the language gets in my way, that's probably a bad thing. People make mistakes in API design and strict API contracts as a feature of the language can be annoying. FWIW, I remember only one case of having to do #define private public in my 10+ year career when dealing with a third-party library. The point is that the API should be a strong suggestion, but not necessarily strongly enforced.
The arguments you make apply equally to Python, btw.
If we are to talk about types, I'd hope people would look at languages like Haskell or Standard ML—or maybe even ATS, Agda, or Coq—for future direction, not Lisp.
Unlike Lisp, C++ lets one write efficient, generic algorithms that can operate on several types of data. Lisp cannot, and falls back to dynamic type testing, which makes for slower code[1]. Basically your only option in Lisp is to specialize everything manually, or inline everything. Both approaches are extremely poor. As I hinted, Haskell and Standard ML do an even better job than both C++ or Lisp. This is talked about a good bit in this article [2].
(Also, for the record, Lisp has no concept of information hiding, interfaces, or APIs. And no, Lisp's packages are just convenient structures for grouping somehow related symbols together.)
The article talked about declaring function types in Lisp. Many implementations plainly ignore those and they provide no value. It doesn't help that idiomatic Lisp code usually doesn't include such declarations.
Lastly, a lot of the things in this article were SBCL specific, and had little to do with the Lisp language itself.
Like others have said, I don't think any points demonstrate that C++ is converging to Lisp. And if it were, that's probably a bad direction anyway, given the author's initial statements about heading toward an algorithmic language.
[1] No implementation of Lisp has true, flexible compile-time polymorphism or any type-algebraic structure; all inferred types must be concretely realized during the inference.
[2] http://symbo1ics.com/blog/?p=1495