[markdennehy]

Why expend manpower and energy improving a working solution just to do so when you have so many other broken things that need fixing first? That's a fairly self-answering question. There's a reason the expression is "If it's not broken, don't fix it".

[efuquen]

We have tools that have virtually been unchanged for over 20 years. While the consistency and stability has been nice, there has been a lot of good things that have happened in software development and technology that those tools could really benefit from. You're honestly going to tell me you don't think that taking a second look at these tools and seeing how we could improve them would be a good thing?

What you're basically advocating is nobody should innovate because things are "good enough". With that sort of attitude we would never have any progress on anything.

[markdennehy]

That's not what I'm advocating. What I'm advocating is not wasting time and effort rewriting working tools just because the rewrite would be newer.

Which is not what you're saying I'm advocating.

[Ideka]

Nobody thinks it's a good idea to rewrite something just to make it "newer". The idea is to rewrite (or maybe just refactor) these tools to make them better.

It's also not "fixing what's not broken", but improving something that could... well... be improved.

[dllthomas]

While the core interaction remains unchanged, 20 years ago was before bash 2.0. The version running on my laptop, bash 4.2, was released in February 2011. The development speed hasn't been blindingly fast, but it's a fairly mature project with scripting support (so less need to extend the core than some projects have), and there have absolutely been changes even in the last 5 years.

http://tiswww.case.edu/php/chet/bash/NEWS

[Perseids]

If you fear breaking it, why not replace / revolutionize instead. See GCC vs LLVM, X vs Wayland, C++ vs Go.

[jhasse]

> C++ vs Go

Bad example :P