Thanks for giving this an actual shot. I appreciate it's alien tech, but it's something I've grown quite fond of over the last few years and I enjoy talking abo

Thanks for giving this an actual shot. I appreciate it's alien tech, but it's something I've grown quite fond of over the last few years and I enjoy talking about it. > They did get me thinking why programming is the one technical discipline which is actively hostile to notation/shorthand. Oh they're not the only one. Look at maths papers from the last ten years versus just twenty years ago: So much more verbose! So hostile to brevity! The benefit to a good notation is keeping in your head the solution. The downside to a good notation is that it keeps people from contributing to the solution that don't understand the notation. My conjecture: People who can't learn the notation can't contribute for other reasons. My second conjecture: This shit isn't as hard as people think it is. > the decision to use extremely concise identifiers has nothing to do with the performance / size / correctness characteristics of the code. This is not true! When I wrote the first kOS kernel, I wrote it with newlines and tabs because I didn't know any better. When I rewrote it in this style, I noticed a lot of code duplication that I could only see because the kernel now fit on a screen. This made my program smaller (original kernel was around 50kb the new one was around 30kb) which left more room in cache for programs making them faster as well. I was also able to see bugs that were only visible because I could see the caller and the callee at the same time and correct them. It all adds up! Since then, I've had numerous opportunities to see similar effects in other programs. Learning how to use notation has made me a better programmer.