Do you think a sculptor would like to listen to Michaelangelo talk about stone carving? What about an engineer having lunch with James Watt?
This post brought this thought up - we're able to talk to the second generation of giants in this industry, and we seem to not take advantage of it as much as we should. Sure, we've developed things much beyond the original technology (My second PC had a 40 MB hard drive. Today I can buy a 1TB drive for one tenth the cost of that PC), but they had the brains to do things in tiny memory over slow data lines, and Moore's Law was not yet in effect.
I've seen Commodore Grace Hopper speak, for crying out loud!
It seems a shame that we're rushing headlong into the future without listening to our elders.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 04, 2009
Monday, March 02, 2009
Good, Fast, Cheap Revisited
Here's a good discussion of the old programmer adage "Good, Fast, Cheap. Pick any two". The comments are enlightening.
A few things that I realized reading that was that there are some definitions that make this a little tricky to discuss.
The first is that your axes need to grow in the correct direction. You can say you're increasing scope by pushing that apex away from the center, which makes the project more difficult, but you've then got to treat resources and time in the same manner, which means that extending the Time apex is not giving more time, but decreasing the time to deadline; similarly, extending the Resources apex means filling up more of your developer's capacity.
I'll need to ponder this a while - perhaps I'll come up with a better analogy, or at least better terms to use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
A few things that I realized reading that was that there are some definitions that make this a little tricky to discuss.
The first is that your axes need to grow in the correct direction. You can say you're increasing scope by pushing that apex away from the center, which makes the project more difficult, but you've then got to treat resources and time in the same manner, which means that extending the Time apex is not giving more time, but decreasing the time to deadline; similarly, extending the Resources apex means filling up more of your developer's capacity.
I'll need to ponder this a while - perhaps I'll come up with a better analogy, or at least better terms to use.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 01, 2009
Haters
As one of the (relatively) older people in Software Development, I've seen a good deal of the history of the profession, and one of the perennial things we are forced to live with are the holy wars over various things. We've got Editor Wars (Emacs vs vi), OS Wars (Windows vs Mac vs Unix), distro wars (Ubuntu vs Fedora vs Gentoo), and so on.
But the biggest wars are those over the programming paradigms - Declarative programming (DP), Functional programming (FP), Object-oriented programming (OO), and the others. So it's always amusing to read the various viewpoints from the various camps, and quite often I learn something useful from them.
However, not all are so valuable - this post, from a Erlang partisan, is an almost classic example of elevating personal preference to moral imperative. He (?) takes various straw men about OOP and proceeds to tear them apart, claiming that this then "proves" OOP is a bad idea.
I'm not usually prone to point-by-point rebuttals, but this one was too egregious not to try.
Objection 1 - functions and data should not be bound together
This shows a total misunderstanding of the premise of OOP. The objects exist to collect the data and behavior that modifies that data. If you have an object modeling a car, and you want to track fuel consumption for that car, where better to place that than with the car, so that any individual quirks about fuel burn rate for that specific car are contained there? An FP alternative would be to have a fuel-burn function, but that would have to be able to handle every possible fuel burn option, making it a very complex function; if only a few vehicles needed certain options, the OOP solution would keep those options close to where they are used.
Objection 2 - everything has to be an object
While not true in most OOP languages, the point is clear. However, the example he gives is for time, and he suggests using the Erlang type declarations. Now, I know very little about Erlang; in fact, I know effectively nothing about it. But this set of functions reference a conceptual time object - the real time clock of the system, and only return values from that object.
Objection 3 - OOPLs spread data type definitions all over the place
This one does have a grain of truth - you can't put everything in your OOP program in one file. However, it provides an encapulation - you don't need to know the inner workings of everything if you have a well-defined interface to those things. He also makes the spurious claim that if you need a "ubiquitious" data structure, you must inherit from that class to use it. This shows a lack of awareness of how OOP works - inheritance is only part of the mix - composition is more useful, and does not require inheritance to work. In fact, composition is part and parcel of earlier structured languages and their data structures.
Objection 4 - Objects have private state
Spoken (typed) like a true FP partisan. "State is the root of all evil", yet "in the real world, state abounds" Why then do we wish to eliminate state, if it is part of the things we wish to control? He claims that revealing all the state is good, but using monads to allow the programmer to avoid knowing about state is also good. You can't have it both ways - either there is state, and it needs to be managed, or you need to avoid it altogether. OOP allows the programmer to use state when desirable, and to hide it when convenient, much like the real world - I do not need to know all the details of state when I buy a soda from a vending machine, but it's very useful to me should I be repairing that machine.
He then wraps it all up by dismissing OOP because he sees no evidence it helped people learn faster, or made code reuse easier. Arguemnt from incredulity is hardly convincing.
OOP is not a panacea, by any means, but it is a strong tool for partitioning a problem set into disparate sections for working on it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
But the biggest wars are those over the programming paradigms - Declarative programming (DP), Functional programming (FP), Object-oriented programming (OO), and the others. So it's always amusing to read the various viewpoints from the various camps, and quite often I learn something useful from them.
However, not all are so valuable - this post, from a Erlang partisan, is an almost classic example of elevating personal preference to moral imperative. He (?) takes various straw men about OOP and proceeds to tear them apart, claiming that this then "proves" OOP is a bad idea.
I'm not usually prone to point-by-point rebuttals, but this one was too egregious not to try.
Objection 1 - functions and data should not be bound together
This shows a total misunderstanding of the premise of OOP. The objects exist to collect the data and behavior that modifies that data. If you have an object modeling a car, and you want to track fuel consumption for that car, where better to place that than with the car, so that any individual quirks about fuel burn rate for that specific car are contained there? An FP alternative would be to have a fuel-burn function, but that would have to be able to handle every possible fuel burn option, making it a very complex function; if only a few vehicles needed certain options, the OOP solution would keep those options close to where they are used.
Objection 2 - everything has to be an object
While not true in most OOP languages, the point is clear. However, the example he gives is for time, and he suggests using the Erlang type declarations. Now, I know very little about Erlang; in fact, I know effectively nothing about it. But this set of functions reference a conceptual time object - the real time clock of the system, and only return values from that object.
Objection 3 - OOPLs spread data type definitions all over the place
This one does have a grain of truth - you can't put everything in your OOP program in one file. However, it provides an encapulation - you don't need to know the inner workings of everything if you have a well-defined interface to those things. He also makes the spurious claim that if you need a "ubiquitious" data structure, you must inherit from that class to use it. This shows a lack of awareness of how OOP works - inheritance is only part of the mix - composition is more useful, and does not require inheritance to work. In fact, composition is part and parcel of earlier structured languages and their data structures.
Objection 4 - Objects have private state
Spoken (typed) like a true FP partisan. "State is the root of all evil", yet "in the real world, state abounds" Why then do we wish to eliminate state, if it is part of the things we wish to control? He claims that revealing all the state is good, but using monads to allow the programmer to avoid knowing about state is also good. You can't have it both ways - either there is state, and it needs to be managed, or you need to avoid it altogether. OOP allows the programmer to use state when desirable, and to hide it when convenient, much like the real world - I do not need to know all the details of state when I buy a soda from a vending machine, but it's very useful to me should I be repairing that machine.
He then wraps it all up by dismissing OOP because he sees no evidence it helped people learn faster, or made code reuse easier. Arguemnt from incredulity is hardly convincing.
OOP is not a panacea, by any means, but it is a strong tool for partitioning a problem set into disparate sections for working on it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)