Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31240 > unrolled thread

Re: About concurrency and functional programming

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: About concurrency and functional programming Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-02-28 12:56 -0600
    Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-02-28 21:26 +0000
      Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-28 21:28 -0500
        Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 08:41 +0000
          Re: About concurrency and functional programming Robert Klemme <shortcutter@googlemail.com> - 2015-03-01 12:34 +0100
            Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 14:26 +0000
              Re: About concurrency and functional programming Joerg Meier <joergmmeier@arcor.de> - 2015-03-01 15:30 +0100
                Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 14:31 +0000
              Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 14:30 +0000
              Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 11:29 -0500
                Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 17:07 +0000
                  Re: About concurrency and functional programming Joerg Meier <joergmmeier@arcor.de> - 2015-03-01 20:12 +0100
                    Re: About concurrency and functional programming Robbie Brown <rob@example.com> - 2015-03-01 20:31 +0000
                      Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 16:13 -0500
                  Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 16:11 -0500
                  Re: About concurrency and functional programming Jerry Stuckle <jstucklex@attglobal.net> - 2015-03-01 16:17 -0500
      Re: About concurrency and functional programming Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-03-01 12:03 -0600

#31240 — Re: About concurrency and functional programming

On 2/27/2015 6:45 PM, Ramine wrote:
> You will notice that "Bartosz Milewski" is saying that object oriented
> programming is not composable in presence of concurrency... but i think
> he is not correct... because what you can do is write near the
> property's interface(and don't forget to use set and get) and the
> methods that they are thread-safe, so when you you will inherit from the
> parent class, you will just read near the interface of the parent's
> class wich one is thread-safe and you will take that into account when
> you will compose by ineritance, and i think that this is easy to do
> and that it's efficient and no need for functional programming.

... Wow... I had known you were an idiot when you thought that Delphi 
was topical in a Java newsgroup, but you've managed to prove yourself 
more idiotic by thinking that composition and inheritance are the same 
thing.

I don't know where you learned object-oriented programming, but however 
much it cost you was a waste of money if you passed without being able 
to distinguish between composition and inheritance.

And, for the record, to see why Bartosz was right, I invite you to write 
code that can swap the head elements of two lists in a thread-safe 
manner, independent of the lists' implementation details (e.g., suppose 
was the result of Collections.synchronizedList and the other was a 
java.util.Vector). If you believe it can be done, then, boy, do I have a 
bargain-rate bridge I can sell you.


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [next] | [standalone]

#31241

On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
> On 2/27/2015 6:45 PM, Ramine wrote:
>> You will notice that "Bartosz Milewski" is saying that object oriented
>> programming is not composable in presence of concurrency... but i think
>> he is not correct... because what you can do is write near the
>> property's interface(and don't forget to use set and get) and the
>> methods that they are thread-safe, so when you you will inherit from the
>> parent class, you will just read near the interface of the parent's
>> class wich one is thread-safe and you will take that into account when
>> you will compose by ineritance, and i think that this is easy to do
>> and that it's efficient and no need for functional programming.
>
> ... Wow... I had known you were an idiot when you thought that Delphi
> was topical in a Java newsgroup, but you've managed to prove yourself
> more idiotic by thinking that composition and inheritance are the same
> thing.
>
> I don't know where you learned object-oriented programming, but however
> much it cost you was a waste of money if you passed without being able
> to distinguish between composition and inheritance.

hmm

Thinking abstractly, inheritance is a perfectly valid way of 
implementing composition. In fact, we can look on inheritance as the 
purest form of composition (in an Object Oriented paradigm). An instance 
of a subclass cannot exist without the superclass extant, the subclass 
is (in part) *composed* of the superclass.

How do you 'distinguish between composition and inheritance'?
(as opposed to distinguishing between composition and aggregation)
they are two entirely different (but ultimately, often connected) concepts.

I do agree that the OP has a somewhat 'unique' way of putting his/her 
ideas across to say the least.


-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31242

On 2/28/2015 4:26 PM, Robbie Brown wrote:
> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>> On 2/27/2015 6:45 PM, Ramine wrote:
>>> You will notice that "Bartosz Milewski" is saying that object oriented
>>> programming is not composable in presence of concurrency... but i think
>>> he is not correct... because what you can do is write near the
>>> property's interface(and don't forget to use set and get) and the
>>> methods that they are thread-safe, so when you you will inherit from the
>>> parent class, you will just read near the interface of the parent's
>>> class wich one is thread-safe and you will take that into account when
>>> you will compose by ineritance, and i think that this is easy to do
>>> and that it's efficient and no need for functional programming.
>>
>> ... Wow... I had known you were an idiot when you thought that Delphi
>> was topical in a Java newsgroup, but you've managed to prove yourself
>> more idiotic by thinking that composition and inheritance are the same
>> thing.
>>
>> I don't know where you learned object-oriented programming, but however
>> much it cost you was a waste of money if you passed without being able
>> to distinguish between composition and inheritance.
> 
> hmm
> 
> Thinking abstractly, inheritance is a perfectly valid way of
> implementing composition. In fact, we can look on inheritance as the
> purest form of composition (in an Object Oriented paradigm). An instance
> of a subclass cannot exist without the superclass extant, the subclass
> is (in part) *composed* of the superclass.
> 
> How do you 'distinguish between composition and inheritance'?
> (as opposed to distinguishing between composition and aggregation)
> they are two entirely different (but ultimately, often connected) concepts.
> 
> I do agree that the OP has a somewhat 'unique' way of putting his/her
> ideas across to say the least.
> 
> 

I would strongly disagree with this.  Inheritance and composition are
two entirely different things, with two entirely different approaches to
programming.  About the only thing they have in common is there is some
kind of relationship between the parts.  But what kind of relationship
is all important.

Composition exists in virtually every programming language, including
assemblers.  The elements of the composition have a "has-a" relationship
with the object.  For instance, a Person has a Name, a BirthDate, and
many other attributes.

Inheritance, OTOH, exists only in Object Oriented languages such as
Java, SmallTalk and C++.  The relationship between the base and the
derived classes is an "is-a" relationship.  For instance, and Employee
is always a Person and has the same attributes of a Person.  However,
the Employee has additional attributes such as StartDate, CurrentSalary
and others.

It's easy to get composition and inheritance mixed up - but even in the
most abstract case they are not the same thing.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31243

On 01/03/15 02:28, Jerry Stuckle wrote:
> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>> You will notice that "Bartosz Milewski" is saying that object oriented

<snip>

>>>
>>> I don't know where you learned object-oriented programming, but however
>>> much it cost you was a waste of money if you passed without being able
>>> to distinguish between composition and inheritance.
>>
>> hmm
>>
>> Thinking abstractly, inheritance is a perfectly valid way of
>> implementing composition. In fact, we can look on inheritance as the
>> purest form of composition (in an Object Oriented paradigm). An instance
>> of a subclass cannot exist without the superclass extant, the subclass
>> is (in part) *composed* of the superclass.
>>
>> How do you 'distinguish between composition and inheritance'?
>> (as opposed to distinguishing between composition and aggregation)
>> they are two entirely different (but ultimately, often connected) concepts.
>>
>> I do agree that the OP has a somewhat 'unique' way of putting his/her
>> ideas across to say the least.
>>
>>
>
> I would strongly disagree with this.  Inheritance and composition are
> two entirely different things, with two entirely different approaches to
> programming.  About the only thing they have in common is there is some
> kind of relationship between the parts.  But what kind of relationship
> is all important.
>
> Composition exists in virtually every programming language, including
> assemblers.  The elements of the composition have a "has-a" relationship
> with the object.  For instance, a Person has a Name, a BirthDate, and
> many other attributes.
>
> Inheritance, OTOH, exists only in Object Oriented languages such as
> Java, SmallTalk and C++.  The relationship between the base and the
> derived classes is an "is-a" relationship.  For instance, and Employee
> is always a Person and has the same attributes of a Person.  However,
> the Employee has additional attributes such as StartDate, CurrentSalary
> and others.
>
> It's easy to get composition and inheritance mixed up - but even in the
> most abstract case they are not the same thing.

Actually, I find that people often get composition and aggregation mixed 
up, personally I can never remember which UML diamond to use for each, 
filled or outlined, I have to write it down :-(

Anyway, here's a thing
(compiles in Eclipse Kepler with compliance = 8)

class A{
    protected Integer state = 99;
}

abstract class B {
	
    protected A a;

    public B() {
       a = new A();
    }
}

class C extends B{

}

public class D{
	
    public static void main(String[] args){
	
       C c = new C();
       B b;
       b = c;
       Integer x = c.a.state;
       Integer y = b.a.state;
       System.out.printf("%d", x);
       System.out.printf("%d", y);
       //prints 9999
    }
}

So, I think we probably agree that B has a composite relationship
with A, C has an inheritance relationship with B, B is a composite.

C 'is a' B. Is C composite by inheritance?

C is certainly 'a B' but B can't 'exist' without C and dies when C dies. 
In at least one way, C 'owns' B. B has no meaning or purpose in the 
system without C, a classic description of composition.

Just a thought.


-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31244

On 01.03.2015 09:41, Robbie Brown wrote:
> On 01/03/15 02:28, Jerry Stuckle wrote:
>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>> You will notice that "Bartosz Milewski" is saying that object oriented
>
> <snip>
>
>>>>
>>>> I don't know where you learned object-oriented programming, but however
>>>> much it cost you was a waste of money if you passed without being able
>>>> to distinguish between composition and inheritance.
>>>
>>> hmm
>>>
>>> Thinking abstractly, inheritance is a perfectly valid way of
>>> implementing composition. In fact, we can look on inheritance as the
>>> purest form of composition (in an Object Oriented paradigm). An instance
>>> of a subclass cannot exist without the superclass extant, the subclass
>>> is (in part) *composed* of the superclass.
>>>
>>> How do you 'distinguish between composition and inheritance'?
>>> (as opposed to distinguishing between composition and aggregation)
>>> they are two entirely different (but ultimately, often connected)
>>> concepts.
>>>
>>> I do agree that the OP has a somewhat 'unique' way of putting his/her
>>> ideas across to say the least.
>>>
>>>
>>
>> I would strongly disagree with this.  Inheritance and composition are
>> two entirely different things, with two entirely different approaches to
>> programming.  About the only thing they have in common is there is some
>> kind of relationship between the parts.  But what kind of relationship
>> is all important.
>>
>> Composition exists in virtually every programming language, including
>> assemblers.  The elements of the composition have a "has-a" relationship
>> with the object.  For instance, a Person has a Name, a BirthDate, and
>> many other attributes.
>>
>> Inheritance, OTOH, exists only in Object Oriented languages such as
>> Java, SmallTalk and C++.  The relationship between the base and the
>> derived classes is an "is-a" relationship.  For instance, and Employee
>> is always a Person and has the same attributes of a Person.  However,
>> the Employee has additional attributes such as StartDate, CurrentSalary
>> and others.
>>
>> It's easy to get composition and inheritance mixed up - but even in the
>> most abstract case they are not the same thing.
>
> Actually, I find that people often get composition and aggregation mixed
> up,

And now you even mix up the topic of the discussion: it was composition 
vs. inheritance.

> personally I can never remember which UML diamond to use for each,
> filled or outlined, I have to write it down :-(
>
> Anyway, here's a thing
> (compiles in Eclipse Kepler with compliance = 8)
>
> class A{
>     protected Integer state = 99;
> }
>
> abstract class B {
>
>     protected A a;
>
>     public B() {
>        a = new A();
>     }
> }
>
> class C extends B{
>
> }
>
> public class D{
>
>     public static void main(String[] args){
>
>        C c = new C();
>        B b;
>        b = c;
>        Integer x = c.a.state;
>        Integer y = b.a.state;
>        System.out.printf("%d", x);
>        System.out.printf("%d", y);
>        //prints 9999
>     }
> }
>
> So, I think we probably agree that B has a composite relationship
> with A, C has an inheritance relationship with B, B is a composite.

Check.

> C 'is a' B. Is C composite by inheritance?

Not sure what that is supposed to mean.  C inherits B and as such 
instances of C contain an instance of A as well.  So in sum, C makes use 
of both concepts but for different purposes.

> C is certainly 'a B' but B can't 'exist' without C and dies when C dies.

No, C does not die but _instances_ of C die!  That's a huge difference. 
  And for all these instances there are just two object identities and 
not three - one for instance of A and one for instance of C.  There is 
no separate identity for instances of B, so there is no composition at 
work.  It's really that simple.

> In at least one way, C 'owns' B.

Not at all.  Ownership is usually not a concept used among classes but 
rather used to describe relationships between instances.

> B has no meaning or purpose in the
> system without C, a classic description of composition.

The purpose of B is to inherit from it (either because it represents an 
abstract concept or purely for implementation inheritance purposes).  If 
there is no class inheriting it then it _may_ be superfluous but the 
fact does not change the purpose of B.  Otherwise all interfaces defined 
in libraries are without purpose if not at least one class in the 
library implements it.  That is silly.

I recommend reading "Object Oriented Software Construction" by Bertrand 
Meyer.  That is the most profound work on various aspects of OO and 
inheritance I am aware of.  You'll be hard pressed to find a language 
that has more ways to do inheritance (and a few other things) than Eiffel.

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#31245

On 01/03/15 11:34, Robert Klemme wrote:
> On 01.03.2015 09:41, Robbie Brown wrote:
>> On 01/03/15 02:28, Jerry Stuckle wrote:
>>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>>> You will notice that "Bartosz Milewski" is saying that object
>>>>>> oriented

<snip>

>> Actually, I find that people often get composition and aggregation mixed
>> up,
>
> And now you even mix up the topic of the discussion: it was composition
> vs. inheritance.

It was a passing comment. Your attempt at ridicule is disingenuous.

<snip>

>> C 'is a' B. Is C composite by inheritance?
>
> Not sure what that is supposed to mean.

What is it you don't understand? I can't think of a clearer way to 
express this in the English language.

Instances of classes are implementation details. They are the result
of trying to express a real world, possibly infinite concept in a finite 
approximation of that world (a computer). Don't get upset if you don't 
understand it, it seems strange at first but it's quite simple really. 
Anyway, I think I understand what the OP means.

> C inherits B and as such
> instances of C contain an instance of A as well.  So in sum, C makes use
> of both concepts but for different purposes.
>
>> C is certainly 'a B' but B can't 'exist' without C and dies when C dies.
>
> No, C does not die but _instances_ of C die!

You shouldn't be thinking about 'instances' at a high level of 
abstraction, that's the point of abstraction, you ignore irrelevant 
details so you have space in your brain to consider higher level concerns.

> That's a huge difference.

No, there really isn't, not at a particular level of abstraction.

<snip>

>> B has no meaning or purpose in the
>> system without C, a classic description of composition.
>
> The purpose of B is to inherit from it (either because it represents an
> abstract concept or purely for implementation inheritance purposes).  If
> there is no class inheriting it then it _may_ be superfluous but the
> fact does not change the purpose of B.  Otherwise all interfaces defined
> in libraries are without purpose if not at least one class in the
> library implements it.  That is silly.

I see, an interface that nothing implements is not superfluous ... OK (?)

> I recommend reading "Object Oriented Software Construction" by Bertrand
> Meyer.  That is the most profound work on various aspects of OO and
> inheritance I am aware of.  You'll be hard pressed to find a language
> that has more ways to do inheritance (and a few other things) than Eiffel.

I have read many books on OO, written several manuals and training 
courses on OO Software Engineering with Java and designed many computer 
systems, and I have used Eiffel. I'm happy that I 'get' this stuff and 
am always interested in what other people think. I have no entrenched 
ideas and prefer to believe that I am free thinking and open to ideas 
from experts and beginners alike, however, I do try to avoid personal 
insults however as they serve no purpose.

Rob

-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31246

On Sun, 01 Mar 2015 14:26:58 +0000, Robbie Brown wrote:

> Your attempt at ridicule is disingenuous.

[...]

> Don't get upset if you don't 
> understand it, it seems strange at first but it's quite simple really. 

Hey pot!

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#31248

On 01/03/15 14:30, Joerg Meier wrote:
> On Sun, 01 Mar 2015 14:26:58 +0000, Robbie Brown wrote:
>
>> Your attempt at ridicule is disingenuous.
>
> [...]
>
>> Don't get upset if you don't
>> understand it, it seems strange at first but it's quite simple really.
>
> Hey pot!

No, it's 'Rob'


-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31247

On 01/03/15 14:26, Robbie Brown wrote:
> On 01/03/15 11:34, Robert Klemme wrote:
>> On 01.03.2015 09:41, Robbie Brown wrote:
>>> On 01/03/15 02:28, Jerry Stuckle wrote:
>>>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>>>> On 2/27/2015 6:45 PM, Ramine wrote:

> ... however, I do try to avoid personal
> insults however as they serve no purpose.

Oops, too many 'howevers'

-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31249

On 3/1/2015 9:26 AM, Robbie Brown wrote:
> On 01/03/15 11:34, Robert Klemme wrote:
>> On 01.03.2015 09:41, Robbie Brown wrote:
>>> On 01/03/15 02:28, Jerry Stuckle wrote:
>>>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>>>> You will notice that "Bartosz Milewski" is saying that object
>>>>>>> oriented
> 
> <snip>
> 
>>> Actually, I find that people often get composition and aggregation mixed
>>> up,
>>
>> And now you even mix up the topic of the discussion: it was composition
>> vs. inheritance.
> 
> It was a passing comment. Your attempt at ridicule is disingenuous.
> 
> <snip>
> 
>>> C 'is a' B. Is C composite by inheritance?
>>
>> Not sure what that is supposed to mean.
> 
> What is it you don't understand? I can't think of a clearer way to
> express this in the English language.
> 
> Instances of classes are implementation details. They are the result
> of trying to express a real world, possibly infinite concept in a finite
> approximation of that world (a computer). Don't get upset if you don't
> understand it, it seems strange at first but it's quite simple really.
> Anyway, I think I understand what the OP means.
> 
>> C inherits B and as such
>> instances of C contain an instance of A as well.  So in sum, C makes use
>> of both concepts but for different purposes.
>>
>>> C is certainly 'a B' but B can't 'exist' without C and dies when C dies.
>>
>> No, C does not die but _instances_ of C die!
> 
> You shouldn't be thinking about 'instances' at a high level of
> abstraction, that's the point of abstraction, you ignore irrelevant
> details so you have space in your brain to consider higher level concerns.
> 
>> That's a huge difference.
> 
> No, there really isn't, not at a particular level of abstraction.
> 
> <snip>
> 
>>> B has no meaning or purpose in the
>>> system without C, a classic description of composition.
>>
>> The purpose of B is to inherit from it (either because it represents an
>> abstract concept or purely for implementation inheritance purposes).  If
>> there is no class inheriting it then it _may_ be superfluous but the
>> fact does not change the purpose of B.  Otherwise all interfaces defined
>> in libraries are without purpose if not at least one class in the
>> library implements it.  That is silly.
> 
> I see, an interface that nothing implements is not superfluous ... OK (?)
> 
>> I recommend reading "Object Oriented Software Construction" by Bertrand
>> Meyer.  That is the most profound work on various aspects of OO and
>> inheritance I am aware of.  You'll be hard pressed to find a language
>> that has more ways to do inheritance (and a few other things) than
>> Eiffel.
> 
> I have read many books on OO, written several manuals and training
> courses on OO Software Engineering with Java and designed many computer
> systems, and I have used Eiffel. I'm happy that I 'get' this stuff and
> am always interested in what other people think. I have no entrenched
> ideas and prefer to believe that I am free thinking and open to ideas
> from experts and beginners alike, however, I do try to avoid personal
> insults however as they serve no purpose.
> 
> Rob
> 

You should try to understand what you read.  And contrary to your claim,
you do have "entrenched ideas", as you show by arguing here.  And BTW,
your "entrenched ideas" are wrong.  You do not "get" this stuff.

For the record, I've been doing OO work since 1988, long before Java.  I
also spent 12 years as an independent consultant writing and teaching
programming classes for corporations (mainly Fortune 500) in the U.S.,
Europe and Asia.  These included Java, C++ and OOAD (using UML).

The only reason I got out of it was I got tired of 75K+ air miles every
year.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31250

On 01/03/15 16:29, Jerry Stuckle wrote:
> On 3/1/2015 9:26 AM, Robbie Brown wrote:
>> On 01/03/15 11:34, Robert Klemme wrote:
>>> On 01.03.2015 09:41, Robbie Brown wrote:
>>>> On 01/03/15 02:28, Jerry Stuckle wrote:
>>>>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>>>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>>>>> You will notice that "Bartosz Milewski" is saying that object
>>>>>>>> oriented

<snip>

> You should try to understand what you read.  And contrary to your claim,
> you do have "entrenched ideas", as you show by arguing here.  And BTW,
> your "entrenched ideas" are wrong.  You do not "get" this stuff.

Ah yes, anyone who disagrees with you must be wrong.

I've met this overblown egotistical attitude countless times over the 
years. It's the single most significant contribution to project failure 
in my experience. I'm sure your employers are grateful for all the extra 
work the government (or whoever) has had to pay for because of your 
inability to even consider that you could be in any way less than 
perfect. Keep up the good work, your boss needs a new Bentley.

> For the record, I've been doing OO work since 1988, long before Java.  I
> also spent 12 years as an independent consultant writing and teaching
> programming classes for corporations (mainly Fortune 500) in the U.S.,
> Europe and Asia.  These included Java, C++ and OOAD (using UML).

Oh look, a pissing contest.


-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31252

On Sun, 01 Mar 2015 14:26:58 +0000, Robbie Brown wrote:

> I do try to avoid personal 
> insults however as they serve no purpose.

On Sun, 01 Mar 2015 17:07:12 +0000, Robbie Brown wrote:

> I've met this overblown egotistical attitude countless times over the 
> years. It's the single most significant contribution to project failure 
> in my experience. I'm sure your employers are grateful for all the extra 
> work the government (or whoever) has had to pay for because of your 
> inability to even consider that you could be in any way less than 
> perfect. Keep up the good work, your boss needs a new Bentley.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#31255

On 01/03/15 19:12, Joerg Meier wrote:
> On Sun, 01 Mar 2015 14:26:58 +0000, Robbie Brown wrote:
>
>> I do try to avoid personal
>> insults however as they serve no purpose.
>
> On Sun, 01 Mar 2015 17:07:12 +0000, Robbie Brown wrote:
>
>> I've met this overblown egotistical attitude countless times over the
>> years. It's the single most significant contribution to project failure
>> in my experience. I'm sure your employers are grateful for all the extra
>> work the government (or whoever) has had to pay for because of your
>> inability to even consider that you could be in any way less than
>> perfect. Keep up the good work, your boss needs a new Bentley.

An observation backed up by empirical evidence is not an insult.


-- 
Not floundering ... just fishing

[toc] | [prev] | [next] | [standalone]

#31257

On 3/1/2015 3:31 PM, Robbie Brown wrote:
> On 01/03/15 19:12, Joerg Meier wrote:
>> On Sun, 01 Mar 2015 14:26:58 +0000, Robbie Brown wrote:
>>
>>> I do try to avoid personal
>>> insults however as they serve no purpose.
>>
>> On Sun, 01 Mar 2015 17:07:12 +0000, Robbie Brown wrote:
>>
>>> I've met this overblown egotistical attitude countless times over the
>>> years. It's the single most significant contribution to project failure
>>> in my experience. I'm sure your employers are grateful for all the extra
>>> work the government (or whoever) has had to pay for because of your
>>> inability to even consider that you could be in any way less than
>>> perfect. Keep up the good work, your boss needs a new Bentley.
> 
> An observation backed up by empirical evidence is not an insult.
> 
> 

The only "empirical evidence" is in your mind.  But I can see you're no
better than other trolls.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31256

On 3/1/2015 12:07 PM, Robbie Brown wrote:
> On 01/03/15 16:29, Jerry Stuckle wrote:
>> On 3/1/2015 9:26 AM, Robbie Brown wrote:
>>> On 01/03/15 11:34, Robert Klemme wrote:
>>>> On 01.03.2015 09:41, Robbie Brown wrote:
>>>>> On 01/03/15 02:28, Jerry Stuckle wrote:
>>>>>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>>>>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>>>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>>>>>> You will notice that "Bartosz Milewski" is saying that object
>>>>>>>>> oriented
> 
> <snip>
> 
>> You should try to understand what you read.  And contrary to your claim,
>> you do have "entrenched ideas", as you show by arguing here.  And BTW,
>> your "entrenched ideas" are wrong.  You do not "get" this stuff.
> 
> Ah yes, anyone who disagrees with you must be wrong.
> 
> I've met this overblown egotistical attitude countless times over the
> years. It's the single most significant contribution to project failure
> in my experience. I'm sure your employers are grateful for all the extra
> work the government (or whoever) has had to pay for because of your
> inability to even consider that you could be in any way less than
> perfect. Keep up the good work, your boss needs a new Bentley.
>

Yes, you have - every time you look in a mirror.

>> For the record, I've been doing OO work since 1988, long before Java.  I
>> also spent 12 years as an independent consultant writing and teaching
>> programming classes for corporations (mainly Fortune 500) in the U.S.,
>> Europe and Asia.  These included Java, C++ and OOAD (using UML).
> 
> Oh look, a pissing contest.
> 
> 

You're the one who brought it up.  Just showing you your experience
isn't very impressive.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31258

On 3/1/2015 12:07 PM, Robbie Brown wrote:
> On 01/03/15 16:29, Jerry Stuckle wrote:
>> On 3/1/2015 9:26 AM, Robbie Brown wrote:
>>> On 01/03/15 11:34, Robert Klemme wrote:
>>>> On 01.03.2015 09:41, Robbie Brown wrote:
>>>>> On 01/03/15 02:28, Jerry Stuckle wrote:
>>>>>> On 2/28/2015 4:26 PM, Robbie Brown wrote:
>>>>>>> On 28/02/15 18:56, Joshua Cranmer 🐧 wrote:
>>>>>>>> On 2/27/2015 6:45 PM, Ramine wrote:
>>>>>>>>> You will notice that "Bartosz Milewski" is saying that object
>>>>>>>>> oriented
> 
> <snip>
> 
>> You should try to understand what you read.  And contrary to your claim,
>> you do have "entrenched ideas", as you show by arguing here.  And BTW,
>> your "entrenched ideas" are wrong.  You do not "get" this stuff.
> 
> Ah yes, anyone who disagrees with you must be wrong.
> 
> I've met this overblown egotistical attitude countless times over the
> years. It's the single most significant contribution to project failure
> in my experience. I'm sure your employers are grateful for all the extra
> work the government (or whoever) has had to pay for because of your
> inability to even consider that you could be in any way less than
> perfect. Keep up the good work, your boss needs a new Bentley.
> 

Oh, and BTW - EVERY project I've managed has come in on time and on (or
under) budget.  And every one has met the client's requirements.  Some
have been small projects - a few hundred person-hours.  But I've had a
couple with dozens of person-years.  And lots in between.

And my clients still want me back, even though I'm not interested.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31251

On 2/28/2015 3:26 PM, Robbie Brown wrote:
> How do you 'distinguish between composition and inheritance'?
> (as opposed to distinguishing between composition and aggregation)
> they are two entirely different (but ultimately, often connected) concepts.

It struck me only long after I wrote that post that Bartosz was not 
referring to composition in the traditional OO 'has-a' sense but rather 
in the functional or transactional sense. "Composition" in this sense is 
meant to refer taking algorithmic units (say, running Dijkstra's 
algorithm on a graph or maybe Tarjan's SCC-finding algorithm) and using 
them as building blocks to solve the problems you want to solve (e.g., 
interprocedural optimization).


-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web