threecreepio's comments

I have irregular astigmatism. In my experience, glasses and normal soft contacts do very little to correct it. Scleral contacts do a decent job with the astigmatism, but they have a few other issues.

And SQL has been relevant for about half a century, odds are good you'll continue to find use for that knowledge for the remainder of your career.. Well worth the time investment.

For your template code in angular, there won't be any significant benefit to using typescript. It could be worse than not having typescript at all, since you can add type annotations to your 'login'-function that don't match up with reality.

That's not really a typescript issue though, and it works great with libraries that don't use string templates. From what I've seen the angular community hasn't really prioritized a typecheck-able templating language.

> The buttons on that controller mockup are only color-coded, which means it will be difficult (if not impossible) to clearly communicate to a color-blind player

I wouldn't bet on that being a final controller, the video shows references to the buttons by letter, O, U, Y and A. (Can see them along the bottom of the screen while showing Canabalt)

The colors also appear to be the same as my old xbox-360 controller, but I don't keep up with consoles, so you may be right about that.

I hadn't actually looked at the issues list to notice that this and similar issues have already been brought up plenty enough, so, sorry about that. And I do like implicit returns, and they're one of the main reasons I'm using CoffeeScript in some projects.

What I was trying to express was that I don't generally run into this issue in ruby because the similar looping constructs don't behave this way, and don't carry the same kind of unexpected side-effects:

    def test(lst) lst.each{|i|do_stuff(i)} end

this method will return "lst" back to me, it won't create any new arrays of the do_stuff(i) results, the same goes for for/while loops, whereas:

    def test(lst) lst.map{|i|do_stuff(i)} end

will return the block results. The key difference being that the map method always creates an array and returns it, even if I would have a return; after, so it is consistent.

The only situation where I get into the problem is with looping, and after some time using CoffeeScript, only rarely, so it may just be one of those things you have to put up with. Still crops up occasionally after refactoring though.

I would not want to get rid of implicit returns, and would far rather continue dealing with the loop problems than that. Would just love it if those weren't the only options.

I both like and use CoffeeScript, but the video does show off one thing that i personally quite dislike about it.. Implicit returns (which I love in ruby..).

When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like:

    test: (m) ->
      m(i) for i in this.set

Since I didn't really expect them to build up and return arrays of the results of invoking m, which at times could result in a method that would generate gigantic arrays that I would subsequently throw away, killing my performance.

I probably should have expected that, sure, and if you don't have to deal with too much data it probably won't matter.

I have a site in progress that's used an endless paging with a sliding window, so after 5 pages it'd clip the top page. It was a little irritating in that you could notice that something different was happening with the scrollbar once you hit the limit, but other than that it did work well on mobile devices.

In the end we had to replace the endless bit with a big "load more" button though, for unrelated reasons.

It wasn't even the first .Net MVC implementation, Castle Monorail has been around since late 2005.. 3 or 4 years before the first version of ASP.Net MVC.

But it takes the Microsoft stamp to get a lot of these people excited.

These kinds of things definitely need to be overseen/'banned' somehow, but it's a bit easy to wind up catching too many real users in the net, that I'd rather have a few bad eggs around personally.

I feel plenty worse seeing users like http://news.ycombinator.com/user?id=EllieAsksWhy , with all their comments silently marked as 'dead' and made invisible without them having any idea what's going on, than I do having to ignore a few spammers.

(edit: note, you have to mark "showdead" as "yes" in your profile to see what i'm talking about)

It's a good concept and all, the issue i've had with it for my own use is that the native Array functions are so fast in JavaScript (and function invocation so comparatively slow) that you really need a very specific use case for them to be worthwhile over simply performing your operations on the array directly like Underscore.js.

Then why does 100000..100000 get the same error? Not a huge span, and not likely to contain anything all too sensitive.