0xr0kk3r

Not just techbro/hipsters: programmers have huge egos, when in reality they are just mediocre tradesmen. Like your typical construction worker. There are 10,000 hammer swingers for every architect, but those 10,000 think they are all in the top-10. So we end up with egos and factions creating a tidal wave of mediocre tools, each with just enough fan base to grow large enough to be cancerous. Too few architects with experience at the helm (and trained by the old guard), unfortunately, is the problem.

This is actually pretty funny. I coded javascript for a solid ~18 years (I stopped about 3 years ago) and the majority of the concerns in this list are from the past 10 years. What I find glaringly absent, which would have been present if this were written in 2013, is the absence of polyfills.

What other things that were JS nightmares in 2013 have largely ceased to exist? (Only to be replaced by this funny list.)

This is my favorite part: "You stop to count how many tools and parsers work on your codebase: TypeScript, esbuild, swc, babel, eslint, prettier, jest, webpack, rollup, terser. You are not sure if you missed any. You are not sure if you want to know. The level of pain is so high you forget about anything else."

What do you think I'm talking about? OP pruned the comments out of github and put the code on the page w/o them. I didn't click to the github page. Still confused?

Oh, I didn't follow that link, I was just reading the blog. Those are decent comments, too bad they were nixed for the blog.

My original post was about the futility of debating RISC vs CISC, supporting OP. The idea that RISC has very few instructions that are near register-level single-cycle: load/store/add/subtract/branch, etc. But in reality there is a tendency for these instructions to be come more tied to the hardware, compiler, or application; hundreds of opcodes that perform multiple RISC operations per opcode is very un-RISC-y. Same with multi-cycle operations that are tied to specific hardware, thus not "pure". Same goes for applications. (The classic example is the Arm "RISC" instruction called "FJCVTZS", or "Floating Point JAVASCRIPT convert to signed rounding to Zero". There's an entire HN thread on this from years ago.)

The crux of my argument is the review and ratification of extended compiler switches that add lots of functionality that becomes less about core compute and more about APPLICATIONS and HARDWARE. And that's where things get CISC-y. Hence the futility of comparing RISC v. CISC: if the clean-slate RISC-V project runs into this, stop arguing the the legend/myth because it is a waste of energy.

My use of the term "wacky" was a poor choice. My problem with the first reply is because they insist that isn't the case, sneers at me, and says "tell me what you think is wrong and I tell you why you are wrong..." That's flamebait, because there are several other replies that the post brushes off with more flamebait.

HARDWARE:

RISC-V has extensibility in the ISA, and T-Head added instructions that require an ASIC. So now we have an ISA+ that very clearly is hardware dependent. Should RISC-V really have entertained Alibaba's hardware-specific SIMD instructions as part of the standard, even if they are enabled with compiler switches? That's a question that will have consequences. RISC-V's biggest market is by far China, so maybe it makes sense? But these opcodes are "wacky" (ugh) in the sense because they require THead hardware, and are very CISC-Y.

I'll stop picking on T-Head. Consider the extensions for non-temporal instructions based on memory hierarchies. This is incredibly hardware specific. But of course, there will always be memory hierarchies regardless of vonNeuman v. harvard designs. And they can be left out of course. But still they will only apply to specific implementations. Much like machines that don't have FPUs cannot make use of FP opcodes, machines without hierarchies cannot make use of non-temporal instructions. So do FPU instructions not belong in the ISA, of course not.

APPLICATIONS:

Does an ISA need vector crypto? Well, it is an extension, so it can be turned off, but AES could easily become post-quantum obsolete. So why bloat the ISA? Sqrt/Sin/Cos will never become obsolete, but AES might.

Even security and privilege levels. Hypervisor extensions, and execution + code isolation extensions force a particular way of doing things on an ISA.

MY DARNED POINT

To recap: I may have made the biggest strawman of all time, but it is based on what I keep hearing. It is easy to wave away all four of my examples if you think RISC-V-can-do-no-wrong. But that misses my point: ISAs are complicated, and when you have hundreds of instructions that do complex things in multiple cycles with lots of side effects that are required by certain hardware or certain applications ... you no longer have a reduced instruction set computer. Even when the best minds start from a clean slate to create RISC they end up with CISC.

Which is why I think the debate is bunk and wastes everyone's time. It was entirely the product of 1990's marketing against Intel and still plagues us today.

The reply is an obvious troll. Whenever someone yawns at your post, dismisses, and then decides to be the arbiter of what constitutes valid (classic fallacy), walk away. Proof? Others did reply and Op just pisses on them verbally. If you don’t know how to read the ratified extensions which OP admitted we’re harmful, just walk away from the topic.

It is NOT feature hell. That is an absolutist/purist standpoint that only gets in the way in my experience. Products evolve to fit their market, which is literally why products are made.

Complexity needs to be managed, not labelled and shunned because it is "too hard" or "ugly". That is life. Learn that early and it will help.

It is fascinating that semantic confusion over RISC vs CISC persists since I was in college in the 80's. It is largely meaningless.

The naive idea behind RISC is essentially to reduce the ISA to near-register-level operations: load, store, add, subtract, compare, branch. This is great for two things: being the first person to invent an ISA, and teaching computer engineering.

Look at the evolution of RISC-V. The intent was to build an open source ISA from a 100% clean slate, using the world's academic computer engineering brains (and corporations that wanted to be free of Arm licensing) ... and a lot of the subtext was initially around ISA purity.

Look at the ISA today, specifically the RISC-V extensions that have been ratified. It has a soup of wacky opcodes to optimize corner cases, and obscure vendor specific extensions that are absolutely CISC-y (examine T-Head's additions if you don't believe me!).

Ultimately the combination of ISA, implementation (the CPU), and compiler struggle to provide optimal solutions for the majority of applications. This inevitably leads to a complex instruction set computer. Put enough engineers on the optimization problem and that's what happens. It is not a good or bad thing, it just IS.

Super wobbly. Looks like the structure holding the rotors together has a lot of flex in it. Makes my engineering brain panic.

I could see this being a rescue device for difficult terrain where a helicopter can't fit.

Recently some coast guard pilots had to risk their lives to save a dog on a hard to reach beach. This thing could have zipped into a tighter space than a chopper and been out in under 15 minutes.

I hate wasting ui space by forcing every application to use their window real estate for a menu bar. There should be only one menu bar in the same location that changes when the context changes. It’s one of my favorite aspects of macOS.