Browse Source

Added tech file

master
dirkson 5 months ago
parent
commit
22a5dae5d5
1 changed files with 140 additions and 0 deletions
  1. +140
    -0
      src/tech.md

+ 140
- 0
src/tech.md View File

@@ -0,0 +1,140 @@
## Technology choices

---

### Source access

* Closed advangages:
* Open advantages:
* Technical users can locate and fix security issues, bugs, etc. Many of these users will gift these changes back to you.
* The above leads to more secure, less buggy code.
* Technical users can modify the code to better suit their needs. Many of these users will gift these changes back to you.

* Closed disadvantages:
* No open source benefits
* Open disadvantages:
* Your software might be copied and sold by others on the dark web, I guess?
* There aren't many commonly used licenses that can be used to pragmatically sell the licensed software.
* Some libraries with common open source licenses are difficult or impossible to use in closed-source and/or commercial software.

There are no advantages or disadvantages as far as copyright is concerned - Both open and closed source software are equally protected by copyright.

Yeah, open source is obviously correct for all individuals and businesses.

### Structure

* Monolithic
* Examples: System D, windows, zig, osx, linux kernel, meson.
* Large, all, in one projects with few replaceable parts
* Makes writing code for the system easier, because people can assume the existance of things.
* Composable
* Examples: Most linux distros as a whole, most GNU tools, runit, tup, make.
* Small tools focused on doing one thing. Chain together multiple of them to accomplish more complicated goals.
* Requires more technical knowledge to operate.
* Much more flexible.
* Code is frequently written to meet a published standard, allowing others to design more optimal tools as well.
* Code that does less is much easier to design, test, and verify.
* Sometimes performance restraints do not allow composability - Not everything conforms to tight little units.

Composable is absolutely the way to go, if you can come up with a good design to accomplish it.

---

### Progamming language

A good programming language is:

* Flexible enough to do your jobs
* Most languages do this perfectly well. The obvious counterexamples are domain specific languages, scripting, etc.
* Easy to reason in
* This one is highly subjective. People will have different preferences for functional languages, imperitive, recursive, etc.
* I find it much, much easier to reason imperitively, and can do recursion for some problems, but functional is right out.
* Has a wide choice of existing libraries
* Code that you don't have to write is better than code you do. Access to existing libraries is a massive bonus.
* Easy to make predections about
* Garbage collected languages almost entirely fall down here. It's just too difficult for a human to make performance predictions when the garbage collector is wandering about constantly.
* That said, modern computers in general are massivly too complicated for a human to make performance predictions. This is not currently avoidable, while garbage collection is.
* Large and/or new languages also tend to fail hard here. Rust, for example, has many strange corner cases that come up rather quickly in actual use.
* Easy to read and comprehend existing code
* This is useful for both reading others' code and for the maintainability (By you and others) of your own code.
* Implicit typing schemes tend to have issues here. When reading code, it becomes incredibly difficult to figure out what exactly is being referenced. That said, good tooling in your text editor can absolutely fix this.
* Does not introduce overhead in the...
* CPU. Your users' time is as valuable as yours. If there are 3600 of them, removing a 1 second slowdown is worth an hour of your time.
* RAM. Why use resources if they don't help?
* Programmer. Don't make more work for yourself if you aren't forced to. All other things being equal, prefer a language that lets you do more with less.

So for my purposes, I want a general purpose, imperitive language that's not garbage collected. What options does that leave?

* C
* "Small" language, nevertheless with a bunch of hidden corners and weird gotchas. Most, but not all, are labeled as such.
* Massive number of available libraries.
* Extremely composable - Every bit of the compilation toolchain is replaceable.
* C++
* Very comparable to C, but substantially more complicated.
* That complexity makes it harder to predict than C, and can introduce CPU/RAM overhead. It does generally benefit programmer overhead, though.
* Includes all of C's libaries, as well as a substantial amount more.
* Extremely composable - Every bit of the compilation toolchain is replaceable.
* Rust
* Large, high-complexity language. Lots of unpredictable corner cases.
* Includes all of C's libraries
* Somewhat composable - While Rust does interate a package management system, and has its own build system, usage of there is not mandatory
* Rather new - Just barely past 1.0, Rust is still releasing breaking changes. Code bitrots fast enough without help.
* Theoretically extremely predictable, removing entire classes of common programming bugs without introducing massive run-time overhead
* Zig
* Extremely monolithic - Build system, package management, even the indentation scheme is mandated by the only compiler in existence.
* Includes all of C's libraries
* Extremely new language - Not even 1.0.



### Make

* Make
* Complicated and unintutive build script logic
* Quite fast
* Sometimes creates phantom issues due to unclean builds. These are fixable, but take time and effort to unpack.
* Mandates understanding the build chain, which improves your ability to reason about build issue.
* Users on highly nonstandard system may need to manually change compilation binary names
* The standard - Your users know what to do.
* Meson
* Very, very easy to specify a project in.
* Written in python, and it shows in slow build startup speeds.
* Hides what's actually happening, making some issues incredibly challenging to debug
* Your users have never heard of it.
* Actually has a rudamentary package management system
* Creates a lot of weird directories
* Tup
* Builds are nearly always correct. Much less time wasted finding phantom issues.
* Builds are obscenely fast. Nothing gets built that isn't required.
* Mandates understanding the build chain, which improves your ability to reason about build issue.
* Users on highly nonstandard system may need to manually change compilation binary names
* Build script syntax is very unintuitive, although the logic is excellent
* There's no way to tell it to clean, on the rare occasions it does mess up, so you need to manually remove its cache directory
* Your users have never heard of it.
* Not well documented
* Cmake
* Complicated and unintutive build script logic
* Not particularly fast
* Hides what's actually happening, making some issues incredibly challenging to debug
* Your users have heard of it and sort of know what to do sometimes
* Who thought this was a good idea?
* Autotools
* Layer on top of make
* Automatically finds compilation binary names
* An additonal layer of complicated and unintutive build script logic
* The standard - Your users know what to do.
* Who thought this was a good idea?
* Scons
* Python, so slow
* Your users have never heard of it.
* Waf
* Python, so slow
* Your users have never heard of it.
* I dunno so many others


There really aren't any truly great options here. I like understanding the build chain and fast, correct builds, so I use Tup. But it's got its own issues.

### Keyboard layout

Use qwerty. I'm not. It wasn't a good decision, and even six months in I'm still slower. 6ut now that I've invested the effort, my qwerty is so rusty that there's not a good reason to switch back.

Loading…
Cancel
Save