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.