An interesting opinion on a style in OOP that leads towards a Functional Programming vibe. From my brief forays into FP, the advantage is that you don't have to manage state; the downside is that you have to organize your program so that you can drop all the intermediate results into a single function.
Of course, small focused methods are a Good Thing (tm) in their own right, so this may just be a convergent evolution of a sort - encapsulating the mutable state so that it's not important at other levels.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Tuesday, March 10, 2009
Monday, March 09, 2009
Fake It Til You Make It
Recent studies in social leadership have tended to show that those who speak up are perceived as leaders.
The obvious Ninja take-away from this is to be sure you speak up in the workplace. If you've been following along here, you should have some of the chops to back it up.
Of course, this may explain the tendency for all the red-tape layers of management to call meetings just so they can voice their irrelevant opinion and rubberstamp the decision.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The obvious Ninja take-away from this is to be sure you speak up in the workplace. If you've been following along here, you should have some of the chops to back it up.
Of course, this may explain the tendency for all the red-tape layers of management to call meetings just so they can voice their irrelevant opinion and rubberstamp the decision.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, March 08, 2009
The Death Of One Thousand Cuts
One of the big things you get as a software developer is a sense for automation. Every advancement of our profession is about automating something - computers were first intended to replace tedious manual math calculations, after all.
So we have the hammer of automation, and tend to see many things as the Nail of repetition. Not that this is a bad thing - it makes our jobs interesting, and keeps us from dying of RSI.
Yet as we go along, we sometimes get into the rut of the things we are not yet able to automate, so I see this post as a reminder to keep looking for thing to automate.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
So we have the hammer of automation, and tend to see many things as the Nail of repetition. Not that this is a bad thing - it makes our jobs interesting, and keeps us from dying of RSI.
Yet as we go along, we sometimes get into the rut of the things we are not yet able to automate, so I see this post as a reminder to keep looking for thing to automate.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Signs And Portents
This list is going to look familiar to any of you that were coding during the dot-com boom and bust.
The scary part is that so many of them are true.
I counted 26 that I have personally seen. #40 was a point in my most recent company meeting.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The scary part is that so many of them are true.
I counted 26 that I have personally seen. #40 was a point in my most recent company meeting.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Wednesday, March 04, 2009
On The Shoulders Of Giants
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
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
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)