Page 2 - Cobol v. Pascal

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

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.

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

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 .

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.

Sounds good in theory but it doesn't work that way in my experience. You might have to write a function to begin with but once you have you can use it anywhere it's useful.

I wrote filter and reduce when I first started using Scheme and I use them all the time. If at some point I rewrite these functions (presumably to improve them) then the programs that use them instantly benefit (this is one of the benefits abstraction has that isn't quoted as much as it should be).

Having the code on hand also makes it easy to change the pattern to fit other applications; CL can't claim this because you don't have the functions source available as easily. You can search on Google etc. but of course you still have to understand this code inside and out before you can use it to its full potential.

Yes CL has all the functions you might like to use in everyday Lisp programs and many more. But how many of these functions are actually use regularly? I’d guess less than a 1/3.

There are functions that are used over and over (print, reduce, remove-if, remove-if-not etc.) but to be fair most aren't (time, eval, write-line) .


Python isn’t so good for RAD because of there are a large number of libraries. Unless of course you think C is suitable for RAD for the same reasons. RAD is more a reflection of the system as a whole, most importantly the expressiveness of the language. Scheme is a cleaner language and this translates into less problems – it follows more closely the principle of least surprise.

Scheme includes some things that CL doesn’t i.e. first class continuations. Then again Scheme doesn’t have a separate namespace for functions, which is a good thing IMO. CL doesn’t include tail-call optimization as part of the standard .

This IMO makes Scheme just as suitable for RAD as CL, but for different reasons .

Take care,

Mark.

Hi, I am just starting to use COBOL. I am asked to do the "LEAP YEAR" program. It will be helpful for me, if anyone can give me the source code for this,

Thanks in advance.

No, we cannot just give you the source code. You try to develop the program and come back with a specific problem you have issue with. We do not do the work for you.

All you need to know is the formula for working out a leap year and the most basic cobol instructions...

ok, fine. i will try to do it..

You can't say you honestly expected us to write the program for you? We're mostly professionals with our own commitments, and we don't waste our time helping people to get through their courses without any of their own effort. If you want the accolade, you have to work for it, or it defeats the purpose.

I can't believe any school is still forcing you to learn either of these!

COBOL is certainly not dead, but it's not worth teaching anybody any more. Pascal is probably the most utterly worthless, me-too, agenda-based "language" ever designed, and has no commercial value. If it weren't for Delphi propping it up, Pascal would have died the horrible twisting death it deserves.

Given the choice between these two evils (which from the date of your post you've probably already made) choose COBOL.

Why does pascal suck?

Syntax. I have big bones with pascal syntax, begin/end, the fact the assignment operator is := etc.

Lack of built in functions. Some things you need to do can't be done without extensions to the language. Other languages have better ways around this than pascal.

General distaste for the way it does things.

It's still good for explaining to person absolutely new to computer programming how things may/can work. It is an easy to use language. It was designed for teaching purposes, why should it need to be extensible? It doesn't. Many of the concepts of Pascal also apply to C, the two have been compared and viewed as quite similar in a variety of ways.

What is wrong with := as an assignment operator? Io uses :=, do you happen to hate Io as well because of something so minor?

First, I agree with you that := isn't the least bit problematic. This ALGOL-based choice is considerably preferable to the silly (spiteful) C syntax which created more problems than it solved. It's hard to justify since the algebraic languages which predated it which didn't differentiate between assignment and equality (FORTRAN, COBOL, PL/I) didn't create problems for programmers, and since := was understood as a grammatical (syntax) expression it was actually quite clear.

But to Pascal.....

It's not a good teaching language, and it doesn't explain to anyone new to programming the basics of how things can work. BASIC and now Python, are far better choices.

Pascal, like its bastard offspring Java, is an indoctrination kit. It was language based on agenda, an agenda that structured programming as understood by Niklaus Wirth(less) had some kind of inherent merit.

If Pascal would have been designed first, then some of what you said would be reasonable. Given that C was firmly established (and that Algol and PL/I were firmly established before C) Pascal is entirely needless except as a policy tool.

Wirth and his damnable Pascal, and later Java (with an even more nefarious agenda), have done more to damage programmers and the art and science of professional programming than any other things I have seen in over thirty years. Structured programming is a nice theory, but 95% of commercial and industrial programming is not algorithmic and is not best coded in a structured fashion. Not everything in the world is best modeled with a big loop containing a series of smaller loops, and even though you can certainly code that way, it's not efficient. If it doesn't bother you to litter your instruction path with thousands or millions of spurious instructions, then by all means, continue. If you know what the machine is doing, this kind of bloat isn't acceptable.

Java dumbed the world down further, first with the big lie that it's a language (sadly, its proponents can't distinguish between a language and an application deployment platform) which tries to minimize its immense bloat, and then with the unsupportable notion that OO is the silver-bullet solution to the world's problems. The plain truth is that Java is nothing more than an overgrown scripting framework that can't support its own weight. It's not suitable for anything but GUI (and even that's questionable) but I suppose that's fine since everything today seems to be about user interface and nobody writes software that actually does anything anymore.

Java makes the "programmer" dependent on it. Part and parcel of learning Java is an ostrich-like avoidance of understanding the basic principles of programming; Java keeps you away from the hardware, it keeps you from having to understanding fundamental concepts of how real software works, and why. It builds a sick co-dependence between coder and platform, and the sad thing is that they can't line up enough fast enough to kowtow to it. When these people have to learn to actually program, it's very difficult to get them to give up the false security blanket they've carried all that time- that Java takes care of everything. Yes, resource management, recovery, serialization, performance- these are all issues real programmers have to deal with. If you spend all your life coddled by scripting languages you can float along, oblivious to reality. But someone has to deal with this stuff. When Java breaks, what do you do then? Crying isn't going to help.

OO is just another way to look at a solution. It's not inherently good or bad. Unfortunately, the (barely) trained monkeys coming out of what passes for universities these days have been brainwashed to hum the OO mantra for all seasons and are utterly incapable of creative or independent thought. A good programmer needs to first understand his hardware. Without that, he's just a glorified secretary. After that, he needs to understand his compilers and toolchain. He needs to be concerned with what kind of executable gets generated from the source code he writes, or he will not be able to discern good from bad. Java "programmers" are the singularly most incompetent, ill-equipped, misguided group of hapless morons the world has yet known, surpassing even the herculean lameness of their structured forefathers. There's nothing new in Java and there's nothing intrinsically good about "new" or bad about "old". Understanding what came before is good so you can build on it. It seems as though most people today don't understand that, and everything is a fad. If you just got off the boat (student) or haven't had a real job in your life (academic) don't presume to tell us you know better than we.

Believe it or not, they sent men to the moon without IDEs, without code completion, class browsers, or GUI builders. We've written operating systems, filesystems, and "mission-critical" software- real software- using basic tools coupled with a real understanding of hardware, software, and how the two are supposed to fit together. There isn't anything in software that we haven't already accomplished just by staying with the basics.

There are more lines of COBOL running today than there are lines of probably most other languages added together. It's not beautiful, it's not elegant, it's not glamorous. But it's an honest, basic, and effective language which fulfills its purpose better than anything that has been devised in 40 years (except PL/I, which never caught on). Pascal on the other hand, was designed for academic indoctrination, and the world would have been better served had it (and its designer) never been allowed to escape from the laboratory.

I copied Yegg's question in as it was the motivation for this response in which I hoped to give a little history lesson, since people today seem so oblivious of and disrespectful to the same (history, not Yegg!) Aside from the := issue, I don't mean anything here as a reply to Yegg...but thanks for prompting the discussion.