However, almost all the good new things came from some re-invention. Don't let the tradeoff scare you away from your original ideas. Maybe the whole interface doesn't beat what we have now, but there are quite a few very good stuff in your demo. And I believe some of them (zoomable overviews, widgets), can truly work better than what we have now. It somehow reminds me of Rob Pike's Acme editor, though they look very different.
While that is true, I do also think it's healthy to have some scepticism about the design of projects because some are just poorly executed (either because it's based on an outdated model that everyone has stuck to because it's the standard way of doing things, or because of time constraints, or sometimes just because of a lack of love for the project).
Sometimes it's worth people re-inventing the while just to see for themselves as occasionally a new developer might just have a unique perspective that results in them solving a previously considered "unsolvable problem".
Obviously this philosophy isn't without it's drawbacks. But sometimes it's worth testing the old standards.
Part of this is because it's hard to differentiate between crap and something that was well-designed without putting the time into researching it. This leads developers to just assume most things are crap unfortunately.
It's really interesting to go back to my old notes and
goals and, with hindsight, truly understand _why_ they
didn't work out, and what it would take to make them work.
Sadly, I don't do any blogging, but I'll see if I can do something about that.
Try medium, it works for such infrequent blog posts... and post the link back on here and we'll all get an insight into the learnings.
The project has no licensee, so it's effectively all-rights-reserved. To make the code usable by others, you should select a license, but be sure you understand that with many licenses anyone can copy/fork/rename/translate/extend/repack the project.
Don't be creative and stick to a standard license like BSD/MIT/LGPL/GPL and a few more. They are not equivalent. Take your time to select the one you prefer for your intentions and your definition of open/free. https://www.google.com/?q=mit+bsd+lgpl+gpl
Can you give some examples? It might be very valuable to share your conclusions.
The linked C++ project was the result of an initial year of working on it, which culminated in a winning entry to LIVE 2013 contest [1] and me switching to working on a version of it written completely in Go [2]. I no longer work actively on the C++ version, but I do on the Go one [3].
Primarily, it has been an extremely insightful learning experience. I had a lot of ideas and I wanted to try them, and by building Conception I found out the reasons why certain things that are commonly desired do not actually work well in practice, and why our seemingly outdated practices of writing code no different than decades ago are still so predominant and effective.
It's really interesting to go back to my old notes and goals and, with hindsight, truly understand _why_ they didn't work out, and what it would take to make them work.
The Go version is go-gettable and working [4] despite having lots of dependences (as proven by the green Travis build). This is one of the benefits of using Go and not the case for C++ version. You can easily try it, but at this point the UI is so far from finished, it's not really fit for general use. If you're interested, I highly recommend watching the repo so you'll see further development. :)
[1] http://liveprogramming.github.io/liveblog/2013/04/live-progr...
[2] https://github.com/shurcooL/Conception-go
[3] https://github.com/shurcooL/Conception-go/graphs/contributor...
[4] https://github.com/shurcooL/Conception-go#installation