Neovim nightly already has some tools available as plugins. I'm using tree-sitter for syntax highlighting, text objects, and folding right now. Pretty satisfied so far.
>Look at it done correctly: tomc1985 objects that "[he is] one of these people, and [he] most definitely exists!"
You also need brackets around "exists" since the original quote had "exist". I think you're proving the point. I completely agree with the author that sentences like this are absolutely miserable to read. You can quote him as saying "I am one of these people, and I most definitely exist!" and, because we all have basic reading skills, we all understand that the "I" refers to the person speaking. Mangling quotes with unnecessary brackets is bad writing.
The option seller needs to buy the stock to deliver the shares when the option expires, so if the price continues rising their losses are unbounded (by contrast, their gains are bounded by how much they originally sold the option for).
Sorry but I find this claim (which I've heard from others too) ridiculous. "Blacklist" is an actual common English word in the dictionary. "Denylist" is an incredibly awkward-sounding neologism without any context or history behind it. There is no way that "denylist" is the "objectively clearer" one here.
You could expand this category to an AI for a number of similar games (like checkers and reversi) as well. I've written a double dummy solver for bridge--a program that computes the optimal result of the play of a bridge hand--as a side project and I think it's also a very good choice. A lot of the same tools as chess engine development apply: alpha-beta and the myriad variant search algorithms like MTD(f), transposition tables, heuristics like the killer move heuristic or the countermove heuristic. But you also need to apply some domain specific heuristics and tools, and since the whole thing is performance critical you need to worry about low level optimizations and good multithreading. In the bridge case it's not at all trivial to get something that can even finish at all in a reasonable timespan.
Chess is a very rich and pretty well-balanced game--that's what makes it so rewarding to study and to play. Even amongst modern computers that are miles ahead of the best humans, there's nowhere close to a single dominating opening or set of openings. On the human level, there is already far more computer opening theory than most players (including very serious, titled players) are capable of memorizing, so things haven't gotten stale yet.
>I remember back in the day when we used to just ask people if they could do FizzBuzz now we're looking at if they used an interface to wrap their ORM usage. That's something that can get picked up at code review and taught. Not everyone is going to code by default at the style of a company but they can learn to do the things the company wants.
>Then there is the obivous, lets test people for things they aren't going to do. Google and co made this the in thing and the fact we now have books upon books just designed so people who are good at tech can pass a tech interview is a sign in itself that there is something rotten.
So which is it? Should interviews be related to the work at the job or not? The Google type interviews evolved precisely from the philosophy in your first paragraph I quoted: that a lot of domain knowledge can be learned easily and that it was most important to test for more fundamental knowledge and abilities as well as general problem solving skills.
Ultimately I think it's a lot easier to criticize the interview process than to come up with a good alternative, as well as establishing some basic criteria about what should be selected for and against. Not that I think Google style interviews are perfect or anything, mind.
If that was only in the US or other wealthy economies, maybe. But they're an international company. Some of those rides are in places where a $2 increase doubles the price of the ride. I think it would be more revealing to compare with their total receipts and see the % change that would be required.
>There's also the weird thing of younger people like myself avoiding proper punctuation/capitalization for the aesthetic. Mainly because a lack of proper writing can make certain messages feel more "relaxed" and casual, if that makes sense.
I don't think it's weird at all, and I don't think it's simply aesthetic. All these things (punctuation, capitalization, emoji/emoticons, representations of non-verbal communication like "lol" and "hmm", message boundaries, message send times) are ways of conveying tone, nuance, and a personal voice in an otherwise sterile, flat medium.
These nuances have been around as long as we've had instant messaging, but the specifics have changed over time. Representations of laughter are a good example: over the years we've had (in no order) "lol", "Lol", "LOL", "rofl", "ROFL", "lmao", "lmfao", "LMAO", "LMFAO", "hah", "haha", "hahaha", "HAHAHAHA", "roflmao", "roflcopter", and others. Over time the nuances of these options have changed, with some no longer au courant (the rofl family is currently outmoded), just as spoken slang and language rapidly evolve. Punctuation choices and so on follow similar patterns.
I do roll my eyes a little bit at some of the wild prescriptivism that can be found in this thread, which I think completely misses the point. The footnote from the original post I find especially infuriating:
>sloppy with their written communication, which is to say "careless and unsystematic; excessively casual".
Casual speech is not sloppy! Choices of punctuation, capitalization, and so on are deliberate.
I think it's best to use native speakers as oracles: you can give them a piece of language and they can tell you if it's correct/natural or how they'd phrase it. You can't expect people to go beyond that, and trying to explicitly systematize the grammar isn't necessarily important or that valuable anyway; you need to internalize the grammar (as one has done with a native language) and that's not a conscious process.
>Fires have health and economic impacts on people who aren't in immediate danger of being burned to death and the only way to minimize these impacts to reduce the number of fires.
Reducing the number of fires isn't really a viable strategy; the flammable material just accumulates more and more. California has always had wildfires, they're just a part of the ecosystem. A lot has been written lately about how the strategy of trying to suppress every fire the last century is a big part of why we have so many giant, out-of-control wildfires now.
A min heap is different from a min-max heap. A min-max heap supports the operations of both a min heap and a max heap (essentially by interleaving the two). A normal min heap is a standard data structure, a min-max heap less so.
Yes indeed. Say you're creating a new component, and this new component will contain (among other things) some existing component, but the existing component needs to be styled slightly differently in this particular context. How do you deal with this with inline styling? Threading around this information between the components in JS to make the old component aware of the new one seems clearly wrong. A good old-fashioned style sheet handles it easily and relatively cleanly.
I've seen that inline CSS seems to be the latest trend, but I haven't really read up on why myself. Is this post really the current thinking? I find it completely uncompelling.
Originally one point was that you signed the back of your card and the merchant would compare the signature on your receipt to the signature on the card to verify your identity. Another point was so the merchant has proof you intended to pay them.
When I was living in the UK (which wisely uses a more sensible PIN system instead of signatures) I was shocked the first time someone asked to see the back of my card. I don't think it's ever happened to me in the US. Culturally we've collectively decided to ignore the whole "signature verification" thing, but when using your card abroad you sometimes are reminded that it's supposed to happen in theory.
You're confusing two different things. Ye as a plural pronoun is a bone fide archaic English word, ultimately sharing an etymology with the still-extant "you". "Ye" as an article ("Ye olde...") has the history you reference, where the y comes from a stand-in for a thorn (th), and so was not supposed to be pronounced as "yee". But ye as a pronoun (by far the most common usage, I think, and the usage in the poem) is just a normal word and doesn't share that history.