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...
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.
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.
If a projects seems interesting enough for someone, it’s more than easy to see what language is it written in. BTW, that’s how things work: you don’t decide to contribute to a project because it’s written in your favorite language. You first have to like the project itself, and if it happens to be in a language you’re comfortable with, you may contribute to it.
Still interesting tho.
He could add automatically reloading live code, and link the testing suite... You see a bug, correct it, and the test suite runs continuously at the spots where the code is compilable, giving feedback per code fragment.
Was curious what the main difference was.
But I can't do the clicking and dragging. If the layout was automatic and controllable via keyboard, I'd give this a serious look.
Give a bit of padding to your text blocks
Identify clearly the input from output
And adding syntax colouring will give it 300% sweetness.
What a spaghetti. Is that the author or the language?
It was helpful to me to keep everything in a huge file during initial development for a few reasons:
- I wanted to learn what happens when you break the convention that a project should be split into many files.
- I wanted to test the limits of various tools I am using and building. The main.go kinda works as a worst case scenario so I can look at performance of my code and existing tools like sublime text, goimports, gocode, etc.
- It allowed me to make faster progress implementing tasks in my limited free time, and I plan to delete/refactor the code to be nicer and more readable over time.
It's effectively a compromise/trade off, I did not optimize for having the cleanest code as my top priority.
Every software developer worth his (or her) salt.
> what matters is the formal structure of the code
Yes, and splitting code into well named files is a starting point for giving it proper structure.
The same goes for the size of your functions. Here some (like "ProcessEvent") consist of nearly 500 lines... that's roughly 10 screens. Textbook spaghetti code.
Overly long code files are difficult to maintain and introduce various practical problems, eg. greater likelihood of merge conflicts. That's why they're considered a red flag in software engineering. Professional literature on software development elaborates more on the subject if you don't want to take my word for it
> This is a work in progress Go implementation of Conception.
> ...Conception is an experimental project.
