Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Have a quick look at the code graphs of Grunt: https://github.com/gruntjs/grunt/graphs/contributors

Also, consider how the main contributor (cowboy) last commited in May 2015. This is just a cursory github-health-scan (tm), but it tells me two things:

- Don't expect any large changes in the grunt code-base in the coming years - The code-base is probably not easily modified (either caused by low code quality or of the risk of breaking builds).



Don't expect any large changes in the grunt code-base in the coming years

A lot of people consider that a good thing.


TeX is probably a great example where the codebase converged on 'perfection'. A fixed set of features, practically bug-free, superb quality.

I could mention some flaws of TeX, and observe how many are related to input, output and environment:

- archaic syntax. Even though it has an interesting design philosophy, it does not adhere to the syntax (input) most programmers are used to (you know if you ever tried to write TeX)

- does not take advantage of modern system architectures. Needs to process a TeX file multiple times.

- does not allow animation (this was not a requirement, nor a possibility back in the 70's)

- not much interactivity (yes, URLs are possible, but it's mostly a hack). Web wasn't available back then.

- output format (DVI) limits possibilities

So, even though I like TeX and its attention to detail, it was already dated when I started using it in 2000. In our landscape, adaptability is an important trait of libraries.


TeX still works on files from the 80s. It sucks when every [any] update to a library requires me to rewrite code.


This is exceptionally true when the code I would have to rewrite is my build logic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: