I must be missing something, but how is EventEmitter helping you get rid of the nested code in your examples? It looks like changing all the anonymous callbacks to named functions, and then using the function names as the callbacks is what made the code more readable. EventEmitter wasn't necessary to do that, right?
Yes and no -- it's not absolutely necessary; I could've written it similarly without turning the callback-accepting functions into emitter-returning functions. It would have felt gross to do so, though. The downside I see with using straight callbacks that accept error and data arguments is that they conflate the logic of what that callback is actually attempting to do with the error-checking of the calling function. For example, my `baseDirOkay` method shouldn't care whether or not the calling `fs.stat` function succeeded or failed -- it should only care that the data it was passed is or isn't a directory. It shouldn't be called at all if the path was not valid. With an EventEmitter api, I can rely on the emitter itself to tell me whether or not to even call my `baseDirOkay` function, instead of having to conflate that logic with my method.
This seems like a tiny gain in readability, but it means that I don't have to make a decision between putting the error/success logic of `fs.readFile` in my method (where it does not go) and my calling function (where it probably does not go, and where it would incur unnecessary nesting -- and the finagling of the `this` variable that that incurs).
This may just be my taste -- but I find designing around (and reasoning about) EventEmitter-type API's much easier.
We need to turing-test people like that! But seriously, I've never encountered people who can really go that far off-topic. I'm sure it was an exaggeration, but if it was enough to change your mind about how our brains work...
Exactly. Someone once said during the AI research heyday (Minsky?) that research in artificial intelligence should be more correctly renamed to research in natural stupidity. While an exaggeration, I think he had a point.
It would seem that exchanges like these indicate the opposite. These chat bots have no understanding and anything that seems like it is just some cheap trick or other. It can't be called intelligence, in the same way we speak of human intelligence. Neither would pass the turing test.
However, I am aware that the meaning of AI is always pushed to "whatever we can't yet do". Yet, in this case it's hardly justified to think that these chatbots even slightly challenge Penrose's thesis.
I read the book too BTW, loved it. I'm not sure if he's right, but it's nevertheless a wonderful book and heartily recommend it to all.
RFC439, posted by the co-creator of TCP/IP, Vint Cerf, actually has a similar exchange between "PARRY" and the "Doctor" from 1972(!): http://tools.ietf.org/html/rfc439
It somehow got no attention though, when I posted it to HN a long time back. The title matters a bit too much, I remember keeping the original title for my post.
On a related note, I love how some early RFCs are written in a pretty whimsical manner. Perhaps it's just Vint Cerf who likes messing around? For instance, see RFC968, 'Twas the Night Before Start-up': http://www.faqs.org/rfcs/rfc968.html
It would seem pretty short-sighted for the developers to not have realized this though (though I wouldn't say the same for venture capitalists and media). I'm guessing they must have figured this out, but just don't have a solution for it yet.
For my own startup-wannabe, I had to pivot because of the same problem: the app would only be useful if millions of people were using it, the way it was originally conceived.
From the link: Degrades gracefully if JavaScript is not enabled
Graceful degradation is less common for JavaScript now than it used to be though. So if you want a smooth web experience, these days you just can't go without JavaScript. I personally don't think that's a horrible thing, but I guess most people who've disabled JavaScript (or use Lynx or something) would disagree.
The only thing I was still using Lynx for is for downloading graphics drivers on Linux. Alas, since NVIDIA did their last site update, that doesn't seem to work anymore :(
I think that if your site has a clear-cut function, you should at least try to provide that functionality even for bare-html browsers. Doesn't matter if it looks ugly, the focus is this case is on functionality not looks.
I think that's just a result of lazy programmers. Most of the sites I put together work with or without js. It's not that hard to do with a good templating engine that splits up each "ajax" part of html into a piece that can be rendered with a refetch of the entire page, or a refetch of just that part.
Deleted comments don't go dead, as far as I know. I think it was killed by someone by mistake (there are a few overzealous moderators here, or it may just have been a mis-click, or maybe even some algorithmic spam-killing, though I doubt that last one). Here's the comment from antirez:
What changed since this article was written:
1) The Server structure in the unstable branch is finally divided into sections using comments.
2) The command table is now loaded into an hash table, so the lookup is now O(1) and it is possible to alter the hash table at runtime. This is how we implement ed the command renaming and shadowing in redis.conf.
3) The shared integers are not used when diskstore is enabled, since we need tha t every object is independent with a different LRU timestamp and so forth. But o therwise using the default mode of operations (in memory) shared integers are us ed.
4) Databases are now watched for the implementation of "WATCH" using a better AP I, that is signalModifiedKey().
5) Now we listen to the TCP socket and to Unix socket if configured. The Redis C luster branch (not public) will also listen to an additional TCP port using for cluster message passing.
7) Loading data from disk to memory is now non blocking, we do this re-entering the event loop while loading data.
8) Response reading is now faster and cleaner code, thanks to Pieter's work.
This is a very nice overview. Of course only the surface is covered, there are a lot more things going on in the specific commands, in VM / diskstore command (by far the most complex part of Redis), in specially encoded data types, and in rdb/AOF loading/saving, incrementally expanding hash tables, ...
In just 30k lines of code there is already a lot to take in mind!
Basically I and Pieter already reached the point where we are experts in different areas. We both understand the whole Redis codebase, but for instance he is more expert in the sorted sets and special encoding code, I'm more expert in the diskstore things, and so forth.
Full-screen application switching has a far far greater mental-cost than having two windows open at the same time.
As an XMonad user with a 15.4" screen, I disagree. For example, when programming, I find it quite easy/fast to alt+1 to my browser for documentation, and alt+8 to go to my 8th workspace, where I usually have a couple terminals open with vim. Or sometimes I'm switching between those two and Gimp on workspace 6.
This doesn't really require XMonad, just having workspaces and quick shortcuts for moving through them is good enough. Most applications are easier to use when you give them the whole screen (at least smaller screens). But yeah, if you're using some sort of taskbar/dock to switch between applications with your mouse, it's probably easier to just have both open together.
This is true, a very-fast screen switcher mitigates the cost heavily, maybe even negates it entirely. Alt-tab never did it for me, too unpredictable. On OSX, while developing with a single monitor, I pretty often split my things between 4 desktops, and it's great.
On Windows, on the other hand, nothing switches quickly. Ever. And it takes a long time for applications to "wake up" after even short periods of non-use. Nothing but a second monitor has ever saved me.
On the iPad, currently, the situation is far worse than even Windows users suffer through. Double-tap the home button, and click the application (maybe scrolling between), which isn't in a static location. That's a non-screen action, followed by a change in the UI, followed by a touch, followed by a comparatively-slow transition. I liked someone-here's suggestion of gestures solving this, but single-tasking on anything without a separate keyboard is a total efficiency-crap-shoot everywhere, from what I've seen.
The issue that I have with desktop switching on my shiny new MacBook is that OS X switches focus between applications, not windows.
Here I've got vim and Firefox open, with the focus on vim. I switch to another desktop to glance at some documentation (since the Firefox window on the first desktop is for the application I'm developing), switch back and begin typing. But alas! My key strokes are logged to Firefox, because that was the last application I had focused, rather than to the last window I was using on the desktop.
Aside from that, once I added some basic tiling functionality[0], it's not too bad working on it, even for a someone as used to a tiling wm as me.
The examples you mention (e.g. programming, then looking something up in documentation) only require you to switch between apps rarely. In those cases, it makes sense to let each app take up the whole screen. The additional screen space each app gets is worth more to you than the mental cost of having to switch between screens.
In other cases (e.g. writing a cover letter or a job application while looking up information about the company on their website), you constantly refer to two different apps, so it makes sense to allow both to exist on the same screen.
Agreed. I suspect this notion that you incur mental cost from screen-switching comes from those who have not used a tiling window manager. Once you get used to this, a desktop is clumsy/painful to use.
I have the same layout every day: screen 1 is tmux with several xterms, one running vim; screen 2 is the browser; 3 is email; 4 is remote connections; etc.
I constantly toggle alt-1 and alt-2 to jump between vim and the browser and it takes no mental effort. Why not put them side by side? I could, but I prefer full screen.
[Your down-voter could perhaps re-read the guidelines.]
I'd encourage you to apply whether or not you have a working prototype by the 20th. In fact, apply today. You can update your application later if you have a demo or something to add to it.
