

Why do all code editors look the same? - dangoor
https://medium.com/@jviereck/43de0df2daed

======
tikhonj
The basic idea of looking at how we can improve workflows in editors is great,
but I have issues with much of the actual analysis. Even the core premise—that
all editors "look the same" is flawed. They only look the same to the extent
that most of the screen is taken up by, of all things, _text_. In this sense,
image editors also start looking suspiciously the same...

Image editors, of course, have all sorts of tools and buttons, not just the
image. But this is just a function of the main modes of interaction: mouse vs
keyboard. Unlike an image editor, a text editor is used almost exclusively by
a keyboard, so most of the controls are optimally presented as keyboard
shortcuts.

Then, the post goes on to argue by analogy: always a risky strategy. Would I
put two pieces of paper side-by-side when I'm writing an essay? Probably not.
But code is not text; often, I _do_ want to compare two pieces of code next to
each other, line-by-line... which is done perfectly by putting them next to
each other. And the rest of the paragraph goes on to pretty much describe my
Emacs workflow[1] anyhow: I often have one main buffer and a bunch of random
resources in another buffer which I periodically move around or swap.
Sometimes, I also have a browser window or two open in the same way.

The buffers don't overlap _per se_. In practice, they actually do: each one
shows a _window_ into the underlying text or image or whatnot, and can just
show a small part. (Moreover, I can have _multiple_ windows into one document,
which is occasionally useful in practice). The only constraint is the physical
grid... which I might use anyhow if it was easy with physical things. I lose a
bit of flexibility in how things overlap in return for not having to worry
about positioning and having everything line up nicely; a great compromise.

An important detail is that, in Emacs at least, open, closing and swapping
panes is trivial. I constantly bring up new ones, look at new things in
existing ones and then close them in the normal act of editing. Very
transient, very flexible and largely possible because they _don 't_ overlap so
that we can lay out new ones automatically instead of giving me a floating
window to manually drag out of the way.

My workflow still looks just like the wireframe in the blog post. Interesting.

In the end, this is just going from the cozy world of tiling window management
into the frontier of floating windows. While it might be friendlier to
newcomers, floating windows are simply not as good for experts and,
presumably, most code editors _are_ aimed at experts.

I would much rather take on a slightly worse learning curve to get my stuff
laid out automatically, all from keyboard commands. My code editor is one of
the tools I use the most, so the trade-off is a no-brainer.

In fact, by using Emacs, that's exactly what I've already done!

[1]: [http://jelv.is/emacs-workflow.png](http://jelv.is/emacs-workflow.png)

~~~
asuffield
> They only look the same to the extent that most of the screen is taken up
> by, of all things, text.

And the main thing I notice about most of the examples given in the article is
that they involve most of the screen not containing text. In fact, most of the
screen appears to contain nothing useful.

There's a reason why the major popular editors all fill the screen with text,
and it's something I've discovered from years of editing code: nothing is more
important to programmer productivity than being able to pack a lot of code on
the screen at once. There is probably an upper bound to this, but I suspect it
is higher than available space on my desk to put monitors in.

You don't really need annotations and graphics and dotted lines to show you
how things relate. You just need to have all the things in front of you so
that you can read them together. Since we tend to write code vertically, this
is usually best achieved with a small number of side-by-side panes of text, a
feature which basically every decent editor has.

~~~
judk
When your project gets larger than one super screenful, the story changes,
though. You'll need to see how things relate in the Birds-eye view.

~~~
asuffield
With projects in the millions of lines, I have never reached this point. You
just need to be able to pack in all the things relevant to what you're doing
at the moment.

------
Ogre
I approve of people trying to improve the editor experience. This is a good
project! I have a nitpick though:

"forking the current panel using Ctrl+F is a game changer, as you don’t have
to scroll away from your current code location when looking up something at a
different place in the same file."

A game changer over what? Are there editors that don't let you do this? The
two I mostly work in are Emacs and Visual Studio, and you can do this in both.
(I'd actually have to hunt around for how to do it in VS, I use both side by
side because of a whole lot of Emacs muscle memory, but it's there for sure)

It worries me that he's not actually aware of the features available in the
editors he's trying to improve upon.

~~~
MetaCosm
This is exactly what I thought. I set vim to always open in new splits, I
often have the same file open in 3 splits for 3 functions. It press 2 keys to
open a reference to a function in a new split with me looking at the function.

It seems like the author might not have ever learned how to properly use the
existing editors.

~~~
Ad_Nauseam
Creating your own tools are easier than exploring existing tool's
documentation...

~~~
rakoo
Yes, but that doesn't mean you can say "no other editor can do this".

Even Eclipse allows you to do this.

------
Permit
For what it's worth, not ALL editors look the same. :) I'm working on an
editor with a friend of mine called Code Connect that is considerably
different than most typical editors.

It's heavily inspired by Code Bubbles as well. However, instead of working
with code on a file-by-file basis, we're working with code on a function-by-
function basis.

We've got a demonstration video here:
[https://www.youtube.com/watch?v=CuQ8NJOypqs](https://www.youtube.com/watch?v=CuQ8NJOypqs)

And we'll be shipping an alpha version for people to play with over the next
two weeks.

~~~
phloxicon
That looks absolutely gorgeous. Working with functions like that is something
I've been looking for. Is there a longer demo video? If like to see how new
functions are added to existing files, how it handles a bigger code base, and
how it deals with a clutter of bubbles e.g. does it remember old bubble path
lists so they don't have to be expanded layer (or maybe this shouldn't be the
case due to causing clutter).

I love how it has autocomplete due to VS integration. With the right keyboard
shortcuts and some polish, I think your editor would be very useful. Keep us
updated.

~~~
Permit
Thanks a lot! The video I posted is fairly dated, and we'll be releasing a new
one this week to discuss how Code Connect deals with interfaces and
inheritance. Adding bubbles is an issue we haven't solved yet. We've tried a
few different approaches, but nothing feels quite right yet.

Like you said the user experience is key with a tool like this, so we're
constantly working to refine it.

The biggest thing we're looking for right now is feedback, so I'll definitely
keep you updated on our progress, videos and alpha release date.

------
mercurial
On one hand, it's always nice to see people experiment. On the other hand...

* I didn't leave KDE for XMonad to get a window manager in my editor. I'm interested in maximizing the real estate for my code, because I also need a web browser and two or three terminal windows.

* I don't see how that's going to scale to something useful when you have a project with hundreds of files where you often need 10 files open at the same time.

~~~
ufo
Which begs the question - why not open multiple windows and let the window
manager take car of them?

~~~
mercurial
No good reason? As long as they are in the same process or can communicate via
IPC, it sounds more rational to me.

------
emeraldd
The floating window style editor looks interesting, but ties you to working
from a GUI environment. I quite frequently find myself working via SSH
sessions to remote machines for a good chunk of my development. Anything that
requires a GUI/mouse is a non-starter in that kind of setup.

~~~
gpmcadam
I agree, I very rarely use my mouse when editing. I imagine this idea, and
especially the Code Bubbles idea linked to in the article, would work best
with a tiling window manager similar to awesome
([http://awesome.naquadah.org/](http://awesome.naquadah.org/)) or tmux
([http://lukaszwrobel.pl/blog/tmux-tutorial-split-terminal-
win...](http://lukaszwrobel.pl/blog/tmux-tutorial-split-terminal-windows-
easily))

------
mgkimsal
People have different needs, and I get reminded of this when talking about
editors/IDEs with others. Had a friendly 'discussion' with a dev a couple
years back who was leading a discussion group and publicly scoffed when I
mentioned I'd picked up IntelliJ. He went on to talk about his company's code
and how 'lean' it was and how they didn't need any 'heavyweight' tools like a
Java IDE.

I asked him about the code he was working on. How much of it did he write? "A
lot". How much was written by people at the company "100% in house - we write
everything from scratch". OK, great. Working on the exact same codebase with
the same core team for years on end (2+ years in their case), you probably
know every single bit and byte by heart - awesome. Very few of us operate in
that world. Many of us come in to codebases where we didn't write every line.
The original gone, hostile or possibly even dead at this point. Full-featured
IDEs (the guy in question kept gushing over sublime-text and how fast and lean
it was) provide another level of code insight that basic editors don't provide
(not ragging on ST, just pointing out it doesn't do what I need for the
breadth of projects I work on).

I think the OP needs to look deeper at the tools he's criticizing before
writing them off. His ctrl-f example demonstrates that he doesn't seem aware
of other IDEs that provide this (and... I'd probably use ctrl-f to _find_
something, not _fork_ ).

In the vEdit example, we get 'what file do you want to open?' That's generally
precisely what I _don 't_ want to think about when I come in to a new project,
because I want a visual overview of what's available. I want to see the naming
convention, the layouts, note what's available and what's not. Removing that
in an effort to be 'simple' hinders a heck of a lot of automatic project
discovery for the sake of ... what? 'Simplicity'?

~~~
gizmo686
At my company, we are working on an Android fork, meaning a very large
codebase of which we wrote almost none of. I tried useing an IDE, but found
that vim+grep+locate turned out to be much more productive.

~~~
mgkimsal
interesting you say that. there are times that vim/grep works better for me,
but I've found jet brains tools phpstorm and intellij) really are more
productive for more _most_ of the time. depends on how complex the code is, I
think.

------
tokenrove
This looks like a Smalltalk environment, which is also a 40 year old paradigm.

~~~
anthony_d
That was my first thought as well. I'll also add that it doesn't look like it
would work as well in Java thanks to Java being much more verbose.

Given about 2 minutes of thought I'm leaning towards this being the wrong
approach. The challenge with verbose languages is getting enough context on
screen or in your head to think about the real problem; it's a pretty old
problem and a lot of things have been tried, but not much has really worked.
What I would like to see is something that hides more of the incidental
complexity and lets you not think about it.

~~~
riffraff
FWIW, the smalltalk browser _look_ ("hierarchical" selector blocks on top and
content at the bottom) has been an available UI in java in eclipse for years,
and IMO it's far better than the tree-ish browser on the side exactly because
it helps with getting more context on screen

------
kennethfriedman
this reminds me of Bret Victor's talk: The Future of Programming.
[http://vimeo.com/71278954](http://vimeo.com/71278954)

Similar ideas on the problems with code editors / current programming, but
Bret Victor's ideas are a little more fleshed out.

Also, if you haven't seen it, it's a pretty funny talk. Brilliant guy.

------
nigwil_
John Carmack [1] highlighted the tyranny of limited screen real-estate could
be vanquished by immersive media (virtual reality) headsets - easy to imagine
a VR "code landscape" littered with derelict or active work-in-progress code
dumps. It would still allow the best of current designs to exist in this new
interaction space but no longer bounded by physically awkward wall of screens.
Something like Croquet[2]+VR+editable-code-objects and so on.

[1]
[https://www.youtube.com/watch?v=BMmwhjfVSbk#t=1h16m30s](https://www.youtube.com/watch?v=BMmwhjfVSbk#t=1h16m30s)
(next minute) [2]
[http://en.wikipedia.org/wiki/Croquet_Project](http://en.wikipedia.org/wiki/Croquet_Project)

------
ollysb
The killer feature for me would be able to "expand" method implementations at
a call site e.g.

    
    
        class UserController
           def create
             ...
             UserMailer.send_invitation(user) # expanded line
               def send_invitation(user) # implementation from UserMailer
                 ...
               end
           end
        end
    

This way you could unfold the entire call stack in place i.e. you can see all
the code you're working on at once.

~~~
MetaCosm
It works for trivial examples, but on anything complex... as you go 3/4 layers
down and on longer / more complex functions, I suspect it quickly makes less
sense... what about when that function references other stuff in its local
context, etc?

That is an amazing demo feature -- but maybe not as useful day to day versus
just hoping around functions.

------
zimbatm
LightTable started it's life with an unusual layout which gave me hope we
could break free of that classical layout. Unfortunately it reverted to the
classical layout later on.

~~~
shurcooL
Interestingly, my Conception project shared a similar history. It started off
as small individual boxes on a large canvas, but the latest version is
currently more like Sublime.

I still haven't committed to either one paradigm, there are just certain
problems with an open large canvas model that need to be resolved for it to be
usable for large tasks.

------
shurcooL
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](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.

------
todd8
Emacs can already open multiple windows all showing views of the files
currently being edited. It's easy to have multiple windows that can be dragged
around on the GUI each split into as many panes as desired. I find that one
big window split into three or four panes works best for me most of the time.

~~~
emeraldd
Being able to split one "window" into multiple panes has become an absolute
must for me. Once a file get's longer than the screen's height, it's
inevitable to need to go hunt something down that's one screen away from what
I'm working on right now.

------
dodders
Most of the developers I work with (including me) already work in this fashion
- multiple windows open on the desktop showing (for example) code being edited
(usually in an IDE); code open for reference (a 2nd copy of the IDE, or simply
notepad/uedit/vim/whatever); scripts (vi/emacs/grep/less); database stuff in
another IDE; source control; folders view and usually multiple grep windows.
My point being that I pick what they need to use and let the desktop take care
of displaying them simultaneously. I'm not sure I can conceive of, or even
desire, a single IDE that can handle every scenario that I encounter for me. I
think most scenarios are handled by opening another vi/notepad/ide session as
needed.

------
wisty
The new idea looks like my desktop. A web browser, terminals, text editor
windows ...

~~~
stinos
Or like Visual Studio. On the desktop. Where you can have your text editor
windows float over multiple screens.

------
krakensden
As long as you're using a desktop environment, you can have this environment
today, with no extra programming required.

Those who live in an iPad-only world may still be slightly stuck though.

------
myg204
The floating windows reminds me of the text editor called sam. You have
floating resizable windows in the editor, one window being a command window to
operate on the current buffer text. It's a powerful idiom . Here's a
screenshot:
[http://en.wikipedia.org/wiki/Sam_(text_editor)#mediaviewer/F...](http://en.wikipedia.org/wiki/Sam_\(text_editor\)#mediaviewer/File:Sam_text_editor.png)

The most different editor is 'ed' though :)

~~~
_cipher_
That was exactly the first thing that came to my mind as well. :)

------
kleiba
Note that Emacs' window splitting ability doesn't stop at splitting the editor
in two. You can recursively keep splitting as much as you want: when
navigating complex code bases it has helped me in the past to have it split
into four sections. More splits than that made the displayed sections too
small for my taste, and even if you have all those splits right in front of
you I personally felt that I had a harder time keeping track of where to look.

~~~
spb
Cloud9 allows similar unlimited pane splitting iirc.

------
jasonkostempski
I've recently gotten a good XCode workflow going and it feels a lot like this.
If I'm exploring code that's new to me, I'll have a tab dedicated to a file
with several assistant editors open. An assistan pointed at counter parts and
one at callers. If it's something I'm already familiar with my editor will
usually look like the classic layout.

------
simplyinfinity
To my best understanding, what the author has shown can be done in Visual
Studio 2012/13 and i quite often work in a similar way.

------
lispm
Some of the non-text-file-based environments edit different by default:
Smalltalk, Interlisp, Self, Apple Dylan, Boxer, ...

------
baruch
There are other IDEs as well, I'm aware of lamdu
[https://github.com/Peaker/lamdu](https://github.com/Peaker/lamdu) which is
for haskell or at least a very close variant. I'm not a big fan of haskell but
I've seen a demo of an early version once and it seemed great.

------
skore
Because the job of a code editor is to get out of the way.

You get out of the way by emulating what people know to at least such a degree
that they can filter it out easily and concentrate on the task, not the
environment.

------
bubblicious
The only big evolution I see with code editors in the next couple of years is
real touch/gesture support. Any attempt to code on a touch device will
convince you within 30 seconds that the IDEs of today are not adapted.

~~~
asciimo
noflo looks like would work really well on a tablet
[http://noflojs.org/](http://noflojs.org/)

~~~
bubblicious
Ooh that actually looks really cool, Thanks a lot for the link! :)

------
krallja
Reminds me of "How to Think Like a Pioneer" (2010) by James Hague:
[http://prog21.dadgum.com/69.html](http://prog21.dadgum.com/69.html)

------
spb
I didn't think of Cloud9 for that mockup. Cloud9 has two horizontal, tabbed
panes, one being for files and the other being for the console (for the out-
of-box workspace).

