6 ms·

Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.

qwertyuiop924 10y ago
I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
- king_magic 10y ago
  And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is still the same.
  - qwertyuiop924 10y ago
    And I... Kind of agree? :). You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet. >It's not "certainly less complex". The total complexity of the system is still the same. The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze. So, I assume that this something you agree with. In which case, congrats, you've convinced me.
    - collyw 10y ago
      How is it reduced if you have everything needing to communicate back and forward? Sounds like more complexity to me.
      - qwertyuiop924 10y ago
        The components aren't necessarily separate apps, but even if they are, that problem has been solved many times over. Take your pick: HTTP, raw sockets (TCP or unix domain), ZeroMQ, RabbitMQ for larger projects, Shared Memory, pipe(2) (and friends), hell, even message queues and semaphores, if you hate yourself...
Ace17 10y ago
Sorry, I couldn't help myself :-) http://e-venue.org/wp/ignore-the-real-world/ http://e-venue.org/wp/ignore-the-real-world/

I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.

king_magic 10y ago
And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is still the same.
- qwertyuiop924 10y ago
  And I... Kind of agree? :). You do have to plan out your software, I guess I kind of de ied that. I was wrong. You were right. Take your victory dance, then sit down, I'm not quite done yet. >It's not "certainly less complex". The total complexity of the system is still the same. The total complexity of the system is the same, yes, but the GLOBAL complexity of the system is significantly reduced: A lot of complexity is isolated, and if the components interact through well-defined interfaces, you can treat each as a black box (theoretically, once they work), and use them as building blocks to build your system. Every programming paradigm, language, and system in the last 60+ years is based around this idea, from structural, to OO, to Unix, to Lisp, to Microservices, and on to the next craze. So, I assume that this something you agree with. In which case, congrats, you've convinced me.
  - collyw 10y ago
    How is it reduced if you have everything needing to communicate back and forward? Sounds like more complexity to me.
    - qwertyuiop924 10y ago
      The components aren't necessarily separate apps, but even if they are, that problem has been solved many times over. Take your pick: HTTP, raw sockets (TCP or unix domain), ZeroMQ, RabbitMQ for larger projects, Shared Memory, pipe(2) (and friends), hell, even message queues and semaphores, if you hate yourself...

Ace17 10y ago

Sorry, I couldn't help myself :-) http://e-venue.org/wp/ignore-the-real-world/ http://e-venue.org/wp/ignore-the-real-world/