flaviu1

I'd expect it to go something like this:

- There are many many languages without classes that make good use of enums

- Doing this refactoring is excessively verbose

- Someone making bold claims like this about a language feature that's never been considered error prone and been around since the beginning ought to provide some really good evidence to back things up.

There's cases where enums are good, and there's cases where polymorphic classes are good. Dismissing one of them by default is wrong, since both are useful at different times.

edit: and the citation there to Martin Fowler et al., Refactoring: Improving the Design of Existing Code doesn't even match the claim being made. That book mentions

- "The first part of this problem is that switch statement. It is a bad idea to do a switch based on an attribute of another object. If you must use a switch statement, it should be on your own data, not on someone else's." -- sure, I agree

- "Often you find the same switch statement scattered about a program in different places. If you add a new clause to the switch, you have to find all these switch, statements and change them. The object-oriented notion of polymorphism gives you an elegant way to deal with this problem." -- fair enough

This is a long way from "enums are a code smell," and honestly feels like padding the citation count. Another thing to note is that the second edition of Refactoring: Improving the Design of Existing Code says:

> Even in our more wild-eyed youth, we were never unconditionally opposed to the conditional. Indeed, the first edition of this book had a smell entitled “switch statements.” The smell was there because in the late 90’s we found polymorphism sadly underappreciated, and saw benefit in getting people to switch over.

> These days there is more polymorphism about, and it isn’t the simple red flag that it often was fifteen years ago.

I don't have a deposit banking relationship with any brick-and-mortar banks, so for me it's very convenient: I have a way to turn my paper money into electronic money.

There are some excellent multimeters around the $25 price point, like my Aneng AN8009 (especially after doing the capacitor mod)

Take a look at the reviews at https://lygte-info.dk/info/DMMReviews.html, they're very through.

On iOS, all browsers are Safari, just with different themes.

That'd actually be acceptable to me, since I wouldn't feel the need for redundancy--but it looks like the cheapest 1TB SSD that can be found is $67, while I can get HDDs for $15.88/TB. That's x4.2 the price of an HDD, definitely not practical for me.

> Data leaving their network is going to be more expensive for them.

Not $10/50GiB more expensive. They want people using their streaming services, and I'm certain they already have their call center employees using the "tired of extra fees? just buy xfinity TV"

It's anticompetitive, other streaming services just can't compete on these terms.

That's very different--that's on my own hardware, and my fingerprints don't leave the phone. This is amazon's hardware, and they store the fingerprints in a centralized database.

What would be the proper way to do something like this? I've made a couple desks myself, but I've never been able to figure out a good way to do joints.

I've generally had two choices: 5-12Mbps DSL or cable. A couple times I was able to get Google Fiber, but I'm sure you know how limited the availability of that is.

You need to take 10 minutes out of your day to remove the plastic enclosure. Depending on your setup, you may also need to make some minor modifications to the drive: google.com/search?q=3.3V+wd+easystore

The theory is that this is a form of market segmentation, where enthusiasts/companies are willing to pay more for a bare drive regular consumers.

looks like they're not: https://static.businessinsider.com/image/4f3c01186bb3f7d71d0...

> It seems to reduce the potential for security leaks

Misguided views like this are exactly how. Turning off autocomplete doesn't improve any sort of security, since the site already needs to trust the browser.

It serves no purpose other than to frustrate the user, and might even reduce security if it prevents the user from easily making use of a password manager.

Because you're immediately dismissing a whole set of thought with random anecdotes.

The only way that policy decisions should be made is with hard data. Policy decisions shouldn't be made on the basis of little girls getting stabbed by needles, just like they're not made on the basis of people getting hit by lightning.

Yes, there's circumstances where cars are essential.

Dense urban environments are not it. There's a massive set of negative externalities that cars and the mindset that people should never have to walk more than twenty feet between their front door and their destination bring. They've lead to greatly reduced quality of life in these urban areas.

> If there's anything that Fukushima should have taught us, it's that we underestimate the risk that bad things can happen with nuclear, and we overestimate our ability to engineer around those things.

From https://en.wikipedia.org/wiki/Fukushima_Daiichi_nuclear_disa...:

> there were no deaths caused by acute radiation syndrome. Given the uncertain health effects of low-dose radiation, cancer deaths cannot be ruled out.[11] However, studies by the World Health Organisation and Tokyo University have shown that no discernible increase in the rate of cancer deaths is expected[12]

So basically Fukushima has taught us that over-reacting to nuclear accidents has not yet gone out of fashion? And that even when "radiation releases exceed official safety guidelines", there are still almost no consequences to humans?

Comparing fission generation to those other things is unfair. Fission reactors produce gigawatts of power, Shoe-fitting fluoroscopes were gimmicks and the Ford Nucleon was literally a toy.

It calls you, and then you need to pick up and press the one key to authenticate yourself.

I'm not really impressed by this article. The two main points:

> An investigation by ProPublica identified more than 60 accidents since June 2015 involving Amazon delivery contractors that resulted in serious injuries, including 10 deaths

A better investigation would count the number of miles traveled and compare the rate to the general population. Driving is the most dangerous thing most people do: 37k people died on the road in 2017.

I'd like to see actual numbers here--driving is an inherently dangerous activity, and therefore needs to be looked at through statistics, not character pieces (like this article does).

> citing agreements that require them, as one puts it, to “defend, indemnify and hold harmless Amazon.”

This sounds pretty standard. However, if this is the case, then

> often Amazon directs, through an app, the order of the deliveries and the route to each destination

seems like it may be a problem. Either the contractors have the autonomy to do things like they need to to stay safe, or Amazon should take that liability themselves.

It uses a custom CPU and ISA that's specialized for the application: https://www.anandtech.com/show/14750/hot-chips-31-analysis-i...

> Internally the DPU uses an optimized 32-bit ISA with triadic instructions, with non-destructive operand compute. As mentioned, the optimized ISA contains a range of typical instructions that can easily be farmed out to in-memory compute, such as SHIFT+ADD/SHIFT+SUB, basic logic (NAND, NOR, ORN, ANDN, NXOR), shift and rotate instructions

Re. CPU cache coherency, they have a software library that automagically hides that: https://images.anandtech.com/doci/14750/HC31.UPMEM.FabriceDe...

Not exactly sure how it works, I'm not super familiar with the internals of CPUs.

Courts aren't stupid, I don't think they'd look kindly upon you if they see you've done this.

The milestone there targets a completion date of 05/01/2019 for all the attached issues, but they still haven't resolved all of them.

> The result of this training is stored in a file called "dictionary", which must be loaded before compression and decompression

The docs say that the dictionary is required for both compression & decompression.

I don't necessarily trust the adblock developers. The whitelist can say that a sitekey is only used on certain sites, but how can I know it isn't also being used on others? If sites want to have their ads white-listed, they should be less sneaky about it and just add `ad` to the class, making it possible for the users to prove that only that ad is whitelisted.

What if you want reproducible random numbers, such as in, I dunno, AES? That limitation would prevent any sort of decrypting things.

No, they are on the same heap since the GC isn't a moving collector.