lsadam0

Discussing improved hurricane protections is shifting the conversation to addressing symptoms rather than root causes. The conversation thread starts with the assertion that the US will be unable to take climate change seriously until a major city is lost.

While you make fair points, you're not disagreeing with general trends. Democrats have made moves to address emissions, while Republicans are struggling to admit there is even a problem. We do live in a Democracy, and politicians do have to work within the reality of what can be passed. The general public is the problem. Until the public has a strong appetite for addressing climate change, no meaningful change will happen. Any leader making bold moves prior to that is just going to be voted out. The scary conclusion at the root of this thread is that the public will lack that will until a major city is lost.

Obama’s “War on Coal”: https://time.com/2806697/obama-epa-coal-carbon/

Trump ran on and has tried to revitalize the coal industry: https://www.bloomberg.com/news/articles/2019-06-18/trump-s-b...

The first step in solving our problems, political or otherwise, is being honest about them. No matter where on the political spectrum you fall, every voting American knows that one side has pushed the idea that climate change is a hoax while the other has been trying to take action.

I’m not sure what the motivation of your question is. Proving that democrats have attempted action while the republicans have chosen to ignore science, is such low hanging fruit that I’m a bit baffled.

Thanks for the detailed reply. There’s lots here I had not considered. I’ve realized my overloading implementations have been rather simple cases.

Why do you think function overloading is messy?

To me, the fundamental issue isn't that CSS is hard, it's that CSS is just not interesting.

AMP has always and will always be a garbage idea. Stop implementing AMP.

I had already forgotten about the Trump administration's attempt to slash the ARC. That would have been a huge economic hit to Appalachia.

There's something you don't understand about Kentucky: The huge economic divide between Eastern Kentucky (Appalachia) and the rest of the state. Appalachia clings to being a coal based economy, and it's been failing them for decades now. According to the state Government, as of August 2018 the unemployment rate for Eastern Kentucky is much higher than the national average at 7.8%: https://kystats.ky.gov/kylmi/index/

Taking the state wide average masks how bad things are in Appalachia. Eastern Kentucky cannot catch up to the rest of the state until politicians stop lying to them and lay bare the sobering reality: Coal isn't coming back.

> What does that have to do with the article?

I'm from this area of Kentucky and the fact that it went for Trump has everything to do with the subject.

I'm 36 now, and coal has been in decline for almost my entire life. Yet the area cannot move beyond it because they keep waiting for 'coal to come back'. Politicians come and lie, and say they will return them to the glory days of coal. Trump came and told the most brazen, unrealistic lies of any previous politician. And so the state went for Trump.

Coal isn't coming back, and Appalachia cannot accept this. Until they can accept this and move on, Appalachia will always be impoverished. Sure the rest of the country is having economic boom times, but Trump made Kentucky worse.

I will say your take is reasonable, but on projects I manage I still push for usage of const/enum in these cases.

It sounds like you really just disagree with the example given, not necessarily the rule itself. You're arguing that `isAdmin()` might require a different implementation in a difference scenario, but you have not made a case that the string "admin" should not be constant or enum.

I honestly cannot think of a reasonable argument for why constant values should not be in static constants or enums. For one, why would you want to re-type the value over and over? And two, it only takes one typo in one manually typed value to introduce a frustrating bug! It's such an easy bug to avoid and costs almost zero to do correctly! Honestly, devs manually typing values that are effectively consts is one of my biggest pet peeves, you're just creating easily avoidable problems for yourself and your team :).

> Not really, I ignored most of that 3rd book technobabble because it was unphysical

I think this is the basis of our debate. I can totally understand why many people did not like the series. The author at times drags the reader through multiple chapters of details that feel as though they have nothing to do with the story. They don't even feel like world building. Honestly, I had a really hard time with some of those myself. Especially the first few chapters of books 2 and 3. However, in the end all those asides really matter to wrapping up the story. Is that good storytelling? I don't know. I rather enjoyed it though :)

But yeah, the last 25% of the final book is full of technobabble, but that babble is pretty important to wrapping up the story and understanding the motivation of each civilization.

Which Sci-Fi book or series of books would you say are the best?

* More Spoilers *

> But we're not an ant colony to them

Tri-Solaris technologically stomps humanity throughout the series. Humanity was ignorant of the dark forest, and Tri-Solaris knew that. Further, they're able to suppress the Sun's broadcast capability. From their vantage point there was no feasible way for humanity to become aware of the dark forest. Their misunderstanding of humans is a central plot point. By every single measure Tri-Solaris had the advantage in a massive way.

> Why? They have their stealth probe

It was not stealthy. Humanity literally saw the probe pull ahead of the fleet and knew the probe was coming 50+ years before it arrived. Sometimes hiding behind an asteroid or planet is not stealth.

> They were destroyed because their coordinates were broadcasted.

No, the Tri-Solaris civilization still existed near the end of the universe. Their planet was destroyed, but they lived on as a space faring species.

> How? They aren't any less stealthy than sattelites, tv, or radio.

Do you recall what light-speed capable ships do to the fabric of the universe?

Spoilers Ahead!

> betting their existence on a species they knew already uses MAD

If ant colonies depend on MAD for continued existence, it means nothing to us. This example was used multiple times throughout the series. They didn't even make a singular bet on Earth. The invasion was just one avenue they chose for survival.

> You don't have to invade a system, you can send a stealthy probe.

In the dark forest of the three body universe you could send a probe, but you learn nothing if it finds no life in a system. The only reliable, actionable information a probe can provide you is if life is found. Finding an absence of life just as easily means that the life in the system is so far advanced beyond you that you cannot detect it. It would be far riskier to bet your future on a system in which you found no life. Not to mention that you are making a huge gamble on the stealthiness of said probe. The probe could be the very thing that makes you the target of a dark forest strike. Earth already appeared safe, so why take further action that carries real risk of notifying some other civilization that you exist? You can't be reliably stealthy because some other race can be technically beyond you.

> Send a big meteor

Earth was an un-imaginable eden to Tri-Solaris, it's made clear that they wanted the planet intact.

> or make a deadly disease that looks like flu

This requires a much longer timeline as multiple trips are required to carry out the plan. The Tri-Solarans were facing a very real threat of extinction that made a shorter plan worth the risk. It's made very clear that they did not wish to exterminate humanity.

Earth was valuable because in all probability the rest of the universe did not know it existed. Given that you are saying they were stupid for not building space habitats, you must not be aware of what actually happened to the Tri-Solarans :). Besides, those space habitats present their own form of danger to their inhabitants. Actually, the danger they pose is worse than existing on a planet.

I can understand why you say Three-Body has a rather traditional solution, but I would argue said solution is misdirection. The first book is really just setting up the real meat of the story, in the 2nd and 3rd books.

Invading our Solar System was worth the risk for Tri-Solaris. Because of the Dark Forest nature of the universe they could not just pick a star where they thought there was no life, as life there could just be especially good at hiding. When they found earth they found a luxurious planet containing a race which was ignorant of the true state of the universe and technologically incapable of doing anything about it anyway. On top of all of this, our solar system was very close by :). Their own star system was hellish compared to ours, they needed to leave.

The final book in the series does a good job showing why Earth was a good option for them. Tri-Solarians knew far more about Earth than they could reliably determine about most nearby star systems.

Ah, thanks for the clarification. At first I thought this made it through the actual release process.

I mean sure, the turn-around time is great...but how did this pass review in the first place? This should never happen in a reasonably managed project.

I don’t really disagree with what you’re saying. I realize my viewpoint on this topic was Very selfish. But that is why I pointed out that we all get to vote with our money.

I can understand how having a touchscreen helps with mobile development, but I have no use for touchscreen functionality in my development. I don't have a desire for my macbook to have a touchscreen at all. Further, I think the touch bar was a huge mistake. I've really gotta side with the idea of letting a desktop/laptop excel at being a computer rather than suffering from an identity problem.

All that said, we all get to vote with our dollars :)

> ...a single hardware spec and a dedicated OS just for that platform. Without regard to backwards compability in OS, like BeOS at the time.

I would argue the closest mainstream machines currently available that meet this requirement are Macs and iOS devices. Sure, there's a handful-ish amount of different configurations, but they do not vary greatly. Backwards compatibility certainly isn't much of a concern in macOS.

It caught my eye that you said 'book' rather than 'books'. You might not be aware Three Body is part of a trilogy? If you've not read The Dark Forest and Death's End, you are in for a real treat.

I don't think The Martian and Three-Body should be compared. I think it's fair to say that The Martian is more 'hard sci-fi' in that the story is more grounded in what we know to be true. Three-Body has to invent some ideas in order to finish it's story.

That said, I overall enjoyed Three Body more. Even if it did push me into an existential crisis of some sort.

Ah, +1 for your point about the poor documentation.

Thanks for taking the time to clarify, and thanks for the original pros/cons post. I'm currently working on a mid-sized MVP project that is standard ES6 + Flow. I've recently been exploring our options for migrating to TypeScript or something like ReasonML. I've worked extensively with TypeScript, but am only starting to dip my toes into other options. You've been more helpful than just reading the documentation :)

I'm going to blame any communication breakdown on the fact that I know nothing about ReasonML or React-Reason. However, the point of having to store state so you have something to compare against strikes me as a really odd choice for the React-Reason library to introduce, since it deviates from the functionality of React itself.

I was curious enough to glance at the React-Reason doc's and they say that `shouldUpdate` is passed a record called `oldAndNewSelf: {oldSelf: self, newSelf: self}`. Does that not have what is needed to implement the method without extra storage? For example, in standard React `shouldComponentUpdate` is passed `nextProps` & `nextState`, and since the method is in context of the previous render, we have everything we need to make the comparison without explicitly taking extra steps to store previous/next.

Maybe we are saying the same thing in different ways, I seem to be pretty good at that :).

There very well could be something I'm not understanding. What you are describing still sounds like standard React.JS behavior. Unless you use a PureComponent, or explicitly implement your own `shouldComponentUpdate` method, then `shouldComponentUpdate` will always resolve `true`.

> shouldComponentUpdate is hard-coded to `true`

As in you can't override it? `shouldComponentUpdate` resolving to true in the absence of a custom method or PureComponent usage is standard React behavior: https://github.com/facebook/react/blob/7350358374036c0834ea6...

I could not agree more. If my first visit to a website includes this popup asking to show notifications, my opinion of said website is instantly lowered.

Give me a service that makes me want to opt in, something I need, and then you won't have to ask me to show notifications, I'll be asking you.

Rent control and difficulty of new development are problems that need to be addressed. However, AirBnB is absolutely part of the problem. The existence of multiple causes is no reason to dismiss an individual cause.

> I really don't like state machines because if you need to add a new event, each of the states need to be updated to handle that event. If you add a new state, you have to figure out how to handle each of the transitions from other states

You still have to do all this without state machines, but likely in a less organized and harder to maintain way.