6 ms·

Practice what you preach. Passive-aggressively sniping at asynchronous code by implying it can never be small or light is not a valid argument. There is no "mea

Practice what you preach. Passive-aggressively sniping at asynchronous code by implying it can never be small or light is not a valid argument. There is no "meat" to such a subjective position.

judofyr 14y ago
Callback-based code will always be more complex than synchronous code (and I believe that's an objective observation), but please let's not go there. My remark was against their "Keep your code small and light". Making your code lighter doesn't always make it faster. If you can get your code to do less (like, skipping memory-based sessions), that will make it faster. If all you're doing is avoiding complexity, there's no guarantee it will be perform better. The proper way is to benchmark and profile. You can refactor your code based on developer happiness, but only try increase its performance based on objective data. EDIT: I should probably clarify this (although it seems silly to have to do this on HN): I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.
- btilly 14y ago
  Inside of an asynchronous framework where every call blocks all others (eg Node.js), callback-based code is almost always going to be the right choice. If you can't immediately produce the answer, don't wait. And if you can immediately produce the answer but it will take a while, break it up into multiple smaller computations so that you do not block. If you are in a different environment, the arguments for/against become much different.
- sausagefeet 14y ago
  > I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea. Node doesn't really give you much of a choice. If something is going to take awhile then you will be using callbacks, it's that simple.

Practice what you preach. Passive-aggressively sniping at asynchronous code by implying it can never be small or light is not a valid argument. There is no "meat" to such a subjective position.

judofyr 14y ago

Callback-based code will always be more complex than synchronous code (and I believe that's an objective observation), but please let's not go there. My remark was against their "Keep your code small and light". Making your code lighter doesn't always make it faster. If you can get your code to do less (like, skipping memory-based sessions), that will make it faster. If all you're doing is avoiding complexity, there's no guarantee it will be perform better. The proper way is to benchmark and profile. You can refactor your code based on developer happiness, but only try increase its performance based on objective data. EDIT: I should probably clarify this (although it seems silly to have to do this on HN): I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea.

btilly 14y ago
Inside of an asynchronous framework where every call blocks all others (eg Node.js), callback-based code is almost always going to be the right choice. If you can't immediately produce the answer, don't wait. And if you can immediately produce the answer but it will take a while, break it up into multiple smaller computations so that you do not block. If you are in a different environment, the arguments for/against become much different.
sausagefeet 14y ago
> I consider callback-based code yet another tool for solving problems, not something you preach for/against. There is a time and place for callback-based code, just as there is a time and place where it's not a good idea. Node doesn't really give you much of a choice. If something is going to take awhile then you will be using callbacks, it's that simple.