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.
I think it's pretty obvious, tbh. Traditional roguelikes are turn-based, take place on a square grid, are good vehicles for exploring focused mechanical ideas, and can be fun without much in the way of story or graphic design. All of those features mesh well with the rules of chess, which itself is probably the most widely played game in the world.
It's in fact the opposite: an intentional design choice to make save scumming (edit: and by extension, sharing specific rng seeds) more effective for people who like doing it. They made a similar design choice with how save/restore works, in that it resets the current encounter, which allows players a limited ability to undo/backtrack if they make a mistake.
Can you describe what you mean by "oracle attack" here? CSPRNG APIs (at least the ones I've used) usually expose ways to set a specific seed and serialize the RNG state. In fact, arguably the simplest possible CSPRNG, where you just run a (suitably strong) block cipher in counter mode, would seem to meet the requirements for game dev in a straightforward manner.
> ArXiv doesn't even check the submission closely, so how can they know?
They can be informed by people who read the papers and check the citations. A zero-tolerance policy provides an incentive to report sloppy papers (namely, that you can be confident something will be done about it), and each time a paper is removed or an author is banned, it incrementally increases the value of the arXiv as a whole.
> Being required to publish in a peer reviewed journal will close off arxiv for many researchers for good.
At the end of the day, demanding that people carefully proofread their LLM-generated papers before sharing them on the arXiv seems like a relative low bar to clear, and I sort of question whether it's reasonable to call individuals who find it too onerous "researchers" in the first place.
I think it's possible to be simultaneously: gracious and supportive towards the developers and ops staff who have been struggling to maintain reasonable uptime on the extremely important piece of shared internet infrastructure that everyone commenting probably relies on (either directly or indirectly) on a daily basis; and spiteful and cruel towards the massive (and, historically speaking, ethically fraught) corporation whose cynical acquisition and subsequent mismanagement of that same resource got us here in the first place.
It might surprise you to learn that a large number of software exploits are written without the attacker having direct access to the program's source code. In fact, shocking as it may seem today, huge numbers of computers running the Windows operating system and Internet Explorer were compromised without the attackers ever having access to the source code of either.
They didn't say you "might" be able to use it under the AGPL, but that you "may" be licensed to use it. Which, as a native speaker of American English, seems to be relatively clear in its meaning along the lines of what the GP poster stated. Of course, the various meanings of "may" in English might be subtle enough that I'd readily believe it's less clear to non-native speakers (or maybe even speakers of a different dialect), and it's unfortunate that Mattermost's lawyers aren't interesting in cleaning up the language.
In Haskell specifically, arrays really do allow for the more general definition. This makes the library documentation[1] quite a bit more intimidating to newcomers (speaking from personal experience), but saves you the boilerplate and hassle of figuring out the mapping yourself if you're indexing your array by some weird nonsense like `[(False, 'a', 5000, 0)..(True, 'z', 9001, 4)] :: (Bool, Char, Integer, Int8)`.
I remember having a similar sort of realization early in my career when trying to implement some horribly convoluted business logic in SQL (I no longer remember the actual details of what I was trying to do, just the epiphany which resulted; I think it had something to do with proration of insurance premiums and commissions): I realized that if I simply pre-computed the value of the function in question and shoved it into a table (requiring "only" a couple million rows or so), then I could use a join in place of function application, and be done with it. An obvious idea in retrospect, but the sudden dredging of the set-theoretic formulation of functions--that they are simply collections of tuples--from deep within my memory was certainly startling at the time.
It seems appropriate that, for a website whose purpose is to make links which raise your suspicions, the visual design itself also raises your suspicions.
That's a pretty lazy analysis. As an easy counterpoint, no one pays to look at Facebook or Instagram posts, but both Meta and (at least some) individual influencers are able to run profitable businesses based on that media consumption (and you could say the same of some bloggers in the late 00s/early 10s, for that matter). More speculatively, I think there is also an argument to be made that even gratis media consumption gives cultural weight to a work which is then available for monetization, especially in this age of tentpole franchises and granularly tracked personal behavior.
- 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.