Readit NewsDead Comment
Dead Comment
Dead Comment
My paranoid 4 glasses of wine self can believe nothing other than money being involved.
What is with all the Zoom hate? The company have been around for a decade, enjoyed relatively mediocre success until the outbreak of Covid, and suddenly apparently since they're experiencing huge demand and press coverage, every man and his dog is finding reasons to write a blog post complaining about them.
I've read some article splitting hairs over the nuances of "end to end encryption" and how Zoom is so horrible, evil and wrong because they, like almost every telecommunication provider under the sun, can intercept your calls. What makes Zoom so special?
What's driving all this hate? Because it's a far more interesting question than what technical flaws Zoom, or any other product in this category, almost certainly suffer from.
Has someone done any security analysis of Houseparty? It's experienced surge growth in the same period. But in the time I've seen maybe 20 Zoom-hate articles on HN I haven't seen a single mention of Houseparty. What about Google Hangouts: is it "end"-to-"end" "encrypted"? What about its recording feature? Where are the articles? Where is all the hate?
Why?
> print vs print() is what I think the parent comment was referring to.
as another person mentioned is likely what you meant, but it was easy to take your comment as meaning that you had mismatched parens somewhere, which would imply broken python2, as well as 3.
> * given a tool that promises to cease functioning 'correctly' at any future moment based on its own whim, preferences, industry fashions and styles, in an ecosystem where many similar such tools exist that explicitly promise not to cease functioning over the same time period, it is a fool's errand to pick the tool that promises to externalize additional costs on the user when alternatives exist that avoid any such cost.
This is clearly a falsehood, if the tool provides additional value. To bring things back to the topic at hand, if C++ were allowed to break ABI compatibility in very specific ways, it could be faster. stl container types are slower than many third party ones (absl, for example).
Which is to say that if you want "the best" that C++ has to offer, you have to be willing to have your libraries make backwards incompatible changes.
To jump back to python,
> given tool designers who externalize almost frivolously minor technical costs on to every user, where each 'minor' change is amplified perhaps 10000 times over and directly translates into expensive engineering time
I disagree that this happened. The examples you give are trivially fixable with 2to3. There are harder problems that 2to3 doesn't solve, but it sounds like you don't have any, so the frivolously minor technical costs are frivolously minor, and translates into running `2to3 my_code/` one time, to fix all the missing parens and most of the moved functinos.
> bash that continue functioning to the present day
I have yet to encounter a 20 year old program written in bash that functions to this day. It might be syntactically valid, but it won't do what it intended to do.
You're welcome to absorb all the externalized costs your heart desires, but in future please consider reviewing HN's rules before bandying attacks like "smug" and "superior".
There is a fabulously unending depth to explore in the chasm lying between these opposing world views. It would be more than possible to write a book on the topic and fail to cover it all, however here are some of the most important aspects, from my perspective at least:
* given a perfectly functional tool relied on heavily by its user to perform their job, and given that tool suddenly decides to change shape such that it no longer fits the user's hand without retraining, nor fits with the remainder of the user's toolset, including custom tools the user has invested in producing, the continued utility of the no-longer-functioning tool is called into question, along with a deserved reappraisal of the tool's applicability in the context of the user's original intended problem domain.
* when the reason for its reshaping is to solve what are highly important problems from the perspective of the tool, but much less so from the perspective of the average user, and that user's application of the tool to real world problems, it can no longer be said that the tool is simply an implement that may be called and relied upon at any point in future -- the tool develops a chaotic life and importance all of its own, and may choose to reshape once again at any future moment (and indeed in this case it has). It is no longer a tool, but some sentient entity demanding unpredictable ongoing costs and attention paid all of its own.
* given a tool that promises to cease functioning 'correctly' at any future moment based on its own whim, preferences, industry fashions and styles, in an ecosystem where many similar such tools exist that explicitly promise not to cease functioning over the same time period, it is a fool's errand to pick the tool that promises to externalize additional costs on the user when alternatives exist that avoid any such cost.
* given tool designers who externalize almost frivolously minor technical costs on to every user, where each 'minor' change is amplified perhaps 10000 times over and directly translates into expensive engineering time, the question is easily raised whether the philosophy of the tool is appropriate for its advertised utility, and whether continued reliance on the tool makes business sense. In economic terms, what was the cost to productivity of the retraining and re-tooling of users compared to any alleged future productivity improvement?
* had I written these scripts in bash, C# or C++, they would not have broken even remotely to the same degree. Of course these are not some completely unevolving entities either, however all take the promise of forwards compatibility deadly seriously, and it is more than possible to find 10-20 year old programs written in C++ or bash that continue functioning to the present day. From my perspective, they are therefore excellent and highly dependable tools.
Utterly pointless and reputationally ruinous. I don't do serious work in Python any more
https://www.worldometers.info/coronavirus/ (trust it if you like) says that the USA has (as of 2020-04-05T15:13:00Z) had 9,119 deaths- and I was going to say 8,486 but I refreshed the page and it jumped to 9,119 because of course it did.
9,119 / 0.33% = 2,763,333 infections.
9,119 / 1.33% = 685,639 infections.
But, we also have to consider that death isn't instant- so add in everyone who became infected in the last 5-10 days. That'll be a bigger number. The reported number of infections because of limited testing is 320,828.
I think it's not unreasonable to say that probably 1m Americans have now been infected by this virus. And the longer ago this comment was made, the more likely that estimate is correct.
Edit to add: I trust the number of deaths more than the number of infections because it's easy to say "don't come to the hospital to get tested if you don't need to" but it's hard to say "let's pretend that dead body died of something else".