|
REBOL for COBOL programmers |
A shorter letter
Date written: March 6, 2015 This is a thought on the idea of defining variables You should read this article by Carl which will open in a new window. This is a comment about the concept of "clean expression" (which I fully admit I might not understand at all). You probably have heard that quote, attributed to many, of, "If I had more time, I would have written a shorter letter." The idea is that you might be able to say things better if you could take time to pare down how you say it. Also of interest is those scenes you sometimes see in movies, where character 1 explains something in a somewhat involved manner, then character 2 asks, did you mean such-and-such (phrased more simply), character 1 says yes, character 2 comes back with something like, why didn't you say so in the first place, and character 1 finishes with, I believe I did. Consider the following code sample. >> BLK: ["Tom" 01-JAN-2000 "Dick" 01-FEB-2001 "Harry" 01-MAR-2002] == ["Tom" 1-Jan-2000 "Dick" 1-Feb-2001 "Harry" 1-Mar-2002] >> foreach [NAME BIRTHDATE] BLK [print [NAME " born on " BIRTHDATE]] Tom born on 1-Jan-2000 Dick born on 1-Feb-2001 Harry born on 1-Mar-2002 >>In a COBOL program you would have to define variables called NAME and BIRTHDATE before you could use them, and code like the above would give a syntax error because NAME and BIRTHDATE were undefined. In REBOL you can just use those words, and any sort of definition, or memory allocation, or whatever is taken care of. When you are familiar with REBOL, and have the reflex that NAME and BIRTHDATE are place holders for words taken out of the block in the processing of the "foreach" loop, being required to pre-define NAME and BIRTHDATE elsewhere in the program will seem like a nuisance. Not only that, the extra lines of code to define those variables will make the whole program bigger, and more code usually is harder to process mentally than less code. Add up a couple lines for this loop, and a couple more lines for another loop, and pseudo-definitions for other words (where you set a word to some initial value just for the sake of defining it), and you can get a bunch of code that is not really necessary for the sake of solving the problem. In other words, one might argue that a language like COBOL prevents a clean expression of a problem solution, because there must be so much extra code in the solution. Alternatively, one might argue that the requirement in COBOL for defining everything makes a tidy, if verbose, expression of a solution. A conclusion to these notes was deliberately omitted. |