6 ms·

Actually - I've found the "elegant properly engineered code" a total NIGHTMARE to deal with. Reflection, endless hierarchies, complexity on complexity. The PHP

Actually - I've found the "elegant properly engineered code" a total NIGHTMARE to deal with. Reflection, endless hierarchies, complexity on complexity. The PHP script kid basically writes a linear program (tons of duplication) with no crazinesses. Yes, it's "low quality", but if you do a few function out refactorings you've got something very easy to work with. I just wish there was a standard template - access check, runtime complexity at code comment at top of function (ie, O(1), O(n), O(n^2)) some reasonable comments, error handling, done. Throw in some unit tests if desired.

rightbyte 5y ago
I full heartely agree. Bonus point for globals you can set checked breakpoints on. Linear long functions are victims of bullying. Sure, it is a balance act, but I take bad linear code over deeply nested code any day. When trying to figure out how code works I can't keep much depth in my head, unless it is some tree walk on a data tree.
- slownews45 5y ago
  Exactly this. The person who knows all the "engineering" - you have this giant mutating pile of impossible to fellow (but maybe 5% faster) code. The person who just codes enterprise style, long but done and easier to follow and edit.
  - thinkharderdev 5y ago
    I guess it depends on how you define "enterprise" but I always associated that word with unnecessarily bloated code. Or even worse, trying to reduce the amount of code by pushing more and more to ever more complicated declarative configuration files. That is mostly because when I hear "enterprise" I immediately think Java EE, which to me was the exact polar opposite of easy to edit and follow.
thinkharderdev 5y ago
"Reflection, endless hierarchies, complexity on complexity" sounds like the exact opposite of "elegant properly engineered code"
- slownews45 5y ago
  You may not have worked with folks really into "properly engineered code". But it is amazing sometimes to see how they can twist language into pretzels by knowing every trick and pattern out there. And yes, somewhere in OOP land this is all proper engineering and the abstraction on abstraction on library on library is the key. The worst is when they start talking about future this and that. Trouble!
  - deleted 5y ago
    [deleted]
  - dbt00 5y ago
    I think that the parent comment was expressing a disagreement with your definition of "properly engineered code". I agree with them -- simpler code is properly engineered, lots of complex magic is not.
  - lamontcg 5y ago
    That isn't properly engineered code. And if you dig into all that code usually the designer didn't understand those tricks and patterns as well as they thought they did and were trying to teach themselves along the way. You can often throw away 3/4 of the code, throw away 3/4 of the "requirements" which aren't being used and wind up with something that is actually simple and elegant and solves the problem, but doesn't attempt to construct anything as grandiose. Of course YAGNI is a whole lot easier in hindsight when you can really look over the course of years and see that nobody ever needed it so it never should have been built and throw it out.
    - AstralStorm 5y ago
      Such features to throw away /s (You must not actually remove any of them. Enterprise jokers will want all of it.) - security (the most forgotten until it bites you) - GUI flow complexity (client requirement you cannot touch) - distributed state management with logical consistency guarantees (horizontal scaling) - ability to quickly adapt for new features - schema upgrade capability (see above) - advanced database queries - event reactivity and/or scheduling (logging, security, notifications) None of the above is quite actually given to you on a silver platter by any one library really, it a combination thereof, and they're rather hard to grow bottom-up organically.
winrid 5y ago
I think the hidden message in your comment is "duplication over abstraction" - and I agree! Often duplicating things is preferable to complicated abstractions.
- slownews45 5y ago
  I find functions etc fine. But the problem is a lot of code let's you go absolutely crazy with complex design patterns - and folks who like to be "engineers" and "architects" go totally nuts with these. There was a fad I think around OOP (maybe with Java) which then bled into a lot of places. Yes, you can do crazy stuff, generics, meta programming, reflections etc. But for example, if go just beefed up the standard library (especially around data structures - give us everything - and common functions there) I think they could have pushed a bit longer in terms of holding off on generics.
- ajmurmann 5y ago
  Sandi Metz has a quote that was something like this "We don't tell me developers about avoiding duplication because it's so important, but because it's the only thing they understand". Duplication is much better than the wrong abstraction

rightbyte 5y ago

I full heartely agree. Bonus point for globals you can set checked breakpoints on. Linear long functions are victims of bullying. Sure, it is a balance act, but I take bad linear code over deeply nested code any day. When trying to figure out how code works I can't keep much depth in my head, unless it is some tree walk on a data tree.

slownews45 5y ago
Exactly this. The person who knows all the "engineering" - you have this giant mutating pile of impossible to fellow (but maybe 5% faster) code. The person who just codes enterprise style, long but done and easier to follow and edit.
- thinkharderdev 5y ago
  I guess it depends on how you define "enterprise" but I always associated that word with unnecessarily bloated code. Or even worse, trying to reduce the amount of code by pushing more and more to ever more complicated declarative configuration files. That is mostly because when I hear "enterprise" I immediately think Java EE, which to me was the exact polar opposite of easy to edit and follow.

thinkharderdev 5y ago

"Reflection, endless hierarchies, complexity on complexity" sounds like the exact opposite of "elegant properly engineered code"

slownews45 5y ago
You may not have worked with folks really into "properly engineered code". But it is amazing sometimes to see how they can twist language into pretzels by knowing every trick and pattern out there. And yes, somewhere in OOP land this is all proper engineering and the abstraction on abstraction on library on library is the key. The worst is when they start talking about future this and that. Trouble!
- deleted 5y ago
  [deleted]
- dbt00 5y ago
  I think that the parent comment was expressing a disagreement with your definition of "properly engineered code". I agree with them -- simpler code is properly engineered, lots of complex magic is not.
- lamontcg 5y ago
  That isn't properly engineered code. And if you dig into all that code usually the designer didn't understand those tricks and patterns as well as they thought they did and were trying to teach themselves along the way. You can often throw away 3/4 of the code, throw away 3/4 of the "requirements" which aren't being used and wind up with something that is actually simple and elegant and solves the problem, but doesn't attempt to construct anything as grandiose. Of course YAGNI is a whole lot easier in hindsight when you can really look over the course of years and see that nobody ever needed it so it never should have been built and throw it out.
  - AstralStorm 5y ago
    Such features to throw away /s (You must not actually remove any of them. Enterprise jokers will want all of it.) - security (the most forgotten until it bites you) - GUI flow complexity (client requirement you cannot touch) - distributed state management with logical consistency guarantees (horizontal scaling) - ability to quickly adapt for new features - schema upgrade capability (see above) - advanced database queries - event reactivity and/or scheduling (logging, security, notifications) None of the above is quite actually given to you on a silver platter by any one library really, it a combination thereof, and they're rather hard to grow bottom-up organically.

winrid 5y ago

I think the hidden message in your comment is "duplication over abstraction" - and I agree! Often duplicating things is preferable to complicated abstractions.

slownews45 5y ago
I find functions etc fine. But the problem is a lot of code let's you go absolutely crazy with complex design patterns - and folks who like to be "engineers" and "architects" go totally nuts with these. There was a fad I think around OOP (maybe with Java) which then bled into a lot of places. Yes, you can do crazy stuff, generics, meta programming, reflections etc. But for example, if go just beefed up the standard library (especially around data structures - give us everything - and common functions there) I think they could have pushed a bit longer in terms of holding off on generics.
ajmurmann 5y ago
Sandi Metz has a quote that was something like this "We don't tell me developers about avoiding duplication because it's so important, but because it's the only thing they understand". Duplication is much better than the wrong abstraction