I switched to vim-plug from Vundle a couple of weeks ago, and I'm in love. Lazy initialization and, if your vim is built with ruby, threaded plugin installations and upgrades. As a bonus, it's beautiful.
It would be a shame for man-millennia of work to be lost, but it would also be a shame for advancement to be stalled by these kinds of concerns. Experimenting with new approaches and ideas, direct competition between projects, excitement over new languages and frameworks. These are all factors that lead to advancing the state of the art.
It's worth being concerned about losing the lessons learned from Qt, but this is a kind of false dichotomy between the old and the new.
With that said, I don't think those lessons will be lost anyway. Qt can't (and shouldn't!) last forever or remain in its current form. C++, though it will live for a long time yet, will eventually fall out of favor, and large sections will eventually be purged from Qt as the project matures. The man-years that went into the portions that were, or some day will be, removed have taught Qt developers and users a great deal.
Qt developers and users will bring knowledge and wisdom to new projects that will compete with Qt (directly or indirectly). Some projects will survive and some won't. Some will be much the same as Qt, while some will be completely different from the start. Conrod, as it happens, is an approach to a different kind of GUI development (see this comment: https://news.ycombinator.com/item?id=8244224).
This, of course, doesn't include developers who do their own things without ever using Qt. Hopefully, they will encounter blog posts and articles about some of those lessons, as well as attracting developers who've learned some of these lessons.
This isn't a case of getting away with reinventing the industry. In this nascent stage, computer science, with all the renegade hackers and developers, is still a necessary occurrence when new languages and frameworks are invented.
As a novice, it took several hours to wade through the configuration files when setting up an IRCd, and additional time to configure services daemons. I also continually run into issues with configuration decisions I made before using the daemon more actively.
While I could have relied on the defaults, I wouldn't trust my users' data with a default configuration. It would be irresponsible at best, and this is even more important to companies.
I assume the the people choosing the methods of communication for startups are capable of learning to use irssi or weechat, but both of those clients take quite a bit time to learn and require significant amounts of customization to make them truly comfortable. It isn't a good business decision to require your teams to learn to use these tools.
Is IRC an acceptable medium for a company? Maybe it can be. Is it wise? Not with tools like irssi.
Which is wonderful if you're an old hat who enjoys having new people get frustrated and leave before they have a chance to contribute to the ecosystem.
I wonder which title attracts a larger audience. Maybe confident developers would assume “five things every competent Javascript developer must know” would contain nothing new to them, while “5 tips to become a better Javascript developer” promises to offer something new.
Improving education involves improving the approaches used by teachers, whether teachers already employed or new teachers. These kinds of things don't change overnight, but they can be changed over generations. Studies are, in theory, an effective way to determine what aspiring teachers should know and apply.
I don't think driving down the advantages of becoming a teacher is an effective way to improve performance. Many people interested in making a difference would, rightfully, forgo being a teacher for their own sakes and take a different approach.
Mozilla is comprised of a lot of different people working on a lot of different things. There are people focusing on various memory and speed issues, but they can't (and shouldn't) allocate all their resources to focusing on just a few issues.
yarou obviously didn't say that they should focus everyone only on reducing Firefox's memory usage and performance problems. I'm not sure how you mistakenly got that impression, because that's clearly not what that comments suggests.
The main issue here is that we've been hearing that these problems will be fixed, or even that they supposedly have been fixed, yet they're still present years later.
Whatever work is being done clearly isn't having much of an impact. Users are still reporting problems with Firefox's performance and memory usage, even if those within the Mozilla community wish to deny these problems exist, or claim that they'll be fixed "soon".
Users can only take so much of this. With Chrome and Firefox offering UIs that are pretty much identical these days, but Chrome offering significantly better performance and significantly lower memory usage, any reasonable user will obviously consider switching from Firefox to Chrome. Many have done so already, and many will continue to do so as time goes on.
yarou's comment is in response to a presentation about unrelated features, and his/her response suggests knowledge that Mozilla isn't focusing on memory and performance problems.
Many of the memory leaks have been fixed over the years, benchmarks suggest [Firefox can compete with Chrome in terms of speed](www.tomshardware.com/reviews/chrome-27-firefox-21-opera-next,3534-12.html), and Mozilla, realizing their UI still feels sluggish, launched a project (called Snappy) to fight this UI sluggishness.
Many improvements have been made over the years on all counts.
