Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yoda Conditions

en.wikipedia.org

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Yoda Conditions

#71

Post by kazinator »

nilved wrote: post #66
dom96 wrote: post #20

Earlier quoted context omitted.

There is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.

There's nothing wrong with using assignment in if conditions. For example, `if let Some(thing) = computation_that_may_fail { ... }`.

The operator there is let. The = is just a punctuator which indicates the initial value expression for the let.

Litmus test: if this was rendered into S-expressions, the let would stay, but the = would disappear.

Re: Yoda Conditions

#72

Post by kazinator »

dom96 wrote: post #20
hashkb wrote: post #16

Earlier quoted context omitted.

The real lesson is for language designers, who for some reason love using equals for assignment. Lisp got it right a hundred years ago and nobody learned.

There is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.

That's a cure worse than the disease. If I faced a false choice between = as an assignment operator or else accepting syntax that distinguishes statements and expressions, I'd just take the = operator.

Re: Yoda Conditions

#73

Post by Gaelan »

ghurtado wrote: post #63
Gaelan wrote: post #40

Earlier quoted context omitted.

You can write gibberish in any language. You shouldn't kill useful features because they are sometimes misused.

Not even PHP's "register_globals"?

I'd argue that register_globals is never a good idea. Post-if is sometimes a good idea, with one case that is problematic (less readable, not even a negative affect on function)

Re: Yoda Conditions

#74

Post by jquast »

geofft wrote: post #30

I ran across a bug at $dayjob where someone was clearly trying to use Yoda conditions, but messed up differently: if "start" == argv[1]: .... else if "stop" == argv[1]: .... else if "reload": .... else if "status" == argv[1]: .... I think it'd be harder to make this mistake with the conditions the right way around. (Also, never mind that the equality bug isn't even possible in Python.)

I wish python had case statements for this very problem. If the statement blocks can be defined by a common function signature, your example could use

  {'start':  fn_start,
   'stop': fn_stop,
  }.get(
    argv[1] if len(argv) > 1 else None,
    fn_undefined
  )(*args, **kwargs)
I used this in a demonstration terminal nibbles/worms video game clone, https://github.com/jquast/blessed/blob/master/bin/worms.py#L...

Re: Yoda Conditions

#75

Post by cronjobber »

hashkb wrote: post #16
paol wrote: post #3

Don't do this. In languages where accidental assignment is possible (i.e. writing if(a=b) when you meant if(a==b) ), configure the compiler or linter to emit a warning in this situation. For example in C, GCC will complain about this when compiling with -Wall, which you should be using anyway.

The real lesson is for language designers, who for some reason love using equals for assignment. Lisp got it right a hundred years ago and nobody learned.

Hacker News is implemented in a dialect of Lisp designed by a guy who wrote multiple books on Lisp. Seems even lispers don't learn:

> The assignment operator is =. I was dubious about this, but decided to try it and see if I got used to it. It turns out to work well, even in prefix. Stripes stand out, which is why they get used on warning signs and poisonous animals.

http://www.paulgraham.com/arcll1.html

Re: Yoda Conditions

#76

Post by kazinator »

cronjobber wrote: post #75
hashkb wrote: post #16

Earlier quoted context omitted.

The real lesson is for language designers, who for some reason love using equals for assignment. Lisp got it right a hundred years ago and nobody learned.

Hacker News is implemented in a dialect of Lisp designed by a guy who wrote multiple books on Lisp. Seems even lispers don't learn: > The assignment operator is =. I was dubious about this, but decided to try it and see if I got used to it. It turns out to work well, even in prefix. Stripes stand out, which is why they get used on warning signs and poisonous animals. http://www.paulgraham.com/arcll1.html

That is quite silly. I briefly contemplated this idea for TXR Lisp, but completely rejected it. The = function is numeric comparison, like in Common Lisp. You don't want to turn that into assignment. People used to Lisp dialects where = is numeric comparison will make the mistake:

  (if (= whatever whatever-else) (you-got-burned))
Arc code written by people used to Lisp dialects where = is a pure comparison function, or Arc code converted from other Lisp dialects, has to be carefully reviewed against this.

If I put this into a Lisp dialect, I would make the code walker issue a warning whenever the value of a (= ...) assignment is used, and provide an alternative assignment operator which doesn't have that warning.

Re: Yoda Conditions

#77

Post by ghurtado »

Gaelan wrote: post #73
ghurtado wrote: post #63

Earlier quoted context omitted.

Not even PHP's "register_globals"?

I'd argue that register_globals is never a good idea. Post-if is sometimes a good idea, with one case that is problematic (less readable, not even a negative affect on function)

I happen to agree, but the statement was about "useful features".

Re: Yoda Conditions

#78

Post by nilved »

kazinator wrote: post #71
nilved wrote: post #66

Earlier quoted context omitted.

There's nothing wrong with using assignment in if conditions. For example, `if let Some(thing) = computation_that_may_fail { ... }`.

The operator there is let . The = is just a punctuator which indicates the initial value expression for the let . Litmus test: if this was rendered into S-expressions, the let would stay, but the = would disappear.

No, that's just because the example I used was Rust. In Ruby it would be `if user = User.find(..)` and the same goes for Go and plenty of other languages.

Re: Yoda Conditions

#79

Post by alexeiz »

Yoda conditions suck. You don't compare a constant to a value of a variable to make sure that the constant has a certain value. Such comparison is backwards. Unfortunately it is extremely popular at Microsoft among C++ programmers. They seem to totally lack any sense of style. Sometime in the nineties the enforcement of Hungarian notation throughout the company had a long lasting damaging effect on their psyche they still can't recover from after all these years.

Re: Yoda Conditions

#80

Post by kazinator »

nilved wrote: post #78
kazinator wrote: post #71

Earlier quoted context omitted.

The operator there is let . The = is just a punctuator which indicates the initial value expression for the let . Litmus test: if this was rendered into S-expressions, the let would stay, but the = would disappear.

No, that's just because the example I used was Rust. In Ruby it would be `if user = User.find(..)` and the same goes for Go and plenty of other languages.

If user is being freshly bound, that isn't an assignment but an initialization.

If the construct is not allowed when user is already in scope, it reflects the designer's view that an assignment in a conditional isn't a good thing.

If the construct is allowed when user exists already, with no diagnostic, then it carries the pitfalls that this thread is about.

Post reply on HN