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.

OO philosophy of OO language engines

we often complain about how developers don't "think OO".....

Consider this: each OO engine (.Net framework, Java,....) throws a null reference exception if you try to use a null object. Very well.

Now let's think about what is an object. In pure OO terms, "An object is an instance of a class". Good.

Now let's take a look at the message thrown in a null reference exception: "Object reference not set to an instance of an object".

Hmmmmm...... wait: shouldn't we be talking about the instance of a class?

Shouldn't be the messagge "Object reference not set to an instance of a class"?
But since we don't have a reference we cannot even talk about an object... even a better message could be: "Variable reference not set to an instance of a class".... or "Object not set to an instance of a class"

If we want to promote OO-though, may be someone should start from giving the right terminology inside the OO engines.
Dealing with the correct use of the terms is the first step towards the correct use of the tool.
Johncharles Send private email
Friday, November 18, 2005
 
 
Classes are also objects. It's turtles all the way down baby.
son of parnas
Friday, November 18, 2005
 
 
We all know inside the machine it's all pointers: objects, classes, methods, functions, just everything...

But the goal of an OO engine should be to mask this stuff, and to expose a clean OO representation of adresses & pointers in OO terms...

Right?
Johncharles Send private email
Friday, November 18, 2005
 
 
Java and .NET are hardly the right place to look for good OO design. The class libraries of both violate the Liskov Substitution Principle left and right.

Java has MethodNotSupported, and .NET has NotSupportedException. In a properly designed OO system, there would be no need for either of those exception classes because every class that implemented an interface would actually implement the entire interface.
comp.lang.c refugee
Friday, November 18, 2005
 
 
Good point - the closest I can think of to absolutely pure OO is SmallTalk, which still allows a part of an interface to not be implemented. Are there any actual pure OO languages out there, or is it all a bit like democracy (we all think that we live in one, but no-one asks your opinion before going to war, changing interest rates etc.)
Paul Brown Send private email
Friday, November 18, 2005
 
 
No no no, son of parnas...

we all know that inside the processor it's all pointers: object, classes, methods, functions... everything.

A good OO engine is supposed to mask all this address&pointer stuff and expose a clear OO paradigm to the user (the geek in this case..)

Right?
Johncharles Send private email
Friday, November 18, 2005
 
 
No, no, John.

The essence of a programming language is to provide an un-ambiguous way to specify, to the compiler, higher level concepts from the human.

I think this is one of the reasons 'C' survived so well.  It was a "good enough" high level language, that would compile to very efficient machine code.  "Purity" didn't really matter.  If it did, you'd NEVER have a 'Macro Pre-Processor'.

So, the quality of a programming language is not how 'pure' its implementation of a higher level concept might be.  Instead, it's how efficiently it can implement that higher level concept -- even if 'purity' is reduced.

Even today, efficient use of the processor matters.  Otherwise, C++ would be gone, since Java seems much more 'pure'.  However, Java has that 'run-time' environment in the way, so the performance of C++ preserves it.  So far, anyway.
AllanL5
Friday, November 18, 2005
 
 
>  No no no, son of parnas...

One "no" will suffice. I will not force myself upon you.

> A good OO engine is supposed to mask all
> this address&pointer stuff and expose a clear OO
> paradigm to the user

Toyota is doing pretty well with those hydrid engines. Maybe there's a lesson in that?
son of parnas
Friday, November 18, 2005
 
 
Allan, you're right.

The point is that I'm not talking about the performance of a language. I'm talking about the correct use of a given paradigm in a language that wants to be compliant with it.
And I think that if a language (more precisely: a compiler that translates a language to a machine code) wants to be a successfull programming interface for the humans, first of all he has to be compliant with the terminology of the paradigm... otherwise the human will be puzzled, and he will not grasp the paradigm at 100% - like the null exception i was talking about.


Son of parnas,
the Toyota engine is a mechanical structure. Information, computing and abstraction is totally different from that: fuel vs. hyrodgen combustion is not a matter of abstraction levels, paradigms or concepts....
I wouldn't mix these two things.
Johncharles Send private email
Friday, November 18, 2005
 
 
But while the statement

"An instance of a class is an object"

is true, the converse

"An object is an instance of a class"

is not necessarily so. In C++, .NET and Java, for example, you have the concept of a struct, an instance of which is an object. In .NET, a value type - which in strict terms does not have to be instantiated - is an object as well. Then there's enumerated types - in .NET again, these are first-class objects.

So the error message is rather more accurate than it might seem at first. You could re-phrase it - "Object reference does not refer to an object" for example, but it's perfectly satisfactory as it is. I don't see that it serves to confuse anyone who has already got the concepts of reference types, references, and object lifetimes firmly sorted out in their head. The issue that tripped you up last time - the inability to type-compare a null reference - stems from not having fully internalised those things, at least as they exist in .NET.

It probably helps to have done some old-fashioned C (no idea if you have or not) because once you've got your head properly around pointers, references (in general, and specifically in managed environments like .NET and Java) are less of a challenge.
.NET Guy
Friday, November 18, 2005
 
 
.Net guy,

You got it! Absolutely right. But..... just in case you had any doubts, try to Google "An object is an instance of a class" ...  :)

Here is a bunch of the biggest authorities in OO domain, just look at what they're teaching:

http://www.mathworks.com/access/helpdesk/help/toolbox/ccslink/objects3.html
http://smalltalk.cincom.com/tutorial/version7/tutorial1/vwoop1.htm
http://www.embedded.com/shared/printableArticle.jhtml?articleID=9900943
http://www.codeproject.com/perl/camel_poop.asp
http://www.javaworld.com/javaworld/jw-04-2001/jw-0406-java101.html

They're all teaching the same thing: "An object is an instance of a class".

I know the exception message is just a detail and I know that it doesn't create any problem to someone who already sorted out references... of course! They already got it  :)
Clearly, I am not concerned with people who already figured out these things....
I'm talking about people who newly begins programming and never saw C, no C++, no Pascal, no nothing.

And last but not least: don't worry, I began programming in 1991, and I perfectly internalised those things :)
I never judge people's ability just by reading what he's posting - please don't have the presumption of doing this. ok?
Johncharles Send private email
Friday, November 18, 2005
 
 
Can't an object be *both* an instance of a class and an instance of an object?
N
Friday, November 18, 2005
 
 
> Information, computing and abstraction is totally different from that

You seen certain of that, with nothing more than an assertion behind you.

> fuel vs. hyrodgen combustion is not a matter of abstraction levels,

And what makes you think your question is about abstraction levels? Classes and instances are real things. They represent something in your mind, but they are still as real as anything else you can come up with.

> I wouldn't mix these two things.

As an a priori rule this needs some work.
son of parnas
Friday, November 18, 2005
 
 
"Classes and instances are real things."

Try to touch them.

Maybe each of you should define your understanding and definition of "real" and "things" before continuing this discussion.
Secure
Saturday, November 19, 2005
 
 
:) i knew this was going to end up like this :)

it's too philosophycal.....  tomorrow i'll try to explain why I think that IT & programming is very different from traditional engineering disciplines - like mechanics
Johncharles Send private email
Saturday, November 19, 2005
 
 
No long explanations needed. ;)

Traditional engineering (hardware) is about learning, using and following the rules (laws of nature). You have no choice - there is no perpetuum mobile.

Programming (software) is about making and defining the rules. Even mathematic and logic are no borders - you can write your own programming language with your own set of rules. The only borders are space and time.
Secure
Saturday, November 19, 2005
 
 
"And last but not least: don't worry, I began programming in 1991, and I perfectly internalised those things :)
I never judge people's ability just by reading what he's posting - please don't have the presumption of doing this. ok?"

No offence intended. I don't know anything about your background, so I had no idea if you were a 50-year old engineer with 30 years hardcore realtime C/C++, or six months out of college and wet behind the ears. I can only respond to what you post at face value. I'm happy to take it on trust that you know what you're talking about - you never sounded like you didn't, you just seemed to be having a little difficulty with .NET references specifically, which was where I thought I could help out.

Anyway, as someone pointed out in a different thread, I'm just a clueless manager who doesn't know how to code, so I guess I can talk, eh? :-)

"it's too philosophycal.....  tomorrow i'll try to explain why I think that IT & programming is very different from traditional engineering disciplines - like mechanics"

I have always had difficulty with equating programming with any other discipline except as a distant relation. It's easy to say programming = math or programming = engineering, but in practice neither of these hold up (yes, I'm aware that, essentially, anything = math, but that's way beyond the level I'm talking at here). But here's the thing - I think programming = whatever you want it to be. You can approach it, mentally, from whatever angle you like. Think about it like a mathematicican, and you can design code as if it were a proof, rigorously and logical. Think about it like an engineer, and you can design code as if it were a bridge, applying rules and planning it in every detail, then executing that plan step by step. Think about it like a designer, and you can design code as if it were a new chair, iteratively, with an eye for function and elegance. Or think about it like an artist, and you can design code with the computer as blank canvas, painstakingly adding, changing and reflecting until you're satisfied with what you see.

Now, not every approach is appropriate for every job, and IMNSHO, no approach is suitable for all jobs. How you think about what you're doing depends on a) who you are, b) how you think naturally, and c) what you're applying that thinking to. I've seen people of all those types deliver great software.

Given the ephemeral nature of what we do, I don't know if anyone will ever succeed in 'standardising' software development as a discipline. I'm not sure it's even a desirable goal, except to those who count the beans.
.NET Guy
Saturday, November 19, 2005
 
 
> Try to touch them.

I touch them all the time with an extended sensory system.

Why do you give your sense of touch a special place in the world when its purpose is to convey information to your brain.

We have many ways of doing that.
son of parnas
Saturday, November 19, 2005
 
 
> it's too philosophycal.....  tomorrow i'll try to
>explain why I think that IT & programming is very
>different from traditional engineering disciplines -
>like mechanic

When we have the ability build things one atom a time do you think the other disciplines will become more like software?

BTW, you can try to explain why two things are different without resorting to philosophy, so embrace it.
son of parnas
Saturday, November 19, 2005
 
 
Actually, programming is virtually the equivalent of engineering... in a world where you could affect the laws of nature.

You have a problem with the Planck constant (read e.g.: persistence framework)? No problem, select another one. None of the available ones fits your needs? Again, no problem: make up your own.
Berislav Lopac Send private email
Saturday, November 19, 2005
 
 
Hi, thanks to everyone for the posts...

I'll try to be brief but it's difficult... so it's gonna be long :)

The main point is that software is real but abstract, not physical. This property of software raises one big problem: you cannot represent it directly as it is in the physical world. Yes we have UML, but it's way too inadequate for what I mean by representing directly a thing.
Think of a building or a bridge (the "mechanical" engineering world): it's physical. You can directly draw it as it appears. You can make drawings of it without building any structure. You can explore different solutions on the drawings. You can take a handyman, show him a detailed drawing, and say "Ok, do it like this. Exactly as it is drawn". See what I mean?

As "S.O.P." - change you nick man, it's too long :) - says, we can even think of something like a sensory extension to touch&feel software but there are two points:
1: it would be a physical projection that we invent ourselves, not the physicality of a real thing. The physicality of real things already exist - no human invented the tree I have in front of my window. So the feeling itself would in turn depend on how you invent your projection process.
2: you should have your software already built in order to "feel" it and this brings us to the beginning.

I don't think there's a satisfactory way to physically support the design or creation of software, like the drawings mechanical engineers have, because software itself is abstract by nature: it's not like a bridge or the Toyota engine, or an airport or a buiding, or a petroleum extracting pump...... these are all physical machines that you can directly represent on drawings before realising them. There's no way of doing this with software. The OO paradigm and UML both go near this goal even if by unavoidable trade-offs.
Electronics is a middle-way between the two: you have the pyhsical product (so it's more representable than software) but it's so small that it ends up being too far to be directly grasped by the designer. This is why "building things one atom at a time" as S.O.P. asks, would probably be more like programming than constructing a building......

Now to Berislav's post:
It depends on what you mean by "programming"...
The technology of software is like having redefinable physical rules as you pointed out....
BUT the science of software (that is to say: Computer Science) is not at all like this... absolutely not. Computer science has its well defined laws, just like any science. Go back and read Church, Turing, Chomsky, Kleene, Rice, McCarthy,...  You'll find a mathematical, quite difficult, young, but real science. I sometimes do it when I have troubles like trying to get the declaration interface of a null reference (by the way, .net guy: i'm  still convinced that the problem is of realisation, not theoretical...). It's plenty of NP-difficult, even unresolvable problems...
Unresolvable! Do you realise what this means? More or less, it means that we humans have thought of problems which are mathematically proved unresolvable: we know at least one solution exists, but there can be no software (precisely: no Turing machine) in order to find the solution by computation. Mathematically proved. Just think about it.....

More or less, it sounds like telling to a "traditional" engineer: "Hey, we want to build a machine in order to do this and that. Well we have mathematical proof that doing this and that is physically possible, but it's impossible to build a machine that does it....". It's nonsense in the mechanical world. But this kind of situation can happen in Computer Science, even if - I admit - for not quite everyday problems...

But the average bean-counting-"MBA" manager thinks that IT is like mechanics....  And this is why we programmers have so much trouble!

.Net guy is 100% right when he says that we don't know if it will be possible to "standardise" programming as a discipline... but this is not because software is ephemeral (i don't think it is: UNIX still lives after 30 years or so)... it's just because software is special: it's abstract and complex enough to give serious headaches, but it's practical enough to create expectancies in the average "bean-counting-manager".
Johncharles Send private email
Sunday, November 20, 2005
 
 
> it would be a physical projection that we invent
>ourselves, not the physicality of a real thing.

Why are things we invent ourselves than things invented by some other process?

> you should have your software already built in order to "feel" it and this brings us to the beginning.

Why does it have to be built at all to be real?
son of parnas
Sunday, November 20, 2005
 
 
Umm, I may be picking a nit here, but doesn't NP-Hard mean not that you cannot build a machine to solve the problem, but that there's no way to solve the problem completely that's faster than just enumerating every possible value?
Chris Tavares Send private email
Monday, November 21, 2005
 
 
yep.. but there are np-hard problems and unsolvable ones... (not "unresolvable"... sorry.)  I was telling about these ones. bye!
Johncharles Send private email
Monday, November 21, 2005
 
 
Johncharles, you should separate the design process from manufacturing. These are two different domains, even in software.

A design is always abstract, the design of a bridge is not a bridge. Bridge designs exist even if no bridge is built based on them. I can design classes and objects, with interfaces and fields, and never do the coding.
jquiroga Send private email
Thursday, November 24, 2005
 
 
(sorry for the late post...)

you're right: design and manufacturing is to be kept distinct.
But I tried to explain that the design of a bridge is a direct, 1 to 1 representation of a physical thing: the bridge is physical, and you draw it directly as it will appear.
Software is abstract - is not physical at all. So we have tremendous problems to represent it. And due to the nature of computation, you cannot fully represent software directly as if it was a "bridge" or a physical thing.

This is what was my post was about.... bye.
Johncharles Send private email
Tuesday, December 06, 2005
 
 
Classes ARE objects and its really good.
Consider about following....

Class item{
Long interface;)
}
Class weapon extends item[
another interface.
}
----
class uberFATSOsword extends bastardsword{
 ubersword(){
  prarity=100;
  sellable=true;
  parentsConstructor();  SkillTest()*(user.strength()+user.());

  }
 DealDamage(){
  parent.dealDamage(100+user.getWeight())
  }
}
Now the shop code uses object MAINPROGRAM which type is Class . It searches all its subclasses that extends the Item Class. And uses the Item class interface to define how probably shop has it on sale. Now I can add another item like uberFatsosword just creating another class, and it suddenly gets used by monsters, and added to shops etc... WITHOUT TOUCHING THE SHOPKEEPER CODE.

Classes are objects and you can use them with those interfaces, and they are VERY usefull objects.
Jouni Osmala Send private email
Wednesday, December 07, 2005
 
 
Please don't mind about any bugs in the code, its ugly but it was just meant to explain things how Class Objects could be usefull.
Jouni Osmala Send private email
Wednesday, December 07, 2005
 
 
OO is a state of mind. Back in the day (1987 to 1993 for me) at Smith Corona (remember them?), we used to do OO programming with 8-bit micro-controller (8051) assembly language.

Also, when you create software, you are creating a game. The users are the players, the data is the pieces, the business rules are the rules, the infrastructure is the board. Any similarity to real engineering is purely accidental.
Steve Hirsch Send private email
Thursday, December 08, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz