Not Equals

Please compose all posts in Emacs.

Moderators: phlip, Moderators General, Prelates

Which do you prefer?

!=
161
76%
~=
2
1%
/=
5
2%
=/=
20
9%
<>
8
4%
Platypus
15
7%
 
Total votes: 211

User avatar
Sizik
Posts: 1159
Joined: Wed Aug 27, 2008 3:48 am UTC

Not Equals

Postby Sizik » Tue Aug 07, 2012 11:04 am UTC

There are many ways to represent ≠ in ASCII, but not all were created equal. If they were, that would defeat the purpose.
gmalivuk wrote:
King Author wrote:If space (rather, distance) is an illusion, it'd be possible for one meta-me to experience both body's sensory inputs.
Yes. And if wishes were horses, wishing wells would fill up very quickly with drowned horses.

Elench
Posts: 0
Joined: Wed Sep 09, 2009 9:39 pm UTC

Re: Not Equals

Postby Elench » Tue Aug 07, 2012 12:04 pm UTC

Either ≠ or ¬= here.

Though now I'm not sure if ¬ is in ASCII...

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Tue Aug 07, 2012 2:07 pm UTC

Elench wrote:Either ≠ or ¬= here.

Though now I'm not sure if ¬ is in ASCII...

Um, neither ≠ nor ¬ is ASCII. (Though ¬ is in Latin-1.)

ycc1988
Posts: 28
Joined: Fri Jun 22, 2012 5:13 am UTC

Re: Not Equals

Postby ycc1988 » Tue Aug 07, 2012 2:32 pm UTC

/= is "compound division and assignment" in quite a few languages. I wouldn't want to lose that to the "not equals" operator. <> is probably the easiest to type, but I'm uncomfortable with it because of the use as < and > as brackets in some languages. I'm pretty sure all languages I've ever used use either != or the sequence 'neq'.

Elench
Posts: 0
Joined: Wed Sep 09, 2009 9:39 pm UTC

Re: Not Equals

Postby Elench » Tue Aug 07, 2012 5:36 pm UTC

EvanED wrote:
Elench wrote:Either ≠ or ¬= here.

Though now I'm not sure if ¬ is in ASCII...

Um, neither ≠ nor ¬ is ASCII. (Though ¬ is in Latin-1.)


Then I'm going to keep my vote of "Platypus" and take as my preferred option not(x = y), or better yet (not (= x y)).

All the other are ugly and/or confusing.

Роберт
Posts: 4285
Joined: Wed May 14, 2008 1:56 am UTC

Re: Not Equals

Postby Роберт » Wed Aug 08, 2012 5:52 pm UTC

Using the '/' character is clearly not a good idea.
~= would be a decent idea.
<> terrible
I voted != since bang is often used for negation anyway. Really it depends on what language you're working with. Whatever signifies negation plus the equal sign.
The Great Hippo wrote:[T]he way we treat suspected terrorists genuinely terrifies me.

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Wed Aug 08, 2012 6:12 pm UTC

Роберт wrote:~= would be a decent idea.
<> terrible

You call ~= "decent" and <> "terrible"? Really?!

Without any context, ~= looks to me like an ASCII rendition of "approximately equals", which is pretty close to the opposite of what you want. In the programming language context, I can think of a few things it could be along that line. For instance, some weakly-typed languages (*cough* Perl/PHP *cough*) will consider 4 == "4" to be true, but provide a stricter operation (e.g. ===) for equality with the same type; you could turn that around and make a language with == meaning the stricter operation, and then ~= would be a decent choice for the former. Or another example: ML doesn't provide an == operation (it calls it =, but whatever) for floating point types; you have to subtract and compare against some epsilon manually. You could imagine an ~= operator that does this automatically for some global epsilon setting. (Not sure this is a good idea... but you could imagine it at least. :-))

Роберт
Posts: 4285
Joined: Wed May 14, 2008 1:56 am UTC

Re: Not Equals

Postby Роберт » Wed Aug 08, 2012 9:07 pm UTC

EvanED wrote:
Роберт wrote:~= would be a decent idea.
<> terrible

You call ~= "decent" and <> "terrible"? Really?!

Without any context, ~= looks to me like an ASCII rendition of "approximately equals", which is pretty close to the opposite of what you want. In the programming language context, I can think of a few things it could be along that line. For instance, some weakly-typed languages (*cough* Perl/PHP *cough*) will consider 4 == "4" to be true, but provide a stricter operation (e.g. ===) for equality with the same type; you could turn that around and make a language with == meaning the stricter operation, and then ~= would be a decent choice for the former. Or another example: ML doesn't provide an == operation (it calls it =, but whatever) for floating point types; you have to subtract and compare against some epsilon manually. You could imagine an ~= operator that does this automatically for some global epsilon setting. (Not sure this is a good idea... but you could imagine it at least. :-))

That's why I said it was language dependent. If the language consistently used ~ for negation, ~= would work and be intuitive. If it didn't, it would have all the problems you mentioned. In any language, <> just looks weird, I don't see how it could be intuitive, even though I get the idea behind it. Also, if you propose <>, why not propose ><?
The Great Hippo wrote:[T]he way we treat suspected terrorists genuinely terrifies me.

User avatar
phlip
Restorer of Worlds
Posts: 7543
Joined: Sat Sep 23, 2006 3:56 am UTC
Location: Australia
Contact:

Re: Not Equals

Postby phlip » Thu Aug 09, 2012 8:18 am UTC

Роберт wrote: Also, if you propose <>, why not propose ><?

Well, BASIC, whence the <> operator comes, does accept "><". And also "=<" and "=>" for less-than-or-equal and greater-than-or-equal. Or at least, QBASIC and the VB tree accept them.

Code: Select all

enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵​╰(ಠ_ಠ ⚠) {exit((int)⚠);}
[he/him/his]

Роберт
Posts: 4285
Joined: Wed May 14, 2008 1:56 am UTC

Re: Not Equals

Postby Роберт » Fri Aug 10, 2012 1:29 pm UTC

phlip wrote:
Роберт wrote: Also, if you propose <>, why not propose ><?

Well, BASIC, whence the <> operator comes, does accept "><". And also "=<" and "=>" for less-than-or-equal and greater-than-or-equal. Or at least, QBASIC and the VB tree accept them.

Interesting. If you do <=> does it always return true?
The Great Hippo wrote:[T]he way we treat suspected terrorists genuinely terrifies me.

User avatar
Grimgar
Posts: 12
Joined: Fri Jun 24, 2011 6:04 pm UTC

Re: Not Equals

Postby Grimgar » Sat Aug 11, 2012 11:56 am UTC

EvanED wrote:some weakly-typed languages (*cough* Perl/PHP *cough*) will consider 4 == "4" to be true, but provide a stricter operation (e.g. ===) for equality with the same type

There is no === operator in Perl. == is numerical equality, and eq is stringy equality. Their respective couterparts for inequality are != and ne.

<> is terrible, because it is read as "is less than or greater than", which is NOT equivalent to "is not equal to", unless you're working with a totally ordered set. Of course, it makes sense for numbers, but don't tell me that "p <> NULL" or "somePlatypus <> anotherPlatypus" makes any sort of sense. Plus, <> is the readline operator in Perl.

=/= is a poor attempt at an ASCII rendition of the ≠ character.

!= is great, because ! is commonly used as a logical negation.

Brickmack
Posts: 59
Joined: Wed Sep 01, 2010 1:48 am UTC

Re: Not Equals

Postby Brickmack » Sun Aug 19, 2012 6:37 pm UTC

!= is my choice. =/= is just attempting to make a ASCII version of ≠ (which I would choose if it was included on normal keyboards). The others look weird, and != is commonly used for negation anyway.

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Not Equals

Postby sourmìlk » Sun Aug 19, 2012 6:44 pm UTC

I don't actually have much of a problem with =/=, but I prefer != for the aforementioned reasons.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Not Equals

Postby troyp » Wed Aug 22, 2012 6:40 pm UTC

It really all depends on the language. If we're confined to ASCII and equal is == or =, I'd probably prefer /= if it's available. In a C-like language, != works pretty well.

I actually don't mind <> at all. And >< is actually even better, although I've never seen it used (I didn't realize BASIC interpreted a concatenation of operators as the operator performing the disjunction of individual operations - that's actually quite interesting).

It'd be nice if editors replaced some of these operators with symbols the way some editors replace lambda with λ.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Not Equals

Postby ahammel » Wed Aug 22, 2012 6:49 pm UTC

I like /= in Haskell, but it doesn't have compound division and assignment. != is acceptable for everywhere else.

Incidentally, using = for assignment really bothers me because you can get things like x = x + 2 which is nonsense mathematically.
He/Him/His/Alex
God damn these electric sex pants!

User avatar
sourmìlk
If I can't complain, can I at least express my fear?
Posts: 6393
Joined: Mon Dec 22, 2008 10:53 pm UTC
Location: permanently in the wrong
Contact:

Re: Not Equals

Postby sourmìlk » Wed Aug 22, 2012 7:10 pm UTC

Okay, but it's not supposed to mimic mathematical equality. Although I wouldn't mind a <- operator or something.
Terry Pratchett wrote:The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it.

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Not Equals

Postby ahammel » Wed Aug 22, 2012 7:14 pm UTC

sourmìlk wrote:Okay, but it's not supposed to mimic mathematical equality.
Well, yeah, but it means you have to invent a new symbol to represent mathematical equality. Why not just use the perfectly good symbol we've got for equality (which is even called 'the equals sign') and use something else for variable assignment?

sourmilk wrote:Although I wouldn't mind a <- operator or something.
R has that. I think a few languages us := as well.
He/Him/His/Alex
God damn these electric sex pants!

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Wed Aug 22, 2012 7:15 pm UTC

[Ninja'd, but I'll post anyway to show my agreement.]

sourmìlk wrote:Okay, but it's not supposed to mimic mathematical equality. Although I wouldn't mind a <- operator or something.

If it's not supposed to mimic it, why's it using the same symbol? :-)

While I don't care much, I am with ahammel; I'd be (a tiny bit) happier if C had gone the Pascal route and used := for assignment and = for equality testing. (<- is OK, but in the context of C I don't like how at first blush it looks like it might have some relation to ->. I also like how you can read := as being "make equal to" or something like that.)

Derek
Posts: 2154
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: Not Equals

Postby Derek » Wed Aug 22, 2012 8:15 pm UTC

I prefer = for assignment and == for comparison, as opposed to := for assignment and = for comparison, because I use assignment more often than comparison. Also == corresponds with the other standard boolean operators in being two characters (<=, >=, !=, &&, ||).

User avatar
Yakk
Poster with most posts but no title.
Posts: 11047
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

Re: Not Equals

Postby Yakk » Wed Aug 22, 2012 8:41 pm UTC

I prefer := for assignment and == for comparison. :)
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Wed Aug 22, 2012 8:58 pm UTC

Derek wrote:I prefer = for assignment and == for comparison, as opposed to := for assignment and = for comparison, because I use assignment more often than comparison. Also == corresponds with the other standard boolean operators in being two characters (<=, >=, !=, &&, ||).

cls is fewer characters than class. Should C++/Java/etc. have made that the keyword instead? i is shorter than int. Imagine how many fewer characters you could type if C chose that! := and = makes more sense than = and ==.

And sure, == has the same number of characters as <=, but you're ignoring < and >.


Yakk wrote:I prefer := for assignment and == for comparison. :)

I might actually go with that if designing a language now, but I'm not sure.

Actually I'd also consider just using ≠ (and ≤ and ≥) and letting people set up their editors so that they could get that.

Роберт
Posts: 4285
Joined: Wed May 14, 2008 1:56 am UTC

Re: Not Equals

Postby Роберт » Wed Aug 22, 2012 9:18 pm UTC

EvanED wrote:Actually I'd also consider just using ≠ (and ≤ and ≥) and letting people set up their editors so that they could get that.

Non ASCII code just seems weird to me.
The Great Hippo wrote:[T]he way we treat suspected terrorists genuinely terrifies me.

webzter_again
Posts: 119
Joined: Sun May 27, 2012 4:37 am UTC

Re: Not Equals

Postby webzter_again » Wed Aug 22, 2012 9:35 pm UTC

Роберт wrote:
EvanED wrote:Actually I'd also consider just using ≠ (and ≤ and ≥) and letting people set up their editors so that they could get that.

Non ASCII code just seems weird to me.


Code: Select all

public class ಠ_ಠAttribute : Attribute
{
  public ಠ_ಠAttribute()
  {
    Debugger.Log(1,"Code Review Time","This code is bad and you should feel bad");
  }
}

[ಠ_ಠ]
public class SomeClass
{

}


troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Not Equals

Postby troyp » Thu Aug 23, 2012 12:06 am UTC

EvanED wrote:
Derek wrote:I prefer = for assignment and == for comparison, as opposed to := for assignment and = for comparison, because I use assignment more often than comparison. Also == corresponds with the other standard boolean operators in being two characters (<=, >=, !=, &&, ||).

cls is fewer characters than class. Should C++/Java/etc. have made that the keyword instead? i is shorter than int. Imagine how many fewer characters you could type if C chose that! := and = makes more sense than = and ==.

That counterargument doesn't really hold because in those cases the shorter forms would be less readable. And "i" would be unavailable to be used as a variable, further hampering readability (since "i" is often a very natural name for a counter or index variable)

I like := and = marginally better to read, but = and == significantly better to type. Note that they're easier to type even if assignment and equality are equally common, since "==" is easier to type than ":=" (well, it is to me, although it could be that I'm less used to it).

Another combination is =: for assignment (I'd guess it's supposed to a right arrow, meaning "becomes") with = for equality. That's what J uses.

Derek
Posts: 2154
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: Not Equals

Postby Derek » Thu Aug 23, 2012 12:49 am UTC

EvanED wrote:
Derek wrote:I prefer = for assignment and == for comparison, as opposed to := for assignment and = for comparison, because I use assignment more often than comparison. Also == corresponds with the other standard boolean operators in being two characters (<=, >=, !=, &&, ||).

cls is fewer characters than class. Should C++/Java/etc. have made that the keyword instead? i is shorter than int. Imagine how many fewer characters you could type if C chose that! := and = makes more sense than = and ==.

But you don't actually need to type "class" very often, so a lengthy name is fine. And really, you should have to tell the compiler that your variables are ints most of the time :P

And sure, == has the same number of characters as <=, but you're ignoring < and >.

Shit, I knew I was going to forget something obvious when I wrote that sentence :P

Another good counter would have been to point out that all the other assignment operators are two characters: +=, -=, *=, etc. But that's also not quite right, because of >>= and <<=, so really the whole line of thought it flawed.

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Thu Aug 23, 2012 1:43 am UTC

troyp wrote:That counterargument doesn't really hold because in those cases the shorter forms would be less readable.

So I'm not saying my analogy isn't a bit of hyperbole, but I do think you can say the same thing about := and = vs = and ==. I think you'd get used to using i (or I) for int -- it'd be something you'd have to learn. I mean, you already have to learn that you type int instead of integer; it's just a matter of degree how abbreviated it'd be. Just like you have to learn that = isn't really = in the sense you're used to. In some ways, I think the = concept may even be harder to learn, because you have to break some degree of preconception about what it means.

Edit: think back to when you were learning your first C-like language... how easy was it to type if (a = b)? I think my first multi-hour debugging session was finding one of those. (Incidentally, that was what caused me to become an absolute freak about warnings. :-)) Sure, some of those bugs were just typos, probably including my big one, but I think a substantial contributor is thinking is "I want to test if a equals b, and = means equals; after all, that's what I've known since kindergarten or whatever".

Edit again: now that I think about it more, I think there are some parallels between = being assignment and calling kilo=2^10 instead of 10^3 etc. In both cases, comp sci people took a concept/notation/word that already had a well-defined meaning and applied it to a somewhat-related-but-actually-pretty-different concept in CS for the reason that it was convenient to. And in both cases, I pretty firmly think it was the wrong decision.

And "i" would be unavailable to be used as a variable, further hampering readability (since "i" is often a very natural name for a counter or index variable)

So go with I then, or something.

I like := and = marginally better to read, but = and == significantly better to type. Note that they're easier to type even if assignment and equality are equally common, since "==" is easier to type than ":=" (well, it is to me, although it could be that I'm less used to it).

I do think that you're probably right on the typing issue, for the very simple reasons that == is two of the same characters right after each other, and = is unshifted (unlike :). However, I think that readability & learnability wins out over writeability, and so would still favor := and ==.

Derek wrote:But you don't actually need to type "class" very often, so a lengthy name is fine.

But if shorter is better, shouldn't it still be an improvement to use cls, just maybe less of an improvement?

ycc1988
Posts: 28
Joined: Fri Jun 22, 2012 5:13 am UTC

Re: Not Equals

Postby ycc1988 » Thu Aug 23, 2012 7:17 am UTC

Code: Select all

int x <- 2;
if (x = 3) puts("WTF??");
if (x != 3) puts("OK");
if (x <- 3) puts("Why would anyone do this?");


The improbability of typing that last line will eliminate many programming bugs, I presume, as compared to the current C syntax:

Code: Select all

int x = 2;
if (x == 3) puts("WTF??");
if (x != 3) puts("OK");
if (x = 3) puts("Common programming mistake");

troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Not Equals

Postby troyp » Thu Aug 23, 2012 8:35 am UTC

EvanED wrote:So I'm not saying my analogy isn't a bit of hyperbole, but I do think you can say the same thing about := and = vs = and ==. I think you'd get used to using i (or I) for int -- it'd be something you'd have to learn. I mean, you already have to learn that you type int instead of integer; it's just a matter of degree how abbreviated it'd be. Just like you have to learn that = isn't really = in the sense you're used to. In some ways, I think the = concept may even be harder to learn, because you have to break some degree of preconception about what it means.

Edit: think back to when you were learning your first C-like language... how easy was it to type if (a = b)? I think my first multi-hour debugging session was finding one of those. (Incidentally, that was what caused me to become an absolute freak about warnings. :-)) Sure, some of those bugs were just typos, probably including my big one, but I think a substantial contributor is thinking is "I want to test if a equals b, and = means equals; after all, that's what I've known since kindergarten or whatever".

That's a somewhat persuasive argument, although I do think it's specific to C-like languages. It depends on "assignment instead of equality" being a potentially trickier bug to find than vice versa (after all, a novice programmer is just as used to using = for assignment as for equality). These issues didn't come up so much for me, since I learned Python before C-like languages (and I haven't used the latter very much, anyway). Assignment is a statement in Python (one of the few cases of Python having reduced expressiveness compared to C), so using = in place of == is an simple syntax error. By the time I learned any C or C++, I was used to ==. For a beginning programmer, it would be a bit of a hazard. (It would help if the compiler would give a warning if you used a pure expression somewhere a statement was expected, like it's own line or the initialization statement of a for-loop. I'm sure there are static analysis tools that do so, but if the compiler did it on standard settings it would help novices with this sort of error.)

Of course, if you had := and =, people would be making the opposite error in that case, and having uninitialized variables in their programs. At least you get warnings for that if they're turned on, though (and I assume it can't happen at all in Java?)

Edit again: now that I think about it more, I think there are some parallels between = being assignment and calling kilo=2^10 instead of 10^3 etc. In both cases, comp sci people took a concept/notation/word that already had a well-defined meaning and applied it to a somewhat-related-but-actually-pretty-different concept in CS for the reason that it was convenient to. And in both cases, I pretty firmly think it was the wrong decision.


I think calling powers of two by standard prefix names is much worse. That's not just a notational convention in a specific language. It's corrupting standard scientific terminology throughout an entire industry.

Also, I'm not convinced that "=" for assignment is a different meaning. Assignment is really just the same as "let x = 2" (where the "let" is sometimes omitted). And the same symbol's used in both ways in math for a reason. It has the same core meaning in both cases, it's just in one case the condition is being set true and in the other case tested for truth. In that sense, they're kind of different moods of the same verb (equality being indicative and assignment imperative).

So go with I then, or something.

Urghh! It looks like an identity matrix or something. I'm starting to think you're not as attached to your single-letter variables as I am :-)

Роберт
Posts: 4285
Joined: Wed May 14, 2008 1:56 am UTC

Re: Not Equals

Postby Роберт » Thu Aug 23, 2012 2:37 pm UTC

ycc1988 wrote:

Code: Select all

int x <- 2;
if (x = 3) puts("WTF??");
if (x != 3) puts("OK");
if (x <- 3) puts("Why would anyone do this?");


The improbability of typing that last line will eliminate many programming bugs, I presume, as compared to the current C syntax:

Code: Select all

int x = 2;
if (x == 3) puts("WTF??");
if (x != 3) puts("OK");
if (x = 3) puts("Common programming mistake");

Code: Select all

if(x < -3) puts("unhandled error");
if(x <- 3) puts("WTF??");
if(x<-3) puts("uh-oh, which situation is this?")

<- would be absolutely terrible for assignment.
The Great Hippo wrote:[T]he way we treat suspected terrorists genuinely terrifies me.

User avatar
Yakk
Poster with most posts but no title.
Posts: 11047
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

Re: Not Equals

Postby Yakk » Thu Aug 23, 2012 2:54 pm UTC

:=, and ==.

If we wanted to be all nice[1], = can be the operator that acts like := or == depending on context. In a statement context, it acts as :=, and in an expression context, as ==.

[1] not actually nice.
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Thu Aug 23, 2012 3:39 pm UTC

troyp wrote:That's a somewhat persuasive argument, although I do think it's specific to C-like languages.

I don't agree here. I think other languages minimize the impact of = and == through means such as preventing assignments in conditions, but in a bit hyperbolic fashion I'd say that all they're doing is hiding the bad decision -- treating the symptom rather than the disease. (Of course, you might want to prohibit assignment in conditions for other reasons than "it's easy to accidentally put it there", so it'd also be reasonable to fix both problems.)

It depends on "assignment instead of equality" being a potentially trickier bug to find than vice versa (after all, a novice programmer is just as used to using = for assignment as for equality).

I disagree with this statement. I'll say more about this later, but personally I think that the only significant place where you'd have people committing the opposite bug is when they're coming from current languages that use = for assignment. (It's for this reason that I say I might go with Yakk's idea of := and == if I were to design a language, though I'm not sure. Like assignments in conditions, it would also be possible to mostly prevent the opposite bug through other syntactic restrictions, e.g. making a top-level expression a == b syntactically invalid. Unlike assignments in conditions, I would hyperbolically say that this decision is hiding the bad decisions made in other languages rather than this one. :-))

(It would help if the compiler would give a warning if you used a pure expression somewhere a statement was expected, like it's own line or the initialization statement of a for-loop. I'm sure there are static analysis tools that do so, but if the compiler did it on standard settings it would help novices with this sort of error.)

Really it's just a matter of the warning setting. MSVC does on /W4, but Visual Studio sets it at /W3 by default. (This statement is current as of, uh, VC6. :-) I didn't try it with newer ones, so it's possible that they shuffled around that warning.) GCC includes it in -Wall. (Also, cue my usual grumble about the GCC folks not knowing what "all" means. :))

Also, I'm not convinced that "=" for assignment is a different meaning. Assignment is really just the same as "let x = 2" (where the "let" is sometimes omitted).

I have two objections to this.

First, what about people who start programming before seeing maths that include such statements? (For instance, me.) I don't have any elementary school textbooks in front of me, but I suspect that things like "let x = 2" don't really show up until almost algebra.

Second, statements like let x = x + 1 I suspect are very rare within formal maths. At least in my experience, you'd see either (1) a new variable, (2) no "assignment" used and just x+1 in the future, or (3) in an iterated context, a subscripted version of x a la let xi+1 = xi + 1. My impression is that programming-style assignment where you change the value of an existing variable is seen as bad form.

Urghh! It looks like an identity matrix or something. I'm starting to think you're not as attached to your single-letter variables as I am :-)

Probably not. :-) But even if I was, I'd never use I as a variable name -- it starts with upper-case.

Derek
Posts: 2154
Joined: Wed Aug 18, 2010 4:15 am UTC

Re: Not Equals

Postby Derek » Thu Aug 23, 2012 5:25 pm UTC

I think it's worth noting that BASIC used = for both assignment and equality. Assignment wasn't allowed in comparisons so there was no conflict. I'll admit that in my QBASIC programming days I never really pushed the edge cases of potential ambiguity though.

I do think that assignments shouldn't have a return value, and therefore not be allowed in comparisons, or at least you should have a dedicated boolean type (that everything doesn't automatically cast to) to make it harder to make that mistake.

EvanED wrote:My impression is that programming-style assignment where you change the value of an existing variable is seen as bad form.

See pure-functional programming languages. In imperative languages it's actually quite common, although in most cases of simple arithmetic you can use one of the shortcut assignments.

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Thu Aug 23, 2012 5:49 pm UTC

Derek wrote:
EvanED wrote:My impression is that programming-style assignment where you change the value of an existing variable is seen as bad form.

See pure-functional programming languages. In imperative languages it's actually quite common, although in most cases of simple arithmetic you can use one of the shortcut assignments.

I'm talking about using programming-style assignment in math. Or said another way, math and pure functional languages agree on the the point that = isn't an assignment. :-)

webzter_again
Posts: 119
Joined: Sun May 27, 2012 4:37 am UTC

Re: Not Equals

Postby webzter_again » Thu Aug 23, 2012 6:17 pm UTC

F# (note, I'm an F# newb)

Code: Select all

> let a = 3
- a = 4

val a : int = 3

> let a = 3
- a <- 4

  a <- 4
  ^^^^^^

stdin(8,1): error FS0027: This value is not mutable

> let mutable a = 3
- a = 4

val mutable a : int = 3

> let mutable a = 3
- a <- 4

val mutable a : int = 4

> let a = 3
- let b = a + 1

val a : int = 3
val b : int = 4

> let isEven x =
-     if x % 2 = 0 then
-         "yes"
-     else
-         "no"
- let test = isEven 12

val isEven : int -> string
val test : string = "yes"

ycc1988
Posts: 28
Joined: Fri Jun 22, 2012 5:13 am UTC

Re: Not Equals

Postby ycc1988 » Thu Aug 23, 2012 6:37 pm UTC

I'd rather it be

Code: Select all

let a <- 3

rather than

Code: Select all

let a = 3

so that all assignment uses the same <- symbol.

I would love for ← to be on the keyboard, but unfortunately it isn't.

In response to Роберт, I guess since

Code: Select all

if (x <- 3)
makes no sense, there's no real ambiguity in that last case you mentioned. But I can see how it would be confusing to see <- develop 2 usages depending on whether an assignment or a comparison operator is expected.

Роберт
Posts: 4285
Joined: Wed May 14, 2008 1:56 am UTC

Re: Not Equals

Postby Роберт » Thu Aug 23, 2012 7:26 pm UTC

ycc1988 wrote:But I can see how it would be confusing to see <- develop 2 usages depending on whether an assignment or a comparison operator is expected.

It certainly seems more confusing than := would be.
The Great Hippo wrote:[T]he way we treat suspected terrorists genuinely terrifies me.

EvanED
Posts: 4324
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Not Equals

Postby EvanED » Thu Aug 23, 2012 7:26 pm UTC

ycc1988 wrote:In response to Роберт, I guess since

Code: Select all

if (x <- 3)
makes no sense...

I disagree with your assumption. While I disagree with the C approach (just replace = with <-), I definitely don't think you can say that it makes no sense.

Even if you take the Java approach and require that the condition of an if must be a Boolean (something I'm definitely in favor of but that's another discussion), it can still make sense if you say if (x <- true). (Though I guess comparison wouldn't in that case, so technically a language that allows assignment in expressions, requires Booleans in conditions, and uses <- for assignment would still be unambiguous.)

User avatar
ahammel
My Little Cabbage
Posts: 2135
Joined: Mon Jan 30, 2012 12:46 am UTC
Location: Vancouver BC
Contact:

Re: Not Equals

Postby ahammel » Thu Aug 23, 2012 8:37 pm UTC

Роберт wrote:

Code: Select all

if(x < -3) puts("unhandled error");
if(x <- 3) puts("WTF??");
if(x<-3) puts("uh-oh, which situation is this?")

<- would be absolutely terrible for assignment.
As mentioned, R has <- assignment. I fired it up to see how that works:

Code: Select all

> x <- 2
> if(x < -3) { print('This works as expected') }
# No output
> if(x <- 3) { print('Oh god why?') }
[1] "Oh god why?"
> if(x<-3) { print('You deserve this bug.') }
[1] "You deserve this bug."

I love R, but I also hate it with a fiery passion.
He/Him/His/Alex
God damn these electric sex pants!

troyp
Posts: 557
Joined: Thu May 22, 2008 9:20 pm UTC
Location: Lismore, NSW

Re: Not Equals

Postby troyp » Fri Aug 24, 2012 12:48 pm UTC

To be fair, this sort of situation, where you have to surround an operator with spaces to ensure correct parsing, is not that unusual. Which is not to say I think it's okay. It's ugly and tricky and should be a last resort. And I don't think it's usually necessary. The operators should be chosen to avoid ambiguity (usually - I don't mind in the case of unary minus, for instance*). For some languages, that might not be so easy (eg., Haskell, which has a shitload of operators, including arbitrary user-defined ones, plus a number of other uses of non-alphanumeric characters), but most languages only use modest number of operators and have every non-alphanumeric character except underscore available (for operators and other syntax), so there's really no excuse.

So I don't like <- as an operator in a typical language. But if assignment were a statement, I think it would work a lot better to require spaces around it. In that you wouldn't have (for example) an assignment parenthesized in the middle of a complex expression, where you might want to write it compactly. Plus, I find it less offensive to special-case a statement than an operator.

* Unless the language has an extremely regular syntax that needs to be preserved, eg. J, which uses _ as the negative sign in numeric literals

EvanED wrote:
troyp wrote:That's a somewhat persuasive argument, although I do think it's specific to C-like languages.

I don't agree here. I think other languages minimize the impact of = and == through means such as preventing assignments in conditions, but in a bit hyperbolic fashion I'd say that all they're doing is hiding the bad decision -- treating the symptom rather than the disease. (Of course, you might want to prohibit assignment in conditions for other reasons than "it's easy to accidentally put it there", so it'd also be reasonable to fix both problems.)

It depends on "assignment instead of equality" being a potentially trickier bug to find than vice versa (after all, a novice programmer is just as used to using = for assignment as for equality).

I disagree with this statement. I'll say more about this later, but personally I think that the only significant place where you'd have people committing the opposite bug is when they're coming from current languages that use = for assignment. (It's for this reason that I say I might go with Yakk's idea of := and == if I were to design a language, though I'm not sure. Like assignments in conditions, it would also be possible to mostly prevent the opposite bug through other syntactic restrictions, e.g. making a top-level expression a == b syntactically invalid. Unlike assignments in conditions, I would hyperbolically say that this decision is hiding the bad decisions made in other languages rather than this one. :-))

I have to admit, I didn't really question my assumptions about this. Considering more carefully, I'm inclined to agree with you, and your observation that we're used to = as equality from arithmetic from a young age, well before we encounter algebra, adds further weight to the argument.

Second, statements like let x = x + 1 I suspect are very rare within formal maths. At least in my experience, you'd see either (1) a new variable, (2) no "assignment" used and just x+1 in the future, or (3) in an iterated context, a subscripted version of x a la let xi+1 = xi + 1. My impression is that programming-style assignment where you change the value of an existing variable is seen as bad form.

I accept this as an argument that = as assignment is unintuitive, but I don't think it detracts from my claim that assignment is basically the imperative mood of equality.

I think the reason you don't see this sort of statement in math is just that math is usually based on a declarative approach, whereas reassignment is inherently imperative (in PL terms now, not just grammatical*). In that sense, math is more like FPLs, which don't permit reassignment either (unless you count rebinding a variable, which math does too). When math does need to describe things imperatively, it either (1) uses natural language, possibly augmented with bits of declarative math (classical description of algorithms), (2) uses pseudocode or an actual PL (modern description of algorithms) or (3) convert the imperative description into declarative form (simple cases, like converting a loop into recursive sequence).

* There is clearly a strong similarity between the imperative/declarative distinction in programming and the imperative/indicative distinction in grammar. You could claim that in a declarative approach you don't really have statements that are grammatically imperative: that declarative assignment is not really setting a variable, but rather asserting the truth of an equality. That's true in some sense, but the fact remains that you're still "setting" or "fixing" something. An assignment is not a statement of what is already true, nor a question. It is instructing the system to make something true. So I'd say that assignment in declarative programming is grammatically imperative. Which is unfortunate, terminologically - hence this footnote to clarify.

Urghh! It looks like an identity matrix or something. I'm starting to think you're not as attached to your single-letter variables as I am :-)

Probably not. :-) But even if I was, I'd never use I as a variable name -- it starts with upper-case.

Although I usually reserve initial uppercase for things like classes, I'm (slightly reluctantly) willing to except single-letter identifiers. It's not like I usually want a single letter class name anyway. Of course, that decision depends on several things, most of all whether the language will even allow me to use a capitalized identifier for a variable.


General thoughts on operator naming and syntax and the need for standardized transformations:
I mentioned above, that it would be nice if editors/IDEs would substitute unicode symbols for things like !=. I'd go further and say it would be awesome if there was some kind of standard markup language for specifying stylistic variants of a language. It would (a) control transformation of a programmer's input into valid source code; and (b) control the display of source code, like a CSS for PLs.

The input transformation part would be a some kind of simple source code transformation system. Nothing sophisticated, that you'd use for metaprogramming or code generation; it would just permit simple cosmetic changes that could be used to create stylistic variants. Things like changing unpopular operators, converting between significant indentation and braces, "literate" syntax, etc.

In many cases the output transformations would just be the inverse of the input transformations, but there could be differences, eg. "snippet"-like capabilities could be added, where you type an abbreviation and see the full text appear. Beyond the core capabilities, there would be additional possibilities for output beyond plain text. eg. substituting images for certain operators, or enclosing block comments in coloured boxes. There could be additional "plugins": composable transformations that could be applied afterwards for custom output, like an output transformation to produce HTML output displaying the source with syntax highlighting.

There would be a standard tool, like a macro processor, to handle the textual transformations, and additional tools for other kinds of outputs. Editors/IDEs could make use of these or implement the functionality themselves. Ideally, they would all support the text transforms and offer varying support for graphical and other output. Each tool would have it's own approach for handling integration and user interaction. Some may perform transformations when you press a button, others on the fly, with support for highlighting graphical output and having the textual source copied to clipboard. And so on.

I think some sort of system like this would really help to provide both languages and tools with some basic flexibility they could take for granted, without having to worry about decisions that should be trivial and in the user's hands. So if := and == are least confusing for assignment and equality, you could just use them, and people who want the easier-to-type = could just use the trivial =-to-:= stylesheet. Similarly with Python3 deprecating <> for inequality. We'd still have these sort of debates on forums, but hopefully they could stay off development mailing lists, at least.

ycc1988
Posts: 28
Joined: Fri Jun 22, 2012 5:13 am UTC

Re: Not Equals

Postby ycc1988 » Sat Aug 25, 2012 4:16 pm UTC

Let's write all our algorithms in LaTeX and use \gets for assignment. Making the answer to this thread's original question \neq.


Return to “Religious Wars”

Who is online

Users browsing this forum: No registered users and 2 guests