more work on clirenaissance.

content/posts/clirenaissance/index.md

@@ -17,6 +17,7 @@ sed,,1974,c
 bc,,1975,c
 make,,1976,c
 vi,,1976,c
+TeX,,1978,pascal
 bourne shell,,1979,c
 awk,,1985,c
 screen,,1987,c
@@ -26,7 +27,7 @@ vim,https://www.vim.org/,1991,c
 midnight commander,,1994,c
 ssh,,1995,c
 curl,https://github.com/curl/curl,1996,c
-fish,https://fishshell.com/,2005,c (currently being rewritten in rust)
+fish,https://fishshell.com/,2005,c++ (currently being rewritten in rust)
 fossil,https://fossil-scm.org/home/doc/trunk/www/index.wiki,2006,c
 tmux,https://github.com/tmux/tmux,2007,c
 git,https://git-scm.com/,2008,c
@@ -221,21 +222,26 @@ but its an extremely usable IDE out of the box thanks to having all of its featu
 Where possible, documentation should not even be required for the most common use cases.
 Whenever I want to use `find`, I almost always have to first look at the man page,
 as I dont use it quite often enough to memorize it.
-But thats totally unnedded! 90% of my uses of `find` take the form of `find ./ -name "*foo*"`.
+But thats totally unneeded! 90% of my uses of `find` take the form of `find ./ -name "*foo*"`.
-with [fd](https://github.com/sharkdp/fd), the exact same invocation is a simple `fd foo`, dead simple, no man page needed.
+With [fd](https://github.com/sharkdp/fd), the exact same invocation is a simple `fd foo`, dead simple, no man page needed.
 Of course, 10% of the time im doing something else and have to look at the manual even with fd,
-but the point is that manuals are for when you want to do someing with the tool that is not the most common usecase.
+but the point is that manuals are for when you want to do something with the tool that is not the most common usecase.
 
 There are many other examples as well. How many of your grep invocations are in the form of `grep -R 'foo' ./`?
-most of mine are. [Ripgrep](https://github.com/BurntSushi/ripgrep) shortens that to `rg foo`
+Most of mine are. [Ripgrep](https://github.com/BurntSushi/ripgrep) shortens that to `rg foo`
 while still having all the power of grep when I need it, and it is faster to boot!
 
 This isnt to say that tools should 'dumb themselves down' or hobble themselves to make them easier to use.
-Tools abosultuely should not shy away from being powerful; however they should keep in mind the first time user experience
+However they should keep in mind the most common usecase that their tool is likely to be used in,
-and what the first time user is likely to want to use the tool for; as that is likely also what power users will want to use the tool for 90% of the time.
+and streamline that usecase.
 
 ## Shedding historical baggage
 
+Many tools were made for one thing, and over time have evolved into another thing entirely.
+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 new usecase eclipses
 <!-- look at just command runner, simplifying the common use case of make-->
 
 ## The trendsetter
@@ -269,6 +275,7 @@ available, wikipedia otherwise, and sorting is by year first, then alphabetical.
 |bc|1975|c|
 |make|1976|c|
 |vi|1976|c|
+|TeX|1978|pascal|
 |bourne shell|1979|c|
 |awk|1985|c|
 |screen|1987|c|
@@ -278,7 +285,7 @@ available, wikipedia otherwise, and sorting is by year first, then alphabetical.
 |midnight commander|1994|c|
 |ssh|1995|c|
 |[curl](https://github.com/curl/curl)|1996|c|
-|[fish](https://fishshell.com/)|2005|c (currently being rewritten in rust)|
+|[fish](https://fishshell.com/)|2005|c++ (currently being rewritten in rust)|
 |[fossil](https://fossil-scm.org/home/doc/trunk/www/index.wiki)|2006|c|
 |[tmux](https://github.com/tmux/tmux)|2007|c|
 |[git](https://git-scm.com/)|2008|c|