www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Elliotte Rusty Harold's take on Java

reply Justin Johansson <procode adam-dott-com.au> writes:
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!

Justin Johansson
Sep 16 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <procode adam-dott-com.au> wrote in message 
news:h8ruu1$1qpn$1 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.
Sep 16 2009
next sibling parent Justin Johansson <procode adam-dott-com.au> writes:
Nick Sabalausky Wrote:


 *** 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. 


Yes, I knew that *** was incompatible with D doctrine (and mine) but certainly
a lot of what he said was a wake-up call that might spawn a few interesting
discussions in this camp.

Perhaps if people take home something from the article that they want to talk
about here, it might be an idea to quote the relevant bit and fork this thread
(with new subject line as appropriate) so we don't end up with another tangled
thread like the Hud? one last week.

<JJ/>
Sep 16 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 17/09/2009 06:43, Nick Sabalausky wrote:

 "Justin Johansson"<procode adam-dott-com.au>  wrote in message
 news:h8ruu1$1qpn$1 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.


making primitives full objects is the right design and has nothing to do 
with bloat which just means the implementation sucks.

consider:

struct Integer(int bits, signed = true) {...}
with specializations for 8, 16, 32, 64

Integer!(32) will have the same size as an int since structs don't have 
vtables in D.

of course, for this to be truly useful the compiler needs to understand 
"123.methodName()" kind of code.
Sep 16 2009
parent reply Justin Johansson <procode adam-dott-com.au> writes:
 making primitives full objects is the right design and has nothing to do 
 with bloat which just means the implementation sucks.
 
 consider:
 
 struct Integer(int bits, signed = true) {...}
 with specializations for 8, 16, 32, 64
 
 Integer!(32) will have the same size as an int since structs don't have 
 vtables in D.
 
 of course, for this to be truly useful the compiler needs to understand 
 "123.methodName()" kind of code.


And I'm guessing you didn't mean auto-boxing either?
Sep 17 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 17/09/2009 16:15, Justin Johansson wrote:

 making primitives full objects is the right design and has nothing to do
 with bloat which just means the implementation sucks.

 consider:

 struct Integer(int bits, signed = true) {...}
 with specializations for 8, 16, 32, 64

 Integer!(32) will have the same size as an int since structs don't have
 vtables in D.

 of course, for this to be truly useful the compiler needs to understand
 "123.methodName()" kind of code.


 And I'm guessing you didn't mean auto-boxing either?


of course not. auto boxing is a patch for a broken design.

it's already possible to define in D:
void func(type[] arr, params) {}
and use it as:
type[] arr;
arr.func(params);

applied to strings (which are just regular arrays in D), you can do:

string str = "Hello World";
str.toUpper(); // assume to upper is defined as above.

next step would be to allow the same for literals:
"hello World".toUpper();

now let's take the above one step further. why limit this to arrays? why 
not make it work for numbers as well?
123.next(); could be understood by the compiler as
Integer.next(123);

No bloat required.
Sep 17 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Yigal Chripun wrote:


 On 17/09/2009 16:15, Justin Johansson wrote:

 making primitives full objects is the right design and has nothing to do
 with bloat which just means the implementation sucks.

 consider:

 struct Integer(int bits, signed = true) {...}
 with specializations for 8, 16, 32, 64

 Integer!(32) will have the same size as an int since structs don't have
 vtables in D.

 of course, for this to be truly useful the compiler needs to understand
 "123.methodName()" kind of code.


 And I'm guessing you didn't mean auto-boxing either?


 
 of course not. auto boxing is a patch for a broken design.
 
 it's already possible to define in D:
 void func(type[] arr, params) {}
 and use it as:
 type[] arr;
 arr.func(params);
 
 applied to strings (which are just regular arrays in D), you can do:
 
 string str = "Hello World";
 str.toUpper(); // assume to upper is defined as above.
 
 next step would be to allow the same for literals:
 "hello World".toUpper();
 
 now let's take the above one step further. why limit this to arrays? why
 not make it work for numbers as well?
 123.next(); could be understood by the compiler as
 Integer.next(123);
 
 No bloat required.


This is already supposed to be in D under the name of extension methods. But 
it is just another syntax for a function call, what has this to do with OOP?
Sep 17 2009
parent Justin Johansson <procode adam-dott-com.au> writes:
Do you guys think it might be an idea to fork the thread?

Subject say "Syntactic sugar and OOP"

JJ


Lutger Wrote:


 Yigal Chripun wrote:
 

 On 17/09/2009 16:15, Justin Johansson wrote:

 making primitives full objects is the right design and has nothing to do
 with bloat which just means the implementation sucks.

 consider:

 struct Integer(int bits, signed = true) {...}
 with specializations for 8, 16, 32, 64

 Integer!(32) will have the same size as an int since structs don't have
 vtables in D.

 of course, for this to be truly useful the compiler needs to understand
 "123.methodName()" kind of code.


 And I'm guessing you didn't mean auto-boxing either?


 
 of course not. auto boxing is a patch for a broken design.
 
 it's already possible to define in D:
 void func(type[] arr, params) {}
 and use it as:
 type[] arr;
 arr.func(params);
 
 applied to strings (which are just regular arrays in D), you can do:
 
 string str = "Hello World";
 str.toUpper(); // assume to upper is defined as above.
 
 next step would be to allow the same for literals:
 "hello World".toUpper();
 
 now let's take the above one step further. why limit this to arrays? why
 not make it work for numbers as well?
 123.next(); could be understood by the compiler as
 Integer.next(123);
 
 No bloat required.


 
 This is already supposed to be in D under the name of extension methods. But 
 it is just another syntax for a function call, what has this to do with OOP?
Sep 17 2009
prev sibling next sibling parent Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
Nick Sabalausky wrote:


 "Justin Johansson" <procode adam-dott-com.au> wrote in message
 news:h8ruu1$1qpn$1 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.


There are many things that prevent Python from replacing Java, even though 
Python 3 might look a bit cleaner. Closures are nice and so is a purer 
object system, but Python (at least by default) doesn't have an integrated 
static checker for syntax and semantics, i.e. a compiler. I can't imagine 
how anyone would want to port their 1 MLOC project to python since the 
existing compiler can even prove that the code is free from many kinds of 
errors.

I just looked at open job positions here and most companies are still using 

a very rich library ecosystem, there aren't that many alternatives available 
in many cases.
Sep 17 2009
prev sibling parent reply downs <default_357-line yahoo.de> writes:
Nick Sabalausky wrote:

 "Justin Johansson" <procode adam-dott-com.au> wrote in message 
 news:h8ruu1$1qpn$1 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¢)
Sep 17 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
On 17/09/2009 14:44, downs wrote:

 Nick Sabalausky wrote:

 "Justin Johansson"<procode adam-dott-com.au>  wrote in message
 news:h8ruu1$1qpn$1 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.
Sep 17 2009