Oh, good idea ... any preference on the first? :-)
soc
joined 2 years ago
Naming conventions in programming – a review of scientific literature [and tips on how to do it well]
Naming conventions in programming – a review of scientific literature [and tips on how to do it well]
Sure, there are some worse/more limited predecessors – my design was partially motivated by a desire to improve upon these.
For instance, that ML-derivative you are using for your examples
- very likely still has
if then else
in the language, thus making it not unified - desperately tries to emulate functionality with guards that simply comes out of the box with my approach
- relies on the ultimate hack of "match on unit", because
match
is very limited in which coding patterns it can express
Also, none of the examples are "more clear" or "have less magic":
Maybe they are more "familiar" to you personally, but that's about it.
Too me they just look clunky, full of accidental complexity and trying to work around a poor/limited language design.
view more: next ›
That's still a workaround to try and keep a completely artificial distinction alive.
Even if I didn't need
[]
for types, I still wouldn't want "some functions use()
, some functions use[]
" as a language rule.