a while back we had electron powered terminals that ran on typescript and that .... kinda made sense even if it was extremely heavy. But writing a tui itself in typescript unless its meant to be used as an integrated node package for some complicated setup is beyond stupid.
Dear lord. I never considered the idea of untrained professionals "vibe coding" as a replacement for professionals using it to enhance their work.
"middle management" but construed very, very liberally. If you're following what's going on with institutional fraud in, eg. Minnesota, the reality is that there are a lot of jobs that aren't complete scams like the Quality Learing one, but basically exist because management doesn't want to fire Karen, so she gets some dumb busywork dead-end that isn't management or anything, it's ostensibly useful, but could be replaced "with a very small shell script" by an experienced dev. And when I say "a lot of jobs", it's looking more and more like "most of them".
I don't want to turn this into a full-on politics thread, but that's almost the entire economy. "Service economy", means that we all pretend to work and pretend to get paid when nothing is meaningfully being produced and our dollar is worth less year after year, while finance-bros enrich themselves through speculation. We should, by all means, be in some form of fully automated luxury gay space communism if the world was a logical, well-ordered place, and for the beneficiaries of fraud, it practically is, while the working white taxpayer is financially raped to support quality learing centers across the country.
Functional programming adores having no program state and composing programs from pure functions whose values depend only on their inputs. This results in a problem, because a useable program almost always requires state, and the functions become impure because they need to interact with that state and create side-effects. Further, in the case of an interactive program or a service, the inputs aren't actually known at the time when the main function is run.
Don't dread it, there's going to be a lot of well-paid consulting positions in a few years when all that shit has to be
this is part of why i dislike the functional programming meme.
But that is all that a command line program, stated most simply, is. Bytes go in, bytes come out. Even interactivity can be simplified down to (and, in theoretical scenarios, often is) input at certain points in time. A compiler, for example, "just" takes a program written in a high-level programming language as input and then outputs the corresponding program in a low-level language. In many ways, programming is about specifying how exactly one input should be transformed into another.
The objective of controlling the machine is to make it calculate something in the end, no? To take some numbers in through one end and then spit out some different numbers through another. Functional programming is simply realizing this and trying to be as direct as possible in specifying what you want to do.
the objective usually consists of establishing I/O behavior that interacts with and depends on various external systems (local OS, file system, local io devices, network stuff, some database) which means side effects are a necessity
In a deterministic clockwork universe, we're all just a series of inputs that have already been decided, waiting to punch them in at the nearest teletype.
In my experience, it is much easier to read, write and understand a bunch of pure data transformers with some I/O shims on top than a big state machine where half the state is implicit. At the end of the day, functional programming just forces you to separate concerns you should be separating anyways and exposes a lot of seemingly essential state as inessential caching. You can then deliberately choose which parts you actually want to cache for performance reasons.
There are actually fewer differences between functional and procedural programming than you'd expect. The main difference is that procedural programming involves operating on implicit states. The state of a CPU is very much implicit - only upon actually sending signals to various other devices, as you mentioned, does it reveal its internal state to the user. The idea behind functional programming is to represent that internal state itself as an explicit input so that the program is easier to reason about and prove certain properties about. In fact, this sometimes allows rather performant code to be written (e.g. Erlang, occasionally Haskell) more easily than in a procedural language (C/C++). The difficulty in reading and understanding it mainly stems from being introduced to programming by procedural languages, in my opinion, rather than the functional paradigm itself.
In many cases, this is not actually the purpose of the program - these are incidental ways of gaining input for the core logic of the program (its actual purpose). A program could very well be structured as a core, functional loop that siphons data from several sources and outputs it to several sinks. The other programs connecting the core to the sources and sinks would indeed be procedural but that does not mean the core logic has to be.
that is definitely true. if my first language had been something like haskell instead of BASIC i would probably find functional stuff more intuitive and easier to understand than i do now.
"Reactive" basically just means "uses async in Javascript or equivalent".
Fairly unrelated, but once upon a time I messed around with creating a scripting language that used ternary Kleene-Priest logic for all of its control structures, rather than the binary Boolean logic that we’re used to using. I did this on a whim because I saw that Fortran used to have three-way if statements and something in me just thought that would be really cool.
if x > 5:
then: // Explicit true block
return x - 5
else: // Explicit false block
return x
err: // Explicit unknown block
print("Looks like X isn't a number!")
return unknownerror(“value is not a number!”) in the err block.