4 ms·
I'll make three points. The article is focused on machine efficiency. Human efficiency also matters. If you want to save cycles and bytes then use assembly l
by DannyB2 9y ago
I'll make three points.
The article is focused on machine efficiency. Human efficiency also matters. If you want to save cycles and bytes then use assembly language. Geez, we had the assembler vs fortran argument back in the 70's. Probably even in the 60's but I'm not that old. Guess what? High level languages won.
Next.
Hey, Notepad is much smaller, leaner, and faster than Word! Okay. But Word has a lot of capabilities that Notepad does not. So is it "bloat" or is it "features" ? Guess what, Windows is a lot bigger and slower than DOS.
Imagine this argument from a business person:
If I can be to market six months sooner than my competitor for only three times the amount of RAM and two times the amount of CPU horsepower -- IT IS WORTH IT! These items cost very little. You can't buy back the market advantage later. So of course I'll use exotic high level languages with GC. I'm not trying to optimize machine cycles and bytes, I'm trying to optimize dollars.
- mikebenfield 9y ago> If you want to save cycles and bytes then use assembly language ... High level languages won. This is a ridiculous straw man. It is completely possible to write efficient software in high level languages, and no one is suggesting people extensively use assembly language. Actually, in many cases it is very difficult to write assembly that beats what's generated by an optimizing compiler anyway.
- _Tev 9y agoConsidering how many people are preaching "do not use electron, write true native apps", the argument is the same (use lower level tools) and reply to it also stays the same: Dev time is the most expensive resource.