HackerTrans
TopNewTrendsCommentsPastAskShowJobs

mandw

no profile record

comments

mandw
·2 माह पहले·discuss
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.
mandw
·2 माह पहले·discuss
Fair enough. I assumed everyone would have watched it by now from here :)
mandw
·2 माह पहले·discuss
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.
mandw
·6 माह पहले·discuss
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.
mandw
·6 माह पहले·discuss
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.
mandw
·6 माह पहले·discuss
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.
mandw
·6 माह पहले·discuss
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.
mandw
·6 माह पहले·discuss
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.