That's basically the comment I was just going to write but you made me not need to.
We need simpler protocols and formats, especially those that are used over the internet.
I want everyone to really start fighting for this.
I always use a browser that doesn't run any scripts (w3m) for both this reason and others.
It hurts when I see websites that don't work without js.
A bit funny though that this page is one of them so I was not able to read it.
Wikipedia is basically the most popular application of all time and it doesn't rely on javascript. People just generally don't give a shit about where their money goes.
There is no possible interpretation under which JS fits “simpler protocols and formats,” and no world in which JS could form part of a truly secure network client environment.
I am working on a project that will be like a whole environment
bootstrapped from the smallest possible beginning.
I thought a hex-to-binary converter like hex0 was too much like
machine code, and I wanted everything to be source code, so I
chose to instead start with a super simple interpreted language
that is described in english and the user is supposed to write
an interpreter for it themselves in any way they want. This
way I connect the human to the computer using the language of
the human which I thought felt better and easier to understand.
This super simple interpreted language then builds a super
simple RISC-V assembler. Here I came up with a nice technique
where the functions in the assembler are called through
pointers, which makes them replacable while the asesmbler is
running. So as soon as the assembler has compiled a better
version of one of its own functions, that function is then
replaced with the better version while the asesmbler is running
and it continues to compile the rest of the code which can then
use the new features. So it evolves without having to restart.
I still have a small fee available from NLNet for the implementation of a RISC-V back-end for a compiler (more a transpiler) from a small stack language to assembly. I have already started the effort, but at this moment not the time to work on it. I am available for support. Back-ends to x86, x86_64 and arm64 are available and working. This is part of the MES-replacement project [1]. Let me know if you are interested (see email at the bottom of the website mentioned in my profile here or on GitHub.)
I wasn't thinking about distractions or being able to concentrate when I asked this.
I meant something that exists over longer time, like years.
Like, the knowledge that there are so many other things makes it harder to appreciate and care about each of them.
There seems to be a similar effect when living in a place where there is a high density of people.
They start looking like background noise.
But if there are not many people around, you might talk to almost everyone you see.
Trying to answer my own question, one thing that I think has helped me to more appreciate some things, is to have rules and try to enforce them.
It could be to use an unusual operating system, or disconnect my computer from the internet, or deciding that there are some types of things or features that may not be used.
That has the effect that most things I find online don't pass the rules or don't work for me and therefore I have to care more about the things that do.
So I was wondering how we can achieve this at a bigger scale, unless everyone else want to limit themselves as I do.
It's quite fun actually but I don't think people care enough to do this.
I think another reason to write code by hand is that you want to know what you get.
If you have an idea, then you can implement it better than an LLM, just like you can implement it better than another person, because you are the only one who understands what you mean exactly.
Details are always lost and misunderstood in communication; this is a weakness of LLMs.
Similarly, even if I don't write the code but I let someone else who I trust do it for me, there is value for me in that person not using LLMs, because only if they don't, I can know that the only spirit that lives in the code is of the person of my choice.
It's like a social thing; I can know and trust a human, but I'm not sure I can do that with an LLM.
It's similar to how you wouldn't want to use LLMs in politics: the whole point of expressing your ideas is that they are your ideas and if you let someone (or something) else do it for you, details will be missed and misunderstood.
So this is one reason that I think hobby communities don't like LLMs; they care too much about what they build.
Depending what you are making; coding slows you down and think as you build stuff step by step. Its kind of like speaking vs writing. Generating code through LLM for me is like talking -- I love talking, but when I write something down, I'm more structured, think more about things etc etc.
People say, if you you write elaborate well spec'ed prompts, it will do the right thing. Coding in a way is doing that.
- A server package containing: web server, smtp server, database engine, page generating language and a supervisor that keeps everything alive. All written in C and I use them for all server programming I do.
- A file renamer that can rename multiple files. It puts the filenames in a text file and lets you edit it and then renames the files according to the changes.
- A RISC-V start kit containing a very simple assembler, disassembler and documentation.
- A script that runs twice a day and downloads things from the internet (like weather forecasts, news feeds, podcast feeds, train traffic info), puts them in a folder and does some processing and formatting. Then I can easily go through it all to get my daily information.
The article is about only one side of the solution: using AI to make it easier to work with code.
I think the other side of it is more important: making software simpler so that people can work with the code without having to use AI.
That's what I try to do.
There are so many formats and standards and people using different sets of them that I feel like we need an organisation that selects some of them and decides that those are the ones that people should use.
Everyone could become a member of that organisation and vote for which standards should be part of the next version of the selected set.
Maybe there could be a new version every other year or something.
This would give us some kind of leader that shows the way.
It would make it easier for developers if people were more focused on fewer standards and there would be a well defined point in time when we would upgrade to the new set of standards.
For those of you who are familiar with RISC-V, it would be like the RVA23 spec: one big collection of things to use that can be targeted and talked about as one thing with one name, rather than everyone having their own collection of extensions that they use.
I don't know if there can be any memory safe languages.
Programming is always unsafe because you can always make mistakes.
The best we can do is to use tools that help us avoid the common mistakes.
As an example of that, the rust compiler helps the programmer to avoid many mistakes but it's still possible to use memory incorrectly and the tool is only safe as long as you use it as intended.
You could say that C is safe too as long as you use it as intended and make no mistakes.
The only problem is that it's hard to use it as intended and make no mistakes.
So let's think about what memory safety could mean.
My understanding is that a memory bug is when you use memory in an unintended way.
An example of that is when you write to memory after you have deallocated it, which means after you have decided not to use it any more.
No compiler or tool can make sure you don't write to or read deallocated memory, because whether it's allocated depends on what your intention is, and no compiler can read your thoughts.
They can only give you a tool (like functions for allocating and deallocating memory or compiler checks) and hope that you will use that tool in a way that reflects your intention.
One problem is that those tools are not always sufficient to keep track of your intentions and you may not always use them as intended.
Memory allocation is relative.
In a sense, no program that runs under an operating system can use deallocated memory, because when they read or write to memory that has not been mapped to the process, they crash.
In a sense, even "safe" rust can use deallocated memory;
let's say you have an array of 10 integers and you decide that the fifth integer should not currently be used, you have then deallocated it on a level where the available tools can not help you, but you can of course still access that memory.
So again, everything is safe if you use it as intended and nothing is safe if you use it in other ways.
Safety depends on how well the code matches your intentions.
Remember that programming always happens in layers and no tool can cover all of them.
It's not even clear what "all layers" would mean or how many there are in a program.
> but it's still possible to use memory incorrectly
Only by misusing unsafe. Using it in regular programs actually isn't that necessary. In languages like C you have unsafe code almost in every line.
> My understanding is that a memory bug is when you use memory in an unintended way
Memory safety rules are more strict and formalized than you think. Memory safety issues are typically reading uninitialized memory (or strictly speaking changing observable behavior based on contents of uninitialized memory), reading/writing memory after it have been freed (free/delete call or out-of-scope going for local variables), concurrent unsynchronized memory access.
> No compiler or tool can make sure you don't write to or read deallocated memory
I am author of a programming language, where you can't write to or read deallocated memory, unless you misusing unsafe.
> no compiler can read your thoughts
But many languages more complex than C have powerful features allowing telling the compiler your about intents. At least partially.
> Memory allocation is relative. In a sense, no program that runs under an operating system can use deallocated memory
You are mixing two different concepts. One is memory model of the abstract machine defined by the specification of a language and other is the OS processes model. They have much in common, but there are a lot of differences.
> So again, everything is safe if you use it as intended
Such mindset is considered harmful, since it provides an excuse to use languages where making mistakes is easy (like C).
Say I implement a dynamic array in the usual way with buffer, length, capacity. Currently the capacity is 50 and the length is 20. I access element 30 i.e. an unallocated element. Was that memory unsafe?
Yes. In practical terms, because optimizers like GCC and LLVM track uninitialized values and it's undefined behaviour to read from them, so you essentially have a split between what memory is allocated from the perspective of write operations (capacity) and what memory is allocated from the perspective of read operations (length).
On an academic level, memory safety is split into "spatial" and "temporal" cases and one that Wikipedia calls "spatiotemporal", with reading off the end of "capacity" being a spatial memory safety bug and reading within "capacity" before initializing being a temporal memory safety bug.
The other temporal memory safety types as Wikipedia enumerates them are:
* Use after free
* Double free
* Mismatched free (stuff like not using the free() from the same DLL that called malloc(), mixing up malloc/free with new/delete, etc.)
I think the point you missed or don't want to accept is that I think of all layers of memory management as the same thing just on different layers.
Where you say that I mix different concepts, I say that it's just different layers of the same problem.
So which layer should we care about?
All of them?
Yes, if we want the most safety.
I will give you an example of how I can use memory incorrectly in "safe" rust.
Let's say I have an integer that contains my age.
Now I forget what the number was used for and I use it as shoe size.
I have now used memory (the content of the variable) as something it was not intended for.
Maybe you think this example is silly, but what is really the difference between using a float pointer as an int pointer and using age as shoe size?
Another thing we could do is to use an index for one array as an index for another array.
That's an example of using a pointer as the wrong type because an index is just a relative pointer.
So if we want to care about all layers of memory safety then we have to care about not using ages as shoe sizes and indexes with the wrong arrays.
"Memory safe" languages usually don't help us with that and therefore they don't give us total memory safety.
I think "memory safety" is not a very useful term because all data in a program lies in memory and basically all bugs have something to do with using that memory in wrong ways.
> we have to care about not using ages as shoe sizes and indexes with the wrong arrays. "Memory safe" languages usually don't help
In languages even slightly better than C one can create a wrapper type for int/float with additional semantics like age, shoe size or something else. Since they are different types, using one in place of other isn't possible. This doesn't solve all problems, but at least can prevent silly mistakes.
Interesting, I have had ideas about having that feature in a language: being able to make subtypes, like "this is an integer but on the next level it is a shoe size".
Can you give an example of such a language or how they usually do that?
(The first ShoeSize is the type name, the second is the name of the constructor that converts an integer to one, or pattern-matches on it. This is unambiguous in Haskell and they are often the same. It has symmetry with "data" which is for more general ADTs that can have more than one constructor.)
First, AI is not just a tool like other tools.
It's much more random and complex, which makes it very different from other tools.
You can't simply say that it's useful.
How useful it is depends on what you are trying to do.
If you are making some software that you need to understand well and be responsible for, then I think AI could make that harder, because it doesn't force you to think through and understand everything, and having to do that probably makes it just as fast to write it by hand anyway.
Don't forget that part about understanding and being responsible.
It's important.
Even if AI got 100000x better, understanding and being responsible would still take about the same amount of time, because it has to be a very manual process, and it taking time is part of the point of it.
Also, while a computer can't take responsibility, a human has to do it, so using AI could easily reduce the responsibility taken by the human without increasing it anywhere else.
Some people say they "hate" AI. But in my view that is misguided. AI is a "tool" in the sense that humans use it for their own purposes. We should hate people who use it for bad purposes, not the tools they are using.
We need simpler protocols and formats, especially those that are used over the internet. I want everyone to really start fighting for this.
I always use a browser that doesn't run any scripts (w3m) for both this reason and others. It hurts when I see websites that don't work without js. A bit funny though that this page is one of them so I was not able to read it.
reply