L8D

If you're not paying for the model through Open router, then which provider are you buying it from? I thought that if that provider was listed on open router it would be the same price as going directly to the provider? Are you buying from a provider that isn't listed on open router already?

It is lovely to see experimentation like this going on. I think this has a lot of potential with something like Haskell's green threading model, basically taking it up a notch and doing threading across pthreads instead of being restricted to the VM threads. Surely, if this can be well fleshed-out, it could be implemented at the compiler-level or library-level so existing multi-threaded Haskell software can switch over to something like this to squeeze out even more performance. I'm not an expert here, though, so ¯\_(ツ)_/¯ take my words with a grain of salt.

I can second this. NYC has plenty of companies accepting applications, but an extremely small number of interviews actually happen, and an even smaller number of people are getting hired. It feels like there are 200-300 job seekers for every job posting that makes it onto a job board, with titles like "Senior Software Engineer."

I think the hip thing to do is just use your spare time to build stuff, and organically learn from building stuff. Self-sufficiency, creativity and generally being a self-starter is what's hip. More time spent building translates into an incentive to pickup tricks and relying on yourself to find hip solutions to actual problems.

GitHub is the [canonical spelling](https://github.com/about) though

Do the people who think like seriously imagine that this is something reasonable and expectable, and not totally subjective to the style and habits of individual developers? I'm always baffled by managers or business people who seem to think quantification of productivity is easy. They must be incredibly lazy to not want to invest themselves in understanding what their developers are doing to gauge productivity themselves. Is this a sign of horrible management, or at least, as you say it, management that has become horribly out of touch with their developers?

In accordance with Betteridge's Law of Headlines[1] the answer is no.

[1]: https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

I don't know how people do links and stuff on hacker news

You're not missing anything. What you and the author are describing (in terms of pattern/architecture) has existed for quite a while but was widely popularized recently by Facebook's [Flux](https://facebook.github.io/flux). The author is either naive towards current state of the JavaScript landscape or their just being arrogant about what is actually unique to 'functional' programming.

- [Lobsters](https://lobste.rs) - [Hacker News](https://news.ycombinator.com) - [Reddit](https://reddit.com) - [Product Hunt](http://www.producthunt.com/) - [Designer News](https://news.layervault.com/)

The crux of my argument is relying on methodologies to write good software or to guide a design is pointless.

Instead of trusting everything you read, you should question it an consider it in practice before you actually follow it.

I'm sorry but I call BS. In the author notes it doesn't try to say that games are a bad influence at all. Nor does it try to shame the gaming industry.

The author notes go over why he created the game, and how his childhood experiences and the current state of the gaming industry both affected the creation of the game.

He doesn't even mention Nintendo what-so-ever in the notes, neither does he focus on violence.

You severely miss-interpreted what the author wanted to portray.

He focuses on how video games and their authors attempt to toy with our emotions, and how it can be a much more powerful medium to effect the way people think than with books, television or even social media.

Yep if you're on Canary then that should happen. Otherwise it goes to full-screen and you see the ending dialogue.

Perhaps you could contribute to the file via a PR instead of ranting at a post on a news aggregator? If people like you did then the open source community would be a better place.

If you think this is cool, go ahead and check out bfb, an IRC bot written in a derivative of Brainfuck.

https://github.com/billiob/bfb

Austin TX, Remote, Full Time (priority) | Contact | Part Time

Stack: Node, JS-HTML-CSS, CSS Frameworks (Bootstrap, Foundation...), JS Frameworks (Angular, Backbone...), Haskell, (former) Linux server administration

Contact: tenorbiel@gmail.com.com

I'm interested in working with a team since the majority of me work has been independent contracting. I'd like to develop the skills to work on large projects with large teams.

IIRC, it was made specifically for us and the startups in San Fran.

Why did you blatantly steal from Mark Steve's version?

Yeah, I trashed pretty quickly because I realized I didn't have time to work on it, nor did I have the creativity to write good examples. It would have better suited to be about JavaScript rather than Node, and there are already plenty of better ways to learn good JavaScript on the internet. I might do 'Haskell by Example' which would be really fun, if I ever have time for it.

What speed and ease to you gain with it? CoffeeScript won't get you any performance; if any, less. Making obscure or verbose patterns easier to use is syntactic sugar. Part of the thing about CoffeeScript, is that there are more bad parts that it introduces than prevents. Cleaning up the class model is generally not a good thing, since JavaScript isn't designed to have true OOP principles. Things like it's expressive for loops and default arguments generate really ugly code, and shun people from using ES5 array methods like .forEach, .map, and .filter, which are a lot cleaner and more optimizable by the engine. If you're ever trying to check the existence of a variable, then you've already probably made a bad design choice; but you won't realize it because CoffeeScript encourages the pattern. Also, CoffeeScript will completely obscure the way JavaScript works to newcomers, and will confuse them and encourage them to use the syntactic sugars in place. The syntactic shortcuts were originally there to make it easier for those who really needed to use the nasty things to achieve it. Now, a CS user would use them because they're there. If you teach a ruby programmer CoffeeScript in order to introduce them to JavaScript, they're not going to be able to know the differences well enough to appreciate and understand them.

The thing about CoffeeScript is that it makes it a ton easier to reason about doing operations like default arguments, pattern matching or expressive for loops. When you don't see the messy code generated from its syntactic sugar, you don't think its a problem. But when it comes to best practices, long term decisions and performance, CoffeeScript will stab you in the back.

The original reason for hatred towards CS in the Node community was when module written in CS started showing up on npm. If someone was trying to debug something and hunt down a problem to your module, they can't really read the code generated by CS(because it really does become a mess unless you don't abuse the syntactic sugar), and you can't debug the CS code.

Another problem occurs when you're trying to setup a sane build system for your project. It can become really tedious to use the entire build system every time you want to run your code, and even more to setup everything correctly with source maps, stack traces, minifying, etc. Just about every other module that deals with the code you write will support CS, so in many cases it is the deciding factor in which modules or libraries to use.

The original reason for me to dislike CS was because the first team I worked with using CS made so many different style choices about the code that it become unreadable. Some people wanted to use the syntactic sugar sparingly, others would use it and put everything in one line.

Take this for example:

    # print all lines given
    pall = (lines...) -> console.log line for line in lines

Someone might write the function like that so that it would fit on one line and be easier to call. But as it turns out, there is a lot more than meets the eye. This is the generated code:

    var pall,
      __slice = [].slice;
    
    pall = function() {
      var line, lines, _i, _len, _results;
      lines = 1 <= arguments.length ? __slice.call(arguments, 0) : [];
      _results = [];
      for (_i = 0, _len = lines.length; _i < _len; _i++) {
        line = lines[_i];
        _results.push(console.log(line));
      }
      return _results;
    };

Which in that case, you might as well skip CoffeeScript's for loop and do an ES5 `Array.protocal.map` call, which will do the same thing, and can be optimized a lot further by the engine.

    # print all
    pall = (lines...) -> lines.map (line) -> console.log(line)

Which, in V8, can be shortened down to:

    # print all
    pall = (lines...) -> lines.map console.log

That skips the whole array generation part and is much more concise and up to ES5 standards. But there are still a few more problems with the code. Look at what it generates:

    var pall,
      __slice = [].slice;
    
    pall = function() {
      var lines;
      lines = 1 <= arguments.length ? __slice.call(arguments, 0) : [];
      return lines.map(console.log);
    };

See a problem? We could skip the entire first two lines by calling `Array.prototype.map` directly on the arguments. But also, we've forgotten that we never needed to 'map' over the array in the first place, because we know that `console.log` will return `undefined`. I just stuck with using map over `.forEach` so it would match CoffeeScript's 'always return something' rule, and it would be ugly to have an empty handing `return` at the end. So instead, we should probably write the function like so:

    # print all
    pall = -> Array::forEach.call arguments, console.log

This is all in all the best of all the other code, because it generates the optimal representation in JS. If you wrote code like what CS generates, then you could see and make out a ton of flaws before hand, but who dare questions the power of CS and inspects the generated code? But none the less, if you were to write your CS like that, there would be no point in CS. Still, if you wanted to cleanest possible code to be generated, you'd need to put one of those annoying empty returns at the end of the function.

    pall = -> Array::forEach.call arguments, console.log
              return

There has been a development of hate towards CoffeeScript in most JavaScript communities. CoffeeScript seems to be very popular in the non-JS communities that need to write JavaScript, like in the Ruby and Python web development communities. CoffeeScript was designed for non-JS coders to feel a lot more comfortable writing JS.

That would break the point of it being 'low-level' unless you're saying the standard library and kernel were both designed to function like that.

I'm in the process of making a clone of the site for node.js [here](https://github.com/L8D/nodebyexample)

You do realize that go has lambda expressions (anonymous, in-line, functions) right?

This is the best explanation of functional programming I've ever read.

Congrats.

When it says "giving you the benefits of tools like LESS and Sass" I think they are referring to how you can postprocess the CSS generate by LESS and Sass

Where Ruby usually denotes code blocks with a `do` and an `end`, Python denotes code blocks with a `:` and an outdent. But also, Ruby has a lot more implicit syntax and uses methods as operators(`1 + 1 == 1.+(1)`). There are a few more things that wouldn’t be obvious, like how it is still indentation sensitive yet you still need to use an `end`. Also, you can avoid the `end` keyword is you include it on the same line, like so:

    fun square(n): n * n

Not only does Vim have a Ctrl+P plugin, but the Ctrl+P feature of Sublime originated from the Vim plugin.

Hey, I think something that would make the experience a lot better would be to incorporate Ace editor into it, so you get a very well-featured editor incase you don’t have easy access to a better-than-<textarea> editor.