RE: RE: WDSC and Linux -- CODE400-L

> From: Michael Naughton
>
> Using your definition, I bet most of us are "application assemblers".  But
>  I'm not sure there's anything wrong with that.

I disagree.  In the old days of BPCS (and indeed most ERP packages), if
something went wrong, you could debug the code line by line and eventually
find the problem, even if it wasn't your program.  And in so doing, you
began to learn what made that whole system tick.

Now, I don't remember every piece of BPCS, but I can definitely tell you
from the ground up how the MRP generation process works, enough so that I
could probably write my own from scratch if I had to.  And most of the
systems I worked on for any length of time, I learned to that level.

That's what we're losing today.


> I think practical reality drives most of us to understand the
> tools and components we use in our assemblies at differing levels: some we
> understand thoroughly, and some we we know just enough about to understand
> how to use them effectively.

And herein lies the rub.  What happens when something you know how to "use
effectively" breaks?  Can you debug it?  Do you know enough about what it is
SUPPOSED to do to determine what it's not doing?

In the old days of the midrange, we most certainly could.  Nowadays, as we
throw in more third-party open source packages and more proprietary
middleware like .NET, more and more of our application is becoming black
boxed.  And this would be fine if the black boxes were as stable and
reliable as OS/400, but from the sheer number of questions on the users
groups, it's obvious that this is not the case.  Things break in odd and
mysterious ways, and something that's been working fine for a week suddenly
crashes because somebody twiddled something they oughtn't to have twiddled.


> In fact, isn't that the point of encapsulation? You don't have to have a
> clue as to what that darn object is doing on the inside -- all you have to
> know is what messages you need to send it and what messages to expect
> back. Now, that's not going to stop some of us from cracking apart those
> objects to see what makes them tick, but it is really required that we do
> so before we use them?

This only works when the stuff you are using has been tested to hell and
gone.  It's particularly well suited for middleware (stuff like UI
formatting) and poorly suited for stuff like business logic.  That's because
UI formatting follows a relatively constant set of rules, while business
rules change daily (or more!) and there are all kinds of one-off exceptions
that need to be taken into account.

Yes, modular programming is all about being able to call a module without
having to know what it does, but that doesn't mean using something that you
have no clue how it works.  That's part of the reason I don't like Open
Source for mission critical stuff, although I can live with it because at
the very least I have the source code.  Proprietary stuff like MS middleware
is really scary to me, because I have no clue what it's doing, and the error
reporting is usually next to useless.

Anwyay, I still stand by my position that programmers should take an
assembly language course, and that using a visual IDE to put together
preformed proprietary program pieces (Whoo hoo!  Four P's!) is not
necessarily a step forward.

That's part of why I like WDSC so much, by the way.  It allows you to
assemble pieces, including Open Source JAR files, and then set breakpoints
all throughout your application, including in servlets and JSPs.  And my
understanding is that you should be able to do it with called RPG programs
on the host.  That level of integration is very nice - a programmer (by my
definition) can go chasing through all the available code and see what's
really happening.

Joe Pluta
Eclipse: Step by Step
http://www.mc-store.com/5059.html



Joe