You have a weirdly restrictive definition of "tinker"

maccard 29 minutes ago | parent | next [-]

Almost all of my tinkering is “download this thing, cache it (because it’s huge), run a program or a series of programs on it, and package the output up somewhere.” When I’m writing the thing that does the work I’m not tinkering any more..

▲

ACCount37 an hour ago | parent | prev [-]

Not really?

I've been places, from embedded bare metal to ML AI, and that "embedded bare metal" end is the one place I don't use Python directly in. Embedded bare metal is just ruled by C forever.

Bit of a shame, because C is kind of bad at its job, but nothing else has the "compatible with everything" badge of honor.

The tooling around embedded devices though? Python.

▲

cornstalks 33 minutes ago | parent [-]

When I want to tinker it’s usually because I want to make something faster than anyone else has done. Does that help illustrate why some might prefer to tinker in Zig, and why your definition of tinker seems a little narrow?

	▲	ACCount37 a minute ago \| parent [-]
		Most of the time "make something faster than anyone else has done" is just not worth doing? Good enough is good enough. Unless it's some super hot path and it's the speed that's the main goal, nothing else. Which is rarely the case. If you only ever think of tinkering for the purpose of execution speed ninjutsu, isn't it your definition of tinkering that's far too narrow?