in reply to Re: ^3 OT: JavaJunkies (Javamonks sorta)
in thread OT: JavaJunkies (Javamonks sorta)

"large scale application development will not be terse".

They are not terse because that is the way they are written. They are large because they are large. They could be small. They could be medium sized. Consider the Tau.

A lot of enterpise apps could be simplified by reducing them to datastructures and event handlers, but they tend to sprawl. They have multiple interfaces where they could add multiplexors to simplify things. All things can be simplified with time, and "large scale" doesn't mean "scaleable", "powerful", or "advanced", or even "feature rich" -- it just means "large scale". Consider the Tau.

  • Comment on Re: Re: ^3 OT: JavaJunkies (Javamonks sorta)

Replies are listed 'Best First'.
Re: Re: Re: ^3 OT: JavaJunkies (Javamonks sorta)
by coreolyn (Parson) on Feb 05, 2004 at 22:33 UTC

    I was going to let this branch die, but after trying to consider The Tau and looking at your over simplification of the problem at hand I couldn't help myself.

    In order for programming to progress to the next natural level ( i.e programs writing programs for programs ) rather than simply getting bogged down with delivery systems, content management, and business logic, the code itself must be capable of encapsulation in order to managage the complex relationships that need to exist. Datastructures and event handlers are wonderfull from a programers mindset, but from the perspective of technological advancement they are impediments to the larger problems and abstractions. (i.e. Getting computers to solve real world problems ) Scalable doesn't just relate to the number of users that can access a system, but also to the ability to handle fast change at any level of the problem domain with the least impact to process and product.

    If it we're simply about size for the sake of size OO itself is discounted as a viable option. 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... we'll make sooo much cash man"

    ?

      You oversimplify myself. OO is perfectly fine in most languages, it is the Java theory of it (as well evidenced by the confused Sun API) that I dislike. This is not OO=bad, but OO Overload = bad. I've written some very nice C++. I generally like it. STL goes a little overboard, but I can tolerate it. You can still mix concepts, and for that, the language remains flexible.

      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.