• 1 Post
  • 894 Comments
Joined 2 years ago
cake
Cake day: November 13th, 2023

help-circle


  • I’m using whatever the stock keyboard is on Google Android. Since we’re on the topic, I’m open to suggestions. Especially if I’m going to re-train to swiping inputs.

    It’s hard to pin down anything specific as an example. If I had to sum it up, its usually where I want to use a long word with a common root for others. There could be eight or so different ways to go for auto-completion, but my choice is seldom in the top three.


  • I’m going to just take a guess: Most people who have a problem with autocorrect type each letter individually by pressing each letter?

    Possibly. I’m in that group, for what it’s worth.

    1. Was unaware that was even a thing. As a long-time touch-typist, doing this never even occurred to me. And I know how to use Palm Pilot Graffiti input, so I’m admittedly embarrassed here.
    2. My vocabulary is broader than the auto-complete’s dictionary/prediction, so what I want to say isn’t even a suggestion more than half of the time. I’ve struggled with this since iOS 3, and most recently on Android. It’s never been very useful for me.

    Then there is/was this feature that resizes key hitboxes on the fly, based on prediction. I’m unaware if that’s still a thing, but at the time, it absolutely screwed with my thumb-typing muscle-memory in the worst way. Until I learned about this, I was convinced that I was just garbage at hitting the keys, then I started seeing it mis-register keypresses when I looked closely.

    From all that I think I see the problem. These systems are compromises for a huge range of different users and communication styles. So it’s going to be pretty mid for a lot of folks until (people like me) move to the middle where the software wants people to be. Were it not for the sake of clear, personalized, and expressive communication, I’d be on board with that.








  • $0.02: much like AM radio (is/was), it’s basically a “2nd screen experience.” Put it on in the car or while you’re doing something else. Most of these do not deliver enough information or laughs per minute to demand your full attention. The exception are programs that are meticulously scripted, narrated, edited, produced, and sometimes acted, like NPR and the occasional oddball thing like Nightvale.


  • I’m not a geologist, but I’m imagine that the deep ocean would be a colossal underwater glacier, with intermixed sedimentary layers. Kind of like what we have with methane hydrate deposits, only much, much deeper. The super-deep ocean simply wouldn’t exist, and we might not even know about the Mariana Trench, or a lot of other sea floor features. Also, it’s possible a different proportion of the world’s water would be frozen in this way.

    With ice as a part of the sea floor, it would also interact with subduction zones at continental edges. That might push a LOT more superheated water into volcanoes, faults, and everywhere else water could go. That would probably make for a lot more geysers in such areas, and volcanic eruptions would be far more energetic.

    The trajectory of human history and technology would also be changed. There might have been fewer ice bridges between continents during the last ice age. Ice-skating wouldn’t become as common a thing until we get refrigeration. Harvesting ice in the winter would require bodies of water to freeze solid first, making it impractical except in shallow areas.

    I’m also going to wager that glaciers would behave differently too. I don’t know enough about their dynamics, but I wonder if having meltwater on the bottom helps lubricate their movements somewhat. Kind of like a lava flow, only slower. Inverting that relationship might make glaciers far less mobile.


  • This was my experience too, until I learned a few things.

    • If you’re coming from another programming language, the equivalent capabilities you’re probably used to are Box, dyn, and Rc.
    • Dynamic dispatch (dyn) isn’t really necessary a lot of the time. Identify where you absolutely need it and solve everything else through other means.
    • You wind up with lifetime specifier problems if you try to do a lot with references (&). Instead, try to re-think your structs and functions using composition and clone/copy instead. It’s less efficient, but it’s easier to optimize a running program, too.
    • Rust enum, match, if let, and ? are weird, but are where you get the most leverage in the language. Try to master them.
    • derive[...] is a first-class feature with a lot of standard lib support. Always use this to make your custom types mesh with the standard lib more seamlessly.
    • If you are experienced with the “Design Patterns” book, you absolutely need this: https://rust-unofficial.github.io/patterns/intro.html
    • Macros are an advanced feature, but help get you around limitations in generics and the type system in general. it really is worth knowing, and like the preprocessor in C/C++, isn’t avoidable at the intermediate level.
    • The compiler digs deep into your code to figure out types where they’re not explicitly declared. I’ve seen it reach into the return type, call-spec, and function calls within that function, to figure out types for things. This is very hard to observe without an IDE that’s checking syntax on the fly. Lean into both of those for more readable and maintainable code.
    • if and match are expressions, not statements! You can use either block to evaluate to a single value, useful in composite expressions like let. Example; let x=if y>20 { y } else { 0 }; Or use them to return values from functions (w/o need of a return statement).

  • I will say this: for me, learning rust was 80% un-learning habits from other languages.

    People tend to not like it when they have to change habits, especially if those took a long (and painful) time to acquire.

    In this particular case, this is the same complaint Go faced with its form of explicit error handling. And Java, for that matter.

    Honestly, Rust does a killer job of avoiding checked exceptions and verbose error hooks by way of the ? operator, and requiring all possible match branches to be accounted for. If you embrace errors fully, by using Result<> and custom Error types, your program gets a massive boost in robustness for not a lot of fuss. I recently learned that it gets even better if you embrace enum as a way to define error values, and make sure it implements useful traits like From and Display. With that, error handling code gets a lot more succinct, permitting one to more easily sift through different error values after a call (should you need to). All of that capability far exceeds any perception of clunkyness, IMO.