Lots of people were typing like that. As far as typing today, different layouts, hobbies with ergonomic keyboards etc we see far more people touch typing today than were in the 80's.
I wouldn't call it abnormal, I was pecking - very quickly for a long time before I ever knew what vi was. I found vi on my first unix login in '85 and still pecked at it.
I also know that today, with far more people typing, less of them probably gain the same knowledge as we did hacking back then. Good typing can't replace your computer knowledge.
Today I never look at my keyboard, it's 36 keys and its no use looking as no symbol represents what happens when you press the key. I am a better typist, not better at software though.
I have to admit, when a specific person died I was feeling so bad about it I never watched the last episode. I still have it on the drive how many years later.
I could see it coming and HATED EVERY SECOND of it. Then it happened even sooner than I expected and the impact was huge. The actor really gave that character life, and impact when the death happened, great talent.
The only real question I have with this is did the program have to have any specific performance metric?
I could write a small utility in python that would be completely acceptable for use but at the same time be 15x slower than an implementation in another language.
So you do you compare code across languages that were not written for performance given one may have some set of functions that happens to favour one language in that particular app?
I think to compare you have to at least have the goal of performance for both when testing. If he needed his app to be 30% faster he would have made it so, but it didn't need to be so he didn't. Which doesn't make it great for comparison.
Edit, I also see that your reply was specifically about the point that the libs by themselves can help the performance with no work, and I do agree with you, as you were to the guy above.
Honestly I'm not quite sure what point you're making.
> If he needed his app to be 30% faster he would have made it so
Would he have? Improving performance by 30% usually isn't so easy. Especially not in a codebase which (according to Cantrill) was pretty well optimized already.
The performance boost came to him as a surprise. As I remember the story, he had already made the C code pretty fast and didn't realise his C hash table implementation could be improved that much. The fact rust gave him a better map implementation out of the box is great, because it means he didn't need to be clever enough to figure those optimizations out himself.
Its not an apples-to-apples comparison. But I don't think comparing the world's fastest C code to the world's fastest rust code is a good comparison either, since most programmers don't write code like that. Its usually incidental, low effort performance differences that make a programming language "fast" in the real world. Like a good btree implementation just shipping with the language.
I did feel my post was a bit unneeded when I added my edit :)
My point about the 30% was that you mentioned that he got in rust and attributed it to essentially, better algorithms in the rust lib he used. Once he knew that then its hard to say that rust is 'faster' but the point is valid and I accept that he gained performance by using the rust library.
My other point was that the speed of his code probably didn't matter at the time. If it was a problem in the past he probably would have taken the time to profile and gain some more speed. Sure you cant gain speed that can't be had but as you pointed out, it wasn't a language issue, it was an implementation of the library issue.
He could have arbitrarily used a different program that used a good library and the results reversed.
I also agree that most devs are not working down at that level of optimisation so the default libraries can help but at the same time it mostly doesnt matter if something takes 30% longer if that overall time is not a problem. If you are working on something where the speed really matters and you are trying to shave off milliseconds then you have to be that developer that can work C or Rust at that level.
What I think it illustrates more is how much classic languages could gain by having a serious overhaul of their standard library and maybe even a rebrand if that's the expected baseline of a conformant implementation.
>If he needed his app to be 30% faster he would have made it so
That still validates "In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code" the parent wrote
Yes, copied it in to my scratch buffer to read it, not readable in the browser at all with a dark background. It did then make all the elisp nice to look at.
I think the same thing, and then I went a little smaller! I went to a large split then to a 58 key split, then to a 42 key split. At 42 I saw no advantage in going smaller other than it being smaller if you liked the look of it.
Then I wanted to try a small dactyl and that lead me to an already designed 36 key split and I love it. I lost some more keys and found that I can easily handle that. I would not say that the move from 42 to 36 made it more ergonomic but not worse.
While I went from 42 to 36 without thinking there were downsides, I think going any smaller does start to compromise functionality for the sake of form.
At 36, I think that even on a bigger keyboard I would emulate the layout I have now as it is so easy.
I don't think Miryoku is a good layout for many either, it will depend on your usage.
A strange thing is that many come in to the small split keyboard world and then don't have the motivation to come up with something that works for them. You can make anything work, so a lot make Miryoku work but I doubt for many that would be the best layout for them.
I code a lot and find that its layout would not suit me. I have 99% of what I need on a the base layer and one more layer for doing development work - on a 36 key board. I could not imagine that I would want to switch layers as much as I would have to for a continuous stream of alphabet/symbols and numbers.
I think Miryoku would be fine if you were an average computer user editing documents, emails etc and I do sometimes forget that there are a lot of guys out there using Miryoku doing only that.
I recently downloaded a number of magazines froma now defunct publication from late eighties. No onesells them and annas archive was the only place i found them. its not exclusivly pirating, its a source for a lot of out of print.
Thank you for the suggestion. The news I was after was usenet feeds, I have archives of some groups but thought it would be interesting to rather than go and read it all at once have it put a new days worth of posts every day from the past.
As the messages are all in just text format with headers and timestamps I should just be able to extract the messages from a particular day and add them to my news reader, worst case changing the timestamp to today to have it appear in a sensible place and putting the original timestamp back where it can be seen when reading.
If it could be OK for you other than that, there is usually a timeout setting that can be applied before it is recognised as a press.
For example, any press under 200ms is ESC, anything over will register as Ctrl. The timeout can be adjusted to work and not capture that time that you press it but then decide you don't want it.
