Bad programming ideas that only become apparent after years

Re:Bad programming ideas that only become apparent after years by fayten on Sunday December 27, 2020 @01:17PM (#25552997)

I don't agree with this line of thinking. This implies that after a certain period of time, you will have the insight to know these things are bad. If you don't agree, then are you just a bad programmer? If I have a differing opinion, have I not programmed enough to come to the same conclusion? What about programming languages like Lisp, Scheme, Nim, and Haxe where Macros are their bread and butter?

Different programmers use different tools. If the end product is the desired result, then let people use what works best for them. I don't use dynamically typed languages; I avoid them like the plague, but that doesn't mean there isn't a ton of good work being done in Python.

Walter is a brilliant language developer and has a lot of firm opinions of programming semantics. I hope to see him expand upon this post and share why he thinks programmers need to be careful using these constructs.

[ Parent | on HN ]

Re:Bad programming ideas that only become apparent after years by AtlasBarfed on Sunday December 27, 2020 @01:23PM (#25553057)

Things that are meant by "time":

1) original programmer moves on, someone else maintains/fixes/owns the code

2) scope / features / scale expands over time generally, so bad decisions for extension / expansion / scaling become prominent

But really the article is about 1.

[ Parent | on HN ]

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

Nearly all code regardless of advanced features can run into severe maintenance issues when domain knowledge is lost. Solving problems should not start with gate keeping features, but promoting better documentation.

[ Parent | on HN ]