352 karma · joined November 15, 2010
Extra responsibility/accountability/risk without corresponding compensation reads like a promotion to some folks, but to other folks it looks more like a pay cut.
That having been said I do agree that it is disappointing how sluggish some apparently-straightforward applications have gotten despite the hardware performance increases over the years.
Two things. First, I've been bitten by this myself, but it's pretty much always been something like "Oops, I renamed a function and forgot to update a reference to it, but the code still worked because the old definition was still there... until I reloaded the REPL." It's always been a trivial fix for me, since when I try to re-evaluate the buffer containing the outdated function reference it throws a "cannot find function definition" error. I currently consider the advantages of REPL-driven development to outweigh that occasionally happening.
Second thing: maybe others do it differently, but I don't think I generally make manual changes to the state while things are running. If the state doesn't look the way it should, I either start iteratively tweaking functions (by modifying my .clj file and eval-ing them) and re-running with fresh state to understand and resolve the problem, or I work with a separate, similarly-shaped piece of state and run it through functions in a sort of "manual unit testing" to tweak and fix whatever's wrong, and then I re-run everything from scratch to make sure it worked. I don't adjust the state, evaluate a code path, and then continue on if it works (because yeah, I can totally see how that would lead to the sort of situation you describe, which sounds unpleasant)
Some of the "tells": The whole thing has a "Chick Tract" vibe to it (personal, relatable story but with oddly specific details segueing into actions you can take for the good of your soul/safety of your family). Most of the items are obviously and patently false to anyone with any kind of domain knowledge, but are phrased earnestly enough that someone who assumes the writer is acting in good faith may not realize this. For example, number 4 suggesting that Snow Crash, Cryptonomicon, Neuromancer, etc. are "hacking manuals" or number 5's conflation of Disk Operating System DOS with Denial Of Service DOS.
It would be great if by this point in time everyone who saw something like this would realize it was either in jest or bad faith, but I suspect that computer illiteracy--and the number of folks who would take this at face value--is far higher than most of us realize (then again, maybe I'm just being overly cynical. I hope so; that's the sort of thing that I'd love to be wrong about! ;-) )
inoremap jk <ESC>
I learned it through Spacemacs and it's one of the things that really made modal editing work for me, so I was thrilled to discover that Vim itself also supports it. (I'd tried to learn Vim before, but always having to jump over to the Escape key was a huge downer for me, and coming from Emacs I'd already mapped my CapsLock to Ctrl--though the idea of having it be Esc if pressed by itself is intriguing and I need to look into it more!)There's also a line from the Klutz Book of Card Games that ended up being an in-joke with my family that we still use 20+ years later: "You poor fool, I can read you like a book!"
Thanks for all the fun! <3
Personally, I'd rather just implement the wireframe (or something like it) and try to iron out the interaction wrinkles there where it's much easier to update the design and you don't have to worry about fonts and spacing nearly as much; once the interaction implementation is nailed down, then I think it's a better time to move on to the mockup. Hopefully we'll get an opportunity to try this at some point, but it was enough of a struggle to do a separate wireframe at all that I'm guessing it'll take awhile ;-)
As some folks have mentioned, normal US notebook paper doesn't work particularly well with fountain pens (they tend to show through to the other side enough that I can only use one side of each page). Most printer paper also suffers from this problem. You can get nicer notebooks that address this but they tend to be very pricey and I take notes prolifically (and of things that I don't particularly care to keep) enough that those aren't a great solution for me either--I go through them too quickly, and then I have a collection of random ephemera that I feel bad about tossing. So I use the paper mentioned above with off-brand Levinger rings, which let me reorganize them fairly easily (though it's still enough of a hassle that I'm thinking about giving the good ol' 3-ring binder another try...)
[0] https://www.amazon.com/HP-Printer-Paper-Premium32-Letter/dp/...
Perhaps more to your point, if these are mating dances, why do so many people who already have stable, long-term mates participate?
if( maybeNullValue ) {
myValue = maybeNullValue;
} else {
myValue = defaultValue;
}
can instead be expressed as this: myValue = maybeNullValue || defaultValue;
I'm personally a little bit torn about it. On the one hand, now that I'm familiar with it I love how much more concise code can be. On the other, it can have a fairly negative impact on code maintainability: if someone comes along who isn't familiar with that idiom, they might have a bad time trying to figure out what's going on (or worse, they might take offense that all these predicates aren't returning True or False values and rewrite the whole mess--or you could end up with a mix of the two, where some functions follow the idiomatic convention and others return actual boolean values which is arguably the worst)Also I'm not trying to say that there's not some YAGNI going on here--just that I suspect he did it that way somewhat reflexively, and that in that particular case we probably cannot infer he had originally intended to do something else with those results and then changed his mind later.
[0] at least in the Lisp world, which Norvig has extensive experience with[1]