Author here. I was just about to go sleep when I noticed a retweet and a lot of new stars on Conception; this explains it.
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. :)
Developers who re-invent/re-imagine some wheels usually realize at the end why the original wheels are designed like those. We, understandably, don't quite appreciate the work other people have done, where we consider their tradeoffs as mistakes. But when we do them ourselves, we eventually see the huge amount of conflicting goals, as tradeoff is the essence of engineering, or anything.
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.
> Developers who re-invent/re-imagine some wheels usually realize at the end why the original wheels are designed like those.
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.
>We, understandably, don't quite appreciate the work other people have done, where we consider their tradeoffs as mistakes.
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 is important to distinguish between prototypes and demos vs. products meant for consumption; many people easily get confused that all released code should somehow be shippable. This is why I'm hesitant to release my own demos even though I get a lot of requests for them.
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.
It would be awesome if you could blog about it or share your notes!
I'm very interested in reading this too, but please don't let "set up a blog" be a blocker on "share what I learned". You could just add a findings.md to the repository
I don't blog either... but then once every few years I do and it turns out that when blogging when you actually have something to say is valuable to people.
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.
> Feel free to steal any good ideas you see here. My goal is to benefit the world as much as possible; personal gains are a lesser priority.
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
I like it! I've been thinking a lot about user interfaces for creating programs and gaining insight into execution lately, so I'm really glad to have seen this. From the demo video, it looked a little cumbersome to move everything around and it seems like your workbench can get disorganized quickly. Have you experimented with layouting at all? Also does it actually feel cumbersome in practice, or is that a misconception from just watching the video? Anyway, great effort. Looking forward to see this develop.
After watching the demo video I though it looks cool, but impractical and ineffective for non-demo usage. It looks heavily dependent on mouse centric Bluebottle-style zoom/scroll desktop and drag-and-drop windows/widgets. Do you have plans/ideas how to transfer some of the advantages to a more keyboard centric, tabbed/tiled window management UI, and if that would be more practical and effective in non-demo usage scenarios?
I just have to say, I've been following this project for awhile. I've been hoping that it progresses beyond experimental stages. The two concept videos on YouTube are great.
> 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
Can you give some examples? It might be very valuable to share your conclusions.
Why should being written in a particular language matter? We see a lot of these “written in Go”s these days for a lot of new softwares. I’m a big user of Go myself. Love the language and use it for almost everything. But I just don’t get why an editor or IDE or static site generator or any other piece of software brag about using a particular language or library.
For me, the language of a project has a large impact on whether I would consider contributing to it or not. When I dislike the language, I'll usually not want to be involved with the project, but just watch it growing. Thus, it makes a project more interesting for me if the language is nice.
I know. That’s kind of true for all of us. But yet I believe this is not that important. Specially not important enough to put the language like a badge of honor beside the project’s name or description in the title, like how these “written in Go”s are.
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.
Your last sentence while intuitively seems true, simply isn't. There are plenty reasons some one might contribute to a project, the language could be the only reason, and that would be completely reasonable.
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.
For me the fact that Go programs don't have a runtime dependency like python or ruby makes a big difference.
There are a lot of cool projects written in python or ruby which I would love to try but knowing that I have to setup rbenv/rvm/virtualenv/etc just to try it is a big inconvenience for me (or you could just install it globally for the system/user but I generally avoid that).
It's Hacker News. A community of hackers. The first thing I look at when someone shares a project is what language it's implemented in because it is interesting to see how other hackers' approaches. Having "... written in X lang" in the title just makes it easier to find projects I may have interest in.
You’re right. What makes this project interesting is the idea and the design, not Go, yet it would be much harder to get this publicity through that. And that’s exactly what I’m saying: why should people upvote just because of the language?
People can be interested in the link for two different reasons, now. Some people want to see a new editor; some people want to see the source code.
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.
Setting up email alerts for Clojure stories sounds useful. Can you describe how you do that? I couldn't find a way to set up alerts, either using hn.algolia.com or using Google Alerts.
You should give a try to http://hnwatcher.com, it's an alerting tool based on the HN Search API. I personally follow the "algolia" keyword -> it helped me get your question mentioning "hn.algolia.com". Enjoy ;)
Thanks! I'll try hnwatcher.com for now. I emailed the creators because I didn't get a confirmation email yet, but it looks like what I was looking for.
I think you mean "it sucks that we do that" and i agree. It seems to me this is an eternal problem with our large communities. With internet everything is a large community ;)
Sikuli is also based on a similar idea and is written in Python. I am guessing it boils down to preference, but writing code as it is written now involves a lot less 'mouse' and much more keyboard, which most developers, me included, take for granted.
I do agree that currently code written has very high limitations on re-usability, primarily because code is written with a specific project in mind. I believe two things can be done to make it more re-usable:
1) either have all developers write code with the idea in mind that they are writing independent libraries and not code for part of a bigger project so the code becomes much much more modular and decoupled and can be used in other projects on the fly.
2) create an extension which creates a project specific visual map for the code, which would in turn allow other developers to pick and choose code to their liking while having a greater understanding of how the code actually works.
This being said, the author's efforts are much commendable.
This indeed is commendable. There are more possibilities than what he has touched so far.
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.
Is this similar to what Epic Games has been doing with their Unreal Engine, specifically the Blueprint system? The main difference appears to be that you can directly write code, which does seem more powerful. There's a lot of power in bridging the gap between developers and designers, would love to see where this goes.
This looks insanely cool (congrats!) but from a purely practical perspective I'm not sure if I'd want to use it even if it was a perfect, finished product. After all, I'd have to forget everything I ever learned about text editors and IDEs.
How do you visualize diffs and conflicts, though? I imagine it must be different from version control as we know it, effectively forcing you to relearn this part of our skillset...
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.
> 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 one of those "software engineering best practices" that sounds nice but has no basis in reality. What matters is the formal structure of your program: types, composition, state, capabilities. Where your code is located on the filesystem is incidental complexity.
> This is one of those "software engineering best practices" that sounds nice but has no basis in reality
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.
Considering a major goal of the project / approach is precisely to deprecate the the hierarchical and file-based approach to programming, it doesn't really surprise me to find all the code in a single file.
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.
I get paid to program c, c++, java, python, and r (not necessarily in that order, with other languages as needed) and there's nothing inherently wrong with a 500 line method if that's what the problem calls for.
It's grounds for getting the stink-eye in code review, but to reject it out of hand is pure ideology.
"there's nothing inherently wrong with a 500 line method if that's what the problem calls for"
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...
I'll bite. We were just talking about spaghetti code in the context of the Toyota ETCS. In that case, static analysis was used to measure the cyclomatic complexity of the code and even then some comments claimed that wasn't enough to immediately qualify as 'spaghetti code'. https://news.ycombinator.com/item?id=8905718
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".
> Functions should be atomic, re-usable, repeatable, clearly defined, and well encapsulated.
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.
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 :)
The thing about spaghetti code is it's like spaghetti: if you try to follow one strand (of execution or pasta) you get mixed up with all other strands.
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