REBOL for COBOL programmers

Programming by side effects

Date written: March 29, 2013
Date revised:
Date reviewed:

Here is something to think about that might help in understanding.

Programming paradigms

If you go to youtube and search for "stanford programming paradigms" you might some lectures on programming paradigms. One concept mentioned in one of them is "programming by side effects."

In REBOL, you make a function call and the function returns a result. These functions are the built-in functions or ones that you write. The result of that function call can be assigned to another word, or fed into another function.

In COBOL, you define all these data items in the file section or in working storage, and then you perform some blocks of code, and stuff happens to those data items you defined. That stuff that happens is the side effects of the code you ran.

Similar things happen in assembler language or machine language. The computer is a processor and memory. You set up spots in memory where your data will reside. You run a block of code somewhere. Your data items change. Those changes are the side effects of running the code.

If you approach REBOL trying to figure out how to set up this side effect scenario, you might get confused. That's not REBOL's "paradigm." You can write REBOL in the "side effect" paradigm if you want to, but you are not going to find features of the language, like a working storage section, that lead you into the side-effect paradigm.

COBOL is a third-generation language. The first two generations were machine language and assembler. If you are coding in machine language or assembler, you are so close to the hardware that the side-effect paradigm is natural. That's what you've got to work with, memory locations and instructions. Something else, like a function call and a returned value, is a higher level of abstraction. COBOL is one step above assembler language, but still is in that side-effect thinking. You still reserve memory locations for data, but instead of a bunch of "DS" (define symbol) directives, for example, you use a bunch of English-like data names in working storage. Instead of coding individual instructions wherever you want, you group English-like instructions in a procedure division. But the paradigm is very similar.

If you can accept that your use of COBOL leads you to try to write programs in a certain way, and that there are other ways, maybe you can stop looking for COBOL ways in REBOL. Looking for COBOL-like ways of doing things in REBOL can block your understanding of how to use REBOL.