[geeks] Java as a first language

[Charles Shannon Hendrix]

Fri, 10 Nov 2006 @ 21:55 -0600, Jonathan C. Patschke said:

> But, again, J2EE lends itself to the sort of thinking where, rather than
> writing simple code, you go out and buy "components" that don't quite
> fit in to the application and then spend forever trying to write a shim
> in-between them.

That's one fundamental problem with object oriented programming, or
perhaps, a problem with how it is used.

Code re-use is hailed as some kind of holy grail, but in reality it is
quite often a bad idea.

It works great for small routines and/or those that are well focused.
Those tend to fit almost any situation. They are easy to improve or
change without breaking the API, and conversely you can often change
API without tremendous pain. They also tend to be less prone to side
effects.

OO programming seems to have a tendency to cause a lot of bloat, and
over generalization of both APIs and the code behind them. This makes
libraries difficult to change without affecting the API, and the APIs
are difficult to change without massive cascade effects on the rest of
the code base.

As a result, older OO code has a tendency to either not be improved, or
it gets replaced wholesale.

It also let's poor programmers cobble things together without really
understanding all of the parts, and of course it makes for large
programs even for small jobs.

While OO should be able to reduce the complexity of programs, it appears
in most cases to have increased size and complexity instead, effectively
nullifying many of the advantages of OO programming.

Therefore, to answer the original question: No, I don't think Java,
or any other OO language, is a good first language.  I think other
important fundamentals are better learned before you examine OO
techniques, so you'll know how to govern your use of objects and
object methods.

> Therein lies the rub: even in programming languages where you don't
> manage resources directly, you STILL need to manage your resources.

The other thing is that it (GC) helps reinforce the idea of using memory
for everything, which leads programmers to write code as if their
program were the only one running on the system.

Ever notice how many C++ and Java programs work by loading all data into
memory?

Multiple reasons for that, including an unfortunate tendency for
computer science education to skimp on non memory based data structures,
storage, and access methods. When I went to college most of our
algorithm classes were taught from the point of view of unlimited
memory.

The result is that almost no software written now can tolerate a memory
limit. If they run out of memory, they can't continue. At most they
might loop waiting for an allocation to succeed.

Very few programmers would, for example, know how to write a program to
access a lot of data, but only allow a certain amount of it to be loaded
at any one time.

The idea of a cached on-disk data structure is pretty foreign to them.

It seems to me that OO languages are ideal for implementing this kind of
thing, but I can't recall the last time I saw anything like that.

In their defense, I rarely see much in C++ and Java libraries that
supports the idea of non-memory based data structures. Pretty much
everything is written to suck it all into memory and keep it there.

> > I think Perl is a good place to start.
> 
> I'd have to agree.  So long as you remember "use warnings; use strict;"
> it's very possible to write good code in Perl, and it's an easy language
> to get running in very quickly.

I have mixed feelings about that because Perl has a lot of side-effect
features that can trip even experienced programmers.

-- 
shannon "AT" widomaker.com -- [There is a limit to how stupid people really
are -- just as there's a limit to the amount of hydrogen in the Universe. 
There's a lot, but there's a limit.  -- Dave C. Barber on a.f.c.  ]