5 ms·
> 1. Everything is an expression. I am not sure this argument is given. Immediately, I see there is a mismatch between what I want to program -- an objectiv
by hzhou321 7y ago
> 1. Everything is an expression.
I am not sure this argument is given.
Immediately, I see there is a mismatch between what I want to program -- an objective, an algorithm, a procedure, a series of side effects that is outside the axioms of the programming language can support -- a mismatch between these objectives and this confinement of everything being an expression. An expression is a value. So to program in a language where everything is an expression is to map our idea into a (list of) value. This may be natural for programs that is seeking a value, but often not so. Even for programs that is seeking a value, the bulk of the program is to control the process of finding this value. There is no easy way or even correct way to map a process and side effects into a value. Math is logic or equivalency. To establish equivalency is to discard the effect of path or side effects. Therefore, to map the desired process and side effects into value, we have to add back the implicit knowledge of how these values are actually transformed. In stead of directly stating the transformation of values -- an imperative programming style -- we express that with dependency and relying on the understanding how these dependency is being resolved. The latter is very hard.
Of course, in practice, we have to give up on the fine control of our program to some extent and relying on the compiler implementation giving us desired result (the path and its side effects), then we only need worry about the value. When it works, it works great; when it does not work, we need either lower our expectations or give up the language, or transfer the burden/blame to compilers.
The argument for everything being an expression is the composability(although I thought the reason was ease and flexibility of writing compilers for it). This is similar to the argument that: if every object is a lego piece, then building something is easy. Well, it depends. First we need accept that lego pieces are all what we have. Second, we have to contend that what lego pieces can build is good for our needs. There are amazing lego projects, but they are nowhere I would find easy.
- lispm 7y agoWell, in languages like Scheme and Lisp, expressions are returning a value. But they can also be control structures. For example IF forms are an expression, but IF is also a control structure: (if (rocket-engine-running?) (start-rocket) (start-engine))
- hzhou321 7y agoWhen expression is not pure value -- they also can be control structures -- the arguments for "everything is an expression" is being defeated, right? A control structure is for defining the path -- control flow. The values in a control structure is a side effect just as the control-flow is a side effect in an expression language. When control flow is the center of logic, won't a control-flow oriented language -- imperative programming -- be more straight forward? In your example, after you started the engine, don't you still need `start-rocket`? The bug sneaks in due to discrepancy that while the syntax is all about values, the semantics is all about flows.
- lispm 7y agoIt gives us as a developer the freedom to decide: do I want control flow, return values or both?