2,891 karma · joined July 30, 2011
But, of course, voting by mail is even worse, and most of the US seems to not care about it a slightest bit.
Having the whole project - design, architecture, all implementation details - in one head is not a trivial advantage. Even ignoring communication overhead, there might be subtle duplication of code simply because different people choose to do similar things in slightly different ways.
While the ratio of Rust to Python code kind of matches my expectations, I wonder how much of it might be due to the difference in team structure vs the difference in chosen language.
Then the choice is also simple, and it sounds way better than fining or prosecuting accident victims.
E.g. maybe you had a class 'Box' with a field 'area'. Later you added fields 'width' and 'height'. What are you going to do? Change 'area' to 'getArea()' and break the API? Write extra code to ensure that you update area every time you change width or height? Or write a getter that returns width*height?
I'd say getter is the cleanest option in many cases.
If you prioritize performance over maintainability, you're sacrificing long-term correctness, which is supposed to be your #1 priority.
PS. Also, "C++ Coding Guidelines"? This is neither coding guidelines, nor anything specific to C++.
Huh? It takes years before developer starts writing C++ code that does not blow up in production. Even with JavaScript or Go it takes months to start writing reasonable code (as opposed to something that just seems to work). What are you comparing it to?
https://en.m.wikipedia.org/wiki/Monetary_reform_in_the_Sovie...
They are equally easy to stop (simply standing in the road works just as well) and are even easier to take control of (one can always put a gun to driver's head and ask him to hand over the keys - thieves won't be able to pull this trick on a robot).
Here is a Wikipedia article (in Russian): https://ru.wikipedia.org/wiki/%D0%95%D0%B3%D0%B3%D0%BE%D0%B3...
On the other hand, I agree that preventing sharing of public domain works runs counter to the mission of public museum and, while legally entitled to, they probably shouldn't exercise their copyright in this way.
My go to solution for this is libwebsockets. Balde seems to have some nice features, but SCGI + external webserver requirement makes it difficult to embed. I'd also question whether GLib is a reasonable dependency for HTTP microframework.
PS. There's much more info about soda machines in Russian version, and lots of cool graphics too:
http://gazirovka.15kop.ru/machines/ (scrolls horizontally, in case you haven't noticed)
Say, your app depends on libraries foo & bar, and both of them depend on baz. Say, foo is bundled with baz v.1.1 and bar is bundled with baz v.1.2. If you used package manager you'd get baz v.1.2 and everything would work fine because baz 1.2 is API compatible with 1.1.
However, it does not mean you can use them interchangeably! If you pass an object created in baz 1.2 to baz 1.1 things might break because internal implementations of the two are different. Even having two instances of the same exact library may not work - e.g. if that library keeps some sort of internal cache.
NPM must be fixed so that packages that we depend on can't just be unpublished. Bundling everything together is not the right solution.
(1) There are clever hacks to mimic this behavior to some extent, but I don't even want to go there. If you really want this feature - just use a language that has it.
So, you pass file name to your data access library and the file is not there. How are you going to deal with it? Write an error to the log nobody reads and call terminate()? Create a new file and let users guess what happened to the data they expected? Or return an error code?
If you picked the last option (as most people do) - well, bingo, you've just put your error handling far from where the error occurred. The only difference with throwing an exception is that now every function up the call stack needs to check that error code till it reaches the place where you can handle it or, even more likely, till someone forgets to check or chooses to ignore it. Because, unlike Go or Rust, C++ compiler won't help you there.
Error codes don't undo I/O either.
As to "which functions can throw" - let me suggest a simple rule: every function can, unless you can prove otherwise.
Look, there are situations where it makes sense to avoid exceptions, but not for the reasons you listed. Exceptions are the least evil way to handle errors in C++. Google style guide bans them mostly for historical reasons, let's not cargo cult it.
We've been through the same exact arguments years ago, only then it was about things like std::string. Oh, no, it allocates dynamic memory behind the scenes - there are systems that don't even have heap! As a relic from that era some popular libraries still use their own string classes.
I'm not sure where to draw the distinction between a language and a platform and I don't think I care. Those additions will make C++ way more useful, libraries will become more composable, binaries smaller, and life will be easier for 99.9% of people who use C++. So, I'm glad they finally dropped the lowest common denominator approach - we've been making our own batteries for way too long.
Seems like C++17 finally resolves this. We only had to wait 34 years :)
So, contrary to what spicyj is saying, to me it seems to create the most confusion in the long run at the expense of addressing some short-term concerns ("people already call it React 14"). I'd much prefer they switched to 1.0.
Say, you have app v.20150701 running in production. Today you deployed new version and it ran migration script against production DB. Two days later you discovered a critical issue in your new version and are forced to roll back to the old app. Now, your 20150710 app opens the database and notices that it has 20150811-oh-we-did-something-to-the-db.sql migration applied. Can it use the database or should it fail/downgrade the DB? How do you tell if all you have is a timestamp and description?
IMO this is more important than solving branch merges because it helps me when my production system is down and there's pressure to bring it back online ASAP. Merging branches can be done offline in the cozy comfort of my development environment.
PS. Of course, the above scenario might be more or less relevant depending on your development and deployment workflows.
I prefer to use two integers: major & minor version, semver style. Minor version gets incremented if old code can still use new DB (e.g. when adding a column). Major gets incremented when the change is not backwards-compatible (e.g. when renaming a column).
When you have to rollback a release not having to downgrade the DB can be a major time saver.
To create the whole map on the fly using JavaScript - try mapbox-gl.js [3]. You should be able to pass your location boundaries via mapboxgl.GeoJSONSource (and then you probably don't even need MapBox API key - haven't tried it, though) and style it like this: https://www.mapbox.com/mapbox-gl-styles/styles/bright-v4.jso...
PS. If you decide to host your own tiles - remember that browsers limit the number of connections to each domain. Your map will load much faster if you serve tiles from several different domains, e.g. tiles1.example.com, tiles2.example.com, etc.
[1] TileMill - https://www.mapbox.com/tilemill/
[2] Leaflet - http://leafletjs.com/
[3] MapboxGL - https://www.mapbox.com/mapbox-gl/
This is absolutely what's going to happen if such system is implemented.
Appearing to delegate one way, but having their votes counted another way? Seriously? It is way too complicated for an average voter. Even if you implement some sort of plausible deniability scheme (so that aforesaid someone can't just login with your credentials and set it up the way they want) - imagine explaining plausible deniability to a 90-years-old grandma or some uneducated farm worker, or a drug addict...
Elections are rigged this way even in countries with supposedly secret votes: bad guys might ask you to prove your vote by, say, snapping a picture of "correctly" filled ballot alongside your ID, but even that is not necessary - enough people will do what someone with power tells them to on a vague threat "if you try to fool us we will find out", or because it's a "patriotic" thing to do, or simply because they are told to and don't know better.
Not to mention that a huge number of people just couldn't care less. Half of population simply don't show up at the polls. How many of them will simply sell their right to vote for a token sum of money?
The current system is bad in many ways [1], but this proposal is even worse - way too much potential for abuse.
[1] Some reasons why - http://en.wikipedia.org/wiki/First-past-the-post_voting
If it indeed took 12 years for the algorithm to appear, it's likely because finding loops in a linked list isn't a very common problem, not because the algorithm itself is that hard.
This is what should be driving Mozilla's decisions, not the moral aspects of charging for revocations.