You're right. Postmodernism isn't a relevant philosophical movement since the 80s at best (some would argue it wasn't a movement at all, just a term used by simple minds to join multiple philosophers who rejected meta-narratives but all had very different point of view on everything else). I don't understand why in the past 15 years everyone talk about it. My understanding is that it's often people who never read Lyotard and misunderstood Derrida (I don't have the English word for 'contresense', basically understanding the opposite of what is said. I heard someone say 'you shouldn't criticise art with the standard of the current time' to attack Derrida's ideas lol. Which is fair, because Derrida was a cryptic asshole on purpose, but he did teach in English and his lecture are publicly available, and almost clear.)
Also, the last 'representant' was Baudrillard, and he died in the early 2000s, probably a bit sad that 'Matrix' misrepresented his philosophy so much. Baudrillard never worked on consciousness, but if he did, I think he would be a materialist (an illusionist probably. At least reading his books made me one, and hopefully I didn't misunderstood him).
This paper doesn't look like continental philosophy at all though, so I don't understand why postmodernism comes up.
Bertrand Russell made the great point a very long time ago.
Most of what we think of as “truth” is merely what we agree to among ourselves (my paraphrase.)
Couched in a generation that subtly rejects objectivity of truths in their “investigations of science” there are these meandering conjectures of poor disguise.
You’re impressed. Fine.
The read is like a hypotonic act. First if a then alphabunny. And then yes to zetahumanity, and United Stated for keyword associativity.
Okay folks, like what you like.
I take my ideas seriously, and this is rubbish! I blame the lack of vigorous debate, not the lack of “choices.”
Browsing the repo, I can see a couple of advantages:
- Single contributor. Software bugs are generally caused by developers writing code. By reducing the number of contributors, syq has cleverly reduced the surface area for defects to sneak in.
- Distribution via shell script. rsync is bundled in most linux distributions, which means you have to deal with annoying software updates from time to time. Syq, OTOH, tells you to pipe curl into bash to execute a shell script, which means one-and-done installation and maintenance.
- UI clarity. If you search StackOverflow for rsync, you'll see thousands of questions asking how to accomplish various tasks with rsync, both straightforward and arcane. By contrast, `syq` isn't even a tag on SO. The obvious conclusion here is that rsync's interface is so byzantine, and its documentation so poor, that users must resort to asking strangers for help, a problem obviously not shared by syq.
- No need to be snarky. It's a new project, while rsync is time tested, and that is certainly an advantage for rsync and all old software.
- You can install by piping curl to bash, using brew, or by compiling yourself. One thing about distribution I would argue syq gets right is that you are never relying on whatever version of syq happens to be installed on a server. The client syq always talks to a server syq tagged with the exact same version, and when your local copy of syq installs a remote copy, it verifies that the remote binary is signed by me.
- I never said or implied that rsync has a byzantine interface or poor documentation. I think rsync is well documented and the interface is overall fine. Syq even has an rsync compatibility mode, so you don't have to learn any new syntax if you don't want. Still, I tried to provide good docs for syq too, and honestly even if there were a gap in the docs, all you have to do these days is ask AI to look at the source code and tell you what to do. I think this also mitigates the trust issue with a new project from a single contributor.
FWIW, I'm only half-joking with my comment: dealing with software updates is an annoying part of life, and IMO rsync's UI is rather complicated (in that it's easy to use the wrong set of flags and do the wrong thing, sometimes in annoyingly subtle ways) and I basically always need to refer to the man pages (or, these days, an LLM, followed closely by the man pages to sanity-check what I'm doing) whenever I'm writing a new incantation of it rather than copying from an existing script or my shell history. I just chafe a little bit at declarations like "better than," since that's clearly not true (in the same way that rsync is not unequivocally "better than" syq), when more precise and less conceited descriptors like "faster than" are sitting right there on your benchmarks page.
Yeah, I get that. I really didn't mean to sound conceited, and I don't think that syq is better than rsync for every use case. I was just trying to convey in a very short space that it is something that rsync users might be interested in because it solves some frustrations with rsync.
It just installs in $HOME/.local/bin by default (and some other parts go in other locations inside your home directory). You don't need superuser access for anything. The first time you connect to a server, it installs its matching counterpart in your home directory on the server.
Let's say this is widely used and let's presume that a specific version has a security issue. With everyone having their own copy of the binary on every host versioned at the time they first ran a command on that host, or any decently sized fleet, it'll take a big effort to track down and ensure all versions have been updated or removed (to be re-generated later).
Frankly, we would re-kick our fleet ahead of schedule rather then try to remediate it more manually. But we re-kick our fleet on a rotating yearly schedule, so it's not too much an effort to re-kick it earlier. It's a completely automated system in place now.
I personally like making (and using) TUIs because:
- They encourage developing simpler, information-dense, and keyboard-driven interfaces, which I tend to prefer in general.
- I find them more fun to write, and less aggravating to maintain and debug, than interfaces built with GUI toolkits.
- Most software I write for personal use is going to be run in both a Linux and Mac OS environment (and a lot of the time on a headless server to boot), and a TUI often has less fuss than other options (at least, IME).
- I think monospaced text in a terminal just looks cool.
But you can't really do information dense when you are limited to a fixed grid of monospaced character glyphs.
Variable width fonts are much more information dense for example.
By "information dense," I meant in contrast to what is typical in modern GUIs: generous borders and margins between interface elements, large buttons, etc. My experience both using and writing TUIs is that, because of the extreme limitations of your tools w/r/t styling and layout, more of the screen real estate tends to be devoted to displaying data, and on whole I prefer that.
YMMV, of course, I'm just sharing my own experience and perspective.
I prefer TUIs personally, but I can't see myself use maps, or visual image editing in a TUI for example, but is vi infinitely faster than vscode for manipulating a codebase? Absolutely.
Anything that lends itself to keyboard input, piping, text manipulation and a bunch of other things are so much faster if you're equally proficient in both input modes.
One way to get around this in some cases is to subscribe to the feed's associated email newsletter, which, IME, is more likely to have the full text of the article. This, of course, introduces other problems[1], but if your goal is to remove reasons to habitually look at your phone, it's worth investigating.
[1] The feed needs to have a newsletter in the first place, you probably need to clean up the markdown a bit before shoving it into an epub (I've noticed that table-based layouts are much more common, for instance), and your email provider probably doesn't provide an RSS feed of your inbox. The latter two are straightforward to fix but do require a bit of programming elbow grease.
Based on bot traffic to my personal blog over the past year or so, the minimum viable web crawler apparently does not need any of those things (much to my own personal annoyance, to be very clear).
I think you certainly grasp the gist of things if you understand that the point is self-reference. What makes the proof shocking and beautiful (at least, IMO), is how sparse a toolbox Gödel is working with (and, perhaps, how clever the construction is). Contradictory self-reference in, say, plain English or naïve set theory, is not particularly surprising (at least to our modern eyes), because those are rich languages where you can express an extremely wide range of statements, but Gödel manages to smuggle it in using just whole-number arithmetic and first-order logical statements, which provides a recipe for doing so in essentially any formalized system of interest to "normal" mathematicians.
Some comments elsewhere in this topic mention that you can use the halting problem to arrive at the same essential conclusion in a more understandable way (and certainly one less fraught with small technicalities to work through), but (again, IMO) there's a certain mischievous magic to the way the Gödel sentence gets constructed that makes it very fun to work through for the first time.
Honestly, other than the length and tedious presentation, I don't really think the material in the Principia Mathematica is outside the reach of an advanced undergraduate. As a point of reference, MIT's capstone mathematical logic course[1] has a syllabus that requires at least as much mathematical maturity, and it wouldn't really surprise me that much to see it as an ancillary or excerpted text.
That said, even if the OP was assigned the text at some point as an undergraduate, I remain a bit doubtful it was actually read.
> As a point of reference, MIT's capstone mathematical logic course[1] has a syllabus that requires at least as much mathematical maturity,
The textbooks they use in that course are written in modern notation and are accessible to a knowledgeable reader; neither can be said of the Principia Mathematica. The archaic syntax is a serious issue.
> if it is weakened, how can you prove the same stuff?
Sometimes, you can't. In particular, so-called "non-constructive" proofs don't work in intuitionistic logic. Some mathematicians like to work in intuitionistic logic: for philosophical reasons, pragmatic technical considerations, or just because they think it's interesting.
This is not entirely true: non-constructive proofs can be fully understood within intuitionistic logic as proofs of negative statements, viz. statements about what isn't constructively true or doesn't constructively exist. From this point of view, intuitionistic logic can be seen as stronger and more powerful than classical logic, because it can endow positive statements (particularly statements about logical disjunctions or existentials) with computational content whenever they have a direct proof.
Classical logic doesn't bother with this; positive and negative statements are completely dual to one another, and this duality is elegant in its own way (as people who are committed to classical logic will readily point out), but one needs linear logic in order to combine it with an awareness of constructive statements.
Speaking personally, there are essentially two distinct reasons I like having programmable config languages:
- For personal application config (window manager, shell, text editor, etc), I find I often want to have site-specific configuration, but I also want identical configuration files at every workstation. My laptop probably needs slightly different keybindings than my desktop, my $PATH and text editor needs to be configured a bit differently for work than for personal use, etc. When the configuration is done with a real programming language, this is always straightforward, when it's done via a json/yml/toml file, it's usually a huge pain in the ass.
- You want templating for your configuration, to improve readability, reduce typos and configuration drift, &c, but if you give programmers an inch with any sort of templating system, they will eventually take a mile and figure out how to smuggle Turing-completeness (or, at least, for-loops and variable binding and probably closures) into their configs. If you have a real programming language, this is fine, because the programming language was designed to make loops and conditionals and function calls readable, and probably has decent tooling to boot, but if they're doing it with, say, Mustache-templated YAML, you will have an unreadable mess that is extremely unpleasant to work with.
Something I've personally noticed over the years is that when I take the time to hand to write thoughtful commit messages, the overall quality of my technical work tends to increase as well. My theory is that the process, while boring and time-consuming, forces me to think holistically about how my current task fits within the system and find gaps in my own understanding and implementation. I sympathize with the author's impulse to ignore these tedious details (I, too, love slacking off at work), but, at least for myself, my decades of (admittedly unstructured) A/B testing "how good is the software I write if I don't do this" unambiguously points to it being a somewhat load-bearing piece of my effectiveness as a software developer.
Of course, if you're just optimizing for the amount of slop you can shove into github each week to appease your manager/PM, then yeah just let the chatbot write the commit messages too.
Nor does it make any claims about the nature of intelligence, for that matter.
Did you even read the abstract?
reply