- #1
- 1,231
- 0
I've been thinking about functional programming and what really makes it different from imperative programming. It's not that you can prove things more easily about programs written in it--that may be true, but most programmers do not prove the correctness of most of the code they write so it can't be the central feature. I think that the difference is that data is "up front" and easily visible as the arguments to a function or the return value of the function. This makes it easier to understand. I recently had the misfortune of trying to figure out how a disorganized Python program works. This program had a central loop that just called a series of functions with no arguments. The functions depended entirely on side effects, setting member variables instead of returning values (and worse, in Python you don't have to declare your member variables before you use them; they were getting declared within the functions, not in the initializer). It was very difficult to read--even determining the type of a lot of things was a challenge, since they were being read from external data and Python doesn't have an explicit type system.
Data hiding is right in one thing: it's bad to allow outside code to directly alter your class data, and perhaps also bad to allow outside code to directly access your class data. But I believe that it's clearer to read if all data handled and its type should all be instantly in the view of a programmer reading the code. i.e. a distinction should be made between hiding data from another part of the program, which is good, and hiding data from the programmer, which is not good. If a function alters any global or member variables or performs any I/O, it should say that does in its declaration--and what exactly it does to that data should be documented, not abstracted away. A while ago I was trying to determine how HashMap worked and why it didn't seem to be efficient. The abstract description contained no clue, and it was only by going past the abstraction, into the source code for the class, that I figured out what it was really doing.
I want a programming language that has these properties:
--object oriented
--strongly typed
--all inputs to a function must be declared along with their type
--the return value of the function must be declared along with its type
--if any global or member variables that persist outside the function are altered or accessed within a function, these must be declared in the function declaration
--if any IO is used in a function, this is basically the same as altering global variables and must be declared
--the documentation guidelines ask that for each non-trivial function, the following should be described:
1. What its inputs are
2. What its output means
3. What (global data, member vars, input) it reads data from
4. What (global data, member vars, output) it writes data to and what its output to those places mean
5. What exceptions it may cause, and when
--the documentation is tiered, so that it can be set to various levels with lower levels of documentation hidden. 1 and 2 are the bare essentials--if there is any documentation shown then 1 and 2 should be shown. Also 5 should be shown. If more information is needed, 3 and 4 should be shown, with I/O and global data at a higher level of visibility than member vars.
--Optimally, the type signature for a class, describing all of that besides the manual documentation, should have the option to be generated automatically to save typing.
As Frederick P. Brooks said in The Mythical Man Month:
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
Data hiding is right in one thing: it's bad to allow outside code to directly alter your class data, and perhaps also bad to allow outside code to directly access your class data. But I believe that it's clearer to read if all data handled and its type should all be instantly in the view of a programmer reading the code. i.e. a distinction should be made between hiding data from another part of the program, which is good, and hiding data from the programmer, which is not good. If a function alters any global or member variables or performs any I/O, it should say that does in its declaration--and what exactly it does to that data should be documented, not abstracted away. A while ago I was trying to determine how HashMap worked and why it didn't seem to be efficient. The abstract description contained no clue, and it was only by going past the abstraction, into the source code for the class, that I figured out what it was really doing.
I want a programming language that has these properties:
--object oriented
--strongly typed
--all inputs to a function must be declared along with their type
--the return value of the function must be declared along with its type
--if any global or member variables that persist outside the function are altered or accessed within a function, these must be declared in the function declaration
--if any IO is used in a function, this is basically the same as altering global variables and must be declared
--the documentation guidelines ask that for each non-trivial function, the following should be described:
1. What its inputs are
2. What its output means
3. What (global data, member vars, input) it reads data from
4. What (global data, member vars, output) it writes data to and what its output to those places mean
5. What exceptions it may cause, and when
--the documentation is tiered, so that it can be set to various levels with lower levels of documentation hidden. 1 and 2 are the bare essentials--if there is any documentation shown then 1 and 2 should be shown. Also 5 should be shown. If more information is needed, 3 and 4 should be shown, with I/O and global data at a higher level of visibility than member vars.
--Optimally, the type signature for a class, describing all of that besides the manual documentation, should have the option to be generated automatically to save typing.
As Frederick P. Brooks said in The Mythical Man Month:
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious."
Last edited: