5 ms·

I blame object orientation. It is too easy to create useless classes. Funcional programming data types, on the other hand, are much more direct to the point, wh

I blame object orientation. It is too easy to create useless classes. Funcional programming data types, on the other hand, are much more direct to the point, which makes it easier to spot useless layers.

YZF 5y ago
It happens everywhere, not just OO. It's just human nature. I worked on C code where there were 8 layers of calls where each function was f() {return next_layer_f();} . The thing is sometimes layers serve a function and sometimes they don't. Then there's an always present pressure to look "professional" and so tons of layers and lots of details/checklists. The 4 lines of code that actually does everything you need doesn't cut it. And what will you do the rest of your day? The funny/sad thing is it doesn't matter how hard you try to fight human nature it doesn't seem to work. I love how the Go developers thought `go fmt` will end the formatting nitpicks. Guess what, it doesn't. We just found other things to nitpick. Or "Agile" or whatnot. Python says "A Foolish Consistency is the Hobgoblin of Little Minds" ... Well, try that on your co-worker in your next Python code review ;) Functional programming doesn't help either. In very small teams/companies sometimes the stars align and magic happens but it's really hard. EDIT: Also nothing to do with the article ;) though maybe we can dream up some connection to the human brain.
RedShift1 5y ago
I used to be balls deep into OOP. I was in the rabbit hole. For me it was _the_ way programs had to be written. Whenever I started a new project, it would start out as a bunch of interfaces and abstract classes (with the god abstract class which everything extended from present and accounted for). At the time there was also the transition from PHP 4 to PHP 5 which unlocked a treasure trove of new OOP features and obviously every one of those features had to be used. However when things went wrong they would often turn into a nightmare, spending hours chasing down obscure bugs with endless print_r's to follow state changes. Over time I became better at managing this, keeping the amount of abstractions lower and just general better OOP design, but I was still afraid whenever things would go south, it meant hours of debugging, as was often the case. At one point or another I started asking questions about OOP design, the nature and origin of it and searched the internet for answers. Along the way I started realizing that many of the problems I was having are intrinsic to OOP. Whenever I would search for solutions to the complexity of OOP the answer would always be: you're doing it wrong. Along the way I transitioned to OOP-less programming (I'm calling it OOP-less because I don't want to start a fight over "functional" vs "procedural" vs "..." etc...), not with the intention to do away with OOP but just to play with it. I rewrote some earlier, simple programs and what became rapidly obvious was how easy the code was to debug. The datastructures I had written prior were way too complex with too many levels and useless wrappers to make everything fit into the OOP paradigm. I rapidly became annoyed with the complexity of OOP and realized, I was in a rabbit hole and I had dug in _deep_. Even now when I'm writing bigger programs OOP-less I still find them much easier to debug. I'm still afraid debugging sessions can get rough but as time passes by this seems like more of a PTSD effect from my 15 year long OOP stint. By now I've mostly done away with OOP programs but it's still annoying to have to interface with OOP designed libraries. I also changed my coding style camelCase to snake_case and the latter is much more legible to me but as a lot of libraries use camelCase or PascalCase it doesn't make the code look pretty. So yes long story short, I share your assignment of blame. Complexity just seems to be the nature of the beast.
- juangacovas 5y ago
  >spending hours chasing down obscure bugs with endless print_r's to follow state changes It's not better chasing that using an interactive debugger with expression breakpoints? (pause execution when some variable/property changes?)
  - RedShift1 5y ago
    I've used interactive debuggers but didn't feel like they made debugging any easier. This article https://buttondown.email/geoffreylitt/archive/starting-this-newsletter-print-debugging-byoc/ https://buttondown.email/geoffreylitt/archive/starting-this-... mirrors my feelings about debuggers.
- tored 5y ago
  snake_case is better "Although, no difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style. " http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn... Personally I can't decide on what to use so there is usually a mix with snake_case and camelCase, even within the same project, depending on what it is applied on.
- tored 5y ago
  This weekend I did an experiment of writing a toy project as procedural PHP instead of OOP. This was because of a discussion on reddit where someone claimed that procedural was much better than OOP, but without giving any proof or showing any code. Procedural PHP has ofc always existed, but I wanted to experiment how a modern take with the latest PHP 8.1 features could look like. There was both plus and minuses. I will publish it to github soon.

YZF 5y ago

It happens everywhere, not just OO. It's just human nature. I worked on C code where there were 8 layers of calls where each function was f() {return next_layer_f();} . The thing is sometimes layers serve a function and sometimes they don't. Then there's an always present pressure to look "professional" and so tons of layers and lots of details/checklists. The 4 lines of code that actually does everything you need doesn't cut it. And what will you do the rest of your day? The funny/sad thing is it doesn't matter how hard you try to fight human nature it doesn't seem to work. I love how the Go developers thought `go fmt` will end the formatting nitpicks. Guess what, it doesn't. We just found other things to nitpick. Or "Agile" or whatnot. Python says "A Foolish Consistency is the Hobgoblin of Little Minds" ... Well, try that on your co-worker in your next Python code review ;) Functional programming doesn't help either. In very small teams/companies sometimes the stars align and magic happens but it's really hard. EDIT: Also nothing to do with the article ;) though maybe we can dream up some connection to the human brain.

RedShift1 5y ago

I used to be balls deep into OOP. I was in the rabbit hole. For me it was _the_ way programs had to be written. Whenever I started a new project, it would start out as a bunch of interfaces and abstract classes (with the god abstract class which everything extended from present and accounted for). At the time there was also the transition from PHP 4 to PHP 5 which unlocked a treasure trove of new OOP features and obviously every one of those features had to be used. However when things went wrong they would often turn into a nightmare, spending hours chasing down obscure bugs with endless print_r's to follow state changes. Over time I became better at managing this, keeping the amount of abstractions lower and just general better OOP design, but I was still afraid whenever things would go south, it meant hours of debugging, as was often the case. At one point or another I started asking questions about OOP design, the nature and origin of it and searched the internet for answers. Along the way I started realizing that many of the problems I was having are intrinsic to OOP. Whenever I would search for solutions to the complexity of OOP the answer would always be: you're doing it wrong. Along the way I transitioned to OOP-less programming (I'm calling it OOP-less because I don't want to start a fight over "functional" vs "procedural" vs "..." etc...), not with the intention to do away with OOP but just to play with it. I rewrote some earlier, simple programs and what became rapidly obvious was how easy the code was to debug. The datastructures I had written prior were way too complex with too many levels and useless wrappers to make everything fit into the OOP paradigm. I rapidly became annoyed with the complexity of OOP and realized, I was in a rabbit hole and I had dug in _deep_. Even now when I'm writing bigger programs OOP-less I still find them much easier to debug. I'm still afraid debugging sessions can get rough but as time passes by this seems like more of a PTSD effect from my 15 year long OOP stint. By now I've mostly done away with OOP programs but it's still annoying to have to interface with OOP designed libraries. I also changed my coding style camelCase to snake_case and the latter is much more legible to me but as a lot of libraries use camelCase or PascalCase it doesn't make the code look pretty. So yes long story short, I share your assignment of blame. Complexity just seems to be the nature of the beast.

juangacovas 5y ago
>spending hours chasing down obscure bugs with endless print_r's to follow state changes It's not better chasing that using an interactive debugger with expression breakpoints? (pause execution when some variable/property changes?)
- RedShift1 5y ago
  I've used interactive debuggers but didn't feel like they made debugging any easier. This article https://buttondown.email/geoffreylitt/archive/starting-this-newsletter-print-debugging-byoc/ https://buttondown.email/geoffreylitt/archive/starting-this-... mirrors my feelings about debuggers.
tored 5y ago
snake_case is better "Although, no difference was found between identifier styles with respect to accuracy, results indicate a significant improvement in time and lower visual effort with the underscore style. " http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn... Personally I can't decide on what to use so there is usually a mix with snake_case and camelCase, even within the same project, depending on what it is applied on.
tored 5y ago
This weekend I did an experiment of writing a toy project as procedural PHP instead of OOP. This was because of a discussion on reddit where someone claimed that procedural was much better than OOP, but without giving any proof or showing any code. Procedural PHP has ofc always existed, but I wanted to experiment how a modern take with the latest PHP 8.1 features could look like. There was both plus and minuses. I will publish it to github soon.