On 17/09/2009 14:44, downs wrote:
Nick Sabalausky wrote:
"Justin Johansson"<proc...@adam-dott-com.au>  wrote in message
news:h8ruu1$1qp...@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.

Reply via email to