jasperry

By the traditional translation of if/then sentences to classical logic, it is. If you want to go further down the rabbit hole, several things are debatable here: When people use if/then sentences, do they really mean material implication, where (A -> B) is equivalent to (~A OR B)? Also, people often use the word "or" in a sense that's closer to exclusive OR, as opposed to the inclusive OR that the logical operator indicates. Overall, can the meaning of a sentence with imperative intent be fully captured by a proposition that is just meant to indicate a state of affairs?

The proper backlash should be not about its capability level but how it's being used. AI is being adopted to deploy mass surveillance on an unprecedented scale, and to make decisions that affect people's lives without being evaluated by a human first. Those seem worthy of lashing back against.

Retinal detachment is one thing that can cause vision loss as we age. My optometrist says that people like me with a strong nearsighted prescription are especially susceptible to it.

Another is high pressure inside the eye, which can lead to glaucoma. Get your eye exams regularly, folks.

Oh, it's a hybrid Sienna minivian! Now I'm bitter, because I was looking at those for the family a couple years back, but stock was low and they were priced $15k higher than a 3-row gas-guzzling SUV.

Actually, another thing was that the visibility out of the Sienna seemed quite bad.

That's good to know. Can you point to an example?

Excited to see another project targeting the QBE back end, from what I can tell it's a great lightweight alternative to LLVM.

This is super useful, thanks. So if I were implementing a programming language, and wanted to have symbols to specify NaN in source code, I'd really only need quiet NaN, right? Because signaling NaN is supposed to always to raise an exception anyway?

Looking at the Wikipedia article, it seems naproxen is a NSAID like ibuprofen and can cause all the same gastrointestinal issues.

This is some of the most useful information I've received in a while. Like the author, the low overdose threshold of acetaminophen made me avoid it, even though I always take low doses anyway and ibuprofen gives me acid reflux almost every time.

Does anybody know whether Fortran is older or younger than Algol? From Wikipedia, it looks like they were both developed around 1957. Was there any overlap in the design?

I don't know of any algorithm to cull non-winnable Klondike games. Playing deal-1 instead of deal-3, and with unlimited flipping of the stock, the win chance is probably close to 50%, but that still makes 2000 in a row statistically impossible.

My guess is that the poster's mom was actually playing FreeCell, in which nearly every game is winnable and people do get streaks like that.

Even though I hadn't thought about xv in decades, as soon as I read the headline, the image of those 3d buttons with the crisp outlines resurfaced from my memory.

Those are functional languages that generally don't use statements, so it makes sense to leave them out of a discussion about statement separators. If you think more people should use functional languages and so avoid the semicolon problem altogether, you could argue that.

Indeed it does, by showing how many different and confusing types of parsing rules are used in languages that don't have statement terminators. Needing a parser clever enough to interpret essentially a 2-d code format seems like unnecessary complexity to me, because at its core a programming language is supposed to be a formal, unambiguous notation. Not that I'm against readability; I think having an unambiguous terminating mark makes it easier for humans to read as well. If you want to make a compiler smart enough to help by reading the indentation, that's fine, but don't require it as part of the notation.

Non-statement-based (functional) languages can be excepted, but I still think those are harder to read than statement-based languages.

It turns out Palpatine returned!

I've looked into TextAdept a few times. It appeals to me because it's got a standard Qt UI, is fast and lightweight and highly customizable with Lua. But I could never commit the time to fully customize it for daily use. Anyway, I'm committed to emacs. Other Scintilla-based editors with a similar feel (but missing the Lua angle) are Geany and Kate.

I was satisfied with Tuareg + Merlin for OCaml development in Emacs, it just worked for me and didn't break when I upgraded packages, but yes, this being from bbatsov is a strong incentive to try it out. My only concern is that it uses tree-sitter, which I try to avoid because of the messiness of the JavaScript ecosystem.

You're right that being a scientist is unlikely to result in personal wealth and so that's not the primary drive for those who seek faculty or research positions. However, it's not just curiosity, prestige and vanity either, because a big factor for promotion and tenure is how much grant money you bring in. That money is what keeps the university's lights on and buys the lab equipment and pays the grad students, so it's still money as a primary driver in the background.

If you rotate it so the board looks like the traditional solitaire layout, the direction of free tiles is horizontal as it's supposed to be. But then the images on the tiles are rotated 90 degrees. Either way you look at it, something is non-standard.

The other thing is that this implementation doesn't seem to support overlapping tiles, which is kind of important. For instance, the topmost tile should overlap and block all four tiles under it.

The author is definitely claiming that it's not just about naming conventions: "These different perspectives ultimately amount, I argue, to mathematically inequivalent structural conceptions of the complex numbers". So you would need to argue against the substance of the article to have a basis for asserting that it is just about naming conventions.

I agree in principle, but does anyone else feel super awkward saying "mebibyte" and "gibibyte"?

I see, thanks for the clear example of the ambiguity you need to avoid! Fun stuff.

Syntax comment: in your control structures you use a keyword ("do", "then") to start a block as well as wrapping the block in parentheses. This feels superfluous. I suggest sticking with either keywords or parens to delineate blocks, not both.

Codeberg supports Org for READMEs! I think some other Git forge does too, but the name escapes me ;)

The value of Org outside Emacs would be the same value that Markdown has, if it had wider adoption. Voit's post makes a strong argument for Org syntax's ability to serve for all the things Markdown currently does, while being more consistent and concise than Markdown, and so he pushes for it to be more widely adopted. We know that in tech, the better format doesn't always win at first, or ever, but we can advocate!

I was also impressed and read the whole thing and got a lot of gaps filled in my history-of-the-web knowledge. And I also agree that the uncritical optimism is the weak point; the article seems put together like a just-so story about how things are bound to keep getting more and more wonderful.

But I don't agree that the system is bound to collapse. Rather, as I read the article, I got this mental image of the web of networked software+hardware as some kind of giant, evolving, self-modifying organism, and the creepy thing isn't the possibility of collapse, but that, as humans play with their individual lego bricks and exercise their limited abilities to coordinate, through this evolutionary process a very big "something" is taking shape that isn't a product of conscious human intention. It's not just about the potential for individual superhuman AIs, but about what emerges from the whole ball of mud as people work to make it more structured and interconnected.

The unity of the block of cheese is circumstantial, but nonetheless we define a piece of cheese defined on the presence of actual matter. The article goes to some trouble to devise a definition of holes that's also based on matter rather than its absence. But only a strict materialist would feel the need to do that, assuming they didn't want to outright deny existence to holes.

I think your definition still leaves the essence of the discussion in the same place: do topological properties "exist"? That's how I tend to blanket-interpret this debate; it's whether one is wiling to define existence to include things that aren't material.

Holes might not really exist, but hollers definitely do, because that's where my papaw lived.

As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config.

Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?