I do agree that Watson seems oversold, but the evidence in this article (Watson's shallow opinion of Bob Dylan, compared to the author's opinion of Bob Dylan) seems kind of weak. I was hoping for some insider information on the implementation of Watson, but unfortunately there is none.
Anecdote: I saw an article about Native Americans, using a technique of quickly focusing from near to far and back as a means to increase their eyesight range, when I was around twelve years old. Called Eagle Eyes, or something. I have been practicing regularly for eighteen years now, and my eyesight has only improved. I have been looking at computers and books at least a third of my time since. Am I actively preventing myopia? Interesting.
Years ago my optometrist suggested I do this exercise. I've been doing it at regular intervals throughout the day for the last 10 years or so. Can't say my eyesight has improved but maybe it's prevented it from getting worse.
It was dropped because Microsoft felt it was inappropriate or embarrassing to ship an app that they themselves could not port to 64-bit, at a time when they were asking 3rd party developers to do the same.
Raymond address that in his reply to the first comment on TFA.
"That would have been even more work, because there was at the time no infrastructure in Setup for having 32-bit-only components. (And then automatically uninstalling it when WOW64 was disabled.) ..."
This website itself is not designed so well. The fixed top bar is super annoying and wastes space. (Yes, I know it's also a modern design trend. It's a terrible one.) Their site is too wide somewhere, and forces an unnecessary horizontal scroll bar on my browser. Their logo/header is pretty cool, but the rest of the site is pretty generic.
Lol, clearly this guy doesn't know it too well. So many rendering issues.
I'm not sure what to think. I mean, this guy clearly read the HTML spec where it pertains to page loads, but also clearly skipped the sections that pertain to basic layout.
Here's one reason why not: no anonymous functions longer than one line. Which is a pretty lame limitation for a modern high-level language, all due to the dumb whitespace-as-scope design.
Honest question: If you are making an anonymous function longer than one line, shouldn't you just make a normal function? What are the use cases for large anonymous functions?
Especially in a learning context, I have no problem with requiring decent names for functions.
It's a learning context, not a professional one. This strikes me as like complaining that your carpentry class won't be covering a particularly exotic tool only favored by a quarter of professional carpenters anyhow. No, it's not a fatal objection to the class. If the tool is so wonderful they'll find out about it later. After they've become familiar with things like "hammers" and "nails" and the pounding thereof, which is the real problem they face today.
I wrote a nonblocking library (for pipes/processes/signals) in Python like node.js. So many of the callbacks end up being inner functions (they don't when you decide you can make all the necessary state object-level, and thus make the callback a method).
The anonymous syntax actually reads better than defining an inner function and then calling it.
I think the real reason why they were never added is syntax, and honestly I can't think of a good syntax myself.
In JavaScript, a broadly comparable language, I mainly use anonymous functions for event handling and map/each/fold. They are also useful for implementing more advanced code like arrows cleanly.
In a lot of ways the anonymous function in these cases is more akin to a block than a named function--it's only used once and in a very clear place. Having to name my click and onload handlers would make the code more confusing.
Coincidentally, this brings me to something that annoys me in both languages: lambdas are too verbose. Having much simpler and more concise lambda syntax (I'm personally a fan of Haskell's \ x -> x because it looks like a lambda if you squint) would make a lot of common idioms more readable and would encourage wider use of custom control abstractions, which can significantly improve code.
Amusingly I don't find myself using lambda syntax nearly as much in Haskell despite the fact that it looks really nice. A surprising amount of the time simple point-free code is all that's needed, and anything too complex gets moved into a where clause. But Haskell is not really comparable with JavaScript/Python at all.
As a programmer this sounds like some pretentious bullshit. I've done so many UIs where 20 people jump in all thinking they are experts and have long drawn out discussions about how the UI should look, only to change their minds after I've done it and have another round of discussions...
Honestly, all the word "design" means to me is "I take so long to get anything done that I must plan my ass off like I only have one shot, and force everyone else to work this way".
Just get stuff done, and move on. No ones going to give a crap about your sweet design if your product doesn't do anything.
If we're talking over-designing, I agree. Design without function is worthless.
At the same time, function without design is an ugly cement cube with no windows for a house; sure, it does the trick, but I'd much rather live under the stars than in that.
