14 ms·

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

410 points by gushogg-blake 4y ago

jarbus 4y ago
Is there anything like AST mode for neovim? Sounds like a cool feature.
- cellularmitosis 4y ago
  Because it is basically undiscoverable (yet highly valuable!) I’ll take this moment to link to Panicz Godek’s “or this this thing by…?” Twitter thread in which he archives links to anything resembling an AST editor / structural editor: https://twitter.com/PaniczGodek/status/1463860646253060104 https://twitter.com/PaniczGodek/status/1463860646253060104
barbazoo 4y ago
What a lovely story. Makes me want to write an editor.
Sparkyte 4y ago
I only unwrite code.
PerryCox 4y ago
The unit testing section is interesting because I feel like this may not be the perfect approach to them, but it is not a bad method. Too many times I see unit testing being used as the holy grail of debugging and then half of them get ignored because "Oh that's a known issue."
- ec109685 4y ago
  Higher level functional tests are nice for that reason. Yes, they won’t pinpoint a bug instantly but they survive refactors nicely.
  - airocker 4y ago
    If you use micro services properly, unit tests can still call APIs and survive refactors.
jackblemming 4y ago
For a small hobby editor, this is fine. For anything serious, much of this advice will not scale at all.
- wudangmonk 4y ago
  Obviously when you want to scale things up, specially to webscale you want mongodb but I rather like the approach of bootstrapping the minimum viable product and then actually using it in order to design the rest. The world would be a much better place if that was the case.
  - aliqot 4y ago
    > 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?
    - chefandy 4y ago
      > What is about coffee in your actual nostrils that wakes you up more than the full cup itself? Not the person you're replying to, but as a food and beverage expert, I'm confident most beverages will yield more powerful emotional and physical responses and quicker absorbtion of many chemical components when taken nasally.
  - chatmasta 4y ago
    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.
    - dr_kretyn 4y ago
      Thank you for reminding this gem https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
- reducesuffering 4y ago
aliqot 4y ago
> A unique property of writing a code editor is that after a very short bootstrapping period, the thing you’re writing will also be the main tool you’re using to write it. I love these types of projects that happened because someone needed it and wanted to, and I loved that they came to us with the project in hand so they didnt have to talk down 100 but-why's like "dude why do you need yet another hobby editor, just use vim/emacs/whatever, i program in $LANG too and use these 37 plugins and 4 keymappings and it all Just Works". I contribute to a popular IDE that I'm sure a lot of you use, and I'm still going to put down my setup and put a week all-in into this just to, if anything, spiritually put something out there, something positive, to validate this person's work. I see value in projects like these, and though it's hard to put into words I hope someone more eloquent echoes this sentiment in a more tangible way. This is great stuff, I wish more people broke the norm and just did-the-thing. > Randomly deleting unit tests may seem like insanity to some of you, and in certain contexts it probably is — but writing your own editor is a particular endeavour, and if you embark on it I encourage you to do whatever feels right to you, refactor as you please, and embrace the chaos. Happy hacking! I wish more people dared to buck the trends. Good on you, Gus.
- cwilby 4y ago
  > Randomly deleting unit tests may seem like insanity to some of you I too, like to live dangerously.
- pizza 4y ago
  Yep - for projects like this, unit tests serve to reduce the dev's mental load. Once a test gets in the way of making easier progress, it's no longer serving that purpose.
  - travisjungroth 4y ago
    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.
rcshubhadeep 4y ago
Congrats for building something new. I too, am trying to build a note taking app on top of Tauri. I am still extremely early but stories like this keeps me going. Keep up the good work!
captn3m0 4y ago
Writing an editor from scratch is a fun exercise. I've written a few using codemirror, and can recommend the kilo-tutorial[1], which walks you through antirez's kilo editor (a 1000 line editor) and explains each change in steps. [1]: https://viewsourcecode.org/snaptoken/kilo/ https://viewsourcecode.org/snaptoken/kilo/
- bajsejohannes 4y ago
  +1 for kilo. Another great approach is just to read the source code itself. It's only a thousand lines and it's well commented. https://github.com/antirez/kilo/blob/master/kilo.c https://github.com/antirez/kilo/blob/master/kilo.c
FounderBurr 4y ago
So many licenses for other peoples software there, you sure this is from scratch?
- slimsag 4y ago
  I'm sad to see comments like this. When I was starting out years ago, my passion project ended up on HN with a very dismissive comment similar to yours - and it almost turned me off of my passion project of 4 years. I looked at their package.json, they pretty much pulled in the standard library (if there ever was one) of JS. Like lodash and that's about it. Not once did they claim "zero dependencies" or "running on my own OS" so your comment is not only dismissive, but wrong. I for one would encourage people to experiment with building new editors, not dismiss them. Otherwise we end up in a world where editors are built only by large corporations.
  - tmtvl 4y ago
    > 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.
- mulmen 4y ago
  > So many licenses for other peoples software there, you sure this is from scratch? If you wish to make a text editor from scratch you must first invent the universe.
  - jakelazaroff 4y ago
    Real programmers use butterflies. https://xkcd.com/378/ https://xkcd.com/378/
ramesh31 4y ago
>I start most of my algorithms with while (true) That's gonna hurt >When you’ve got a while (true)* loop that searches a tree, it’s gonna throw you an infinite loop every now and then. Fortunately, the more times this happens the better you’ll get at lightweight debugging strategies, and the more familiar you’ll become with the algorithm and the data structures I like your style, kid.
- quickthrower2 4y ago
  I always add a counter to the infinite loops to break out of them incase of unexpectedly high number of iterations
  - bee_rider 4y ago
    Error out or something? Otherwise it would seem the program is in a weird state.
    - quickthrower2 4y ago
      Error, or do the sensible “no results found” for example in the tree search.
  - eps 4y ago
    ... and then what?
    - scotty79 4y ago
      Like the article said. Break out into a debugger and figure out why it got stuck.
- Jach 4y ago
  Reminds me of another style: "Just do it, hack! I approach code like games, rush deep into room, trigger all NPCs, die, after respawn I know where NPCs are." --@bkaradzic
garganzol 4y ago
The code of the editor is in JavaScript and not in TypeScript. Which makes me wonder how hard it goes in terms of regressions when the codebase becomes progressively larger. I love vanilla JavaScript, but I always try to switch to TypeScript if the codebase becomes larger than 100-200 lines of code. Or otherwise I may regret, and I know it too well from previous experiences.
- smt88 4y ago
  Using JavaScript in 2023 is a code smell. You get a massive bug catcher for free with TypeScript, and that's only the most superficial benefit. When I hire devs, I don't care much about their previous stack experience, but if they've actively chosen JS over TS, it tells me their philosophy/priorities are completely backward.
  - thefaux 4y ago
    > 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.
    - tengbretson 4y ago
      [flagged]
      - jrockway 4y ago
        There are no code smells in personal projects, but this isn't one anyway. Every text editor I've ever used has had a single button inside that editor to change the code in the editor to what you just typed in. For an author who has written a blog post on how they eschew unit tests, this is probably the most important feature for one. A one sentence comment about how the author is bad at programming says more about you than the author. People have been writing text editors like that for decades. They aren't bad programmers.
Groxx 4y ago
>Don’t worry about breaking things. If the new structuring you’ve thought of is better, get stuck in and change the code. You will introduce bugs this way, but because you’re using the editor every day to write itself, you’ll find them quickly (in fact, almost by definition, you’ll tend to find them more quickly the more important they are) and your policy of always working on whatever needs fixing right now will make sure they’re fixed promptly. Solid advice in the early-ish days of any project. It's not like your code was perfect before the refactor - you just hadn't found some of the bugs yet. You will have bugs after too, but now you have more experience and will probably find most of them quickly. Don't get too attached to the maybe-bugs you currently have. Also: >When you’ve got a while (true) loop that searches a tree, it’s gonna throw you an infinite loop every now and then. A surprisingly effective strategy I've found for development purposes: never have infinite loops. Nothing is actually infinite. You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible"), and crash your debug builds when it happens. With enough of this, you'll get hits, and they're extremely effective at catching pathological cases that you didn't realize could happen. "It's a bit slow" is often too hard to notice.
- fbdab103 4y ago
  >You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible")... This feels like a lot of line noise for those rare-until-you-hit-them bugs. Just capping a loop with a fixed iteration size deserves a comment as to the rationale. Do you do it everywhere? Just IO? The idea has merit, but in practice, I am not sure where I would implement it. Plus, there would always be the temptation to remove that do-nothing code.
  - tmtvl 4y ago
    > 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.
  - oneeyedpigeon 4y ago
    > 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?
readthenotes1 4y ago
Being in a quibbling mood, and remembering stories of people who would reboot a device using their own drivers and no OS, I object to "ground up". No sand or gallium containing stone was transmogrified in this story. "I wrote a code editor from the ground up. I started with notepad and stopped there."
- quickthrower2 4y ago
  He didn’t re-evolve from primordial soup: disappointing.
crispinb 4y ago
I've fantasised idly for some years over building an editor around something very like the AST Mode, so I'm looking forward to trying this out.
- vbezhenar 4y ago
  Somewhat unrelated but I fantasised about creating an assembly language editor which uses binary executable to save code and some kind of attributes or whatever to save comments, identifiers and so on. Will not work with macroses, but an interesting idea IMO. Might actually work with Java-like language (JVM bytecode is very close to Java AST).
- cellularmitosis 4y ago
  (mods forgive me for double-posting this link!) https://twitter.com/PaniczGodek/status/1463860646253060104 https://twitter.com/PaniczGodek/status/1463860646253060104 (Scroll up in that thread for AST inspiration)
xrayarx 4y ago
The editor is based on Electron 22.1.0 https://gitlab.com/gushogg-blake/edita-release.git https://gitlab.com/gushogg-blake/edita-release.git
- geenat 4y ago
  Thanks. First thing I look for when looking at new editors. Electron leads to high latency and slowdown once your editor grows big enough- even on 8+ core machines. We have so many electron based editors at this point, including incumbent VSCode....
  - capableweb 4y ago
    > 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.
francois_h 4y ago
This reminds me of the time I hacked together an editor in assembly. I’m all for writing “just another xyz”, however after 2 decades of development I’m tired of the infinite amount of todo apps/editors/etc. on the web. I am conflicted though. On the one hand reimplementing something existing is a great way to learn coding, sdk’s, api’s, etc. On the other hand I feel it’s limiting imaginations and I would love to see something new and unique. How many “better mouse traps” do we need.
moongoose 4y ago
The off-center plus icon in the sidebar is bothering me more than it should....
kenniskrag 4y ago
here a video, where he shows some features: https://codepatterns.vercel.app/ https://codepatterns.vercel.app/
xav_authentique 4y ago
I'm working on a new programming language and every point resonates with me on a spiritual level. One thing that helped me a lot was writing more integration tests at the outer edges of the application, opposed to unit tests of individual modules. Usually the logic doesn't change between rewrites, so keeping a somewhat stable interface keeps me from breaking stuff in between grand rewrites.
oneeyedpigeon 4y ago
Anyone got this working on macOS? Out of the box, I get: > App threw an error during load > Error: --start-args argument required to separate command-line args from node/electron paths > at filters (~/progs/edita/build/electron/mainProcess/utils/getArgs.js:13:10) after `npm start`.
- mvts 4y ago
  same on windows
  - gushogg-blake 4y ago
    Should be fixed now. Thanks!
    - oneeyedpigeon 4y ago
      Perfect — thank you!
matklad 4y ago
For comparison table in code patterns: https://codepatterns.vercel.app/ https://codepatterns.vercel.app/ There’s one column missing: whether the query is purely syntactic or has semantics as well. In particular, JetBrains allows not only searching for all _expressions_, but also, eg, constrain expressions to be of a specific type, something which isn’t possible with just a parser: https://www.jetbrains.com/help/idea/search-templates.html#type_filter https://www.jetbrains.com/help/idea/search-templates.html#ty...
davedx 4y ago
So refreshingly pragmatic. Some of these ways of working will be brutally beaten out of you in most dev teams unfortunately, whether they're effective or not. Yay cargo culting!
bluelightning2k 4y ago
Just wanted to say this is fascinating. Good luck with it all. For the 2 major features - short demo clips would go a major way.
vidarh 4y ago
I use my own editor as my daily editor, both for code and most other text files. A few observations on the article: > Use it early This was key to me. If you're going to wait until you have a perfect editor to use it, you're better off spending your time on something else, because it'll take a really long time to get there if you ever do. I started working on my editor because I was endlessly tinkering with my emacs config and realised I could write an editor in fewer lines than my config... You need to have a reasonable clear picture of what an MVP looks like to you. But having as a goal to use it early can also drive design. E.g. in my case the first thing I did to enable this was to have the editor serialise all open buffers to JSON and write a dump regularly. If I didn't expect to use the editor until it was stable, I might not have. But I came to like being able to start the editor after a reboot and have all of my buffers as they were. I later also moved the buffers into a separate process using DrB (the editor is in Ruby). Combined that made it near impossible to lose changes as DrB makes the backend near crash proof (exceptions are forwarded to the client), and the checkpoints/dumps deals with the last little piece of risk. The day that was finished, I switched 90%+ of my editing to my own editor even though it was still buggy and lacking in functionality. As a result I as of writing have 2199 open buffers, some dating back a couple of years. I kill some now and again - e.g. if I open a particularly large file, or something sensitive - but by default I just stopped caring as the dump is only 66MB. > If you’re using the code editor to write itself, the most pressing bugs and missing features will make themselves apparent to you for free. This is a big deal with using my own editor. I have a "roadmap" of things I like the idea of, but "what is painful right now" trumps all of it, because I don't have any users (nor do I want any - I'm slowly splitting functionality into gems that I'm happy to deal with issues with, but the github copy of the repo of the editor itself is wildly out of date and heavily dependent on my personal setup, so likely won't even run for anyone else) It also means I can follow the "refactor when it seems like a good idea" advice without caring if the editor is half broken for a while. I have bugs in there that are clear regressions that I'm ok with working around but that I'd never allow myself to commit code for if I was writing this with the expectation of other people using it.
- celeritascelery 4y ago
  This is really interesting! Is your editor written is Ruby then? Is the code hosted somewhere public? 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 am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch.
jojohohanon 4y ago
I’m constantly surprised by the ubiquity of javascript. Of all the languages I would choose for a desktop app, it ranks pretty far down, yet I am clearly in the minority. But I’m not here to show my age or biases - I am genuinely curious. What am I missing that makes JS/node (or is that a redundancy? Is there any other choice than node for JS local development?) such an attractive choice for local development. Over say java / swift / rust for static languages or python / closure / julia for dynamic?
- cellularmitosis 4y ago
  Most likely it is simply the fact that they use it for their day job. Tackling a tough new project from scratch is already mentally taxing, doing it in an unfamiliar lang doubly so.
- izackp 4y ago
  I too have the same sentiment. I realize though there are not many frameworks for cross platform development. If you do want a native language you'll probably have to use QT. There are more out there, but most are based on native widgets which have their own unique behavior which makes them difficult to abstract. It seems to me that these electron web apps provide this 'leak free' abstraction.
- metalspot 4y ago
  i have used nodejs for all of my personal projects for years (almost 10?) now. my reasons are: * JS has the largest developer and runtime install base * JS is very competitive with Go/Java on performance and the runtime (v8) actually improves on cpu/memory performance over time * you get a UI that supports everything on all major platforms (the browser) for free * the apps i write are generally IO heavy and so the async event driven model is very useful to have as a 1st class feature * starting with an async event driven language/runtime makes it very easy to decompose your app if you want to split something out into a separate service * i know js, and work with it professionally already, and it has a large market for professional dev work, so everything i learn in my personal projects increases my value as a professional
- Slackwise 4y ago
garfieldnate 4y ago
The CodePatterns piece deserves serious consideration as its own project; it could be the basis for a generic refactoring engine. It would be great to have some kind of refactoring scripting language for e.g. updating clients of your library when you make a breaking change to it. Just include the update script and your clients will have a painless upgrade to the new library version.
twodave 4y ago
> Don’t waste time keeping unit tests constantly up-to-date if the code is working. Once the code is both correct and well-factored, feel free to disable or remove the unit tests so they don’t clutter your test runs with errors after subsequent refactorings. Wait, what?! To each their own, but you'll pry my well-maintained collection of unit tests--which describe all _defined behavior_ in my application--from my cold dead fingers, thank you very much.
- gfodor 4y ago
  Take a second and consider the tradeoff here. I think you're underestimating the benefits of deleting tests. This doesn't mean that you should delete your tests, but you should definitely should be able to steelman the argument that you should delete your tests.
  - twodave 4y ago
    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.
    - gfodor 4y ago
      A huge benefit of deleting tests isn't merely the reduction in maintenence but the reduction in "conceptual drag". Tests cause design decisions to get baked into code to a higher degree than if the same decisions were made in a codebase without tests. Tests certainly can be valuable for verifying the scope of changes, but they're not the only way to do this. I could imagine supporting the process of delete-as-you-go testing if you could convince me that whatever you are doing to identify regressions works just as well as the test suite would.
graboid 4y ago
Very cool project! The AST mode is super interesting. I also code an editor, and using it from the beginning is really the key.
- 95014_refugee 4y ago
  Projectional editing (and storing the AST, not the projection) are both grail-level items for me. I’m traumatized by the lack of attention mbeddr got; while it was active / maintained it felt like the next big thing for C-family development, and the projectional editing (plus the language concept stacking) were the key features in my eyes.
- gr__or 4y ago
  I'ma use this as an opportunity to plug my own AST mode project: https://twitter.com/watware/status/1607026712755458055 https://twitter.com/watware/status/1607026712755458055
slowmovintarget 4y ago
I got a kick out of the Agile Manifesto parody on the main page: >> - ... - Perfecting smooth and ergonomic interactions over shipping quickly. - Providing rich and configurable features over simplicity or minimalism. - A visually pleasing and quiet interface (over keeping up with design trends).
JediPig 4y ago
Turbo C for dos was written in 2 1/2 months. Now it takes almost 2 years to write a code editor? This is not a ding towards the OP. It is an awareness that something has gone fundamentally wrong with development. vscode and modern IDE now take 1-2 gb of ram for medium projects. What has caused so much resource usage?
jdmg94 4y ago
I tried to do the same with my iPad but the limitations of NPM have made it a bit difficult, def past the first 12 months

410 points by gushogg-blake 4y ago

jarbus 4y ago

Is there anything like AST mode for neovim? Sounds like a cool feature.

cellularmitosis 4y ago
Because it is basically undiscoverable (yet highly valuable!) I’ll take this moment to link to Panicz Godek’s “or this this thing by…?” Twitter thread in which he archives links to anything resembling an AST editor / structural editor: https://twitter.com/PaniczGodek/status/1463860646253060104 https://twitter.com/PaniczGodek/status/1463860646253060104

barbazoo 4y ago

What a lovely story. Makes me want to write an editor.

Sparkyte 4y ago

I only unwrite code.

PerryCox 4y ago

The unit testing section is interesting because I feel like this may not be the perfect approach to them, but it is not a bad method. Too many times I see unit testing being used as the holy grail of debugging and then half of them get ignored because "Oh that's a known issue."

ec109685 4y ago
Higher level functional tests are nice for that reason. Yes, they won’t pinpoint a bug instantly but they survive refactors nicely.
- airocker 4y ago
  If you use micro services properly, unit tests can still call APIs and survive refactors.

jackblemming 4y ago

For a small hobby editor, this is fine. For anything serious, much of this advice will not scale at all.

wudangmonk 4y ago
Obviously when you want to scale things up, specially to webscale you want mongodb but I rather like the approach of bootstrapping the minimum viable product and then actually using it in order to design the rest. The world would be a much better place if that was the case.
- aliqot 4y ago
  > 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?
  - chefandy 4y ago
    > What is about coffee in your actual nostrils that wakes you up more than the full cup itself? Not the person you're replying to, but as a food and beverage expert, I'm confident most beverages will yield more powerful emotional and physical responses and quicker absorbtion of many chemical components when taken nasally.
- chatmasta 4y ago
  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.
  - dr_kretyn 4y ago
    Thank you for reminding this gem https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
reducesuffering 4y ago

aliqot 4y ago

> A unique property of writing a code editor is that after a very short bootstrapping period, the thing you’re writing will also be the main tool you’re using to write it. I love these types of projects that happened because someone needed it and wanted to, and I loved that they came to us with the project in hand so they didnt have to talk down 100 but-why's like "dude why do you need yet another hobby editor, just use vim/emacs/whatever, i program in $LANG too and use these 37 plugins and 4 keymappings and it all Just Works". I contribute to a popular IDE that I'm sure a lot of you use, and I'm still going to put down my setup and put a week all-in into this just to, if anything, spiritually put something out there, something positive, to validate this person's work. I see value in projects like these, and though it's hard to put into words I hope someone more eloquent echoes this sentiment in a more tangible way. This is great stuff, I wish more people broke the norm and just did-the-thing. > Randomly deleting unit tests may seem like insanity to some of you, and in certain contexts it probably is — but writing your own editor is a particular endeavour, and if you embark on it I encourage you to do whatever feels right to you, refactor as you please, and embrace the chaos. Happy hacking! I wish more people dared to buck the trends. Good on you, Gus.

cwilby 4y ago
> Randomly deleting unit tests may seem like insanity to some of you I too, like to live dangerously.
pizza 4y ago
Yep - for projects like this, unit tests serve to reduce the dev's mental load. Once a test gets in the way of making easier progress, it's no longer serving that purpose.
- travisjungroth 4y ago
  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.

rcshubhadeep 4y ago

Congrats for building something new. I too, am trying to build a note taking app on top of Tauri. I am still extremely early but stories like this keeps me going. Keep up the good work!

captn3m0 4y ago

Writing an editor from scratch is a fun exercise. I've written a few using codemirror, and can recommend the kilo-tutorial[1], which walks you through antirez's kilo editor (a 1000 line editor) and explains each change in steps. [1]: https://viewsourcecode.org/snaptoken/kilo/ https://viewsourcecode.org/snaptoken/kilo/

bajsejohannes 4y ago
+1 for kilo. Another great approach is just to read the source code itself. It's only a thousand lines and it's well commented. https://github.com/antirez/kilo/blob/master/kilo.c https://github.com/antirez/kilo/blob/master/kilo.c

FounderBurr 4y ago

So many licenses for other peoples software there, you sure this is from scratch?

slimsag 4y ago
I'm sad to see comments like this. When I was starting out years ago, my passion project ended up on HN with a very dismissive comment similar to yours - and it almost turned me off of my passion project of 4 years. I looked at their package.json, they pretty much pulled in the standard library (if there ever was one) of JS. Like lodash and that's about it. Not once did they claim "zero dependencies" or "running on my own OS" so your comment is not only dismissive, but wrong. I for one would encourage people to experiment with building new editors, not dismiss them. Otherwise we end up in a world where editors are built only by large corporations.
- tmtvl 4y ago
  > 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.
mulmen 4y ago
> So many licenses for other peoples software there, you sure this is from scratch? If you wish to make a text editor from scratch you must first invent the universe.
- jakelazaroff 4y ago
  Real programmers use butterflies. https://xkcd.com/378/ https://xkcd.com/378/

ramesh31 4y ago

>I start most of my algorithms with while (true) That's gonna hurt >When you’ve got a while (true)* loop that searches a tree, it’s gonna throw you an infinite loop every now and then. Fortunately, the more times this happens the better you’ll get at lightweight debugging strategies, and the more familiar you’ll become with the algorithm and the data structures I like your style, kid.

quickthrower2 4y ago
I always add a counter to the infinite loops to break out of them incase of unexpectedly high number of iterations
- bee_rider 4y ago
  Error out or something? Otherwise it would seem the program is in a weird state.
  - quickthrower2 4y ago
    Error, or do the sensible “no results found” for example in the tree search.
- eps 4y ago
  ... and then what?
  - scotty79 4y ago
    Like the article said. Break out into a debugger and figure out why it got stuck.
Jach 4y ago
Reminds me of another style: "Just do it, hack! I approach code like games, rush deep into room, trigger all NPCs, die, after respawn I know where NPCs are." --@bkaradzic

garganzol 4y ago

The code of the editor is in JavaScript and not in TypeScript. Which makes me wonder how hard it goes in terms of regressions when the codebase becomes progressively larger. I love vanilla JavaScript, but I always try to switch to TypeScript if the codebase becomes larger than 100-200 lines of code. Or otherwise I may regret, and I know it too well from previous experiences.

smt88 4y ago
Using JavaScript in 2023 is a code smell. You get a massive bug catcher for free with TypeScript, and that's only the most superficial benefit. When I hire devs, I don't care much about their previous stack experience, but if they've actively chosen JS over TS, it tells me their philosophy/priorities are completely backward.
- thefaux 4y ago
  > 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.
  - tengbretson 4y ago
    [flagged]
    - jrockway 4y ago
      There are no code smells in personal projects, but this isn't one anyway. Every text editor I've ever used has had a single button inside that editor to change the code in the editor to what you just typed in. For an author who has written a blog post on how they eschew unit tests, this is probably the most important feature for one. A one sentence comment about how the author is bad at programming says more about you than the author. People have been writing text editors like that for decades. They aren't bad programmers.

Groxx 4y ago

>Don’t worry about breaking things. If the new structuring you’ve thought of is better, get stuck in and change the code. You will introduce bugs this way, but because you’re using the editor every day to write itself, you’ll find them quickly (in fact, almost by definition, you’ll tend to find them more quickly the more important they are) and your policy of always working on whatever needs fixing right now will make sure they’re fixed promptly. Solid advice in the early-ish days of any project. It's not like your code was perfect before the refactor - you just hadn't found some of the bugs yet. You will have bugs after too, but now you have more experience and will probably find most of them quickly. Don't get too attached to the maybe-bugs you currently have. Also: >When you’ve got a while (true) loop that searches a tree, it’s gonna throw you an infinite loop every now and then. A surprisingly effective strategy I've found for development purposes: never have infinite loops. Nothing is actually infinite. You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible"), and crash your debug builds when it happens. With enough of this, you'll get hits, and they're extremely effective at catching pathological cases that you didn't realize could happen. "It's a bit slow" is often too hard to notice.

fbdab103 4y ago
>You think X might loop 100x? Put a limit of 10,000 ("absurd and impossible")... This feels like a lot of line noise for those rare-until-you-hit-them bugs. Just capping a loop with a fixed iteration size deserves a comment as to the rationale. Do you do it everywhere? Just IO? The idea has merit, but in practice, I am not sure where I would implement it. Plus, there would always be the temptation to remove that do-nothing code.
- tmtvl 4y ago
  > 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.
- oneeyedpigeon 4y ago
  > 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?

readthenotes1 4y ago

Being in a quibbling mood, and remembering stories of people who would reboot a device using their own drivers and no OS, I object to "ground up". No sand or gallium containing stone was transmogrified in this story. "I wrote a code editor from the ground up. I started with notepad and stopped there."

quickthrower2 4y ago
He didn’t re-evolve from primordial soup: disappointing.

crispinb 4y ago

I've fantasised idly for some years over building an editor around something very like the AST Mode, so I'm looking forward to trying this out.

vbezhenar 4y ago
Somewhat unrelated but I fantasised about creating an assembly language editor which uses binary executable to save code and some kind of attributes or whatever to save comments, identifiers and so on. Will not work with macroses, but an interesting idea IMO. Might actually work with Java-like language (JVM bytecode is very close to Java AST).
cellularmitosis 4y ago
(mods forgive me for double-posting this link!) https://twitter.com/PaniczGodek/status/1463860646253060104 https://twitter.com/PaniczGodek/status/1463860646253060104 (Scroll up in that thread for AST inspiration)

xrayarx 4y ago

The editor is based on Electron 22.1.0 https://gitlab.com/gushogg-blake/edita-release.git https://gitlab.com/gushogg-blake/edita-release.git

geenat 4y ago
Thanks. First thing I look for when looking at new editors. Electron leads to high latency and slowdown once your editor grows big enough- even on 8+ core machines. We have so many electron based editors at this point, including incumbent VSCode....
- capableweb 4y ago
  > 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.

francois_h 4y ago

This reminds me of the time I hacked together an editor in assembly. I’m all for writing “just another xyz”, however after 2 decades of development I’m tired of the infinite amount of todo apps/editors/etc. on the web. I am conflicted though. On the one hand reimplementing something existing is a great way to learn coding, sdk’s, api’s, etc. On the other hand I feel it’s limiting imaginations and I would love to see something new and unique. How many “better mouse traps” do we need.

moongoose 4y ago

The off-center plus icon in the sidebar is bothering me more than it should....

kenniskrag 4y ago

here a video, where he shows some features: https://codepatterns.vercel.app/ https://codepatterns.vercel.app/

xav_authentique 4y ago

I'm working on a new programming language and every point resonates with me on a spiritual level. One thing that helped me a lot was writing more integration tests at the outer edges of the application, opposed to unit tests of individual modules. Usually the logic doesn't change between rewrites, so keeping a somewhat stable interface keeps me from breaking stuff in between grand rewrites.

oneeyedpigeon 4y ago

Anyone got this working on macOS? Out of the box, I get: > App threw an error during load > Error: --start-args argument required to separate command-line args from node/electron paths > at filters (~/progs/edita/build/electron/mainProcess/utils/getArgs.js:13:10) after `npm start`.

mvts 4y ago
same on windows
- gushogg-blake 4y ago
  Should be fixed now. Thanks!
  - oneeyedpigeon 4y ago
    Perfect — thank you!

matklad 4y ago

For comparison table in code patterns: https://codepatterns.vercel.app/ https://codepatterns.vercel.app/ There’s one column missing: whether the query is purely syntactic or has semantics as well. In particular, JetBrains allows not only searching for all _expressions_, but also, eg, constrain expressions to be of a specific type, something which isn’t possible with just a parser: https://www.jetbrains.com/help/idea/search-templates.html#type_filter https://www.jetbrains.com/help/idea/search-templates.html#ty...

davedx 4y ago

So refreshingly pragmatic. Some of these ways of working will be brutally beaten out of you in most dev teams unfortunately, whether they're effective or not. Yay cargo culting!

bluelightning2k 4y ago

Just wanted to say this is fascinating. Good luck with it all. For the 2 major features - short demo clips would go a major way.

vidarh 4y ago

I use my own editor as my daily editor, both for code and most other text files. A few observations on the article: > Use it early This was key to me. If you're going to wait until you have a perfect editor to use it, you're better off spending your time on something else, because it'll take a really long time to get there if you ever do. I started working on my editor because I was endlessly tinkering with my emacs config and realised I could write an editor in fewer lines than my config... You need to have a reasonable clear picture of what an MVP looks like to you. But having as a goal to use it early can also drive design. E.g. in my case the first thing I did to enable this was to have the editor serialise all open buffers to JSON and write a dump regularly. If I didn't expect to use the editor until it was stable, I might not have. But I came to like being able to start the editor after a reboot and have all of my buffers as they were. I later also moved the buffers into a separate process using DrB (the editor is in Ruby). Combined that made it near impossible to lose changes as DrB makes the backend near crash proof (exceptions are forwarded to the client), and the checkpoints/dumps deals with the last little piece of risk. The day that was finished, I switched 90%+ of my editing to my own editor even though it was still buggy and lacking in functionality. As a result I as of writing have 2199 open buffers, some dating back a couple of years. I kill some now and again - e.g. if I open a particularly large file, or something sensitive - but by default I just stopped caring as the dump is only 66MB. > If you’re using the code editor to write itself, the most pressing bugs and missing features will make themselves apparent to you for free. This is a big deal with using my own editor. I have a "roadmap" of things I like the idea of, but "what is painful right now" trumps all of it, because I don't have any users (nor do I want any - I'm slowly splitting functionality into gems that I'm happy to deal with issues with, but the github copy of the repo of the editor itself is wildly out of date and heavily dependent on my personal setup, so likely won't even run for anyone else) It also means I can follow the "refactor when it seems like a good idea" advice without caring if the editor is half broken for a while. I have bugs in there that are clear regressions that I'm ok with working around but that I'd never allow myself to commit code for if I was writing this with the expectation of other people using it.

celeritascelery 4y ago
This is really interesting! Is your editor written is Ruby then? Is the code hosted somewhere public? 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 am also curious what you thought was a limiting factor of Emacs so that you found it easier to write an editor from scratch.

jojohohanon 4y ago

I’m constantly surprised by the ubiquity of javascript. Of all the languages I would choose for a desktop app, it ranks pretty far down, yet I am clearly in the minority. But I’m not here to show my age or biases - I am genuinely curious. What am I missing that makes JS/node (or is that a redundancy? Is there any other choice than node for JS local development?) such an attractive choice for local development. Over say java / swift / rust for static languages or python / closure / julia for dynamic?

cellularmitosis 4y ago
Most likely it is simply the fact that they use it for their day job. Tackling a tough new project from scratch is already mentally taxing, doing it in an unfamiliar lang doubly so.
izackp 4y ago
I too have the same sentiment. I realize though there are not many frameworks for cross platform development. If you do want a native language you'll probably have to use QT. There are more out there, but most are based on native widgets which have their own unique behavior which makes them difficult to abstract. It seems to me that these electron web apps provide this 'leak free' abstraction.
metalspot 4y ago
i have used nodejs for all of my personal projects for years (almost 10?) now. my reasons are: * JS has the largest developer and runtime install base * JS is very competitive with Go/Java on performance and the runtime (v8) actually improves on cpu/memory performance over time * you get a UI that supports everything on all major platforms (the browser) for free * the apps i write are generally IO heavy and so the async event driven model is very useful to have as a 1st class feature * starting with an async event driven language/runtime makes it very easy to decompose your app if you want to split something out into a separate service * i know js, and work with it professionally already, and it has a large market for professional dev work, so everything i learn in my personal projects increases my value as a professional
Slackwise 4y ago

garfieldnate 4y ago

The CodePatterns piece deserves serious consideration as its own project; it could be the basis for a generic refactoring engine. It would be great to have some kind of refactoring scripting language for e.g. updating clients of your library when you make a breaking change to it. Just include the update script and your clients will have a painless upgrade to the new library version.

twodave 4y ago

> Don’t waste time keeping unit tests constantly up-to-date if the code is working. Once the code is both correct and well-factored, feel free to disable or remove the unit tests so they don’t clutter your test runs with errors after subsequent refactorings. Wait, what?! To each their own, but you'll pry my well-maintained collection of unit tests--which describe all _defined behavior_ in my application--from my cold dead fingers, thank you very much.

gfodor 4y ago
Take a second and consider the tradeoff here. I think you're underestimating the benefits of deleting tests. This doesn't mean that you should delete your tests, but you should definitely should be able to steelman the argument that you should delete your tests.
- twodave 4y ago
  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.
  - gfodor 4y ago
    A huge benefit of deleting tests isn't merely the reduction in maintenence but the reduction in "conceptual drag". Tests cause design decisions to get baked into code to a higher degree than if the same decisions were made in a codebase without tests. Tests certainly can be valuable for verifying the scope of changes, but they're not the only way to do this. I could imagine supporting the process of delete-as-you-go testing if you could convince me that whatever you are doing to identify regressions works just as well as the test suite would.

graboid 4y ago

Very cool project! The AST mode is super interesting. I also code an editor, and using it from the beginning is really the key.

95014_refugee 4y ago
Projectional editing (and storing the AST, not the projection) are both grail-level items for me. I’m traumatized by the lack of attention mbeddr got; while it was active / maintained it felt like the next big thing for C-family development, and the projectional editing (plus the language concept stacking) were the key features in my eyes.
gr__or 4y ago
I'ma use this as an opportunity to plug my own AST mode project: https://twitter.com/watware/status/1607026712755458055 https://twitter.com/watware/status/1607026712755458055

slowmovintarget 4y ago

I got a kick out of the Agile Manifesto parody on the main page: >> - ... - Perfecting smooth and ergonomic interactions over shipping quickly. - Providing rich and configurable features over simplicity or minimalism. - A visually pleasing and quiet interface (over keeping up with design trends).

JediPig 4y ago

Turbo C for dos was written in 2 1/2 months. Now it takes almost 2 years to write a code editor? This is not a ding towards the OP. It is an awareness that something has gone fundamentally wrong with development. vscode and modern IDE now take 1-2 gb of ram for medium projects. What has caused so much resource usage?

jdmg94 4y ago

I tried to do the same with my iPad but the limitations of NPM have made it a bit difficult, def past the first 12 months