#techpost

I like the idea of chasing uptimes, because it sits in stark contrast
to the need to update update update everything all the time.

I updated my kobo and regretted it, because I forgot that updates
aren't always (especially from corp.) for things that help me as the
user.

#techpost

I don't know if zig is it.
The C interop isn't as easy as purported, and that's the basis
for wanting to use it.

Like for me maybe having Tcl drive C code would be better
in almost every area I would use zig.

I should look at hare again maybe.
Last time I looked into hare I wasn't as deep into C
as I am, so my perspective might have changed.

I have a problem with not being happy with a programming language.
But actually in a way this recently has made me a little more
happy in C.

#techpost

I have decided that hardcoding the interpreter path at the top of a script is fine, BECAUSE
it's a convienience to calling the script like:
<script-interpreter> <script-name>
Convieniences are not where you standardize things.

This is about saying I don't like 'env' as a standard to put
at the top of shell scripts

$!/usr/bin/env <script interpreter>

echo "this is bad"

[grenade pin pulled sound]

I'm writing expect scripts like a boss.
As I've waxed poetic before, I think Tcl is a very great programming
language.

It's interesting doing expect, because it's so antithetical to most typical
good programming practices, yet it is sooo new jersey correct.

#techpost

#techpost #C

I really like C and have really leveled up in it.

One of the downsides of C is no namespacing.
But one of my lessons from learning lots of programming languages is
that you can take a good thing from one language and apply it
to another even if it doesn't support it. Typically by adopting
some convention. For example C figuratively does have namespaces
if you are diligent about naming files and functions.

Anyways one of my patterns that I like is that I use a make target like
this:


\#makefile target to copy in lib files
libs:
cp ../libs/log/log.[ch] .

I have a repo of basic C stuff like file handling and binary math
stuff called "libs". I also have one called "learn". The distinction
is that "libs" is stuff I might re-use, where "learn" is stuff
(like pointer math) that is more of a reference.

So I like this pattern of copying in files from another repo.
And then I just add them to whatever repo locally. It's cool because
it lends itself to developing those libs further in either place.
Like I can re-run that make target to get new changes to
those files, and because they are in git locally, I can see what's
changed. And I can copy the files back to "libs" if the changes
are local. This is a compromise, but very good, especially
since I am learning, so I enjoy the development churn.

Like if I update some code in "libs" it might break something
where I am "importing" it, but then I just fix that up and
commit it all. It's like I don't have to remember, to do
something, because the code breaking will notify me :)

#techpost

I want to write a C program that does the double fork unix thing.
I feel like that is something that would make me a better person.
But it's so fiddly :P
And then of course I need to add socket handling to talk to it.
(sockets are also very fiddly :P)

#C

#OpenBSD

#techpost

Lisp predates python with meaningful white space, because the
atom separator syntax is white space.

This is not a serious thought.

#techpost

Choose OpenBSD if you are migrating from windows and thinking about linux.
It is easier and it makes more sense.

This is my deep wisdom. The many choices of linux is not a feature, especially
to new people. And the OS itself is more complicated to use.


People that use linux because it does specific things for them are obviously,
i hope, not the target of this message. The many choices of linux is good
in the sense it is broadly compatible with things.
Like if you are going to trawl thru a bunch of drives to see what you
have and grab data ... linux* is probably the best.
(but you still have to choose one ...)

#techpost #C

This helps me understand C's "extern":
extern is implicit in C's function declarations.