At one time Dijkstra had to actually argue for structured programming. No-one would take the counter position today.
The equivalent debate nowadays is between languages that separate statements and expressions and expression-oriented[0] languages.
[0]: https://en.wikipedia.org/wiki/Expression-oriented_programmin...
I mean, how many libraries with weird APIs were created just because you can't write the following in most Algol-like languages:
return if(sth) {
foo = SomeProcessing();
Transform(foo);
} else if(sthelse) {
Transform(someDefault);
} else {
someErrorDefault;
};
--
[0] - Which transitions into what is a real debate - "lots of small functions" vs. "fewer but larger functions". It's one of those holy wars that can't die, because both sides have good arguments. But it's a false choice - a limitation of the tools we're using to write programs. 'emilprogviz has a nice summary of that last point here: https://emilprogviz.com/ep05/ep05-transcript.html
Linking to transcript, in the spirit of "text with screenshots is almost always better than a video" - (nice job providing it Emil!) - but the video itself is good too, as are others on that site.
To offer one argument: the problem with expression oriented languages is their generality, in that you can write "weird" expressions, e.g.:
let x =
[giant block of code with multiple nested lets, ifs, etc.]
in
f(x)
Also, for low level languages, the mapping between code and assembly is clearer in languages that separate statements and expressions (I need a more succinct term).
EDIT: Also, by preventing statements from being used as expressions, you encourage breaking up long and complex statements into smaller functions.
Oh, I see what you mean. I discovered Lisp after working in C++ and Java, so I avoided this pitfall in my code, but if I had a dollar for every instance of:
(let ((some-variable (progn
(do stuff)
(do other stuff)
(let ((some-helper-var ...))
(some more code with some-helper-var)
(more-of-the-same (progn
...)))
;; 50-100 lines later, just return one of the values
some-variable)
There's plenty of abuse potential here (and for the love of god, if your language has 'let', it probably also has lambdas or 'flet', use that to create local functions...). But mitigating this, arguably, is a problem for style guides - the overall feature of "everything is an expression" is powerful. It has nice simplicity to it, and reduces boilerplate :).
> Also, for low level languages, the mapping between code and assembly is clearer in languages that separate statements and expressions
I'm guessing this is where the separation originally came from. Assembly is essentially statement-only. But at this point, I think all programming languages in use crossed the threshold where we're actually programming to an "abstract machine", and being expression-oriented seems to confer greater expressiveness.
> (I need a more succinct term).
"Separatist"? :).
> EDIT: Also, by preventing statements from being used as expressions, you encourage breaking up long and complex statements into smaller functions.
Ah yes. The real debate. I edited my comment to mention it before I saw your edit :).
The simplifying potential of expression-oriented languages is huge. Alan Perlis said[0]: "symmetry is a complexity-reducing concept; seek it everywhere", and this is a great example of that.
For example, languages like C and Ada have both if statements and if expressions, this is a duplication that can be eliminated by making them expression-oriented so you only have an if expression like in Haskell or ML.
But, interestingly, there is one historical case of a language going from expression-oriented to statement/expression separation: ALGOL-W[1] was expression oriented, Pascal[2], its successor, separates statements from expressions. Wirth designed both.
I don't know what the motivation was, but I suspect it's because Pascal was designed to be an educational language, and Wirth must have thought that separating expressions and statements made didactic sense when teaching programming as a recipe or list of things to do, as opposed to the more mathematized formulation of expression-oriented languages (of having an evaluation function from expressions to values).
The successors of Pascal (Ada, Modula and its sequels) retain the statement/expression separation.
[0]: http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html
[1]: https://en.wikipedia.org/wiki/ALGOL_W
[2]: https://en.wikipedia.org/wiki/Pascal_(programming_language)
And the block expressions in Algol-68 were certainly used and abused. Basically, the type and value of a block (BEGIN ... END or ( ... )) are those of its last expression, so you can put them anywhere. For example, Algol-68 has the looping construct WHILE <condition> DO <body> OD, but not C's `do <body> while (<condition>)`. So what do you do if you want to have the test at the end of the loop body? Simply
WHILE (
<body>;
<condition>
)
DO SKIP OD
test := True;
WHILE test
DO
<body>;
test = <condition>
ODThis is one of those anti-patterns I sometimes find myself falling into (I don't code Lisp or its descendants often). It's kind of discouraging, to be honest, because it feels like there ought to be some more efficient way to do this, and my inner critic comes along and complains that I'd be better of writing Python or C than learning to do it the Right Way in Lisp.
Is there some kind of idiomatic way to avoid this and write cleaner code? Is the solution to simply extract the progn into another function? Does that violate some rules of function encapsulation in Lisp?
The problem is that the toplevel of a module is full of functions at various levels of granularity.
It might be nice if programming languages had a concept of "code sections" (you could implement this with literate programming), where modules are organized hierarchically into sections, and declarations can be public or private within a section. So you might have:
section foo
// Accessible from outside this section
public important_function()
// Only accessible from inside this section
private utility_function_1()
private utility_function_2()
end sectionExactly--this is what I was hinting at with "rules of function encapsulation." I took a course on LISP in college (apropos of nothing, it featured a lab called, "Isn't this just a one credit course?") in which it seemed like the LISP Way was to use helper functions. It's always felt like something was missing in my ability to "translate" between paradigms because this rubs me the wrong way (although as I went through some examples I realized I do this with some regularity in other languages--but it doesn't "feel" as bad).
In retrospect probably part of the problem was that we ALGOL-adjacent undergrads didn't have the scaffolding to understand more generic approaches like fold and cousins. It was a different way of thinking.
I like the idea of literate programming as a potential solution, especially as it can be used to guide newbies through the code and identify areas where idioms are much different between one's existing paradigms and that of the codebase.
I like to think that there is no OOP vs FP, there is no strong typing vs no typing, there should be just adding to a shelf with tools that each has application in some situations but also constraints on when it can be used effectively. And your job as developer is to understand the bounds on application and effectiveness.
The road to mastery of development then should be by learning and understand those various tools (in the broadest possible sense) rather than by forming strong opinions and shunning the other side of the debate. People who cut off themselves from OOP will never learn its benefits just as people who cut themselves from FP.
I think you're overstating the case with
return if(sth) {
foo = SomeProcessing();
Transform(foo);
} else if(sthelse) {
Transform(someDefault);
} else {
someErrorDefault;
};
var rv: SomeType; -- return value
rv = someErrorDefault;
if(sth) {
foo = SomeProcessing();
rv = Transform(foo);
} else if(sthelse) {
rv = Transform(someDefault);
}
return rv;
The argument against separating expressions from statements is also that it adds redundancy to your programs, as in the above example.
I wrote an essay about this tradeoff in general, not limited to expressions vs. statements, at http://www.paulgraham.com/redund.html.
The arguments against it are always that it requires having keywords that behave differently when being expressions or statements.
Often the alternatives and compromises proposed always have the same issues, such as Javascript repurposing the do keyword for enclosing expression ifs.
For instance with Imperial vs Metric System, Metric optimizes for multiplication, while Imperial optimizes for division. You can never unify these under the current system. But you can, if you change our base to base 12. Then they suddenly merge.
With CLI vs GUI, we've realized that we needed a mixture. We need a GUI that runs through a CLI. And now we have that, it's called a website. I think tabs vs spaces was solved similarly, with tabs as spaces that editors config can treat n-straight-spaces as tabs.
I'm firmly on the expression only and lots of functions sides, but that transcript is very interesting. You can already do local functions in C#, it seems to be implying that we should strive for that to be our mixture.
I strongly agree. Also, that's poetically put. I'm saving this in my quotes file.
I don't see expression-oriented as being similar to that at all. Expression-oriented may provide a boost to programmer efficiency, but it's not nearly on the order of structured programming vs. unstructured. It doesn't require changing peoples' mindset to realizing that programmer time is more valuable than machine time; they already know that. And, the parallel problem would be clarity of data flow, and I'm not sure that expression-oriented is a huge win in that area.
In my opinion it is, because you can compose data transformations from smaller parts. Each part can do only one thing.
For example in Clojure, you could do.
(def transform
(comp
(do-thing-a)
(do-thing-b)
(do-thing-c))
(map transform my-collection)
(-> basket-of-apples
(select-ripe)
(clean)
(cut-to-pieces-of-size 4)
(pack))
Imagine if, nowadays, a grad student took a node in a scientific cluster to run Dreamweaver in a Windows VM instead of writing HTML by hand. (Sorry, it's the closest analogy I could come up with)
He was probably frustrated that people couldn't see the machine code fully formed in their mind's eye :)