Your mentioning "ALTER" made me think about a dialect of BASIC that I once used (STARDOS BASIC on a "Micro V" computer, back in the late 1980s). This BASIC dialect had an "XEQ" function that would pass a string to the tokenizer and execute it as an immediate-mode command. If you started the string with a line number you could create self-modifying BASIC code. It was dizzying to my young mind.

You mention COBOL, I was aught COBOL the JSP (Jackson) method and did lovely code. My first job they used GOTO and I was like argh, COBOL has a GOTO verb. Performance and the like, much less cleaner code but effecient :\ and with that the first steps from the academic world into the real world open your eyes up to many weird programing ways and features.

But I did always liked the COBOL, OCCURS DEPENDING ON ( http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/inde... ) and how you could use it to write variable length records to files, saving space on tape or DISC and with that faster and cheaper.

it is after all effeciency and getting that extra drop of performance that drives the weird and wonderful quirks and usage and practices that this topic aspires to highlight.

Akka actors have a very similar feature, same name. It doesn't swap identities though.

It's actually pretty cool if you think of it as a way to track state without having a mutable variable.

One example is this implementation of the dining philosophers problem:

https://github.com/akka/akka/blob/master/akka-samples/akka-s...

You can also use "unbecome" and effectively treat an actor's behavior as a stack, popping and pushing receive functions. One cool trick is to bind a value to your receive function:

  def receive(foo: Foo): Receive = { ... }

Then you can bind immutable data to a given receive function but think of it as mutable by replacing the current receive function with become().

Smalltalk also is rather famous for giving developers enough freedom to more or less destroy the environment with the terrifying looking command "Smalltalk := nil"

I guess that is because coffeescript's <= operator is just javascript's <= operator, which does implicit type conversion.

but coffeescript's "is", aka ==, aka === in javascript, doesn't.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

having "==" be semantically quite different to "<=" doesn't seem a particularly nice choice of notation.

arguably coffeescript has made things worse in this case compared to plain javascript, where you're probably not going to expect === to behave similarly to <=.

not obvious how you'd improve this to make it consistent, without say redefining how "==" and "<=" work to make them raise type errors or evaluate to something undefined if the types of the arguments don't match.

It's because equality comparisons in CoffeeScript (==, !=, is, isnt) are always compiled into strict (non-type-converting) comparisons (===, !==). [1]

JavaScript doesn't have strict relational operators (>, <, >=, <=), so all relational comparisons undergo type-conversion. [2]

  CoffeeScript: 0 <= "" <= 0           #  True
  JavaScript:   (0 <= "" && "" <= 0);  // True

  CoffeeScript: "" is 0    #  False
  JavaScript:   "" === 0;  // False

[1]: http://coffeescript.org/#operators

[2]: http://www.ecma-international.org/ecma-262/5.1/#sec-11.8

EDIT: Forgot to include 'is' and 'isnt' operators.

I don't see what you mean; could you spell it out?

I'm sure you'll be pleased to find that gcc has kept the assigned goto alive as a c extension.

    #include <stdio.h>

    int main( int argc, char ** argv ){

      void * p = && lol ;

     bounce:
      goto *p ;

     lol:
      printf("lol %p\n", p);
      p = && wtf;
      goto bounce;

     wtf:
      printf("wtf %p\n", p);
      p = && lol;
      goto bounce;

    }

No, it's the other way around; i, j, ... have a long history in mathematics as indices for matrices, summations, etc., with m, n likewise being traditional for the dimensions of a matrix.

In early FORTRAN, integers were present primarily to be used as array subscripts. The INteger mnemonic doesn't appear in any of the early papers or manuals.

As a side note, on the topic of features that would currently seem ‘strange’, some early languages that were intended to be programmed using teletypewriters rather than FORTRAN's Hollerith cards used half-line motions to write array subscripts as actual subscripts.

What about as an abbreviation for "index"?

Source?

This is one of the COBOL features that makes a lot more sense if you think of COBOL as SQL for tape drives than as something that is trying to be, say, Pascal or Ada and failing. (Along with, say, pretty much the entire DATA DIVISION...)

You can do a similar thing with Java, although it's a bit harder... http://stackoverflow.com/questions/3301635/change-private-st...

I think you can do something like this in C# too (not surprisingly).

It kinda made sense, because there wasn't anything fancy like Notepad. If you wanted to read some section, you had to specify the range. If you wanted to change a line, you overwrote it by using the same line number. If you wanted to insert a line, you had to pick a line number which lies between those other two line numbers. That's why you used an increment of 10 (or whatever) instead of 1.

You obviously never dropped a deck of punchcards, did you?

Line numbers are a wonderful thing in that situation.

Cool!

Here is a route to interesting reading (or HN karma, if you're into that):

https://www.google.com/search?q="This+question+exists+becaus...

It is amazing that MUMPS will be 50 years old in 2 years -- and it still alive and kicking.

An emergency MUMPS project is still my highest billing project (per hour) ever.

That's actually more readable than APL, and once you said "f = for" I automatically made the mental association "s = set" and "x = execute". It wasn't actually that hard to figure out the rest from that...

and something about that code reminds me of vi commands.

I haven't heard of that, and it would be great if you could remember where you found it. It sounds to me like it might be an apocryphal corruption of the following:

Fortran passes arguments by reference. If the compiler uses a constant pool, and (lazily or efficiently, depending on your point of view) passes the constant pool location as an argument, a subroutine could inadvertently modify a constant.

FORTRAN 66 (the first ANSI standard) and FORTRAN 77 forbid passing a constant or expression as an argument that will be modified†‡, thereby blessing this implementation. (Fortran 90 and later are tl;dr.)

† http://www.fh-jena.de/~kleine/history/languages/ansi-x3dot9-... §8.4 p26

‡ http://www.fortran.com/fortran/F77_std/rjcnf-15.html#sh-15.9...

It is about space, not time. What you describe happens interactively. At that time, performance does not matter much, after compiling, it does.

At compilation time (the word : is one of the ways to switch the system to compilation mode), Forth doesn't execute words and numbers if finds, but it adds their addresses (in some form, depending on the implementation) to the generated code. When running the code later, the runtime simply fetches each of these function addresses and 'calls' them (that's what makes Forth systems fast without the need for any convoluted compiler technology. Depending on the implementation, that 'call' may be an actual call in the CPU, but it typically is just another 'grab the addresses found there in sequence and execute them' and yes, it can't be turtles all the way down, but Forth gets awfully close)

Now, the question is: how do you compile "push this constant on the stack"? Forth does it by compiling the word called LITERAL, followed by the constant.

So, compiling a function called 0 or 1 adds a function address to the compiler output, but compiling a literal constant adds the address of the function called LITERAL and that constant. For constants used more than a few (where the exact limit depends on he particular Forth implementation) times, the extra space needed for that function gets more than compensated by the gain. In typical Forth systems, -1, 0, 1, and 2 already are space savers before the user types his first character. That's why they are predefined. If you use another constant often, you can easily define it. Many Forth systems even have a function called CONSTANT for it, but you can define it yourself, if it is absent.

For those wondering how the system knows that that constant it compiled isn't the address of a function to call: it doesn't. Instead, the function called LITERAL, when called, hooks into the runtime, uses the 'current instruction pointer' to read the value to push on he stack, and then increases that pointer to point past the constant. When LITERAL returns, the runtime just reads what it thinks is the next pointer and calls it.

This also depends on the flavor of FORTH you're using. The one I wrote in high school (oh so many years ago) compiled directly to executable code, with constants compiled to direct pushes, so "redefining" a constant this way would run more slowly.

While I absolutely hate FORTH as a production language (I've seen millions of dollars flushed down the tubes by FORTH afficianados who were unwilling to admit that their code was unmaintainable, slow, and didn't work), it's fun to play around with. Everybody should write at least one FORTH in their career.

  By definition, the subscript operator [] is interpreted in such a
  way that ‘‘E1[E2]’’ is identical to ‘‘*((E1) + (E2))’’.  Because
  of the conversion rules which apply to +, if E1 is an array and
  E2 an integer, then E1[E2] refers to the E2th member of E1.
  Therefore, despite its asymmetric appearance, subscripting is a
  commutative operation.¹

¹ Dennis M Ritchie, C Reference Manual, 1975 http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf (A revised version of this became Appendix A to K&R.)

There's an answer [1] on the linked SO thread (flip to the first page) but basically, the following two lines are equivalent in C:

a[10] 10[a]

This is because a[10] is equivalent to (a + 10), and 10[a] is equivalent to (10 + a), as the first comment on this answer explains.

[1] http://stackoverflow.com/questions/1995113/strangest-languag...

From the c standard[0]:

> The definition of the subscript operator [] is that E1[E2] is identical to (* ((E1)+(E2))).

Since * (E1 + E2) is commutative, E1[E2] == E2[E1].

[0] http://c0x.coding-guidelines.com/6.5.2.1.html

Now obviously, c arrays are just strips of memory allocated to that array, so you can access them using the address of the start of the address and the offset (number of array items to skip). To access them, you sum the address and the offset, then you have the address of the item.

     [~~~~~~~~~~~~~~~~[a~~~~~~~b~~]~~~] Memory
     ^–––––––––––––––––^                Address
                       ^–––––––^        Offset

And now, a[b] is just short hand for the pointer arithmetic going on and you could just use any two ints and access any arbitrary memory address (i assume the compiler enforces that this doesn't happen).

     address[offset] => *(address + offset) => getValueAtAddress(valueIn(address) + valueIn(offset))

    a[b]  => *(a + b) => getValueAtAddress(valueIn(a) + valueIn(b))
    b[a]  => *(b + a) => getValueAtAddress(valueIn(a) + valueIn(b))

Those two are obviously the same so *(a + b) == b[a] == a[b]

I think the trick is that array[i] and i[array] will always be the same value in C.

It's confusing because array[i] makes sense but i[array] doesn't (how the hell can you use an array as an index on an integer?)

It works because array is a pointer to a memory address and i (or index) is an offset. array[i] will add the index to the memory address and return the value there, where as i[array] will add the memory address to the index. Since array+index == index+array, they point to the same memory and return the same value.