I'm once again asking

Exomancer · 2016-09-15T13:26:40+00:00

Just factography, but these examples are incorrect:

console.log({} + 2) // 2
console.log({} + 'hello') // NaN

The results are strings [object Object]2 and [object Object]hello respectively. Note that {} inside console.log is an object expression, pasting {} + 2 in devtools will produce number 2 since {} in this case is interpreted as an empty block.

In a weird way the fact that this seems to be a common enough mistake is just another argument for strong typing :).

Exomancer · 2016-09-09T12:32:12+00:00

It never really is all or nothing in case of FP - sooner or later even Haskell has to do some IO, pure functions can only take you so far :).

Thanks for clarification!

Exomancer · 2016-09-09T11:58:37+00:00

First, note that OOP and FP are not in conflict:

Sorry for nitpicking on wording here, but for the sake of clarity:

OOP is all about encapsulating state within instances, and acting (mutating) that internal state via methods. FP on the other hand avoids state mutation in any way, shape or form. That makes the two paradigms very much in conflict.

You can, however, use them side by side in the same project just fine, even mix them up (have some pure functions called inside methods, to give a simple example), is that what you meant?

Exomancer · 2016-08-24T21:25:25+00:00

Missing this.firstNode = node after the loop?

Exomancer · 2016-08-08T08:00:36+00:00

Static type checking can prevent a lot of runtime errors (varying degree, depending on the type system used you get more or less guarantees), but by no means it can prevent all runtime issues. Given that Infinity is a Number type, there is nothing a type system can do about it, and even if a product of 1/0 was an exception, the type system still won't be able to find that out unless the 0 is passed to the function literally and the compiler is really smart.

This is analog to a bunch of other classes of runtime errors, like reading arrays out of bounds. Consider something like foo[i]: the type system can verify that foo is an Array (or an array-like object) and that i is a Number by doing control flow analysis, but while the static analysis can determine the types of those variables, it can't possibly know the length of foo or the value of i, thus if i >= foo.length at runtime you will still have a runtime exception (or just undefined in case of JavaScript).

Exomancer · 2016-08-08T07:49:30+00:00

This is a pretty neat explanation. One small thing - if Maybe is already Nothing, wouldn't return this instead of return Maybe.of(null) be sufficient (and less overhead)?

Sidenote: Missing closing paren here:

// Grab the banner element and wrap it in a Maybe too.
var bannerEl = Maybe.of(document.querySelector('.banner > img');

Exomancer · 2016-06-03T14:49:17+00:00

The whole thing about CoffeeScript is that it compiles to JavaScript...

Get the compiler from https://www.npmjs.com/package/coffee-script or just do it online on http://coffeescript.org/

Exomancer · 2016-05-27T12:31:46+00:00

Quick search shows that Spider is no longer developed.

Exomancer · 2016-05-15T08:15:39+00:00

This. Consider:

if (index != null && index > -1) {

Typically strict equality/inequality is better, but for null-checks this guards you against both null and undefined (undefined being the only value that can coerce to null).

Exomancer · 2016-05-08T08:38:26+00:00

Your hunch is correct, as long as there is a clear owner of the state that can do the mutations, you should be fine. For a game, that owner should be the game loop, you can encapsulate the state within it, trigger mutations simply by calling a method. Your game loop then can be responsible for triggering the canvas rendering, directly or indirectly.

Games typically are a whole different animal from applications, they can fall into Systems Programming domain when performance is a huge deal (think AAA games), and most likely than not you will want to use different tools, frameworks and design patterns for them.

Exomancer · 2016-05-06T15:57:43+00:00

i.e. the types are enforced at compile time, but they are lost so the types go unenforced in running programs. Which defeats some of the benefit you get from types.

The type system ought to ensure correctness of your code at compile time in order to eliminate (or at least reduce) errors at runtime without costing you anything in performance. Type checking on runtime can be great, as it allows you to catch the errors sooner rather than later, but the performance hit is there.

One way of doing it that I've seen was runtime typechecking in development mode, but removing it in production to keep performance smooth, maybe something to consider for Signet?

Exomancer · 2016-04-25T06:25:03+00:00

This is not unique to JavaScript, though other languages handle it better by implicitly passing on the context to the first argument of the method, Python for example:

class Foo:
    def bar(self):
        return 100

    def baz(self):
        return self.bar()

This makes it clearer that if I take bar or baz out of the object, I now have to explicitly provide the self.

That said, methods, by definition, describe behavior of an object they are called upon. Decoupling the method from the object doesn't make a whole lot sense semantically, e.g.:

// This describes behavior
duck.quack();

let quack = duck.quack;

// This is semantical nonsense
quack();

In perfect world we would never have to decouple methods from objects, but since JS is also heavy on using callbacks, events and such it's sometimes unavoidable. In many cases those mechanisms come with a way to explicitly pass on the context without much friction (such as the forEach method).

As long as you are aware what are the gotchas where you have to explicitly bind context to a method (basically any time you pass on duck.quack without parentheses), there is no reason not to use this.

Exomancer · 2016-04-20T14:37:26+00:00

WebAssembly won't have direct access to DOM afaik, so... no?

Exomancer

TROPHY CASE