5 ms·

One of my goals is to rewrite all software for developing software, with each application at about (or less than) this sweet spot. Database, version control, r

One of my goals is to rewrite all software for developing software, with each application at about (or less than) this sweet spot. Database, version control, runtime type system (Lua), proto-like serialization, code refactoring, parsing library... The list goes on. About the only heavy thing will be the text editor, and I'm still keeping that at a few thousand lines (+ a small core data structure library). When you cut requirements you can make things small and easy to understand. I'm only concerned about big-O and keeping things simple :) http://github.com/civboot/civlua http://github.com/civboot/civlua

vidarh 3y ago
> About the only heavy thing will be the text editor, and I'm still keeping that at a few thousand lines (+ a small core data structure library). What I found to work really well to trim down my own text-editor was a combination of externalising all menus etc.. E.g. opening files, selecting themes, selecting buffers, all call out to scripts using rofi or similar to do the actual selection, and going client-server so that e.g. I get multiple windows etc. "for free" by just spawning another instance of the frontend which reattaches to the same server. It's still certainly not 500 lines, but small-ish. > When you cut requirements you can make things small and easy to understand. Fully agree with this, and one great way of keeping requirements small like this for me is that I started with the idea that this is my editor. I will only cater to my requirements for the editor itself, but split out shared/reusable functionality in separate libraries so if anyone wants to fork it one day and make their editor we can share much of the code without either of us having to sacrifice. I think too many people insist that everything they build need to be a "product" that they'll let grow to satisfy as many people as possible even when it'd be better to end up with a dozen smaller, more focused tools.
- vitiral 3y ago
  Anything that can be shared or tested individually gets moved to a library, no matter how small. I'll have an 'ed' library for things like the gap buffer and undo/redo aware buffer (built on gap) as well as the movement logic and stuff like that. The "editor" will only handle default bindings, the action/draw/paint cycle and an action event loop. These are core to the specific application so they belong to be coupled to it.
_a_a_a_ 3y ago
You want to write a serious database in 500 lines. Honestly, I'd be impressed but it's a hell of a target. Err, how long are your lines going to be?
- vitiral 3y ago
  Normal lines (max 80) but I do prefer having each line do "one full thought", like putting `if then ... end` on a single line (if it fits) I wrote about the database here https://github.com/civboot/civboot/blob/main/blog/0012-dev-libraries-and-software.md#loam-keyvalue-store https://github.com/civboot/civboot/blob/main/blog/0012-dev-l...
  - _a_a_a_ 3y ago
    Woof. Man, I really don't think you understand what goes into a DB if you think you can do D in 500 or even 5000 lines, unless maybe, maybe, you're aiming for something so simple it's merely a toy.
    - vitiral 3y ago
      It would be considered a toy by most yes
    - vitiral 3y ago
      To be clear, it would depend on some (equally small) libraries, so it's not like 500 lines of no dependency C or something
      - _a_a_a_ 3y ago
        I think what you're suggesting it is possible, to get halfway decent database using components, but I think you need to take a very high level view of these components. For a start, a parser. You almost certainly want a parser generator because that can be reused in other places. You need stuff to handle low level disc writes with logging, again, as a pluggable component (or maybe not, if you plan to shovel everything through your database [to clarify, that your DB effectively becomes the usual end to your filesystem, and everyone uses that, which isn't a terrible idea] in which case it's only got to be written once). You need an optimiser for the queries, even 'simple' ones. For this you might need a prolog-like facility, which again would be useful in other places. [to clarify, a prolog-like component system with some constraint+costs solver component built on top] You'll need a lot more than that as well. You will have to take a very high level view of things, ruthlessly componentised. I understand and endorse what you're trying to do, but a low level infrastructure with a bunch of libraries isn't quite going to cut it. Just my opinion anyway, take it as you will!
beagle3 3y ago
Arthur Whitney had a whole operating system, kOS, in a few hundred lines iirc (including bare metal storage drivers, screen drivers, file system and more), with a more-than-sql database in 200 lines and an editor in a few tens. The magic — other than Arthur’s genius - was the programming language K (also designed and implemented by Arthur). And from another direction, the STEPS project from Alan Kay did a metal-to-everything in 20K lines, including IIRC a paint program and word processor. They only counted lines you need to understand - e.g., it parses the TCP spec RFC to get all the structures and constants; the spec parser is included in the 20K count, but the TCP docs and the generated TCP code is not.
- jpfr 3y ago
  Totally love the quest for elegant and minimal implementations. But I don't think line-counts are comparable across languages. The APL/K crowd has a very different opinion on the number of statements per line. To give an impression of the style, this is the C-implementation of a K interpreter. Have fun deciphering that. https://codeberg.org/ngn/k/src/branch/master/a.c https://codeberg.org/ngn/k/src/branch/master/a.c
- vitiral 3y ago
  Yup, I've seen a lot of those. Cool and inspirational stuff. My favorite so far has been project Oberon. I've not seen how it's assembler works though. What I want is a full stack (assembly included) self-bootsrapping implementation
- kristianp 3y ago
  I was always disappointed that STEPS was something that produced a few research papers, but didn't produce an ongoing open source project that people could try out and innovate on top of. Seems like a waste of funding.
jstanley 3y ago
Re the text editor, when I was writing an editor for my homemade CPU I used the one from this tutorial: https://viewsourcecode.org/snaptoken/kilo/index.html https://viewsourcecode.org/snaptoken/kilo/index.html - it is 1000 lines of C. Might be useful to you. I have diverged a bit from the tutorial because I didn't want syntax highlighting, I really wanted vi-style keybindings, and my environment is much more performance-constrained. Mine is at https://github.com/jes/scamp-cpu/blob/master/sys/kilo.sl https://github.com/jes/scamp-cpu/blob/master/sys/kilo.sl (in my made-up programming language).

vidarh 3y ago

> About the only heavy thing will be the text editor, and I'm still keeping that at a few thousand lines (+ a small core data structure library). What I found to work really well to trim down my own text-editor was a combination of externalising all menus etc.. E.g. opening files, selecting themes, selecting buffers, all call out to scripts using rofi or similar to do the actual selection, and going client-server so that e.g. I get multiple windows etc. "for free" by just spawning another instance of the frontend which reattaches to the same server. It's still certainly not 500 lines, but small-ish. > When you cut requirements you can make things small and easy to understand. Fully agree with this, and one great way of keeping requirements small like this for me is that I started with the idea that this is my editor. I will only cater to my requirements for the editor itself, but split out shared/reusable functionality in separate libraries so if anyone wants to fork it one day and make their editor we can share much of the code without either of us having to sacrifice. I think too many people insist that everything they build need to be a "product" that they'll let grow to satisfy as many people as possible even when it'd be better to end up with a dozen smaller, more focused tools.

vitiral 3y ago
Anything that can be shared or tested individually gets moved to a library, no matter how small. I'll have an 'ed' library for things like the gap buffer and undo/redo aware buffer (built on gap) as well as the movement logic and stuff like that. The "editor" will only handle default bindings, the action/draw/paint cycle and an action event loop. These are core to the specific application so they belong to be coupled to it.

_a_a_a_ 3y ago

You want to write a serious database in 500 lines. Honestly, I'd be impressed but it's a hell of a target. Err, how long are your lines going to be?

vitiral 3y ago
Normal lines (max 80) but I do prefer having each line do "one full thought", like putting `if then ... end` on a single line (if it fits) I wrote about the database here https://github.com/civboot/civboot/blob/main/blog/0012-dev-libraries-and-software.md#loam-keyvalue-store https://github.com/civboot/civboot/blob/main/blog/0012-dev-l...
- _a_a_a_ 3y ago
  Woof. Man, I really don't think you understand what goes into a DB if you think you can do D in 500 or even 5000 lines, unless maybe, maybe, you're aiming for something so simple it's merely a toy.
  - vitiral 3y ago
    It would be considered a toy by most yes
  - vitiral 3y ago
    To be clear, it would depend on some (equally small) libraries, so it's not like 500 lines of no dependency C or something
    - _a_a_a_ 3y ago
      I think what you're suggesting it is possible, to get halfway decent database using components, but I think you need to take a very high level view of these components. For a start, a parser. You almost certainly want a parser generator because that can be reused in other places. You need stuff to handle low level disc writes with logging, again, as a pluggable component (or maybe not, if you plan to shovel everything through your database [to clarify, that your DB effectively becomes the usual end to your filesystem, and everyone uses that, which isn't a terrible idea] in which case it's only got to be written once). You need an optimiser for the queries, even 'simple' ones. For this you might need a prolog-like facility, which again would be useful in other places. [to clarify, a prolog-like component system with some constraint+costs solver component built on top] You'll need a lot more than that as well. You will have to take a very high level view of things, ruthlessly componentised. I understand and endorse what you're trying to do, but a low level infrastructure with a bunch of libraries isn't quite going to cut it. Just my opinion anyway, take it as you will!

beagle3 3y ago

Arthur Whitney had a whole operating system, kOS, in a few hundred lines iirc (including bare metal storage drivers, screen drivers, file system and more), with a more-than-sql database in 200 lines and an editor in a few tens. The magic — other than Arthur’s genius - was the programming language K (also designed and implemented by Arthur). And from another direction, the STEPS project from Alan Kay did a metal-to-everything in 20K lines, including IIRC a paint program and word processor. They only counted lines you need to understand - e.g., it parses the TCP spec RFC to get all the structures and constants; the spec parser is included in the 20K count, but the TCP docs and the generated TCP code is not.

jpfr 3y ago
Totally love the quest for elegant and minimal implementations. But I don't think line-counts are comparable across languages. The APL/K crowd has a very different opinion on the number of statements per line. To give an impression of the style, this is the C-implementation of a K interpreter. Have fun deciphering that. https://codeberg.org/ngn/k/src/branch/master/a.c https://codeberg.org/ngn/k/src/branch/master/a.c
vitiral 3y ago
Yup, I've seen a lot of those. Cool and inspirational stuff. My favorite so far has been project Oberon. I've not seen how it's assembler works though. What I want is a full stack (assembly included) self-bootsrapping implementation
kristianp 3y ago
I was always disappointed that STEPS was something that produced a few research papers, but didn't produce an ongoing open source project that people could try out and innovate on top of. Seems like a waste of funding.

jstanley 3y ago

Re the text editor, when I was writing an editor for my homemade CPU I used the one from this tutorial: https://viewsourcecode.org/snaptoken/kilo/index.html https://viewsourcecode.org/snaptoken/kilo/index.html - it is 1000 lines of C. Might be useful to you. I have diverged a bit from the tutorial because I didn't want syntax highlighting, I really wanted vi-style keybindings, and my environment is much more performance-constrained. Mine is at https://github.com/jes/scamp-cpu/blob/master/sys/kilo.sl https://github.com/jes/scamp-cpu/blob/master/sys/kilo.sl (in my made-up programming language).