Re: Hobby languages

Nomen Nescio wrote:
It is an excellent way to pick up the concepts of Object
Orientation, as it was designed around those concepts.

No it is not. It is an excellent way to pick up Java's view of OO,
which is not the same thing.

And what part of "Java's view of OO" is NOT OO?

If by "dumbing down" you mean simpler, less intricate code, then how
is that a bad thing?

Because 100 out of 100 Java "programmers" have no idea what the
machine is doing, and 99/100 Java coders have no idea what the JVM is
doing.

Donkeys eat carrots.
You eat carrots
Therefore you are a donkey.

"100 out of 100" eh?

I'm a Java programmer (inasmuch as I can and have programmed working
applications in Java.) I know what the machine is doing and I understand the
JVM just as I understand CLR for .NET

You statement would therefore appear to be erroneous. (There is at least ONE
donkey who DOESN'T eat carrots. :-))

Actually, even if you were right, why would it matter? A programming
language is intended for you to communicate with a computer. If you speak in
English with someone whose native language is Swahili, do you have to know
Swahili before you can be sure they understood what you said?


.I don't consider anything that enables idiots to write code
that more or less provides the desired output as helpful or
worthwhile.

And, by "idiots" you mean anyone other than yourself, or those who espouse
the same approach as you do?

"sloppy" : Languages are not sloppy; programmers are sloppy.

Not true, language designs themselves can be sloppy, and Java is an
example of that.

Perhaps you could provide a sample to support your contention, rather than
just an assertion?


"unsafe" : Competent programmers and compilers/interpreters make
code in any language safe.

Also not true, Java constrains you and simply doesn't offer the
facilities it should, so no matter how competent you are you can't
write safe code in Java.

Really?

I wonder what the World's Java programmers will make of that?

Again, something a bit more than just a high-handed assertion might help
your case.


There are benefits in using Java or any other high level language
over most Assembler level languages, but compactness of code and run
time are not one of those particular benefits. That doesn't mean it
is bloated, it just means the resources provided are being used to
obtain benefits that weren't previously available or to obtain
benefits that are considered to be more important than size of
runtime.

I haven't seen any code worth writing where the questionable
usefulness or "benefits" of Java are worth the burden of a VM and
runtime.


Just as well you don't get to make financial decisions regarding computer
system development then...:-) I'd love to know how you decide that code is
"worth writing"... maybe some other time over a beer :-)

It is just silly in this day and age, with the computing resources
now available, to rant about modern languages "dumbing down" the art
of programming and requiring bloated resources. There was a time
(when we managed overlays manually in very limited memory) when
these things were important. Nowadays, except for some highly
specialised command and control and real time processing systems
(which are not a general part of commercial application
development), they are not.

I don't agree with your view, and it's clear that people who share it
are wrong.

ROFL! Don't worry, there are only a few of us... :-)


True, computing resources have grown but not to offset the
performance costs of sloppy code and poorly designed languages and
applications. That is one of the reasons we're in a recession,
because the costs of doing business based on incompetent CTO's making
incorrect technical decisions has made IT a huge cost.

Present your findings to the next G8 conference. (You could be up for a
Nobel prize, and I'm sure everybody will be immensely relieved to find that
all they have to do is revamp their IT practises..:-)) IT is NOT a huge
cost. In fact, it is cheaper now than it has ever been. While, I wouldn't
disagree there are some very poor CTOs, that doesn't mean they are ALL
wrong. There are some very smart ones as well. (I know one or two...) Many
companies are taking IT decisions which make sense in the current economic
climate. Not because IT is expensive or because their CTO is incompetent,
but because the recession is forcing ALL areas of the company to be
scrutinised. Sometimes this scrutiny reveals that historically embedded
practices (both in SOPs AND IT) are costing a lot more than they should be
and alternatives need to be found.

Sometimes the alternatives can be outsourcing, packages, even Java... :-) I
don't know of any cases where they moved to assembler language as a cost
saving measure... :-)

You shouldn't
need to buy a new mainframe every year or two according to your view,
but you do need to because of inefficient code and applications.

I actually have no opinon about how often someone should replace their
mainframe; largely because my company doesn't currently use a mainframe.
However, for the sake of this discussion, let's say I don't think people
need to buy a new mainframe every year or two. And yet they do. Is it
because of "inefficient code and applications" (basically,
"incompetence"...) or is it because they have been persuaded by a salesman
that what they have is obsolete, or it won't run the latest and greatest
apps that are about to be released, or support is likely to be dropped, or
any one of dozens of "other" reasons why?

My point is that the reason you cite is NOT the ONLY possible reason...


ANYONE can have access to COBOL on the PC and there are some
excellent implementations available. I have been using Micro Focus
and Fujitsu COBOL for over 20 years on PCs. They are both excellent
products.

I said they're not commonly found on the PC and they are not.

COBOL IS commonly found on the PCs of people who are interested in COBOL.


Just
because you bought them doesn't mean everyone can buy them,
especially when most PC users consider 49 or 99 dollars an upper
limit for any PC app.

Both MicroFocus and Fujitsu have provided free student editions of their
products for decades. Since Fujitsu North America changed hands it has been
harder to find a free version of Fujitsu COBOL but they are available.
Veryant have promised a free student version of their isCOBOL product (which
is Java oriented, incidentally...) in the near future, right in this very
forum, within the last week, and OPEN COBOL has been free and available for
some years now.

Now, if you are considering developing revenue earning applications, you
will need to pay run time fees to Micro Focus if you use their product, you
will need to buy a FULL version of Fujitsu if you choose to use their
product (no run time fees or royalties), and OPEN COBOL is free.

I would remind you at this point that VB.NET, C#, C++, and Java are all
FREE.



PC Assembly is no more an abomination than BAL is. They are just
different, that's all. If you consider the unfamiliar to be an
"abomination" then that says more about your mind set than it does
about the language in question.

It is an abomination, and you would know that if you had looked at
it.

That is simply rude. I have not only looked at it, I have programmed in it
for some 18 months when PCs first appeared. I've written TSRs in it and
interfaced it to MicroFocus COBOL. You may be used to people making
statements for which they have no experiential foundation; do not categorize
me as such. I know whereof I speak.


First of all there is no one PC assembly language, that in itself
is a big problem.

That is no problem at all. If you want to write Motorola 68000 code, learn
that. If you want to write Intel x86 code, learn that. If you want to write
IBM mainframe Assembler code, learn BAL then progress to macro assembler.
Those are the "joys" of low-level programming. If you want one language that
will run on ALL these platforms, use COBOL (oops, you don't want to pay for
it... OK, learn Java). How hard is that?

If you are referring to the syntax differences between AT&T x86 and Intel
x86 serves you right for trying to move to Linux :-) Actually, that's not a
problem either: code in MASM then run it through GAS, or code in GAS and
select the platform you want.

All it takes is a little imagination and thinking outside the box.




You shouldn't have to learn 2 completely opposite
syntaxes to use assembler on one platform and to be able to move code
from system to system. You do have to do that on the PC.

No you don't. See above.


Making programming into a religion may not be a good path to follow.
It is just computer programming. If you feel so strongly that any
breach of your commandments for good programming is offensive or an
abomination, then you are likely to miss out on much that is good
and useful. However, it is of course, a personal choice.

That's nonsense. The point is you have to have some view of good and
bad or you're lost.

Some things work better than others, true. Some people see more than others,
also true. Just because computers see black and white doesn't mean that
programmers have to. There are many shades of grey surrounding most
problems.Digging for facts is better exercise than jumping to conclusions,
or deciding "that's how I've always done it". Treat problems as new and
worthy of respect. Seek to develop and extend your toolbox and your mind,
rather than deciding there is only one right way. As your tools expand, so
will your mind. If you just have one viewpoint and measure everything aginst
that, you will not get optimum solutions. To a man with a hammer, everything
is a nail. There is no "good" or "bad"; there are solutions that work and
solutions that don't. Sometimes there are solutions that work better. These
are usually found by iteration of a solution, not instantly recognized on
day one (unless the problem is truly a trivial one...)


Not everything is acceptable, and the more you
know and the more pride you take in your work, the more you have
opinions based on experience about what good and bad mean and how
they affect life in the long run.

Only if your mind is closed. It is good to take pride in your work and we
all strive to get the best result we can. But if you don't re-evaluate why
you hold a certain approach to be "good", and measure it in the light of new
tools and experience, there can be no growth. This might not matter to you,
and some people are quite content to hit every problem with a hammer and go
home at 5 o'clock. Not me. My career has been a personal and professional
growth path which has been fun and satisfying. I'm a better person now than
I was, and I'm a better programmer now than I was. Good result :-).


I can't imagine why. Do you also want your bicycle to be as much
like a car as it can? :-)

The difference is I can afford both a bicycle and a car for their
different uses but most people cannot afford a mainframe. Given
mainframe people know mainframes are better, everyone should want one.

:-)


they can do things that mainframes never could. Notice that the
arrival of the internet didn't happen in the decades when mainframes
ruled the world.

Not so, I used internet from a mainframe before most people knew
there was an internet. And we could argue it was better in those days
;)

I suggest that what you used was not "the Internet" (World Wide Web, as
currently understood, although we know there are many more sub-nets than
just that one...). But it really doesn't matter... If you used connected
mainframes over any kind of network you should be broader minded about
connection and synergy than you appear to be. Maybe you were enjoying the
technical achievment so much you missed the conceptual significance.

In 1973 I was involved in setting up the first satellite link between a
mainframe in Melbourne (Australia) and a batch terminal in Wellington (New
Zealand), a distance of about 2500 KM as the crow flies, but much further
when you consider the distance the signal has to travel up and down to the
satellite. I couldn't get it to work and ended up going to Melbourne to
inspect the front-end software on the Cyber. It was a real technical
challenge as other terminals around Australia were working fine. After
poring through the code for a couple of days I realised the problem and set
some delay loops to make it hold our connection. Flew back to Wellington and
we tried it. The terminal screen just filled with garbage and then suddenly,
it cleared and the first 3 words appeared neatly at the top of the screen:
"Haeremai! Haeremai! Haeremai!" (thrice welcome, in Maori...the Melbourne
operator was a Kiwi). I was so thrilled at having solved the technical
problem it never occurred to me what this actually meant in terms of
business and access for problem solution...or in terms of the cash flow it
would generate and the jobs it would secure. Sometimes we get so focussed on
one aspect of a problem we can miss the other aspects.

And yet the world stabbed itself in the eyes with a pen for 50
years, and in some quarters is still doing it. Those of us who made
a living from COBOL did not notice any soreness of the eyes. On the
contrary, we actually loved it. (I still enjoy working in COBOL
although I find it more tedious now than I used to before I knew
there were better alternatives available.)

You seem to be arguing against yourself.

No, I still enjoy COBOL, I just have a more realistic context for it. My
eyes don't hurt.

I would strongly contest your statement that COBOL is "too limited
for general purpose programming", having written applications that
range from heuristic maze traversal, through syntax scanning and
parsing of language
and free format postal addresses, to interactive Web Pages with it,
but maybe your concept of "limited" and mine are two different ones.

You can code almost anything in any language (and you certainly seem
to have done so!) but that doesn't prove that language is a good
choice. Being a good coder is having access to the right tools and
knowing which ones to use and which not to use. COBOL is certainly
not suited to much beyond reports and financial systems (where it
does shine).

I would argue that reporting is not a strength of COBOL. I haven't used it
for reporting much since Relational databases became available in 1983. Once
the data repository is relational there are far better tools to extract
reports from it than COBOL. Crystal Reports and Stimulsoft are just 2 I have
used and been very satisfied with. I see no point in counting printline
fillers when I can drag and drop what I want, where I want...:-)

Using the correct languages for all these projects would
have made the code much smaller, more readable, and more maintainable.

You have become so accustomed to viewing a PC as a Mainframe that you
have lost sight of what they CAN accomplish.

I don't think so, I find PC's very limited and not interesting.

I rest my case. :-) (You see them just like mainframes...)

OK, I'm sure your post was light hearted (as my response has been)
but the bottom line is that Java is a perfectly good language...
and so are ADA, COBOL, and, in fact, MOST computer programming
languages.

I don't agree (with the last part!) There are many awful languages,
if I was to list a few I would include Java, C++, Pascal, and most if
not all interpreted languages. There are very few great languages,
especially if you're talking about great general purpose languages.
There are many great specialty languages but their usage is obviously
limited. What makes a language great? Expressiveness, clarity,
quality of the executable produced, things like that. What makes a
language awful? Complexity, inefficiency, complicated syntax for it's
own sake, ugliness, etc.

OK, at least you gave examples to support your statement. I won't argue
this, because I think not much would be achieved by doing so (and I really
don't care :-); I long ago gave up worrying about what constitutes a "good"
or "bad" language...) With the advent of functional languages and
non-procedural code it is pretty much academic anyway. Nevertheless, if you
search the adjectives you used above I think you will find that many of them
are subjective and arguable. (What you call "ugliness" I might consider
"elegance", what you call "complexity" may be "crystal clear" to me...etc.)

I totally respect your right to disagree. All I ask is that you consider the
arguments, rather than decide that what you currently do is "right". It
might well be, but it doesn't hurt to re-measure occasionally, does it? :-)


Yes, there is an aspect of art in
programming languages.

I would argue there is an aspect of "art" in programming. Attributing this
to the languages is very much admiring the paintbrush instead of the artist.

<small snip>

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: Original Macbook OS died. now no space on HD but also no way to rebuild?
    ... It is very easy to learn to write a program using .net or java. ... learning any language takes longer than a paragraph. ... programming environment is much easier to learn compared to modern ... could compile Java at all. ...
    (uk.comp.sys.mac)
  • Re: Wang COBOL alive and well as Wang VS makes a comeback
    ... I fought to the last to keep COBOL at least peripherally in the ... will be the next language du jour... ... This contributes to the stability of programming efforts ... level of COBOL to another can be as big a deal as migrating across platforms ...
    (comp.lang.cobol)
  • Re: Structured Coding
    ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
    (comp.lang.cobol)
  • Re: Static vs Dynamic
    ... (Java has too much noise in its source code, ... lot to ask and is typical in a typed language supporting polymorphism. ... > developers can easily learn the Java programming language; ... > obivous bugs slip through and b) in many cases, ...
    (comp.lang.lisp)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)