bcheung

Not inside of useEffect.

Overall I think React hooks are an improvement. My codebase is usually shorter and there is a lot less typing involved.

But hooks creates abstractions the developer needs to deal with that never existed before.

Hooks are not functional because they break referential transparency of functions.

You have to track dependencies manually and hooks are more difficult than they need to be for the "componentDidMount" equivalent. If you don't get the dependencies just right you end up with things not firing or in infinite loops.

You have to wrap your functions in "useCallback" or "useRef" just so the reference doesn't change and cause infinite loops.

You can't create abstractions where a hook calls another hook. So you end up having to inline a bunch more code into your function rather than outsourcing it into a helper function.

The positional order seems like it would be easy to work around if they allowed you to pass in a key. Not sure why that isn't available.

Not sure what you mean but Amazon is doing a lot of research into things like drone deliveries and robotic vehicles which can be powered from renewable energy.

Fuel costs money. Ultimately delivery efficiency is better for business and for the environment.

They also are encouraging all deliveries to happen on a given day of the week so they can be batched up and logistically planned better.

Seems like things are moving in the right direction.

Bummer, I've been curious about learning it.

I think it depends a lot on previous experience, what type of thing you are developing, and your tooling. I'm very comfortable and happy bouncing between C# in Unity, React and JS, and Haskell for more CS / intellectual curiosities. For me it's more about fit and choosing the right tool for the job.

All things being equal I prefer something like Haskell because it is very clean and expressive. But I hate excessive types when you are dealing with generics 3 level deep or when you have these funky type signatures dealing with monad transformers. It's just too many layers of abstraction that takes you away from the actual data / parameters.

When I'm writing something small I find typing slows me down. But when writing something bigger, working in a team, or working on a codebase for a longer period of time the typing acts as documentation. Typing something and having Intellisense tell you what is in a class is extremely helpful. Otherwise you have to jump to the file or look through documentation.

For me it's less about the errors it catches and more about the time saving of not having to read through code that I am calling in order to understand what I need to pass to it.

In general. strong typing is great when you are working with other people's code and 3rd party libraries, but excessive overhead when you just want to experiment and crank out something small.

> what's left of F#

Has it been abandoned? What did you mean by this?

I'm supportive of this. Children should not be held accountable for "the sins of their parents". My parents started charging me rent when I was 18 and told me I had to pay for college entirely by myself. I don't see why their income should be held against me.

I generally prefer FP style for most things as well, but sometimes FP can be taken too far.

Trying to understand type signatures that are 3 lines long with nested class types/generics and getting your code to fit into some kind of monad transformer pipeline can get confusing very fast.

For problem domains where you have a lot of state that is shared all over the place (like trying to implement a vector editing program, electronic schematic editor/simulator, or game development), I find OOP models easier to work with.

Monads can be used when you have shared context, but then your code gets constrained and a bit unnatural; you have to worry about Kleisli composition, endofunctors, and plumbing things into and out of the state monad. Yuck.

FP is a tool. OOP is a tool. Know their strengths and weaknesses and when to use each. Yes, you can work entirely with a single paradigm but IMO you're handicapping yourself by doing so.

If it was feasible for companies to manufacture in the US they would. Effectively blocking China without a concomitant investment in US manufacturing is a lose/lose situation.

Tied to the engine is orthogonal to tied to the language. You can compile C, C++, and Rust to WebAssembly. But you still can't compile JS to WebAssembly.

Given the large amount of code in JS and the number of JS developers, not being able to support a major general purpose language rules out WASM as a cross platform target in my book.

C# is the largest language for sure but it was designed for multiple languages from the start. There are things you can do in CIL and other languages that you can't do in C# even. Functional languages and pattern matching can be expressed quite well in .NET which aren't in C# (at least not yet fully).

I think the statement that the CLR ties you to C# is not justified. Can you elaborate why you think this is the case?

Also, WASM is not tied to JavaScript. You can't even compile JavaScript to WASM because it doesn't support the necessary primitives. In fact other languages that are completely different than JavaScript compile to WASM much easier.

I'm a full time React developer but I would much rather see the CLR than WASM as a universal platform target.

The CLR already supports a larger variety of programming languages from dynamically typed languages like Ruby and Python, to C#, to F# for functional style programming.

It already exists with a rich ecosystem of libraries. The tools to generate CIL opcodes are pretty good and the developer tools with Intellisense are pretty good as well.

It has good packaging support with assemblies. And you can already compile .NET code to WASM using Blazor.

And with .NET already running on Linux, Win, Mac, iOS, Android, and IOT devices, I don't really see targeting WASM adding anything that doesn't already exist.

That's largely the belief system that is behind Google, Facebook, YouTube, etc being banned in China.

Why does academia still tolerate the archaic scientific publishing world when there is the Internet?

The fact that people are still so dependent on these useless hegemonies sickens me.

It only takes a little bit of courage and everyone else will join. Scientists are only keeping themselves captive by playing along.

So what's the alternative to not using CDN's for those of us who don't have 100% of our customers in or near Germany?

Love how the probability distributions are presented. I wish those diagrams were in the material when I was first learning probability. Would have communicated the concepts so much faster and easier.

The website lets you pay $0 for tip so you can tip in cash. I haven't found a way to set the tip in the app. Unfortunately, the website is much less reliable than the app and frequently has issues.

What is this for and why would someone want to use it?

There's basically nothing on the website but the API. No decent overview or tutorial or even why someone would want to use this project.

Amazon cardboard boxes have so many uses from Maker projects, to mulch, to shredding and sticking in the compost.

> Apple said the update does not require any user interaction and is deployed automatically.

I think this scares me just as much. #singlePointOfFailure #rootKit

It also strengthens the ability of people to get along despite having opposing views and philosophies.

When you insulate people and teach them to be offended at the slightest "micro" aggression, then people become intolerant and unable to function in normal society without being "triggered".

This makes sense to me. The question to me is should platforms like Twitter, Facebook, YouTube, etc be subject to common carrier laws / net neutrality laws? The Supreme Court has repeatedly ruled that hate speech is protected as free speech.

"Hate" is also very subjective as well. If it is controversial even in the slightest, then someone, somewhere, is going to be offended and think it is hateful.

Apple has a history of really bad design ideas in my opinion.

Anyone remember the older Mac towers. Whose bright idea was it to stick razor sharp edges on the handles to pick up a 30 lbs box?

Or requiring people to use a metal file on their MBP so they aren't resting their wrists on a razor sharp edge.

Several years later, it is still a pain having to use dongles to plug in USB devices.

Now give us back the escape key too.

5) High-contrast motion graphic ads right next to what you are trying to read.

Even if the OS supports it, many apps still write their own UI primitives and won't scale with the OS scaling, or when they do, it's not uniform so the text is either obnoxiously huge, or the UI affordances are way too small.

Working with a larger screen without scaling makes this problem go away. I personally have 2 x 4K monitors at 32" and find it quite ideal.

Which IoT devices does this affect? Is it just devices that run Linux and have an exposed SSH? Wondering if things like the Particle.io / Obniz / ESP8266 are affected.

Realistically I hope they work solidly through USB-C. I'm tired of piling up expensive high quality monitors I can't use because they keep changing the connections every 3 or so years.

And they really need to have larger displays 30"+ for anything 4K and beyond. There's not much point to a 27" 4K monitor if you have to double the scaling just to read anything. 8K at 27" would be a complete waste.

Wow, those screenshots bring back memories. Used that same exact IDE to make games when I was a kid. It was an amazing time to be programming.

Is the motivating idea behind this that patients can demand the same price that insurance companies are getting and ultimately lessen the monopoly insurance companies have? Maybe even just get much cheaper insurance for true emergencies and pay out of pocket for everything else?

For me it's understanding how a CPU works at the lower levels. Seeing complex functionality arise from such simple things like transistors is quite amazing.