Absolutely. To nearly everyone, the user interface is the program. This sounds like a truism but really is the opposite. It has important practical consequences.
30,328 karma · joined August 18, 2007
I sense, though, that the author's tactics for working with teams that don't share his values are half-measures. It reminds me of the large and sad literature on "organizational change" in software development, wherein people trade stories about how to cajole managers into letting them do fragments of good engineering. None of that works very well. The satisfying solution is to be part of an organization that values good engineering in the first place.
Similarly, a designer like the author would be better served by working with–I'm tempted to say better engineers, but that's my bias–engineers who feel the same way that he does about product. These exist; I'd consider myself blessed to collaborate like that.
Alexander's critique of modern architecture is devastating, but his later, hugely more ambitious work is somehow less compelling. Perhaps I should give it another chance.
Re null reference checks, to get behavior analogous to a null exception you have not only to check for null, but also pass back an explicit error if you find it. That's a lot more work than adding in an extra question mark. Null checks that do nothing but not crash are a mixed blessing; 90+% of the time they do what you want, but when they don't, you get a silent failure and a debugging goose chase. I'd be surprised if you told me that that never happens.
I took a look at Node.js domains and they do seem really complicated. If I were working in Javascript instead of having control over the language, I doubt I would use them; I would probably just crash-and-restart as one of the other commenters described. That's not a good solution, but probably the best tradeoff given the alternatives.
As for domains, I don't know what you mean by them, but if they're catching errors at a higher level than the async library, my guess is that they must be some more sophisticated sort of top-level handler; perhaps something that keeps track of which async calls are in progress and attempts to bind exceptions back to their context? Whatever it is, it sounds complicated.
But what I understand least of all is how you guys all seem to write Javascript code that generates almost no exceptions. To me that sounds almost like bug-free code. No null references, for example? I get stuff like that all the time.
The terms "object" and "object-oriented" mean so many different things that it's hard for any discussion not to run aground on semantics. But I'll chip in with this anyway: in my experience, you don't need OOP, and it's a particularly obscuring influence in JavaScript. Certainly you should not take for granted that OOP reduces complexity, but rather ask yourself in the context of particular programs how true that really is. (Games may be a special case, since they're closer to the simulation-of-an-external-system paradigm that is the sweet spot for OOP.)
In my view, the fundamental problem with OOP may be premature encapsulation. Once the core concepts of a program have gotten clear enough to be very well-defined, it makes sense to put them in the kiln and bake them. The rest of the code can then just use an interface and care nothing about the details. But as long as the core concepts and their relationships are still in the process of being discovered, which is actually the default case for most programming, what you need most is malleability. The OO infrastructure of encapsulation impedes that. This manifests as unclear classes with unclear names and unclear dependencies between them. Such a program is harder to work with than a loose collection of functions would be. And the fact that JS wasn't designed to be used this way makes its effects worse in JS.
Sure, but what if the error is thrown at you as an exception in the first place—which happens a fair amount, because that's how the JS runtime tells you when something is wrong? How do you get from there to the callback way?
What the Lisp macro I mentioned does is generate a separate try-catch around each block of code that runs at a different time and thus might throw an exception that would not otherwise get caught. In that way it catches every exception that's thrown, converts it to an error object, and passes the error back through the callback chain. The async library could do the same, albeit with a lot more code. I'm curious why it doesn't.
From a practical perspective, it doesn't make sense to try to catch exceptions in asynchronous code, anyway.
I don't think that's right. Asynchronous code is just synchronous code that runs at different times. Each block of synchronous code can generate exceptions. I agree that if you don't catch them then, they become useless; but you can catch them then. The reason this is not a "practical perspective" in JS is not that it doesn't make sense, it's that the language doesn't support it. Even the minimum code necessary to catch every exception involves so many try-catch blocks as to obscure the rest of the program. So no one writes such code by hand in JS.
Yet it is, I think, code that one wants, because without it you don't have a consistent error model. You end up having one model for first-class errors—the ones you detect and pass to callbacks before an exception has a chance to arise—and a second one for the dregs—the ones that come from any code that didn't know about or follow the callback convention (which, critically, includes the language runtime). The latter kind of error either crashes the server or gets caught by a top-level handler so it "only" crashes the request it was processing. That's a half-baked system.
Whose behavior does that not describe?
The graph from the last article you linked to: http://skepticalscience.com//pics/ProjvsObs.png
The graph from the OP: http://www.drroyspencer.com/wp-content/uploads/CMIP5-90-mode...
In both cases the actuals are at the low end of the predicted range. They disagree as to how low, obviously, but not as much as I expected.
I ask because I wrote some Lisp macros (I work in a Lisp that compiles to JS) to implement a few async patterns I need, and making sure that exceptions are trapped and threaded into the callback chain correctly was the most complicated part.
When a new thing comes out, the discussion should focus on what's significant about it.
dreamdu5t said neither of those things, and there's no need to be rude.
https://news.ycombinator.com/item?id=7204558
It got very little discussion, so if you didn't see it, I recommend it.
Actually, when I was looking through stuff for him, I found a project that implemented Minecraft bindings for JavaScript with the aim of creating a friendly environment for kids. The author was an HNer and had posted it here a year or two ago. But the project had languished since then, and it struck me (perhaps unfairly) that it probably wouldn't work out of the box in all configurations. The last thing one should put in front of a kid is something that immediately frustrates them by failing in strange ways. Tools like that need to be really, really well-hammered. Which is one of the advantages of Scratch.
That rings very false to me. It was not at all the case when I was in high school. In fact it was just the opposite, and I see no reason why that would have changed.
That's so obviously false that I doubt she's saying it. I suspect it's more like: these qualities tend to come up in childhood, so if we want to see more of them, that's where we should focus.
Everything about your comment ("I figured out HTML on my own") makes me bet you that had these qualities in spades as a kid long before you had a computer. All this existed before computers, after all. I remember Jerry Weinberg saying that he knew he wanted to devote his life to computers from the day Time Magazine ran a futuristic cover story about them in the late 1930s. Another farm kid, as it happens. He went to college to study computers and found they didn't exist yet, so he majored in physics and bided his time until programming became a thing.
I wonder sometimes whether any of this is about childhood per se or the fact that children are more likely to do things out of play, to figure stuff out, see what will happen, and so on. If that's it, then we can dispose of the controversy by agreeing that people who come to programming purely as a career or (god forbid) for status will do worse not if they're too old, but if they're too uncurious.