The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Why OO Sucks

http://programming.reddit.com/goto?rss=true&id=1gfov

<quote>
Objection 1 - Data structure and functions should not be bound together
Objection 2 - Everything has to be an object.
Objection 3 - In an OOPL data type definitions are spread out all over the place.
Objection 4 - Objects have private state.
</quote>

I don't agree with the objections, but they are at least reasonable. One thing I've never understood is how a module in a functional language, like Erlang, is any different than an object. Single assignment is different, but the structure still seems the same to me.
son of parnas
Monday, April 09, 2007
 
 
Objection 1 - Data structure and functions should not be bound together

Answer: Then don't bind them together. It is perfectly legitimate to have classes that are "pure data objects" and classes that are "pure functional" objects. A pure data class is just a replacement for a structure.

Objection 2 - Everything has to be an object.

Answer: True. So what's the point? In a non-object oriented language I could say that everything has to be a function or a data member. But I wouldn't be proving anything at all.

Objection 3 - In an OOPL data type definitions are spread out all over the place.

Answer: Then don't spread them all over the place.

Objection 4 - Objects have private state.

Answer: So what's the point? Why is that bad? Functions in non-OO languages have private state. And having completely global state is a real disaster in my book.

Kepp on trolling folks. But please try a little harder next time.
johnny
Monday, April 09, 2007
 
 
The article is quite bias; between the lines I've noticed a "religiously functional" attitude. The author tries to prove at all costs that OO sucks. Then it doesn't look at where OO is successful and where it fails and, for this reason, it provides very little value for the reader.

1) Data structure and functions should not be bound together
The bind between data and functions is not unreasonable as long as they are both implied by the same class.
For example:
string -> length
string -> chars[]

2) Everything has to be an object.
Any entity of the physical realm is an object. Our mind puts borders around things and makes them objects. Therefore the data structures and functions of programming languages are objects.

3) In an OOPL data type definitions are spread out all over the place.
Data types and functions scatter naturally because of the single responsibility principle (Robert Martin): A class should have only one reason to change.

4) Objects have private state.
State is a natural thing. State occurs when stateless systems are decorated with a feedback loop. I don't see anything wrong with state.
Dino Send private email
Monday, April 09, 2007
 
 
I didn't find the arguments very compelling.  For the most part they left me saying, "So what?"  The essay left me with the feeling that the author has never really understood the object oriented approach. 

This is especially the case when the author says, "...data structures representing times can be manipulated by any function in the system."  One of the strengths of the kind of encapsulation offered up by an OO approach is that it prevents data structures from being manipulated by "any function in the system."  Instead manipulation is limited to those functions capable of manipulating the data structure in a manner consistent with the definition of the data structure - the member functions. 

I will be the first to admit that sometimes one or more of the strengths of the OO approach gets in the way of something I am working on.  This is a sign to me that perhaps an OO approach isn't right *for that particular problem*  It doesn't mean that "OO sucks" in general.
Franklin Send private email
Monday, April 09, 2007
 
 
This always bothered me:

> Any entity of the physical realm is an object. Our mind
> puts borders around things and makes them objects.
> Therefore the data structures and functions of programming
> languages are objects.

This is so wrong. First, not everything in the physical
realm is an entity or an object. There are also physical
quantities (mass, speed), forces, etc.
Second, in the physical world objects do not have limited
functions assigned to them and no other. In OO, a
screwdriver would have a method "screw". In the real
world, you can also use it to pierce things, for example.
So, OO is a very limited way of modeling that. It's ok,
too, all models are limited.

And also:
http://www.research.ibm.com/sop/

But stop with this "it's just like the physical world" -
it totally is not.
DEBEDb Send private email
Monday, April 09, 2007
 
 
> But stop with this "it's just like the physical world" -

I think it's a hold over from Randian epistemology and doesn't track modern research. OO is just a useful way to structure software. It doesn't need some deep affiliation with nature for justification.
son of parnas
Monday, April 09, 2007
 
 
Not too bad, but not really good either.

I remember the 'olden days' of OO, where "Objects" would just "Know" what "Method" should be called, where having created your sea of "Classes", you'd invoke a single "Method", and the "App" would just "Do what you wanted".

There was this mystical way of talking about Objects, like an Object was a sentient being that "Knew" things and would automatically (they LOVED the term "automatically") choose the right thing to do.  This led to huge inheritance trees.

And reuse would be so easy, because each "Object" would just tell you what its "Methods" were.

I believe nowadays we're allowed to treat a "Class" as a repository of "Methods" and "Properties", which "exposes" its "Methods" as "services" it "provides" to the rest of the application.  And really long "inheritance" trees (and especially Multiple Inheritance) is deprecated.

The reason over-use of State Variables is not a good thing is that it becomes increasingly difficult to verify and validate that a program will work.  Especially if you use the state variables to dramatically change what a program does depending on the state variable.

Now, I've used state-machines, and local storage of a state variable, when necessary.  But usually as a last resort for problems that couldn't be solved any other way.  And yes, they were a pig to debug and verify.
AllanL5
Monday, April 09, 2007
 
 
DEBEDb,

"First, not everything in the physical realm is an entity or an object." That's why I wrote "Any entity of the physical realm is an object." But I recognize the ambiguity of my own statement. I'll rephrase it "Everything in the physical realm is an object". Even mass and speed and forces are physical objects. (state parameters are points in the phase space).

I didn't write in my post "it's like the physical world" anywhere. OO is part of the physical world, but like son of parnas was writing, that's not really that important

"Our mind puts borders around things and makes them objects. Therefore the data structures and functions of programming languages are objects." This is a limitation of logical reasoning. Regardless what we call any of the programming artifacts, they all are physical objects.
Dino Send private email
Monday, April 09, 2007
 
 
> I've used state-machines...And yes, they were a pig to debug and verify.

State machines are the only things you can verify because there is a statement of what is supposed to happen. Otherwise you are just churning and testing your code into submission. What is more solid than communicating state machines? Nothing. But programmers simply do not like that level of rigor.
son of parnas
Monday, April 09, 2007
 
 
Once upon a time, somebody wrote "A Program == Data Plus Code".

Meaning, a good balance between the code execution, and the data structures used, led to a good program.  'Good' here meaning one easy to verify, and easy to modify, and one easy to keep reliable.

As long as somebody in a design review will point to a 'struct' (a data structure without methods) and say "THAT'S not OO!" or "That's PROCEDURAL programming!" then there's still something wrong with the OO community.  Even Stroustrup has said it's not necessary to lock everything into an OO architecture.

But I percieve that's a problem with the culture, not with OO programming in general.
AllanL5
Monday, April 09, 2007
 
 
Dino,

"OO is part of the physical world,"

I have to disagree. OO as a software concept is part of the virtual world. While the virtual world needs the physical world for execution, it is nonetheless a completely different world with a completely different set of rules.

Basically, OO is just another way to express ideas in the virtual world. While it may be a good concept to describe the physical world, and a lot of our problems we want to solve with software are coming from this world, it represents only a subset of what is possible in the virtual world.

One rule of software is that even reduced concepts can solve ANY problem that is solvable with software, as long as some basic requirements are fulfilled, e.g. Turing Completeness. It is only the question of how complex and complicated the solution for a specific problem will be in a given concept.

If anyone claims "X sucks" or "X is the solution of all problems", the first reaction should be doubt. Software developers should know better.
Secure
Monday, April 09, 2007
 
 
If OO is a useful abstratction for a particular problem, then use it.  If not, don't.

The OP may be objecting to "pure" OO languages (e.g., Smalltalk) where literally everything is an object.  Other languages (e.g. C++) don't have this restriction. 

FWIW, I see LOTS of examples where programmers would have been much better served by using OO techniques, and/or by using OO techniques properly (i.e., it's not enough to wrap some procedural code in a pair of squiggles and call it a class).

Then again, I have more of a data modelling background than many programmers, so I find OO a very natural approach.
BillT Send private email
Monday, April 09, 2007
 
 
"If OO is a useful abstratction for a particular problem, then use it.  If not, don't."

...and there you have it.  I wish that this was the first response to the post.
old.fart
Monday, April 09, 2007
 
 
Secure,

"OO as a software concept is part of the virtual world."

OO is as physical as the geometrical point is (or any of our sciences for that matter). Saying that OO is part of a virtual world and not physical is a dangerous concept because if that is true, the same is true for all of human sciences that rely on mathematics.

Unfortunately you are not entirely right and not entirely wrong. The key is to realize that human knowledge is only a small and random partition of reality. Even more, the part of reality that is accessible to human study and discovery is very small.

For example, the set of real numbers which we know or we could know (i.e. there is a finite algorithm to calculate them) is countable(as many as integer numbers = Aleph0). However there are far more real numbers (Aleph1 = 2 ^ Aleph0) and most of them we'll never know. These numbers are not just random sequences of bits, they are also non-computable: we cannot compute nor know their bits.

For example we cannot compute the bits of the Omega number (George Chaitin) because we cannot determine if any given Turing machine Tn will halt or not for all natural n. Even more important, nothing of what we know at bit n will help us determine the value of bit n+1. The n+1 bit can be obtained only through discovery and that process is essentially a random search.

A second example, probably more relevant, is human knowledge itself. We can assume that all human knowledge can be written down in some sort of encyclopedia. If that's a file on a computer, that file is a sequence of bits. Sort the data and then compress it. In the end the result is a random sequence of bits = random real. And the next discovery will add some bits to that random real, however until we make our discovery we don't what they are.

Back to "OO sucks", OO is a random scientific fact which is as physical as physics itself. It is something Mr Stroustrup stumbled upon by accident (an accident aka as C++). Its suckiness is as random as the concept itself.
Dino Send private email
Monday, April 09, 2007
 
 
Dino, did you ever meet McKinstry?  He used to talk like that too.
AllanL5
Monday, April 09, 2007
 
 
"XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign."

http://www.tbray.org/ongoing/When/200x/2007/04/08/James-Clark
throw ''
Monday, April 09, 2007
 
 
Oh, no, not again.

I remember when OO was something "an average programmer" would have trouble with.  Now it's "Functional Programming". 

Deep sigh.
AllanL5
Monday, April 09, 2007
 
 
Dino,

you seem to have missed this part of my post: "While the virtual world needs the physical world for execution"

You wrote:

"Saying that OO is part of a virtual world and not physical is a dangerous concept"

Beside that I said "OO as a software concept"... Dangerous... I like this. ;) If we actually happen to talk about the same definitions of both, I think that not distinguishing between physical and virtual (or hardware and software) is much more dangerous. Theoretizations about Alephs and Omegas aside, the danger manifests itself in laws like Copyright and patents, introduced when information was strictly bound to media and doing a lot of real damage today.
Secure
Monday, April 09, 2007
 
 
I use OO for one primary reason.  It provides a good mechanism for organizing code into modules.

I started in what the referenced author must finds as the good old days doing purely functional development in assembly and later C.  Functions tended to be extremely long and the guidance was try to limit a function to a single page of printed text.  This guidance was frequently violated even by "good" programs and abused by some deviant monsters.  In OO code, I have rarely seen a function come close to violating the old single page rule; I am much more likely to encounter single line methods then 80 line plus methods.

The understanding of a function is not nearly the simple experience described by the writer when dealing with long functions.  I would also note that functions do have state, this is why we have local variables.  State change is also hidden in functional programming; this happens whenever a function calls a subroutine.  The data in the original function has been changed by an outside source.

As for reuse, this has succeeded at the micro level, though not at the indermediate level prophesized by some evangelists.  In procedural code, it was quite common to see blocks of code copied and pasted throughout.  It was a challenge when the operation of this code needed to change or when some bright guy decided he could do it slighly better in section of code.  In OO, these blocks tend to be consolidated into a class, implemented once, and reused throughout the code.

Is OO the prefect mechanism for organizing code, no probably not.  It is, however, much better than what we had during the days of functional decomposition.
Wayne M.
Tuesday, April 10, 2007
 
 
Wayne M, functional programming means using languages
like Haskell and Miranda. What you were doing was not
functional programming, it was assembly programming.
I don't think C even qualifies as procedural
programming; that would be languages like Pascal, Ada
or Modula. And you will have a hard time explaining
to me why the language Modula is not modular; if
modules are what you need procedural has them in spades.
Object hater
Tuesday, April 10, 2007
 
 
Well, of course Object Hater, you understand that Wayne never said "Functional Programming", that he was using the term "function" (little-'f') and "functional development" to refer to what you call "procedural programming".

Since 'C' calls them 'functions', I think that's a natural way to talk about it.  I'm sure he wasn't expecting a kind of Spanish Inquisition.
AllanL5
Tuesday, April 10, 2007
 
 
Oops, he DID use the term "functional programming" (little-'f', little-'p') once.  Oh well.

And usually "storing state" in a procedure, function, or module (whatever you want to call them) results in a 'static' variable in that function which 'stores state'.  If all of your variables are NOT static, you're right, there IS 'state', but it's not maintained from invocation to invocation.
AllanL5
Tuesday, April 10, 2007
 
 
AllanL5,

I didn't not meet McKinstry. Actually I didn't know about him until 5 minutes ago. And although we may talk about similar things, I'm not emotionally unbalanced, I don't do drugs nor  armed standoffs with the police :)

Instead I to read on sciences - math & physics - and then to observe their principles at work in daily life. All that to keep my brain trained and firing at appropriate rates.

But I'm only an average person, enjoying the little things of life. That's all.
======================

Secure,
Beyond Copyright and legal terms, the theory is equally important to practice ;) However, you're right, in today's context Copyright and legals terms are considered more important than knowledge. How wrong can that be?
Dino Send private email
Tuesday, April 10, 2007
 
 
Sorry, Dino, I didn't mean to be snarky.  It sounded like you were confusing a model of reality with reality there, for a little bit, but apparently not.  McKinstry loved to do this, which is why it reminded me of him.
AllanL5
Tuesday, April 10, 2007
 
 
Oh, and you can Patent an idea, you Copyright an expression of an Idea.  You can do the one, the other, both, or neither as you please.

Knowledge is always important.  The question is, what protections do you need to keep control of the idea, so you may release it for the good of humanity, or make money off of it, (or both) whatever your goal happens to be
AllanL5
Tuesday, April 10, 2007
 
 
"...a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, someone asked him: 'If you could do Java over again, what would you change?'
'I'd leave out classes,' he replied. After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible..."
OneMist8k
Wednesday, April 11, 2007
 
 
Well implementation inheritance and aggregation, and
their associated bad style of programming, are the
whole point of OO. Most of the other features that are
supposedly OO already existed in procedural languages,
and all of the rest already existed in high level
declarative languages.

e.g. I keep trying to point that interfaces, classes,
namespaces and other such accumulated baggage
are OO-languages' half-assed implementations of modules,
just as "polymorphism" and generics are OO-languages'
half-assed implementations of true polymorphism.

The only thing added by OO-languages is implementation
inheritance, and the only things added by OO-design are
the treating of your code as a simulator and the
atomizing of your algorithm into lots of tiny bits of
code associated with different containers.

This
(a) makes your algorithm harder to understand
(b) smears dependencies through your code
(c) forces your code into a low-level model of what the
    processor is doing rather than a high level model of
    what is the desired result, which is harder to reason
    about and debug
and
(d) gets so complicated that it makes your could much
    bigger, and therefore slower and harder to debug or
    maintain (Fragile base class, anyone?)

But the response I get is always first a shopping list
of the alleged advantages of OO. I point out that these
are irrelevant because the non-OO languages like Modula
already had these, so you don't gain anything by moving
to OO.

Then I get told that all the disadvantages of objects
would magically go away if I were using SmallTalk, and
that since I obviously can't find a job in a 733t,
SmallTalk-using company, I must be a really crappy
programmer.

One thing I never hear is a convincing refutation of the
appalling shortcomings of OO.
Object hater
Wednesday, April 11, 2007
 
 
> One thing I never hear is a convincing

It's unlikely anyone called "object hater" is going to hear much of anything that is convincing.


> half-assed implementations of modules,

Modules are just huge dumping grounds for state and functions. The ability to structure a system with OO happens at a much lower level granularity. Which feeds into:

> smears dependencies through your code

Your dependencies are only smeared of you decides their was an advantage to specializing something into an object. Otherwise you would just fold it in and avoid the dependency. So somebody made the decision that conceptual clarity, cohesiveness, unit testability, and documentability, and specializability was worth the cost. You think differently from a distance based on your hatred of objects.
son of parnas
Wednesday, April 11, 2007
 
 
No, son-of-parnas, you have the causality backwards,
my hate of objects comes from the problems with OO code.

Secondly, the "cost" of using OO is exactly
"conceptual clarity, cohesiveness, unit testability,
documentability, and specializability", which I have
observed intimately closely, not "at a distance".

I have spent years of my life trying to maintain and debug
the OO hellholes produced by other people. The whole point
of the codebase was (a) to manage a few large matrices,
and (b) log some http requests, so the codebase should have
been almost trivially simple, only "someone" decided
"a much lower level granularity" was a good idea and
created an inheritance nightmare.

Now I don't design my modules so badly that the result
is a "dumping ground". If you do, inheritance is the
last thing I should trust you not to abuse, especially
if I have to maintain your code afterwards.

The problem with OO-languages is that they put this
maintainability-armageddon in the hands of everybody.
Object hater
Wednesday, April 11, 2007
 
 
> No, son-of-parnas, you have the causality backwards,

Didn't you just say that?

> I have spent years of my life trying to maintain and debug
the OO hellholes produced by other people.

I have spent many years driving on the road with idiot drivers. Do I blame the cars? Do I stop driving?

> The whole point of the codebase

You spend many years on one code base and conclude something true for OO in general. Causality is unhappy.

> I don't design my modules so badly that the result
is a "dumping ground"

And I don't design my objects the way you said, though I have a feeling you might find a problem with any codebase if it disagrees with your mental model.


> in the hands of everybody.

Modules can be created by anyone. And they become dumping grounds of unrelated junk. Single assignment molds this confusion into something safe, but that doesn't mean the approach is faultless.
son of parnas
Wednesday, April 11, 2007
 
 
Object hater,

"d) gets so complicated that it makes your could much
    bigger, and therefore slower and harder to debug or
    maintain (Fragile base class, anyone?)"

My experience of the last few years is quite of the opposite.

One problem I find with OO is not OO itself (which is yet another tool) but the way people adopt it. Basically everybody jumps on OO bandwagon and expects that the OO alone will make them a better programmer. Unsurprisingly, that doesn't happen. Quality programming has a very long learning curve regardless of the method (OO or not); one should try both the text book and his own ideas to find out what works and what doesn't; and how things work too. Just reading Mr Booch's sell list or learning java syntax and APIs doesn't make anybody a better programmer, that for sure. Same for design patterns or what not.

And bloody hell, being in in functional programming or structured programming or relational database or whatnot takes the same sort of efforts. In programming, there is no replacement for intelligence, education and hard work (they are all required).

===========

On Gossling's comments: I would allow extends only from abstract classes.

===========

AllanL5,

Usually I don't mistake a model for reality. I hope not. Our models are part of reality and never the other way around. Sciences and their derivatives (e.g. programming) are only one way of cognition - and it's a scientific fact that it's a limited one.
Dino Send private email
Wednesday, April 11, 2007
 
 
son-of-parnas

> I have spent many years driving on the road with idiot
> drivers.  Do I blame the cars? Do I stop driving?

I believe that you will blame the cars if they happen
to be Assembler brand, but will maintain a sweet double
standard for OO brand cars.

> I have a feeling you might find a problem with any
> codebase if it disagrees with your mental model.

If I need to calculate a balance, that is a vector/repeated
addition. The OO alternative would be to create an account
object containing lots of item objects and a sum method,
which would call the item objects add methods, thereby
exploding a simple, clear, immediately understandable
3 line piece of code into 2 paragraphs. Do the same to the
rest of your code and see what that does for your
maintainabilty. Bonus points for framwork disease or
factory-itis. Extra bonus points for some moron coming
along and "extending" your code adding a whole sub-program#
pretending to be a number to your list of items.

Alternatively try teaching OO programming to a non-computer
person but who is still technical. Say a quantitative analyst. Then try teaching him procedural. You'll see the
difference in ease of understanding the code to anyone who
wasn't OO-brainwashed to begin with. I say as someone with
experience of this.

> Modules can be created by anyone. And they become dumping
> grounds of unrelated junk

Except with OO, you can have dumping grounds of unrelated
junk inheriting from other dumping grounds of unrelated junk.

Now riddle me this: if Mort were writing code in something
like Haskell, precisely how could he create spaghettiware?
He'd have trouble getting things even to compile if he didn't
do things properly. And if Mort were writing something in
C++, how could you construct a proof-of-correctness for it?
Object hater
Wednesday, April 11, 2007
 
 
"If I need to calculate a balance, that is a vector/repeated
addition. The OO alternative would be to create an account
object containing lots of item objects and a sum method,
which would call the item objects add methods, thereby
exploding a simple, clear, immediately understandable
3 line piece of code into 2 paragraphs."

select sum(balance) from acount where account in (...)

You don't need to do that, OO or not. Bad example. Try something else.
Dino Send private email
Wednesday, April 11, 2007
 
 
Ooh, O.H., I was with you, until you indicated your preferred alternative to OO was Haskell and formal proofs.

Ouch.
AllanL5
Wednesday, April 11, 2007
 
 
> O.H., I was with you, until you indicated your
> preferred alternative to OO was Haskell and formal
> proofs.

AllanL5, for some purposes verification is a
requirement, period.

This can be done using functional programming,
and I believe with dialects of Ada as well,
because they are clean.

You cannot do this with OO code because it is low
level spaghettiware. I choose the example in order
to illustrate this, not to advocate formal proofs
or a particular language.

If you can think of a better example than formal
proofs please contribute it here.

I would also be grateful if you explain what you
have against proofs and what you have against
Haskell.

I quite like Haskell though my preference would be
to use Python and minimize use of the OO features.
Object hater
Wednesday, April 11, 2007
 
 
"The OO alternative would be to create an account
object containing lots of item objects and a sum method,
which would call the item objects add methods, thereby
exploding a simple, clear, immediately understandable
3 line piece of code into 2 paragraphs."


Why do you think a seasoned OO expert would design things this way, given your specification of an account with a balance query on it? Sounds like the bit abot the item objects and all that is overkill for the problem as you've presented it, and a good OO designer would know this. Certainly agile guys who subscribe to the "Do The Simplest Thing That Could Possibly Work" principle[1] wouldn't start with such a complicated approach.

Maybe you are just the victim of being exposed to really bad code masquerading as OO-code? Heaven knows there's plenty of it around and all of us have suffered from it. Maybe you're mistaking correlation for causation?



[1] http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
Franklin Send private email
Wednesday, April 11, 2007
 
 
I doubt OO spaghetti code is inherently worse than say, Fortran spaghetti.  It is not the language that makes spaghetti, it is the programmer.  I believe it is axiomatic (or perhaps a corollary to Gödel or Murphy) that any sufficiently powerful language must allow you to make a mess.

Structured "gotoless" languages did not stop people from writing spaghetti code.  OO did not stop people from writing spaghetti code.  Haskel does not stop people from writing spaghetti code.

In each case there was an early period when the only people using the new model were passionate about good structure, and the code base reflected that passion.  As the model gained wider acceptance the code base became a muddle.  Your beef is not with OO, it is with mediocre, muddle-headed programmers.
Mikkin
Thursday, April 12, 2007
 
 
Verification may be a "requirement" for some cases, but no matter how many periods you use for emphasis I'm not yet aware of any language that allows useful code to be written and also contains a complete solution to the halting problem.

Formal methods are great for their thing, but it would be interestingly optimistic to assume that they're going to guarantee bug-free software in all situations.

(Also, I thought one of the problems with OOP was the hype - so shouldn't the hype haters be more careful about hyping their own preferred alternative? Or am I suffering inexplicable optimisim again? Next I'll assume that the "objects are evil because they have state, everyone should use Haskell" crowd will learn about stateful programming using monads.)

Thursday, April 12, 2007
 
 
Haskell question: has anyone solved the fragile base function problem?

here's how it works (or, rather, doesn't work so well):
  define func in terms of fa fb and fc
  define fa in terms of fa1 fa2 and fa3
  define fb in terms of fb1 fb2 and fb3
  define fc in terms of fc1 fc2 and fc3

  make a change to fb3. watch the author of 'func' squirm.

We now have thirteen functions. And if any of the functions needs changed for any reason, the author would have no need to know about all the users of it - yet could still cause them serious problems.

Me, I like fucntional programming - but I see potential for some over-hyping.

Thursday, April 12, 2007
 
 
OK for the last time I was not trying to advocate,
much less hype, formal verification. For some
programming, like for my friends working on military
telecoms, it is a REQUIREMENT, meaning if you don't
do it you won't get paid.

Secondly, as far as I can see it you already have
the risk of fragile base functions in programming,
it's not something you only get afflicted by if you
use functional programming. However, if you use OO
you get fragile base classes as well, fun fun fun.

Thirdly, some CONSISTENCY please. GOTOs were removed
from programming languages because programmers write
spaghetti. So if OO gives you spaghetti, you should
remove OO as well, because you can be darn sure when
you have to do maintenance, it will be on spaghetti
written by poor hackers, not brilliant works of art
created by the best computer scientists.
Object hater
Friday, April 13, 2007
 
 
You get good code neither by assuming that
the crappy programmers who came before you
were "seasoned experts", nor by "encapsulation"
or "reuse" of the crap they wrote. You get
good code if it is small, readable, powerful
and easy to reason about.

"Readable" means something sufficiently
verbose that it doesn't look like line noise.
If you don't know what I mean try learning APL.

"Easy to reason about" means that you can
understand a complex piece of functionality
just by looking at it, without having to think
too hard, which implies a level of mathematical
elegance. If you don't know what I mean, compare
the beignner's tutorials for Mathematica and
MUMPS.

"Small" means code that is both so concise that
you can understand the outline of an algorithm
by looking at a page of code, and so small in
terms of absolute codebase size that you can
keep a significant amount of it in your head at
one time. If you don't know what I mean, try
debugging on one of those multi-gigabyte
enterprise software monstrosities that takes an
hour to compile. (Without structure or docs.
With a bug report that only says
"Screen A is wrong". You are allowed to use
Windows->"Search within files" to try and find
which files contain the program text for Screen A.)

"Powerful" means that the few lines of code
you write are sufficient to replicate the
function of thousands of lines in a crappy
language. If you don't know what I mean,
try re-implementing a datawarehouse query
using csv files and assembler instead of SQL and
MDX.

High level languages, such as SQL and MatLab,
and yes -  even functional languages, have these
properties. Take your pick.

OO code does not have these properties and the
whole point of OO design is in order not to have
them. OO design blasts your algorithms into tiny
pieces so that you really can't see the outline
of any complex algorithm on one page, the code
size you have to wade through is much larger, and
any one line of code you look at does not do much.
Bad bad bad.
Object hater
Friday, April 13, 2007
 
 
> OO code does not have these properties and the whole point of OO design is in order not to have them.

The point of OO I think is to let you write class libraries, which have two properties:

* Libraries are reusable
* Classes model 'real-world' entities

For example I might use OO to model a telecom call, and give it methods like establishCall, dropCall, transferCall, putCallOnHold, connectToVoicemail, etc., etc., etc. Once I *have* this library, I can use it in my top-level, application-level, 'transaction-level' code to write the one-page algorithms that you want to see, for example:

switch (numberDialled)
{
 case "*98": call.connectToVoicemail(); break;
 .. etc ...
}

To take another example, I might use OO to model the parts of an airplane:

void airplane.takeOff()
{
  throttle.increase();
  flaps.raise();
}
void airplane.climb()
{
  throttle.increase();
  elevators.left.raise();
  elevators.right.raise();
}
void airplane.turnRight()
{
  throttle.increase();
  elevators.left.raise();
  elevators.right.raise();
  aileron.left.lower();
  aileron.right.raise();
  rudder.right();
}
Christopher Wells Send private email
Friday, April 13, 2007
 
 
> The point of OO I think is to let you write
> class libraries, which have two properties: Libraries
> are reusable, Classes model 'real-world' entities


See, you just don't know what you are talking about. OO is about structuring software. You don't ever need to make a library and their are no real entities in software, just software ones. So your fundamental conception of OO was learned from some 80s Software Engineering comic book.
son of parnas
Friday, April 13, 2007
 
 
> You don't ever need to make a library

Perhaps 'package' or 'component' would be a better word.

> their are no real entities in software, just software ones.

By 'entity', I mean "a noun which exists in the vocabulary of the problem domain or solution domain" (for example 'database', 'customer', etc.).
Christopher Wells Send private email
Friday, April 13, 2007
 
 
@Object Hater

I think you have a poorly informed idea of what OO design is and how it is properly done.  Good OO code has all of the desirable properties you mention in your post above and quite a few others besides.

After reading your post, all of your objections seem to center on the notion of abstraction.  All of the things you mention (readable, small, powerful, easy to reason about) are properties of well-abstracted code.

So in essence, you are claiming that OO technique does not allow for good abstraction? In fact, your later claim, "...the whole point of OO design is in order not to have them" is really a claim that the point of OO design is to avoid abstraction.

C'mon, that's just silly.
Franklin
Friday, April 13, 2007
 
 
> Perhaps 'package' or 'component' would be a better word.

Still wrong. Both words assume an externally facing solution is being constructed instead of the structure to solve an immediate problem.

> By 'entity', I mean "a noun which exists in the vocabulary of the problem domain or solution domain

Again, simply grade school objects. Most objects don't exist in a vocabulary. They are tactical in nature. They solve a problem.
son of parnas
Friday, April 13, 2007
 
 
> Both words assume an externally facing solution is being constructed ...

Which is true: I write a class or package in order for it to be used, either by an end-user (top-level UI) or by a higher-level package (in a layer above this one).
Christopher Wells Send private email
Friday, April 13, 2007
 
 
> write a class or package in order for it to be used,
> either by an end-user (top-level UI) or by a
> higher-level package (in a layer above this one).

That's a service oriented view of objects. Objects can be services, but they are much more than that. Objects are elements and services are long chain polymers. An object is software structured to solve a problem. Most objects are never seen externally. So by focusing only as objects as services you are missing their real power, which is to structure your software for all those good software enginery things like cohesion, coupling, extension.
son of parnas
Friday, April 13, 2007
 
 
Object Hater's point is that we should never use tools that it is possible to use badly.

If he will provide us an example of a tool that it is NOT possible to use badly (but that is, nonetheless, useful)...
Don Edwards Send private email
Friday, April 13, 2007
 
 
@Franklin

On the contrary it is you you have a poorly
informed idea of what a powerful language is.

"Powerful" means:
A) you can can do a lot of work
B) in terms of the problem domain
C) using only a few lines of code
D) using only the primitives of the language
E) without method calls
F) without externally defined data structures
G) and someone else can look at it and see it's correct
H) without really having to think

You get this level of power by modelling your problems
in terms of what results should be achieved (high level),
not what behaviour the solution should exhibit (low level).

With the exception of academic languages, OO languages
are low-level, behavioural and therefore incapable of that
sort of power, which is also why OO programs are hard to
reason about.
Object hater
Friday, April 13, 2007
 
 
"An object is software structured to solve a problem."

Very well stated. However, most programmers just write lines of code and spend no or insufficient time to build proper code and data structure. And that sort of unstructured code sucks, regardless the programming language. Then the "fragile base class" is in fact the "reusing crappy code" problem - which is independent of the programming language.
Dino Send private email
Friday, April 13, 2007
 
 
"G) and someone else can look at it and see it's correct"

This doesn't seem too formal to me ;)

Sorry for beating the dead horse ...
Dino Send private email
Friday, April 13, 2007
 
 
@Don

I claim not that OO is open to abuse but that it
*encourages* bad design and bad code.

I have suggested several times that you should
use declarative high level techniques instead of
low level behavioural techniques. This will also
make the whole codebase smaller and faster.

I also suggest writing large pieces of code,
rather than small snippets that call other small
snippets ad nauseam leading to a DEEP call stack.
It is better to reduce the cognitive load on the
programmer by having as much of the problem as
possible literally on the same page in front of
him (ie go "broad+shallow").

Finally I suggest avoiding inheritance when at all
possible. Sometimes even copy/pasting code (ugh!)
is more maintainable.
Object hater
Friday, April 13, 2007
 
 
> Objects are elements and services are long chain polymers. An object is software structured to solve a problem. Most objects are never seen externally.

I suppose you're referring to implementation-detail-level classes such as iterator, visitor, delegate, listener, lock, etc.
Christopher Wells Send private email
Friday, April 13, 2007
 
 
@Dino

If your specification is eg that the same operation
should be applied to every item in a list, you
can use map in Haskell and be sure (without thinking)
that it is correct to within the physical possibilities
of your hardware (or your Haskell environment is buggy).

If you want to do that with C++ you end up messing
with iterators and loops and perhaps off by one errors.
Even if the code is correct, you can't tell that just
by looking at it.

An automatic verifier will have the same difficulty.
At some point, a human being has to look at the code
and see that it's correct, because even if you have code
that's proven to match its specification, you can't be
sure there aren't any bugs in the spec. But it's still
best to minimize the manual effort involved in the whole
development process.

Maybe I didn't phrase things very well. If you have a
better definition of powerful, please contribute.
Object hater
Friday, April 13, 2007
 
 
> I have suggested several times that you should
use declarative high level techniques instead

I've done this. My program:

    Do What I Want

has still not completed.
son of parnas
Friday, April 13, 2007
 
 
@Object Hater

I was addressing your original definition of "powerful" in my previous reply, so it's not that I have a poorly informed understanding of what "powerful" means - after all it was your earlier posting that provided the definition I was using in the context of my message.

As to your most recent posting, if you are going to change your definitons after each remark, we're not going to get very far, are we? This is especially true if you conveniently alter the definition so that it excludes any model of computation that doesn't appeal to you by inserting qualifiers like "without method calls" for no apparent reason other than to disqualify anything you might not agree with, eh?

Since this sort of thing usually just continues to swirl in ever more meaningless circles, it's probably best to just agree to disagree. Good luck.
Franklin Send private email
Friday, April 13, 2007
 
 
>"Powerful" means:
>A) you can can do a lot of work
>B) in terms of the problem domain
>C) using only a few lines of code
>D) using only the primitives of the language
>E) without method calls
>F) without externally defined data structures
>G) and someone else can look at it and see it's correct
>H) without really having to think

That is a very nice theory. It works, perhaps, if your language perfectly implements your problem domain and has embedded in it all necessary data structure definitions, with the appropriate methods defined as language primitives.

But we don't have such languages. At least, not off the shelf, except perhaps in a few closely-defined domains. Further, most problem domains are changing at a fairly steady rate, in different directions depending (often) on local politics.

Now I've tried to follow the approach of "develop a domain-specific language and then use it" since I was taught Pascal in college nearly 30 years ago - and while it's a nice theory, it's really no better than "write a  monolithic application" - unless the language in which the domain-specific language is developed, supports encapsulation and inheritance.
Don Edwards Send private email
Friday, April 13, 2007
 
 
@Franklin

A powerful language is one where you can do
a lot of work with a single line. You are not
doing that with a method call, you are referencing
lots of lines of code in another location.

It is dishonest to claim that I was changing my
definition. What I was doing was explicitly
ruling out your dubious justification for your
bogus claim that OO languages are powerful.

Let's take me out of the equation. Why don't you
try convincing your local CS Professor that Java
is as powerful as Haskell. There's a good chance
he'll laugh at you.
Object hater
Friday, April 13, 2007
 
 
@Don

I find that you can make a language more powerful
just by making it more mathematical. SQL is an example
that is powerful, practical and widely used, easy
to optimize and frequently understood and programmed in
by non-techies.
Object hater
Friday, April 13, 2007
 
 
@object hater

"A powerful language is one where you can do a lot of work with a single line. You are not doing that with a method call, you are referencing lots of lines of code in another location."

OH, you do understand that when you invoke one of your favorite language's programming constructs, like list comprehension or whatever, that this invocation gets translated into a bunch of other code either built into the language's runtime package or else generated by the language compiler, right?  I mean, you understand that Haskell or Miranda or whatever is not magic, right? It boils down to the same machine code as something written in C# or Smalltalk or whatever language you hate the most. 

Then how is that any different from a method call which references "lots of lines of code in another location?" Do you think that server down the hall from you has a "SQL Chip" inside it that somehow natively understand SQL? All of these languages are abstractions which eventually get turned into "references to lots of lines of code in another location..."

Anyhow, the main reason I'm responding is that I rather resent you calling me dishonest.  You DID in fact provide one definition of "powerful" and then later you provided a different one. Do you deny this? Search the page for the phrase ""Powerful" means" if you doubt me. I'll be awaiting your retraction and apology.

As far as asking the opinion of a computer science professor, I'm sure that most would claim that they are equally powerful because they are all Turing equivalent.

I think the term you really want to talk about is "expressive power" as it's defined in SICP and various other places.  Out of the box, languages like Haskell are probably more expressive than languages like C#, in general (though I don't know of any generally accepted system for objectively measuring and comparing "expressive power").

So what? By the time you include basic libraries, we're back to even, for the most part. Add in the availability of many special purpose libraries for various OO platforms and I think there's a case to be made for the *practical* expressive power of OO.

Anyhow, I'm done with it, provided you don't insult me again. Good luck.
Franklin Send private email
Friday, April 13, 2007
 
 
"I've done this. My program:
    Do What I Want
has still not completed."

No surprise here. Your program is completely messed up and buggy. Try this corrected version:

    Do What I Mean
Secure
Saturday, April 14, 2007
 
 
@Franklin

It is a pretense in the literal sense to take
"power" to mean Turing completeness, when I was
of course referring to expressive power. It is
similarly a pretense to take the word "means"
as always equivalent to "defines" and not
"logically entails", and on that basis to claim
that I have made a redefinition. It is I who
ought to feel insulted, and it is I who await an
apology. And if you think libraries equivalent to
more powerful primitives, try hunting for the
bugs in MFC.
Object Hater
Saturday, April 14, 2007
 
 
"and on that basis to claim
that I have made a redefinition. It is I who
ought to feel insulted,"

Coder Wars Episode IV: A New Definition

"And if you think libraries equivalent to
more powerful primitives, try hunting for the
bugs in MFC."

Coder Wars Episode V: The Straw Man Strikes Back

Watch out for the last episode:

Coder Wars VI: Return Of The OSWIS (Operating System Written In SQL)
Secure
Saturday, April 14, 2007
 
 
> Thirdly, some CONSISTENCY please. GOTOs were removed
> from programming languages because programmers write
> spaghetti. So if OO gives you spaghetti, you should
> remove OO as well, because ....

Is Emerson listening?

In a shop where GoTo was forbidden, one guy "wrote
spaghetti" by setting flags all over the place and
using them in conditionals in places where it was
tough to figure out when and where the flag was set.

So, for CONSISTENCY, we should remove Booleans, integers,
enumerations, IFs, and Select/Case/Switch statements.
Wes Groleau Send private email
Wednesday, April 18, 2007
 
 
> I have suggested several times that you should
> use declarative high level techniques instead
>
> I've done this. My program:
>
>    Do What I Want
>
> has still not completed.

Is that because you want too much?

Maybe it's because "Do what I want" is not
declarative, it's imperative.

  :-)
Wes Groleau Send private email
Wednesday, April 18, 2007
 
 
If you don't like coupling methods to data then use the visitor pattern.

http://en.wikipedia.org/wiki/Visitor_pattern

OOP like anything else in programming it just a tool to use when needed not THE HOLY GRAIL or the ONE TRUE WAY.

Frankly I suggest reading design patterns by the Gang of Four. Patterns are to objects as algorithms are to functions. Basically how to construct objects to do X task.

Before people starting describing algorithms, re-creating commonly done tasks in software was a pain. The same for OOP. Without learning about patterns is hard to see what objects can be truly useful for.

For example the command pattern

http://en.wikipedia.org/wiki/Command_pattern

really helped my software a lot because with it I was able to standardize how various tasks were started by the UI and implement a full undo redo system.

Wednesday, April 18, 2007
 
 
Looks to me the argument is over the fact that to do anything beyond the trivial requires Knowledge, Understanding, Discipline, Skill, Thought, and Effort.  One side complains because OO is not a Silver Bullet that gives automatically correct results.  The other side says that OO is almost a Silver Bullet for some problems.  Bah...Its all no better than a religious war. 

Both sides are right from their own perspective and both sides are wrong from each other's perspective.  Each side can create massive piles of evidence "proving" they are right.  Each side ignores the massive pile of evidence accumulated by the other side.  All that is produced from such argumentation is an increase in entropy and the number of noise bits stored in the hyperspace of the Internet.

The real question is "Can either side get real work done for a cost that's less than the payoff?"  The answer:  It depends.  If the doers in question have enough of the necessary attributes (Knowledge, Understanding, Discipline, Skill, Thought, and Effort) and their environment permits them to use them, then the answer is YES!  If not, no tool no matter how highly hyped is going to make much of a difference.

shouldn't the focus be to be able to produce results for a cost less than the value of the results?  Otherwise, what's the point?

Oh, I see.  Its too much work to assure you have enough Knowledge, Understanding, Discipline, Skill, Thought, and Effort to do the work.  You would all rather argue over the equivalent of how many angels can dance on the head of a pin.
Lionell Griffith Send private email
Thursday, April 19, 2007
 
 
> Both sides are right from their own perspective and both sides are wrong from each other's perspective. 

How wet is water where you are?
son of parnas
Friday, April 20, 2007
 
 
Stick to your functional programming.

If you really hate something, maybe you should just not use it  :)

Choice is a beautiful thing.


I think topics like these are just meant to be argumentative
Steve
Friday, April 27, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz