3 ms·

But these are not absolutes. You can learn to use and read `unless` just as effortlessly as you did with `if`. I didn't learn to use/read `unless` on college. B

But these are not absolutes. You can learn to use and read `unless` just as effortlessly as you did with `if`. I didn't learn to use/read `unless` on college. But I did focus on trying to learn these things and today I have another tool in my belt. It's an opportunity to get better at something versus banning it from usage because we aren't used to it. Growing is, for me, almost always the right choice.

neilv 4y ago
Dangling conditionals the parent was talking about. Where the conditional comes after the thing you told it to do. Computationally, that's increased backtrack/lookahead for no good reason. Regarding `unless`, that's a different matter. I was actually the person who proposed adding an `unless` syntax to Racket, and later regretted it. I was bikeshedding, before I knew something more useful to do. This isn't about learning new things to add to our mental toolbox. This is about our difficulty to introspect on our own thought processes and effectiveness, and about bikeshedding. Software engineering competence is hard, or we wouldn't have all the huge expenditures, slipped project schedules, and rampant security vulnerabilities. Redundant syntax forms that objectively makes it harder to read (see the lookahead and parser theory), solely because someone imagined it was sometimes easier to read this way (see dying languages Perl and Ruby) is just wasting our time, when we could be tackling the real problems. (Though us pulling theories about programming and process out of our posteriors, to defend to the death, is arguably half our problem in industry right now.)