9 comments:

  1. There are many more aspects to the whole thing than the rather naive (IME) post. First, optimizing software makes it inherently less portable, less maintainable and ultimately more "fragile" normally. If the problem is well understood, doesn't change quickly and justifies lots of resources to be solved @ high performance, then it's worth doing, most problems in software are not like this. Ultimately, if the problem is _really_ well understood, performance _really_ matters and there is _real_ money on the table, silicon is built which is a very rigorous process. But then lots of people turn around and are disappointed that a free lunch of high-performance and 2 weeks release cycles is not attainable.

    When requirements are loose and are changing fast (which is the enchantment of the day as in "software can do anything and be changed on a whim") and there isn't enough money in it on top (enters open-source) and on top of the top it has to be kept maintainable (staff turnover, portability, stable APIs to plug into other stuff) then layering and abstraction naturally takes over (which is really our only way to deal with massive amount of complexity in somewhat predictable fashion by containing the blast radius of the entropy being pumped into the system). Layering means indirections and that means performance loss on today's computer architecture in prevailing languages @ least. There is work being done in modern CS emphasizing "zero-cost-abstraction" and natural parallelization (which is a rewarding but difficult path to performance) but this ends up in lambda-calculus corner pretty much which @ this point in time few programmers understand IME since it's more math than the usual "let's put bunch loops and ifs together" and slides quickly into distributed systems theory that is easy to get 99% correct and then the last 1% is impossible to debug if one doesn't have enough understanding of the basics of it ...

    well, my usual 2c "no free lunch" flavor ...
    Replies
    1. While I (as is most often the case) totally agree with you, you're talking about reasonable world. Unfortunately I've seen way too many cases where people kept heaping abstraction layers on top of abstraction layers out of sheer laziness or worse.

      I would say this is the canonical example: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/

      Also, I'm guessing we're both old enough to remember Pascal (and other compiled languages), and I don't think our speed of development (of reasonable-quality code) was ever significantly impacted by the compilation time.
    2. As to compile, try 40-50 MLOC lines (as in millions ;-) of code that is nothing particular at all for a complex system these days ... Only an extended handful of shops have people smart/hard working/experienced enough to keep compile times/abstraction/sanity on something like this in parameters ...

      But then yes, as anything, abstraction and layering can be a fetish ;-)

      And ultimately, I wouldn't mention JavaScript and reasonable in the same sentence or even book ... JavaScript is like PHP, it's a statement of belief largely rather than a logical calculus a normal programming language is.
    3. Looks like we'll have to continue this discussion over (a large set of) beer(s). You're talking about giant monolithic systems, whereas the article mostly focuses on the crap deployed as web apps... and yes, most of its rant is targeting the likes of JavaScript and PHP.
    4. I'm not talking monolitic, I'm talking reasonable _systems_ whether you put them together with some freebies and automation or buy a vertically integrated product or mix things. Those things have huge volumes no matter what you do ... But that's beside the point.

      If we talk PHP and JavaScript it's not worth the time, it's not a very interesting discussion IMO and it seems an odd discussion for ipSpace anyway ...
    5. "If we talk PHP and JavaScript it's not worth the time" << and yet a lot of so-called SDN and automation stuff out there is written in Python which might or might not be better than PHP based on your religious beliefs ;)
  2. Honestly, it is all of our faults. We like and/or created the users who like easy and pretty application experiences. Modern programming and software design is 5% problem solving, 60% ascetics, 25% making it as idiot "resistant" as possible, then 10% more problem solving due to adding all the unnecessarily ascetic touches and idiot resistant bloat. Yes, idiot resistant; there is no such thing as idiot proof. We are caught in a repeating cycle of dumbing things down and prettying them up, just so the current user base can utilize things without thought. This breeds the next generation of less resourceful users. Honestly, we all love the benefits of the new "easy button" world. Just think of the early morning call with your parents or other family members trying to explain how to do something tech related.... That being said, the art of simplicity is being lost. We could all use a little RFC1925 rule 12 like methodology in our designs.
    Replies
    1. 60% ascetics !

      Did you mean aesthetics/esthetics? (a branch of philosophy dealing with beauty and the beautiful)

      Or did you really mean asceticism? (a lifestyle characterized by abstinence from sensual pleasures, often for the purpose of pursuing spiritual goals)
  3. aesthetics, sorry lex-dysia got me again
Add comment
Sidebar