Conception

I used to care about DRY to a _very_ great degree [0], and I still do. But I've come to realize DRY is much better to apply for high level _concepts_, ideas, and architectures, not unexported helper code. It's unhelpful to try to apply it to little snippets of code and helpers. It's much less expensive to copy a snippet that's needed and duplicate it 1-2 times before starting to worry about factoring it out. By the time it's repeated 3+ times, you'll have a much better idea how to structure it. [0] https://github.com/shurcooL/Conception#motivation

It's cool to see more people thinking about and experimenting with this stuff. I've done a similar attempt with my Conception project, https://github.com/shurcooL/Conception#demonstration One reason "all code editors look the same" is because they're really mostly "text editors" with some coding-functionality on top. And as tikhonj explains, they display text prominently like image editors display images. I used to think writing code as text was an inefficient legacy decision and that moving up to working with higher level concepts would be a big improvement, since we usually think about code at a higher level than an ascii-character-at-a-time. However, the limiting factor is the input hardware we use to interact with computers. The most efficient input device is a keyboard, and text is most efficient to manipulate with a keyboard.

Compare: https://github.com/shurcooL/Conception-go - Go, 7'500 lines https://github.com/shurcooL/Conception - C++, 15'000 lines Which would you rather work with? You can look at the commit activity to see my preference.

Neat stuff. I'm fascinated by the potential in this field, and working on implementing some ideas too. You see some of my efforts at https://github.com/shurcooL/Conception#demonstration, if you haven't already.

Go makes it very easy to create tools on top of it. And its fast compiler enables doing things almost as if it's a dynamic language. I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use). There are other REPL-like tools like [2] and [3]. [1] https://github.com/shurcooL/Conception#demonstration [2] https://github.com/sriram-srinivasan/gore [3] https://github.com/shurcooL/goe#examples

How about instead of writing just an opensource sublime text clone. We sit down as a community and discuss how we can create an even better editor than Sublime Text. There are some awesome text editors out there that have features I wish were in sublime text but sadly arent. For example, Rob Pike's acme editor has some really awesome ideas like mouse chording, (contextual right click. middle click command executions, etc), 9p vfs interfaces that allow plugins to be written in any language. And then there are little experimental editor ideas like Conception with great ideas that are worth checking into. https://github.com/shurcooL/Conception Sublime Text gets alot of things right, but during my experience using it and using acme. I often find myself wishing there was a way to take both editors and mash them together because using one often

I really like this, because he states my thoughts, and I didn't have to do the work of putting them into words eloquently. I'm completely on board since a year and a half ago. This [1] is what I have so far. More to come. [1] https://github.com/shurcooL/Conception#conception

Thanks for trying. It's really strange that it doesn't work on your OS X while it does on mine (and on someone else's system who tried it somewhat recently). I'd like to figure out why. I've pushed a small update [1] that prints the current working dir of the app. Perhaps you can try it and verify that it's being set correctly. See this screenshot [2] for Xcode setting that sets the running app cwd. [1] https://github.com/shurcooL/Conception/commit/37bbbb57e56caa... [2] http://img526.imageshack.us/img526/7548/imagexcsb.png

Going through this, I now realize one of the significant reasons I took such a big liking to Go. They realize [1] how important it is to make it easy not just for a programmer to work with the language, but also for writing tools that work with the language. And this happens to be very important for what I do. [2] [1] http://talks.golang.org/2012/splash.slide#34 [2] https://github.com/shurcooL/Conception#conception

What is Conception? I searched for “conception text editor” and didn’t find anything. Edit: Found it – it’s https://github.com/shurcooL/Conception, a research project IDE that you’re working on.

Sure, take a look at https://github.com/shurcooL/Conception - there are some screenshots in the README and if you're feeling adventurous, you can compile the thing on OS X or Linux out of the box. There are also some older public-oriented binaries in the simple-live-editor branch. There's still a lot to do, and much of that is stuck in my head at this time, but I'll do my best to put it all with the source soon. Plus I gotta work on "presenting" it a bit better (in a way that is more friendly towards other people seeing its long-term value and getting them interested in collaborating).

I thought so too, so I wanted to experiment with applying the same type of (physically-accurate) motion blur to scrolling text. Screenshot: https://dl.dropbox.com/u/8554242/dmitri/projects/Conception/... Source: https://github.com/shurcooL/Conception/tree/motion-blur I've realized the effect in motion looks quite nice, but it HAS to run at full 60 FPS at all times. If there are dips in the framerate, the effect is horrible (partly because the 16.66 ms number is hardcoded rather than calculated). My implementation is very naive and not optimized, but it funs well with a dedicated card. Not so much with Intel 3000. It was just a mockup so I didn't develop it further for now.

Would something like this qualify as a REPL, or is it not quite so? https://github.com/shurcooL/Conception/tree/simple-live-edit...

Then please star https://github.com/shurcooL/Conception, I'm working as fast as I can on making it happen. :)