Which I guess is better, but they are not tackling the root of the problem.
180 karma · joined July 12, 2021
Which I guess is better, but they are not tackling the root of the problem.
Now sure, you could answer that they are doing it better than others and you may be perfectly right, but is it really the way we want to solve it? Gossiping on every company on how often they update their software?
Having a phone with a new battery doesn't matter if I can't run the same apps as others.
There is no way to ensure that a vm/compiler will last forever, especially given the infinite amount of potential platforms. Binary search as a concept will last longer than ScummVM.
My problem with these is that they are cross-platform only as long as the maintainers decide they are, you aren't gonna write a vulkan software impl from scratch if the platform doesn't come with one.
Now you can argue that this is all very unlikely, but you have to agree that this is no archival. At some point the project will become unusable because of all the automation code it depends on. Binary search will outlive it.
The source does not mean anything if there is no working compiler, or if the compiler doesn't support your new shiny platform.
It is the same for servers. Having the source for a whole hosting service depending on some specific hardware doesn't matter.
If we decide to truly care about software legacy, we need to re-think the stack.
Giving conflicting informations to people all around the world expected to interact with each other is a bigger issue.
> but I haven't yet come up with a good system of combinators that can represent I/O and foreign functions properly
I do not believe that you should support either.
I/O could simply be the program arguments & the final reduction of the expression. The input being your mouse position and the output being a window shouldn't be the responsibility of your program.
Foreign functions are IMO a bad idea, especially if the goal is for the program to outlive you, you lose the guarantee if these functions depend on the environment. Why couldn't you copy/paste the code into your own project?
[0] - https://esolangs.org/wiki/Binary_lambda_calculus
[1] - https://esolangs.org/wiki/Dependently_Typed_Binary_Lambda_Ca...
We shouldn't prevent language from dying, but they shouldn't either due to lack of maintenance.
I believe the biggest problem to be environment/io access. It will be the bottleneck of most new language implementations and encourage people to update the old instead of creating the new. A simple fix would be to separate both, like in this blog post having input/output instructions and leave the actual environment interaction to something else.
Now I am not from the US so I won't comment about history, and I can fully believe that there is some link between being a white nationalist and believing one "race" to be superior to the others, but I do not believe that this is a reason enough to disqualify the idea.
Will this device be able to load any web page in one or two decades? It would likely be slow, but the impossibility would be a pure software limitation.
I didn't even mention these which are likely far from the priority or realistic, what about one day shipping?
Framework laptops could be considered as open-source, but I am not convinced that I could understand the system much quicker than any other random laptop manufacturer
The problem is that humans aren't getting specially smarter as generations go, but technology continue to grow
Or historically, if this wasn't true we would be the happiest humans to ever live on earth. Doesn't seem to be true on any possible metric.
What this means is that improving the standard of living of the average person by 5% while improving it by 50% for a smaller population will hurt more than it helps.
Dogs may be a hard no for someone, and yes for someone else. It's kinda arbitrary.