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.
Example: You might not be interested in writing a text editor, but you've seen this and the lime project, both written in Go, you don't care for writing a text editor, but you might figure you could spend some time to this guy fix an issue in your free time.
Is the above a little far-fetched? Maybe, is it unrealistic? Not really.
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.
I have a search set up that emails me daily about Clojure topics on HN. I'd be very interested to see new editors written in Clojure, and not very interested in using the editors themselves.
Tools are a means to an end. Attaching anything more to them is silly.
My thinking is more along the lines of http://erlang.org/pipermail/erlang-questions/2011-May/058768... and http://tonymorris.github.io/blog/posts/identifier-names/, but I bet your professional literature would be apopleptic at suggestions like these :]
Are you a programmer? What languages?
> Where your code is located on the filesystem is incidental complexity.
Incidental complexity is still complexity to deal with.
It isn't easy for me as a developer to find such and such routine if you've thrown everything into a big bucket named "main".
You also omitted the fact that I didn't only refer to files. I mentioned the size of functions, too. Now functions ARE logical units of code, and if you need to scroll ten screens and names are as vague as "ProcessEvent" (which is not broken down into subroutines), this doesn't speak very well about the overall design.
Thanks for the links - but it's hard not to notice that they both refer to FP languages, however (Erlang and Scala).
I wouldn't step out to judge the quality of an Erlang codebase, because that's not a paradigm I'm well familiar with.
Go, however, doesn't belong to that family. I see no reason why SRP and other oldschool principles wouldn't apply here. I'd be happy if someone told me (that's why I asked at the beginning - "or is that the language"?).
The other commenter (@mod) implied that since the project is experimental, it's done quick and dirty but that's because it's prototyping.
Note that I've never said the author of the project is a sloppy programmer, I only wondered at the code being so messy.
Perhaps the better storage layer would be function definitions living in a database. That Conception uses an unindexed flat file as the 'code database' also isn't surprising given the stage of development.
It's grounds for getting the stink-eye in code review, but to reject it out of hand is pure ideology.
>
>A module should not contain more than 400 lines of source
>code. It is better to have several small modules than one
>large one.
Spaghetti code refers to the complexity of tracing cause/effect through a set of routines increasing to the point where you can no longer safely add functionality or fix bugs without too high a risk of regressions. It has to do with the difficulty of understanding the purpose, intent, actions, and side-effects of each function.
As is often the case, splitting a function too much simply based on a LOC guideline can result in spaghetti code just as easily as it may guard against it. Functions should be atomic, re-usable, repeatable, clearly defined, and well encapsulated.
I don't see lines of code as a direct factor in judging a function implementation, as long as those lines are spent moving the feature forward and not violating "DRY".
And when they're very long, it's a warning flag indicating that they may NOT be atomic, re-usable, repeatable, clearly defined nor well encapsulated.
Also bear in mind that code is not carved in stone, but subject to constant change in every project that isn't deprecated, let alone in one under active development. This is why we judge its design not only by what qualities have been achieved up to this point - but also by whether the design serves to prevent them from deteriorating.
A long function that's reusable at the moment is at much greater risk of becoming unreusable than a concise one.
Readability is of great importance, too, since code is meant to be read by humans.
Note that the author himself kindly replied to my comment and admitted that he's going to refactor - https://news.ycombinator.com/item?id=8908307
Poor readability and messiness is acknowledged as an issue at the moment, since it is (to quote https://github.com/shurcooL/Conception-go/issues/3) "hurting readability of the project for other people". What else is poor code readability if not (to quote your words now) "difficulty of understanding the purpose, intent, actions, and side-effects"??
> I don't see lines of code as a direct factor in judging a function implementation, as long as those lines are spent moving the feature forward and not violating "DRY".
Well, in this case we have to agree to disagree I guess :)
Yeah, "if", but that's rarely the case :) Care to show me an open-source example of a function 500 lines long where you don't think one could find proper seams to split the code along? Ideally in https://github.com/shurcooL/Conception-go/blob/master/main.g...
