The worst features [of a language] are the attractive nuisances, the features that are both useful and dangerous.
The following data structures are a complete list for almost all practical programs: array, linked list, hash table, binary tree.
Well, I’m an old-fashioned guy. And I also happen to believe in history. The lack of interest, the disdain for history is what makes computing not-quite-a-field.
On the NPM website, they say: “What can you make with 700,000 building blocks?” and to me it’s like: “What can you make with 10,000 kitchens?”
The only reason to have unit tests is to make sure that code that already works doesn’t break. Writing tests first, or writing code to the tests is ridiculous. If you write to the tests before the code, you won’t even know what the edge cases are.
Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.
I think software is getting worse and worse and worse with time. It’s not that we cannot do amazing things with computers, we can! But when they don’t work, we don’t understand why they don’t work. In the past, when you had a program that didn’t work, you can look at it. Now, you ask Google.
Don’t ever let anyone tell you that fork(2) is bad. Thirty years from now, there will still be a fork(2) and a pipe(2) and a exec(2) and smart people will still be using them to solve hard problems reliably and predictably, just like they were thirty years ago.
If you can use limited shared memory and semaphores, asynchronous I/O using SIGIO or poll/select rather than threading, do it that way.
Rushing to optimize before the bottlenecks are known may be the only error to have ruined more designs than feature creep.