Do you really think the folks at Sun got up one day, smoked a dubie and said, "Whoa Dude.. Lets right a really complicated fat language that seems intense... cuz if its fat and complicated everybody will think its cool man...

No, I think they tried to commercialize a failed embedded language that also failed for browser applications. I've been using Java since 1.1.7. There is no grand vision....it's all tacked on. They hit gold with the app servers, IMHO.

n order for programming to progress to the next natural level ( i.e programs writing programs for programs )

Back to your original item, this is A.I. land, I'm not sure why it entered the discussion. Historically, A.I. has lent itself towards functional programming (Lisp, Scheme). O.O. is fine, I like it, and it can be used combined with A.I. concepts -- however, I should point out, 'programs writing programs' has little to do with a need for 'encapsulation'. Again, the "shotgun" metaphor can be brought up.

Ok this post does much to bring down the hackles your previous post raised -- so pardon my previous simplifications and sarcasm. Gotta admit I started playing with Java 1.1.2 (Still have the Java in 24hours book *g*) and discounted it very quickly ( read applets sucked ).

What I see in Java is organization and methodology on a large scale. I don't think Java is the beat all language technologicaly, but what I do see is the beginnings of a language that can be more readily managed and matured on a global scale. Although looking at the (huge) applications I work with there is no way to discount the overkill and bloat in the majority of cases.

Once folks write getter and setter methods for everything, through in a few static accessors (cough...PC globals), or chain objects such that an entire object tree is accessible...essentially encapsulation is just an illusion. It's just harder to get what you want, but you can get it. And if you need it, you'll code in a way to get there. 'encapsulated' interfaces can still cause huge ripple affects with changes, they rarely get isolation & modularity correct -- which are concepts that are not OO specific.

No argument with that statement++

On the other hand my favorite language, Perl, is impossible to manage on a large scale ( Read multiple development centers ) as every script is as unique as it's developer. C++ suffers from this as well though obviously not to the same degree.

In the end it's the old addage Use the right tool for the job.

coreolyn

Perl, is impossible to manage on a large scale ( Read multiple development centers ) as every script is as unique as it's developer.

I can't accept or believe this. I see no reason why perl code should be any different from Java in this regard. I think it more comes down to mentality of the people involved. Project managers in perl have a lot of architecture related decisions to make before a large project can commence. In the Java world these decisions are made by the language so they need not be contemplated. Of course as a project manager/architect i would prefer the flexibility of perl, and the added responsibility of making wise decisions than the rigid framework of Java. But I think many project managers I know, (especially those from the "business side" of things) would prefer Java because then they dont have to make those decisions, nor be responsible for their outcome.

Part of the reason i say this is that a large perl project need not have more than one "script", being entirely composed of modules and objects that do the actual work.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi