HN user
In fact, that's how Lua itself came to be. They started with a simple configuration language and added more and more features until at some point they decided to rip the bandaid and turn it into a proper programming language.
Just this past week, I have had to answer two surveys, from different sources, asking how I use AI in my work. Both had a "choose all that apply" checkbox, and, funnily enough, neither allowed me to select zero options. "This question is mandatory". :)
In math, the utility lies in the proof itself. A novel proof of a hard problem usually comes with new insights and abstractions that help solve even more mathematical problems.
To go with your analogy, mathematicians care more about the source code of the program than about the result of the program. But I'm afraid that we will see things change with the increase of vibecoded proof slop. A black box proof is not as useful, even if it is correct.
The part in the beginning about Galois Connections is very worth learning. It has countless applications.
European banks offer the credit, but the payments infrastructure currently goes through US companies. The first step is to get those payment processors out of the picture.
In Brazil, which is further along in the transition to digital cash, PIX already supersedes debit cards. Some banks already offer deferred PIX payments, wherein the merchant receives the money right away and the buyer pays their bank later, with interest. The central bank is also developing a "pix with guarantee", which will compete with credit cards: payment would be agreed to be settled at a later date, with the bank guaranteeing that the merchant will receive the money.
Wouldn't help much.
* Some kind of scans, like CT scans, use ionizing radiation and should not be done too often. * Looking at only imaging scans it is often impossible to tell apart a cancer and a benign growth. (More invasive tests would still be required, which was what the parent posters were warning about)
One important kind of seeded run are the daily challenges, where everyone gets the same seed once a day (like Wordle)
They want two players with the same seed to have a similar gameplay experience in terms of challenges encountered.
For this reason they want to isolate the RNG that procedurally generates maps, card rewards, shop contents, from other RNG streams such as the RNG used by random enemy attacks in battles, random event outcomes, etc.
One example of the wonky things that are possible when there is a single RNG stream is speedrunners manipulate the RNG state. For example, in Super Mario 64 they can jump in place to produce dust clouds that advance the RNG state until it is in a favorable position.
In the post, the ladybird maintainers say that they trust pull requests less than they used to, because many pull requests are authored by AI now. A big pull request no longer signals that the submitter put in a lot of work into it and it's committed to developing and maintaining quality code.
The article has a section covering this. According to them, finding Haskell talent is not difficult, the bigger problem is onboarding them into the company coding style because Haskell developers come with strong opinions.
As you said, it's more like CPU stack frames. In a register VM all instructions can read and write to any position in the stack frame. In a stack VM, most instructions only read and write to the top but they are often combined with LOAD and STORE instructions, which can read and write to any position in the stack frame.
The author seems to complain about a lack of stack manip expressions like dup and rot, but at least for me that's what I would expect from an average programming language stack machine. Even Java, which does have those instructions, doesn't use them --- reuse happens via local variables.
The way I see it, the difference between register and stack vms is all about the instruction encoding. Register VMs have fatter instructions in exchange for needing fewer LOAD and STORE operations. Despite the name, register VMs also have a stack.
We do run the linter on CI as well, but I think our comitters would get faster feedback if they ran those checks locally.
I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?
It can also happen if the person has some disease that affects the liver, which in turns lowers how much of the drug they can take.
That EWD is one if my pet peeves. Dijkstra makes an unfair comparison because he lists plenty of examples where 0-based indexing is more convenient but ignores the equally numerous situations where 1-based is more convenient. For example, iterating backwards over an array is much better in an 1-based world.
I like the argument that 1-based is better for indexing and 0-based is better for offsets: https://hisham.hm/2021/01/18/again-on-0-based-vs-1-based-ind...
There's a little bit of far side on the right of the picture.
Tail call optimization optimizes the situations where the recursion doesn't actually need any stack space, but I think the parent poster is asking about situations that aren't tail recirsive.
It's indeed very mechanical and some programming languages can do it for you.
I think you're mainly asking for heap-allocated stacks. Some languages always use the heap for stack frames instead of the native stack and can set the stack limit as high as there's memory available.
You might also want to look into stackful coroutines, which allow one to pause the execution of a recursive function and switch to another function. This can provide you with multiple call stacks, which is another reason people sometimes choose to use write explicit stacks.
Even if soaked, beans still take hours to cook without a pressure cooker.
Few students do optional assignments unfortunately. Other tasks that are directly worth a gradetend to take priority (e.g. studying for another class that has an exam this week).
Students are also people. If we're managing a software project, a single deadline at the end is sure to suffer from delays. It's better to split things into shorter deliverables with more frequent feedback.
Students are very grade-motivated and unfortunately they rarely do the homework assignments if they are not worth points.
At-home coding projects, writing essays, etc also exercise different skiils than you can test for in a 2 hour written exam. It's unfortunate that due to rampant AI cheating, we can no longer reward the students who put in the work and develop these skills.
J.K. Rowling is now infamous for using her vast wealth to lobby against transgender rights.
A microwave lifehack I recently learned:
If you're gonna brown some onions, microwave them for a bit before tossing them into the pan. The first step of browning onions is just boiling away the water, which microwaves are great at. You may find that it begins to brown sooner this way.
Indeed. The point I was trying to make is that an ad-hoc type inference scheme that works by recursively traversing the tree will probably be most similar to unidirectional or bidirectional type inference.
If your language is typed it's good to know at least a bit, so you can do the type inference properly; there are many ways to shoot yourself in the foot when it's ad-hoc.
Bidirectional type inference is a type inference style where you traverse the syntax tree once. Sometimes the type info flows top to bottom and sometimes it flows bottom up. If your type inference algorithm works by traversing the syntax tree, I suggest reading more about bidirectional type inference to get a better idea of how to best coreograph when the type info goes up and when it goes down.
Hindley-Milner type inference works by solving constraints. First you go through the code and figure out all the type constraints (e.g. a function call f(x) introduces the constraint that x must have the same type as the argument of f). Then you solve the system of equations, as if you'd solve a sudoku puzzle. This sort of "global type inference" can sometimes figure out the types even if you don't have any type annotations at all. The catch is that some type system features introduce constraints that are hard to solve. For example, in object oriented languages the constraints are inequalities (instanceof) instead of equalities. If you plan to go this route it's worth learning how to make the algorithm efficient and which type system features would be difficult to infer.
Considering that the primary source is South Korea's spy agency, I think it's worth taking this news with a grain of salt. When north and south korea release news about each other it is always hard to tell which parts are factual and which parts are propaganda.
Related to shadow stacks, I've had trouble convincing the C optimizer that no one else is aliasing my heap-allocated helper stacks. Supposedly there ought to be a way to tell it using restrict annotations, but those are quite fiddly: only work for function parameters, and can be dusmissed for many reasons. Does anyone know of a compiler that successfully used restrict pointers in their generated code? I'd love to be pointed towards something that works.
An indirect effect though is that if we no longer dedicate a portion of the grade to homework, fewer students do the homework and then they crash in the written exam. (Students have always been very grade-motivated. If it's not worth points they'll deprioritize it.)