Not Equals

[Sizik]

There are many ways to represent ≠ in ASCII, but not all were created equal. If they were, that would defeat the purpose.

[Elench]

Either ≠ or ¬= here.

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

[EvanED]

Either ≠ or ¬= here.

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

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

[ycc1988]

/= 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]

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.

[Роберт]

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.

[EvanED]

~= 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. )

[Роберт]

~= 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 ><?

[phlip]

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.

[Роберт]

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?

[Grimgar]

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]

!= 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.

[sourmìlk]

I don't actually have much of a problem with =/=, but I prefer != for the aforementioned reasons.

[troyp]

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 λ.

[ahammel]

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.

[sourmìlk]

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

[ahammel]

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?

Although I wouldn't mind a <- operator or something.

R has that. I think a few languages us := as well.

[EvanED]

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

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]

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 (<=, >=, !=, &&, ||).

[Yakk]

I prefer := for assignment and == for comparison.

[EvanED]

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 >.

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.

[Роберт]

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.

[webzter_again]

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]

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]

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

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

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]

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 ==.

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]

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]

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

[Роберт]

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.

[Yakk]

:=, 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.

[EvanED]

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 x_i+1 = x_i + 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]

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.

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]

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]

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]

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.

[Роберт]

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.

[EvanED]

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.)

[ahammel]

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.

[troyp]

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

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 x_i+1 = x_i + 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]

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