Hacker News new | comments | show | ask | jobs | submit login

That isn't really a problem. The problem is that people never pause and reflect over it once they reach some critical adoption. OPs software might never have been a productive business if he micro optimized some C++ code in pursuit of best possible performance. Make it work, then make it fast if you need to, but only if you need to.



As Dewie also pointed out, it is about keeping performance and efficiency in mind when programming and not about squeezing out the last drop of performance before going live. Not thinking about it from the start will cause a lot of trouble in the long run and might make the transition to something more efficient quite painful or "impossible".


> OPs software might never have been a productive business if he micro optimized some C++ code in pursuit of best possible performance.

It's not an either-or. Maybe the best long-term approach would be to write it in a high-level style favouring readability, productivity and adaptiveness, while also being conscious not to use features that could lead to performance problems. Maybe you'd write it in a compiled (native/efficient VM) language[1] with garbage collection and be mindful of memory layout, instead of writing it in Ruby[2]and then having to rewrite some parts in another generally faster language later. Then you also wouldn't have to have that "Ugh, now I need to bust out C++/C/Go/Whatever and rewrite that stuff... oh never mind it's probably fast enough" when you start to run into performance problems.

[1] More precisely an implementation of a language which is compiled...

[2] Though maybe Ruby is compiled in the canonical implementation, for all I know.


10/10, would agree again.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: