Hobby languages
in [Cobol]
|
From: Pete Dashwood on 25 Jul 2010 01:24 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."
From: Jessica Colman on 25 Jul 2010 03:50 > > As for getting a room with Jessica: if we were working on a Java project I'd > be happy to do that, and share it with the rest of the team as well... :-) Let me know if you come to Munich :-)) Jessica
From: Richard on 25 Jul 2010 04:02 On Jul 25, 10:01 am, Nomen Nescio <nob...(a)dizum.com> wrote: > No it is not. It is an excellent way to pick up Java's view of OO, which is > not the same thing. There are several 'views' of OO, none of them are _THE_ view. Such things as multiple inheritance, operator overloading, factory, are all issues that can be argued for or against. > 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. I don't > consider anything that enables idiots to write code that more or less > provides the desired output as helpful or worthwhile. Exaggeration merely highlights your high opinionated ignorance. > I don't agree with your view, and it's clear that people who share it are > wrong. Just yell 'I am right and the rest of the world is wrong' over and over and we will see if that convinces anyone. > 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, Complete uninformed nonsense. > because the > costs of doing business based on incompetent CTO's making incorrect > technical decisions has made IT a huge cost. 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. You are confused. > I said they're not commonly found on the PC and they are not. 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. You are uninformed. The largest number for an application is MS Office and that is much more than 49 or 99 dollars so most users do not find those numbers an upper limit. > It is an abomination, and you would know that if you had looked at > it. First of all there is no one PC assembly language, that in itself is a > big problem. 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. Clue number 1: there is no one assembly language on mainframes. It may be that there is one main IBM OS/MVS assembly (or whatever it is these days) but those are not the only mainframes. Every architecture has, of necessity, at least one assembler. Some have several. This means that there are hundreds of assemblers. Or are you so limited that you can't think beyond IBM Z Series and Intel P4 ? > 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. Are mainframes better at being laptops ? Are mainframes better at being in-car systems ? Are mainframes better at being smart phones ? Do you drive a Mack Truck because it is better than a car ? > I don't think so, I find PC's very limited and not interesting. I learned very early in life that the more one knew about something the more interesting it was. The corollary is that the reason people find something uninteresting is because they know nothing about it. The 'limitation' is yours and the 'uninteresting' is due to your complete lack of knowledge. > 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. Yes, > there is an aspect of art in programming languages. They are tools but so > is a 2 dollar Chinese pot-metal chisel and so is a 300 dollar hand-forged > and machined chisel and I know the difference. There are many ways to judge languages. You have been indoctrinated with the need for 'efficiency' of the executable. I Have clients where a commodity single core PC under Linux runs all their users (50-60) with response times that are unnoticeable and the constraint on performance is _NOT_ the CPU. Having a compiler that produced 'better' code would make zero difference. Certainly if I was working in systems dealing with millions of transactions an hour or a minute then I would care, but I don't. Just as there are people that care about race car engines and extracting the last ounce of horse power there are others that only care that their car works everytime they turn the key. I do a lot of coding in 'scripting languages', or specifically Python. In most cases, with the systems I work on, the CPU load is _not_ the limit. Having the code in assembly would make almost no difference to the time taken. Horses for courses. You may learn that if you ever got off your high horse and learned something new.
From: Non scrivetemi on 25 Jul 2010 10:16 James Gavan <jgavan(a)shaw.ca> wrote: > bytes), I fail to see how any language can dovetail neatly to do > automatic garbage collection for you, and always get it right. (How can > an independent 'third party', the OO runtime, anticipate 100% accurately > WHEN I the designer want something destroyed ?). I don't know Ada etc., > but are there constraints put upon you in class/method design so that it > recognises when to destroy certain objects ? I'm not the right person to answer your question on Ada but I know it does allow you to control finalization either directly or indirectly. For a good answer please ask on comp.lang.ada, several Ada designers and compiler writers are there and can answer all your questions.
From: Pete Dashwood on 25 Jul 2010 10:35
Jessica Colman wrote: >> As for getting a room with Jessica: if we were working on a Java >> project I'd be happy to do that, and share it with the rest of the >> team as well... :-) > > Let me know if you come to Munich :-)) > > Jessica Thank you, Jessica. :-) I lived in Dueselldorf for around 4 years and, of course, visited Muenchen and Bayern. I still have a few friends in Germany but it is unlikely I'll spend time working there again. These days I am enjoying being home and the Pacific lifestyle. Although the Rhine was very beautiful, I enjoy surf beaches more... :-) Tchuess! Pete. -- "I used to write COBOL...now I can do anything." |