This article is also available on my blog.
I spend a lot of time thinking about development tools. In this article
I want to discuss integrated development environments. These are
programs that provide text editing (usually code) as well as a variety
of features tailored to making the software development process
Why you should care
Better tools can make the development process more efficient. This
doesn't just save you time, but also changes what you are willing to
A good text editor is at the core of writing code, but it is only the
start. The more integration you can perform, e.g. by making your editor
aware of your language of choice and its symbols, building the program
directly from the editor, and even debugging and visualizing program
execution in the editor, the more seamless and natural development can
You also shouldn't settle for "good enough". We need to always be
improving our tools.
Finally, I have derived a lot of enjoyment from noticing something
annoying or inefficient, then solving that problem by improving my
tools. It is deeply satisfying to use an environment that is
increasingly tailored to you. Much like a kitchen or workshop where
every tool is right where you expect it to be, a well-tuned environment
lets you focus on building the product rather than constantly annoy you
or slow you down.
IDEs in the game industry
If you asked a random group of gameplay programmers "What IDE do you
use?" (IDE stands for integrated development environment), you would
almost definitely get the answer "Visual Studio". Specifically,
Visual Studio 20XX
Professional etc., not Visual
Studio Code, which is a quite different thing.
Visual Studio is dominant in the game industry, and it is evident by
what the large engines choose to support. Unreal has a
and Microsoft has a dedicated page showcasing Unity
support (this is no
surprise given Microsoft's involvement with bringing C# to life; most
Unity games are written in C#[^2]).
One should not use a program just because it is popular like Visual
Studio. In this article I hope to show how IDEs could be even better
than Visual Studio, with the motive that someone might read this article
and be inspired to implement more of these features in their IDE. I want
every programmer to have the best tools they can, and having a wide
variety of attempts at making better tools I think will lead to a
healthier marketplace and increase innovation.
Because IDEs like VSCode, Visual Studio, XCode, and Android Studio are
so popular, I want to present a few examples of relatively esoteric
IDEs. The more exposure developers have to these, the better. You don't
have to use them, but you should at least understand how they push the
frontiers of the tools we use to make programs.
This is the editor I have the most experience with.
Emacs is a great example of an IDE for modifying itself. It can
profile, debug, and provide documentation on its own features.
Emacs is one of the oldest pieces of software being actively developed
and used today. Imagine the advantages and drawbacks of a program with
46 years of continuous development. The big disadvantage is lots of
cruft. The advantage is 46 years of refinement of features.
Emacs has some incredible features that are still unmatched in modern
IDEs: it's easier to modify, easier to debug, has fantastic git
integration via magit, has fantastic
diff integration (via e.g. ediff, but also tools like SMerge that
automatically detect inline merge conflict formatting in files), has an
absolutely unparalleled markup and note-taking
experience, a magical remote editing
experience (don't just edit, but
also stage and commit with magit practically without even realizing you
are remote), and more. There are definitely rough edges, but the sheer
number of killer apps and synergies between them in Emacs make it still
stand above modern editors in my mind.
Emacs performance isn't so bad as to be unproductive, but I do want
something more lightweight. The biggest drawback to Emacs for me
personally is how frustrating it is each time I want to set it up on a
new computer. My Emacs
is several thousand lines and requires a few dozen plug-ins. Something
always breaks when I set up with new version or a new machine. The next
evolution of IDE for me is something significantly simpler. That said,
Emacs has raised the bar for me for what to expect from software in
general, not just IDEs.
Pharo came from the Smalltalk world. Its
features constitute a majority of what I
desire. This kind of environment is the most cutting-edge I have seen.
This kind of environment blurs the line between using a system and
modifying it, which I think is a powerful idea. It is fundamentally
different than the precompiled, closed-source (or "takes more than a
few clicks to obtain"-source), complex tool-chain world we live in on
Mac, Linux, and Windows.
Closely related, the Glamorous Toolkit includes
and furthers many of the same ideas as Pharo. The Glamorous demos
showcase the power of custom, easy-to-write visualizers for making data
explorable and shareable. It demonstrates how an object model can be
more user-friendly, more robust, and more powerful than the Unix
"everything is text" idea.
Bret Victor's ideas
Bret Victor's Learnable
doesn't only apply to learning programming--even long-time experts
would benefit from IDEs with timeline views and temporal decoupling. His
Inventing on principle
talk also talks about these ideas.
It is important to start from "In a perfect world, how would I try to
understand and modify this software?" and work backwards from there.
This is one way to come up with ideas that wouldn't be obvious from a
"I have an IDE, what's the next incremental change to improve it"
approach, which can lead to local maxima. In addition, radical changes
might require much tighter integration with the user's program, even to
the point of forcing a language like Pharo. This sort of change would
likely never be on the table with an incremental improvement approach,
but might be the only way (or the most efficient way) to reach the next
Project Oberon is "a design for a
complete desktop computer system from scratch". There are many great
ideas in the project, but I'm only going to mention the ones I am aware
of that are relevant to this article.
Similar to Pharo, the entire system is written in the same language.
Oberon avoids the distinction of processes, instead using the idea of
modules. As an example, you can import the graphics application's
module in your code and call its functions naturally. This is much
cleaner than the fragile and messy Unix way of using pipes or sockets to
communicate. In Oberon, leveraging functionality across the system is a
natural part of the language, not a complex runtime negotiation.
Oberon's text-based interface has a brilliant feature. Runnable
commands are simple to create--the user merely types the command name
and arguments into any text input, then middle-clicks to run the
command. This radically simplifies the creation of user interfaces,
because the interfaces are just lists of commands in text files. Window
button bars work exactly the same way. This also makes the system more
learnable, because the user can see the action every "button" takes
and can simply copy paste and tweak that button's command into their
own versions. If they then want to run several commands (a.k.a.
programming!) that's a clear next step, not a giant leap.
The trade-off with a text-based interface is that it might look less
conventional or "pretty"[^3], but the amount of value gained from this
transparency and consistency is worth it. Emacs is another good example
of just how powerful and usable a text-only interface can be.
Critical feature: easy modifiability and extensibility
The difficulty in modifying the development environment itself is
important for many reasons.
The difference in difficulty of modifiability is partly demonstrated by
Visual Studio when compared to Visual Studio Code. Visual Studio is
modified via Visual Studio extensions. Extensions are written in C#,
though it is likely possible to write them in C++ as well. The Start
developing extensions in Visual
guide demonstrates how to write an extension.
Contrast Visual Studio with Visual Studio Code's
Finally, compare those to this Emacs Lisp
Creating new editor functionality is typing Emacs Lisp anywhere in the
editor, highlighting it, then running a single command
That's pretty hard to beat, and compared to the Visual Studios,
there's no contest.
There is of course a cost to learning Emacs' custom language, Emacs
Lisp, to configure it. You need to get a hang of it, but once you do,
creating new editor functionality is a natural part of the development
experience, and done over time results in extremely tightly tailored
environments custom for your preferences and problems. I believe the
only way to reach perfection is allowing and encouraging deep user
customization, because no single product could meet every developer's
needs out of the box.
A point system for evaluating IDEs
For fun, here's a point system you can use to evaluate IDEs. The
features and amounts are what I care about; everyone has different
preferences, so I expect your feature list and point amounts to be
different. I also expect I've forgotten things, or didn't get the
relative values right, but this should at least provide a coarse view. I
scored points relative to the other entries in the feature groups. I
only partially scored things relative to all other groups, so group-wide
multipliers may make sense to help e.g. fundamental features always
dominate the score when they are not found.
Fundamental expected features
These features are in almost every editor. This is not an exhaustive
list, but should serve to be a "basic functionality" checklist that
e.g. Windows Notepad might not pass.
- Easy to create custom language highlighting = 200
- Easy to create custom language formatting[^4] = 100
- Easy to re-theme (dark, light, user-generated, etc.) = 50
- Easy to re-bind keys = 300
- Find text in file = 500
- Find text in files in directory = 500
These features are common in modern IDEs, but noticeably absent in
development environments before e.g. Sublime Text.
- Command palette to easily search for and run functionality via keyboard = 200
- Fuzzy search on all selection fields = 100
- Go to file by name (goal here is to beat File Explorer's slow folder navigation) = 500
- Go to symbol by name (list all symbols and filter to desired) = 300
- Go to definition of symbol at cursor = 300
- Possible to tie key bindings to specific languages/"modes" = 200
- Macro system for bulk text editing or complex cross-file automation = 250
- Multiple-cursor support for bulk text editing[^5] = 250
- Possible to integrate with version control (native, plug-in, or CLI sub-process) = 300
- Existing plug-in ecosystem/community with in-editor browsing/downloading = 400
- Extensions can be written and loaded interactively (no closing of editor necessary) = 100
The following features ensure the "environment" truly becomes an
integral part of the development cycle. Not only should it edit text,
but it should also offer control of the end-to-end process from editing
text all the way to building, debugging, and visualizing the developed
- Debugger which lets you single-step code in the same editor = 800
- Profiler which lets you quickly find performance hotspots = 300
- Run other processes trivially from the editor[^6] = 500
- Build and run the program being developed in one keypress = 500
- View build and run output in editor = 300
- Jump to error file and line from build or output in editor = 400
- Integrated difference visualization (remove need for external diff tools) = 200
- Integrated notes so I can e.g. write my to-do list and easily jump to referenced code[^7] = 500
- Extensions written in same language as editor core = 100
- Integrated help and documentation on extending the editor itself = 200
IDEs of the future
These features are absent in most IDEs. I would consider an IDE with all
of these to be cutting-edge. If you have ideas for IDEs of the future, I
want to hear them! Email me!
- Easy to write simple graphical visualizations (lines, rectangles) = 200
- Easy to write complex graphical visualizations (3D shapes, node graphs) = 100
- Possible to use developed program code to enhance editor too (e.g. inline render) = 300
- Indexed file search (something faster than
grep) = 150
- Trivial and natural to modify and extend (Emacs'
eval-region sets the bar to hit) = 500
- Integrated debugger used when extending the editor itself = 100
- Integrated profiler used on the editor itself = 100
- Temporal visualization (see Bret Victor's timeline ideas) = 500
- Remote editing (files are on remote machine) = 150
- Remote debugging = 300
The following can be added in if they are things you care about. These
are important enough to include, but not important to everyone. Not all
of these features are important to me.[^8]
- Vim emulation = 100
- Free and Open Source = 800
- Free (as in beer), even for commercial development = 200
- If open source: simple to build IDE itself from source (simple tool-chain) = 100
- 100% keyboard support (I shouldn't ever need a mouse to browse, debug, or edit text) = 400
- Extensions written in same language as your programs (depends on your programs) = 500
Here are some editors I'm familiar with, scored according to my point
system. Optional features sum appear in parentheses.
- Emacs scored 7550 (1900)
- Visual Studio 2022 scored 6750 (500)
- Visual Studio Code scored 6250 (1000)
- Sublime Text scored 5950 (400)
There is some ambiguity or debate that could happen on whether a feature
counts. If the feature must be included via plug-in, but the plug-in is
commonly installed, I count that as the editor itself having the
feature. I do not count plug-ins that only partially implement the
feature such that relative to the other editors the feature does not
meet the minimum quality bar. I am not counting from the
"out-of-the-box" experience because even a small time investment can
introduce many of the important features in my lists to the editor.
This list is not meant to say one of these programs is fundamentally
better, and that you shouldn't ever use the others. It is meant only to
be a demonstration of how one can compare these programs with how it
approaches the "future of development environments". Additionally, it
has the false assumption that these programs even set out to create
development environments. All of these programs have different goals and
target audiences, which means one should not expect they do well at
whatever arbitrary criteria you throw at them. There's some axis that
each these individually beats the others at, for example.
I did not count Emacs as having a debugger because the Grand Unified
Debugger with gdb do allow step-debugging, but it doesn't quite reach
the quality relative to Visual Studio 2022 where I feel it deserves to
be counted. I do have a C/C++ focus, so e.g. Emacs would count as having
a debugger if you have a Lisp focus. Similarly, Visual Studio Code's
debugger pales in comparison to Visual Studio 2022, so I also didn't
Visual Studio 2022's score is bolstered by its inclusion of a great
debugger, which is indeed its killer feature. It is behind the rest in
regard to ease of extension especially, and lacks features like multiple
cursors that I believe make a big difference. (And no, Visual Studio's
block-based multiple cursors does not count because the column nature of
it is far too limiting).
Finally, I do not want this to be read as "Emacs is the best editor,
and everyone should use it!" I'm only trying to show that Emacs does
well under the given criteria. I expect an IDE engineered to meet all
these criteria would easily defeat the competition, simply because it is
easier to optimize for a specific test than just set out to create an
IDE without knowing the goals.
Cakelisp and IDEs
Where does my programming language,
Cakelisp, fit in with all of
The Beef programming language ships the
language and an IDE (including debugger!). I think this greatly lowers
the barrier to entry for the language. I want to do something similar,
with the goal of replacing my existing IDE (Emacs) and making a better
development experience than could be provided by any existing IDE.
The path to this is not completely clear to me yet. My working idea is
to fork a C compiler like Tiny C
Compiler and modify it to provide the
dynamic environment I
want. The next
step would be to port Cakelisp to C, which it can already export, but
itself requires C++. I would then start building the editor in this
environment both as a dogfooding experiment as well as to ensure the
editor can be modified seamlessly at runtime. This would radically
simplify the tool-chain for building Cakelisp programs, because it would
be a single executable that can compile, run, and eventually debug the
programs. Currently, I am dependent on the standard C++ compiler
tool-chain as well as 3rd-party debuggers. I want Cakelisp to be a
vertical integration-type system.
There is still plenty of room for improvement in development
environments. If you plan on building an IDE, make sure to look outside
of the common, popular examples to find much more powerful ideas.
[^1]: One should be careful as always of vendor lock-in. It is natural
for vendors of closed-source or SaaS software to force your project
to be organized with their tools. This usually means the service is
more convenient, but it comes at a huge price. Companies are known
to raise their prices, move to subscription
or even remove functionality in the name of simplicity to appeal to
a different target audience. You should always know what your
valuable data actually is (source code, configuration, etc.), where
it is stored (important for making your own backups anyways; do not
trust cloud services to exist forever or not ban you for some
arbitrary reason), and how the end-product is built from the data
(i.e., the build process). If you don't know these things, you
are being locked in, and you should consider your data (and by
extension, your business) at risk. The steps you should take in the
right direction are owning the storage of your data and being able
to build and run the program(s) completely locally, without some
software that needs to phone home asking whether you have permission
to do so.
[^2]: The Unity engine itself is mostly C++, but most indie to mid-size
developers build Unity games with C# exclusively. The Unity C++
source is closed and costs significantly more to access.
[^3]: By lowering the bar for how difficult it is to create UI, you can
focus on the usability and power instead. The same holds true for
video games: if your game can tolerate art assets that are "low
quality" but cheaper to make, you can make new gameplay much
faster. While it is of course nice to have things look good, there
is a definite price for aesthetics vs. speed of iteration/new
feature development which should be weighed carefully. A game like
Dwarf Fortress would be infeasible to make with the graphical
fidelity of a game like Red Dead Redemption 2, for example. Every
icon, wireframe, and custom layout required reduces the likelihood
of rapid and "risky" experimentation of new UIs and feature sets.
[^4]: This could be in the form of running
clang-format on the
highlighted region, Emacs-style "electric indent" (when I press
tab, it does what I want it to according to my alignment
preferences, not just inserts a tab character), or any "smart"
[^5]: Many editors have macro systems, which similarly accomplish bulk
editing. However, the immediacy of multiple cursors (popularized by
Sublime Text) as well as the ease of initiating them feels different
from macros and I end up using them much more.
[^6]: This is a game-changer when it comes to integrating the editor
with the ecosystem at large. Every build process, compilation
process, version control system, authentication scheme, etc. should
have a command line interface for easy integration in this way.
Writing a plug-in to have tighter, more "native" integration is
usually superior, but it is usually good to support sub-process
execution as a transition or stopgap.
[^7]: The absolute best form of this I've ever seen is
org-mode. It's no contest--Org has so many
killer features like heading folding (so you can can have a huge
amount of complex notes without it getting cluttered; most
programmers I've seen naturally end up with an outline-style notes
structure, and Org is built to support that), inline code
highlighting, URLs to both local files and web URLs,
export to a wide variety of formats for
publishing (this article is itself written 100% in
smart table/spreadsheet authoring (you can even do Excel-like
formulas on the cells, and it's all still plain text!), and many
more features I haven't even explored. Unfortunately, the only true
implementation is in Emacs; any emulation I've seen lacks the
critical features like heading folding that really make org a killer
[^8]: I don't care about Vi-style modal editing, for example. I use the
Kinesis Advantage2 and heavily customize and rebind things, so Vim
doesn't actually appeal to me. I know people who are used to Vi(m)
are very tied to it, which is why it deserves an optional category
here. If you are building a text editor/IDE, you should at least
have some idea how to please the ever-growing Vim crowd.