Strangest Programming Language Feature?

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.

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

    s:foo'="" foo(foo)=foo

    set foo="hello"

    set foo("fizz")="buzz"

    if foo'="" do [something]

Two more features: 1) Almost every directive can be reduced to one letter. 2) If I want to quit based on a condition, I can do either if condition quit or quit:condition

So the line above is more legibly written as

    if foo'=""  set foo(foo)=foo

    set foo("bar")="bar"

w:q p,?$x\8+18

w:q == WRITE, using the value of 'q' as a post-conditional, only to be executed for non-zero values of q.

If we write, we will write 'p', setting the position of the cursor with '?' (syntax particular to write) using the '$x' variable (built-in for the current cursor position).

Note: $x\8+18 evaluates to (($x INTEGER DIV 8)+1)8

First line:

GTM>f p=2,3:2 s q=1 x "f f=3:2 q:ff>p!'q s q=p#f" w:q p,?$x\8+18

2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71

Edit: Formatting is messed up. (asterisk == '* '). I could have escaped, but didn't want to add whitespace.

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.

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

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

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

That is, unless you import a module within redeclariations, in what case the module will inherit the values of the last declarations above the line it's imported on (not the last one of the file). And yep, that'll replace any declarations within that module.

The biggest surprise is that this is useful.

Of course when your whole compiler has to run in 8 Kwords or whatever, syntax checking isn't a high priority. So if you do "1234 = 0" it would allow it (since '1234' is just a variable in the symbol table) and it actually would change all of the meaning of 1234 everywhere else in the program!

    0 CONSTANT 0
    1 CONSTANT 1
    -1 CONSTANT -1

    const 0 = 0;
    const 1 = 1;
    const -1 = -1;

1. Read one word, where "word" is literally defined as "a sequence of non-space characters delimited by spaces". Some standard words include DUP 2DROP 1+ - . " and :

2. Attempt to find the word in the dictionary. If found, execute it.

3. If it's not found, attempt to interpret it as a number. If that works, push the number on the stack.

4. If neither 2 nor 3 succeed, emit an error message.

So the reason for defining a constant named "0" is to save time: it's quicker to interpret the word "0" if it's in the dictionary; otherwise you have to search the whole dictionary and then do a text-to-number conversion, which takes too long.

So really it does make sense.

    #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;

    }

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.

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

Line numbers are a wonderful thing in that situation.

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