1.  

    I looked into this device a couple of years back. I needed a way to take notes and read papers.

    Long story short: it’s too expensive. Even after the initial purchase, you still have to buy replacement nibs for the stylus. I was also worried about the software bit-rotting: I had no idea if the manufacturers would keep up with security patches.

    I ended up getting an Amazon fire HD 10 for reading, and a Rocketbook Everlast for note taking.

    Together, these were about a third of the price of the reMarkable tablet. Admittedly, I do have to refill the Frixion pen for the Rocketbook, but still…

    If anyone is thinking about doing the same, I highly recommend the Xodo android app for annotating PDFs. I also tried a few different styli for the Fire, but ended up finding it easier to use a finger.

    1.  

      It handles arbitrary PDFs perfectly. I’ve been using it to read math textbooks, papers, and even arbitrary web-pages that I save to PDF. Few PDFs require you to zoom a bit, which is a little annoying, but I expect that it should be fixed in a future software update.

      1.  

        When I started getting in to computers with FreeBSD 20 years ago the FreeBSD handbook listed various popular backup solutions. The top of the list was “do nothing” :-)

        1.  

          What are Haskellers meant to do with this feedback? This kind of feedback comes up often, and it seems it’s always either that Haskellers are meant to admit that all programming languages are the same and which one you choose is not important, or that if Haskellers recognise some language features that provide genuine leverage then they shouldn’t talk about if for fear of offending the egos of those who don’t understand this stuff yet.

          1.  

            I agree with all your points – there is a certain energy that abounds when someone masters their tools and can operate with fluency in the physical world. I personally don’t think it should be a subject of controversy that proficient use of the primary computer input device makes one a more proficient user of the computer – it’s easier to get into a flow state, it’s easier to use tooling, and it’s easier to communicate with others.

            If you’re a faster typist, you might find it easier to spare a couple seconds writing that email to a remote colleague that might just flip their day from bad to good. You might spare a couple seconds to comment that tricky bit of code before moving on. You might spare a couple seconds typing out repetitive test cases instead of DRYing them prematurely and making others cry when they have to add functionality. If typing feels like a slog, you’re going to be more stingy with written communication in general.

            But, I also have a meta-comment about topics like this. People who aren’t fast typists will be the ones piping up in the comments about how typing speed doesn’t matter, and those who type well will say that it does matter. Confirmation bias is a thing, and ultimately I think it comes down to aesthetics. I know a couple of programmers who are atrocious typists—to the point that watching them type is painful—but are excellent at programming and ultimately very productive. Maybe they just don’t feel they need the ‘energy’ that comes with mastery of physical movement?

            1.  

              Similar to a toy gist I made a few years back: https://gist.github.com/wvdschel/2250827

              Thankfully, C++17 has removed them, and you will get compiler errors if you use sane & modern compilation flags. Not sure about C.

              1.  

                I find the idea neat, but I still struggle to see the benefits in my day to day job. The example doesn’t illustrate clearly what I cannot already do easily with bash, curl and jq:

                curl https://jsonplaceholder.typicode.com/todos/ | jq '[.[].title]' > titles.json

                1.  

                  Yes, no forward/backward secrecy, which is a serious concern.

                  Also, there’s no support for group chats beyond pairwise encrypting to everyone.

                  To be fair, that’s all that Signal does for group chats too.

                  1.  

                    If I have too many windows open, I close some, or otherwise put them on different monitors or virtual desktops for instant navigation with shortcuts. Each to their own, of course. The main things I can’t not use a mouse for are FPS games and DAWs.

                    I first played the PSX version of DOOM, and a little later, a keyboard-only version. Vertical aiming isn’t necessary at all, and it’s perfectly serviceable without a mouse!

                    1.  

                      Oh the irony that the ICANN website is accessible on the same TLD that is being sold.

                      1.  

                        If I were to compile a list of things I believe have the potential to make you a better musician, your ability at sight reading would very likely not even make it. Getting any sort of benefit from your amazing sight reading skills assumes you actually have something to play, which is—at least for me—most of the time not the case when playing music. I spend much more time thinking about what to play and when to play it than I do actually playing. Does it matter that I can, after a week of studying, play this piece 120bpm as opposed to merely 100bpm?

                        If you feel that your musical reading ability is holding you back, then by all means invest time in learning solfège. But if not, there are so many other areas of musicianship you can focus on—like listening and understanding other people’s music—that have much higher chance of making a better (and more virtuosic) musician out of you.

                        1.  

                          All of the retrospectives of StackOverflow’s culture clearly state that asking questions effectively is a skill. They then repeat the same few bullet points about ensuring that questions are within the scope of the site, provide enough information, aren’t duplicates, etc. etc. What they don’t mention is that this will have approximately zero impact on your question getting answered. As far as I’ve been able to tell over the past decade on StackOverflow, what leads to your question getting answered is the size and popularity of the technology or programming language your question relates to. Ask a Javascript question? You’ll have a dozen replies almost before you hit submit, even if your question is poorly formed and has been asked a million times before. Ask a question about a relatively obscure technology, and it’s very possible that your question will never be answered.

                            1.  

                              for me:

                              • navigating in text is done faster using the mouse when jumping more than a few lines/words, even when displaying relative line numbers in vim.

                              • acmes mouse chording is really nice to use and required only a short time to become used to. i still wish copy/cut/paste would work like this everywhere. maybe modified a bit for the current mice, clicking with the wheel isn’t that great.

                              1.  

                                Does it know if the closure used to map is pure or not?

                                1.  

                                  I think typing speed matters. Not a whole lot, but it matters. Not in finding a bug, not in reading code, but when you, occasionally, just need to bash out some boilerplate. It also works for writing prose which I believe many programmers should do (even if it’s just documentation or comments).

                                  When I ask some of my more experienced coworkers something, they talk while they type something like cd folderwherethesourcefileiaskedsomethingaboutis vim sourcefileiaskedsomethingabout /somekeyword

                                  and before the end of the first line of their answer they can point at the relevant line of code and answer my question. Gary Bernhardt types pretty fast, and I think it really helps in how fluent his screencasts are. See https://www.destroyallsoftware.com/screencasts (there is a free screencast – I don’t think they are regularly updated so I wouldn’t go for a subscription but there’s great content there so it might be worth it to subscribe once and download everything).

                                  That being said, chances are there are much more efficient ways to get better at programming.

                                  1.  

                                    There is something to this the author did not point out. Typing faster is less frustrating than slow typing when you feel the flow. Faster typing enables faster use of tools, even if the mouse were occasionally involved.

                                    Depending on your programming language and tools, faster typing allows you to “think out loud” in code and tests. It may even drive you to make the dev cycle faster.

                                    Pair programming is more fun and efficient when you don’t spend time on slow typing, and eventually you may even talk while writing out the code, like a singing instrumentalist.

                                    And in a lot of work, any task really isn’t that unique. Doodle some diagrams and start prototyping by typing fast.

                                    Contemplate old code and fix it by typing fast.

                                    Even if the seconds saved never amount to much real time, there’s an energy to it that should not be discounted.

                                    1.  

                                      Yes, that’s right. I was just not going for accuracy before. ;)

                                      1.  

                                        Yep link time is non-trivial. lld can help here if you’re on a supported platform. E.g. here’s a 50% reduction in debug build time on a game. Here’s an example by the Embark game studio for how they speed up compile times with lld on Windows.

                                        1.  

                                          I’d be interested in seeing a good example of Haskell code that becomes more expressive/performant than its equivalent in another language thanks to laziness features that aren’t lists.

                                          I’ve barely done any Haskell so take this with a grain of salt, but one benefit I’ve been told is that there’s no need to build seperate “streaming” APIs. Everything is streaming by default due to laziness — network interaction, parsing, decompression, etc.