[nylug-talk] Why does "enterprise" imply "Java"?

[Eric Moore]

Michael Bacarella <mbac at netgraft.com> writes:

>> Ok, but...  any programming tool is *supposed* to make programming
>> more like the "good" kind.  I mean, heck, if you want to spend all
>> your time doing technical crap...  program in raw machine code.  We
>> have languages, and libraries precisely to make programming less about
>> technical details, and more about cleanly expressing the problem...

And for reference, the original definition:

  "the ability to model a problem in terms of the subject domain, and
  then without having to go through the disorienting process of
  translating each technical requirement of that need (of which there
  could be many) solve that problem in a way that makes the whole
  thing act the way the user expects it to"


> Really?  I thought programming tools were supposed to help you get it
> done as fast as possible.  Time is money, chop chop!

Have you ever had a program take LESS time to complete because you had
"to go through the disorienting process of translating each technical
requirement of that need"?  In my experience, the closer to the
language of the subject domain I can express the problem, and still
have it act the way it's supposed to, the faster the program gets
written.

> Or were they supposed to make the code easy to understand and maintain?
> We need to be able to fire you on a whim, you know.

Again, when has a program that is expressed cleanly in terms of the
subject domain and (successfully) abstracts away the technical
requirements been harder to understand and maintain?

> Well, also, watch your memory usage.  You can't just hog all of
> these servers for yourself.

Technical requirement.

> And make it faster, it takes entire seconds for the user's request
> to complete and they're getting annoyed.  And while we're talking about
> the user experience, can we make the output prettier?  Textured marble
> 3d bar graphs in those charts, please.

Technical requirements, and behaving "the way the user expects it to".

> Oh, and I almost forgot...
>
> Our vendor is making us do a security audit.  I hope we haven't been
> paying you the big bucks (ha ha) to write swiss cheese code the past
> 2 years.  Make sure it passes these tests.

technical requirement, or behavior the user expects (not giving their
credit card number to thieves, for example ;)

> Speaking of tests, why did you stop unit testing?

That's a tool :)

> Also, I read this thing about proving algorithms.  I didn't really
> understand it, but it sounds like something we should be doing.

Another tool.

As described, a tool that accomplishes what Peter said (as rephrased
by me) would accomplish all the things (except unit testing, which is
itself a tool for ensuring that the thing behaves as expected) that
you listed.  So yes, it seems so far a pretty universal description of
what programming tools are supposed to do :)

-- 
Eric