[Theodour]

I'll be taking a Cobol class sometime in the near future (required), and wonder if there are any Cobol tools available for the Mac.

Anyone?

Thanks in advance.

[holygoat]

http://www.thekompany.com/products/kobol/
(coming soon)

http://www.oevelen.com/eng/cobol/lang/
(possibly applicable)

http://www.freeprogrammingresources.com/cobol.html

[Brass]

Originally posted by Theodour:
I'll be taking a Cobol class sometime in the near future (required)

My sincere condolences. COBOL is painful. It's not difficult, just so antiquated. It's a shame that all the old COBOL still in use has not yet been replaced, and the language allowed to die forever.

[Theodour]

Thanks for your input.

Looks pretty bleak, unless The Kompany finishes their version ... but then, my school has an "affininty" towards Wintel, and I might be required use some Windows based solution.

As for its age ... Yeah, I remember when Jr. High School (early 80s) had a room full of DEC models ... and I think the only language you could take was COBOL.

But that was already the future. A friend of mine from the same school, who graduated about 10 years ahead of me, tells me his adventures in punch card programming. Wow.

[Arkham_c]

Originally posted by Theodour:
I'll be taking a Cobol class sometime in the near future (required), and wonder if there are any Cobol tools available for the Mac.

A school is actually still teaching COBOL? That's insane. When I was in college (10 years ago, whew!) I had to learn Pascal and considered that to be ancient. I can't imagine any modern use for a COBOL programmer other than to maintain 30-year-old code, and who on earth would want to do that?

Even the days of C are numbered IMHO. For performance-critical applications, people are moving to C++ and Objective-C, and for everything else, to Java, Perl, and Python. Why on earth would anyone want to teach COBOL when so many superior choices are available?

[holygoat]

Originally posted by Arkham_c:
A school is actually still teaching COBOL? That's insane. When I was in college (10 years ago, whew!) I had to learn Pascal and considered that to be ancient. I can't imagine any modern use for a COBOL programmer other than to maintain 30-year-old code, and who on earth would want to do that?

Even the days of C are numbered IMHO. For performance-critical applications, people are moving to C++ and Objective-C, and for everything else, to Java, Perl, and Python. Why on earth would anyone want to teach COBOL when so many superior choices are available?

There's nothing wrong with Pascal! For structured programming it's a very good language. It's also modern in the form of Delphi (Object Pascal).

Unfortunately, COBOL programmers are in heavy demand - an enormous percentage of business systems currently in-use and being maintained are in COBOL, and there aren't enough skilled programmers to go round! Maintenance is the biggest part of software engineering.

The days of C (and C++ to a lesser extent) will never be numbered: C layers appropriate abstractions on machine code, occupies a large portion of most operating systems, and is typically the first compiler for a platform (because it is simple). What do you think Python's interpreter is written in?
C has its place.

For user-level applications, however, languages such as Python, Ruby, Java (sort of), and Lisp are better choices. Languages always change.

[Person Man]

Originally posted by Arkham_c:
Even the days of C are numbered IMHO. For performance-critical applications, people are moving to C++ and Objective-C, and for everything else, to Java, Perl, and Python. Why on earth would anyone want to teach COBOL when so many superior choices are available?

Maybe plain-old C, but you still have to learn C before you can learn C++ and/or objective-C.

I have yet to find a book on either language that doesn't already assume you know C.

[Richard Edgar]

C layers appropriate abstractions on machine code

.... on a PDP-11. I don't think that you'll find vector processing operations (such as those provided by AltiVec) as part of C, since C doesn't even really know what an array is.

[holygoat]

Of course C (surely you mean C compilers?) knows what an array is - it's a contiguous region of memory, as it is either explicitly or in the implementation details of most other languages.

All C provides is a set of useful abstractions over machine code - the concepts of functions, manipulating addresses, arithmetic, arrays, etc., basic type support, and common programming features on a low level (I/O, time and date functions, etc.).

I think you're making a mistake in expecting every language to account for the architecture on which it can run. There are a few approaches to something like AltiVec:
- optimising compilers (good approach - AltiVec can often be applied in places where a human wouldn't do it themselves)
- pragma instructions
- specialised function calls or macros
- inline assembler.

I'd regard it as wrong to build this kind of extension into the language - it's not only inapplicable to other architectures (and after all, the whole idea of standardisation is to aid in portability between machines and compilers) but it's also ignoring future changes.

Far better to make appropriate abstractions in the design of a language - and GCC will generate AltiVec-enabled code from standard C source, as ICC makes good P4 code. The concept of an array is generic; the concept of a VPU is not. Pick your abstraction so they can be reliably layered.

C's strength is that it made the right abstractions for building system-level applications, because that's what it was used for while being designed.
Those requirements haven't really changed, so it's still around. I point to VxWorks and other embedded systems for a thriving C environment.

You seem to expect that all languages in use today should make the kind of abstractions that you personally want. The notion of a complex number, or a preferences file, or a window, or even a string, are not suitable levels of abstraction when you're writing an OS. And for application development, there are other languages. Which was exactly my point:

For user-level applications, however, languages such as Python, Ruby, Java (sort of), and Lisp are better choices. Languages always change.

[Richard Edgar]

Of course C (surely you mean C compilers?) knows what an array is - it's a contiguous region of memory

That is precisely the answer I was expecting - from a C programmer. An array has more than that. It has dimensions and datatypes - it should be impossible to pass a 2D array to a routine expecting a 1D array. And since when did arrays have to be stored on contiguous memory? I can pass an array slice, which may or may not form a contiguous section of the parent array. Do you really want to have to do a copyin/copyout for that? If I have an array of a user defined datatype, I want to be able to pass the equivalent array of a single component of that datatype - without a copyin/copyout, or having to do pointer arithmetic myself (particularly since the routine being called need not know that it is actually getting a slice like that). C has pointers to blocks of memory. That is all.

Far better to make appropriate abstractions in the design of a language - and GCC will generate AltiVec-enabled code from standard C source, as ICC makes good P4 code

As a matter of interest.... how good is it really? My experience with automatic parallelisation (of which vectorisation is a special case) is that just flicking a compiler option doesn't always work so well.

[holygoat]

Originally posted by Richard Edgar:
That is precisely the answer I was expecting - from a C programmer. An array has more than that. It has dimensions and datatypes - it should be impossible to pass a 2D array to a routine expecting a 1D array.

No, the ADT for the 'array' concept has those properties.
It is possible to enforce those constraints (e.g. through structs), but that's not the level of abstraction that C is working at. It will always allow you to work below the compiler if you want to.

And since when did arrays have to be stored on contiguous memory? I can pass an array slice, which may or may not form a contiguous section of the parent array. Do you really want to have to do a copyin/copyout for that?

That's the level of abstraction at which C works. Higher-level languages work at a higher level of abstraction, in which concepts such as array slices, mapping, etc. are introduced and the physical storage method is hidden.
If you wish, you can implement this yourself in C.

C has pointers to blocks of memory. That is all.

Which is pretty handy for a systems language! My point is that C is still around because it provides a small, useful set of abstractions on a basic machine, making systems-level programming easier.
Other languages can be built on top of this framework for applications, and this is the way the world works.
It wouldn't be wise to implement a GUI application in C these days, though it's possible - you'd find yourself implementing all the abstractions of a HLL yourself.
It would also be foolish to attempt to program an OS in Python (assuming you could get a bootable interpreter). Different tasks.

As a matter of interest.... how good is it really? My experience with automatic parallelisation (of which vectorisation is a special case) is that just flicking a compiler option doesn't always work so well.

From what I've read, it's not bad at all. The automatic processes for SSE produce noticeable improvements, and I recall reading about Apple's approach. Of course, the manufacturer's compilers (e.g. ICC) are better than the cheaper ones, though there are also at least two companies with automatically-vectorising Fortran, C, and C++ compilers for AltiVec.
I ran across an Apple tutorial for doing it manually a long while ago.
My point still stands, however, that there is no reason for a standardised language to have inbuilt support for a certain architecture's capabilities- that should be the role of the compiler.
Would you like to see ANSI C++ have special MMX keywords?

[Richard Edgar]

Higher-level languages work at a higher level of abstraction, in which concepts such as array slices, mapping, etc. are introduced and the physical storage method is hidden.
If you wish, you can implement this yourself in C

I can also bang my head repeatedly against a brick wall.

Would you like to see ANSI C++ have special MMX keywords?

What I would want would be constructs that free the compiler to optimise as necessary, by guaranteeing that certain things are side-effect free. C provides no mechanism for doing that.

The point is that C providing a 'useful set of minimal operations' is a rather strong disincentive to providing more sophisticated operations on the silicon. Which is the cause, and which is the effect?

[holygoat]

Originally posted by Richard Edgar:
I can also bang my head repeatedly against a brick wall.

Or use the right tool for the job. To bring this back on topic, COBOL is bad because it has no advantages over any other language - it has been entirely superceded.
C is not in this category - it fulfills its role (a small, portable, compiled systems language) very well.
More abstractions and features mean reduced performance, larger footprint, and more complex compilers - none of which are desired at a low level.

What I would want would be constructs that free the compiler to optimise as necessary, by guaranteeing that certain things are side-effect free. C provides no mechanism for doing that.

Language design is a difficult topic. It may or may not be the case that a simple, imperative language such as C can have those constructs while retaining its advantages.
If you want pure functions, go for OCaml or Haskell. But C is right for a certain set of tasks, which is why it is still around.

The point is that C providing a 'useful set of minimal operations' is a rather strong disincentive to providing more sophisticated operations on the silicon. Which is the cause, and which is the effect?

The advantages of RISC have been proven. Every additional bit of hardware adds overhead, cost, and a point of failure.
In the case of, say, pipelining or vector processing, the speedup is sufficient to outweigh the overhead, so they're included.

I don't know what kind of "sophisticated operations" you might be suggesting, but I don't think language support is a retarding factor. Where they offer a sufficient advantage, improvements are included in the hardware - and the compilers and libraries modified to match (as is the case with SSE, pipelining, FPUs, etc.).
It's not necessary to expand the language itself to support most changes; indeed, there are clear advantages to divorcing the language from the specific hardware. This is C's approach: provide a complete language that still allows you to push bytes around. It's a systems language, not a HLL.

[iJed]

Originally posted by Richard Edgar:
I can also bang my head repeatedly against a brick wall.

This is often what you find when trying to write some reasonably low level code in something like Java which would be trivial in C.

I remember a friend of mine was having a terrible time writing low level UDP code in Java because he didn't have unsigned types available. He ended up needing to write a class (which is yet another layer of abstraction) that did all sorts of bit shifting for this purpose alone.

[Arkham_c]

Originally posted by holygoat:
To bring this back on topic, COBOL is bad because it has no advantages over any other language - it has been entirely superceded.

I think this is the real crux of the argument. Fortran is still used because it has some performance advantages.

Pascal is still used because it's not a bad compiled teaching language.

C survives because other languages are still hamstrung by bootstrapping issues that don't exist on C (since other languages are generally compiled in C rather then in their native tongue).

COBOL has no advantage, other than the fact that old mainframes still run ancient code. For that reason it's not something of value to learn or practice.