I think there are three approaches to software design. Data oriented, algorithm oriented and object oriented. I can tell that you are an algorithm oriented designer like I am. A data designer thinks the design is done when all the SQL tables are designed, and an object designer thinks the design is done when the object model is complete. You and I, we like to know how things actually work :-) The data structures and classes we end up with are a by product of the design, not the design in itself.
Yeah, that's basically it. I'm not above starting with SQL or object diagrams from time to time, but I view those as rather narrow perspectives on the system as a whole, and try to keep them as simple as possible.
Subclassing is a way to save typing when you have two situations where you need similar but not quite identical behavior. (But then you will discover that they are more different than you thought. Which is okay, just don't be surprised...)
Also in some languages (C++) it's the name for how you get "interfaces", but that's not really subclassing anyway.
This is totally typical of formal education in programming, though; we have practical skills that we don't know how to articulate very well (which is in no way unique to programming) so when we're *forced* to articulate something in teaching then we just make stuff up that uses the same words and sounds like it makes sense. (Something similar seems to happen in academic CS, where the value of a system is based on how convincingly you can describe that value in a paper.) ...Then sometimes the stuff we make up sounds *so* good that it gets built into all new languages. Thus, OO.
I wish POSIX exposed more information about socket write buffers.
The reason why such API doesn't exist is that it's not flexible enough while adding conciderable overhead to the raw syscall-based API. For example, this API states that any 'can read' condition will lead to unconditional method call
( ... )
If you're trying to rate limit a download connection you can do it (awkwardly) by only reading from the socket at the rate you want. This will cause the sending side to slow down, although it's kind of clumsy under the hood due to technical issues with how TCP works. There unfortunately isn't a better way to rate limit TCP on the receiving end.
Twisted could in principle work, in fact someone's already implemented swapping out the Tornado networking layer with Twisted (at some cost to performance). The main problem is that Twisted looks like a convoluted monster, and it's extremely unclear how to get started from just looking at it.
You're comparing bad design in OO versus good design in FP. In practice they aren't really all that different - a function is just an object with only one method, although Java culture in particular tends to encourage excessive objectification.
Comments 26
Reply
Reply
Also in some languages (C++) it's the name for how you get "interfaces", but that's not really subclassing anyway.
This is totally typical of formal education in programming, though; we have practical skills that we don't know how to articulate very well (which is in no way unique to programming) so when we're *forced* to articulate something in teaching then we just make stuff up that uses the same words and sounds like it makes sense. (Something similar seems to happen in academic CS, where the value of a system is based on how convincingly you can describe that value in a paper.) ...Then sometimes the stuff we make up sounds *so* good that it gets built into all new languages. Thus, OO.
I wish POSIX exposed more information about socket write buffers.
Reply
Reply
Reply
(The comment has been removed)
Reply
(The comment has been removed)
What problems of design in Twisted does Tornado actually solve?
My initial guess was that twisted was a too-large kitchen-sink solution and the friendfeed guys wanted something lighter.
Reply
Reply
Reply
Reply
(The comment has been removed)
Reply
Leave a comment