Elliotte Rusty Harold's take on Java

[Yigal Chripun]

On 17/09/2009 14:44, downs wrote:
> Nick Sabalausky wrote:
>> "Justin Johansson"<procode at adam-dott-com.au>  wrote in message
>> news:h8ruu1$1qpn$1 at digitalmars.com...
>>> Being somewhat of a fan of Elliotte Rusty Harold, I drop in for a
>>> coffee& read at his cafes from time to time.  I think D people
>>> will enjoy this December 2008 article with amusement so may I
>>> please share it with you. Some of the comments aren't too bad
>>> either.
>>>
>>> http://cafe.elharo.com/programming/java-is-dead-long-live-python/
>>>
>>>
>>>
Here an excerpt:
>>>
>>> "Java by contrast, is dead. It has at least as much brain damage
>>> and misdesign as Python 2.x did, probably more; yet Sun has
>>> resisted tooth and nail all efforts to fix the known problems.
>>> Instead they keep applying ever more lipstick to this pig without
>>> ever cleaning off all the filth and mud it’s been rolling in for
>>> the last 12 years. They keep applying more perfume when what it
>>> really needs is a bath."
>>>
>>> Enjoy the read!
>>>
>>
>> What he was saying in that article sounded good...right up until he
>> implied that all primitives should always endure the bloat of
>> always being full objects.
>>
>> It really bugs me though that it's taken the industry until the
>> last few years to *FINALLY* start noticing that Emperor Java is
>> missing it's clothes.
>>
>>
>
> The post seems to make the argument that with modern processors we
> can afford making every primitive an object - and I say to that, as a
> coder heavily interested in raytracing and fractals, we _still_ need
> _all_ the speed the CPU can give us, so think twice before you
> consume in the name of language purity.
>
> (Of course, this doesn't apply to Python)
>
> Besides that, I think all the people here who say, and are going to
> say, that making primitives full objects would be the right decision
> (even for D!), need to remember that D at its core is _not_ an
> object-oriented, but a multiparadigm language, and I think embedding
> objects this deep into the type model would give the object-oriented
> features of D _far_ too much weight.
>
> (Just my pre-emptive 2¢)


disclaimer: I'm one of those people who want to go this OOP path for D.

a few comments and questions:
first off, I don't agree that this must be an either or decision. There
are better ways to implement this concept without getting the
performance penalty.

Yes, D is multi-paradigm and not just OO but I don't see how adding more 
OO support will hurt other paradigms. Can you give an example of this?

IMO this has no affect on other programming styles.
for instance you could use both "hello".toUpper() and toUpper("hello") 
and I don't see how ane interferes with the other.

for example, Ruby is fully implemented and designed with OO in mind, yet 
it's straight forward to write functional style code with it.