They should follow the more familiar pattern of CSS libraries with a series of simple examples. I feel this reads more like a paper.

I disagree. It's made for writing papers and paper-likes. It sets the tone and expectation with itself as a fluid set of examples.

Basic income without universal housing, healthcare and education is more-or-less a poverty sentence.

One obscure issue that ends with the comment "It's slow but I don't think it's the crippling bug I first thought it was." hardly supports a claim that " Angular4 suffers from the same slow down/performance problems as Angular 1.x."

> 17.an amazing IDE - it has a tool to debug macros!

This may be true for an experienced user, but I've mainly used VS Code/Atom/Sublime etc, and I did not enjoy DrRacket -- I'm assuming that's what you're talking about. Some of the dropdown menus didn't render for me, and while this may sound stupid, I had the damnedest time figuring out that half my screen was a REPL and the other half a file.

How long ago did you try it / what platform are you running on? It was a few years ago now, but they rewrote the GUI libs to be native rather than whatever x-platform lib they used. DrRacket seemed to get... better then.

I mostly use emacs, but was playing with paredit for DrRacket with emacs keybindings the other day and decided that I could get to like some of the other creature comforts of DrRacket.

I'm still slightly confused. The author suggests that a monad is composed of 3 functions. It seems to me you've shown 2 of these functions.

a -> m b

>>=

What is the third function? Did I misunderstand you?

The author is mistaken. There are only two functions necessary for a monad: >>= and return

Also, the type of return is `a -> m a`. The type you cite `a -> m b` is a parameter to >>= (which has type `m a -> (a -> m b) -> m b.

The author might be refering to a quirk of the Haskell monad interface, which has to additional functions:

">>" which can be easily defined in terms of >>=. I assume this is part of the interface so users can override it with a more efficient implementation, but every implementation I have seen just uses the default one.

"fail" which is an error handler. This is being depreciated as a function of Monads, and moved into its own MonadFail typeclass. This also has a default implementation that just throws an exception.

> The author is mistaken. There are only two functions necessary for a monad: >>= and return

Probably because monads are frequently described as triples -- two functions and a functor. The author seems to have reduced that to three functions (presumably fmap) without realizing that it isn't sufficient.

I suspect the third function is the one for running the monad. It's different for each one, so it's not part of the type class, but you do need it to use a given monad. (Except IO, though even it has unsafePerformIO)

What is the function for running Maybe, or List?

How does that differ from saying the same thing about say webpack -- ie, "the build is documented in the webpack config"?

Makefiles are more stable, webpack just went through a breaking change to 2.0.

Makefiles are more versatile, they can be used not just for Javascript files, but for anything. I have a django project that uses lib-fann on the backend, and Selenium for data collection. I wish I had put that into a makefile because I can't remember the commands I used to build it, and now I have to take the time to go figure it out.

Makefiles have conventions for not just building, but also running: "make all" to build, "make run" to run, and if you have an unusual project, you can get plain "make" to print out out some documentation explaining what to do. Webpack has webpack-dev-server but then you have to remember that command.

Ultimately a lot of that could be had by a README file, of course, but Makefiles are easier.

vim readme.md

"To run, use 'npm run'. To develop, use 'npm run dev'. To test, use 'npm test'."

Or, open up package.json and see what scripts are there... I don't get how that's any different? Why wouldn't you have scripted all that?

I script it that way and then add a makefile on top of it so that it's conventional and handles things like envvar setting.

    build:
        NODE_ENV=production yarn build:server
        NODE_ENV=production yarn build:client

    test:
        NODE_ENV=test yarn test

we do the same, but the npm scripts are just the "entry point". one of them was this:

    "build:dist": "NODE_ENV=production babel ./src --out-dir ./dist"

Maybe you missed this paragraph, it talks about your point:

Makefiles are more versatile

Do you generally run long running tasks such as a dev server with Make?

Not the GP, but if I'm going to use make anyway, sure. init/systemd/upstart scripts for a system install, make run for a local install. It's exactly the same idea as running "node start" (apologies if I have the invocation wrong, I'm not really familiar with the node ecosystem).

A makefile is just a way to group commands together conveniently (at least, that's one aspect of it). So you can just type "make run-server" or whatever you want and it's just like running a script.

It's probably not something I would do on a production server, but it wouldn't hurt either.

It is also a way to write down and share very complicated command lines that you want to generate only one time because it is a pain to type it each time. So, a kind of self-documentation.

Not a JS dev, but if I run "ls" or "tar xf foo.tar.gz" and I see "Makefile", I instinctively run "make". Ditto for "./configure", although I'd probably despair if autotools were needed for a JS project ;)

Because make is human readable and webpack reads like some sort of regex gone wild example.

It works with the outside world and it's been stable for decades.

I feel like stability is underrated.

> Boser explains why some of the most common ways we try to memorize information are actually totally ineffective, and he reveals what to do instead.

I couldn't get past the first paragraph. I don't think memorisation and learning should be conflated as it appears to be in this article. Perhaps it's the fault of the title -- clickbait?

Clearly you didn't get past the first paragraph.

> You can use History PushState [0] and CustomEvents [1] to handle routing.

Can you please expand on this?

Sorry in a bit of rush as it's Sunday here, I will try to write a blog post with more detailed example later tonight.

For now, I will share this snippet:

  document.addEventListener('state-change', (ev) => {
    const { key, action } = ev.detail;
    const state = { key, action };
    window.history.pushState(state, null, `/${action}/${key}`);
    console.log(`triggered state change. action: ${action} key: ${key}`);
    return handleState(state);
  });

And then in your app code (for example, when a user clicks a button), trigger a state change:

  const event = new CustomEvent('state-change', {
   detail : {
    state: state,
    key: key
   }
  });
  document.dispatchEvent(event);

Hey just wanted to say thanks! Never heard of the `CustomEvent` API I [used it](https://github.com/AyriaPublic/desktop/commit/3e3b0ad76e7624...) in a small work in progress Electron app. ^^

Oh, a Wire reference on HN... my life is one step closer to completion.

Is the xkcd Appropriate Standards strip appropriate here?

Python xkcd: https://xkcd.com/353/

What's even ironic here is that the print command he used is Python 2 instead of Python agnostic. I wonder which version Randall Munroe would prefer, if either.