A. Stepanov on the STL(antiquark.com)
antiquark.com
A. Stepanov on the STL
http://www.antiquark.com/escape/public_html/stepanovusa.html
5 comments
He has a book now, Elements of Programming: http://www.amazon.com/dp/032163537X/
Boy, that's old.
> Java is a very new language
:-)
> Java is a very new language
:-)
"As the chief proponent of Java at SGI told me: 'Alex, you have to go where the money is.' But I do not particularly want to go where the money is - it usually does not smell nice there."
I really love this quote
I really love this quote
T max<T>(Comparable a, Comparable b) {
if (a.compareTo(b) < 0) { return a; }
else { return b; }
}
Or something..
Explicitly specifying that a and b needs to be comparable instead of shooting an endless template error message.
And: "My approach works, theirs does not work." explains perfecly why C++ is what it is.
Or something..
Explicitly specifying that a and b needs to be comparable instead of shooting an endless template error message.
And: "My approach works, theirs does not work." explains perfecly why C++ is what it is.
Is that similar to this Haskell code?
max :: Ord a => a -> a -> a
max a b = if a > b then a else b
That Haskell code, as I understand it, will dynamically dispatch the call to max through the Ord typeclass dictionary passed at runtime. The C++ code will statically choose the appropriate function.
I'm pretty sure that Haskell typeclasses are also resolved at compile time. That's why you can't have a list containing different ordered types, for example (unless they can all be coerced to the same type).
No, you can't have a list containing different ordered types because the signature for comparison only permits two values of the same exact type, not any arbitrary member of class `Ord`.
As I said before, Haskell passes [runtime dictionaries](http://www.haskell.org/haskellwiki/OOP_vs_type_classes). The compiler can perhaps infer many cases statically, but the core implementation is to pass around runtime dictionaries for typeclasses.
As I said before, Haskell passes [runtime dictionaries](http://www.haskell.org/haskellwiki/OOP_vs_type_classes). The compiler can perhaps infer many cases statically, but the core implementation is to pass around runtime dictionaries for typeclasses.
Yep
"Your approach" is what Stepanov was referring to as "concepts" about .. erm .. 10 (?) years ago. It is effectively a template argument constraint system.
Concepts were one of the most expected features of C++0x, the one that got just recently dropped from the consideration due to being "not ready".
Concepts were one of the most expected features of C++0x, the one that got just recently dropped from the consideration due to being "not ready".
The article is old, from when Java was new. His criticism was correct back then. Java didn't get generics until 8 years after it was introduced. (Java 1.5: http://en.wikipedia.org/wiki/Java_version_history )
Equality and comparisons in presence of subclassing etc. are not the business of a sane man. I think it is impossible to write an .equals() in java that satisfies all the relevant laws people usually assume from it.
It's possible to be locally sane. For example, suppose you define an abstract Number class, and define subclasses for ComplexFloat and IntFraction numbers. You could define .equals() methods on each of those that only compare to the same type, and work correctly. You don't always have to deal with weird issues.
In Eclipse:
Alt-Shift-T for refactor. Select "Generate Hash-code and Equals".
Alt-Shift-T for refactor. Select "Generate Hash-code and Equals".
I upmodded this for comedy value. This is really how Java programmers think. So what if the code is wrong in corner cases, it was auto-cut-n-pasted!
equals(Object o) has a very tricky contract to implement, when you add subclassing to the mix. Auto-generated code won't make those problems go away.
See http://www.artima.com/lejava/articles/equality.html
See http://www.artima.com/lejava/articles/equality.html
I was mostly joking when I wrote the parent comment. I've read Joshua Block's Effective Java which spends a long time discussing the challenges of properly implementing equals.
Generally speaking, Eclipse gets it correct. Implementing equals properly boils down to following a set of rules - something that computers are exceptionally good at.
Generally speaking, Eclipse gets it correct. Implementing equals properly boils down to following a set of rules - something that computers are exceptionally good at.
Stepanov is a really smart guy, but I find his arguments that OOP methodology is "wrong" or somehow is no good, doesn't hold water. The truth is that a lot of the world is build on at least some OOP principles and that they have worked for countless designs, and been included into languages by lots of other really smart people.
It also seems like this interview was done quite some time ago (see his comments about generics in Java) but I can't find a date.
Nevertheless, a very interesting interview.
It also seems like this interview was done quite some time ago (see his comments about generics in Java) but I can't find a date.
Nevertheless, a very interesting interview.
I think you are misrepresenting him.
He says his paradigm is “start with the algorithm” (to make it generic) and that does not work in the OO model, and as an example he gives a simple max(a, b) function which he wouldn’t know how to write in Java.
The “OOP principles” adopted by others, which you think voids his argument, you can argue are also used by Stepanov himself. He just calls it data abstraction (iirc).
He says his paradigm is “start with the algorithm” (to make it generic) and that does not work in the OO model, and as an example he gives a simple max(a, b) function which he wouldn’t know how to write in Java.
The “OOP principles” adopted by others, which you think voids his argument, you can argue are also used by Stepanov himself. He just calls it data abstraction (iirc).
His argument actually seems to point to dynamically-typed functional programming, which is not surprising, considering his work with Scheme.