Anders F Björklund wrote:
> Sebastián E. Peyrott wrote:
> 
>>> Every decade seems to have its programming buzzword:
>>>
>>> 60's: artificial intelligence
>>> 70's: structured programming
>>> 80's: user-friendly
>>> 90's: object oriented programming
>>> 00's: metaprogramming 
>>
>> Then, it may be in D's best interest to start thinking
>> which will be the 10's buzzword ;)
> 
> I am afraid it will be: "virtualization"
> 
> --anders

What do you mean? Isn't virtualization at the core a hardware concept?


-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:

>> I am afraid it will be: "virtualization"
> 
> What do you mean? Isn't virtualization at the core a hardware concept?

Like this: http://www.kernelthread.com/publications/virtualization/

In this case: D#, or other bytecode ?

--anders

Hasan Aljudy wrote:
> Deewiant wrote:
>> Oskar Linde wrote:
>>
>>> Deewiant wrote:
>>>
>>>> Walter Bright wrote:
>>>>
>>>>> The trouble with OOP is, well, not everything is an object. For
>>>>> example, take the trig function sin(x). It's not an object. Of
>>>>> course, we could bash it into being an object, but that doesn't
>>>>> accomplish anything but obfuscation.
>>>>>
>>>>
>>>> sin(x) isn't an object, but x is, and sin can be made a property of
>>>> that object.
>>>
>>> How would you define a binary mathematical function then? atan2(y,x) and
>>> binominal(n,k) for instance.
>>>
>>> /Oskar
>>
>>
>> My reply was somewhat tongue in cheek - I suppose I should have added a smiley.
>> Of course everything is not an object.
>>
>> Although binomial(n, k) I'd define as n.choose(k). <g>
> 
> n.choose(k) is actually /less/ confusing than binomial(n,k)

I disagree, think about how you would do a math problem. It would not involve this sort of syntax.

Bruno Medeiros wrote:
> 
> What do you mean? Isn't virtualization at the core a hardware concept?

Generalized abstraction (ie. virtualization) has become a pretty popular term recently.  I think this may be a product of security paranoia, as "virtualized" is becoming synonymous with "safe."


Sean

Lars Ivar Igesund wrote:
> Hasan Aljudy wrote:
> 
> 
>>I wish the whole world learned object oriented principles from Schock
>>http://pages.cpsc.ucalgary.ca/~schock/courses/w05/cpsc233/lectures.html
> 
> 
> I doubt he is the only lecturer out there to have understood object
> orientation ;)

Yeah .. of course! but I found no resource on the net which can give the kind of understaind of oop that he's given me.

> 
> 
>>The problem is when people look at OOP superficially as a set of tools,
>>e.g. inheritance!
> 
> 
> OOP _is_ a set of tools. Nothing more, nothing less.

no my friend, it's alot more!
oop is a way of thinking (in terms of coding, of course). It's a different way of doing analysis and design.
Object oriented analysis and design produce completely different results from procedural analysis and design.

You can do procedural analysis and design but write code that uses classes and employes inheritance, but your code will still be procedural, because when you thought about the problem you did so procedurally, and the code will inevitable reflect that.

>>OOP is not a set of tools, it's a set of principles. Inheritance is not
>>there just for the sake of it, it serves a very good purpose: increasing
>>cohesion by pulling common/shared code in a super class.
> 
> 
> Yes, and by this you get tight coupling and reduced reusability and
> extendability.

If that happens, it generally means you don't know what you're doing; you're using inheritance the wrong way.


> Principles just get in the way for practicality. Using
> inheritance just for the sake of it, or because of principles, is nothing
> even close to practical.

You don't use inheritance because it's a principle (that's the same as using just for its own sake).
You use inheritance when you find that you need to. i.e. when you find yourself writing too much duplicate code.

A common *wrong* way for using inheritance, is deciding a class hierarchy before doing any kind of analysis for objects.

> But then my programming principles encompass pragmatism :)

Funny you should say so.

Is skipping the analysis and design phases (i.e. diving right into writing code) pragmatic or not?
You can say it's pragmatic .. if you're too lazy to do it! However, you'll actually get the most out of your time if you do a proper analysis and design first.

Hasan Aljudy wrote:
> Walter Bright wrote:
>> "Craig Black" <cblack@ara.com> wrote in message news:dun68p$30kv$1@digitaldaemon.com...
>>
>>> A lot of the bias towards OOP purism comes from Java vs. C++ comparisons, much more convincing than Anything vs. D.  Hopefully the simplicity and power of D can help to eliminate OOP purism.
>>
>>
>> The trouble with OOP is, well, not everything is an object. For example, take the trig function sin(x). It's not an object. Of course, we could bash it into being an object, but that doesn't accomplish anything but obfuscation.
> 
> That's because we've been taught math in a procedural way ;)

Not at all. It's based on functions. Ever heard of functional programming languages? <g>

> Ideally, x, the angle, would be an object, and sin is a method on that object.

???? How about the derivative function? It operates on functions.

Consider something as simple as "+".
real a;
ireal b;
creal c = a + b + a;

Should "+" be a member of a, b, or c?


> Like you said, it'll be a bit confusing if it was an object, but that's not because it can't be an object, but mainly because that's not how we think about it.

No, it's because the only way that pure OOP can make sense is when EVERYTHING is an object. In particular, functions must be objects.
(And then 'object' is a poor word to use).

OO has some great ideas. But overuse of OOP is a disaster. It's unbelievably difficult to write good OO code on a large scale.

Don Clugston schrieb am 2006-03-10:
> OO has some great ideas. But overuse of OOP is a disaster. It's unbelievably difficult to write good OO code on a large scale.

So, how do you design/write lare scale projects?

Thomas

Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Don Clugston schrieb am 2006-03-10:
>> OO has some great ideas. But overuse of OOP is a disaster. It's unbelievably difficult to write good OO code on a large scale.
> 
> So, how do you design/write lare scale projects?

Being careful to avoid over-zealous application of OO. In particular,
avoiding inheritance as far as possible; not defining something as an object unless it really is an object.

I see inheritance hierarchies as being like goto. Seductive, looks good in small examples, very popular at one time, still occasionally useful -- but very dangerous.

Thomas Kuehne wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Don Clugston schrieb am 2006-03-10:
> 
>>OO has some great ideas. But overuse of OOP is a disaster. It's unbelievably difficult to write good OO code on a large scale.
> 
> 
> So, how do you design/write lare scale projects?
> 
> Thomas
> 
I prefer data driven design.  Usually using a database but sometimes using XML or other external format(scripting falls under this in some ways).

And by OOP I assume Don meant inheritance, since the other aspects are not unique to it.

Outside of simple Shape examples in textbooks, implementation inheritance has largely been a failure for reusable or easy to maintain code.  OOP is supposed to be about black box reusability of objects,ie. components but then its main claim to fame is a way to break that abstraction.

see:
http://okmij.org/ftp/Computation/Subtyping/#Problem

-DavidM

Hasan Aljudy wrote:
> Is skipping the analysis and design phases (i.e. diving right into writing code) pragmatic or not?
> You can say it's pragmatic .. if you're too lazy to do it! However, you'll actually get the most out of your time if you do a proper analysis and design first.

I must live in the wrong country, or spend too much time with self-taught programmers, earning their living programming.

Very seldom do I see one who actually thinks before he hits the keyboard. Whe I ask, they frown and say "I've already got it covered!" Yeah, right. And just looking at their code proves them wrong.

With all the UML and stuff floating around, one would think they would have understood the meaning of planning and analysis. And the funniest thing is, on all these programmer's door it says "analyst", not "programmer".

But "UML is for suits." Glad at least the bosses try to get something thought out before it's done. :-(