3 ms·

The comments here don’t seem to reflect what I think is the most interesting point here: quick loops of satisfaction. So much of programming often takes forever

The comments here don’t seem to reflect what I think is the most interesting point here: quick loops of satisfaction. So much of programming often takes forever to get any real utility or see progress. That can really be depressing, especially for a side project. That’s what I love about cooking or sewing; you quickly see the process come together. I wish programming was like that more often.

vidarh 3y ago
Yeah, I'm using my own terminal, and my own editor. The terminal also relies on a font-engine I have heavily modified (I converted the original from C to Ruby). So I "control" the whole pipeline from the editor to the actual pixels, and on one hand it has all kinds of quirks I wouldn't wish on someone else, on the other hand they all have bits and pieces that are custom-written to fit exactly what I want, and which features gets implemented are decided almost entirely based on which little change feels like it'll immediately improve my life right now (and I'm not joking - I spend enough time in front of my terminal that fixing small aspects of the terminal or my editor does feel like it is making an actual improvement in my happiness).
- wnolens 3y ago
  What do you do? That all sounds like so so much effort, I'm very curious. I'm in a terminal most of the day but never have I ever thought of once writing my own. Installing ohmyzsh was a huge step - I'm good for life now.
  - 8n4vidtmkvmk 3y ago
    I'm constantly disappointed by my terminal. It always feels sluggish, especially with something like ohmyzsh. Boggles my mind why the whole pipeline is synchronous too.
  - vidarh 3y ago
    Devops and development. It is effort, but it's also relaxing. I'll start by saying I don't think this is for everyone and it is far easier if you like minimalist environments. E.g. to me Visual Studio Code for example is an utter nightmare of visual overload. I want my editor to at most show a minimal one-line or less status area and maybe, optionally line numbers. Nothing more. I actively don't want it to pop up auto-completion options or documentation. And so on. A lot of my requirements makes things simpler rather than harder, and that's not necessarily the case for others. I started with the editor when I realised my Emacs config was several thousand lines and I though "I can write a whole editor in less". As it happens, a basic editor can be extremely small even in a language like C (e.g. see Antirez' "kilo"), but important: It can be extra small when you write it only for you. I can overlook bugs that doesn't bother me, and only implement functions I care about, and make assumptions about the environment others can't. E.g. my editor presumes you're running under bspwm. It can run without it, but requires adapting helper scripts, because e.g. "split horizontal" and "split vertical" are implemented by opening a container and starting a new instance of the editor that will fill that area on screen and attach to the same view (the buffers are all held in a server, similar to if you use Emacs in client server mode). It also contains no code for picking files, because it spawns an external one-liner which uses rofi to select files (same for themes etc.). After a while, I started thinking about minor nuisances as a result of my terminal. E.g. I like a high degree of translucency, but that makes text hard to read unless there's an outline, so I started hacking outlines into st and kitty, but found other things that annoyed me, and before you knew it I had a "I bet I could replace this" moment. I don't really care about packing up these for others as-is because so much is specific to how I want things, but I am slowly working my way through and pulling out generic components to release, and then I'll clean up the pase so it's at least there to look at. EDIT: Just to add that e.g. for the terminal, the entire codebase, including packaging up all dependences other than the standard Ruby library, is currently ~6.5k lines. That includes ca. 1.5k lines for the Toml parser for the config files, for example, so I think it can be trimmed down significantly. For comparison `st` is around 8k lines, excluding dependencies like Xlib, freetype etc, and Xterm is around 88k lines. That's not to crow about how tiny mine is, because a lot of it I get "for free" thanks to Ruby, and a lot of it is down to just not implementing features I don't care about. But it is an illustration of how you can start really small and make something usable when you're free to keep a really tight focus. "Just" the terminal codebase itself is about 1.5k lines. But it will fail to correctly render a bunch of apps that I don't care about because there are still escapes I haven't bothered to implement. That's fine for me, but not for a terminal for general use.
    - wnolens 3y ago
      Awesome thanks for the reply. I definitely love that feeling of building just for myself. In the past year I've adopted emacs in hopes to achieve the sort of agency you have to define the experience you're having on your computer. So I completely understand the motivation, it's just that terminal and text editor seem like daunting projects. I'm SO so busy at work, and after work I need to unplug. I can justify carving out 10-15% of my time to sharpen my axe, but i just assume that a text editor took a team of people years to create. I think you are highly productive developer. Cheers
      - vidarh 3y ago
        Thanks. But keep in mind to me programming has been a hobby since childhood. It is what I do to unplug from work - just different types of projects. That makes all the difference in terms of motivation, and energy. That said, while an editor like Emacs is a big project, an editor can start really small. E.g. look up Femto on GitHub, which was my starting point, or Antirez' "Kilo", so named because its about 1k lines. If you ever get the itch, look at existing small editors and pick one to butcher as a starting point. You can replace every single line over time, but starting from something working let's you focus on what you want it to be rather than how to get it to a point where you can start using it (and even if not something you can use for everything, at least now and again). It's a lot easier to stay with a project like this is you get to where you use it every day, and every improvement makes things a bit easier.
m463 3y ago
> I wish programming was like that more often. Sometimes I think a shitty visible working prototype is a better goal than a more elaborate deep prototype that takes more time to see results. for example, I know you can design in a log system, but you can start with printf and do the logging later. It's more important to tickle your motivation brain cells with something that works. Or, you can start with a working project, strip stuff out, and get something visible. Then add your code. There's also another (related?) trick - when something is working stop in the middle of a feature that is almost done. The next day you tickle those motivation braincells when you can dive right in and finish it instead of diving into the motivation-killing "planning the next step" stage.

vidarh 3y ago

Yeah, I'm using my own terminal, and my own editor. The terminal also relies on a font-engine I have heavily modified (I converted the original from C to Ruby). So I "control" the whole pipeline from the editor to the actual pixels, and on one hand it has all kinds of quirks I wouldn't wish on someone else, on the other hand they all have bits and pieces that are custom-written to fit exactly what I want, and which features gets implemented are decided almost entirely based on which little change feels like it'll immediately improve my life right now (and I'm not joking - I spend enough time in front of my terminal that fixing small aspects of the terminal or my editor does feel like it is making an actual improvement in my happiness).

wnolens 3y ago
What do you do? That all sounds like so so much effort, I'm very curious. I'm in a terminal most of the day but never have I ever thought of once writing my own. Installing ohmyzsh was a huge step - I'm good for life now.
- 8n4vidtmkvmk 3y ago
  I'm constantly disappointed by my terminal. It always feels sluggish, especially with something like ohmyzsh. Boggles my mind why the whole pipeline is synchronous too.
- vidarh 3y ago
  Devops and development. It is effort, but it's also relaxing. I'll start by saying I don't think this is for everyone and it is far easier if you like minimalist environments. E.g. to me Visual Studio Code for example is an utter nightmare of visual overload. I want my editor to at most show a minimal one-line or less status area and maybe, optionally line numbers. Nothing more. I actively don't want it to pop up auto-completion options or documentation. And so on. A lot of my requirements makes things simpler rather than harder, and that's not necessarily the case for others. I started with the editor when I realised my Emacs config was several thousand lines and I though "I can write a whole editor in less". As it happens, a basic editor can be extremely small even in a language like C (e.g. see Antirez' "kilo"), but important: It can be extra small when you write it only for you. I can overlook bugs that doesn't bother me, and only implement functions I care about, and make assumptions about the environment others can't. E.g. my editor presumes you're running under bspwm. It can run without it, but requires adapting helper scripts, because e.g. "split horizontal" and "split vertical" are implemented by opening a container and starting a new instance of the editor that will fill that area on screen and attach to the same view (the buffers are all held in a server, similar to if you use Emacs in client server mode). It also contains no code for picking files, because it spawns an external one-liner which uses rofi to select files (same for themes etc.). After a while, I started thinking about minor nuisances as a result of my terminal. E.g. I like a high degree of translucency, but that makes text hard to read unless there's an outline, so I started hacking outlines into st and kitty, but found other things that annoyed me, and before you knew it I had a "I bet I could replace this" moment. I don't really care about packing up these for others as-is because so much is specific to how I want things, but I am slowly working my way through and pulling out generic components to release, and then I'll clean up the pase so it's at least there to look at. EDIT: Just to add that e.g. for the terminal, the entire codebase, including packaging up all dependences other than the standard Ruby library, is currently ~6.5k lines. That includes ca. 1.5k lines for the Toml parser for the config files, for example, so I think it can be trimmed down significantly. For comparison `st` is around 8k lines, excluding dependencies like Xlib, freetype etc, and Xterm is around 88k lines. That's not to crow about how tiny mine is, because a lot of it I get "for free" thanks to Ruby, and a lot of it is down to just not implementing features I don't care about. But it is an illustration of how you can start really small and make something usable when you're free to keep a really tight focus. "Just" the terminal codebase itself is about 1.5k lines. But it will fail to correctly render a bunch of apps that I don't care about because there are still escapes I haven't bothered to implement. That's fine for me, but not for a terminal for general use.
  - wnolens 3y ago
    Awesome thanks for the reply. I definitely love that feeling of building just for myself. In the past year I've adopted emacs in hopes to achieve the sort of agency you have to define the experience you're having on your computer. So I completely understand the motivation, it's just that terminal and text editor seem like daunting projects. I'm SO so busy at work, and after work I need to unplug. I can justify carving out 10-15% of my time to sharpen my axe, but i just assume that a text editor took a team of people years to create. I think you are highly productive developer. Cheers
    - vidarh 3y ago
      Thanks. But keep in mind to me programming has been a hobby since childhood. It is what I do to unplug from work - just different types of projects. That makes all the difference in terms of motivation, and energy. That said, while an editor like Emacs is a big project, an editor can start really small. E.g. look up Femto on GitHub, which was my starting point, or Antirez' "Kilo", so named because its about 1k lines. If you ever get the itch, look at existing small editors and pick one to butcher as a starting point. You can replace every single line over time, but starting from something working let's you focus on what you want it to be rather than how to get it to a point where you can start using it (and even if not something you can use for everything, at least now and again). It's a lot easier to stay with a project like this is you get to where you use it every day, and every improvement makes things a bit easier.

m463 3y ago

> I wish programming was like that more often. Sometimes I think a shitty visible working prototype is a better goal than a more elaborate deep prototype that takes more time to see results. for example, I know you can design in a log system, but you can start with printf and do the logging later. It's more important to tickle your motivation brain cells with something that works. Or, you can start with a working project, strip stuff out, and get something visible. Then add your code. There's also another (related?) trick - when something is working stop in the middle of a feature that is almost done. The next day you tickle those motivation braincells when you can dive right in and finish it instead of diving into the motivation-killing "planning the next step" stage.