My impression, although I'm not an insider and could be off base, is that it wasn't conceived to be an enterprise language, but its patterns were. I learned it when I started application programming for my startup (I had been doing scientific routines, i.e. FORTRAN and Mathematica), because I was curious about OO. A lot had changed since I hacked out a little C and assembler on my Mac+ many years ago, and the scale of the problems programmers and programming teams had to handle had changed significantly. It seemed OO became popular as a way to handle this scale of things. Java was presented as a solution for building maintainable apps, so I learned it.
I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off.
On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful.
You are correct about the IDE thing. That does ease a large burden in Java.
I think that this is happening to many people who are doing a lot of 'non-trivial' JavaScript. The language is still very young and because the concepts that were chosen when creating the language are powerful and flexible (prototypal inheritance, objects can be accessed like hashes, first-class functions etc) there's always a million ways to code something.
OO-wise i think you can divide into those who use the `new` keyword and build objects that are more or less Java-like classes and those who create objects and prototypes on the fly, and probably use a lot more ideas from the functional and LISPy side of things.
I have somehow settled into the pattern of using new/java-like classes for large objects that store a logical set of data and need to operate on it, and on-the-fly prototypes to groups group just data (or, perhaps, a trivial operation).
My worst crime by far (that I am aware of) is that I have no hesitation to use a global variable if it saves me from bending over backwards to get around it. I'm doing animations, and sometimes the algorithm just comes to me a lot faster if I let a var keep a global value and be used by lots of functions between calls to my animate() function (using window.setInterval() ).
Most of these patterns come from Smalltalk (which was probably the original language of complex enterprise OO systems). I think that what made Java this kind of entrprise language is that it was reasonably similar to smalltalk so all these patterns and concepts can be reused and on the other hand it is similar to "normal" programming languages so average programmer does not have problems with it's workflow and IDE (as is the case with ST). On the other hand most uses of design patterns in Java code (eg. 90% of uses of Observer pattern, especially in cases when it is called Listener) seem to be to be compensating for fact that Java is not Smalltalk(/JavaScript/Ruby/Python/C# whatever with first class classes and methods).
JavaScript is language that is very different from anything else. Depending on how you look at it it has either unconventional semantics (majority view) or unconventional syntax (my view). It's object model is strong and often useful (you can emulate class-based inheritance with it, not the other way around), but I agree that it is to some extent afterthought (although I have strong feeling that our reasons are very different). What is probably largest problem of whole JS is the "Java" part of it's name and weird syntax deliberately designed to "look-like-Java" or "look-normal", which simply does not match underlying semantics.
Coming from C/Unix background I actually consider the IDE thing burden in itself. I expect that there are some easily editable source that is transformed by series of some steps into final program, but all changes happen only in the original input. Which is simply not case in Java/ST world, where you essentially need pretty complex IDE (on the side note: few years ago some Java IDE I was using for quick experiment forbade me from saving source file with syntax error with it... WTF?).
LOL- I think I had the same IDE when I was first stumbing about with Java! It was definitely a WTF moment. It became useful for code expansion, refactoring, and unit testing however. I'm now using vim to develop php and Javascript and I miss its convenience (on the other hand, I'm a lot better with sed now...). But using Firebug to find my errors is a bit slow.
What I find really cool about your comment is that you appear to have a deeper view of it all (meaning a deeper understanding of the underlying semantics), and I'm wondering how my view will change as I continue to work with it.
Interesting about objects in javascript. I have actually started feeling that prototype-based object orientation is less tacked on than its class-based cousin. The syntactical implementation is a bit strange (the 'function' keyword for objects, putting functions on the prototype object rather than the object itself), but the mechanism itself seems more generic and flexible. The implementation in Io is better I think, you should check that out before discounting prototype-based object systems outright.
Oh, I won't discount them (I'm not good enough to be a prima-donna about it), and it's nice to know that I will see how to use it to my advantage as I play with it more.
I also tried to stay close to the OO paradigms (of course, I was just learning them), as I built this 50000 line beast called "Egorg." Now, I get to maintain and update it, so we'll see if it paid off.
On a side note, I have a real distaste for objects in Javascript. They seem clunky, almost like they were stuck on as an afterthought (I get a similar feel about Generics in Java). But the design of Javascript makes it quite easily to hammer out a script to do something cool. I'm worried about maintenance, though, because I feel like I'm evolving my own design patterns, so retracing my steps will likely be painful.
You are correct about the IDE thing. That does ease a large burden in Java.