Well that's kind of his point, throw the TCP/IP stuff to the proverbial Aaron to deal with. It's just that if you're doing the system design, you're playing the role of the proverbial Aaron.
But in other case I mentioned, I wasn't "Aaron" (and not every place has an Aaron). I was just a dev trying to use HTTP(S) to call another service. The vendor said it was a problem on our end, and if I didn't learn TCP/IP it would have been hard to prove otherwise. Regular devs still need to eventually learn how it works in order to fix it when things go wrong.
At the end of the day, customers will not accept "it's not my fault, but the framework" as an answer. They simply want it to work. The customer still holds the dev team responsible for the product, including everything their chosen framework does, good and bad. That's why I prefer libraries, because they can ideally be understood in isolation of the rest of the system. It is harder to do this with frameworks which mix many concerns.
I don't think we actually disagree in principle, but in degree of abstraction.
I'd agree with you there. Libraries, and anything that's that modular, are much easier to deal with than frameworks. I don't think platforms have that problem as much as frameworks do, since you're pretty much only dealing with things in the layer under you instead of other things in the same layer or even in the layer above you.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Well that's kind of his point, throw the TCP/IP stuff to the proverbial Aaron to deal with. It's just that if you're doing the system design, you're playing the role of the proverbial Aaron.
But in other case I mentioned, I wasn't "Aaron" (and not every place has an Aaron). I was just a dev trying to use HTTP(S) to call another service. The vendor said it was a problem on our end, and if I didn't learn TCP/IP it would have been hard to prove otherwise. Regular devs still need to eventually learn how it works in order to fix it when things go wrong.
At the end of the day, customers will not accept "it's not my fault, but the framework" as an answer. They simply want it to work. The customer still holds the dev team responsible for the product, including everything their chosen framework does, good and bad. That's why I prefer libraries, because they can ideally be understood in isolation of the rest of the system. It is harder to do this with frameworks which mix many concerns.
I don't think we actually disagree in principle, but in degree of abstraction.
I'd agree with you there. Libraries, and anything that's that modular, are much easier to deal with than frameworks. I don't think platforms have that problem as much as frameworks do, since you're pretty much only dealing with things in the layer under you instead of other things in the same layer or even in the layer above you.