davidp

> we are not the recipe writers we were 20 years ago - that instead we are "abstractioners"

> we have to know far more than just the basic consturcts [sic] of the language and things like IO

Did anyone else find these annoying? I recall building a great deal of abstraction into my systems 20 years ago, and we certainly used frameworks at various layers of the system. We had to know far more than basic language constructs and IO.

Today's systems and frameworks are more available (open-source) and differently targeted (e.g. cloud-scale problems), but they're still just building abstractions on what came before, just like us old fogies were doing 20 years ago. The problems and solutions are not qualitatively different -- they just have different scale and connectivity.

All that said, Light Table seems pretty cool. But it's not evidence of deeper insight than what came before.

This is clever, thanks for sharing.

When viewing the output (using the "computer science cheat sheet") I found some differences between browsers that I thought HN readers might find interesting. These aren't primarily issues with your tool, hence posting here.

- I primarily use Chrome (21) as my browser, and the cheat sheet renders very quickly. I noticed it doesn't seem to render some equations correctly (see bad operators here[1]).

- FF (15.0.1) seems to render more correctly, but it is glacially slow. The whole app (chrome and all) freezes for several seconds between clicks while the document is loaded in any tab.

- IE (9) renders the same page both correctly and quickly.

[1] http://imageshack.us/a/img88/3754/chromeformulas.png

Maybe I lack imagination, but even though the tool provides many interesting solutions, it doesn't seem to "scratch an itch" for any problems I need to solve.

The screencast narrator asks a number of intriguing "what if you could XYZ" questions, but it doesn't actually answer them, leaving the listener to come up with useful applications. Well, what if I could do all those things? I would like to have heard more about what higher-level problem(s) these solutions address, and why these are better solutions than what I'm already using. Something motivated the developer(s) to write this, but I can't immediately tell what that motivation was.

> it's the only language without any deal breakers

Interesting thought. Can you elaborate?

> you should be using Secure UDID or something similar

As an app developer, does this give me some benefit over just generating and saving a random UUID on first launch?

Can you elaborate?

IANAL but here are two things I found interesting about the patent:

1. It doesn't claim the methods, only the systems. My (dim) understanding is that this means it isn't a software patent (a "method" patent), it's just a patent on a "system" (e.g. a device) implementing those methods. If you want to claim the algorithm, you have to claim the methods too; these claims commonly mirror the claims for the system, but with the words "a method" generally replacing "a system".

2. A claim stakes out an area of ownership; the more "and"s there are, the narrower the claim, just like a SQL query returns fewer results with the more AND phrases you include in the WHERE clause. That first long claim (on which all the others are based) could be paraphrased as "Like Tivo, but with the user additionally being able to cut/copy/paste ('edit') sections of video, but only when there's a hard drive, and only when there's a CD burner, etc." So a system that omitted or replaced one of those components would not infringe the patent.

The other claims basically just preemptively stake out further sub-sections of the area of ownership so that the next guy to come along can't do what this guy did and just specialize/narrow/tweak the existing invention in those ways.

> But I wish the Window key was more like the Cmd key in OS X. That is, I wish it was a modifier key that can be used in key combinations, and ideally have it be the primary modifier.

I disagree; the entire point of the Windows key is that it isn't interpreted by applications. It provides instant keyboard-driven access to OS/shell functions (i.e. cross-application functions), and I love it.

Linux (really X Window and window managers, I suppose) could benefit from using that key in the same way; Ubuntu's Unity does so to a limited extent. Imagine having useful keyboard-driven system/window management that's guaranteed not to conflict with any of your applications. (If that already exists, someone please clue me in, I'm less familiar with Linux than I am with Windows.)

I sympathize; but on the other hand, many of us value our own thoughts very highly too.

> I think perhaps he is confusing best practices for public interfaces with general-purpose best practices.

Exactly. Most of the advice in the article is sensible when viewed from that perspective.

I use LINQ to Entity in my company's service API. If you fail to "seal" the query (as he calls it) with ToList() before you leave the 'using' block for your DB context, your callers get a runtime error later since the IQueryable isn't run until the caller enumerates it (i.e. after the 'using' block has disposed the DB context). (On the other hand, if you call ToList() too early in your method chain, you're preventing L2E from composing your expression tree into optimal SQL, since everything after ToList() is run client-side.)

As an API provider you have to treat the behavior of your return values as part of the contract, and if your caller is expecting a plain IEnumerable (like you claim to return in your method signature), you'd best make sure it isn't really an IEnumerableThatDependsOnNondeterministicContext or an IEnumerableWithUnpredictableSideEffects.

His point is spot on about returning IQueryable only when your intention is for the caller to compose your result with other queries. If you're just returning an IQueryable because you think it's cool to defer execution, you're probably missing the point. Deferred execution isn't 100% win; you can just as easily defer yourself into a timeslot when there's more contention for a resource as into one where there's less contention. In many cases it's just as well to declare your need for the data (e.g. by calling ToList() as early as possible and let the system manage the execution.

I think he may have just tanked his chances. People buying cars in that price range 1) expect to have mechanical service available for the foreseeable future, and 2) don't like to be associated with losers. You don't want to drop $90k on a cool new car and then six months later have your friends roll their eyes or pity you when you roll up at the party.

It looks like most of the folks in the Haskell reddit community are taking it with good humor; I read that comment as a wry tweaking rather than as outright dismissal. Language nerds at play, fun to watch.

And the vim team.

Automatically downgraded by an algorithm, not by a human analyst. Not terribly significant news-wise, since e.g. the algorithm can't realistically take into account the recent positive reviews of Tesla's new models.