This article recommends instead a STAR voting system which is still simple to implement and understand while not electing extremists in some cases. I would be sad to see NYC and others turn to ranked choice without considering all the alternatives.
In the real world, moderate candidates (green in the example) get more support/votes than extremists so it’s unlikely they would get the fewest first place votes. Also, if green is only able to get a tiny sliver of first-choice preferences, I don’t think they should be elected, even if they are in the middle of the 1-dimensional spectrum.
This is quite reductive and ridiculous, people don't measure their difference from a candidate on a single axis and vote for the person with the smallest distance.
> people don't measure their difference from a candidate on a single axis and vote for the person with the smallest distance.
Good news, that's not how it works. You are minimizing the distance in a hyperspace, not a single axis. People draw a singular axis (or two) to simplify and explain the concept. But still, the distance is measured in a hyperspace.
I am generally an RCV fan, but I think you're writing off this critique a bit too quickly.
Even with multiple axes the critique is still correct right? And I think (far from an expert) that there's decent evidence to support hotelling's law and median voter theorem.
No, it is how much they like a candidate on a certain topic and then they consider all topics, which are weighted. But also the distance measurement of voting systems aren't in reality a single axis. So this doesn't really matter anyways because it is already accounted for.
Thinking about this decision just as a performance one disregards the fact that the code is substantially different. It does seems likely that one way is more intuitive / easier to work with than the other, I wouldn't know which though.
It depends on the probkem younare trying to solve with your GUI, I suppose. Sometimes, it is better to just recreate the whole GUI to adapt to a model change (e.g. the user moved half of the tree nodes somewhere else), sometimes it is easier/faster/... to just update the existing GUI (e.g. update the text of a label inside a complex dialog widget).
It seems a bit premature to claim high performance without having a story for memory. I'm sure ocaml, swift, and basically all languages that do any type of runtime garbage collection would be significantly faster without it.
That's a fair comment. I will say however that the references to performance are more an attempt to keep it in mind from the beginning, rather than being an assertion at this point. I only began working on it shortly after my mom passed away last month (it's dedicated and named after her), so at this stage I'm mostly goal setting and rapidly prototyping.
I hope you can take time to give it another look when its further along. Thanks!
It's complicated. The best runtime GC nowadays tends to take on some of the performance characteristics of a stack, including that finding a new memory slot is O(1). Heap allocation in many non-GC languages, by contrast, ends up involving some sort of relatively gross search for free memory. The same mechanisms also mean that, if you aren't doing anything in particular to manage your memory layout, the GC language is likely to achieve better locality of reference at run time.
This isn't to say that better performance isn't achievable in languages with manual memory management, but doing so often requires a special effort that just isn't going to happen most the time, for reasons of practicality.
I think the point was that you can make memory allocation very fast if you do not care about ever freeing memory, but obviously that is not exactly sustainable strategy. So that is why making claims about performance before figuring out memory management story is bit premature.
I author a module for my employer and describe it with their developers@ email and as UNLICENSED; how does NPM discover that I am legally authorized to use and modify this package?
It was surprisingly easy to learn - I found the capabilities system rather intuitive compared to other methods for safely managing data races. Also the syntax is really simple and easy to read!
Code generation is one way to get around generics. Go also stores all the type data at runtime so you can inspect the arguments passed to any function, which gives the same kind of generic behavior in any dynamically typed language.
So you definitely could implement an ORM in go without code generation - it's almost certainly been done.
They did not switch from a postgres instance to put all their data in a mysql instance. They switched from a single postgres instance to shard their data across many mysql instances. This an entire reworking of the architecture that is completely ignored in this powerpoint.
Honestly I think Uber switching was more of a business decision as their employees had trouble figuring out how to properly use Postgres. Instagram definitely has different data needs, but is probably much bigger than Uber wrt data. They use Postgres successfully via Django no less!
As someone who participated in this transition, I don't think that was a part of it. The new database layer took quite a bit of instruction to use properly as well, and there were plenty of people misusing it.
