In my experience, what computer scientists (in particular programming language researchers) consider to be "category theory" is very different from what mathematicians (in particular those working in algebraic geometry, algebraic topology, homological/homotopical algebra, ...) consider to be the important parts of category theory.
In my very biased and unfair perspective, the "computer science perspective" on category theory is rather applying the first 50 introductory pages of a decent textbook about category theory, while for mathematicians, where category theory actually starts to become somewhat interesting is only, say, from page 150 on, when also a lot of additional mathematical concepts that actually motivate (or even necessitate) these much more complicated category theory topics have additionally become introduced.
Category theory is an API for mathematics that was developed with specific applications in mind that the API seeks to unify and make easier to think about. Those application domains are algebraic geometry, algebraic topology, homological/homotopical algebra.
Every API comes with trade-offs: typically an API makes one domain easier, at the cost of making other domains harder. Example: CSS is Turing complete.
And I think CSS is really good at helping with styling webpages. But I would not want to write a compiler is CSS.
Computer scientists, like myself, who read from Page 150
onwards have just found the API stylised for
algebraic geometry, algebraic topology, homological/homotopical
algebra, ... not that useful, for applications in computer science. Unlike the first 50 pages, which have been very useful. More specifically, we found the cost of using purely categorical APIs not worth the benefits in many application domains. Maybe we are missing something, maybe we overlooked something. But, given the investments since the 1990s of computer science into category theory, I'd like to see more evidence for!
To conclude with a concrete example: why would I write a compiler using an API for homotopical algebra?
Why are asking for a password? Which password? For what service? Can I get the prompt for it somehow? Can I echo something to?
I've had this happen in the past with mysqld, and I had to resort to running /usr/sbin/mysqld from the CLI manually to get any kind of error or logging messages.
systemd fighting against other daemons without any warnings and error messages is my absolute favorite.
Not being able to list which components are enabled and not being able to format output of "list-units" for easy machine readability are close seconds.
I mean, if OpenStack guys has figured this out, self-proclaimed demigods of Linux can do that, amirite?
While it's noted that it's undocumented behavior (-o is non-existent in systemctl man page), so it might go away tomorrow, it's not a bad start. However what I want is more like
I can add --terse for single line output to prevent adding jq to the pipe for processing that JSON.
Maybe instead of writing a bit better code and actually documenting these options, they can just absorb jq as jsonctl, who knows.
Sorry, I kinda get angry when I encounter shenanigans like undocumented functionality, or hostile-replacing a daemon because they felt like replacing something really working well for the last 20ish years, just for fun, you know.
Okay but make is a shitty build system. What it does have going for it is you can nearly universally expect it to be already installed or easy to install. That makes it a good way to name commands shorter in a portable way, with some dependencies maybe thrown in.
It’s used for the same reason we write shell scripts
> It’s used for the same reason we write shell scripts
Only worse since it also uses $ for its variables leading to "thing:\n\t env FRED=$$HOME/thing some-command -p $$AWS_PROFILE $(OTHER_THING) -d $$(date +%s)" level of squinting
So for those using it as a task runner from the 60s, without dependency tracking, now it's just laziness over a shell script that has "dependencies" in an imperative and shellcheck-able way
presumably the goal is to have the smoothest and most consistant combustion, and therefore less vibration, and known ,predictable resonant frequencys in the system.
Which makes very small increments of time important.These rockets are consuming ? tons/sec of fuel, and then its a question of how "small" of an inconsistancy will break things.
A simple but true engineering pricipal, is that any noise, is proof of ineficiency, and therefor a full examination of the audio frequency , coupled with video of the flame.Other data that might be nice would be to know exactly what is happening inside the turbo pumps,and fuel lines.
The whole thing is so violent, that resonant phenominon not seen anywhere else, could be doing very weird things inside tanks and lines. And sensors for that, especialy video, could be challenging to engineer.
Here is a wierd fact about a high pressure diesel fuel line: the pressure pulse (-+ 10000psi) causes
a travelling expansion in the fuel line, that then causes a magnetic pulse, which can be detected, but you want to be quick about it, eh!
I’m not really sure what you’re saying. Do you mean you achieve the gaurantees of CRDTs without using CRDTs? What technology are you implicitly referring to?
Whenever I hear someone say “sync” data, I instantly get scared. Consensus is fraught with peril and very very very difficult to implement correctly.
Okay I’m with you, but if I’m not mistaken I believe you have slightly mis-characterized what strong eventual consistency is.
> Strong eventual consistency: Exactly the same, but replace "eventually" with "immediately".
I believe this isn’t quite correct. I was under the impression that the delivery doesn’t have to be immediate, but rather that any two nodes with the same set of events, regardless of received order, must be in the same state.
I'm taking my definitions from section 2.2 here. I feel like I've summarised it fairly accurately, but if I've made a mistake would be happy to be corrected.
Incredibly hard to make work in practice because of the semantic muddiness that results from having events about events etc. You have to think about the domain and its first derivative
reply