I will take an actual look into it later though, seems interesting.
I will take an actual look into it later though, seems interesting.
I actually like the Haskell syntax more because it's looks nicer when formatted in multiple lines:
-- Haskell:
-- single line
if ... then ... else ...
-- multiline
if ...
then ...
else ...
Where in Rust with normal formatting it because 5 whole lines: // Rust:
let result = if ... {
...
} else {
...
};
// or, 4 lines but less common:
let result = match ... {
true => ...,
false => ...,
};
I think the strongest argument for condition-first that's unrelated to "taste" is the fact it is consistent with the order of execution: # Python:
# you have to read "from the middle out" to read with the order of execution
x = a() if b() else c()
I also strongly suggest you look up why Python ended up with the syntax it did. The reasons were not really good and not really applicable to a new language. Maybe my memory is bad because I can't find the source, but I remember one of the justifications was simply that it turned out faster in cpython (the python interpreter) in the test implementation they did.I might also consider asking Chris Lattner (Mojo language). They did use that syntax in Mojo, because it is made to be a superset of Python. But I remember hearing him say he really disliked it.
I'm curious. Why do you think it is bad? What are the possible issues that this style can cause?
On a more basic level, I just don't see any good reason to put the condition in the middle.
Lisp: `(if <cond> <then> <else>)` Haskell: `if <cond> then <then> else <else>` Rust: `if <cond> { <then> } else { <else> }`
All the above read fine and normal. In the python version the order of execution is different then the left-to-right reading order.
It's not like it's a fatal flaw for a language to do it like Python. But it is just silly IMO. My POV is that I actually really like if-expressions, but hate the condition-in-the-middle syntax, so I tend to avoid it unless it's really short. When code changes slightly and becomes longer I'd rather not have to always double take if this now should change to an if-statment or to an expression etc.
Oof! I can see how that can get really messy really fast. Though I wonder how much of it is the language's fault as it is the programmer's. I used to tell my students to avoid trying to be too clever with the source code. Source is meant for humans to read. Leave the cleverness to the interpreter.
> On a more basic level, I just don't see any good reason to put the condition in the middle.
Thinking about it again, I think I understand why the language designers chose that order. They were trying to make it make it more readable by following the structure of the English language. "<Buy a steak> if <the butchers are open>. Otherwise <get some salmon>".
The problem here is that programmers are more accustomed to the natural and somewhat obvious order that every other programming language follows. They also wouldn't have expected some people to abuse it by nesting it.