ehsanul

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?

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

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...

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.

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.

Did you get in? If not, were you invited for an interview?

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.

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.

You made me look this up. *Is it "concision" or "conciseness" - http://raymondpward.typepad.com/rainman2/2005/11/is_it_conci...

Should be "Scheme -> C compiler".

I'm no security expert, but I don't think you even need an out-of-band key exchange mechanism. Just use public key cryptography [1], as used in SSH/TLS/PGP/GPG.

[1] http://en.wikipedia.org/wiki/Public-key_cryptography

This could be very painful for the likes of Mahalo. I remember Jason Calcanis mentioning, perhaps when he first noted a change of direction for Mahalo to high-quality content, that he'll make sure Mahalo is the number one Google result for "how to cook a turkey" and similar queries, where they've spent hundreds of dollars (maybe more) on quality content, notably videos. I just Googled "how to cook a turkey", without quotes, and Mahalo is nowhere to be seen! Not sure if tha t's a good thing or a bad thing, but the guys at Mahalo might just be freaking out right now.

Yeah, it's overlooked by many that the Chrome isn't all that extensible compared to what you can do in Firefox with addons. Chrome's developer tools are built in because they must be, whereas Firebug should be able to do anything that Firefox does natively (though I think it may be mostly Javascript now).

Maybe you'd like Mirah?

http://www.mirah.org/

I've been listening to those talks.

They're only about an hour to 1.5 hours long, and there's only 6 of them. They are supposed to be spread over a 6 week period. So every week for six weeks, you need to find an hour to spend listening to the talk for that week.

You will be meditating during part of the talk. Other days, you will meditate 20-30 minutes. This is not a large time commitment, and since you're on HN, I'm guessing you'd be able to manage.

Good luck! The first two talks have been pretty nice so far.

With bezier curves (it's prettier) in Canvas/Coffeescript (assuming an existing global canvas context 'ctx'):

    heart = (scale,x,y)->
      ctx.beginPath()
      ctx.moveTo(x,y)
      p1 = [x-75*scale,y+20*scale]
      ctx.bezierCurveTo(x-20*scale,y-55*scale,p1[0]-50*scale,p1[1]-55*scale,p1...)
      p2 = [x,p1[1]+60*scale]
      ctx.bezierCurveTo(p1[0]+25*scale,p1[1]+22.5*scale,p2[0]-35*scale,p2[1]-40*scale,p2...)

      ctx.moveTo(x,y)
      p1 = [x+75*scale,y+20*scale]
      ctx.bezierCurveTo(x+20*scale,y-55*scale,p1[0]+50*scale,p1[1]-55*scale,p1...)
      p2 = [x,p1[1]+60*scale]
      ctx.bezierCurveTo(p1[0]-25*scale,p1[1]+22.5*scale,p2[0]+35*scale,p2[1]-40*scale,p2...)

      ctx.strokeStyle = 'rgba(255,40,20,0.7)'
      ctx.stroke()
    
    heart(1.0, 450, 250)

Also would be interesting to see how HN points are correlated to page views.

And raganwald was referring to the '#!' hack, since it's really just the '#' hack. He wasn't addressing the history api.

Note the account's name, 'TrollBait'. Brand new too. If he keeps those kinds of comments up, he'll be banned in no time.

On the other hand, I'm impressed how you just ignored TrollBait's insult and just replied in an absolutely normal manner.

Would you be willing to answer a few questions? I'm a recent mechanical engineering graduate (interest in dynamics/control systems) who likes programming. So I'm pretty interested in the type of work you're involved in and want to see if I can get into it somehow. Couldn't find an email in your profile, but mine's ehsanul@ehsanul.com, if you're open to discussion. Thanks!

Thanks for signing up! (assuming you did)

Counterexample: I doubt the current implementation of pagerank+additions at Google is all that simple.

They had no remorse for the detrimental outcomes they brought upon those they stole from... no compassion whatsoever.

Sounds like they were simply psychopaths, hence lacking most emotion. It seems like that emotion/empathy was selected for in our evolutionary history (or perhaps it's just a side-effect of something else, don't know), so I don't think psychopathic behavior could possibly be characterized as darwinism.

There's a theory from the latest TED talk that says our survival prior to inventing weapons (like spears) depended on running other animals to exhaustion.

http://www.youtube.com/user/tedtalksdirector#p/u/0/b-iGZPtWX...

While you start off with some (probably deserved) snark, I want to thank you for the way you wrote your second paragraph. I wish every downvote HN newcomers get came with a comment like that.

Oh, oops. Sorry, me and at least 3 others had a collective brain fart it seems. I had first thought you meant that both of those sets of compiler flags weren't quite right.

You're probably right, I'm an amateur at this. My current solution works pretty well, but I should really drill into what may be wrong here.

If you don't mind me asking, what in your estimation would be an ideal query plan for a join of the type I've described? A hash join? Also, I've left statistics to their defaults and run ANALYZE after bulk data uploads (the only time data is written), but I'll try bumping statistics collection up and running VACUUM ANALYZE again. I don't know what server configuration could be messed up to cause something like this; I have my memory settings (shared_buffers, effective_cache_size) set up fine, and cost parameters have been left alone. Other configuration settings I've changed shouldn't be affecting read queries.