Helpful Information
 
 
Category: Other Programming Languages
Cobol v. Pascal

I'm a Computer Science major and have to take a course in either COBOL or Pascal, neither have every really interested me, so I was wondering which one was better(not necessarily easier or more fun) to learn for a Computer Science degree? Any comments or advice would be much appreciated. Thanks.

I'm a Computer Science major and have to take a course in either COBOL or Pascal, neither have every really interested me, so I was wondering which one was better(not necessarily easier or more fun) to learn for a Computer Science degree? Any comments or advice would be much appreciated. Thanks.Depends on what you plan on doing after you graduate. Do you plan on continuing in science, or hitting the corporate IT business? Don't let anyone lie to you, there are many big corporate giants and smaller shops as well, still using COBOL for many things, and not many around who know how to wrangle it. If Big Business is not in your future, go for Pascal. Personally, I'd go for FORTRAN.

Personally, I'd go for FORTRAN.
There's always LISP as well...

There's always LISP as well...
LISP is no good, I have to take either COBOL or Pascal, it's a prerequisite for all the C classes.

If the prequisite is for a C class, then I would take Pascal, as it is much closer to C than COBOL is. While I normally would argue to take the more divergent languages, so as to get the greatest breadth of experience, for most programmers exposure to COBOL is like exposure to radiation...

well I already know C(I just got to take the course because it's part of the curriculum & I can test out of it), so I'm not so much worried about taking a language to prepare me for C, as I am taking a language that there is a good market for, or will help improve my programming skills as a whole.

Pascal is a better suit to traditional procedural and OO languages. COBOL is programming in English, very simple and straightforward, perhaps too simple

MULTIPLY WS-INPUT-AMOUNT BY VAT-RATE GIVING VAT-AMOUNT.

I would consider that (at least from what I see) Pascal has no practical usage in the industry and COBOL is only a phase out target.

I would respectfully disagree, having been a corporate programmer in both languages.
COBOL has it's place, and for a time to come, due to investments made by large corporations. Code is not simply updated because a new language comes into vogue, COBOL has seen off a fair few new contenders to the throne.

Pascal is itself a learning language, and some of it's derivatives, still power commercial applications today, one of which I worked on was a forex quoting platform for a number of large financial institutions, though in most of those it has been superceded by newer faster platforms, but rarely driven by the banks request, rather by newer tech-savvy zealots in the banks, we looked to sign up as customers. Pascal was faster than the Java apps that replaced it. For the most part the language is immaterial, the resultant image or executable is what's important, and then comes the cost of support.

Modula II was a derivative of Pascal IIRC, also Turbo Pascal/Delphi still power a number of applications on the Win32 desktops today.

It's a case of what you know, versus what you need to know, I would agree neither are 'need to know' but if I had to choose one, i'd swing for Pascal

I'm a Computer Science major and have to take a course in either COBOL or Pascal, neither have every really interested me, so I was wondering which one was better(not necessarily easier or more fun) to learn for a Computer Science degree? Any comments or advice would be much appreciated. Thanks.

I myself made this decision just a short time ago. I picked up COBOL because I work for one of the largest credit card companies in the world. We use COBOL for all of our transaction and backend processing. We have billions of lines of code in our system and it would be a VERY LARGE time/money investment to update our code. Yes COBOL is extremely easy but when you need a language that can process hundreds of financial transactions a second and is extremely dependable and bug free. COBOL is the head honcho in this area. Alot of big businesses still use COBOL, I wouldn't set the idea aside so easily.

...For the most part the language is immaterial, the resultant image or executable is what's important, and then comes the cost of support...

Hey Ax,

Maybe I'm misunderstanding but I think language is very important. More than just the executable it has so much influence on how you think about a task, and how you solve it. All languages we're not created equal ;).

Personally I'd go for COBOL because it's the least ordinary. That’s good experience :).

Mark.

From a point of view of the owners of the code the most important issue would be cost and cost of maintenance, there's a reason colleges still teach COBOL ... I should have prefaced that :o

my bad

I give COBOL a few years left yet ;)

I personally never got on with pascal, for simple things. The BEGIN/END, the fact they use `:=` for assignment, and the fact it doesn't have functions built in for most things you want to do. COBOL is interesting, it's one of few languages that enforce a program structure, and it's not all that hard to start learning (hey, look at Ax's code snippet). Of the two, I'd take COBOL. But then again i'd be learning other things outside of class too. I recommend three languages:

-Ruby
-Common Lisp (Mark and Schol-R will say Scheme, but it's all the same idea)
-Python

Python less, but there's a lot of code out there using it already, and it would be a nice addition to your studies. CL will mess with your head, but once you've got it, you'll be able to solve problems much easier. Ruby is just a pleasure to use, and has some way of doing everything you can imagine. One thing I should note here is that these are all interpreted languages. It's important to remember that compatibility and flexibility are infinitely more important than speed in all but the biggest apps (hey, most utilities finish before I can boil a cup of tea, suits me).

Before you get to that 'simplicity' you'd have to master the Working Storage Section, Environment Section, Procedural and I/O IIRC.

The actual code is easy to read, but setting it up has a few nuances, now that I think about it :rolleyes:, been a while for both.

We used a Pascal program over 33K lines to create a language database, Cobol read a spreadsheet, and achieved the same result in about an eighth of the time, though I had discovered FDL/CONV on VMS at that stage.

FDL/CONV, the ultimate file utility ... schweet

It's important to remember that compatibility and flexibility are infinitely more important than speed in all but the biggest apps...

Lisp is a compiled language with some interpreters available. You can get some very good performance from Lisp (generally a little slower than C/C++) and the power available to you to describe your code is second to none :).

I like Scheme because it's very clean and light. It does lack a lot of features out of the box, but IMO this just leaves you with a better understanding of your system.

Night night,

Mark.

Lisp is a compiled language with some interpreters available. You can get some very good performance from Lisp (generally a little slower than C/C++) and the power available to you to describe your code is second to none :).

I like Scheme because it's very clean and light. It does lack a lot of features out of the box, but IMO this just leaves you with a better understanding of your system.

Night night,

Mark. Lisp is primarily used interpreted these days, because it allows the greater flexibility. That said, once you've used compile-file to turn it into bytecode, there's no stopping you ;)

Scheme would be nice, but end of the day, you just spend time putting together your own basic functions, waste of time IMO

waste of time

Sure about that?


By reinventing the wheel:

1) You get to fully understand how it works.
2) You appreciate the fact that it's been invented before by someone far more competent than you.
3) You appreciate that person for inventing the wheel first for you to reinvent.
4) Since you already understand it's inner workings, you can easily fix wheel-related problems and adapt the wheel for your own specialized usage in the future.

;)

"Learn from th emistakes of others, because you'll never grow old enough to make them all yourself"

Depends on how much time you have on your hands ...

Lisp is primarily used interpreted these days, because it allows the greater flexibility. That said, once you've used compile-file to turn it into bytecode, there's no stopping you ;)

Scheme would be nice, but end of the day, you just spend time putting together your own basic functions, waste of time IMO

A compiled Lisp program is just as flexible as the equivalent interpreted Lisp program. This has to do with the runtime library not the whether it's compiled or interpreted.

Programs written in Lisp are usually compiled; so Lisp is a compiled language. Besides that most Lisp interpreters are written in Lisp. Now that would give you some problems if Lisp weren’t a compiled language :cool:.

The REPL is mostly used for interactive development with an incremental compiler — this is a common way to write programs. In this role the interactive interpreter is just a tool or front-end.

That said all Lisp implantations I know of come with a REPL so it’s understandable to think that Lisp is interpreted because of this; some do come without an explicit compiler. A compiler is included with most and there are a lot of implementations that are unmistakably compiler based. You wouldn't use the interpreter that comes with these to run your program because the compiled program will execute much faster.

These implementations tend to target the machine, or virtual machines like .NET, JVM etc.

Obviously I can’t expect all of this to apply to every implementation but it works as a general rule.

Note: I would recommend Lisp In Small Pieces to anyone interested in the implementation of Lisp. I’m currently working though this and some other books.


I don't think anything you can do to increase your understanding is a waste of time. It's my opinion that you can't truly understand something until you've implemented it. Scheme helps out by not getting in your way. By being much cleaner you produce cleaner programs, in both look and feel.

CL is just too cluttered for my liking. Being an amalgamation of the Lisps that came before it there’s a definite patchwork. Being a Lisp-2 also complicates things unnecessarily IMO.

Doing things yourself has another advantage:

A custom solution may perform much better than a solution made from a number of general purpose functions. That should be apparent.

Besides, it's fun to sit around and code :).

Enjoy,

Mark.

Yes, it can be fun to sit around and code, but I tend to follow the django philosophy

`perfectionists with deadlines`.

I'll assume you're doing some lisp work at uni. So you get a huge project with a week to do it in, do you spend that time writing thousands of functions, or do you use the CL library which is already there? I'm a fan of RAD, when done properly, and while CL leaves a lot to be desired, it's always POSSIBLE to write your own implementations of things, and so you get the best of both worlds.

It'd be nice to get a well planned lisp going, with a decent backing library that would be better.










privacy (GDPR)