▲ | panny 17 hours ago | ||||||||||||||||
Those "over complex" code bases like curl handle a lot of edge cases. Your 300 lines of C is starting over and relearning what they already learned. | |||||||||||||||||
▲ | dwoldrich 15 hours ago | parent | next [-] | ||||||||||||||||
Also, software is hard to write, and second system syndrome causes loads of loathing and misery even when the goal is to "do it right, aka simple, this time." That said, sometimes we need to take on the risk and effort of making a second system. I have often thought about the relearning/doomed-to-repeat-history problem, and I wonder if software - especially some open source software - might be uniquely positioned to build a second system due to bug trackers. The bug trackers in software like Firefox effectively capture a large percentage of a project's history and design decisions. It seems to me that the bug tracker for a projects' predecessor could lay the proper frame for its successor. | |||||||||||||||||
▲ | yobibyte 17 hours ago | parent | prev | next [-] | ||||||||||||||||
I agree! However in many cases, these edge cases (I'm not speaking of curl now) are not needed for my personal use. E.g. if I use linux/windows/os, I do not care about how my tool behaves on the other os, I do not want to support all kind of hardware etc. If I am the only users, I can prune these use-cases (and features I mentioned in the post) significantly. E.g. I reimplement a subset of vim at the moment, I do not use LSPs or syntax highlighting in my work, I do not need to implement support for them in my editor. | |||||||||||||||||
| |||||||||||||||||
▲ | g-b-r 16 hours ago | parent | prev [-] | ||||||||||||||||
and a lot of legacy baggage. We should begin collecting and centralizing the insights learned from the development of software outside the source code of specific projects |