Over the past 21 months I’ve written a code editor from the ground up

Generalized a bit, unit tests on all projects serve to make progress easier and regression harder. There are secondary benefits on evidence/documentation. When the ROI on them turns negative, just delete them. Overcoming the belief that you can't delete unit tests is the lowest cost way to start writing more and better tests.

It's so weird when you think about it. People don't delete unit tests because not having them is bad. So, they... don't write them? "No unit tests" is a state we can always get back to in a seconds. Don't be afraid to leave it.

What a fascinating combination of "analogy" and "allegory".

This aside, I agree with your point - the best articulation I can think of right now is the human equivalent of "do what I mean not what I say". Where sometimes the collective intent gets stuck in an ideological rut and can't become what everyone wants it to be for lack of expression.

This is mostly how I work today. Intellij for Java backend work, VSCode for front end work. Both using VIM keybindings.

And to your point, I couldn't imagine developing Java without Intellij. It's like they are made to work together.

I'd expect software to be more "stretchable" than armoured military vehicle designs. Hopefully, both the tank and the IFV can be Vim or Emacs or VS Code, and both can be good without compromises.

> This feels like a lot of line noise for those rare-until-you-hit-them bugs.

Yeah, but if doing so can eliminate an entire class of bugs...

...you know something? I think I'm starting to see where those Rust guys are coming from.

> Plus, there would always be the temptation to remove that do-nothing code.

It's not 'do-nothing' code, though. Isn't the temptation just the same as the temptation to remove 'do-nothing' exception handling or 'do-nothing' unit tests?

If it's much "do nothing" code to remove, perhaps it'd be better to move to a more expressive language. E.g. for Ruby at least, block arguments means it's trivial to do this:

    def at_most(num)
       num.times {  yield }
       raise "Should never get here" # or "binding.irb"/"binding.pry" to drop you into a repl, perhaps contingent on a command line flag.
    end

 and do:

     at_most(5) do
        .. logic
     end

If the number isn't obviously absurdly high, I agree it'd be worth documenting why the precise number was chosen, but then it might be worth documenting why as an indication of why you thought an infinite loop was appropriate anyway.

As a counter-argument: why are we generally ok with allowing things to be infinite when they're expected to be finite? Precise bounds are obviously best, but sometimes it's not efficiently calculable or not worth the effort - don't choose the literal worst possible value there (infinity), pick something that'll stop itself when it goes insane.

And no, it's a tool. Use it where it makes sense.

Depends what the refactor is. I think personal/side projects are a great place to give into the attractive nuisances we encounter in programming.

I guess it depends on what motivates you! I find refactors a zen-like experience. Figuring out the way to make everything fit together elegantly is a really satisfying task for me.

Also, "personal projects don't fail until you decide they do" is a great insight :)

I actually love refactoring.

I really like to keep my code "elegant" and so I tend to constantly refactor it (which also makes a typical refactoring step small, and thus not a chore).

At work it's sometimes a hindrance: I tend to overdo the clean-up stuff; for me it's hard to resist a temptation to have even simple throw-away code clean and maintainable, and it is difficult for me to cut corners when working on something urgent. Of course sometimes throw-away code is not thrown away and is maintained for years and years, and cutting corners accumulates code debt (which you later on pay with interest), but overall I tend to be slow with small projects, although reasonably fast (if you include debugging time) with large ones.

But when working on a personal project, and can tidy the code up to my heart content! It actually helps to keep up my enthusiasm, not the other way around.

I guess different people have different preferences and predilections :-)

Most of the things that are infinite from the perspective of the program tend to be event loops of different forms, though, where that perspective is "unless the right event arrives". There are rarely many of them in the same application, and they tend to be high level. If you find yourself writing an infinite event loop at a lower level, odds are something is off (e.g. an infinite loop waiting for a reply packet over the network could do with a timeout)

I agree it's usually fine to use infinite loops for high level event loops, as it's usually easy to test that you can break out of them by triggering the right event (though sometimes it might be worth thinking about pathological cases if you can do something about them, such as whether something is wrong if there's no interrupt for a long enough period; and you can also prevent writing an infinite loop even for event loops by making the break condition whether a suitable "exit"/"restart" event has been received - very few things should be without one or the other of those two even if intended to run forever in normal circumstances).

The advice, I think, is more important for algorithms working on input data that may well lock up the application if the logic is wrong. E.g. a sort should eventually complete; if it takes more passes through an outer loop than the theoretical worst case for the algorithm, something is wrong (be it your implementation or your understanding of the worst case...). A habit of estimating worst cases and treating them as invariants to check and make assertions about can be useful.

Well, look at it this way--what benefits are there in doing so?

- The test suite runs faster

- Less time is spent maintaining the test suite

The argument wasn't whether tests should ever be deleted, but rather an encouragement to delete them as soon as you feel confident in your code. Personally, if a test is still relevant then I will maintain it until the behavior it's testing is no longer part of the application. And often that's a zero sum situation, because now you need to test the some new behavior.

A failed test is literally your test suite saying, "Remember this part of your application that you promised would behave a certain way? Well, surprise! It doesn't behave that way anymore." There is value, if nothing else, in knowing what the implications of a change are, especially as the system grows. So even if you're okay with a change in your application's behavior, I'd argue that tests are the best way to be aware of what those changes are.

> Electron leads to high latency and slowdown once your editor grows big enough

Any large application who extends the number of features forever leads to high latency and slowdowns, unless you structure things as extensions/plugins and load them ondemand/allow users to disable/enable them.

It has nothing to do with Electron, same thing would happen with a application written in C/Rust. Might happen faster with JavaScript, as JS developers tend to have less focus on performance, but it is less about Electron vs the World and more about who the developer(s) is.

Error out or something? Otherwise it would seem the program is in a weird state.

... and then what?

It's on github [1], but the version on github hasn't been pushed to in ages and is a mess because, well, I haven't really cared about making it work for anyone else, so not sure how useful it is to look at. It's an ugly mess, and frankly the one downside of doing a project like this is that it's a bit embarrassing to show people - since I'm the only user I only clean things up when the mess starts hampering me, and since the codebase is so small, that's rare (my current iteration, not the Github one) is about 3.3k, with about 1k of that being syntax-highlighting stuff I'd like to try to get upstreamed to Rouge)

I started out with Femto [2] and ended up quickly gutting it (there's next to nothing left now), and as an example of a minimalist Ruby editor, Femto is perhaps a better starting point - it's certainly both cleaner and smaller.

I've started breaking a bunch of functionality into gems (termcontroller, file_writer, ansiterm, editor_core, keyboard_map) of various stages of usability for others, and my goal is to over time eventually be left with the editor as a tiny shell around reusable components + my personal config, but as per this article, I plod along and fix the things most pressing to me personally and nobody else so who knows when that will happen.

As long as it keeps being useful to me, that's what matters. In that respect it's also a meditative experience of sort that takes my mind off work and having to work in a more professional manner.

> I am also curious what advantage you found in putting the buffers in a separate process. Is it just that a crash in the front end doesn’t cause you to loose changes? Why not just save at regular intervals instead? Is the idea to persistent undo or file revisions?

I also save at regular intervals, so you're right that if that was the only consideration I probably wouldn't have bothered.

But the editor is a terminal application, and I use a tiling window manager (bspwm), and so I figured that if I could spawn another editor instance and have my wm open it in the right space and with access to the same buffer, I didn't need the editor itself to have any understanding of windows itself. Here's "split_vertical" that opens a second view of the same buffer:

    def split_vertical(buffer_id)
      system("split-vertical 2>/dev/null term -e e --buffer #{buffer_id}")
    end

[EDIT: Should also clarify here that "term" is a wrapper for whichever terminal I currently favour, at the moment mlterm, and "e" is an alias for my editor; if I ever were to try to make this usable for anyone else, there'd be a whole lot of cleanups to make - the biggest concession towards this I've made has been to recently move most dependencies on my environment into a separate file]

split-vertical is a helper (I split out a handful of things that depends on external tools) that just runs "bspc node -p south" to get bspwm to halve the height of the current window and "swallow" the next window being opened into the space freed up below the active window, and then exec's its argument. So meta-2/meta-3 works roughly like ctrl-x+2/ctrl-x+3 in Emacs (EDIT: fixed; already forgetting the Emacs keybindings...), except the frames end up in their own windows, running their own client.

Had remoting the buffers been a lot of work, I wouldn't have, but the the Drb specific part of the code is <100 lines and the combined effect of the resilience (if an exception is thrown in the server code, I get thrown into a Pry repl in the client) and the extra abilities it enables makes it worthwhile.

Similarly, I've avoided implementing my own directory handling, and just farmed that out to a wrapper that currently uses rofi, same for theme selection (for syntax highlighting), buffer selection, etc.

The minimalism of delegating all of these things elsewhere appealed to me.

> I am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch.

Strongly disliking Lisp was high on the list (I like the concepts; hate the syntax intensely). Also, it wasn't so much a limiting factor, as realising that my Emacs config file was larger than toy editors I'd played with in the past, and a minimalist bent making it appeal to me to go for something smaller. Also seemed fun (and has been)

[1] https://github.com/vidarh/re

[2] https://github.com/agorf/femto

> You get a massive bug catcher for free with TypeScript...it tells me their philosophy/priorities are completely backward.

This is a superficial take. TypeScript is not free. You are adding a compilation step that takes time, slowing down feedback in certain workflows, as well as a rather large dependency. It certainly can be worth asking why they chose JS given some of your perceived benefits of TS but not using it doesn't mean that their philosophy is backwards.

As long as you're disciplined it probably doesn't matter, but I think it takes significantly more effort to ensure correctness with JS vs TS.

It might be the best option you have, but it's not even close. nim would be a better option.

If you use micro services properly, unit tests can still call APIs and survive refactors.

Should be fixed now. Thanks!

> when you want to scale things up, specially to webscale you want mongodb

What is about coffee in your actual nostrils that wakes you up more than the full cup itself?

Perhaps OP should try piping their code to /dev/null, which is fast in web scale. Does this editor support sharding? Shards are the secret ingredient in the web scale sauce. They just work.

Most if not all of the points are not applicable when medical software and firmware is involved. I could never play so fast and loose at work.

Not convinced. I worked on a project with some friends that got to about 20kloc and then collapsed under its own weight because it became impossible to change anything without breaking something else. While there's a wrong way to design for scaling or extensibility, development practices that rely on holding the whole thing in your head will hit a brick wall sooner or later.

The recent Randall comic is quite fitting:

https://xkcd.com/2730/

I rather think, it has to do a lot with momentum. If you think hard about every step and every change, you will be so slow, that a competing project that just focus on shipping useful features, will get so much traction, that they overcome their wrong design decisions with more man power and after a while, so many people use it, that they continue to use it, despite its flaws.

Otherwise we wouldn't have javascript as the most widespread language for example, with monumental efforts invested in fixing the initial flaws and making it do things, it was never designed for.

> Not once did they claim "zero dependencies"

The title literally says "Over the past 21 months I've written a code editor from the ground up". The linked blog post is titled "How to Write a Code Editor from Scratch in 4 Months".

I don't know what you would consider "from the ground up" or "from scratch", but in my view that means no external libraries, if something isn't in the standard library I code it myself. That means that someone only needs a compiler and the standard library to build the application, rather than having to either use a dependency manager or (worse) track down and build the dependencies themselves.

Real programmers use butterflies. https://xkcd.com/378/

"'Abort, Retry, Fail?' was the phrase some wormdog scrawled next to the door of the Edit Universe project room. And when the new dataspinners started working, fabricating their worlds on the huge organic comp systems, we'd remind them: if you see this message, always choose 'Retry." – Bad'l Ron, Wakener, "Morgan Polysoft"

From scratch means if I am on a fresh install of whatever OS they are targetting and have a compiler (compiler, not build tool, so rustc, not cargo) of the language they use I can build the project without having to install any dependencies.

I can write an editor using tools others have built, too:

  apt install emacs

Or should we, perhaps, consider “from the ground up” and “from scratch” to mean something?