6 ms·
It depends on how large the code base is. Rewriting a 10k LOC project isn't a big deal, compared to a 10 mln one. And a rewrite doesn't have to target performan
by dnu 14y ago
It depends on how large the code base is. Rewriting a 10k LOC project isn't a big deal, compared to a 10 mln one. And a rewrite doesn't have to target performance only, but ease of maintenance too.
- PommeDeTerre 14y agoIf ease of long-term maintenance is a goal, then JavaScript is the wrong approach.
- nkohari 14y agoWell that's just, like, your opinion man.
- gbog 14y agoYou have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard. - Maintenance tooling may be lacking. If I were to choose a language for a project that I new will be big and will need care in 10 or 20 years, I'd hesitate, and maybe choose Java (which I hate) or Python (which I hate less). If in a risk-things mood, I'd give Go a try.
- OriginalSyn 14y agoI don't see how finding JavaScript programmers is going to be a problem in 10 years... even if they started now it would take, at least, that long to fully deprecate the language out of the browser. NodeJS may go away but I think betting on JavaScript going away are some pretty long odds.
- niggler 14y agoNode.js may be young but 98% of the code can be reused (and if you are careful, you probably wrote the fallbacks already). V8 can be built separately. When you understand the zen of javascript and try to write in a consistent manner, JS is more readable than C. I equate these concerns with arguments about how lisp or scheme is unreadable. The ecosystem for tooling is expanding, albeit slowly. However, most of your code probably could be implemented in a way that can be run in browser (e.g. XLS parser: http://niggler.github.com/js-xls/ http://niggler.github.com/js-xls/) which is where I see the real value in node. Aligning the languages means fewer moving parts and potential points of failure (as opposed to having to worry about quirks in implementations of many languages and worrying about features supported in one context but not the other)
- nkohari 14y agoTechnology and business requirements move too fast to worry about writing software that will be around 10 years from now. Choosing the best technology for your particular use case, that will also allow your software to evolve over time, is much more important than trying to predict the future. Also, I've gotta say, you completely undermined all 3 points of your argument by saying you'd choose Go.
- codygman 14y agoI don't think he undermined the second, but would like to know your opinion. Here is mine: "- Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard." Go code is almost always very simple and readable. What makes you think him choosing Go undermines the simplicity and readability arguments?
- nkohari 14y agoSimplicity and readability are subjective criteria. In my opinion, Go has many merits, but readability is not one of them.
- gbog 14y ago> Technology and business requirements move too fast to worry about writing software that will be around 10 years from now This is a common belief but I do not think it applies very well in most cases. If you write the last pic sharing thing, maybe you can dismiss worries, but if you build the next Google, entreprise or scientific software, or even something like Github, you should hope your baby to be well and alive in 10 years, and choose your tech stack accordingly. I guess.