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

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

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/>

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.

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 php, java, c#, and asp for their web development. Considering that Java has a very rich library ecosystem, there aren't that many alternatives available in many cases.

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¢)

> 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?

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.

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.

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?