
Conception – An experimental modern IDE written in Go - baumbart
https://github.com/shurcooL/Conception
======
shurcooL
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. :)

[1] [http://liveprogramming.github.io/liveblog/2013/04/live-
progr...](http://liveprogramming.github.io/liveblog/2013/04/live-programming-
contest-winners/)

[2] [https://github.com/shurcooL/Conception-
go](https://github.com/shurcooL/Conception-go)

[3] [https://github.com/shurcooL/Conception-
go/graphs/contributor...](https://github.com/shurcooL/Conception-
go/graphs/contributors)

[4] [https://github.com/shurcooL/Conception-
go#installation](https://github.com/shurcooL/Conception-go#installation)

~~~
zefei
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.

~~~
hueving
>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.

~~~
seanmcdirmid
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.

------
mostafah
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.

~~~
zobzu
PR seriously. Link had far less chances to get on the fromt page without PR
keywords like "written in Go".

Still interesting tho.

~~~
mostafah
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?

~~~
mod
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.

~~~
loevborg
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.

~~~
redox_
You should give a try to [http://hnwatcher.com](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
;)

~~~
mod
This or IFTTT are the two methods I've used.

Both work well.

~~~
loevborg
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.

------
20kleagues
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.

~~~
erglkjahlkh
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.

------
joefreeman
The images are broken for me (503s from Dropbox, and 404s from GitHub cache) -
here's a direct link to the video:
[https://www.youtube.com/watch?v=DNJ7HqlV55k](https://www.youtube.com/watch?v=DNJ7HqlV55k)

------
bojo
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.

~~~
keyle
Not really. You're thinking of blueprints. They're quite different as there is
no typing involved (beyond power user shortcuts)

[http://i.imgur.com/T2p18c5.png](http://i.imgur.com/T2p18c5.png)

~~~
Gurkenmaster
That looks like flowbased programming in a nutshell. Except you can't create
your own components.

~~~
Moter8
Which is wrong, you can program in C++ and make thhose functions available in
Blueprints too.

------
VMG
I love the instant update and the tight feedback loop. This is what I actually
want when I hack together my _inotifywatch_ command in the shell.

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.

------
avinassh
link to Go repo: [https://github.com/shurcooL/Conception-
go](https://github.com/shurcooL/Conception-go)

------
fishnchips
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.

~~~
exit
"If a man cannot forget, he will never amount to much." \- Kierkegaard

~~~
fishnchips
"Good enough is the enemy of the great" \- Grumpy Cat (attributed)

------
keyle
Lovely. Here is some cheap feedback from a UX perspective.

Give a bit of padding to your text blocks

Identify clearly the input from output

And adding syntax colouring will give it 300% sweetness.

~~~
shurcooL
The Go version has had syntax highlighting for a while now. :)

------
aikah
All screenshots are gone in the README,please use github pages instead of
hotlinking the repo directly.

------
niutech
Looks similar to Code Bubbles.

------
jaked89
The images won't load.

------
V-2
Sweet lord, [https://github.com/shurcooL/Conception-
go/blob/master/main.g...](https://github.com/shurcooL/Conception-
go/blob/master/main.go) is nearly 9k lines long!

What a spaghetti. Is that the author or the language?

~~~
shurcooL
It's an open issue, please see [https://github.com/shurcooL/Conception-
go/issues/3](https://github.com/shurcooL/Conception-go/issues/3) for more
context.

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.

~~~
V-2
Thanks for the clarification! Best luck with the project.

