Home > Archive > Cobol > January 2008 > Java is becoming the new Cobol
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Java is becoming the new Cobol
|
|
| Richard 2008-01-02, 6:56 pm |
|
The article is not making the point that Java is becoming the
corporate language of choice, as Cobol is/once was (choose one), but
that is is becoming obsolete as it is being replaced by newer
languages such as "Ruby, PHP, AJAX [sic]", and even C#.
http://www.infoworld.com/article/07...ted-java_1.html
"""If you're a Java developer, now's the time to invest in new
skills."""
There was a quote from a quarter century ago or more that went "10
years ago there were 3000 languages and COBOL, today there are 300 and
COBOL. In 10 years time I expect there will be 30 and COBOL."
The question then is: Is Java just another fad language in the range:
Algol, Pascal, Modula2, Ada, C++, that will be replaced by the next
fad languages Ruby, PHP, C# which will then be replaced by the
next ...
Or will Java really become the next Cobol and will continue for
decades more ?
| |
| tlmfru 2008-01-02, 6:56 pm |
| Or will COBOL become the new mainframe? I seem to recall that mainframes
were pronounced dead a couple of decades ago.
PL
Richard <riplin@azonic.co.nz> wrote in message
news:28b05ca0-c7a7-4ad5-b307-644da0ffc5fa@h11g2000prf.googlegroups.com...
>
> The article is not making the point that Java is becoming the
> corporate language of choice, as Cobol is/once was (choose one), but
> that is is becoming obsolete as it is being replaced by newer
> languages such as "Ruby, PHP, AJAX [sic]", and even C#.
>
> http://www.infoworld.com/article/07...ted-java_1.html
>
> """If you're a Java developer, now's the time to invest in new
> skills."""
>
> There was a quote from a quarter century ago or more that went "10
> years ago there were 3000 languages and COBOL, today there are 300 and
> COBOL. In 10 years time I expect there will be 30 and COBOL."
>
> The question then is: Is Java just another fad language in the range:
> Algol, Pascal, Modula2, Ada, C++, that will be replaced by the next
> fad languages Ruby, PHP, C# which will then be replaced by the
> next ...
>
> Or will Java really become the next Cobol and will continue for
> decades more ?
>
| |
| Pete Dashwood 2008-01-02, 6:56 pm |
|
"Richard" <riplin@azonic.co.nz> wrote in message
news:28b05ca0-c7a7-4ad5-b307-644da0ffc5fa@h11g2000prf.googlegroups.com...
>
> The article is not making the point that Java is becoming the
> corporate language of choice, as Cobol is/once was (choose one), but
> that is is becoming obsolete as it is being replaced by newer
> languages such as "Ruby, PHP, AJAX [sic]", and even C#.
>
> http://www.infoworld.com/article/07...ted-java_1.html
>
> """If you're a Java developer, now's the time to invest in new
> skills."""
It's true. It is even truer for COBOL developers.
>
> There was a quote from a quarter century ago or more that went "10
> years ago there were 3000 languages and COBOL, today there are 300 and
> COBOL. In 10 years time I expect there will be 30 and COBOL."
>
> The question then is: Is Java just another fad language in the range:
> Algol, Pascal, Modula2, Ada, C++, that will be replaced by the next
> fad languages Ruby, PHP, C# which will then be replaced by the
> next ...
Bad Question.
Algol, Pascal,Modula2 and Ada were NOT "fad languages", and neither are
Ruby, PHP, and C#.
They simply addressed different paradigms.
>
> Or will Java really become the next Cobol and will continue for
> decades more ?
>
Java will not become the new COBOL and neither will anything else.
COBOL belongs to an era when there was no Network and a centralised
mainframe only needed one or two high level languages to program it.
Those days are gone and COBOL is hanging on currently purely because of its
legacy applications. Even these are being slowly replaced. The only new
development in COBOL of any significance is probably on less than 1% of
sites Worldwide, and most of this will be mainframe, and procedural batch
processing.
The trend is to replace COBOL.
Initially that will be with Java (for the most part), but the important
thing here is not the language, but the paradigm.
Java is an OO language and OO is the basis for future development. COBOL
missed this boat (not through any fault of the language or the vendors of
it, but through the shortsightedness and arrogance of the COBOL community)
and there is no way of catching up.
Once something has been refactored into objects, the languages used to
access the objects are irrelevant; it is the paradigm that is important.
Languages like Java, Ruby, PHP, and C# are designed around OO and are
therefore relevant. It isn't a fad; it is here to stay. Certainly, the
technology may move on from OO (it is already doing so with component based
systems), but the underlying base for the perceivable future will be OO, and
commercial sites will use whatever langiuages support this.
The idea of having ONE language is just stupid. We need different languages
for different purposes.
Most COBOL people simply haven't realised that the Holy Source Code is no
longer relevant. It is Holy Object code and Holy Objects that have inherited
the Earth, and we are seeing better IT systems because of it.
There will almost certainly be newer languages that will improve on areas
not beng well served by current ones, but they will be built around the OO
paradigm and they will not be mutually exclusive with existing languages
like Java.
For this reason, we are not going to see the "end of Java" anytime soon.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-02, 6:56 pm |
|
"tlmfru" <lacey@mts.net> wrote in message
news:cBSej.3950$M24.1987@newsfe17.lga...
> Or will COBOL become the new mainframe? I seem to recall that mainframes
> were pronounced dead a couple of decades ago.
>
> PL
Mainframes ARE dead in terms of doing anything interesting with them :-)
The best chance of survival they have is by attachment to the Network and
welcoming the Web. To the extent that they do this and become powerful
servers in a Network environment, they will have a future. The days when
they sat at the centre of things and controlled everything are long gone. To
that extent, the role they served decades ago is gone, so they ARE dead as
far as that goes.
Don't hold your breath for a resurgence of COBOL, in the role which it
served decades ago, either.
Fortress COBOL is in ruins. It has been sacked and looted. Whatever was of
value has been incorporated into the Brave New World and the barbarians on
their wiry little ponies have swept on...
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Richard 2008-01-02, 6:56 pm |
| On Jan 3, 11:17 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "tlmfru" <la...@mts.net> wrote in message
>
> news:cBSej.3950$M24.1987@newsfe17.lga...
>
>
>
> Mainframes ARE dead in terms of doing anything interesting with them :-)
>
> The best chance of survival they have is by attachment to the Network and
> welcoming the Web. To the extent that they do this and become powerful
> servers in a Network environment, they will have a future.
They've being doing that. That is what 'Linux on Mainframe' is for.
> The days when
> they sat at the centre of things and controlled everything are long gone. To
> that extent, the role they served decades ago is gone, so they ARE dead as
> far as that goes.
Actually that is what web servers, or clusters of them, do now.
Web2.0 is, in fact, servers sitting the centre and controlling things.
CICS is replaced by AJAX. gmail (or ant web based), goffice (or
whatever it is called) and AJAX applications accessible from anywhere.
Whether the centre is mainframe or cluster or 'cloud' is not
particularly important (except to the one buying and supporting it).
> Don't hold your breath for a resurgence of COBOL, in the role which it
> served decades ago, either.
>
> Fortress COBOL is in ruins. It has been sacked and looted. Whatever was of
> value has been incorporated into the Brave New World and the barbarians on
> their wiry little ponies have swept on...
>
> Pete.
Geez, Pete, have a rant.
> --
> "I used to write COBOL...now I can do anything."
| |
| billious 2008-01-02, 6:56 pm |
|
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5u2gsbF1f3om9U1@mid.individual.net...
>
[snip]
> Fortress COBOL is in ruins. It has been sacked and looted. Whatever was of
> value has been incorporated into the Brave New World and the barbarians on
> their wiry little ponies have swept on...
>
So we sabotage their latte supplies and kidnap their hairdressers.....
| |
|
| Richard wrote:
>
> """If you're a Java developer, now's the time to invest in new
> skills."""
.....
> The question then is: Is Java just another fad language in the range:
> Algol, Pascal, Modula2, Ada, C++, that will be replaced by the next
> fad languages Ruby, PHP, C# which will then be replaced by the
> next ...
I don't think it's a fad language. However, I do see much Java being
replaced on servers by C#. Looking at the two languages, C# is Java,
take 2 - the syntax is *very* similar, but it leaves out some of the
verbosity of Java. (heh - maybe it *is* the new COBOL!)
For example, if you wanted to access a property of an object which the
property of another object which is the property of another object
(whew!), in Java you have...
topObject.getSecondObject().getThirdObject().getProperty()
....whereas, in C#, it becomes...
topObject.SecondObject.ThirdObject.Property
(Plus, with the Visual Studio IDE, you only have to type like 5 or 6
characters to get that second line! :> )
Another aspect that I like is the way that properties are defined. In
Java, it's almost COBOL-like in the way properties are defined (at least
in our shop). We have the property items in the top, then the
constructors, then the get and set methods after that. In C#, you
declare the get and set method as part of the property.
I see C# and Java in one camp, and PHP and RoR in the other. I *really*
like PHP's implementation of OO, although I'm sure it will mature more
in version 6. They have a "magic" function __call($method, $arguments)
that is called (if defined) if a method is requested of an object that
does not exist. Using this, if you just need a simple getProperty() or
setProperty() method, you don't have to define every single one of them!
Here's an example from a web site I've done...
public function __call($method, $arguments) {
$prefix = strtolower(substr($method, 0, 3));
$property = strtolower(substr($method, 3, 1)) . substr($method, 4);
if ((empty($prefix)) || (empty($property))) {
return;
}
if ($prefix == "get") {
if (isset($this->$property)) {
return $this->$property;
}
else {
return "";
}
}
if ($prefix == "set") {
$this->$property = $arguments[0];
}
}
Voila! :) (Of course, a limitation of the above is that it will blow
up if you say setFoo("bar") and $foo is not actually a property. I'm
sure I could put some error checking in for that, and probably will at
some point.)
So, in answering your question, I don't see PHP and RoR as Java-killers.
I see C# as a serious competitor, but I believe that until Mono
matures more, the Unix/Linux installations will continue to go with
Java. However, the advice given in that first quote is good. Innovate
or die (figuratively speaking, of course).
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Robert 2008-01-02, 6:56 pm |
| On Thu, 3 Jan 2008 11:11:02 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:
>"Richard" <riplin@azonic.co.nz> wrote in message
>news:28b05ca0-c7a7-4ad5-b307-644da0ffc5fa@h11g2000prf.googlegroups.com...
>
>It's true. It is even truer for COBOL developers.
>
>
>Bad Question.
>
>Algol, Pascal,Modula2 and Ada were NOT "fad languages", and neither are
>Ruby, PHP, and C#.
>
>They simply addressed different paradigms.
>Java will not become the new COBOL and neither will anything else.
I believe SQL is becoming the new Cobol, for these reasons:
... It has been largely unchanged in 20+ years.
... It faces little competition, because database servers cannot easily be altered
to accept another language.
... It successfully ignored OO additions in the '90s, analogous to Cobol.
... Long running batch programs are being written in PL/SQL. There are whole shops,
mostly in data warehousing, that do 100% of development in PL/SQL, SQR and database
utilities.
... A recent survey of job ads found PL/SQL is second highest skill in demand by big
companies, after Java. It is higher than C++, C#, PERL, Ruby, et al.
... Attempts to replace the two dimensional relational model have not been successful in
the commercial marketplace.
>COBOL belongs to an era when there was no Network and a centralised
>mainframe only needed one or two high level languages to program it.
A network INCREASES the need for interoperability. When mainframes were islands and data
was passed via flat files, it didn't matter what language the other shop was using. Now
that we pass data by setting a DbLink to the other shop's database, we must talk to it in
SQL. XML doesn't change that much because it is hierarchical rather than object model and
its schemas usually map closely with underlying database schemas.
>Those days are gone and COBOL is hanging on currently purely because of its
>legacy applications. Even these are being slowly replaced. The only new
>development in COBOL of any significance is probably on less than 1% of
>sites Worldwide, and most of this will be mainframe, and procedural batch
>processing.
Generally true, but a non-trivial portion, maybe 30%. of Cobol runs on Big Unix. For
instance PeopleSoft and Lawson.
>The trend is to replace COBOL.
>
>Initially that will be with Java (for the most part), but the important
>thing here is not the language, but the paradigm.
>
>Java is an OO language and OO is the basis for future development. COBOL
>missed this boat (not through any fault of the language or the vendors of
>it, but through the shortsightedness and arrogance of the COBOL community)
>and there is no way of catching up.
>Once something has been refactored into objects, the languages used to
>access the objects are irrelevant; it is the paradigm that is important.
>Languages like Java, Ruby, PHP, and C# are designed around OO and are
>therefore relevant. It isn't a fad; it is here to stay.
Agreed. But isn't it contradictory to say language doesn't matter while pronouncing Cobol
dead? Cobol can talk OO as fluently as other languages.
> Certainly, the
>technology may move on from OO (it is already doing so with component based
>systems), but the underlying base for the perceivable future will be OO, and
>commercial sites will use whatever langiuages support this.
Sometimes it appears they'll use whatever the Fad Language Of The Month Club sent last
month..
| |
| Pete Dashwood 2008-01-03, 7:55 am |
|
"Robert" <no@e.mail> wrote in message
news:r15on39djqv6a4tgdd360rcfp0jr3b50aq@
4ax.com...
<snip>
>
> I believe SQL is becoming the new Cobol, for these reasons:
>
> .. It has been largely unchanged in 20+ years.
> .. It faces little competition, because database servers cannot easily be
> altered
> to accept another language.
> .. It successfully ignored OO additions in the '90s, analogous to Cobol.
> .. Long running batch programs are being written in PL/SQL. There are
> whole shops,
> mostly in data warehousing, that do 100% of development in PL/SQL, SQR
> and database
> utilities.
> .. A recent survey of job ads found PL/SQL is second highest skill in
> demand by big
> companies, after Java. It is higher than C++, C#, PERL, Ruby, et al.
> .. Attempts to replace the two dimensional relational model have not been
> successful in
> the commercial marketplace.
>
An interesting thought. I've managed teams using SQL as a programming
language and was imp[ressed by their tools and their productivity. I don't
disagree that SQL could be considered "the New COBOL", but I'd be a lot
surer of it if there weren't already moves to replace SQL as the "standard"
for data access. Personally, I believe it WILL be replaced by things like
Query Expression languages and functions (LINQ and Lambda functions, for
example...), which are much more powerful and platform independent.
>
> A network INCREASES the need for interoperability. When mainframes were
> islands and data
> was passed via flat files, it didn't matter what language the other shop
> was using. Now
> that we pass data by setting a DbLink to the other shop's database, we
> must talk to it in
> SQL. XML doesn't change that much because it is hierarchical rather than
> object model and
> its schemas usually map closely with underlying database schemas.
>
>
> Generally true, but a non-trivial portion, maybe 30%. of Cobol runs on Big
> Unix. For
> instance PeopleSoft and Lawson.
>
>
>
> Agreed. But isn't it contradictory to say language doesn't matter while
> pronouncing Cobol
> dead? Cobol can talk OO as fluently as other languages.
No it can't.
It CAN talk OO (and I used it for nearly 10 years... it's impressive), but
NOT as FLUENTLY as, say, Java or C#.
Although OO COBOL has all of the OO features, and even exceeds other
languages in some regards (allowing multiple inheritance, for instance,
which Java doesn't...), it is NOT easily assimilable or easy to write. Since
using both OO COBOL and C# (and having dabbled some with Java) I am
persuaded there is no comparison between writing OO COBOL and writing C# or
Java. COBOL was never designed for OO and it suffers from its own verbosity.
The modern languages are quicker, have better tools and IDEs, and are more
concise and compact. It's really no contest, and I say this as someone who
loves COBOL and used it for decades; it simply doesn't compete in the world
of OO development.
Had it been widely adopted when it was first available, its life would have
been extended, but it still would have succumbed to the modern languages
eventually.
There is no need for "self-documerntation" when source is not important
anyway. The major benefit of using COBOL hinges on source code being
maintained. A modern component based approach does not hinge on that, so
there is no driving reason to use COBOL.
The other thing that would have killed it is the sheer expense of
maintaining source, when there are many thousands of lines of it to be
maintained... It isn't economically justifiable. Plugging components
together and reusing them is much cheaper.
>
>
> Sometimes it appears they'll use whatever the Fad Language Of The Month
> Club sent last
> month..
That is certainly true when Management is based on what they read in
Computer W ly and in-flight magazines :-). However, whether this forum
acknowledes it or not :-), IT Management is generally improving, as is the
general level of IT literacy in the population at large. Today's young IT
managers are likely to be Computing Science graduates with a background that
includes some programming. They are less likely to be influenced by fashion
than are managers to whom IT is a mystery, and who can only go by what
everyone else is doing...
Whichever way you cut it, COBOL's time has gone. I gave it until 2015 in
1996; I see no reason to revise that date.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-03, 7:55 am |
|
"Richard" <riplin@azonic.co.nz> wrote in message
news:2dd38e51-75f6-4e35-8db8-92bf2594d844@i12g2000prf.googlegroups.com...
> On Jan 3, 11:17 am, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz> wrote:
>
> They've being doing that. That is what 'Linux on Mainframe' is for.
>
>
>
> Actually that is what web servers, or clusters of them, do now.
> Web2.0 is, in fact, servers sitting the centre and controlling things.
>
> CICS is replaced by AJAX. gmail (or ant web based), goffice (or
> whatever it is called) and AJAX applications accessible from anywhere.
> Whether the centre is mainframe or cluster or 'cloud' is not
> particularly important (except to the one buying and supporting it).
>
>
> Geez, Pete, have a rant.
There was no anger in the above, only whimsy... :-)
I got over the Death of COBOL about a year ago and am no longer emotional
about it...
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| SkippyPB 2008-01-03, 6:56 pm |
| On Thu, 3 Jan 2008 11:17:49 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>
>"tlmfru" <lacey@mts.net> wrote in message
>news:cBSej.3950$M24.1987@newsfe17.lga...
>
>Mainframes ARE dead in terms of doing anything interesting with them :-)
Define interesting. I've been doing new development on a variety of
tasks covering various subjects over the past few years that I have
found "interesting". Both online and batch. 95% in Cobol, 5% in IBM
Assembler. No Java, no C# no soup de jour.
>
>The best chance of survival they have is by attachment to the Network and
>welcoming the Web. To the extent that they do this and become powerful
>servers in a Network environment, they will have a future. The days when
>they sat at the centre of things and controlled everything are long gone. To
>that extent, the role they served decades ago is gone, so they ARE dead as
>far as that goes.
>
>Don't hold your breath for a resurgence of COBOL, in the role which it
>served decades ago, either.
>
>Fortress COBOL is in ruins. It has been sacked and looted. Whatever was of
>value has been incorporated into the Brave New World and the barbarians on
>their wiry little ponies have swept on...
>
>Pete.
Regards.
////
(o o)
-oOO--(_)--OOo-
"Research is what I'm doing when I don't know what I'm doing."
--Wernher von Braun
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
| |
| Frank Swarbrick 2008-01-03, 6:56 pm |
| >>> On 1/3/2008 at 5:20 AM, in message
<5u428mF1f1nuuU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
>
> "Robert" <no@e.mail> wrote in message
> news:r15on39djqv6a4tgdd360rcfp0jr3b50aq@
4ax.com...
> <snip>
> be
[color=darkred]
>
> al.
> been
> An interesting thought. I've managed teams using SQL as a programming
> language and was imp[ressed by their tools and their productivity. I
> don't
> disagree that SQL could be considered "the New COBOL", but I'd be a lot
> surer of it if there weren't already moves to replace SQL as the
> "standard"
> for data access. Personally, I believe it WILL be replaced by things
> like
> Query Expression languages and functions (LINQ and Lambda functions, for
>
> example...), which are much more powerful and platform independent.
Do Query Expression languages and LINQ and Lambda functions not use SQL
under the covers? If not, then what do they use?
Frank
| |
| Pete Dashwood 2008-01-03, 6:56 pm |
|
"SkippyPB" <swiegand@nospam.neo.rr.com> wrote in message
news:bs2qn3lhj5kfn52g98tbcltir30fpd0uv9@
4ax.com...
> On Thu, 3 Jan 2008 11:17:49 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> Define interesting. I've been doing new development on a variety of
> tasks covering various subjects over the past few years that I have
> found "interesting". Both online and batch. 95% in Cobol, 5% in IBM
> Assembler. No Java, no C# no soup de jour.
It wasn't meant to wound, Steve...and was said with tongue in ch. :-)
You don't mention what you consider to be "interesting", but for me I can
immediately think of half a dozen thigs I can't do with mainframes, but
which are "interesting"...I'm quite sure I can could come up with more
:-)...
1. Setting up a personal telephone answering service, complete with
interactive voice response (IVR), voicemail, call forwarding, and camping on
to engaged numbers. I don't want to buy this service from my Telecomm
provider. It has nothing to do with money, just a question of principle
(they are bastards and I dislike them intensely but have little option if I
want a landline phone...:-)). Writing the software for this, is proving to
be very "interesting" and I expect to have it running fairly soon on an old
notebook which can be dedicated to the task.
2. Developing interactive Web Sites, driven by databases, using ASP.Net.
3. Running remote procedures across networks and the world. (My web server
is currently based in San Francisco but is maintained from NZ and accessed
globally. This is fun and VERY interesting...)
4. Experimenting with Lambdas and Query Expressions to organise and access
data more effectively. (I don't know of any mainframe software that allows
this, or supports LINQ style expressions, but there might be. I hope so...)
5. Being able to analyse and repair damaged or scratched DVDs is
interesting.
6. Connecting my mobile phone to my computer by bluetooth and messing with
it is "interesting"...
and a bonus...
7. Developing ANYTHING for mobile devices like iPods and Blackberries is
jolly "interesting"... (I haven't done this yet but it is on my list and I
have the tools to do it...)
While I agree that all of the above COULD be achieved on a mainframe (with
the right hardware and software connections), how much of it IS being done
on a mainframe?
That was my point.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Judson McClendon 2008-01-03, 6:56 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> ... I can immediately think of half a dozen thigs I can't do with
> mainframes, but which are "interesting"...
Over the last year I've been working with an associate to develop Visual
Studio applications to interface between the local county's Unisys A
Series mainframe and some web based services supplied by the state. We
were successful, but again and again we were chagrined to learn that
interfacing capabilities Unisys claimed and documented for the A Series
either did not really exist or were only partially implemented. For
example, the A Series can provide web services, but apparently nobody at
Unisys considered that any of their A Series mainframes would ever want
to *access* a web service on another server, because that capability
does not exist in the Unisys software. Named pipes, and a host of other
features just aren't completely implemented and/or documented.
This makes me  , because I've worked with Burroughs (then Unisys)
mainframes my whole career, and Unisys apparently either doesn't know
how to make their mainframes truly net capable, or don't have the will
or resources to do it.
Computers are computers, and there is no reason why any mainframe could
not be made to do anything a smaller computer can do, with the proper
software. I don't know about the IBM mainframe environment, and it may
be vastly different, but don't the mainframe manufacturers "get it?"
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Pete Dashwood 2008-01-03, 6:56 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:477CC8EE.6F0F.0085.0@efirstbank.com...
> <5u428mF1f1nuuU1@mid.individual.net>,
> Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
>
>
>
> Do Query Expression languages and LINQ and Lambda functions not use SQL
> under the covers? If not, then what do they use?
>
Currently there may be SQL generated at a certain level. In the future there
won't necessarily be. The language for formulating Query Expressions is a
new one and, although it looks like re-vamped SQL, it isn't. There is an
excellent video where Anders Hejlsberg discusses this and explains the
concepts.
http://blogs.msdn.com/charlie/archi...rogramming.aspx
For a detailed article explaining these concepts see:
http://msdn.microsoft.com/msdnmag/i...07/06/CSharp30/
In the future, these queries could generate IL (Intermediate Language, to be
presented to a JIT compiler) directly.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-03, 6:56 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:opefj.37167$Mu4.3749@bignews7.bellsouth.net...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> Over the last year I've been working with an associate to develop Visual
> Studio applications to interface between the local county's Unisys A
> Series mainframe and some web based services supplied by the state. We
> were successful, but again and again we were chagrined to learn that
> interfacing capabilities Unisys claimed and documented for the A Series
> either did not really exist or were only partially implemented. For
> example, the A Series can provide web services, but apparently nobody at
> Unisys considered that any of their A Series mainframes would ever want
> to *access* a web service on another server, because that capability
> does not exist in the Unisys software.
Are you saying it doesn't support XML/SOAP? That's all you need to access a
web service.
<snip>
>
> Computers are computers, and there is no reason why any mainframe could
> not be made to do anything a smaller computer can do, with the proper
> software. I don't know about the IBM mainframe environment, and it may
> be vastly different, but don't the mainframe manufacturers "get it?"
Apparently they don't, although I believe the message is filtering through
in some quarters.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Judson McClendon 2008-01-03, 6:56 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> Are you saying it doesn't support XML/SOAP? That's all you need to access a web service.
It's been several months since we dealt with that but IIRC, it was an
inability to initiate the TCP/IP query, not formatting issues. What we did
(which was appropriate for this particular application) was use a PC
based client that queried the web service, formatted the data and sent
it to the mainframe using named pipes, which partially work, though with
wierd and unexpected issues.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
|
| Judson McClendon wrote:
>
> Over the last year I've been working with an associate to develop Visual
> Studio applications to interface between the local county's Unisys A
> Series mainframe and some web based services supplied by the state. We
> were successful, but again and again we were chagrined to learn that
> interfacing capabilities Unisys claimed and documented for the A Series
> either did not really exist or were only partially implemented. For
> example, the A Series can provide web services, but apparently nobody at
> Unisys considered that any of their A Series mainframes would ever want
> to *access* a web service on another server, because that capability
> does not exist in the Unisys software. Named pipes, and a host of other
> features just aren't completely implemented and/or documented.
Wow. I know they have some of that with some native tools on the
2200-series, as well as a JVM (so you could pretty much make the thing
do whatever you wanted using Java). I believe my old office was
starting to do a little bit of that before I left.
Of course, I know we did some stuff that caught them by surprise.
Between Unisys and DISA*, we seemed to be responsible for finding
documented features that either weren't coded, weren't installed, or had
big problems. I can think of two different bugs we "fixed" (identified
to them, then saw it through) on their COBOL 85 compiler, and 3 with
their relational database server. :)
* Defense Information Systems Agency. I'm *so* glad our current shop
doesn't deal with them. Until about a year before I left, our
relationship with them had been an "us vs. them" thing. In their
defense, though, something changed, and they were very supportive from
then until I left. I think the something that changed is that they
deployed our system with half the resources we told them we would need,
and had to really work hard when the system came to its knees... Heh -
good times... (Of course, "it's all good" would probably be the way to
look at it. Their skimping on hardware prompted us to look at some of
our more processor-intensive processes, and actually gave us a reason to
redesign a couple of areas that needed it.)
The thing is, for the most part, the DISA *people* I dealt with were
nice folks - it was just the policies they were expected to enforce.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| tim Josling 2008-01-04, 3:55 am |
| On Fri, 04 Jan 2008 01:20:41 +1300, Pete Dashwood wrote:
> ...
> The other thing that would have killed it is the sheer expense of
> maintaining source, when there are many thousands of lines of it to be
> maintained... It isn't economically justifiable. Plugging components
> together and reusing them is much cheaper.
>
> ...
> Pete.
Do you have any evidence for this claim? I always thought it was self
evident until I tried to prove it to someone. Then I found out the
evidence - both anecdotal and academic - that I was able to find at the
time was weak to nonexistent.
Tim Josling
| |
| Alistair 2008-01-04, 7:55 am |
| On 2 Jan, 22:43, Richard <rip...@azonic.co.nz> wrote:
> On Jan 3, 11:17 am, "Pete Dashwood"
>
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
<rant and counter-rant snipped>
>
> Geez, Pete, have a rant.
>
>
>
>
Richard, I thought that was Pete having a rant!
| |
| Howard Brazee 2008-01-04, 6:56 pm |
| On Thu, 3 Jan 2008 11:17:49 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>Mainframes ARE dead in terms of doing anything interesting with them :-)
>
>The best chance of survival they have is by attachment to the Network and
>welcoming the Web. To the extent that they do this and become powerful
>servers in a Network environment, they will have a future. The days when
>they sat at the centre of things and controlled everything are long gone. To
>that extent, the role they served decades ago is gone, so they ARE dead as
>far as that goes.
Their best chance of survival is as database servers. The costs can
be right to have centralized, secure database machines for some
systems.
These may be off-topic in a CoBOL newsgroup, however.
| |
| Howard Brazee 2008-01-04, 6:56 pm |
| On Wed, 02 Jan 2008 17:46:14 -0600, Robert <no@e.mail> wrote:
>A network INCREASES the need for interoperability. When mainframes were islands and data
>was passed via flat files, it didn't matter what language the other shop was using. Now
>that we pass data by setting a DbLink to the other shop's database, we must talk to it in
>SQL. XML doesn't change that much because it is hierarchical rather than object model and
>its schemas usually map closely with underlying database schemas.
I'm not sure we can separate XML and SQL in predicting for much of
what's coming. Of course, both could be hidden within GUI
development systems.
| |
| tlmfru 2008-01-04, 6:56 pm |
|
Howard Brazee <howard@brazee.net> wrote in message
news:h2jsn3t4bssl6ksq6ivgshtlpfjqq61gsu@
4ax.com...
> On Thu, 3 Jan 2008 11:11:02 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
OO[color=darkred]
>
> A big plus that Java has that CoBOL doesn't is that it is cheap and
> easy for people getting interested in programming to acquire and use.
> Those guys don't care that it's OO, only that it's available and
> works.
>
Are you seriously claiming that CoBOL is NOT easy to learn and use? (I'm
not sure what you mean by "acquire").
| |
| Howard Brazee 2008-01-04, 6:56 pm |
| On Fri, 4 Jan 2008 11:14:22 -0600, "tlmfru" <lacey@mts.net> wrote:
>
>Are you seriously claiming that CoBOL is NOT easy to learn and use? (I'm
>not sure what you mean by "acquire").
Acquiring in this case means acquiring a compiler and working
environment.
With a compiler, it is relatively easy to learn to create a business
level program using CoBOL. But a high school kid wanting to play
around with programming will find it easier and cheaper to get what he
needs to write a simple Java program that works on his web page. Then
he makes one a bit more complex. Incrementally he learns more and
more without having to spend money.
| |
| Robert 2008-01-04, 9:56 pm |
| On Fri, 04 Jan 2008 08:13:36 -0700, Howard Brazee <howard@brazee.net> wrote:
>On Thu, 3 Jan 2008 11:11:02 +1300, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz> wrote:
>
>
>A big plus that Java has that CoBOL doesn't is that it is cheap and
>easy for people getting interested in programming to acquire and use.
>Those guys don't care that it's OO, only that it's available and
>works.
Let's write a Cobol compiler that's just as free, available and easy to use.
Traditionally, the compiler per se was easier than the workbench and indexed file system.
Now there are free workbenches such as Eclipse and file systems such as MyISAM. Plus
there's the gcc back-end code generator and optimizer.
| |
|
| THE biggest problem with the mainframe is that IBM never embraced a GUI
screen. That's what it's all about. Why is everyone migrating from
mainframe to servers? In almost every place I've worked or looked at, it
is always the same thing. It's not about COBOL. It's not about
performance. It's not about security. It's not about reliability. It's not
about efficiency. In many cases it's not even about cost. It's all about
pretty colors, fancy fonts, drop down boxes, scroll bars, point-click and
giggle. Everyone wants that "rich GUI experience" in their application and
you can't do that on the mainframe. People don't want 3270 screens and
haven't for 15 years. If IBM had embraced GUI screen application
development on the mainframe, we'd still have strong mainframes today.
| |
| Richard 2008-01-05, 3:55 am |
| On Jan 5, 3:05 pm, Robert <n...@e.mail> wrote:
> On Fri, 04 Jan 2008 08:13:36 -0700, Howard Brazee <how...@brazee.net> wrote:
>
>
>
>
> Let's write a Cobol compiler that's just as free, available and easy to use.
>
Just who is the 'us' that you are referring to ?
If you want to get involved then join OpenCobol or tinyCobol, or fork
their code to make your own project.
> Traditionally, the compiler per se was easier than the workbench and indexed file system.
Who told you that ?
> Now there are free workbenches such as Eclipse and file systems such as MyISAM. Plus
MyISAM is _not_ a general purpose ISAM handler, it is one of the
database support systems for MySQL.
> there's the gcc back-end code generator and optimizer.
| |
| Robert 2008-01-05, 3:55 am |
| On Fri, 4 Jan 2008 21:58:37 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:
>On Jan 5, 3:05 pm, Robert <n...@e.mail> wrote:
>
>Just who is the 'us' that you are referring to ?
Us is amorphous .. whoever volunteers.
>If you want to get involved then join OpenCobol or tinyCobol, or fork
>their code to make your own project.
I prefer to do it independently. It's not that difficult.
>
>Who told you that ?
Marc Sokol, the guy who wrote Realia.
>
>MyISAM is _not_ a general purpose ISAM handler, it is one of the
>database support systems for MySQL.
I thought it could be used for Cobol ISAM. I don't know because I haven't looked into it.
| |
| Robert 2008-01-05, 3:55 am |
| On Fri, 04 Jan 2008 23:39:47 -0600, Scott <NoSpam@Spamblocker.org> wrote:
>THE biggest problem with the mainframe is that IBM never embraced a GUI
>screen. That's what it's all about. Why is everyone migrating from
>mainframe to servers? In almost every place I've worked or looked at, it
>is always the same thing. It's not about COBOL. It's not about
>performance. It's not about security. It's not about reliability. It's not
>about efficiency. In many cases it's not even about cost. It's all about
>pretty colors, fancy fonts, drop down boxes, scroll bars, point-click and
>giggle. Everyone wants that "rich GUI experience" in their application and
>you can't do that on the mainframe. People don't want 3270 screens and
>haven't for 15 years. If IBM had embraced GUI screen application
>development on the mainframe, we'd still have strong mainframes today.
You're absolutely right.
Microsoft's GUI screens are the best. Unix's GNOME screens are second. KDE is a distant
third. Web browser HTML is almost as good as Microsoft. I say we go with Web browser and
forget the others.
| |
|
| In article <NoednW8wwYa-heLaRVn_vwA@giganews.com>,
Scott <NoSpam@Spamblocker.org> wrote:
>THE biggest problem with the mainframe is that IBM never embraced a GUI
>screen.
Ummmmm... I was taught, a few decades back, that this wasn't done because
the overhead necessary to make the mainframe architecture do what it
wasn't designed to do (graphic display) would render using the
applications prohibitively expensive. I remember, a few years before
that, being informed that a local Corner Office Idiot had sent out a memo
telling his programmers to reduce their TSO connect-costs... every byte of
core, every swap to disk, all were kept track of and had to be paid for.
I'm not sure how, nowadays, use of a graphics-intensive Linux application
gets costed-out to a department... might be interesting to look into.
DD
| |
| Judson McClendon 2008-01-05, 7:55 am |
| "Scott" <NoSpam@Spamblocker.org> wrote:
> THE biggest problem with the mainframe is that IBM never embraced a GUI
> screen. That's what it's all about. Why is everyone migrating from
> mainframe to servers? In almost every place I've worked or looked at, it
> is always the same thing. It's not about COBOL. It's not about
> performance. It's not about security. It's not about reliability. It's not
> about efficiency. In many cases it's not even about cost. It's all about
> pretty colors, fancy fonts, drop down boxes, scroll bars, point-click and
> giggle. Everyone wants that "rich GUI experience" in their application and
> you can't do that on the mainframe. People don't want 3270 screens and
> haven't for 15 years. If IBM had embraced GUI screen application
> development on the mainframe, we'd still have strong mainframes today.
You're talking about the user side. On the programmer side the equivalent
of GUI "bells & whistles" is OO. Neither is about performance or
functionality, but all about "Wow! That's neat! I want it!"
And yes, I'm programming using OO every day, have been doing so for over a
year, and I have still yet to see anything I couldn't have done simpler and
easier as procedural. After all, OO is implemented procedurally at the
machine code level. OO is, functionally, just a wrapper, so it's false to
say it couldn't be done procedurally, because it is procedural at the bottom.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Howard Brazee 2008-01-05, 7:55 am |
| On Fri, 04 Jan 2008 23:39:47 -0600, Scott <NoSpam@Spamblocker.org>
wrote:
>THE biggest problem with the mainframe is that IBM never embraced a GUI
>screen. That's what it's all about. Why is everyone migrating from
>mainframe to servers? In almost every place I've worked or looked at, it
>is always the same thing. It's not about COBOL. It's not about
>performance. It's not about security. It's not about reliability. It's not
>about efficiency. In many cases it's not even about cost. It's all about
>pretty colors, fancy fonts, drop down boxes, scroll bars, point-click and
>giggle. Everyone wants that "rich GUI experience" in their application and
>you can't do that on the mainframe. People don't want 3270 screens and
>haven't for 15 years. If IBM had embraced GUI screen application
>development on the mainframe, we'd still have strong mainframes today.
It's about allowing a student to connect his laptop computer to the
Web, log on, and sign up for a class. It's about allowing a salesman
to connect his laptop computer to the Web, enter his sales and pull up
some graphs.
The functionality is more than just the pretty face.
| |
| Judson McClendon 2008-01-05, 7:55 am |
| "Howard Brazee" <howard@brazee.net> wrote:
> Scott <NoSpam@Spamblocker.org> wrote:
>
> It's about allowing a student to connect his laptop computer to the
> Web, log on, and sign up for a class. It's about allowing a salesman
> to connect his laptop computer to the Web, enter his sales and pull up
> some graphs.
>
> The functionality is more than just the pretty face.
Now yes, but not in the 1980's when this trend started, because the Internet
hadn't even been born.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| William M. Klein 2008-01-05, 6:56 pm |
|
"Robert" <no@e.mail> wrote in message
news:4rbun3pb9ol97hsgmbkksot82vctdpekn4@
4ax.com...
> On Fri, 4 Jan 2008 21:58:37 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:
>
<snip>
>
> I prefer to do it independently. It's not that difficult.
>
(Generalized snide comment follows)
It is people who think that, that explains why no one understands why COBOL
vendors still exist and make profits - and why no fully conforming '85 (much
less '02) "open source" Standard has been completed.
If nothing else, simply try and figure out how to create ALL the CONFORMING code
for COBOL "copy replacing" some time.
--
Bill Klein
wmklein <at> ix.netcom.com
| |
| SkippyPB 2008-01-05, 6:56 pm |
| On Sat, 5 Jan 2008 08:08:50 +0000 (UTC), docdwarf@panix.com () wrote:
>In article <NoednW8wwYa-heLaRVn_vwA@giganews.com>,
>Scott <NoSpam@Spamblocker.org> wrote:
>
>Ummmmm... I was taught, a few decades back, that this wasn't done because
>the overhead necessary to make the mainframe architecture do what it
>wasn't designed to do (graphic display) would render using the
>applications prohibitively expensive. I remember, a few years before
>that, being informed that a local Corner Office Idiot had sent out a memo
>telling his programmers to reduce their TSO connect-costs... every byte of
>core, every swap to disk, all were kept track of and had to be paid for.
>
>I'm not sure how, nowadays, use of a graphics-intensive Linux application
>gets costed-out to a department... might be interesting to look into.
>
>DD
And why is GUI the answer? Have users become so "dumb" they can't
figure out to use a straightforward 3270 screen? They can't press the
ENTER key on the keyboard, they need a mouse to place a pointer on an
"ENTER" box? The 3270 screen is too scary? It's ridiculous.
My employer has an application that "paints" 3270 screens. That is,
you can use it to design inquiry, data entry or a combination of the
two screens and then run a batch program that will create the copybook
and BMS code. For certain 3270 type monitors, it can also put color
on the screen. In the early 90's I and a colleague went to Athens,
Greece to work on a presentation of our software with our partner
there. The requirement? Make an inquiry screen on a 3270 monitor
look like a GUI screen. We did as much as was possible. After all,
BMS couldn't do graphics. But the requirement (not presented by any
IT people, by the way) seemed to say, our people aren't smart enough
to work a 3270 screen. It seems that sentiment is still around in
some corners and I've yet to meet a user who couldn't effectively use
a 3270 screen.
Regards,
////
(o o)
-oOO--(_)--OOo-
"Research is what I'm doing when I don't know what I'm doing."
--Wernher von Braun
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Remove nospam to email me.
Steve
| |
|
| Howard Brazee <howard@brazee.net> wrote in
news:ietun3hsk4uiug3ilj27mcr0ll7t3k8p0t@
4ax.com:
> It's about allowing a student to connect his laptop computer to the
> Web, log on, and sign up for a class. It's about allowing a salesman
> to connect his laptop computer to the Web, enter his sales and pull up
> some graphs.
>
> The functionality is more than just the pretty face.
It is about a pretty face WITH functionality and you cannot have
a pretty face on the mainframe. Companies always want the pretty screens
and the mainframe loses because of it, in spite of its clear advantage in
almost every other area.
I'm sorry to say but as a Systems Analyst, over and over again, users
and management are always more interested in how an application LOOKS
than in how it WORKS. Of course if it doesn't work right there is a big
problem. But the point is, in every phase of an application life cycle,
to the people outside of I.T. who hold the purse strings, LOOKING good
is always their first priority. And to THEM, looking good MEANS
functionality. That's what screws the mainframe.
It may have cost IBM a pretty penny years ago to make graphic screens
but what is it costing them now? Short-sighted corporate mentality
loses the business again.
| |
|
| That's all true. But the fact is people don't want 3270 screens.
Not because they're not functional or people can't use them but because
3270 screens look "old". It reminds people of MS-DOS. Graphic screens look
"new". They look like Windows. Users and management who hold the purse
strings and make the decisions want their I.T. applications to look "new"
despite everything else.
| |
| tlmfru 2008-01-05, 6:56 pm |
|
Scott <NoSpam@Spamblocker.org> wrote in message
news:NoednW8wwYa-heLaRVn_vwA@giganews.com...
> THE biggest problem with the mainframe is that IBM never embraced a GUI
> screen. That's what it's all about. Why is everyone migrating from
> mainframe to servers? In almost every place I've worked or looked at, it
> is always the same thing. It's not about COBOL. It's not about
> performance. It's not about security. It's not about reliability. It's not
> about efficiency. In many cases it's not even about cost. It's all about
> pretty colors, fancy fonts, drop down boxes, scroll bars, point-click and
> giggle. Everyone wants that "rich GUI experience" in their application and
> you can't do that on the mainframe. People don't want 3270 screens and
> haven't for 15 years. If IBM had embraced GUI screen application
> development on the mainframe, we'd still have strong mainframes today.
>
It's easy, of course, to be wise after the fact. At the time GUI's didn't
exist and nobody except a few wizards at Palo Alto knew anything about them.
In fact, when PC's first became generally available - IBM, remember - there
was a good deal of skepticism about their general usefulness; "real"
computers those days had a big data entry department, and nobody really
thought that users would be willing to take on that burden. They were, of
course, in the long run. And it wasn't the GUI that made PC's take off; it
was the introduction of the first popular spreadsheet that made it happen -
Visicalc, I think? - but not so much because of the application; I myself
wrote a crude batch-oriented spreadsheet-like program about 1979; it was the
realization that the screen could be made infinitely extensible in any
direction that was the breakthough. Until then nearly everybody had written
programs that fit strictly on the screen! It's impossible to predict with
any certainty what will be a breakthrough.
There was a time when IBM's continued existence was a topic for considerable
debate. There was also no lack of helpful advice. One innocent soul
recommended that IBM scrap all its operating systems and implement Windows
on them. Like that was going to happen!
Although I haven't worked with IBM's mainframes for a long time I'm certain
that there's a way of wrapping GUIs around the green-screen applications
thereby giving the users the rich experience they want.
I question just how rich an experience users actually want. I know I get
very tired of plowing through all the fancy stuff when I have a specific
goal in mind: and I get extremely mad and take my business elsewhere when a
vendor tells me my browser isn't supported. My most recent such experience
was with an airline; in my innocence I though the only requirement to fly
with them was to have enough money; but no, all its customers had to have
the very latest browser as well. So far as I'm concerned, the appearance is
a very poor second to the functionality, and if that means a duller site and
the lowest-common-denominator coding then so be it.
PL
| |
| Richard 2008-01-05, 6:56 pm |
| On Jan 5, 8:39 pm, Robert <n...@e.mail> wrote:
> On Fri, 04 Jan 2008 23:39:47 -0600, Scott <NoS...@Spamblocker.org> wrote:
>
> You're absolutely right.
>
> Microsoft's GUI screens are the best. Unix's GNOME screens are second. KDE is a distant
> third.
What people think as 'best', or even acceptable, is entirely what
_they_ are used to. I prefer most that I have used on Linux over the
several different Microsoft ones because I am used to them.
> Web browser HTML is almost as good as Microsoft. I say we go with Web browser and
> forget the others.
How many graphical web browsers in general use don't require an
underlying graphical OS ?
Lynx, for example, does much HTML but I wouldn't call it 'as good as
<favourite GUI>'.
In any case, what you call 'Web browser HTML' is probably not that at
all, but is the result of JavaScript and various widget sets.
| |
|
| "tlmfru" <lacey@mts.net> wrote in news:pUPfj.5192$OC1.1484@newsfe20.lga:
I gave the same argument for years. It just isn't what management and
user's want I have finally realized. To the people who hold the purse
strings and make the decisions, graphic screens are "new", 3270 screens
are "old" and they want "new technology" not "old technology" even if it
ISN'T better.
As a programmer and analyst I agree with you that functionality and
performance should come first. But appearance is what they want and
they associate that with functionality. To the decision makers,
functionality MEANS drop down boxes, scroll bars, pictures and graphics,
point and click. That's what they want, they have the money and the power,
so they put everything on Windows or UNIX and get rid of the mainframe.
Real functionality, maintainability, performance, security, reliability
and so on is not something they understand anyway.
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:42d757df-f66c-4d14-8e31-6e26d3d8bee7@e10g2000prf.googlegroups.com...
> On 2 Jan, 22:43, Richard <rip...@azonic.co.nz> wrote:
>
> <rant and counter-rant snipped>
>
>
> Richard, I thought that was Pete having a rant!
>
Then you were also mistaken.
If/when I have a rant I'll put rant tags around it... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"tim Josling" <tejgcc_nospam@westnet.com.au> wrote in message
news:13nrm4bdaf19bab@corp.supernews.com...
> On Fri, 04 Jan 2008 01:20:41 +1300, Pete Dashwood wrote:
>
>
> Do you have any evidence for this claim? I always thought it was self
> evident until I tried to prove it to someone. Then I found out the
> evidence - both anecdotal and academic - that I was able to find at the
> time was weak to nonexistent.
The only evidence I have is empirical.
Since moving to this paradigm I find I can develop stuff much quicker and I
don't spend time maintaining old code.
I can't quantify it, because the difference is so dramatic I never needed
to.
I would accept that in large organisations, if this approach is not
carefully managed and implemented, it could lead to a loss of most of the
gains.
However, that is true for just about any approach that isn't properly
managed... :-)
Source code maintenance is something that consumes vast amounts of computer
and personnel resource. We are better off with any approach that reduces or
eliminates it. CBD does this.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:m3rsn39i54r3b316e35d2mhltk7oef9nav@
4ax.com...
> On Fri, 4 Jan 2008 11:14:22 -0600, "tlmfru" <lacey@mts.net> wrote:
>
>
> Acquiring in this case means acquiring a compiler and working
> environment.
>
> With a compiler, it is relatively easy to learn to create a business
> level program using CoBOL. But a high school kid wanting to play
> around with programming will find it easier and cheaper to get what he
> needs to write a simple Java program that works on his web page. Then
> he makes one a bit more complex. Incrementally he learns more and
> more without having to spend money.
Exactly.
The other point that is beng ignored is that procedural imperative languages
like COBOL are not relevant to today's main requirements.
(In other words, even if it was free, there is little point in acquiring
COBOL any more...)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"Robert" <no@e.mail> wrote in message
news:mvotn353kn9mv2j3dvl50r34c11iavp7ru@
4ax.com...
> On Fri, 04 Jan 2008 08:13:36 -0700, Howard Brazee <howard@brazee.net>
> wrote:
>
>
> Let's write a Cobol compiler that's just as free, available and easy to
> use.
There are some people doing that currently.(I admire their tenacity and
actually wish them well, however I believe it is too late...)
Again, it is the paradigm of procedural imperative code that is no longer
relevant. If it ain't OO, there is little room for it, except in niches like
batch processing and even these are rapidly closing. If the Network can
handle everything on line, there is no need for batch processing; even
historical queries that need to scan cubes and DWs can run online as
background processes, and, with modern approaches like LINQ and Functional
Programming, can run across parallel processors with deferred execution,
which an imperative language cannot support.
People here need to step back and get their heads out of the way it has
"always been".
Don't take my word for it... expand your horizons a bit. GOOGLE on
Functional Programming and LINQ. Watch a few videos with movers and shakers
who ARE influencing the future.
The world is changing.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:s9Mfj.174560$DQ1.35507@fe03.news.easynews.com...
>
> "Robert" <no@e.mail> wrote in message
> news:4rbun3pb9ol97hsgmbkksot82vctdpekn4@
4ax.com...
> <snip>
>
> (Generalized snide comment follows)
>
> It is people who think that, that explains why no one understands why
> COBOL vendors still exist and make profits - and why no fully conforming
> '85 (much less '02) "open source" Standard has been completed.
I believe some of the existing COBOL vendors will not be flogging COBOL by
2015.
The only way they can continue to "exist and make profits" is by offing a
pathway to New Technology. The ones who haven't done this or are not in the
process of doing it, are unlikely to be with us for long...
Robert's comment about "doing it independently" is not really a valid excuse
as to why the Standards process is a joke... For every "Robert" there are
thousands of "NOT Robert"s :-), and yet the process is still moribund...
>
> If nothing else, simply try and figure out how to create ALL the
> CONFORMING code for COBOL "copy replacing" some time.
>
One solution to that would be to simplify what is "conforming" (...move the
goal posts so they are within sprinting distance. :-) )
Perhaps part of the problem in the past has been TOO grand a design... I
dunno. All I know is that we waited 17 years for a standard.
And when it arrived, no-one wanted to implement it.
That should tell all of us something...
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"Scott" <NoSpam@Spamblocker.org> wrote in message
news:NoednW8wwYa-heLaRVn_vwA@giganews.com...
> THE biggest problem with the mainframe is that IBM never embraced a GUI
> screen. That's what it's all about. Why is everyone migrating from
> mainframe to servers? In almost every place I've worked or looked at, it
> is always the same thing. It's not about COBOL. It's not about
> performance. It's not about security. It's not about reliability. It's not
> about efficiency. In many cases it's not even about cost. It's all about
> pretty colors, fancy fonts, drop down boxes, scroll bars, point-click and
> giggle. Everyone wants that "rich GUI experience" in their application and
> you can't do that on the mainframe. People don't want 3270 screens and
> haven't for 15 years. If IBM had embraced GUI screen application
> development on the mainframe, we'd still have strong mainframes today.
>
If the manframe COBOL community had embraced OO, you might have HAD GUI on
the mainframe... (OO empowers a GUI approach)
It is all supposition and postulation.
We'll never know.
I read your paragraph above with some sympathy. I think you're right that
people wanted GUI (once they saw their kids using it on their Amigas and
Sinclairs at home :-))
(I remember talking to the CEO of a major UK utility and asking why they
were sending out letters to customers without signatures and on green
lineflo... A multi-million dollar system, that couldn't do what a PC or Mac
that cost less than a thousandth of the price could do all day long standing
on its head, as a fundamental principle.)
Given that people (Users) actually WANTED a GUI (or at least, something more
intuitive than a command line...) interface, don't you think it is incumbent
on us as IT professionals to try and address that need?
Mainframes CAN do GUI, they just need a different approach from the
imperative COBOL one. And the IT community was not about to accept that.
(Judging from this forum, they still aren't...:-))
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"SkippyPB" <swiegand@nospam.neo.rr.com> wrote in message
news:3advn3dqjr3ke83pa789k6i42irdorrpvf@
4ax.com...
> On Sat, 5 Jan 2008 08:08:50 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
> And why is GUI the answer? Have users become so "dumb" they can't
> figure out to use a straightforward 3270 screen? They can't press the
> ENTER key on the keyboard, they need a mouse to place a pointer on an
> "ENTER" box? The 3270 screen is too scary? It's ridiculous.
No Steve, it isn't ridiculous and it isn't because they're dumb.
It is because it is a more INTUITIVE interface. Why should every user have
to become a computer programmer in order to understand and interface with a
computer?
Why should we, as computer professionals, IGNORE what users are asking for
and tell them "our way, or the highway..."?
Can you honestly say you know EVERY command and parameter for
DOS/TSO/SQL/NET or any other CLI application?
And if you do, that's fair enough; computers are your job. Why should
someone who just wants a Sales Report, or to see how a certain department is
going against budget, have to suffer the same brain damage?
Aren't computer professionals smart enough to make these systems useful for
the majority of people? Are they so dumb? It's ridiculous...:-)
>
> My employer has an application that "paints" 3270 screens. That is,
> you can use it to design inquiry, data entry or a combination of the
> two screens and then run a batch program that will create the copybook
> and BMS code. For certain 3270 type monitors, it can also put color
> on the screen. In the early 90's I and a colleague went to Athens,
> Greece to work on a presentation of our software with our partner
> there. The requirement? Make an inquiry screen on a 3270 monitor
> look like a GUI screen. We did as much as was possible. After all,
> BMS couldn't do graphics. But the requirement (not presented by any
> IT people, by the way) seemed to say, our people aren't smart enough
> to work a 3270 screen. It seems that sentiment is still around in
> some corners and I've yet to meet a user who couldn't effectively use
> a 3270 screen.
>
It isn't that people CAN'T be trained to use 3270s; we know from the 1960s
that that is possible. It is a question of what is EASIER and INUITIVE.
Icons and windows fit this bill much better than command lines, that's
all...
Pete.
--
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:lAKfj.62062$K27.47894@bignews6.bellsouth.net...
> "Scott" <NoSpam@Spamblocker.org> wrote:
>
> You're talking about the user side. On the programmer side the equivalent
> of GUI "bells & whistles" is OO. Neither is about performance or
> functionality, but all about "Wow! That's neat! I want it!"
>
> And yes, I'm programming using OO every day, have been doing so for over a
> year, and I have still yet to see anything I couldn't have done simpler
> and
> easier as procedural. After all, OO is implemented procedurally at the
> machine code level. OO is, functionally, just a wrapper, so it's false to
> say it couldn't be done procedurally, because it is procedural at the
> bottom.
If you really believe that, then you have missed the major benefits of OO.
If you are running OO on a mainframe, there is some truth in your points;
your objects ARE "implemented procedurally at the machine code level."
(Although there are still conceptual and design benefits from using
objects.) However, as soon as you start to instantiate objects remotely
across the network you have a completely different paradigm. Encapsulation
permits any number of objects to run in parallel, which your procedural code
has to be specially written to support. (And it adds complexity which
exacerbates maintaining it...)
OO is a lot more than "just a wrapper" although I agree it can be that, if
that is how you write it.
You can't drop procedural modules into web pages, or have them run on ANY
platform across the network, at ANY location anywhere on Earth...
Objects can do this, and do it easily.
Think again. :-)
Pete.
--
"I used to write COBOL... now I can do anything."
| |
| Pete Dashwood 2008-01-05, 6:56 pm |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:zIKfj.62066$K27.55895@bignews6.bellsouth.net...
> "Howard Brazee" <howard@brazee.net> wrote:
>
>
> Now yes, but not in the 1980's when this trend started, because the
> Internet
> hadn't even been born.
ARPANET and scholastic networks like JANET were running from the late
60s.(First live ARPANET node, september, 1969 at UCLA; JANET evolved from a
number of earlier nets dating back to mid 70s, but first went live as JANET
in 1983, with 50 nodes connected.)While the Internet may have been
technically born in 1991, objects were around long before that. XEROX SPARC
and Smalltalk are the accepted inception of what we now recognise as
"Objects", and the most widely used implementation of Smalltalk was
released in 1980, but similar functionality was available in the mid 70s.
Xerox Palo Alto had been experimenting with these concepts in the mid 70s
and they were not the only ones.
Creationism cannot be applied to the Internet, although there may be a case
for "intelligent design"...:-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Robert 2008-01-05, 6:56 pm |
| On Sat, 5 Jan 2008 11:33:55 -0800 (PST), Richard <riplin@azonic.co.nz> wrote:
>On Jan 5, 8:39 pm, Robert <n...@e.mail> wrote:
>
>What people think as 'best', or even acceptable, is entirely what
>_they_ are used to. I prefer most that I have used on Linux over the
>several different Microsoft ones because I am used to them.
Here are packages that make WinXP look like Mac OSX, Vista, Fedora and Ubuntu.
http://www.makeuseof.com/tag/5-pack...ws-to-other-os/
The most impressive cross-OS tool I've seen is Ch by softintegration.com. It provides a
Unix command line prompt under Windows. Its shell scripting language is C. One can execute
C source, type C on the command line, run Unix commands and execute DOS and Windows
programs. Try it, I think you'll be impressed.
>
>How many graphical web browsers in general use don't require an
>underlying graphical OS ?
Unix/Linux is not a graphical OS. Graphics is provided by X server. Most graphics apps use
either the GTK libraries, used by GNOME and most open source including Firefox, or the PNG
libraries used by KDE.
The Windows kernel is not graphical, either. Graphics is provided by GDI, which is
analogous to X, and the comxxx libraries, which are equivalent to GTK and PNG.
Mac OS X *is* a graphical OS. It doesn't use X server, despite the name confusion; its
graphical services are called Quartz. It has an optional X-to-Quartz bridge for running
apps developed for other flavors of Unix. More significantly, OS X is the only (surviving)
OO OS.
>Lynx, for example, does much HTML but I wouldn't call it 'as good as
><favourite GUI>'.
>
>In any case, what you call 'Web browser HTML' is probably not that at
>all, but is the result of JavaScript and various widget sets.
What I call Web browser HTML is defined by Standards such as
http://www.rfc-editor.org/rfc/rfc2854.txt
https://www.cs.tcd.ie/15445/15445.HTML
http://www.w3.org/TR/xhtml2/
It's not home grown like "various widget sets". That's why Firefox looks the same on every
OS (where it runs).
| |
| Judson McClendon 2008-01-05, 9:57 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> ARPANET and scholastic networks like JANET were running from the late 60s.(First live ARPANET node, september, 1969 at UCLA; JANET
> evolved from a number of earlier nets dating back to mid 70s, but first went live as JANET in 1983, with 50 nodes connected.)While
> the Internet may have been technically born in 1991, objects were around long before that. XEROX SPARC and Smalltalk are the
> accepted inception of what we now recognise as "Objects", and the most widely used implementation of Smalltalk was released in
> 1980, but similar functionality was available in the mid 70s. Xerox Palo Alto had been experimenting with these concepts in the
> mid 70s and they were not the only ones.
And not one user in 10,000 was aware of them, therefore they did not
affect user desires, which is my point. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Judson McClendon 2008-01-05, 9:57 pm |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
> "Judson McClendon" <judmc@sunvaley0.com> wrote:
>
> If you really believe that, then you have missed the major benefits of OO.
OO is simply a different paradigm for solving problems, no more, no less.
You appear to assign mystical properties to it.
> If you are running OO on a mainframe, there is some truth in your points; your objects ARE "implemented procedurally at the
> machine code level." (Although there are still conceptual and design benefits from using objects.) However, as soon as you start
> to instantiate objects remotely across the network you have a completely different paradigm. Encapsulation permits any number of
> objects to run in parallel, which your procedural code has to be specially written to support. (And it adds complexity which
> exacerbates maintaining it...)
>
> OO is a lot more than "just a wrapper" although I agree it can be that, if that is how you write it.
The overwhelming majority of PC on the planet are Intel, or Intel compatible.
None of those CPU's knows what an object is. OO *IS* a "wrapper". Q.E.D.
> You can't drop procedural modules into web pages, or have them run on ANY platform across the network, at ANY location anywhere on
> Earth...
CGI. Pete, you appear to be confusing interrupt driven processing with OO.
There is not a recursive algorithm that cannot be coded iteratively, and there
is not an OO algorithm that cannot be coded procedurally. Just fact. You
appear to be blinded by the dog and pony show.
> Objects can do this, and do it easily.
>
> Think again. :-)
I've been thinking. :-)
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Robert 2008-01-05, 9:57 pm |
| On Sat, 5 Jan 2008 12:20:50 -0600, "tlmfru" <lacey@mts.net> wrote:
>
>Scott <NoSpam@Spamblocker.org> wrote in message
>news:NoednW8wwYa-heLaRVn_vwA@giganews.com...
>
>It's easy, of course, to be wise after the fact. At the time GUI's didn't
>exist and nobody except a few wizards at Palo Alto knew anything about them.
>In fact, when PC's first became generally available - IBM, remember - there
>was a good deal of skepticism about their general usefulness; "real"
>computers those days had a big data entry department, and nobody really
>thought that users would be willing to take on that burden.
When the IBM PC appeared in 1982, I KNEW it was a revolution. I bought one with $2,000 of
my own money. A few months later I bought several with the company's money and moved half
its programmrs to developing PC software.
One of the first things I did, as proof of concept, was a drag race between a small
mainframe, 4361 with 3310 disks running VSE, versus a 4.77 MHz PC with a slow 10 M disk.
The application was my idea of typical batch processing against an indexed/VSAM file. The
PC won!!
The first application I wrote, in compiled Basic and a little assembly, had an audio user
interface over the telephone. It said push 1 for this, 2 for that. Its basic function was
receiving supermarket orders from handheld Telxon computers that talked through 1200 baud
acoustic couplers. When the user pushed 1 to send an order, the PC turned off a
voice/DTMF modem and turned on a 1200 baud data modem .. without dropping the telephone
connection. At the end of the order, it reversed the switch and spoke a hash total that
the user compared to the hash total on his screen. Other functions involved checking the
status of orders. The store manager could call from his home phone to check the various
departments in his store. The response would say 'Grocery order due at 6PM, received at
5:17. Meat order due at 5PM, not received yet. Produce order due at 6AM tomorrow.'
That's easy today, with off the shelf hardware. In 1983, all we had was analog to digital
converters. We had to digitize the speech ourselves, write our own audio editors and feed
the speech sounds to the telephone.
The application multi-tasked under MSDOS. Each machine could simultaneously handle four
phone lines and eight modems. In production, the company had eight machines connected to
32 phone lines. After I left in 1986, one of my guys rewrite it in Realia Cobol, which
made it run 2-3 times faster. It ran in production for ten years.
>They were, of
>course, in the long run. And it wasn't the GUI that made PC's take off; it
>was the introduction of the first popular spreadsheet that made it happen -
>Visicalc, I think? - but not so much because of the application; I myself
>wrote a crude batch-oriented spreadsheet-like program about 1979; it was the
>realization that the screen could be made infinitely extensible in any
>direction that was the breakthough. Until then nearly everybody had written
>programs that fit strictly on the screen! It's impossible to predict with
>any certainty what will be a breakthrough.
In 1988 Lucid had the breakthrough idea that spreadsheets could be three dimentional. Our
(I worked there) Lucid 3D won the PC Magazine award for best application, and the idea was
promptly copied by Lotus and Microsoft.
The feature still exists in Excel, but isn't widely used (I could be wrong). It wasn't
such a breakthrough after all. Importing and exporting data to csv and XML was a better
idea.
>There was a time when IBM's continued existence was a topic for considerable
>debate. There was also no lack of helpful advice. One innocent soul
>recommended that IBM scrap all its operating systems and implement Windows
>on them. Like that was going to happen!
Unix would have been an excellent suggestion. Users could have kept old iron instead of
replacing it with Sun and HP. Of course, IBM would have been forced to lower the price by
50-90%. As it happened, they lost 100%.
>Although I haven't worked with IBM's mainframes for a long time I'm certain
>that there's a way of wrapping GUIs around the green-screen applications
>thereby giving the users the rich experience they want.
Many have tried. The problem is that the underlying app is state-oriented. It's expecting
the user to enter one field.
>I question just how rich an experience users actually want. I know I get
>very tired of plowing through all the fancy stuff when I have a specific
>goal in mind: and I get extremely mad and take my business elsewhere when a
>vendor tells me my browser isn't supported. My most recent such experience
>was with an airline; in my innocence I though the only requirement to fly
>with them was to have enough money; but no, all its customers had to have
>the very latest browser as well. So far as I'm concerned, the appearance is
>a very poor second to the functionality, and if that means a duller site and
>the lowest-common-denominator coding then so be it.
Tell them you want backward compatibility to the green screen. Let us know what they say.
Better yet, tell them you want the text mode SABRE user interface that was once the norm
with travel agents. It was the most arcane, cryptic thing I've ever seen, and I've seen
some pretty bad ones. Ugly interfaces like that are designed by programmer types sitting
in conference rooms, smugly referring to "dumb users." Then they act hurt because users
abandoned them for flash and eye candy. If they'd designed the interface for the
convenience of users, rather than programmers and bureaucrats, they'd still be happily
married to users.
| |
|
| Judson McClendon wrote:
>
> And yes, I'm programming using OO every day, have been doing so for over a
> year, and I have still yet to see anything I couldn't have done simpler and
> easier as procedural.
I've been doing it right at 10 months (so I guess I'm a little behind
you), but I'm of a completely different opinion. OO has saved me
*loads* of time. In fact, now when I hear a problem being described, my
mind automatically starts breaking it up into the objects that will be
affected, and the information they need to exchange to make it happen.
Just this past w, I had to write some code for a process that was
very similar to another one. What I did was look at what the old one
did, look at what I needed, *and* look at future known requirements, and
I was able to break the original object up into three objects, then
subclass the second to make mine. I didn't have to write *any* of that
code, because it had already been written.
(It was a "data extraction" query. The top-level object is "BaseQuery",
which has a name, how often to run, what user created it, etc. The next
level is "BaseReportQuery", which is designed to run queries off
reports. It adds word-search capability, and Word and Excel output
options. Finally, the next level represents the actual object from the
system ("IllnessQuery", in my case - it searches occupational illness
investigations). It contains the input for the query.
I've also written an MVC (Model/View/Controller) framework for PHP. It
took a little while to get it tweaked the way I wanted it for the first
few pages, but once I got that, it actually helped me make further pages
much more quickly. (As an added bonus, HTML isn't embedded in PHP files!)
The "control script" creates the "UI Service", which provides an XML
tree in memory that has certain page attributes. Then, the control
script will instantiate "Page" objects if there's dynamic stuff to be
done, and they append data to the XML tree. Finally, the control script
tells the UI service to render the page, and the XML tree is rendered
using an XSLT stylesheet. This is done on the server, so I don't have
to rely on the browser to do it. There are other objects (the ones to
represent the actual data), and a database service that creates an
abstraction layer from the database.
Yes, all this *could* have been done procedurally. However, I don't
think I would have come up with that design had I been thinking
procedurally.
I don't know if you were around when I posted my "My First C#" post.
The feedback I got from it (in here) was really, really great. In fact,
I didn't realize the brilliance of some of that advice until I got to my
new job and started doing OO exclusively every day. The biggest thing
that helped me, I think, is the "one method, one responsibility"
concept. If the building blocks are small enough, you can put them
together quickly. If they're too big, you have to take the time to
either split them apart, or add "another" parameter to alter the
behavior under a certain condition. (And yes, it is valid OO to have a
method whose one responsibility is putting the pieces together - in
fact, that's probably the main method in the class.)
> After all, OO is implemented procedurally at the
> machine code level. OO is, functionally, just a wrapper, so it's false to
> say it couldn't be done procedurally, because it is procedural at the bottom.
For me, it's been a mindset shift - and I have seen it benefit me.
Maybe I'm in a shop where it's done right. :) (Not implying anything
about yours, of course...)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++
"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Pete Dashwood 2008-01-06, 3:55 am |
|
"Judson McClendon" <judmc@sunvaley0.com> wrote in message
news:ApWfj.62806$K27.23987@bignews6.bellsouth.net...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote:
>
> OO is simply a different paradigm for solving problems, no more, no less.
> You appear to assign mystical properties to it.
>
>
> The overwhelming majority of PC on the planet are Intel, or Intel
> compatible.
> None of those CPU's knows what an object is. OO *IS* a "wrapper". Q.E.D.
>
>
> CGI.
CGI is SERVER SIDE code. You can't drop modules on to Web Pages and have
them execute.
It isn't me who is  ...
>Pete, you appear to be confusing interrupt driven processing with OO.
Give me a break... I was writing interrupt driven processes long before OO
was ever considered.
I DO know the difference.
> There is not a recursive algorithm that cannot be coded iteratively, and
> there
> is not an OO algorithm that cannot be coded procedurally. Just fact. You
> appear to be blinded by the dog and pony show.
Not true,but I see no point in arguing it. It IS true that there is no
serial algorithm that cannot be coded procedurally, but there are other
classes of algorithms (viz. Functional, Cellular, and multithreaded
Heuristic programming techniques...) which simply cannot be coded serially.
The Von Neumann model is just one of many.
I see no dog and pony; I see someone who has missed some major concepts...
It really doesn't matter.
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| Pete Dashwood 2008-01-06, 3:55 am |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:FdidnWXlad8m3x3anZ2dnUVZ_oCvnZ2d@co
mcast.com...
> Judson McClendon wrote:
>
> I've been doing it right at 10 months (so I guess I'm a little behind
> you), but I'm of a completely different opinion. OO has saved me
> *loads* of time. In fact, now when I hear a problem being described, my
> mind automatically starts breaking it up into the objects that will be
> affected, and the information they need to exchange to make it happen.
>
> Just this past w, I had to write some code for a process that was
> very similar to another one. What I did was look at what the old one
> did, look at what I needed, *and* look at future known requirements, and
> I was able to break the original object up into three objects, then
> subclass the second to make mine. I didn't have to write *any* of that
> code, because it had already been written.
Great stuff, Daniel. Thanks for posting this.
>
> (It was a "data extraction" query. The top-level object is "BaseQuery",
> which has a name, how often to run, what user created it, etc. The next
> level is "BaseReportQuery", which is designed to run queries off
> reports. It adds word-search capability, and Word and Excel output
> options. Finally, the next level represents the actual object from the
> system ("IllnessQuery", in my case - it searches occupational illness
> investigations). It contains the input for the query.
>
> I've also written an MVC (Model/View/Controller) framework for PHP. It
> took a little while to get it tweaked the way I wanted it for the first
> few pages, but once I got that, it actually helped me make further pages
> much more quickly. (As an added bonus, HTML isn't embedded in PHP files!)
>
> The "control script" creates the "UI Service", which provides an XML
> tree in memory that has certain page attributes. Then, the control
> script will instantiate "Page" objects if there's dynamic stuff to be
> done, and they append data to the XML tree. Finally, the control script
> tells the UI service to render the page, and the XML tree is rendered
> using an XSLT stylesheet. This is done on the server, so I don't have
> to rely on the browser to do it. There are other objects (the ones to
> represent the actual data), and a database service that creates an
> abstraction layer from the database.
>
> Yes, all this *could* have been done procedurally. However, I don't
> think I would have come up with that design had I been thinking
> procedurally.
Precisely my point to Judson.
>
> I don't know if you were around when I posted my "My First C#" post.
> The feedback I got from it (in here) was really, really great. In fact,
> I didn't realize the brilliance of some of that advice until I got to my
> new job and started doing OO exclusively every day. The biggest thing
> that helped me, I think, is the "one method, one responsibility"
> concept. If the building blocks are small enough, you can put them
> together quickly. If they're too big, you have to take the time to
> either split them apart, or add "another" parameter to alter t | | |