Since they were on a boat with a Raspberry Pi and not much battery power or internet, in addition to execution speed and portability, they were probably also concerned with:
- speed of compilation and linking (on small machines like Raspberry Pi)
- binary size of anything that might have to be updated or shared over the internet
- having to troubleshooting emergent issues without the ability to lookup documentation or download updates or tools from the internet
In this situation, a simpler language on a simpler VM is probably going to be faster to develop with than compiling/linking a subset of C, and after the initial implementation of the VM, might present less opportunity for an unintended interaction of leaky abstractions in your libuxn and your toolchain to ruin your day on a day when you don't have internet connectivity to check Stackoverflow or to update some buggy dependency.
I have a raspberry pi 2 (one of the first one, very low) and tried compiling orca.c on it with gcc. It took 7 seconds and produced 38KB executable. This is more than what I expected, but it's still pretty reasonable. However, I can see how this can be annoying with very rapid iteration cycles.
(Btw, building alone (no linking) takes 5.4 sec, so compilation time dominates. And optimized build (-O3) was over a minute. Not something to be done as part of development.)
But then I remembered about lighter compilers, and tried 'tcc'. This was substantially faster - just 0.6 seconds for the whole process! I think this is very reasonable, and for newer Pi's it would be even faster.
Also note that my idea was to forgo standard libraries and only link to libuxn (and only include uxn.h). This theoretical libuxn will have the same role as UXN virtual machine - written only once, and then frozen in stone, with no updates.
This will take care of large binary sizes - if you are only linking to libuxn there are no updates to download. And there is no need to lookup documentation or consult stack overflow, as you are only allowed to link to libuxn, no third-party libraries.
Will such limited environment be inconvenient? Somewhat, but less that full-blown VM. Will it take effort to write and maintain libuxn on all platforms? Yes, but less effort than full-blown VM. Won't libuxn have some bugs requiring updates? Likely, but I bet it will have fewer bugs than full-blown VM.
As for other things (updating binary over internet, shareing
Yes, I think it's very possible that human brains unconsciously generate-and-test surprisingly large numbers of small candidate programs when solving a problem.
This approach is https://en.wikipedia.org/wiki/Embarrassingly_parallel, which is a good fit for biological neural architectures, which have very many computing nodes but each node is very slow (compared to electronic computer CPUs/GPUs).
The first thing to do is to put LLMs to work to generate large knowledge bases of commonsense knowledge in symbolic machine-readable formats that Cyc-like projects can consume.
I don't understand why an Income Sharing Agreement would be classified as loans. They seem more like equity than debt; the amount that students would pay depends on their future income, and can be arbitrarily small or large (right? or maybe I am misunderstanding the terms of these agreements).
I had thought that debt is when you have to pay back at least the "principal" no matter what, and equity is when the financier shares the risk of you failing. Maybe that's not correct, though?
Does the definition of a "loan" include any sort of financing, even if the amount that needs to be "paid back" to the "lender" can be arbitrarily small or large? That would make equity financing a special case of debt.
You can’t hold equity in a person, because that is slavery. All consumer liabilities are thus a form of debt. The characteristics that matter most are whether it is secured, the schedule of repayment, and the schedule of fees (interest being amongst the fees). Everything else is window dressing after those three parameters, and the label you stick on the box matters the least of all. Consequently, undischarged debt is indistinguishable from a loan, which is rather the CFPB’s point.
When push comes to shove, the substance of a thing matters much more than the attempt to relabel the thing.
Even if other users (or possibly, sock puppets of the attacker) had not been complaining, the original maintainer probably would have began to trust the attacker after enough real contributions.
This thesis provides empirical support that a specific measure of software architectural complexity is costly. Specifically, they look thru source code in an automated manner, construct the graph whose nodes are source code files and whose edges are the following cross-file relationships (page 73, section 5.1.2.1):
- The site of function calls to the site of the function's definition
- The site of class method calls to the site of that class method's definition
- The site of a class method definition to the site of the class definition
- The site of a subclass definition to the site of its parent class' definition
- The site at which a variable with a complex user-defined type is instantiated or accessed to the site where that type is defined. (User-defined types include structure, union, enum, and class.)
Then they compute the transitive closure of this graph.
Then they compute two metrics for each node by looking at the transitive closure graph (page 76, section 5.1.2.3):
- Visibility Fan In (VFI): how many other nodes have edges that go from the other node to this node?
- Visibility Fan Out (VFO): how many other nodes have edges that go from this node to the other node?
They observe that by looking at the VFI metric across various files, files tend to sharply cluster into either 'low VFI' or 'high VFI', and similarly for VFO (although some files may be high in one metric and low in the other) (page 79, section 5.1.3).
They then classify each file as:
- low VFI, low VFO: 'peripheral'
- high VFI, low VFO: 'utility'
- low VFI, high VFO: 'control'
- high VFI, high VFO: 'core'
They then find that 'core' files are the most costly, in terms of defect density, developer productivity, and probability of staff turnover.
The university system is a mechanism to fund public goods. The problem is the professors are judged according to their production of novel knowledge, and maintaining useful software does not produce novel knowledge. We should endow chairs of "open-source professors", who are judged according to their production/maintenance of useful software, in order to re-use the infrastructure of the university system to fund this other type of public good.
Describes the motivations for and design of a massively parallel computer with many (millions? 64k?) of very simple processing nodes that serve as both memory and CPU. Shows how you can have "active data structures" where each item of data is in a different CPU (or clusters of nearby CPUs) and literally migrates between CPUs as computation proceeds. I think it gives an example of the parallel bitonic sort algorithm being executed in this way. A relatively thin book and relatively easy to read for a programmer.
You could probably make everyone happy just by copying that text to the top of the landing page, as an additional paragraph just above where the "Current progress" button is, right after "..ensure clean and correct multi-threaded designs."
