Taking input and writing output are (usually...) not a big task, nor have they ever really been, though I'm aware that such a statement seriously glosses over what we actually mean by input and output (i.e. files, http transports, entries in a database, streams representing the entirety of a single chromosome in the human genome, etc.). Maybe the encumbrance of checked exceptions makes these tasks a little more involved than one line, but it's still far from being a significant element in the design of most software.
Okay, okay, I'm digressing :) If it's taken as a given that I/O is trivial, then it's not relevant to any discussion of what COBOL devs do vs what Java devs do. Which now leaves us with this... In COBOL: Do something (with a bit of I/O at either end) In Java: Do something (with a bit of I/O at either end) In essence, you're completely ignoring the relative complexity, function, usefulness, value, etc. of what it means to "do something". But isn't all that ignored stuff the very reason why we program computers at all? On 10 July 2010 10:51, Vince O'Sullivan <[email protected]> wrote: > The existence of libraries is not relevant to the point that I'm > trying to make. > > When I first started coding, in the 1980s and in COBOL, a typical task > would be to write a program which would take input from one or more > sources, do something to it and send the output somewhere. > > These days I write primarily in Java. A typical task is to write a > program which would take input from one or more sources, do something > to it and send the output somewhere. > > Whilst I readily acknowledge that progress has been made in all sorts > or areas; the acts of specifying and coding today is more or less > identical to what it was when I started. The level of detail that I > work at is certainly unchanged. The skills used and the constructs > created now are much the same now as they were then. I still need to > specify the SQL and execute and detail when and how to extract the > results. The loops in the code go in much the same places, error > handling still has to be manually specified, etc. > > What hasn't happened was the expected evolution to the position where > you define your inputs, define your outputs and let the computer do > the rest. > > So, not only is Java the new COBOL, but Java IS COBOL. Only the > vocabulary has changed. > > On Jul 10, 9:04 am, jitesh dundas <[email protected]> wrote: > > I beg to disagree on this one. > > > > I have seen that the amount of code that we have written till date has > grown > > to a big amount. As people keep writing the same software again an again, > we > > are coming up with libraries that are reducing the LOCs that we use. > > > > Moreover, have you thought of third-party libraries that allow us to make > > calls to common functions. for e,g, HTTP EMail CLient commons library of > > Apache reduces the LOCs that we write. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
