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.
The official release of built-in treesitter comes with neovim 0.5. Which looks like it'll be out pretty soon. I've been watching a fairly steady march toward release here: https://github.com/neovim/neovim/milestone/19
>I had never thought about the connotations of blacklist and whitelist before it was pointed out to me. In retrospect, blacklist and whitelist are unnatural meanings of the words black and white, and blocklist and allowlist make much more sense.
This is everyone's story with these words. This movement was not driven by POC taking issue with the word "blacklist". It started with some white dude's shower thought that because "blacklist" was a negative thing, and because "black" also can refer to skin color, that the term was thus racist [1]. Then a bunch of other white dudes ([2]) were like "oh yeah for sure that makes so much sense" and here we are--everyone goes along with it because they (rather patronizingly) think that someone else will be offended.
The word "blacklist" is many hundreds of years old. It does not have a racial origin. It's just a word. Nobody actually makes the association between "blacklist" and "black people" unless you tell them to! Our brains aren't nearly so stupid!
>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.
> You also need brackets around "exists" since the original quote had "exist".
That's fair, I put too much trust in hedora's version.
> I think you're proving the point.
I may be demonstrating the article's point, that it looks awkward, but I still strongly disagree with hedora trying to make it look like the subjects get all wonky and confusing.
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).
Correct me if wrong, but my understanding with Robinhood is that you Sell to Close (by default anyway), which just goes back into the market. No further obligation?
You can buy or sell an option to open a position. If you want to buy it, you Buy to Open and Sell to Close.
If you sell an option, you Sell to Open. If you want to buy it back (at a profit/loss and you're not assigned), you Buy to Close which goes back into the market and closes your position. If you are assigned (i.e. the buyer of your option exercises his right to buy 100 shares at the strike price), you have no option other than to buy those shares at market price if you don't have any and deliver it to the option buyer.
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.
The main problem with trees is they’re very slow. It would take decades after we started planting billions of trees a year before they’d have grown to the extend where they’d have captured reasonable amounts of carbon.
So, yes, it’s an option. But it’s a slow option we’d need to start implementing immediately if we wanted it bear fruit.
(We produce enough CO2 that it takes 40 billion hardwood trees growing for 40 years to sequester as much CO2 as we make in a year. We’d have to plant a lot of trees, and then not touch them for years, to affect the course of things)
If you pants trees om every bit of avaliable land, that stilll would not be enough to compensate for the emissions - we use a lot of land for farming, and are emittinghundreds of years wortg of tree-catrure per decade.
You are aware that "temporarily" in this context is the lifespan of a tree, right? Trees live anywhere from several decades to 20+ centuries, and their remains, once broken down, provide nutrients to the soil so more trees can grow.
Also the tree is not capturing carbon, instead emitting, half of the year if not planted in the optimal places near the equator.
And it's carbon neural or negative once almost fully grown.
Basic biology should tell you that the only thing that counts for carbon capture is biomass added. Anything that the tree does that doesn't permanently add to its mass can't capture carbon permanently. Hence, once a tree stops growing, it stops capturing carbon. It still respirates because it does things that require energy, but any carbon it captures doing so is released fairly quickly again, e.g. when the leaves it produced in spring fall off and rot. Of course many trees keep growing a little even after they reach maturity, but the rate of growth is minuscule. A mature stable forest stores a large amount of carbon, but it hardly captures any more.
Anyway, the land we have is limited. You literally can't cover the planet in one big forest to capture the gigatons of carbon we have released. You have to do active forest management and store the carbon somewhere stable, for example as biochar.
You are mostly right, but some of that carbon does sink into the soil and get captured for much longer periods, and some of that will will sink further and likely never see the surface of the earth again unless someone digs it up.
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.
> 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.
If a company wants to test someones basic logical knowledge and fundmental programming knowledge, seems fair enough.
There is a massive difference between writing FuzzBuzz and knowing the differences and uses from all the different sort algorithms and being to write optmisied computer science code. One tests programming and logical skills to a childs level (FuzzBuzz is a kids game), the other tests computer science skills to a high education level.
If someone wants me to write a basic sorting function, then I would have no issues. But if someone expects me write an optimised quicksort function, nah.
The list of the things these Google style questions ask is big enough thath the books for these interviews is quite big. (Lots of fun to read tho, highly recommend them for people wanting to nerd out)
>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.
Well, I think I did come up with a good alternative, basic interview with work trials. You want to know how good they work, not how good they interview and the two actually are different skills.
> If someone wants me to write a basic sorting function, then I would have no issues. But if someone expects me write an optimised quicksort function, nah.
Let me be a devils attorney here. Understanding efficient sorting and how quicksort works is fundamental CS knowledge. I would say the idea is if you know how quicksort works, you should be able to write the code, no? If one is okay with writing a basic sort function but not quicksort - it could mean (1) that person does not know quicksort, (2) knows quicksort but not a good enough engineer to write code for it or (3) idealistic.
That said, I personally don't believe in testing whether a candidate can write the code for quicksort. I have however found that 'general problem solving skills' typically correlate with good engineers at places where one isn't just building yet another MEAN stack app.
> Well, I think I did come up with a good alternative, basic interview with work trials.
Not practical enough. Do you expect, in the current scenario where there is a demand surplus, for candidates to happily sign up for a trial stint - that is for the "interview" to last one or three months? I personally won't be okay with it because it messes up with a persons stability, their ability to interview at multiple places.
Even if you expect this to be AFTER the onsite interviews, like a probation period, both the company and candidate will want to maximize the # of candidates staying on, which means it doesn't really solve the problem you intended to solve.
Sorting is fundamental. Quicksort is not. It’s a single algorithm out of many.
Quick, without looking it up, in 45 minutes, write an implementation of CC-Radix, cache-conscience radix sort. It is a sort, it deals with performance, therefore it’s fundamental, right? After all, in my last Google and Facebook interviews, the questions were all about performance.
While we’re talking about performance, let’s talk about cache. It’s a fundamental part of computing after all. I tell you that you can pick any architecture you like, except one that is four way set-associative. What percentage of candidates can answer that? 50? 25? What percentage who did not go to certain schools can answer that? Of those who could answer it, how many saw this issue ever come up?
I love hardware, but these days most things are out of my control. Either I’m running on my Mac or on some VM instance I didn’t spin up.
Our field is VAST. It is a natural tendency to be biased towards what you know. Many things can be argued to be fundamental, even writing AND, OR, NOR, and NOT gates from NAND. That’s about as fundamental as it gets. It provides zero insight into the candidate for most groups.
> Let me be a devils attorney here. Understanding efficient sorting and how quicksort works is fundamental CS knowledge. I would say the idea is if you know how quicksort works, you should be able to write the code, no? If one is okay with writing a basic sort function but not quicksort - it could mean (1) that person does not know quicksort, (2) knows quicksort but not a good enough engineer to write code for it or (3) idealistic.
Companies are hiring software engineer not computer scientists. If someone wrote a sort algorithm in a normal job I would expect that not to be used and a library to be used. This is also knowledge that people who studied and aced their tests in Uni forget, because no one in their right mind writes a quicksort.
> Not practical enough. Do you expect, in the current scenario where there is a demand surplus, for candidates to happily sign up for a trial stint - that is for the "interview" to last one or three months? I personally won't be okay with it because it messes up with a persons stability, their ability to interview at multiple places.
People actually sign contracts like that on a daily basis. That is literally what you sign up for. Here is the actual process: CV screening -> Tech Test -> Phone Screening -> Interview -> Trial or "probation".
And the rest of it about people looking for jobs, well that's why companies should be selling/recruiting. The whole "but people won't do that" is clearly wrong since they already do and often jump at their first offer.
> Companies are hiring software engineer not computer scientists. If someone wrote a sort algorithm in a normal job I would expect that not to be used and a library to be used. This is also knowledge that people who studied and aced their tests in Uni forget, because no one in their right mind writes a quicksort.
Typically these questions are asked to entry-level software engineers and not ones with some experience.
Again, I don't believe asking people to write quicksort provides any signal but I was arguing that there isn't any difference between asking a candidate to write a "basic sort" vs "quick sort" in an interview.
I also mentioned this is not a good question to ask if all you are hiring for is some MEAN stack app - but is an appropriate question if you do any development where some optimization is required.
> People actually sign contracts like that on a daily basis. That is literally what you sign up for. Here is the actual process: CV screening -> Tech Test -> Phone Screening -> Interview -> Trial or "probation".
Yes, typically for roles where it is difficult to vet a candidate's skills appropriately during the interview. It is also not an improvement for Software Engineering, imo. If you ask Software Engineers if they might prefer this process over the current process, I think, most would not.
> Yes, typically for roles where it is difficult to vet a candidate's skills appropriately during the interview. It is also not an improvement for Software Engineering, imo. If you ask Software Engineers if they might prefer this process over the current process, I think, most would not.
I think you would be surprised, I am sure there are lots of people who wouldn't be interested in such a methodogly. But you need to remember what the purposal is. Do you want to be interviewed and tested on your skills in an interview and then sign a job contract or would you rather do a possible 2 day tech test. You also need to remember the job market, if I have 5 companies in my job pipeline (I stop adding companies at 5) why would I want to do 5 1 day tech tests?
Yes, its certainly an improvement over the whole-day-take-home-test. I was comparing it with the leetcode style format for junior-mid level engineers and system design for senior level. I would much rather prefer that over contract thing; and also my social bubble. Maybe I am biased.
Although, I do agree that sometimes engineers ask questions that they don't expect to work on at the company. When I interview I ask questions (leetcode style because of the nature of systems involved) based on what problems we typically solve. I never go into advanced graph etc. But good understanding of basic data structures, understanding time complexity, testing is utmost important.
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.
