4 ms·

The only thing that stood out to me is that bitwise or is called logior, short for logical inclusive or. As if programmers are not familiar with dozens of other

• samatman 4y ago
  In other words, what C does with absolutely monstrous glyphs, CL does with consistently-named functions. It has logior, lognor, and logxor. I briefly read that five minutes ago and will probably remember it next week.
• thefifthsetpin 4y ago
  Common lisp is from 1980.
  • deleted 4y ago
    [deleted]
• zetalyrae 4y ago
  Explicit is, as they say, better than implicit.
  • kazinator 4y ago
    No it isn't. Even machine language has implicit behaviors which make it suck less like the next instruction implicitly being found at the next address after the previous instruction, without which you'd need an explicit indication of where you want to go. We can just about define the concept of a higher level language in terms of how it makes numerous chores and concerns implicit. Good explicit could beat bad implicit in some situations, and vice versa.
    • thaumasiotes 4y ago
      > Even machine language has implicit behaviors which make it suck less like the next instruction implicitly being found at the next address after the previous instruction, without which you'd need an explicit indication of where you want to go. That's not right. There is an explicit indication of where you want to go, the program counter. By default it will increment in an explicit, documented way, but you can also write directly to it. There's nothing implicit about it.
      • deleted 4y ago
        [deleted]
      • kazinator 4y ago
        If an instruction changes the program counter, but the program counter doesn't appear as an operand of that instruction, then the effect is implicit. "Appearing as an operand" means that the instruction could choose a different register to increment other than the program counter, and to increment it by a different value other than exactly to the next instruction. Indeed, if there is a program counter visible as a register, then it is an explicit representation of where execution is happening. You don't seem to be sensitive to the IMHO critical difference between "explicit representation" and "explicit operation", though. An explicit representation can be subject to the implicit effects of operations. E.g. is is implicit that mkdir("foo", 0755) in Unix will create the directory entries "." and "..". Much of the time you don't worry about them. They are explicitly there, to be sure. A closure object is an explicit representation of a function; the capture of lexical varaible values by a closure is implicit.
• gavmor 4y ago
  > Work on Common Lisp started in 1981 (wikipedia) Is it possible that, then, programmers were not familiar with dozens of other languages? I notice this about the R language (1993), a derivation of S (1976): it is like a language from an alternate timeline in which syntax settled on other conventions but, at the time, the question wasn't closed.
  • donio 4y ago
    And a lot of what ended up in CL has much older roots. I see logior and friends in the MIT Lisp Machine manual but not in the Maclisp one. Maclisp does have a version of boole though.
  • gumby 4y ago
    > Is it possible that, then [1981], programmers were not familiar with dozens of other languages? In those days people knew more programming languages than is common today. In addition most of the people on the CL committee were academics or from academic instititutions — “industry” back then was more nerd oriented than business oriented as it more commonly is today.
  • abecedarius 4y ago
    I think you're basically right that conventions were more open, though that's a different question from whether programmers knew a lot of languages. I started programming in 1981 and read a bunch of older sources in that decade, and saw IOR sometimes (I forget where).
• zem 4y ago
  it keeps the naming scheme consistent
• saghm 4y ago
  To be fair, I've often found that outside of programming contexts, people generally use/interpret "or" to mean xor, and otherwise will use more specific language (e.g. "and/or", "X, Y, or both"). It depends on context of course, but I think a big part of it is that it's somewhat common for the options presented to be literally impossible to both hold true (e.g. "I think either team A or B will win the Superbowl this year") or at least can reasonably assumed to be ("Have you decided what to order?" "I think I'm going to get either the steak or the salmon"). I don't think it's crazy to be willing to experiment with thinking outside the box when it comes to naming things given how hard we always talk about coming up with good names is.
  • ngcc_hk 4y ago
    In fact this “or” thinking underlying a lot of problem in our ability to handle issues. You always being asked to choose a or b … catholic or Protestant etc? the question is always should be 4 options - on top of “or” can we have both or none? For the winning team … if weather or riots etc suddenly prevent further we can declare no win or in some cases both win (each got 1 point instead of re-match).
  • thayne 4y ago
    > outside of programming contexts, And formal logic, and reletadly generally mathematical proofs.
  • adrian_b 4y ago
    While I agree that in common language "or" frequently means "exclusive or", I believe that using "xor" to mean "exclusive or" is a bad choice, because "xor" is ambiguous. In computer programming, "xor" is always used with the meaning "sum modulo 2", never with the meaning "exclusive or", despite its etymology. The 2 logical functions "exclusive or" and "sum modulo 2" are distinct. They coincide only when applied to two arguments, but they are very different when applied to 3 or more arguments. "Exclusive or" of N Boolean values is true when one and only one of them is true. "Sum modulo 2" of N Boolean values is true whenever an odd number of them are true. Both logical functions are very important and I find annoying that the name of "exclusive or" has been misapplied to "sum modulo 2".
• eyelidlessness 4y ago
  > As if programmers are not familiar with dozens of other programming languages using plain or... Specificity is the soul of narrative.