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.
Nor does Vue. The focus is on typing the reactive data that feeds the templates which should be sufficient.
Plenty of things like HTML form elements take numbers or strings just fine, as it all outputs to strings in the end. Additionally, by breaking up stuff into smaller composable components there should be enough gating and typing layers, at least with Vue/Vuex that's the case. If it was just plopping straight into the elements 1-to-1 that might be a different story.
> 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 imagine that the natural thing is to add a square, triangle, circle and cross to differentiate the buttons but that some mega-corp thinks they should own that idea ... another natural alternatife would be inset arrows, but then ...
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.
Out of curiosity ... if you love implicit returns in principle, then why would you dislike them in this context?
Certainly, you need to keep in mind the return value of a function while you're writing it -- if you don't want to return any value, then just "return". And it's definitely something that you need to keep more in mind while porting JS than when writing code from scratch. But given all that, would you really prefer explicit returns in CoffeeScript?
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 quit using CS for essentially this reason. Implicit returns are a nice idea, but they are just implemented a bit too inconsistently. Additionally, it changes the language from being "it's just JavaScript" to sugared JS with different behaviour.
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.
