Andrew Koenig wrote:
> [...] For example, I can write programs that manipulate trees and
> tree-like data structures much more easily in ML than I can in C++,
> as long as I stick to the operations that ML supports. But it can
> be useful sometimes to do things that ML doesn't support well, and
> those things are much harder to implement in a language that has
> trees virtually built in than in a language where trees are built
> on top of a lower-level abstraction.
SML does not have trees "virtually built in." Its type system
understands discriminated unions. This, plus pattern matching plus
automatic memory management is what makes it so easy to build trees
(and many other things) in SML compared to C++.
The *only* high-level semantic concept that C++ supports that SML
doesn't is (C++'s very awkward form of) subtyping polymorphism.
And SML's support for generic polymorphism coupled with support for
higher-order functions more than makes up for it.
> [...] But now suppose we want to be able to identify a specific subtree
> of a tree. If I had gone to the trouble of creating a tree abstraction
> in C++, I could identify a particular subtree by the address of its root.
> But there's no corresponding facility in ML. Trees are values, and
> although one can compare them for equality, there is no notion of object
> identity.
>
> One way to solve that problem is to use ML references for the tree nodes.
> But then the trees really do become objects, and treating them as values
> becomes much more difficult. Moreover, I might not have thought I would
> need to identify particular subtrees, and changing an existing data structure
> to use references requires rewriting all of the code that uses it.
>
> [...]
I fail to see in what way C++ provides any advantage over SML in this
example. The problem of deciding what semantics your data structures
should have doesn't get any easier merely because you're using C++.
To the contrary, SML's type system is far more powerful than C++'s.
This is what makes it easier to get data structure semantics right.
Exposing memory addresses may provide a "built-in" concept of object
identity, but only by imposing a huge memory management burden on the
programmer, a far bigger burden than using refs in the (rare!)
instances that you might need them. (And adding a garbage collector
to C++ only addresses part of that burden.)
In contrast, it's easy to come up with examples of tasks that are
trivial in SML and extremely difficult in C++. I can't describe
what I'm working on, but I was recently glancing through "Design
Patterns" by Gamma et al and happened to notice what they call the
"Command" technique. An entire chapter is devoted to something that
can be accomplished *trivially* in any language that supports
higher-order functions. And I bet if I actually read more of the
book I'd find it was nothing but a catalog of examples of why C++
sucks.
> Incidentally, this whole discussion talks only about language. In
> deciding what programming tools to use, there is more than that to
> consider. After all, if all you care about is how easy the language
> is for you to use, why not just invent your own language? You won't
> have a compiler for it unless you write one, but if ease of
> programming is all you care about, that doesn't matter. [...]
Since you mention it (even if only facetiosly), this is exactly what
makes Scheme so great. It is easy to implement mini-languages for
specific problem sets. My beef is that too many people who have
been trained to think in C/C++ don't even know that this is very
often exactly what they want to do.
Scheme has a simplicity and flexibility that SML doesn't have. SML has
efficiency and safety that Scheme doesn't have. Both make programming
in C++ feel like crawling through broken beer bottles in comparison.
> [...] But even that is not all that matters. There is also the
> question of what tools your colleagues use, and what tools the people
> might be using who will be maintaining your code, and what machines
> you might be called on to support in the future. [...]
In other words, C++ is better than SML because more people use C++
than SML?
-thant
[...followups trimmed...]
|