sethc2

That seems like a pretty good algorithm.

My feeling is the author seems pretty open to criticism.

You should open a PR incorporating your reasoning into the document. Be respectful but make it better. I'd hope the best ideas would win out but then again the author has the authority to merge or not.

To the author maybe you should give one other person you respect whose opinion differs from yours the ability to merge PRS as well. Maybe...

Glad to see this no longer appears to be flagged. I'm curious if anyone knows what HN's process is for unflagging an entry. How do they decide what remains flagged?

Not sure. All I know is I saw the article on the main page, navigated away and when I came back it was gone. I searched for the title and then found it but it was flagged.

I was thinking of sharing on Facebook but I'd probably get banned, even if i still feel we should probably keep the lockdown for a little bit longer, because apparently the moral authorities have decided it is off limits to suggest we should end the lockdown or even discuss whether we should.

Why was this flagged?

I don’t even necessarily agree with the author’s arguments and conclusion, and honestly I have no clue what to think with all the information I hear that is constantly changing from the various tribes. But when something gets flagged simply because he advocates for ending the lockdown, I go from thinking the lockdown is probably necessary and trust the decision is made for reasons I don’t understand, to thinking like the paranoid conspiracy theorist that this is just a totalitarian power grab, and figure the need to suppress dissent means that it is more likely his position is the right one. If the ideas he is presenting are so stupid then people can decide that for themselves and don’t need some moral busybody protecting us from thinking for ourselves by flagging anything that states the opposite of what their tribe thinks is true.

Yeah the stuff I was doing was more to see how crazy of things we could do with the type system. Like I said just fun. But probably a waste of time other than the learning. Just a warning that is tempting to do crazy (but stupid) things.

One kind of weird thing we did, was we had these JSON Schema definitions that were const, so all the strings like "type" were of a literal string type. Then using recursive type definitions, and the `extends` key word we were able to extract the actual shape of the data into a type.

Not exactly that useful, compared to typing it out, but it was still kind of cool.

Oh one other potential drawback.

Typescripts inferred types, can do some crazy things, and can be very powerful. This to me is really fun, but has definitely caused me when I first started using it to get lost in having fun doing crazy things, to ensure my strings were exactly some set of values depending on what some other value was, when a simple unit test and a simple "string" type, would've been a lot quicker and less confusing.

IMO, Yes (usually).

Let me elaborate.

If you are starting a new project, yes use typescript over JS. And configure it with all strict options.

This doesn't magically give you well architected and well-tested code, it still takes a good engineer to do that. But what it does allow is for the engineer to refactor the code to support new functionality with more speed and confidence, rather than shoehorning it in in fear of breaking something or it taking too long. Furthermore, as people join your team, it will be a lot easier for them to figure out where some piece of data is coming from and how the code flows from one spot to the next.

If you have a massive JS project and you want to convert it to typescript. The answer might be no. Oftentimes when people port a JS project to TS, they end up using non strict typescript, and you get the syntactic overhead of writing TS, without really any benefit because nearly everything is any typed. If your only concern is a better codebase, and it doesn't matter how long it takes, then sure it is worth it, but we all know that is never our only concern. It still might be worth it, but I can almost guarantee you from experience, you will still end up with TypeErrors in your console at some point, because people will have just any typed things.

Also if you're writing a tiny node script in a single file, to do some simple operation, then no it is probably not worth setting up a command to compile it and a tsconfig to configure it. Unless it is doing multiple things, and/or someone else in the future will have to use it, then it is probably still worth it.

If his point is that you should dogmatically reduce long functions into a bunch of small functions, I think he is completely wrong. If his point is that when the clearest way to implement some functionality is with a single long function and not several small ones, and that that is likely indicative of poorly architected code and/or data models, I probably agree with him.

Iff you have some poorly architected code that results in you writing a 500 line function, breaking that poorly architected code down into 20 small functions will only make things worse. However it might be that you could re-architect the code and data models in such a way that functions don't need to be large to be clear then that is probably a good thing.

So please don't go breaking a long function into a bunch of smaller ones, where your small functions' names are effectively code comments, but if you can, rearchitect the code so that a set of smaller functions can accomplish the same task in a more clear way, I am all for it.

If you work on a Node backend with Javascript, Where does the idea of switching to Typescript fall into this discussion? Is it a boring technology, or a shiny new technology? It is still using the same tech in Node, which you already know the benefits and pitfalls for, but it isn't like there is no overhead to start consuming Typescript if you haven't used it before.

My hope is for those who agree with the author's premise, that it is still using the same "boring" technology and more people switch to it, because over the last two years when we switched to use Typescript, it has gotten significantly more valuable as more and more people have used it because now a majority of the dependencies I take on have type definitions provided via DefinitelyTyped, or are included with the package.

I don't necessarily want something more technical, but for some reason I was anticipating that the reason given would've been more of a technical one, like "Firefox is way better with WASM" or something of that nature.

Is that even meant to be a secret?

I agree. I think it also has the potential to help motivate developers to write native UI rather than use electron.

Currently if for your market, your primary target platform is the web, but other platforms are still important, going electron might make sense because you really don't want to write your business logic natively for each platform.

Web assembly allows us to use the same native libraries for all our business logic and data models, which besides being more performant, means we only need to be willing to write the UI natively on top of those libraries. We've actually taken (very) old desktop C++ code, and compiled it to asm.js and ran it in our web app, and then rendered its outputs with webGL onto a canvas and have had surprisingly successful results. This makes the prospect of WASM becoming standard across the board very exciting.

Now let's hope we don't decide to replace our native desktop app, that uses this old C++ library, with an electron app of our web app, running the asm.js compiled library :).

I enjoyed his points. I've often thought of the meaningless of things, but I like how he called them rituals.

“Vanity of vanities!” says the Teacher, “Vanity of vanities! All is vanity!”

The above is a quote from Ecclesiastes, which, even if you're not religious, is a pretty interesting book, and it seems to sum up pretty much what he is saying.

Fitting enough, shortly after that opening statement in Ecclesiastes this is said.

"What has been—it is what will be; what has been done—it is what will be done; there is nothing new under the sun. There is a thing of which it is said, “Look at this! This is new!” But it already existed in ages past before us."

I worked in R&D at Philips making ultrasounds. From my experience this is definitely what it is.

The amount of people that were employed to simply test, do documentation, and verify safety alone was staggering, let alone all the smart people it took to develop custom ASICs, FPGAs, mechanical housings, image processing etc. There are physicists who do research, there are sonographers who help achieve the best possible images for clinical scenarios.

The amount of effort it takes to make a high quality, safe, ultrasound is immense. When you add in the fact that you also need to follow a myriad of FDA regulations, even small code changes often require a huge amount of overhead in documentation and review before they get checked in, and then there will be whole teams of people to manage source control.

Ultrasound companies do an immense amount of R&D, but also put out a safe, well-regulated product, and the prices reflect that. I'm surprised the the author in the article found even a low quality ultrasound as cheap as he did.