I appreciate your enthusiasm for correctness, but if I'm reading correctly, the essence of sktrdie's comment was trying to counter the group think that the idea of the article is in some way "bad", "satirical", or "wrong".

It may be that I only ever merit to use this pattern once every 10,000 lines, but that in no way makes the idea of calling with reference over primitive values incorrect. Readers should understand the difference between rare and never.

> he essence of sktrdie's comment

Sure, however the first part of my comment is not intended to address the essence of their comment, so it has no bearing. What they said is incorrect, and in fact a common mistake and I wanted to correct it.

However, I'd also note that what sktrdie is describing is an Array (in Javascript an Array is just an object with numbers for property names and some helper methods).

As far as I can see there is absolutely zero benefit (and many drawbacks) in using the technique outline in the OP article as opposed to just using an Array.

You could get the same result by simply using an Array directly...or if you want to get fancy, add a few simple helper methods.

In this way (and perhaps others) the article is "bad" and "wrong".

Okay, great, you're absolutely right that an Array would have been a better choice of data structure, albeit marginally better.

That was not my qualm, and neither does it seem to be the qualm of other commenters on this page. Of course, I'm having to second-guess the reasons of other commenters because they were disinclined to note them, but am simply contesting the notion that the article is satirically bad.

> marginally better.

I'm not so sure.

As written it's wasteful of resources and not cross-browser. (also not entirely functional)

All the stuff with the closure and defineProperty is basically pointless....

In the end what they have is an object with numbers for properties, and they are sticking values in those properties. That's an array.

All the hoops they jump through don't do anything except heat up the processor and waste resources, with nothing in return for that.

Consider this code which does the same thing:

  var $ = function(val) {
      var addr = $.mem.length;
      $.mem[ addr ] = val;
      return addr;
  }
  $.mem = [];

  var foo = "foo";
   foo = $( foo );
   console.log( foo )  // 0
   console.log( $.mem[foo] ) // "foo"

This code accomplishes the same thing but is much faster, leaner, simpler, and cross-browser.

I'd also say that all of this doesn't really do much to inform one about "pointers". Learning about the link between pointers and arrays in certain other languages might be helpful for some JS developers, but there's none of that here. Here is just a roundabout array implementation that doesn't really teach the reader anything.

I'm not going to spit on the efforts of someone who is trying to learn something, or be condescending about it (at least not intentionally)....but I think it's necessary to point this sort of thing out so everyone walks away the wiser.

Sometimes you really do just want to pass a value by reference. It turns out that most of the time you want to do this the variable already is an object or array already, nevertheless there are cases where this would be desirable, so it's not a bad idea when used carefully.

Having said that, malloc is a bad idea and completely unnecessary, and a nicer way to do the functionality might be to do:

    function pmk(val)     { return { v: val }; }
    function pget(p)      { return p.v;        }
    function pset(p, val) { return p.v = val;  }

Doesn't need free'ing, at the minimal expense of creating one object per "pointer".

Neither of the solutions give you an "address of" type behaviour though :(

This article is incorrect, arrays are passed by reference since they are objects. I've added a comment on the blog.

Bit of a plug, I've written something like this except that it doesn't work via GHC and instead outputs source code (which means the gensyms aren't very safe...)

I'm not working on it anymore (unfortunately never really got over the static typing) but it should run and might be of interest: https://github.com/aliclark/hasp http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html

Rightly or wrongly, because they want to keep the game low tech and reproducible in the park.

Shockingly, one time a few friends and I managed to play soccer in the park without any refs at all!! Crazy right? It was like a completely different game!

/sarcasm

The low-tech argument is not valid. People play football, baseball, basketball in the park all the time. There is no love-lost due to lack of replays, shot clocks, etc.

"Depending upon the Dell computer your purchase, boot times can be around 30 seconds!"

I'm always slightly embarrassed to read exclamations like this knowing it'll wind up as the laughing stock of Reddit/HN in ten years' time.

I'm amazed and slightly worried that they haven't stopped donations yet (assuming this is possible with Kickstarter).

> debian sadly is too dated for my hardware and I don't feel like using sid

Did you try debian testing?

My experience with rolling release:

I tried Gentoo and then Arch, moving off both after they pushed updates which completely broke my system.

Gentoo has a disclaimer that you need to check each update individually, Arch was a little bit more realistic, but on the flip-side contradictory - some places they tell you to just update often, and others tell you to check packages for problems as with Gentoo.

If you do not intend to check each update for breakages (like me), then my advice is to not use Gentoo or Arch (but if you are willing to check all updates, then I'd recommend them).

Debian testing's been okay for me so far and I've got greater confidence that they a) won't be as likely to break my system, and b) will send an update to revert or fix in a reasonable time if they do.

If (or when?) this breaks, I'll go back to Ubuntu, full circle.

My sister's didn't. More RAM for me (and my next laptop will also be a thinkpad)!

> If you don't like my rules, develop for a different platform.

Okay.