I have not familiarized myself with the arguments against expression-based design but as a naive individual contributor/end-user-of-languages, expressions seem like one of the few software engineering decisions that doesn't actually "depend," but rather, designing languages around expressions seems to be unequivocally superior.
Now every time I use typescript or go I have trouble trying to express what I want to say because `when` and similar expressions are just such a convenient way to think about a problem.
In go that means I usually end up extracting that code into a separate function with a single large `switch` statement with every case containing a `return` statement.
In most modern languages something like this could be implemented using composition with interfaces or traits. Especially in Rust it’s possible to write very robust code that has identical performance to the if-else spaghetti, but is proven correct by the compiler.
I’m on mobile, so it’s hard to read through the code, but I noticed one section that tries to find an existing volume to use, and if it can’t, then it will provision one instead.
This could be three classes that implement the same interface:
class ExistingVolume : IVolumeAllocator
class CreateVolume : IVolumeAllocator
class SeqVolumeAllocator : IVolumeAllocator
Far more flexible and robust than carefully commented if-else statements!
Similarly, there's a number of "feature gate" if-else statements adding to the complexity. Let's say the CreateVolume class has two variants, the original 'v1' and an experimental 'v2' version. Then you could construct a SeqVolumeAllocator thus:
allocator = new SeqVolumeAllocator(
featureFlag ? new CreateVolumeV2() : new CreateVolumeV1(),
new ExistingVolume() );
See the legendary Andrei Alexandrescu demonstrating about a similar design in his CppCon talk “std::allocator is to allocation what std::vector is to vexation”: https://youtu.be/LIb3L4vKZ7U
Expressions produce a value, statements do not. That's the key distinction. In C, if statements do not produce a value. In Lisp, if expressions do. This changes where the expression/statement is able to be used and, consequently, how you might construct programs.
In languages where if is a statement (aka returns no value), you'd write code like
int value;
if(condition) { value = 5; } else { value = 10; }
Instead of just int value = if(condition) {5} else {10}
Some languages leave ifs as statements but add trinary as a way to get the same effect which is an acceptable workaround, but at least for me there are times I appreciate an if statement because it stands out more making it obvious what I'm doing.
int value1 = 0;
int value2 = 0;
if (condition) {
value1 = 8;
value2 = 16;
} else {
value1 = 128;
value2 = 256;
}
int value1 = if (condition) { 8 } else { 128 };
int value2 = if (condition) { 16 } else { 256 };let (value1, value2) = if (condition) { (8, 16) } else { (16, 256) }
Or else you’d just use some other sort of compound value like a struct or something. Tuple is just convenient for doing it on the fly.
I love destructuring so much, I don't know if I'd want to use a language without it anymore.
Plus side I dabble in f# which is so much more expressive.
https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
So like I believe you can do this in Rust (haven't written it in a while, I know it has destructuring of tuples)
let (a, b) = if (condition) { (1, "hello") } else { (3,"goodbye") }
int value1 = 128;
int value2 = 256;
if (condition) {
value1 = 8;
value2 = 16;
}In case I'm correct, this is from Andrew Gerrand, one of the creators of Go:
The reason we didn't include exceptions in Go is not because of expense. It's because exceptions thread an invisible second control flow through your programs making them less readable and harder to reason about.
In Go the code does what it says. The error is handled or it is not. You may find Go's error handling verbose, but a lot of programmers find this a great relief.
In short, we didn't include exceptions because we don't need them. Why add all that complexity for such contentious gains?
My poor attempt at a definition, covers it in practice in languages I'm familiar, but not in theory, I assume: a language where switch statements return a value
boo := bar
if foo {
boo = baz
}
(I’m not exaggerating or being flippant: Google programmers being too stupid to understand modern programming languages has literally been cited as one of the main design goals of Go).
Anyway, complicated code should be avoided whenever possible, true, but banning the ternary operator (and similar constructs like match/switch statements as expressions) does nothing to make code simpler. It just forces you to transform
let x = (some complicated nested expression);
var x;
// (some complicated nested tree of statements where `x` is set conditionally in several different places)The `if` statement is just less ergonomic than the ternary operator, because statements don't compose as well as expressions do. A language which has a lazy ternary operator, and which lets you use an expression of type `unit` as a statement, does not require an `if` statement at all, because `if a then (b : unit) else (c : unit)` is identically `a ? b : c`. The converse is not true: you can't use `if` statements to mimic the ternary operator without explicitly setting up some state to mutate.
A language where everything is a value. Yes, a switch statement could be considered a value. More specifically - these are expressions that can be (but don't necessarily have to be) evaluated into a value. The most practical and introductory example of this is probably Ruby (called case: http://ruby-doc.com/docs/ProgrammingRuby/html/tut_expression...).
Python, JS, Ruby all have facilities to do this to varying extents. For a "true" expression-based language you will want to look at something like Clojure.
Check out the ‘case’ statement in elixir for an example.
In languages that support it, it usually becomes an incredibly commonly used expression because it’s just so applicable and practical.