Compare commits

..

No commits in common. "e3d9e2dd987d1ccbe854ed5352f096e3495e2597" and "b1b041a792ea101999564f9049d4ca7933fc5a07" have entirely different histories.

2 changed files with 11 additions and 26 deletions

View file

@ -241,28 +241,8 @@ Many tools were made for one thing, and over time have evolved into another thin
This can happen by conscious design or, more commonly,
from an industry or community picking a tool up and using it for something it was not originally designed for.
While hacking tools for uses they were not designed for is always fun and in many cases the only way to do something,
its perhaps better to make a dedicated tool when the design choices made for the old usecases start hindering the new usecases.
A great example of this is [just](https://github.com/casey/just), a command runner heavily inspired by GNU make.
Make was (and in large part still is) a C build system.
As such, it includes features such as implicit rules
(if a file called `foo.o` is needed and there is no explicit rule is there, the C compiler will be invoked on the file `foo.c`
(there are similar rules for C++ and linking))
and file modification time laziness
(fantastic as a build system, needs liberal sprinkling of `.PHONY` rules when used as a task runner).
These features are *good* features when make is being used as a build system,
but another major use of make that has emerged has been as a way to run common tasks.
so alongside `make build` to buld your program, you would have `make bootstrap`, `make test`, `make config`, etc.
This is where the design decisions behind make the build system start to hinder make the task runner,
making one learn about make the build system in order to work around those features to use make the task runner.
However, make cant drop these features, both because projects still actively use make as a build system,
and because even makefiles that are just used as taskrunners still work around the footguns and
would be broken by make making large changes to its syntax and semantics.
However, Just was designed from the outset to be a command runner, and as a result,
it is much easier to pick up the just language and make a quick set of commands that can be run.
By leaving behind the old tool, a new tool can be made that better fits the tasks that people use the tool for.
its perhaps better to make a dedicated tool when the new usecase eclipses
<!-- look at just command runner, simplifying the common use case of make-->
## The trendsetter
@ -276,10 +256,10 @@ By leaving behind the old tool, a new tool can be made that better fits the task
## Appendix: the tools
This is an extremely unscientific table of command line tools that I have tried, have used, or currently use.
It is assuredly incomplete, but *should* be broadly representative.
The date data has been gathered from the first git commit where available,
wikipedia otherwise, and sorting is by year first, then alphabetical.
This is an extremely unscientific table of command line tools that I have tried,
have used, or currently use. It is assuredly incomplete, but *should* be broadly
representative. The date data has been gathered from the first git commit where
available, wikipedia otherwise, and sorting is by year first, then alphabetical.
|tool|year|language|
|-|-|-|

5
content/posts/gitea.md Normal file
View file

@ -0,0 +1,5 @@
+++
title = "Gitea"
date = 2022-02-10T01:33:49-05:00
draft = true
+++