3 ms·

The problem of which DB to use is one that can be figured out ahead of time with even modest attention to more rigorous engineering practice. But that’s not wha

by sidlls 4y ago

The problem of which DB to use is one that can be figured out ahead of time with even modest attention to more rigorous engineering practice. But that’s not what webdevs the subject of this article do. They play guess-and-check games like they are 15th century engineers building a bridge, because they have hacker mentalities instead of engineer mentalities. Not to mention the cult of celebrity and fad following in the industry.

dasil003 4y ago
The analogies to civil engineering are strained. Sure there is some truth to what you are saying, but also requirements for civil engineering projects tend to be more easily stated at a high level and are depending on the unchanging and unforgiving laws of physics plus some slowly growing list of available materials and construction processes. Everyone understands intuitively that bridges are expensive and you can't just change requirements on a whim without potentially blowing up the whole project and starting over. Software on the other hand can be made to do anything, we can change it any time, and the technical requirements for scale and functionality are hard to predict ahead of time. Trying to apply civil engineering mentality to software results in a process that is too slow and gets beaten by hacker mentality every time.
- cyber_kinetist 4y ago
  Software is also limited by the laws of physics, which is the actual hardware (silicon) it’s running on. Things like CPU clock speed, IPC, memory latency and throughput are all constrained by things like the speed of light, capacitor physics, current status of silicon technology and manufacturing, etc. So when a web app performs sluggish on commodity devices, it’s because the devs haven’t put thought into the actual physical constraints of CPU and memory. It’s just plain bad engineering. (You might say that the whole browser DOM/JS model is at fault, but then that’s bad engineering for the Web spec designers. To be fair though, things like the DOM and JS were invented about 3 decades ago at the time when computer performance was increasing so fast that people really didn’t think about these constraints seriously. Nowadays things are different, and these initial design decisions are biting us…)
deleted 4y ago
[deleted]

by sidlls 4y ago

dasil003 4y ago

The analogies to civil engineering are strained. Sure there is some truth to what you are saying, but also requirements for civil engineering projects tend to be more easily stated at a high level and are depending on the unchanging and unforgiving laws of physics plus some slowly growing list of available materials and construction processes. Everyone understands intuitively that bridges are expensive and you can't just change requirements on a whim without potentially blowing up the whole project and starting over. Software on the other hand can be made to do anything, we can change it any time, and the technical requirements for scale and functionality are hard to predict ahead of time. Trying to apply civil engineering mentality to software results in a process that is too slow and gets beaten by hacker mentality every time.

cyber_kinetist 4y ago
Software is also limited by the laws of physics, which is the actual hardware (silicon) it’s running on. Things like CPU clock speed, IPC, memory latency and throughput are all constrained by things like the speed of light, capacitor physics, current status of silicon technology and manufacturing, etc. So when a web app performs sluggish on commodity devices, it’s because the devs haven’t put thought into the actual physical constraints of CPU and memory. It’s just plain bad engineering. (You might say that the whole browser DOM/JS model is at fault, but then that’s bad engineering for the Web spec designers. To be fair though, things like the DOM and JS were invented about 3 decades ago at the time when computer performance was increasing so fast that people really didn’t think about these constraints seriously. Nowadays things are different, and these initial design decisions are biting us…)

deleted 4y ago

[deleted]