Bad programming ideas that only become apparent after years

Re:Bad programming ideas that only become apparent after years by smallstepforman on Sunday December 27, 2020 @02:09PM (#25553411)

0. Dynamic programming languages. I like detecting errors at compile time, not run time.

1. Garbage collection + Forced reference counting. Why penalise all programs?

2. Coroutines and futures. Just use actors, please.

3. Visual Rapid development tools. Because the moment you need to do something interesting, the tools limit you.

[ Parent | on HN ]

Re:Bad programming ideas that only become apparent after years by ourlordcaffeine on Sunday December 27, 2020 @02:18PM (#25553473)

I agree in general, but isn't number 2 just an opinion? Surely the advice would be to just pick one way and stick to it without mixing in others.

[ Parent | on HN ]

Re:Bad programming ideas that only become apparent after years by zepto on Sunday December 27, 2020 @03:14PM (#25553883)

With #1, I agree you need an escape hatch from GC and or reference counting.

But for most problems, these don’t impose a meaningful penalty and do remove a huge cognitive burden. Why penalize all programmers?

[ Parent | on HN ]

Re:Bad programming ideas that only become apparent after years by Gibbon1 on Sunday December 27, 2020 @04:39PM (#25554491)

What I see as a bad idea is we created systems where the stack is a precious resource. For no actual good reason. You only have a few MB worth of stack. Why, because traditionally CPU's had one stack pointer.

We stick with this despite that stack allocation is vastly faster than heap.

[ Parent | on HN ]