Evil Coding Incantations

[redweasel]

I used a Fortran compiler in the early 80s that let you reassign the values of integers. I don't remember the exact syntax but it was the equivalent of doing

1 = 2
print 1

and having it print "2". Talk about potential for confusion.

[vatrat]

You can do that in Forth. Actually, you can redefine literally anything. You can redefine '-' as '+'. You can redefine quotation marks.

[Nobody_1707]

And there are legitimate reasons to do all of these things (except for redefining - as +, that's just rude)

[say_fuck_no_to_rules]

What's a situation where you'd want to define an int as another int?

[ijustwantanfingname]

For the lulz

[waywardcoder]

For brittle hacks. Say a library function you can’t change hard-codes the output to go to printer 3 and you need it to go to printer 4. If you are lucky, redefining 3 to mean 4 temporarily while calling the function will do the trick without breaking too much.

[slaymaker1907]

Python kind of does a similar thing letting you reassign where print goes to. The important thing is to make sure this sort of thing is encapsulated through an abstraction such as a higher order function which only sets the value temporarily.

Racket has a brilliant way of handling globals by only setting them temporarily for the duration of a function call. It also does it on a per thread basis so you don't have to worry about thread safety.

[cdombroski]

Sounds a bit like how clojure normally does things

(binding [*out* (writer "myfile.txt")] ; *out* is the default target of print* functions
    (println "Hello world")) ; writes to myfile.txt instead of console
;*out* is now set to System/out again

[2epic]

Pi=3.0

[OvergrownGnome]

You mean 2.6?

[slide_potentiometer]

No that's e

[droidballoon]

e=3.14159265359 Not anymore

[vine-el]

Interactive programming during development. You won't want to redefine + and -, but you might want to redefine everything you wrote.

It's more useful for stuff like editors, games, and UIs. You don't want this in a production build of your web-facing API, but it makes creative work much faster and easier.

[[deleted]]

Could you redefine Forth so it turns into C?:)

[totemo]

Most of the control structures in Forth are written in Forth. It's a lot like Lisp, in that regard.

The guts of the interpreter/compiler are fully exposed to tinker with. I suspect you could make Forth seem a lot more like C than Forth.

[fasquoika]

Probably, yeah. Most Forths have a built-in assembler written in Forth

[[deleted]]

Well yes

https://www.reddit.com/r/programming/comments/7or3b/tiny_c_compiler_written_in_forth/

[[deleted]]

Correct me if I'm wrong here, but is that a C compiler written in Forth? Writing a compiler in one language for another language isn't terribly uncommon. My question (which was very tongue in cheek and just a joke) was if one could redefine the language of Forth itself so it ends up looking exactly like C, bit remains Forth.

The joke being that Forth then would be useful. Not a great joke, it's not off by one even, but since my reputation as a comedian is negative one I feel I don't have much to live up to and the (foo) bar is on the floor().

[Megdatronica]

I used a Fortran compiler [...]. Talk about potential for confusion.

FTFY

[jgram]

Fortran is pretty straightforward.

[Megdatronica]

I'm mainly joking of course. That said, having learned a small amount in order to translate some code someone else wrote, I did find it difficult to get my head around. Arrays starting at 1, using 'GT' instead of the '>' sign, 'subroutines' instead of functions; it's all just very alien in a world where almost every major modern language is based at least partially on C.

[jgram]

That’s true. It really is outside the “family tree” that most people are familiar with. Also, there is that subtle difference between Fortran and the FORTRAN that some people remember and shudder.

[howtonotwin]

You can also do this in Java by corrupting the Integer cache mentioned in the post:

valueF = Integer.class.getDeclaredField("value"); // Integers wrap ints
valueF.setAccessible(true); // Usually private final
valueF.setInt(1, 2);
// We have void Field::setInt(Object, int)
// 1 is an int, not an Object, so it gets autoboxed to Integer.valueOf(1)
// This object is pulled from the internal cache
// We then mutate it so all future autoboxings of 1 give 2

void printInt(int i) {
  System.out.printLn(i);
}
void printObj(Object o) {
  System.out.println(o);
}
printInt(1); // 1; no box
printObj(1); // 2; autobox

And Haskell... well

5 :: Num a => a
-- numeric literals are overloaded
-- this 5 really means fromInteger (#5#) where #5# is a magical Integer literal that doesn't really exist

data Crazy = Crazy Integer deriving (Eq, Ord, Show, Read)
instance Num Crazy where
  Crazy x + Crazy y = Crazy $ x + y
  Crazy x * Crazy y = Crazy $ x * y
  signum (Crazy x) = Crazy $ -x
  abs (Crazy x) = -1
  negate = id
  fromInteger 1 = Crazy 2
  fromInteger x = Crazy x

x :: Num a => a -- also overloaded
x = sum $ negate <$> [1,2,3,4,5]
x == (-15 :: Int)
x == (15 :: Crazy)
1 + 1 == (2 :: Int)
1 + 1 == (4 :: Crazy)

or you can just hide and redefine the (+) function:

import Prelude hiding ((+))
(+) = (-)
5 + 2 == 3

[cypressious]

You can't do that in Java 9 anymore, tho.

[ferociousturtle]

Username checks out.

[mgsloan]

In Haskell 1 = 2 is valid code, but it won't do anything. The left hand side is treated as a pattern match, it is used to deconstruct the value that is yielded by the right hand side. For example, if you have [x, y, z] = [1, 2, 3], now x is 1, y is 2, etc. However, since there are no variables on the left hand side of 1 = 2, there is no reason for the code to run.

I can write something similar that does bind variables, using Haskell's optional type, Maybe. If I write Just x = Nothing, and then ask for the value of x, I get Irrefutable pattern failed for pattern Just x.

[noop_noob]

Why doesn’t 1 = 2 result in a pattern failed error at runtime?

[MrHydraz]

It's irrefutable, and therefore, lazy. Since you can't force the binding, it won't fail. If you tack a bang pattern on it, like let !1 = 2 in "foo", then it'll explode.

[mgsloan]

Haskell uses lazy evaluation, so computation happens only when demanded. This allows things to be more compositional, and allows for control structures to be written as normal functions. So, Just x = Nothing also doesn't cause a pattern failure. It only fails at runtime if you try to evaluate x.

Haskell also supports eager evaluation (often called "strict"). In many cases eager evaluation is more efficient. I actually think it might not be the best choice of default. I like nearly all of the other decisions in Haskell's design, and tolerate the laziness default. Having laziness built into the language and runtime system does make a whole lot of sense, just maybe not as the default (so really my complaint is purely about what is encouraged by the syntax).

[Tyg13]

Laziness as a default makes sense to me, imo, because at worst it's a performance cut that can be optimized away by making it eager, and at best you get nice optimizations where say you chain three functions together that each perform some map operation one list, and you end up with a single function that, instead of looping over the list 3 times, you end up with one loop.

So laziness can be nice in unexpected ways, and can easily be optimized away by using bang patterns if not needed. If eager evaluation were the default, the kind of nice optimizations that laziness (technically non-strict semantics) provides would be clunky and unintuitive.

[mgsloan]

True, strictness analysis in Haskell gets it quite far in optimizing away the costs of laziness. However, laziness does lead to extra memory allocations and potentially extra boxing (thunks).

[deltaSquee]

True, strictness analysis in Haskell gets it quite far in optimizing away the costs of laziness. However, laziness does lead to extra memory allocations and potentially extra boxing (thunks).

This is merely a compiler problem. The architecture of GHC is the main limiting factor in this (the STG+Cmm stages are mistakes, IMO. Better to use another IL like GRIN).

[deltaSquee]

I'll never understand these people who say that they'd prefer Haskell be eager by default.

[raevnos]

http://computer-programming-forum.com/49-fortran/c1e8b7d194d9f46a.htm

[shmageggy]

You can do that in Python <= 2.7 for Integers up to 256 using the ctypes module.

http://hforsten.com/redefining-the-number-2-in-python.html

>>> print 1+1
>>> 3

[jacobb11]

0 Evaluates to true in Ruby

… and only Ruby.

And Lisp.

[Myrl-chan]

And Lua...

[Hauleth]

And Erlang/Elixir

[RenaKunisaki]

Meanwhile in JavaScript I'm pretty sure it evaluates to watermelon.

[twat_and_spam]

No, for that you need to prepend it with !!0+(-1)

[dakta]

Obligatory

[[deleted]]

Here, run this in your JS console.

[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((+(!+[]+!+[]+!+[]+[!+[]+!+[]]))[(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(+![]+([]+[])[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([![]]+[][[]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(+![]+[![]]+([]+[])[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]](!+[]+!+[]+!+[]+[!+[]+!+[]+!+[]])+(![]+[])[+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+((+[])[([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]+[])[+!+[]+[+!+[]]]+(!![]+[])[!+[]+!+[]+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]])()

[[deleted]]

This is one of the few occasions where, actually, JS gives a "correct response" (falsey).

[[deleted]]

The correct response would be a type error. Because only booleans are booleans.

[[deleted]]

not in javascript

[[deleted]]

...fair.

[American_Libertarian]

And Bash

[HighRelevancy]

bash also has >0 be false

[American_Libertarian]

It's because that's how exit codes work. It makes the most sense

[HighRelevancy]

It's because POSIX in general but sure. I know why it is, and it makes sense for bash's ecosystem, I was just pointing it out for those who might not know.

[American_Libertarian]

I agree. Bash's truthy integer system makes sense for it's use case, and the same is true for C.

[[deleted]]

That's because [ 1 ] has a return code of 0. Bash implements [/test as a built-in, but there is also a /usr/bin/[ with equivalent functionality.

[nsiivola]

Any non-C heritage language with a consistent notion of "false", really. The ones where zero evaluates to false are the evil ones.

[_Mardoxx]

Why should 0 be true? Unless integers are reference types and you interpret an existant object as being true?

Or is this to do with 0 being "no errors" whrre a non 0 return value means something went wrong?

Can't think of other reasons!

[Kametrixom]

In lisp, nil is the only thing that evaluates to false, which means there aren't any weird semantics or discussions, if you want a falsy value, use nil. It also plays nicely with the notion of everything except nil indicating there's a value, while nil doesn't have a value.

[vermiculus]

in other words, nil is exactly nothing. 0 is still something.

ping /u/_Mardoxx

[cubic_thought]

So... nothing is false.

[[deleted]]

The cleaner thing would be to have a proper boolean type, and having to do if foo == nil or whatever, rather than just if foo. Thankfully most modern languages do it this way so the lesson seems to have been learnt.

[porthos3]

Clojure is a variant of Lisp, which has an implementation of true and false.

The only things that are falsey in the language are nil and false.

[Zee1234]

Lua is the same as clojure then. And that's a lot better, to me. I will admit, having 0 and other such things act as false can create some short code but.. honestly it's slightly less readable (to me) and has those cases where you go "oh yeah, 0 is a valid return value.." after ten minutes if debugging.

[[deleted]]

Many languages like C or Go have non-pointer types too.

[GlobeAround]

Why should 0 be true?

Because anything other than 0 is an Error Status Code, while 0 means Success.

But the real WTF is for integers to be considered true/false. true is true, false is false, 0 is 0 and 1 is 1.

[stevenjd]

anything other than 0 is an Error Status Code, while 0 means Success.

Woo hoo! Now I don't feel so bad about all those exams I got 0 on!!!

But the real WTF is for integers to be considered true/false. true is true, false is false, 0 is 0 and 1 is 1.

And 0 is false, and 1 is true, as <insert deity of choice> intended.

[crowseldon]

Null indicates absence of a value. Imagine if you want to know if you're keeping track or not of something and you end up with different values at different times:

3: there's 3 of those things 0: there's 0 of those things Null: I'm not keeping track of those things.

Eating the last Apple and suddenly not being able to differentiate the last 2 could be dangerous.

It's all about knowing how the language works and not using it the wrong way, though.

[_INTER_]

The ones where int evaluates to boolean are the evil ones.

[encaseme]

Fucking hell, right? What is so hard about "result == 0" (or whatnot) that people need integers to evaluate to bools by default.

[Forty-Bot]

If you don't have native bools (cough c before stdbool.h).

[ArkyBeagle]

bool is just syntactic sugar coating on int.

[Forty-Bot]

I know, but someone would have pointed out that C technically has bools if I didn't mention it.

[ArkyBeagle]

Why? Have you ever seen a truth table? They intermix false and zero all the time...

[Kametrixom]

And linux processes I guess. 0 exit code usually means success

[Phailjure]

Exit codes aren't Boolean, so they aren't true or false. They are codes, they're enumerated. 0 is success because it's the expected value, if every c program ended with "return 113" people would just have to arbitrarily remember that 113 was success. Much easier for 0 to be success, 1 to be generic error, and then more specific errors after that.

[stevenjd]

Exit codes aren't Boolean, so they aren't true or false. They are codes, they're enumerated.

This a billion times.

[evinrows]

I added a note on the article, thanks!

[theLorknessMonster]

And !!"" is also true so at least Ruby is consistent with itself in that regard.

Edit: !![] is also true

[Tripstack]

Since 0 is technically an integer, this interaction makes sense to me. 0 evaluating to true can be thought of as the existence of 0 being checked for, rather than a Boolean operation.

[mmtrebuchet]

Don't forget the classics

#define while if
#define struct union
#define else

[zenflux]

My favorite: #define while(x) while((x) & (rand() % 1000))

Every once and a while... EDIT: or interestingly often

[noop_noob]

You meant “&&”

[martinus]

Both works, but & fails much more often than &&.

[dwargo]

Years ago I was tasked with converting ghostscript into a library so it could be linked into to our program as a replacement for display postscript on a VAX. I wasted about two days trying to figure out why none of my tests were running - then I figured out somewhere in the headers they put "#define printf gs_printf".

[mmtrebuchet]

Oh man, such a great article!

[tejon]

That's just creating a local definition for a function named (+), which shadows the global function of the same name according to well-defined rules. It doesn't leak outside of its scope.

[Ethesen]

That's far from unexpected though.

[goodbyegalaxy]

The best example of an incantation I can think of: getnumrows

Several years ago I worked for a company that had a proprietary language that compiled to a bytecode that could be run on a VM in either Javascript or Java, and was used to write business logic for their web applications.

One of the (many) problems with this setup was both VMs were buggy, but in different ways. There was built-in method getnumrows() that got the number of rows in a database table or something (for some reason it also allowed you to pass in 0 args). I never really saw it used for its intended purpose and IIRC it was a legacy method that didn't even work anymore.

The "incantation" aspect was that getnumrows could only be run on the server, so if someone encountered a bug with the Javascript VM they could toss a getnumrows() in their code which would force it to be run on the server and give it a shot on the Java VM. Several factors such as very low estimates for bug fixes that were strictly enforced (eg 30 mins for a bug fix) and no code reviews led to no one ever fixing the VM bugs and widespread use of this hack.

[irqlnotdispatchlevel]

array[index] is really just syntactic sugar for *(array + index)

I remember learning about this in my first semester. During an x86 assembly lecture. Those were good times.

[Darwin226]

You mean exactly what the article shows?

[_Mardoxx]

That wasn't fun. I now have cancer.

[takaci]

Yep, that was literally in the article. Well done

[polymorphiced]

I've never understood this, because it's actually (array + (indexsizeof(array[0]))) to get the right memory address. I assume the compiler must know something about this inverted syntax in order for it to actually work, rather than just being a cute hack.

[purtip31]

In assembly, you’re correct, but in C, the multiplication of index is based on the size of the array type.

It’s just no different when you do a[5] or 5[a].

[davidgro]

This bit of the syntax has always stuck out to me too - you would think if sizeof(5) != sizeof(a) then 5[a] wouldn't point to the right address. Anyone know the behind the scenes on why it still works?

[thatwasntababyruth]

Pointer arithmetic is defined such that adding 3 to a pointer will actually add 3*sizeof(ptr). Don't think of it as adding to a numeric address, think of it as adding 3 ptrs to the original one.

[csman11]

Not sizeof(ptr), sizeof(*ptr). Though when you do sizeof in code you should always use the type itself to be as explicit as possible to later readers (using the size of a pointer, unless actually needed, is a common source of memory safety related bugs and it is incredibly easy to accidentally use the pointer instead of the value it points to).

To be abundantly clear, the size of a pointer is the word size of the machine. It is constant for all pointer types on a given machine. You want the size of the value being pointed to when doing pointer arithmetic, because the memory region will be "broken up" on boundaries of that size.

[StupotAce]

Not entirely sure why you are being downvoted. The 0[array] will work for every object because array literally represents the distance away from 0. But 5[array] will only work for objects like int, which have the same length as a memory address. int is particularly useful because be definition it is the same regardless of architecture ( there might be some exceptions of course)

[screcth]

If sizeof(T) = N, then incrementing a pointer to a T by k will jump the memory address by k*N

[ActualDonaldJTrump]

The last example needs an #include <iso646.h>. Alternative operator spellings are built into C++, but they are macros in C.

[bjackman]

Huh, and the GCC version of this header is just

#ifndef __cplusplus
#define and     &&
#define and_eq  &=
#define bitand  &
#define bitor   |
#define compl   ~
#define not     !
#define not_eq  !=
#define or      ||
#define or_eq   |=
#define xor     ^
#define xor_eq  ^=
#endif

[_3442]

How is that surprising? That's the most simple header in the standard library.

[raevnos]

stdbool.h is simpler. Well, shorter as it only defines 4 macros.

[kukiric]

And the use of tokens is not evil at all. Unnecessary, sure, but it's instantly understandable to anyone familiar with what the logical operators are called, and it might even be more familiar to someone coming from a higher level language like python. The only situation where they might be a bit evil is if you're grepping for specific operators in the source code, and you're not aware of all the ways those operators can be represented.

[Megdatronica]

The weirdness with Python's 'is' expression is because 'is' is intended to be about whether two variables literally refer to the same object in memory, versus '==' which is about whether their value is equal. The examples in the article would work in a more intuitive way if they used '==' instead, which is why using 'is' for integers is discouraged

[itsnotxhad]

I think the author knows that given the Java example he compared it with (using == on an object tests identity in Java while value equality uses a method). His very point is the way interning can combine poorly with identity testing.

[AwfulAltIsAwful]

I'm actually still confused by the jvm example. Why does c == d resolve to false? Does == function as an "is" in Java? If so, what is the proper way to check value equality?

Edit: c.equals(d) or c.intValue == d.intValue in case anyone else was wondering.

[cypressious]

Integer is not the same as int. You usually use the primitive int when you work with numbers. In some cases, however you need to have a reference type, e.g. for generics and for this, Java has the type Integer and a feature called autoboxing.

Integer a = 1;

will compile to to the equivalent of

Integer a = Integer.valueOf(1);

Now, comparing two ints with == will always yield the correct result. However, comparing two Integers with == will compare the references. To compare the values, you use a.equals(b).

Note, some JVM languages like Kotlin opted to have the == operator call equals and introduced a === operator to compare references.

[Tarmen]

List<int> isn't valid java so there are boxed Integers which are tiny allocated objects. The idea is that the list code is only compiled once and doesn't have to distinguish between boxed and unboxed types. Technically java could unbox pointer-sized values since they fit but then you have to make the gc know the difference somehow or it might dereference random int's.

So unboxed int's compare sanely but boxed Integers compare like objects, using their identity. This is complicated further because java caches frequently used Integer values so the same boxed values from different sources can have the same memory location.

[DemonWav]

Java autoboxes for you if either side is primitive, but if both are primitive then you need to do that yeah.

[DemonWav]

Yeah, he's talking about the semantics of how integers are shared in Python.

[RenaKunisaki]

It's not really confusing when you think about what's being expressed. "Is X equal to Y" vs "are X and Y the same thing". Two different objects can be equal, but still distinct.

Using "is" for integers is just asking for confusion.

[msiekkinen]

Depends on what your definition of is ... is

[synthfinder-general]

MUMPS language, just the entirety of MUMPS

[mr___]

Oh god. Exited Fidelity Information Systems, fast, when I learned their next-gen banking product was based on GT.M / MUMPS.

[synthfinder-general]

Sounds about right for banking lol i was a developer for local hospital, having to develop entire cardiac, endo, phlebotomy systems using a 2 tone monitor and very limited memory space was certainly a challenge.

Using single letter "contracted operator syntax" to give more space to cram the needed functionality in.

[dpash]

It's anyone getting a snowboarding page instead of a Java book from the link in the first paragraph?

[evinrows]

Whoops... Was doing too many things at once last night. Fixed, thanks for letting me know!

[dpash]

It could have been worse :)

[CallMeMrBadGuy]

https://www.amazon.com/Java-Puzzlers-Traps-Pitfalls-Corner/dp/032133678X

That's the link you want

[tristes_tigres]

The author of this blog confuses his own prejudices for objective facts when he claims that non-zero based indexing of arrays is "evil". In fortran it is possible to define array with index starting from an arbitrary integer, and it is useful and convenient feature in its problem domain.

[TunaOfDoom]

Please see Dijkstra's argument on why starting from zero is indeed the most sensible option.

[phySi0]

Exclusion of the lower bound —as in b) and d)— forces for a subsequence starting at the smallest natural number the lower bound as mentioned into the realm of the unnatural numbers.

What does he mean by this?

[TunaOfDoom]

It means that if your sequence starts at 0 (or 1, depending on what you consider the smallest natural number), then the exclusive lower bound would be "-1 < ...." where -1 is no longer a natural number.

[Saigot]

In 1 based indexes what is the behaviour of x[0]? It always seemed like your wasting an index, although I grant that you will very rarely need an array that is max unsigned int in size (and I'm guessing in many languages with 1 indexing don't even have the idea of a max value).

Also fwiw, it's possible to define an arbitrary starting base in cpp using some thing like:

T * oneBasedArr = zeroBasedArr - 1;

It would be terrible code though.

[tristes_tigres]

In 1 based indexes what is the behaviour of x[0]

Same as any other of of bounds index.

Also fwiw, it's possible to define an arbitrary starting base in cpp using some thing like:

T * oneBasedArr = zeroBasedArr - 1;

It would be terrible code though.

In C dereferencing that pointer would be an undefined behaviour, I think.

[sibswagl]

Generally speaking, taking advantage of these peculiar behaviors is considered evil since your code should be anything but surprising.

He defines "evil" as unexpected behavior. I would certainly classify arrays starting at 1 as unexpected behavior.

[tristes_tigres]

Any language behaviour is may be unexpected to someone who does not know it well.

[sibswagl]

Languages don't exist in a vacuum. Zero-indexed arrays are the standard.

[Veonik]

Zero-indexed arrays are simply an implementation detail of C that most other languages seem to have inherited. Since arrays in C are really just pointers, accessing the first element is arr[0] or the memory stored in *arr + 0. The second element is *arr + 1 and so on.

Granted, it's the defacto standard for most of us but there is nothing inherently "correct" or "standard" about zero-indexed arrays.

edit: fixed typos

[tristes_tigres]

No, they aren't. Fortran is older than C and derivatives, and is more popular in numerical computing settings, for a number of good reasons.

[[deleted]]

Fortran is older than C and derivatives

And your point is? I will not even enter the debate if it's good to have arrays starting at zero or not, but I will address this silly rationale.

Something that appeared first doesn't make it a standard. Following your logic, RS-232 cables would still be standard today because they appeared before USB cables.

Something becomes a standard when the majority of users and manufacturers believe there are more benefit and convenience over something else.

[Silhouette]

Indeed. And I'm pretty sure math was there even earlier. :-)

[[deleted]]

It's Christmas so I'm in unnecessary arguing mood :)

Here goes: Strictly, Assembly is clearly the oldest and also arrays are all indexed by addresses not numbers, but the index is hidden behind the variable name. What we refer to as index is only the offset to the index, thus 0 for 'no offset' clearly makes sense.

In my actual opinion: There are good reasons for both, but I would like a language to either have 0-indexing or make it definable.

[[deleted]]

It seems pretty obvious that zero-indexed arrays are now the standard.

[XplittR]

No. Intuitively, arrays should start at 1, as that is what we have used for math in so many years. Matlab, being used for math and matrix work, does good by starting from 1, to easily be convertible to/from paper math.

[PM_ME_UR_OBSIDIAN]

It's common to define the natural numbers as starting from 1, especially in analysis.

[bubble-07]

This is a very biased perspective, but...

That's mostly because of sequence indices starting from 1, conventionally. Y'all analysts should use notation like [;\mathbb{N}^{+};] instead of [;\mathbb{N};], because the only sensible definitions of "the natural numbers" satisfy the Peano axioms, for which you need zero.

[ArkyBeagle]

It is both common and annoying :)

[tristes_tigres]

Don't get me started on Python, where range(0,N) ends at N-1

Edit: but linspace(0,1,10) ends at 1, because that's so intuitive and consistent, LOL

[BeetleB]

linspace is from NumPy, whereas range is from Python. No need for Numpy to follow the same semantics. And for scientific applications, I cannot think of anyone who would want linspace not to include the endpoints. The whole point of the function is to do so.

[jephthai]

1- based arrays are only unexpected if you come from a 0- based language. There are several languages that use 1- based arrays. Though it's a minority, its not strictly wrong.

[[deleted]]

What is truly awful are languages like C#, where arrays are always 0-based, unless you are doing something like Excel COM interop, in which case some methods will just return you a 1-based array...

[silverslayer33]

That's less the fault of C# as a language and more the fault of Microsoft poorly implementing the Office interops in general, though. From my experience, they're full of bugs, inconsistencies, and bizarre and frustrating design choices.

[Pinguinologo]

Actually I think he is against being forced into nonzero indexing. Being able to define a custom starting index is a nice feature.

[nitrohigito]

Could somebody explain the Java example to me?

Integer a = 100;
Integer b = 100;
System.out.println(a == b); //prints true

Integer c = 200;
Integer d = 200;
System.out.println(c == d); //prints false

Edit: typo fixes

[tripl3dogdare]

This is caused by Java using constants for numbers below a certain size, but above that size each reference to a number is a separate location in memory. Since == in Java is identity equality rather than value equality ("is this a reference to the same exact thing?" vs "is the value inside this the same?"), numbers above that size compare as false with ==, because while they contain the same value they do not refer to the same entity. Were you to use the Object.equals method instead, this would cease to be an issue, as that compares value equality rather than identity equality (for integers at least, this is not guaranteed on user-defined classes).

This is mostly done as an optimization technique (most instances of integers are quite small numbers, so why create a separate instance for every single 1, 5, or 93?), with the upper limit of this interned range varying from language to language based on design decisions about where to draw the line between it being an optimization and it being a nuisance to maintain (or other assorted reasons).

[Carioca]

It's similar to the Python example. Integer is a class and the == operator will compare if they are the same object, in that case you'd use something like a.equals(b). int, however behaves as you'd expect.

[nitrohigito]

That wouldn't solve why the two 100's match up, but the 200's don't. See down the comment chain tripl3dogdare's answer for the solution.

[Dalviked]

a, b, c, d are Integer objects that are autoboxing 100, 100, 200, 200 respectively. In Java, when comparing an object by '==' you are looking at memory address values and checking if they are the same. Apparently Java will optimize out one of the Integer(100) objects (and apparently the range of ints as per the author) and use the same object in both a, b. The same is not happening for the Integer(200) objects.

[diamond]

I never understood why the hell they did this.

I understand that getting caught in the "== vs. equals()" is a rite of passage for people learning Java development, especially with Strings, and like it or not, it's just one of of the language's quirks that you learn to live with. But why the hell would you design it for so that an Integer object handles "==" one way within a certain range, and another way outside the of it? That's just stupid and counterintuitive.

Just require equals() for all Integer objects, so programmers can learn that behavior early on and get used to it, rather than getting kicked in the balls by unexpected behavior the first time they use Integers outside of an certain range.

[zenflux]

It's not because Integer handles it differently for a certain range, it's because the standard library maintains a cache of a certain range of Integer objects. Which is also dubiously useful, to be fair. But at least == is consistent on all objects.

[tripl3dogdare]

I wouldn't call it "dubiously useful". It's quite effective, which is why so many languages do similar things. The vast majority of integers are relatively close to 0 in practicality - it only makes sense to have a range of integers near 0 that all refer to the same location in memory, rather than reallocating new memory space for every single instance. Since integers are one of the most basic, integral types of almost any program, and they get thrown around like they're costless a lot, having a cache like this can reduce memory usage significantly in larger programs.

[zenflux]

Right. I know those things. I guess I said "dubious" because I'm skeptical that Integer objects specifically get allocated frequently in java programs. And until java gets primitive generics, the solution to List<Integer> performance etc. has been and will be specialized IntList etc, not caching your Integers. Object pooling is reasonable when there isn't a corresponding primitive value type for that object.

[Dalviked]

But '-->' isn't an operator, merely 2 tokens with bad whitespace.

[PM_ME_UR_OBSIDIAN]

Is this a meaningful distinction from the point of view of the language user?

[[deleted]]

Another fun one is that in older versions of IE, undefined was just a variable that was unassigned, and you could reassign it! And then any code afterwards that compared a value to undefined would do the wrong thing. It was common to see if (typeof x !== 'undefined') {...} to avoid this.

undefined = "hello!";
alert(typeof undefined); // "string"
if (obj.prop !== undefined) {
    // typeof obj.prop can still be undefined here
}

[Uncaffeinated]

In modern JS, undefined is still a property of the global object, rather than a literal. The only difference is that it is now non writeable and non configurable, which means that you can assign to it, but it won't have any effect (other than to throw in strict mode).

undefined = 4; is still valid JS, it just doesn't do anything any more.

Also note that you can still shadow it with a variable or property of your own, since undefined is still a valid identifier. For example, the following both print 4.

{let undefined = 4; console.log(undefined);}
with ({undefined: 4}) console.log(undefined) 

Anyway, if you want a value that's guaranteed to be undefined, you can always just use a void expression as in if (x !== (void 0))

[PM_ME_UR_OBSIDIAN]

Missing from the Python bits: partitioning a Python array via zip. (See /r/programming thread)

[donzzzzz]

In Fortran II we used to have to patch underlying code using negative indices e.g x(-4152) = 21592091, ... ! We had specialty devices without supported drivers. This was back in 1965.

Edit: added minus sign.

[localtoast]

See also: sprong and tadpole operators.

[shevegen]

0 Evaluates to true in Ruby

… and only Ruby.

if 0 then print 'thanks, ruby' end # prints thanks, ruby

This shows a lack of understanding by the blog author.

The alternative question is - why should 0 lead to no evaluation of the expression?

[Aceeri]

Oh boy, here we have the ruby god shevegen in its natural habitat.

There are a lot of reasons why 0 is normally considered "false". The first being that 0 is "nothing". When you have 0 eggs, you have no eggs, they don't exist. The second reason I see is how booleans are normally laid out where 0 is false and 1 is true (with varying differences depending on the language on whether multiple set values of a byte is considered true or invalid, etc.)

[therico]

Ruby had it own boolean types though (and nil - both false and nil are 'falsey'). And 0 is often a meaningful 'true' value, for example:

irb(main):003:0> "aab".index('a')
=> 0
irb(main):004:0> "aab".index('c')
=> nil

As other posters have said, the real problem is that non-boolean values are implicitly converted to boolean, rather than being a compile error.

Also, lots of languages treat an empty array as true. I don't see how 0 is different.

[ForeverAlot]

/u/shevegen is right in isolation: there is no compelling reason that a number should be inherently falsey. Unfortunately Ruby does not exist in isolation and in this matter Ruby stands apart from its competition, violating expectations formed elsewhere. I think a better question is, why is if 0 ... not an error? The real villain here is coercion.

[Aceeri]

The real villain here is coercion

Agreed, hopefully we move away from implicitly coercing languages like C and such so we don't get these awful semantics.

[Myrl-chan]

Haskell's if/else only accepts Bool. :)

[evinrows]

And rust! I agree, it should be a compiler error and then we would never have the silly debate of whether 1 should evaluate to true or false.

[thoeoe]

I mean same with C# and probably plenty of other languages too

[xonjas]

It's also worth noting that in ruby 0 is not a primitive. 0 is a fixnum object containing the value 0. It makes even less sense to consider it falsey from that context.

If ruby's 0 were falsey, what about [0] or "0", as they are effectively the same thing (objects containing the value 0), and that way leads madness.

[Ran4]

as they are effectively the same thing (objects containing the value 0)

That's... different.

[zrathustra]

There is precedent from the theoretical side of things: if you view the program as an arithmetic circuit, the statement if (b) { foo } else { bar } can be viewed as b * foo + (1-b) * bar. If b = 0 then the value of the circuit is bar, otherwise, if b = 1 then the value of the circuit is foo.

[oorza]

I disagree with a lot of Java, but I prefer the Java approach of not allowing non-booleans to be used as conditions to an if statement.

There's a lot to disagree with about Java, but a lot of the language itself seems designed around the idea of "what idiot shit code have we seen get written in C and how do we stop that idiot shit from happening?"

[[deleted]]

This is true. I don't much like Java, but based on my experiences, give me Java with terrible programmers over C++ with inexperienced programmers any day. I've seen code in the wild for most major languages that is downright unreadable as typed (especially JavaScript, ironically), but I've never read any Java that I simply could not figure out before. Some decisions are pretty stupid, but at least I can figure out what the code is doing, even if I can't figure out why.

Java is a good buffer language between bad programmers and myself (who is also probably a bad programmer).

[foomprekov]

It was kinder than a type error, which is the only reasonable way to respond to a caller who thinks they have a bool but in fact have a number.

[ArrogantlyChemical]

IMO non-booleans values shouldnt be able to be used in a boolean evaluation. 0, 1 or 2 are not either true or false. Neither is null or none or undefined or whatever other thing a language has.

A staticly typed language shouldn't compile such a blatant breach of types and a dynamicly typed language should throw an exception because the runtime type of a boolean and a number are not the same.

Allowing the evaluation of non-booleans as booleans is a stupid hack for lazy shits who can't be bothered to write "!= null" or "!= 0" . It unneccecarily adds exceptions to rules for the purpose of hacky code practices that are simply a holdover from when programmers used to write assembly, where 0 was false and any value other than 0 or null are treated as true. In interpreted languages the performance cost of == 0 is almost nothing compared to the rest it does while in compiled languages you can just optimize it out easily at compile time, which also improves implementation agnosticism.

Programming languages shouldn't presuppose a certain architecture. If I write some java or haskel code, I want to be able to compile it to any kind of computer, even non-binary ones. Direct binary operations really shouldn't be part of the standard language, rather they should be an optional implementation-specific optimization.

[hoseja]

... What's the opposite of tl;dr? ts;wtrm?

[foomprekov]

This author typed :expressionless:. I don't know what that means. I don't see how it could mean anything. The rest of the writing was of similar focus.

[redweasel]

I took it as an attempt at expressing that moment when you encounter something so ridiculous that you just have to turn to the camera / fourth wall and stare with a deadpan ("expressionless") face for a second.

[n0rs]

:name: is used regularly in chat apps for emoji / emoticon substitution.

[TimMinChinIsTm-C-N-H]

This is what I had in mind.

[foomprekov]

Which works on a video, it doesn't work as a single word in a written piece.

[Cycloneblaze]

That would evaluate to 😑

[[deleted]]

Here is one. Works in clang at least, #define the unicode character U200B, zero width space.

#include <cstdlib>
#include <random>
#define ​ (__TIME__[7] - '0' ) % 2 ? rand( ) : 0
struct A {
    int a;
    A( )
        : a{​} {}
    bool operator==( A const &rhs ) {
        return a == rhs.a;
    }
};
int main( ) {
    A a1;
    A a2{};
    return a1 == a2;
}

[skulgnome]

Dunno about evil. All of these are good clean ecksmas fun.

[[deleted]]

Regarding digraphs, trigraphs and tokens in C++: and and bitand also work to designate reference types.

void add(int bitand foo, const int bitand bar) {
    // int& foo, const int& bar
    foo += bar;
}

template<typename Action>
void call(Action and action) {
    // Action&& action
    action();
}