24 ms·

Why Does “=” Mean Assignment?

• agumonkey 8y ago
  more broadly, why schools are merging reduction and equality in arithmetic ?
  • jwilk 8y ago
    What do you mean?
    • agumonkey 8y ago
      in primary school the focus in expressions involving = is reduction more than equality: 2 + 2 = 4 <n terms> = <constant> I don't recall teacher showing you equalness through stupid but important ideas: 2 + 2 = 2 + 2 2 + 2 = 2 + 1 + 1 all these are equal, and it's important later on when expression, with variables, aren't reducible to a constant but to another expression which is equal to the other one. IMO it would help a lot for people to try to simplify a problem into a known identity or interesting form (for instance the 'trick' of adding and subtracting one to get closer to binomial formula or other)
• slededit 8y ago
  The '=' sign is used because after that statement the variable will indeed have equality with the r-value. Coincidentally in async languages like Verilog there is a another assignment operator '<=' which means that the variable won't take the new value until the next clock cycle (or more explicitly the next evaluation of the process block). '=' exists also and has the same meaning as with traditional languages.
  • paulddraper 8y ago
    By that logic, a <= 1 Should set a to the minimum of a and 1. I.e. after that statement the variable will indeed be less than or equal to the RHS.
    • slededit 8y ago
      Languages borrowing the syntax don't need to follow its logical consistency. I just thought it was an interesting anecdote.
  • deleted 8y ago
    [deleted]
  • lionel- 8y ago
    What about `a = a + 1`?
    • slededit 8y ago
      The r-value is ephemeral it doesn't exist once the statement ends.
• sideshowb 8y ago
  Bcpl still exists in 2018?
  • careersuicide 8y ago
    It does! Even though, Martin Richards' homepage [0] hasn't been updated in a while you can try it out with a small amount of fuss [1]. 0: http://www.cl.cam.ac.uk/~mr10/ http://www.cl.cam.ac.uk/~mr10/ 1: https://gist.github.com/seaneshbaugh/e09abd748ccc07c5463f253df97e4de8 https://gist.github.com/seaneshbaugh/e09abd748ccc07c5463f253....
  • hwayne 8y ago
    Here's a PDF about running BCPL on a Raspberry Pi: http://www.cl.cam.ac.uk/~mr10/bcpl4raspi.pdf http://www.cl.cam.ac.uk/~mr10/bcpl4raspi.pdf It's aimed at teaching programming to 10 year olds no prior experience. One of the first examples is implementing RSA.
    • thedirt0115 8y ago
      Implementing a cryptosystem is one of the first things for 10 year olds with no prior programming experience???? That seems intense compared to Scratch, etc.
      • jandrese 8y ago
        The math is pretty straightforward. I assume they aren't implementing all of the surrounding logic that makes crypto such a bear.
        • thedirt0115 8y ago
          I don’t mean so much that it’s super difficult, I’m just imagining that 10-year-olds would rather be making pictures move around on the screen over doing a math thing that they might not yet understand the importance of. I could be wrong, it’s been quite a while since I was 10 :) I was trying to imagine 10-year-old me reading that section about RSA in the thing they linked to.
• nailer 8y ago
  Because programming languages are typically designed for the tiny group of existing programmers than the much larger group of future programmers. The same reason unnecessary tokens exist, and 'drop' means delete in databases. It's entirely cultural.
  • protomyth 8y ago
    Technically, DROP is used because DELETE is taken by something that deletes rows and using DELETE for tables and rows is a bit scary so you get DROP. I suspect quite a lot of naming happens that way.
    • pbhjpbhj 8y ago
      I'd have thought, not being a programmer, that drop was used because whilst the access and relations with the drop-ed table are updated the table isn't necessarily deleted. Drop updates the logical structure without necessarily acting on the physical storage in a way commensurate with "deletion". You can this drop a million tuple table in a ms (less I expect) whilst deletion would take far, far longer (of the order of a million-times longer). /guessing
  • dragonwriter 8y ago
    > 'drop' means delete in databases DROP doesn't mean DELETE. DROP <object-type> <object-name> is sort of like a macro for, loosely DELETE FROM <catalog-relvar-for-object-type> WHERE name = <object-name> Except that real RDBMSs don't usually have DDL that is really equivalent to DML against system tables, and particularly (esp historically, but still in many years DBs), DDL has a different relation to transaction processing than DML, so it's a very good thing for clarity and developer intuition to not overload DML keywords for DDL operations, despite the loose similarity between CREATE/DROP in DDL and INSERT/DELETE in DML.
    • nailer 8y ago
      It does according to your next sentence.
  • 8y ago
• User23 8y ago
  Because K&R had terrible keyboards so they abbreviated everything as much as possible. Traditionally := was used for assignment, which makes sense since it is an asymmetric symbol for an asymmetric operation.
  • jghn 8y ago
    There’s also <-, most commonly seen in R but draws it’s heritage from the APL keyboard
    • nfoz 8y ago
      Fun fact, R also has -> (assign to the RHS instead of LHS), and "super-assignment" <<- and ->>, and also can use = sometimes too (and I think has different semantics). Yay R.
      • bllguo 8y ago
        I write R daily and have always used = for convenience. I can count on 0 hands how many times that has affected me. <<- has its uses though!
        • bachmeier 8y ago
          FWIW, that's what Ross Ihaka does as well (or at least did in a presentation that I watched - and pointed out that you can use = for assignment). Personally, I think = for assignment is a disaster, and wish I could use <- and -> in every language.
          • neuxenian 8y ago
            I've used R since it was in beta form, and one of the most interesting things to me (aside from the evolution of type hierarchy) has been changes in use of the assignment operator. When I started, = was the norm for assignment, with == for evaluating equality. Later I started noticing that people were recommending <- based on scope concerns, but it was kind of subjective preference. Now I see articles like this saying that the "preferred use" is <-, and some people don't even know about =. I agree = versus == can lead to tricky errors in code, but I still prefer = for various reasons in general in languages (although I get the scope arguments). The reason is that = is shorter, and assignment is an definitional equality, which to my impression is the whole point of programming in general usually. As others have suggested here, between = and ==, = is by far the more commonly used operator in meaning, so to me it makes sense to use = for succinctness. In math, there is an "equal by definition" operator, with three lines, so I could see that, but keyboards don't have that, so it's more steps. := is also a kind of standard "by definition" usage as discussed in the article, but again, it's more steps. I'd still prefer that over <- in R.
• tomxor 8y ago
  About once every year I have a brain fart on a sleepy morning and confuse myself by using = for comparitors and or == for assignment... shortly followed by "Nnarhh". [edit] :P LOL at downvotes, HN is no place for silly annecdotes "this is serious things we dooo".
  • astrobe_ 8y ago
    There are better places if you just want to talk about yourself.
    • tomxor 8y ago
      > There are better places if you just want to talk about yourself. hmm, I don't agree with what you are implying defines acceptable comment content on HN. There are many if not a majority of comments highly rated on HN which are highly personal that necessarily talk about themselves, it's part of what makes those comments interesting, if we all commented like wikipedia articles it would be a dull place indeed. My comment maybe flawed in the eyes of other HN readers, but not for the reason you have highlighted. In my case it's is both personal and relevant but to be honest - not interesting or insightful which is probably why someone mean enough gave me a downvote... but then afterwards I broke the "first rule of fight club" which on HN is equivalent to throwing yourself to the wolves, I accept that, and also can't help it, it's just my nature, I don't self censor for points.
    • dang 8y ago
      Come now, that's not nice. It's fine to talk about one's experiences on HN. That's what people do in conversation.
• AdmiralAsshat 8y ago
  Well that at least gives me a good idea of why `:=` cropped up in Go. Having never studied anything older than C, it caught me by surprise.
  • taborj 8y ago
    Also used in Pascal for the same purpose.
    • emodendroket 8y ago
      Also Visual Basic.
      • jwilk 8y ago
        No? VB uses = for assigment, just like other Basics.
        • emodendroket 8y ago
          It uses := for named arguments.
• rdtsc 8y ago
  Another interesting way to think about it is as "match". That is try to match the stuff on the right with the stuff on the left. Take Erlang for example: 1> X = 1. 1 2> X = 2. ** exception error: no match of right hand side value 2 Notice variables are immutable (not just values themselves). Once X becomes 1, it can only match with 1 after that. You might think this is silly or annoying, why not just allow reassignment and instead have to sprinkle X1, X2 everywhere. But it turns out is can be nice because it makes state updates very explicit. In complicated applications that helps understand what is happening. And it behaves like you'd expect in math, in the sense that X = X + 1 doesn't make sense here either: 1> X = 1. 1 2> X = X + 1. ** exception error: no match of right hand side value 2 3> It does pattern matching very well too, that is, it matches based on the shape of data: 1> {X,Y} = {1,2}. {1,2} 2> X. 1 3> Y. 2 4> In other languages we might say we have assignment and destructuring but here it is rather simple it's just pattern matching.
  • icebraining 8y ago
    Prolog's unification: X = Y, X = 5, %% Y = 5 now as well -- ?- append([1,2], Y, [1,2,3]). Y = [3].
    • OskarS 8y ago
      Yeah, Prolog's unification operator really blows your mind the first few times you experience it. You left the best part out of that last example: ?- append(X, Y, [1,2,3]). X = [], Y = [1, 2, 3] ; X = [1], Y = [2, 3] ; X = [1, 2], Y = [3] ; X = [1, 2, 3], Y = [] ; false. (a few newlines added for clarity)
  • macintux 8y ago
    I'm sure I've mentioned it here before, but in my favorite Erlang talk I design the language with the equal sign as my core construct. Since the equal sign is an assertion of truth, and since assertions cause a crash on failure, you can pretty much derive the rest of the language/BEAM characteristics from that.
• bhaak 8y ago
  > Since assignment is about twice as frequent as equality testing in typical programs, it’s appropriate that the operator be half as long. Ken Thompson on why '=' is assignment and '==' the equality check. It's this kind of mindset that puts me off Go. But I can totally see that many who want a better C getting into Go exactly for reasons like this.
  • raverbashing 8y ago
    But := is not "assignment" per se in Go, it is 'declare and assign'. Something like auto x = 2; in modern C++ (or C#); If you declare a variable, then x = 2; works in Go.
  • mikekchar 8y ago
    I'm not sure what you find disquieting about the idea. "More frequently used operators should be less verbose" seems reasonable to me. What I find a bit strange about Go is that if they have that mindset then it's still a fairly verbose language, syntactically -- at least compared to some other modern languages. It seems to hang on to the familiarity of C syntax with a few optimisations. Which, of course, is not necessarily a bad thing at all. It's just not doing everything it can to reduce verbosity.
    • bhaak 8y ago
      > "More frequently used operators should be less verbose" seems reasonable to me. Syntax that looks pretty in isolation is a poor design guideline for programming language design. It ignores the problems of writing and debugging this code. I don't know how many bugs went unnoticed because of the "if (a = b)" mistake but it certainly weren't few. Sure, nowadays the compiler warns you about that but that took surprisingly long to be implemented. The argument for saving a few keystrokes for potential longer debugging sessions is not a good argument. Code is much more often read than it is written. But I didn't criticize Go's verbosity (after all, they "fixed" the assignment thin) but the mindset of doing or not doing things for specific reasons that look quite backwards for today (or let me be frank, just plain stupid) but the community then fights with vigorously for this. There are examples for that in the design of the language but the most egregious example of this is the package manager. This went from "we don't needs this" over "do it in this problematic way" over "let's do it like anybody else" to now "no, we are special, we need to do it completely differently". IMO, Go would have been a fantastic language to have in the 90s. But looking at it from today's perspective, it looks outdated in many places. But compared to C which is a language of the 70s it is still great and therefore I understand its appeal for programmers who haven't found another language to replace C with (going from my own experience, most programmers have replaced C with multiple languages instead of just one).
• abakus 8y ago
  The length of symbols should roughly be negatively correlated with its frequency. Since in procedural language, assignment is a much more common operation than equality check, it is reasonable to favor "=" over ":=" or even "<-".
  • pbhjpbhj 8y ago
    So you have a key with the assignment operator on.
  • jfoutz 8y ago
    also, there's no hand balance on either of the composite symbols. := is my right pinky, <- is different fingers, but bottom and top row. neither exactly flows from the fingertips.
    • neaden 8y ago
      I don't think that is a big issue. Just bind it to something else. In RStudio by default <- is bound to alt and -.
      • abakus 8y ago
        But that is still 2 keystrokes. That is why in R they came to the compromise to use both <- and =.
        • ryanmonroe 8y ago
          Well, it also adds a space before and after so you're saving one keystroke vs space = space
  • deleted 8y ago
    [deleted]
  • roselan 8y ago
    What does prevent : to become the assignment operator of a language? It's short, and quite "explicit". x: 2
• ken 8y ago
  I don't understand the LISP line at all. I would have said "LET", "SET", and "EQUAL" (since it's talking about numbers). Is there something I'm missing? EDIT: It's since been changed to "let", "set", "equal" (but still lower-case).
  • mst 8y ago
    The article's been updated.
  • EdwardCoffin 8y ago
    I don't understand it either. I suspect the author does not know Lisp, and badly misunderstood an explanation from someone who does. I think that Lisp doesn't even fit well into that table, since putting LET in the first column would implicitly bring in declaration as well, much of the time SET in the second column would be misleading since mutation is so often done implicitly by a looping construct like DO, DOLIST, DOTIMES or whatever (no SET in sight), and there are all sorts of equality tests one could use. Edit: ok, I see the author has both updated it, and is specifically talking about Lisp 1.5 which does not have the looping constructs. On the other hand, it at least has a bunch of alternatives to SET that probably should be listed as well, like RPLACA, RPLACD, ATTRIB, and so on. I think that even in Lisp 1.5 variables could be declared in different ways to using LET (like rebinding a variable passed in to a function, so the assignment was in invocation).
    • ken 8y ago
      It's not a perfect correspondence, but I think the point is simply to show that back in the 1950's, there was no consensus yet on how assignment ought to look. It just happens that there was no consensus yet on how it should work, yet, either! Then again, neither of the last 2 (modern) programming languages I've used have had FORTRAN/ALGOL-style assignment semantics, so I think the jury's still out.
• cosmotron 8y ago
  I actually rationalized the '=' symbol in assignment into the following statement, "Let 'left hand side' be equal to 'right hand side'". Using this wording resolves some dissonance around its overloaded usage.
  • amyjess 8y ago
    Ditto. Fun fact: various dialects of BASIC let you optionally put LET before your assignment statements. So the following are equivalent: X = 10 LET X = 10
    • joezydeco 8y ago
      Wait...LET was optional? Auigh! Whole months of my childhood, wasted!
      • Doctor_Fegg 8y ago
        Depends on the dialect. It was mandatory on the Sinclair BASICs, for example (ZX81/ZX Spectrum), but optional on the Amstrad (Locomotive/Mallard) and BBC BASICs. A quick search suggests it was optional as early as "MicroSoft"'s Altair BASIC: http://swtpc.com/mholley/Altair/BasicLanguage.pdf http://swtpc.com/mholley/Altair/BasicLanguage.pdf As someone who learned first on a ZX81, I'd always assumed that "LET X=5" was the canonical form, and that "X=5" for assignment was just a shortening for convenience.
        • jameshart 8y ago
          Likewise - but of course in Sinclair BASIC it was mandatory because every command had to begin with a keyword - a fact enforced by the fact that the cursor started out as a flashing [K], and every key on the keyboard was mapped to directly enter a keyword in that mode. LET was on the 'L' key. You literally couldn't type "a = 1" into a Spectrum/ZX81 - you couldn't type an 'a' unless you were at an [L] cursor prompt, which would only appear after you had chosen a keyword. Typing an 'a' at a [K] cursor would get you the keyword NEW. I wonder if you, like me, were also completely thrown when you first encountered a programming language where you didn't also have to enter line numbers...
• deleted 8y ago
  [deleted]
• reaperducer 8y ago
  You'll have to pry my BCPL heffalumps out of my cold, dead hands. The operator " = >" (pronounced "heffalump") is convenient for referencing structures that are accessed indirectly. The expression a=>s.x is equivalent to the expression (@a)»s.x. Source: https://archive.org/stream/bitsavers_xeroxaltobualSep79_5187659/BCPL_Reference_Manual_Sep79_djvu.txt https://archive.org/stream/bitsavers_xeroxaltobualSep79_5187...
• mavhc 8y ago
  Is it really worth allowing assignment in places so weird that you also need ==? Wouldn't it be easier to use = for everything and get rid of those weird edge cases?
  • walshemj 8y ago
    Or you know use different operators entirely
  • nfoz 8y ago
    Yeah I was pretty surprised when I found out that assignment and equality can be totally syntactically separate and nonambiguous with miminal language-design effort. Just get rid of the silly idea of allowing expressions as statements. Although even then it's nice to use different symbols because they are different meanings. I don't like it when a word has different meanings depending on context.
    • icebraining 8y ago
      Just get rid of the silly idea of allowing expressions as statements. I don't think that's enough. Take the two following Python lines: a = b = c == d a = b == c == d No expression is being used as a statement, yet you can't syntactically separate assignment from equality.
      • boomlinde 8y ago
        I think GP might have meant that to go the other way around, i.e. don't allow statements to also be expressions, and more specifically, make assignment a statement.
        • nfoz 8y ago
          Well first I was super intriguied by the example. But I agree with your conclusion, that statements should not also be expressions, so a = b = c shouldn't work (at least not the way we're used to, that the b = c is an assignment "statement" that also produces an expression value). But in the end all this does is allow "a = b = c" to be a nonambiguous statement meaning, in more familiar notation, "a = b == c". Not exactly clear! So even though a language could use the same symbol for both assignment and equality-check, I don't recommend it! Although I still like to keep statements and expressions as strictly non-interchangeable constructs.
• open-source-ux 8y ago
  Here's what Niklaus Wirth (Pascal, Modula-2, Oberon) said about using the equal sign for assignment: > A notorious example for a bad idea was the choice of the equal sign to denote assignment. It goes back to Fortran in 1957 and has blindly been copied by armies of language designers. Why is it a bad idea? Because it overthrows a century old tradition to let “=” denote a comparison for equality, a predicate which is either true or false. But Fortran made it to mean assignment, the enforcing of equality. In this case, the operands are on unequal footing: The left operand (a variable) is to be made equal to the right operand (an expression). x = y does not mean the same thing as y = x. Algol corrected this mistake by the simple solution: Let assignment be denoted by “:=”. > Perhaps this may appear as nitpicking to programmers who got used to the equal sign meaning assignment. But mixing up assignment and comparison is a truly bad idea, because it requires that another symbol be used for what traditionally was expressed by the equal sign. Comparison for equality became denoted by the two characters “==” (first in C). This is a consequence of the ugly kind, and it gave rise to similar bad ideas using “++”, “--“, “&&” etc. From Good ideas, through the Looking Glass by N. Wirth: https://www.semanticscholar.org/paper/Good-Ideas%2C-through-the-Looking-Glass-Wirth/10bddc49b85196aaa6715dd46843d9dcffa38358 https://www.semanticscholar.org/paper/Good-Ideas%2C-through-...
  • akira2501 8y ago
    > Because it overthrows a century old tradition And if the goal of mathematicians and programmers were the same, this might be a compelling argument. In no sense do I see my programs as giant algorithms, they're machines, and as such require different syntax to construct. > But mixing up assignment and comparison is a truly bad idea Then := is also a bad decision. You should use the fully historically supported form of 'let <variable> = <value>'. Both := and == suffer from the fact that if you omit a single character, you change assignment into comparison or vice versa. It strikes me as a nitpicky argument for it's own sake.
    • TimJYoung 8y ago
      You're missing the point - languages like Pascal have a := assignment operator because the = operator is for comparison only. If you accidentally drop the :, then you have a simple Boolean expression. If this Boolean expression is used as a statement, by itself, then the result is a compiler error.
• msla 8y ago
  Because ASCII had already replaced the ← with the _, something which made PIP somewhat harder to use, as this: PIP destination←source /switches became this: PIP destination=source or this: PIP destination_source https://en.wikipedia.org/wiki/Peripheral_Interchange_Program https://en.wikipedia.org/wiki/Peripheral_Interchange_Program
• benatkin 8y ago
  I like = for assignment, but I don't like it for configuration. HCL and TOML chose it, to their detriment, I think. When it reads as "let x equal y" it makes sense. I think it makes good sense for imperative programming. It makes slightly less sense for functional programming. For declarative configuration, I think a colon makes much more sense.
• russellbeattie 8y ago
  I've been programming professionally for 25 years using mostly C inspired languages, and I will still regularly write "if(foo = bar)" on a daily basis and not notice until there's an error. It's easily the most common syntax error I write, followed closely by using commas in my for-loop as apparently it looks like a function to my fingers: "for(x=0, x<10, x++)"
  • dotancohen 8y ago
    Which IDE so you use? Even VIM has plugins to warn on assignment in an if() statement.
  • jandrese 8y ago
    Don't compilers warn about assignment inside of conditionals now?
    • gumby 8y ago
      In C++17 not only can you do assignment in the conditional, you can declare new variables which have the scope of the then and else clauses. But yes, most compilers will catch this case.
      • gowld 8y ago
        The compiler warns unless you add an extra () around the assignment to signal that you mean it.
    • OskarS 8y ago
      It's used often enough in loops like this: while (v = next()) { ... } or, perhaps more usefully: while ((v = next()) != ERROR) { ... } EDIT: just did a quick check, and LLVM did in fact warn me about this: if (x = 4) { ... } To silence the error, you have to double up on the parenthesis, which I guess is a reasonable enough solution: if ((x = 4)) { ... }
  • ben509 8y ago
    Same here. I have flycheck running a linter, so I catch it a bit quicker, but single = is my single most common typo.
• mortdeus 8y ago
  because in math it means assignment. y = mx+b That is an assignment. There is also a math symbol that specifically designates equivalence.
  • heinrichhartman 8y ago
    No. It does not.
  • tomjakubowski 8y ago
    I sympathize with this view; I did some simple programming in C-like languages before I learned algebra, and it's sometimes hard to not see = this way. But if = in math notation denoted "assignment", what could ≠ mean?
    • ben509 8y ago
      Maybe lhs = rhs is the set of assignments implied by a postcondition. So x = 5 implies a single assignment, but x = ±5 could mean two possible assignments. Similarly, x ≠ 5 would mean all the possible assignments but x = 5.
      • smadge 8y ago
        Equality is symmetric. If lhs = rhs then rhs = lhs. x ≠ 5 means exactly that, x is anything that is not 5. So if you are talking about the natural numbers, x could be any element of the set {0, 1, 2, 3, 4, 6, 7, ...}. If x = ±5 then x could be any element of the set {-5, 5}.
  • qntty 8y ago
    The concept of assignment only makes sense in a context with a time axis. Computation has a time axis (location of the instruction pointer) but math does not.
    • YOrlandoLO 8y ago
      Nope. Logical axioms are required logically, but not associated with time. Comprehension is associated with time, so I can understand how you might arrive where you did.
• Asooka 8y ago
  I always read it with an implied "let" in front, so it has always sounded completely natural. It's also ergonomic to type, easy to read and while you can confuse := and = on account of : being a small glyph even in monospace fonts - you can mistake it for empty space if you're just skimming, == and = are harder to confuse since one is twice as long as the other.
• dboreham 8y ago
  Should be -> Or perhaps <-
  • smadge 8y ago
    I would definitely prefer ‘destination <- source’ as it reflects the actual flow of data.
    • tom_mellior 8y ago
      In what way would 'source -> destination' not reflect the "actual" flow of data?
      • smadge 8y ago
        I would be ok with that too! I must have misinterpreted dboreham as suggesting destination -> source Which is very confusing to me.
        • dboreham 8y ago
          The arrow always reflects the direction of flow. Difference is just whether you like to have destination first or last. Basically are you Motorola or Intel..
• Itaxpica 8y ago
  A coworker of mine once referred to := as the 'Zoidberg operator', and the name has stuck with me since.
  • pedro_hab 8y ago
    hehe, you are right, I can only see it now tho
  • pxmpxm 8y ago
    Cannot unsee.
  • aaron_m04 8y ago
    At first I thought you meant "why not colon-equals?" but now I see it (literally).
  • bwldrbst 8y ago
    How about :≡ ?
    • chrisan 8y ago
      thats the logically equivalent zoidberg operator
• emodendroket 8y ago
  I've always had the notion that if I made a language I'd make the operators := and == so it'd be harder to accidentally use the wrong one.
  • pbhjpbhj 8y ago
    Wouldn't : and = make it equally (heh!) hard to use the wrong operator notation?
    • klez 8y ago
      Using == and := would guarantee you never accidentally use = by itself (out of habit from other languages) because that's not a valid operator.
• tom_mellior 8y ago
  > Prolog came out the same year as C and popularized logic programming, and you can sort of fake assignment with cuts. Can anyone explain to me what this is supposed to mean? (I know Prolog, I understand cuts very well. But I don't know what the author means here.)
  • hwayne 8y ago
    It means I don't understand Prolog very well and really shouldn't have namedropped it :P
    • triska 8y ago
      Prolog is a good example of a language where "=" doesn't mean assignment. In Prolog, "=" means unification: You can read X = Y (which is =(X, Y) in functional notation) as: "True iff X and Y are unifiable". You can think of unification as a generalization of pattern matching. For example, f(X, b) is unifiable with f(a, Y) by the substitution {X → a, Y → b}. I think this aspect would be a valuable addition to the article. Fun fact: If (=)/2 were not available as a built-in predicate in Prolog, you could define it by a single fact: X = X. Thus, you do not even need this predicate as a predefined part of the language.
• epx 8y ago
  I've always preferred the Pascal's :=
• usernum3hundred 8y ago
  this might not be fact but I like to think that the colon in := might have been dropped just like diacritic symbols were dropped from the English alphabets. I am not a native English speaker so I had similar issues learning the English script. It was particularly hard to grasp things like why 'do' and 'go' are pronounced differently. But overtime I released that eliminating extra characters reduces a lot of unnecessary complexity and makes your writing faster.
• nostalgeek 8y ago
  Well Ada uses := for affectation and = for actual equality. In pure algorithmic notation, people might use <- or <= instead.
• cup-of-tea 8y ago
  It isn't just mathematically unsound, it's the cause of many errors, especially in C. Certainly a "million dollar mistake". A classic way to guard against accidental use of assignment in logic statements is to write it "backwards", i.e.: if (2 == x) {...} Since (2 = x) won't compile, while (x = 2) will not only compile but might appear to work for a very long time.
  • jwilk 8y ago
    https://en.wikipedia.org/wiki/Yoda_conditions https://en.wikipedia.org/wiki/Yoda_conditions
  • v_lisivka 8y ago
    It's better to use -Wall -Werror options for C compiler.
    • ben509 8y ago
      Agreed, fix the tools, not the person. Really, any source you have control over should have all error checking possible turned on and breaking immediately, _especially_ with C derivatives.
    • cup-of-tea 8y ago
      That won't always catch the error and even if it did, why is it better?
      • ben509 8y ago
        -Wall can almost always catch the problem as it will insist on redundant parens surrounding an assignment. So you can only screw it up if you typed extra parens for an equality expression. Variable on left is conventional, it's how people sound it out in their head, so it's just easier to process mentally when the expression becomes more complex. Yoda syntax catches that single error at the expense of making all equality expressions harder to write, read and maintain. And, besides, if you're going to use Yoda syntax, you're going to want your linter to enforce it... at which point you may as well turn on -Wall anyway.
• rootedbox 8y ago
  Pascal got rid of the confusion.. := is assignment = is comparison. I really wish more languages had an specific assignment operator.
  • Taniwha 8y ago
    I think Pascal got all that from Algol68 (which in turn got stuff from Algol60) (Pascal is essentially the easy bits to implement from Algol68)
• danans 8y ago
  The Go language brings back the ":=" to mean declare and assign, while inferring type. a := 5 You can also equivalently do var a = 5 I almost never use the latter within functions (only at module scope). I believe the former is forbidden except within functions.
  • munk-a 8y ago
    I'm not a big fan of this decision by golang, with the frequency of multi-assignment happening in common code make this awkward. Specifically: var a = 5 a, b := 2, 3
  • jug 8y ago
    I was puzzled by this decision of theirs though. They are so hell bent on keeping the language as simple as possible with a minimum of keywords, but apparently can't be arsed to just write var a = 5 like normal people, but prefer to invent a whole new operator for it. Operators are often demanding even more of a reason to exist than keywords. Then you also get the operator inconcistency between "assigning to a new variable" and "assigning to an existing variable" and is it so important to tell the two apart from within an operator, of all things? When writing Go, I have been way more inconvenienced by its error handling mechanics than having to tell that I want a new variable using a few more characters.
• antoineMoPa 8y ago
  TI-Basic, which I used on my TI-84 plus used ':=' for assignments like ALGOL. https://en.wikipedia.org/wiki/TI-BASIC https://en.wikipedia.org/wiki/TI-BASIC
• robotresearcher 8y ago
  I always liked Pop11's assignment syntax: 1 => x [ 10 11 12 13 ] => mylist Reads and evaluates left to right. C seems backwards after that. (Also LISP-type lists without commas).
• rootbear 8y ago
  During the public comment period for the original ANSI C standard, we had at least one request to add ":=" as an alternate assignment operator. We declined, but I personally would have supported that. The use of = and == is one of my least favorite bits of C syntax.
  • rootbear 8y ago
    These days, I suppose we could add the Unicode character for := ≔ U+2254 COLON EQUALS and there is also ⩵ U+2A75 TWO CONSECUTIVE EQUALS SIGNS if you find typing two = characters fatiguing...
• dkrich 8y ago
  I always liked DHH's take on these sorts of arguments (paraphrasing): who the hell cares? Once you know the purpose of the '=' how often do you make mistakes reading or writing code? Whereas Java is all about protecting developers from themselves, Ruby (for example) let's you get away without variable type declaration because at the end of the day, how often do you not know whether a particular variable is a string or an integer? Enough to justify enforcing declaring everything at the outset or receiving errors throughout your code? That's not to say that those enforcements never make sense. I think that structured languages like Java are better for larger teams where enforcing standards is more important than a smaller team. But there are other ways to do that and a lot of time the rules make development a horrible experience.
  • AdeptusAquinas 8y ago
    I prefer to take the middle ground: implicit typing in C#/Scala with var. Benefits of both worlds.
  • deleted 8y ago
    [deleted]
  • ben509 8y ago
    > because at the end of the day, how often do you not know whether a particular variable is a string or an integer? I'm refactoring some data-pasta to more clearly declare types because we just have dicts of lists of whatever, so often enough that a random reader chimed in after 20 minutes.
  • sanderjd 8y ago
    My issue with the larger teams vs. smaller teams argument is that the price of success is finding yourself with the wrong tools because successful projects usually grow large teams. The counterargument is that the price of choosing the right tools for a large team may be failure when those tools don't let you execute quickly enough. I don't really buy this trade-off. Maybe it is true for the specific language of Java for a small team (I'm not so sure it is) or Ruby for a large team (I have lived this and found it to be anecdotally true, so I do buy this one), but I don't believe you have to make this choice; I believe there can be languages that are productive for small teams while avoiding foot-guns for large teams.
• notmarkus 8y ago
  It's ...odd... but I've always liked the simple elegance of (Meditech's) MAGIC languages. Strict left-to-right, even in assignment and in math. Instead of "A gets 1" (A = 1), it's "1 goes to A" (1^A). > 1^A 1 > A+A^A 2 > IF{A+A*A^B B} 8
• kolpa 8y ago
  most of this article is covered in the Wikipedia page: https://en.wikipedia.org/wiki/Relational_operator#Confusion_with_assignment_operators https://en.wikipedia.org/wiki/Relational_operator#Confusion_... but Wikipedia says: "The reason for all this being unknown. [footnote] Although Dennis Ritchie has suggested that this may have had to do with "economy of typing" as updates of variables may be more frequent than comparisons in certain types of programs" while the OP says: "As Thompson put it: Since assignment is about twice as frequent as equality testing in typical programs, it’s appropriate that the operator be half as long." Thompson and Ritchie designed C together.
  • timbit42 8y ago
    Economy of typing definitely shouldn't be the #1 concern when designing a language. Look at APL.
• wpietri 8y ago
  > Ken Thompson [...] personally, aesthetically, wanted to minimize the number of characters in source code. Funnily, when Thompson was asked what he would do differently if he were doing it over again, he said, "I'd spell creat with an e." https://en.wikiquote.org/wiki/Ken_Thompson https://en.wikiquote.org/wiki/Ken_Thompson
• rhabarba 8y ago
  TIL: "BCPL later adding a floating point keyword. And when I say “later”, I mean in 2018. "
  • karmakaze 8y ago
    That one really gave me a chuckle.
• DubiousPusher 8y ago
  My first programming teacher insisted we call the single = sign the 'gets' operator. So int x = 10 int y = x would read in English as x gets 10, y gets x. Shortly after that class I took a break from any coding. When I went to another school I saw Softmore and Junior level programmers still struggling with this. I retained the habit of using 'gets'and never had a problem with this.
  • rocqua 8y ago
    I've heard the same but with 'becomes' rather than 'gets'. I think becomes works better for people with a mathematical background, where the concept of variables is totally natural. For people without this, 'gets' might be better because it helps anthropomorphize the variable. The coder 'gives' X a value to hold.
    • Retra 8y ago
      People with a mathematical background should be thoroughly familiar with words having overloaded and jargoned up meanings. Fiber Bundle, group, set, relation, etc... They all mean something different when you're not talking about mathematics, and '=' is no different.
    • DubiousPusher 8y ago
      If you're speed reading some code 'becomes' is a bit of mouthful.
      • rhaps0dy 8y ago
        Do you mouth the name of operators when you read code? Like most people I do make the words sound in my head when reading text but only the variable names make sounds when reading code.
        • DubiousPusher 8y ago
          I'm a bit of a mutterer but it depends on my mood I think.
• PrimHelios 8y ago
  >A common FP critique of imperative programming goes like this: “How can a = a + 1? That’s like saying 1 = 2. Mutable assignment makes no sense.” This is a notation mismatch: “equals” should mean “equality”, when it really means “assign”. I sort of disagree with this. Many functional languages pull heavily from lambda calculus and other forms of mathematics. In math, "a = a + 1" isn't the same as "1 = 2". The issue isn't equality, it's that you're trying to rebind a bound variable, which isn't possible. In other words, rebinding a bound variable is not the same as "1 = 2".
  • kbp 8y ago
    > In math, "a = a + 1" isn't the same as "1 = 2". The issue isn't equality, it's that you're trying to rebind a bound variable, which isn't possible. "=" means equality in math; a = a + 1 is the same as 1 = 2 because if you subtract a from both sides and add 1 to both sides you get 1 = 2. Lambda calculus has the concept of binding variables, but it doesn't use "=" for that, it uses application of lambda forms. It's the same idea that's applied in some variants of Lisp, where LET is a macro such that (let ((x 1) (y 2)) ...) expands to ((lambda (x y) ...) 1 2). The way it plays out is that rebinding is perfectly fine, because it's not really any different from binding in the first place. The same way that (let ((x 10)) (f x) (setf x (1+ x)) (g x)) can be re-written as ((lambda (x) (f x) (setf x (1+ x)) (g x)) 10) That can itself be re-written as: ((lambda (x) (f x) ((lambda (x) (g x)) (1+ x))) 10) If you'd like to read more about this sort of thing, Sussman and Steele's "Lambda: The Ultimate Imperative" is a good starter: http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-353.pdf http://repository.readscheme.org/ftp/papers/ai-lab-pubs/AIM-...
    • kazinator 8y ago
      Rebinding is essential for recursion, which is a concept in mathematics. Given a fib(x) function defined in terms of itself, the when we express fib(10), the parameter x is simultaneously bound to a number of different arguments through the recursion. We just understand those to be different x's in different instances of the f scope. Rebinding is also needed for simple composition of operations. Given some f(x), the formula f(3) + f(4) involves x being simultaneously bound to 3 and 4 in different instances of the scope inside f.
• kureikain 8y ago
  When I was in 10th grade, I found a Pascal book(I live in Vietnam so no internet at the time), I have no computer too. I though it was a math book since I aware of Pascal. I was super confuse when I saw: i := i + 1 I'm not sure how I get used to it but when I discover Erlang I feel so much happy since we nolonger has that in Erlang. I wish more language follow it.
• tropo 8y ago
  The third option: an assertion of fact A language could reasonably use plain = to let the programmer state that two things are equal. In a debug build, this could be compiled into code that validates the condition. A debug build would abort if the condition is not met. For a performance-optimized build, the compiler could use the information for optimization. It could be like the __assume keyword that Microsoft supports.
  • smadge 8y ago
    This is essentially what ‘assert’ does in some C like languages except it allows more than just asserting equality. For example: assert(length < 10)
• Stranger43 8y ago
  I think they are forgetting that a lot of languages take que's from old math textbooks where you would see function definitions written as "f(x) = nx + b" or "y = nx + b" and constant assignment with a "c = <number>" notation. if you want to calculate the output of a function into a data table(which is what early computers were often doing) iterating a variable x over a f(x) = xn + b(with n and b being fixed constants) is exactly how you would do it on paper so it's probably a case of computers emulating applied math rather then simply being pure theory machines.
  • rocqua 8y ago
    This works for initialization, but not for reassignment. Most notably, it is absurd for statements like x = x + 1. Meanwhile, such self-referential updates are very common in imperative programming, so anyone designing the language would come across this.
    • vlasev 8y ago
      You have something similar in mathematics. Recurrence relations. Since we are dealing with a sort of time difference inside a computer, something like "x = x + 1" can be interpreted as "the value of x at the next time unit is the value of x at the previous time unit plus one". That is "x[n+1] = x[n] + 1" and this is a recurrence relation. My guess is that early programmers were deeply aware of this time difference, so "x = x + 1" made perfect sense.
      • rocqua 8y ago
        The way these recurrence relations are taught at university is to distinguish the new value from the old value by using a ' pronounced prime. Here, you would write x' = x + 1 to give the recurrence relation x[n+1] = x[n] + 1. Or, more generally x' = f(x) for x[n+1] = f(x[n]). The reason for this is because in mathematics x = x + 1 is absurd (ignoring modulo arithmetic).
        • Izkata 8y ago
• optimuspaul 8y ago
  Simple, programming is like using Old Speech, the language of Dragons. We cannot lie in that language and therefore when we make a statement it becomes true. (In case I'm being too obtuse.. Earthsea) But really, this is such a pedantic discussion, trying really hard to not get sucked in.
• j2kun 8y ago
  = has contextual meaning in math, why not programming? It's not like we can fool ourselves into thinking that tests for equality don't also have wildly different meaning depending on context. No operator has a universal meaning, nor should they.
  • Guthur 8y ago
    Can you provide an example where equals sign is not equality I'm curious.
    • mkl 8y ago
      Defining things, usually preceded by "let", "if", etc.: "let f(x) = 2x+1" or "let w = 2", etc. Sometimes mathematicians us ":=" to be clearer and shorter.
    • webbles 8y ago
      When you aren't strictly referring to an equation.
    • j2kun 8y ago
      Most equivalence relations eventually drop any special notation in favor of = In general, = is not rigorous. It's used as a stand-in for the word "is". Another example is when someone writes x = 1, ..., N, meant to imply x is changing, not that x is equal to a tuple. Also the index in summation notation, which really is an assignment as in programming. I could go on.
    • pedasmith 8y ago
      How about Σ Sigma notation for summation? It's often written with something like i=1 at the bottom and 1000 at the top to denote the summation from 1 to 1000. The Wikipedia article at https://en.wikipedia.org/wiki/Summation https://en.wikipedia.org/wiki/Summation has some examples.
• willtim 8y ago
  IMHO, it was a mistake for some languages to make "=" mean assignment. Algol and Pascal got this right and used ":=" to mean assignment. Even the use of "variable" is wrong when talking about mutable memory. "Assignable" would be better.
  • timbit42 8y ago
    Both excellent points.
• chasedehan 8y ago
  In R, it is actually distinguished that way, example: a <- a + 1 a + 1 -> a # also works, but REALLY bad practice But, so does a = a + 1 Granted, there are a bunch of R haters (especially from people with formal CS educations), I think this convention makes a lot of sense. While most will disagree about the '<-' I like it from a code reading sense in that you know that it is an assignment right away. Coming from a mathematical perspective before learning to code, this makes a lot more sense in the 'assignment' fashion. In case you are wondering, the difference between <- and = in R is in scoping. For example, in the following function call: foo(x = 'value') x is declared in the scope of the function, whereas: foo(x <- 'value') x is now declared in the user environment. Granted, that is not good practice, but that is why there is a difference.
  • thalesmello 8y ago
    `->` is a bad practice? I like to use it at the end of a long `%>%` pipe. Reading the whole thing feels a lot more natural.
    • lionel- 8y ago
      It is bad practice because you are hiding the side effect.
    • chasedehan 8y ago
      The first time I ever saw that you could do that was in a blog post about stringing at the end of the a series of pipes. I thought it was pretty neat (and actually used it a couple times), then had problems when I couldn't figure out why my code was messing up. for example, this assigns a ggplot to 'plot': df %>% na.omit() %>% ggplot(aes(x=x, y=y)) + geom_line() -> plot That is really confusing in that the way most people would read it is that it is something to be plotted. However, the assignment does occur and is masked. having 'plot <- df %>%' as the first line makes it clear that a new object is being created. We actually had to modify our style guide to prevent the '->'
  • Myrmornis 8y ago
    > Granted, there are a bunch of R haters (especially from people with formal CS educations), I think this convention makes a lot of sense. To be clear, the assignment syntax is great, it's other things that are the target of R haters' hate! Like a high-level language without hash tables.
• sifoo 8y ago
  It does? Never made much sense to me; especially considering that it already means something useful, equality; which then becomes == and sticks out like a sore thumb. I prefer 'let' for assignment and generic '=' for equality; Cixl[0] adds '==' for identity, can't remember where I stole that one. https://github.com/basic-gongfu/cixl#equality https://github.com/basic-gongfu/cixl#equality
• ggm 8y ago
  At one level, the syntactic difference between = and := and == is moot. At another, since it expresses intentionality (semantic intent) its quite important. "takes the value", "is equal" and "becomes equal to" are not saying the same things. What matters is inside the parser for the language, and expressions (as in spoken or written words) between people about the language. Confusion abounds in the latter, but a well designed language doesn't have moments of confusion in the former case. Some of the choices incur backtracking cost parsing the input. Some don't but incur more keyboard presses per unit of code expressed.
• cm2187 8y ago
  Another question is why the assignment is from right to left when the natural direction would rather be left to right, like 2+2 => x to store the value 4 in x. I was told once by a math professor that it is a habit inherited because we use Arabic numbers/maths which were really meant to be read from right to left. Don’t know if the theory has any merit.
  • gowld 8y ago
    English has Subject-verb-object word order, not object-verb-subject. That's why x is the first word in x = 2+2
    • dragonwriter 8y ago
      > English has Subject-verb-object word order, not object-verb-subject Imperative programming corresponds to the imperative moodin English, where English normally has verb-object word order with the subject (the entity being commanded) ommitted. The subject of the command to set the value of x to the result of the addition of two and two is the computer/runtime running the code, not the variable x which is the direct object. English has SVO order for declarative sentences, which correspond to declarative programmig, which tends to feature definition or binding rather than mutating assignment.
  • kps 8y ago
    In conventional mathematical notation, as used in science and engineering, formulas usually have the form ν = ε, which is both a statement of equality and a method for calculating ν from the terms in ε. For example, V = I R. If you have V and I and want R, you start by rewriting this as R = V / I. Computer languages explicitly followed this.
• jrochkind1 8y ago
  Approximately 20% of this giant thread seems to actually have read the article before offering their own musings.
• dmh2000 8y ago
  assuming you are ok with mutation its just syntax. = means assignment so you only have to type one character. == means equal, so you have to type two. it could be the other way around with := and = but its really a non-issue. there's all kinds of weird syntax out there.
• hullsean 8y ago
  for me it’s := and probably always will be. those fond memories
• fspacef 8y ago
  "I don’t know if this adds anything to the conversation. I just like software history." This topic has my curiosity peaked as well. What is a good place to start reading/understanding more about this? From my understanding software development is a complex field that blew up in multiple places at the same time.
• tobiasSoftware 8y ago
  The way I explain this to beginner programmers is that there are three types of equals in math and programming: The math "=" means "these are equal" The programming "=" means "make these equal" The programming "==" means "are these equal?"
• sedatk 8y ago
  BASIC also came out with “=“ character for assignment in 1964, 5 years before B. I think it also contributed to the adoption, considering how it was popular in the 80’s.
• glorioustao 8y ago
  Coincidentally I am just reading the <<Programming in Ada 2012>>, and found this in the introduction chapter: > C history ... The essence of BCPL was the array and pointer model which abandoned any hope of strong typing and (with hindsight) a proper mathematical model of the mapping of the program onto a computing engine. Even the use of := for assignment was lost in this evolution which reverted to the confusing use of = as in Fortran. Having hijacked = for assignment, C uses == for equality thereby conflicting with several hundred years of mathematical usage. About the only feature of the elegant CPL remaining in C is the unfortunate braces {} and the associated compound statement structure which was abandoned by many other languages in favour of the more reliable bracketed form originally proposed by Algol 68. It is again tragic to observe that Java has used the familiar but awful C style.
• te7eyw8u 8y ago
  In Smalltalk it's ←
• smadge 8y ago
  If x = x + 1, then x - x = x + 1 - x, then 0 = x - x + 1, then 0 = 0 + 1, then 0 = 1. This is why ‘=‘ is a terrible symbol for assignment.
• aknoob 8y ago
  I think the question should be why is assignment operator represented using "=" ?
• aap_ 8y ago
  = is used for assignment in PL/1, a language ken and dmr were very familiar with due to their work on Multics.
• Quarrelsome 8y ago
  As someone that's done a bit of Delphi I think he's missed the crucial issue at play: If you use := as assignment your code just looks like a vertical cascade of penises.
• hennsen 8y ago
  I value clarity and explicity a lot. And I’m someone who generally lines to think about proper naming of a variable twice to make it easier for future readers of code. At the same time when reading > How can a = a + 1? That’s like saying 1 = 2. I think: Well, depends how you interpret it. If the translation is „we state, that from now on, a is the previous value of a plus 1“ it’s totally ok. Not a big difference from saying a = b + c So i‘m not sure if the usefulness if changing all languages to using := is that high that it’s worth to think about changing it in current languages - and even when inventing a new language I’m not sure if it’s helpful. I also wonder if reassignment, beside counters that need to be changed with iteration/ appearance of the event to be counted, is a thing that should generally be avoided if possible. Ok maybe in general everything where data is transformed in iterations...
• mwrouse 8y ago
  While this is an interesting article on history, this isn't an actual criticism, is it? I've never heard this criticism. I really don't think saying "a = 1; a = a + 1;" is the equivalent of saying "1 = 2" because "a" is a variable.
  • jholman 8y ago
    It's a very common criticism. And as a teacher of programming to adult students, this causes a small amount of wasted time with the overwhelming majority of students, because they know what "=" means, even the non-mathematical ones. Usually not a huge obstacle, but a perceptible one. And once they learn that it's a mutating assignment, some (small) fraction of students continue to forget, for an infuriatingly long time, which direction the mutation goes.
• todd8 8y ago
  As the article points out, the big first programming languages, FORTRAN, COBOL, LISP, and Algol each had their own way of doing variable assignment. FORTRAN used "=" and Algol used ":=" the other two languages used commands or functions to set or bind the values of variables. In the mid 60's, when I started programming, most programs had to be keypunched. (There was paper tape entry and Dartmouth's new timesharing system using BASIC, but these weren't in very widespread use.) Until 1964, the keypunch machine in use (IBM 026) had a very limited character set. This is the reason that FORTRAN, COLBOL, and LISP programs were written in upper case. Even the fastest "super" computer of the time, the CDC 6600, was limited to 6-bit characters and didn't have lower case letters. Naturally, symbols like "←" or "⇐" weren't available, but even the characters ":" and "<" were not on the 026 keypunch keyboard and so ":=" or "<-" were much harder to punch on a card. These early hardware limitations influenced the design of the early languages, and the early programmers all became accustomed to using "=" (or rarely ":=" or SET) as assignment even though "⇐" might have been more logical. The designers of subsequent programming languages were themselves programmers of earlier languages so most simply continued the tradition.
  • kps 8y ago
    > Naturally, symbols like "←" or "⇐" weren't available, but even the characters ":" and "<" were not on the 026 keypunch keyboard and so ":=" or "<-" were much harder to punch on a card. This explains why early ALGOL implementations (e.g. Burroughs, the only dwarf who went all in on the language) and dialects (ALGO, JOVIAL, MAD, NELIAC) actually used ‘=’ for assignment. This was perfectly legal according to the language definition, which distinguished between the ‘reference language’, which used ‘:=’, and its ‘hardware representation’, which could be anything. (Naturally there was no portability.)
  • mygo 8y ago
    I feel like this is the best answer. People have to work with what they have. Much in the same way that SNES games look the way that do, even though the designers back then were just as smart and talented as the ones today. That’s simply what they could do with the medium at the time. The limitations define the style. And then dogma perpetuates it, as the new generation continues to live with the results of once-great but now outdated thinking.
• Aardwolf 8y ago
  = is not that bad imho, if you see the thing before the = as next state. So in "x = x + 1", x in its next state is mathematically equal to x + 1 in the state before the assignment
• lucidone 8y ago
  I've always taken assignment to map to 'is', as in '1 + 1 is 2', or 'const foo is bar'
• petulla 8y ago
  Are there any good software history books that describe how the languages influenced each other like this?