283 karma · joined September 22, 2010
>>> def deriv(f):
... dx = 0.0001
... def fp(x):
... return (f(x + dx) - f(x)) / dx
... return fp
...
>>> cube = lambda x: x**3
>>> deriv(cube)(2.0)
12.000600010022566Arbitrary decisions from an executive may or may not be better than popularity contests. I guess it depends on the executives and the culture.
How can Skype pretend something is desirable if it goes away automatically when you pay? That's nearly the definition of undesirable.
This is the same way I feel when programmers complain about writing "just another CRUD app." CRUD apps are in fact very difficult to write because of usability concerns. If all of your "create" screens look exactly the same no matter what is being created, that means you are making no effort as a UI designer to anticipate common creation patterns. Even assuming a cookie-cutter UI, a CRUD programmer has to properly model the concepts in data, which is not trivial either.
I found music theory knowledge very helpful when learning how to play guitar. In fact, if somebody knows what intervals a minor triad and a major triad are made of, and they know what note each string of the guitar is, then they can work out how to play a lot of chords.
The interesting thing isn't how funny it is that the mind screws up sometimes, it's knowing the actual mechanisms of perception, cognition, memory, behavior, etc. Edge cases and failures are only the beginning of understanding, because they hint at how things work.
For example, visual perception is heavily based on detecting edges. So there are a set of optical illusions where you fail to accurately perceive the colors or shades of different areas (like the chessboard illusion), because the relative shading of adjacent areas is more important for producing edges and shapes in your mind.
I can't take this statement seriously. Have you ever even taken an intro cognition or perception class? Almost everything is about how minds typically work, and all of the findings are less than one hundred years old.
In Python, I would just say something like, ‘Get up and go through the door.’ In other languages, I might have to say something like, ‘Stand up, but not with so much force that you fall over, take three steps to the north, take one step to the east, approach the door, check that it is open, if it is not open, open it, then step through it with this amount of speed …’
The first problem is similar to the second, yes. They both still need to be solved, so what is your point?
Unreliable services are everywhere. So what's your universal solution for dealing with them? I'll give a concrete example: suppose I have a JSON service being consumed by a Javascript web UI, and my service needs to hit some kind of authentication backend. In the event that the authentication backend server is [pick one: down, giving 500 errors, being slow], what kind of response does my service give to the Javascript app, and what kind of message or visual cue does the app give to the user? If you think the answer is something other than "it depends on exactly what the application does", then I disagree.
If you think latency is the problem, why are you talking about building in latency? It seems like you actually think chatty APIs are the problem. And, yes, chatty APIs can cause slowness. But chatty APIs often exist because they are the simplest possible design. Once you realize that there is too much back-and-forth you may have to sacrifice API usability and simplicity by adding caching and eager-loading code. Again, you think this is just something that solves itself?
- Designing usable APIs, which is to say identifying which aspects of System A are most important to System B, how the concepts should be transformed, and how the data should be aggregated.
- Catching errors thrown by one system when data is requested from another system and relaying, translating, or suppressing these errors. Also developing policies for dealing with unreliable services.
- Performance issues.
I'm not being facetious, I just think that seems contradictory. If I had a lot of money and that same knowledge, I would invest very conservatively.