Prev: Construction of large object
Next: Free Session Tonight on Example Driven Development w Fit - London
From: S Perryman on 21 Oct 2007 12:22
Dmitry A. Kazakov wrote:

> On Sun, 21 Oct 2007 11:41:39 +0100, S Perryman wrote:

>>Nothing wrong with dynamic type checking.

> As I see it, the language should separate types and subtypes, hence types
> and constraints checking. I strongly believe that there is no place for
> dynamic type checks, as all of them can be performed statically.
> Constraints can be checked dynamically. [Downcasting is a
> constraint/subtype conformance check.]

Not quite.
One of the benefits of weakly-typed prog lang envs is the ability to put in
any old rubbish in and try to execute it. Some static type systems can
affect that flexibility with the time taken to get the program correct first.

But as proven long ago by Lisp envs etc, the ability to develop on a whim
in the 'mode' you desire, is very useful.

OTOH, type inferencing is probably a good counter-example (manifest typing
grief etc) .


>>Strong typing.
>>The ability to turn on/off static checking on demand (as with Lisp envs
>>etc) .

> In my view there would be no need in that if the language allowed to
> create/denote a corresponding class of types. I.e. instead of brutally
> turning checks off, we would simply satisfy them.

1. See above.
2. I don't dispute this. But I would like control as to if/when/how the
checks are applied as part of my daily activities.


DK>Both, and interface inheritance from concrete types.

>>Break from the Simula model : inherit from X != substitutable for X.

> Conditional substitutability.

Not quite.
More that substitutability must be either explicitly declared (by a
developer) , or inferred (by a proof system etc) .

Think of the real world.
Because you inherit the properties (genes) of your parents, does not mean
you are substitutable for them in all contexts.


DK>Concurrency support you mean. Yes, integrated in the types system.
DK>(difficult to do)

>>Where possible, I prefer orthogonality.
>>Minimal support in prog langs should be given to allow differing schemes
>>(the "select" , Eiffel SCOOP etc) to be easily implementable.

> It was attempted in Ada and that made the language too complex.

What was the underlying problem ??


> I think that an orthogonality in the end would be incompatible with DbC.

The Eiffel SCOOP approach seems to use such orthogonality.
For example, pre-conditions on 'normal' types become synchronisation
conditions when that type is used in a concurrent env etc.


> This is a
> big issue, as multi-core architectures and distributed systems have
> arrived.

Concurrency is always a big issue, regardless of the underlying sys
architecture.


DK>5. Abstract interface of referential types (AKA pointers)

>>Such as Simulas' "ref(X)" type ??

> So that the semantics of referencing and dereferencing could be defined by
> the user and contracted. And with interface inheritance and supertyping, a
> reference could be made a full equivalent (substitutable) to its target.

Not sure I want people arsing about with refs like that. :-)

Simula realised the key OO semantic differences between identity and state.
The latter is merely a set of values. The former (in s/w - and to a large
degree in the real world) is something physical.

That is why Simula has the ref(X) syntax, and a set of ops ( :- , == , =/=
etc) to distinguish reference assignment/comparison from the value
equivalents.

Even in FP, the purist bastion of value-based programming, the notion of
identity is acknowledged (AFAIK FP langs like Haskell have a 'mutable ref'
type etc) .


Regards,
Steven Perryman
From: Dmitry A. Kazakov on 21 Oct 2007 13:22
On Sun, 21 Oct 2007 17:22:16 +0100, S Perryman wrote:

> Dmitry A. Kazakov wrote:
>
>> On Sun, 21 Oct 2007 11:41:39 +0100, S Perryman wrote:
>
>>>Nothing wrong with dynamic type checking.
>
>> As I see it, the language should separate types and subtypes, hence types
>> and constraints checking. I strongly believe that there is no place for
>> dynamic type checks, as all of them can be performed statically.
>> Constraints can be checked dynamically. [Downcasting is a
>> constraint/subtype conformance check.]
>
> Not quite.
> One of the benefits of weakly-typed prog lang envs is the ability to put in
> any old rubbish in and try to execute it. Some static type systems can
> affect that flexibility with the time taken to get the program correct first.

Why should I want to run incorrect programs? I never could understand this
argument.

> DK>Both, and interface inheritance from concrete types.
>
>>>Break from the Simula model : inherit from X != substitutable for X.
>
>> Conditional substitutability.
>
> Not quite.
> More that substitutability must be either explicitly declared (by a
> developer) , or inferred (by a proof system etc) .
>
> Think of the real world.
> Because you inherit the properties (genes) of your parents, does not mean
> you are substitutable for them in all contexts.

Fine, so what was inherited? Mysterious genes nobody can see? Inheritance
is useless if totally irrelevant to substitutability. But I agree that
context should play an important role to late bindings. It can "complete"
inheritance process ensuring ad-hoc substitutability. In other contexts
this completion might fail. When contexts are static in that respect,
everything would be OK: you can drive the car of your son, but cannot vote
instead of him.

> DK>Concurrency support you mean. Yes, integrated in the types system.
> DK>(difficult to do)
>
>>>Where possible, I prefer orthogonality.
>>>Minimal support in prog langs should be given to allow differing schemes
>>>(the "select" , Eiffel SCOOP etc) to be easily implementable.
>
>> It was attempted in Ada and that made the language too complex.
>
> What was the underlying problem ??

The problem is that concurrency primitives aren't composable. Neither,
procedural ones (like rendezvous and messaging), nor object-based (like
protected object). If you have them separated from the rest of the
language, that does not help you to solve the actual problem in any way. It
just makes it doubly messy.

>> I think that an orthogonality in the end would be incompatible with DbC.
>
> The Eiffel SCOOP approach seems to use such orthogonality.
> For example, pre-conditions on 'normal' types become synchronisation
> conditions when that type is used in a concurrent env etc.

This is basically the "protected object" approach. In Ada one put much hope
in it when it was introduced, but as 10 years of experience have shown it
is too weak in many cases. Further it is inconsistent with multi-methods.
It probably is not that efficient on true multi-processor architectures,
and certainly inefficient on distributed architectures. It would be nice to
let the compiler to program instead of us, but this is an utopia to believe
in.

> Concurrency is always a big issue, regardless of the underlying sys
> architecture.

Yes, but it was successfully ignored by most of programmers.

> DK>5. Abstract interface of referential types (AKA pointers)
>
>>>Such as Simulas' "ref(X)" type ??
>
>> So that the semantics of referencing and dereferencing could be defined by
>> the user and contracted. And with interface inheritance and supertyping, a
>> reference could be made a full equivalent (substitutable) to its target.
>
> Not sure I want people arsing about with refs like that. :-)
>
> Simula realised the key OO semantic differences between identity and state.
> The latter is merely a set of values. The former (in s/w - and to a large
> degree in the real world) is something physical.
>
> That is why Simula has the ref(X) syntax, and a set of ops ( :- , == , =/=
> etc) to distinguish reference assignment/comparison from the value
> equivalents.
>
> Even in FP, the purist bastion of value-based programming, the notion of
> identity is acknowledged (AFAIK FP langs like Haskell have a 'mutable ref'
> type etc) .

IMO there is no identity other than from the problem domain. The language
shall not introduce new identities. If an identity is a solution space
artefact, as it is with references in the most of cases, then why should
somebody want to expose it? All that Java/C# stuff, GC etc, can be happily
thrown out of the language and provided as a set of libraries instead.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: topmind on 21 Oct 2007 16:14

alexandre_pater...(a)yahoo.fr wrote:
> Hi c.o.,
>
> are there a set of fundamental properties a language
> needs absolutely to be an "OOP language" ?
>
> Can we say that an "OOP language" is a language that
> allows to do OO programming (say from a nice OOD)
> without having the limitations of the language turning the
> program into an inextricable mess ?
>
> dynamic typing ?
> static typing ?
> strongly typed or not?
> closures?
> multiple (interface?) inheritance?
> support in the language for DbC?
> pointcuts?
> thread support?
> awareness of the 'nil' concept?
>
> What would be the "properties" of an OO language ?
>
> Once it comes to translating an OO design into
> a program that actually does something in the
> real-world [TM], are there pratical choices other
> than third-generation languages ?
>
> Btw, I'm in my mid-thirties and, no, this is not
> homework ;)
>
> Alex

(I apologize if this gets posted twice. Server burped.)

To figure out the minimum features needed to be called an "OOP
language", first we'd have to establish an accepted definition of OOP.
So far, this has been a daunting task, for nobody seems to agree on a
root set and asking starts massive flamewars.

As far as the other features listed, there will be fans and proponents
of each one and the disagreement about which is more important will be
even wider there than in an OOP root definition.

In short, good luck.

-T-

From: S Perryman on 24 Oct 2007 05:12
Dmitry A. Kazakov wrote:

> On Sun, 21 Oct 2007 17:22:16 +0100, S Perryman wrote:

>>One of the benefits of weakly-typed prog lang envs is the ability to put in
>>any old rubbish in and try to execute it. Some static type systems can
>>affect that flexibility with the time taken to get the program correct first.

> Why should I want to run incorrect programs? I never could understand this
> argument.

The "argument" is when doing exploratory coding etc, in prog langs where
manifest typing is the norm, the time taken to declare all the types + the
compilation times etc hinders the activity.

Of course, it is an argument made often on the basis of worst of breed (C
etc) . One that was killed a long time ago by type inferencing, incremental
compilation (Ada, Modula-2 etc) etc.

That aside, strong typing won the war.

Apart from meta-typing problem domains (if an object supports this
property but not that one, do this or do that etc) , there is nothing
weakly-typed langs/envs can do appreciably faster/safer than a strongly-
typed equivalent.


DK>Conditional substitutability.

>>Not quite.
>>More that substitutability must be either explicitly declared (by a
>>developer) , or inferred (by a proof system etc) .

>>Think of the real world.
>>Because you inherit the properties (genes) of your parents, does not mean
>>you are substitutable for them in all contexts.

> Fine, so what was inherited? Mysterious genes nobody can see? Inheritance
> is useless if totally irrelevant to substitutability.

It is not irrelevant. Merely that it is not equivalent (implicitly or
otherwise) to substitutability.

If Y is substitutable with X, I want a declaration of that fact.
Either by a developer (a contract - they take responsibility therein) , or
by a proof system (as best they can) .

And if/where possible, where substitutability is *not* guaranteed.


> But I agree that
> context should play an important role to late bindings. It can "complete"
> inheritance process ensuring ad-hoc substitutability. In other contexts
> this completion might fail. When contexts are static in that respect,
> everything would be OK: you can drive the car of your son, but cannot vote
> instead of him.

>>The Eiffel SCOOP approach seems to use such orthogonality.
>>For example, pre-conditions on 'normal' types become synchronisation
>>conditions when that type is used in a concurrent env etc.

> This is basically the "protected object" approach. In Ada one put much hope
> in it when it was introduced, but as 10 years of experience have shown it
> is too weak in many cases. Further it is inconsistent with multi-methods.
> It probably is not that efficient on true multi-processor architectures,
> and certainly inefficient on distributed architectures. It would be nice to
> let the compiler to program instead of us, but this is an utopia to believe
> in.

Can we take this bit into another posting (beyond the old Ada rendez-vous +
select mechanisms, I am ignorant of current Ada concurrency mechs) , as
some of the above is quite interesting to me ??


>>Simula realised the key OO semantic differences between identity and state.
>>The latter is merely a set of values. The former (in s/w - and to a large
>>degree in the real world) is something physical.

>>That is why Simula has the ref(X) syntax, and a set of ops ( :- , == , =/=
>>etc) to distinguish reference assignment/comparison from the value
>>equivalents.

>>Even in FP, the purist bastion of value-based programming, the notion of
>>identity is acknowledged (AFAIK FP langs like Haskell have a 'mutable ref'
>>type etc) .

> IMO there is no identity other than from the problem domain. The language
> shall not introduce new identities. If an identity is a solution space
> artefact, as it is with references in the most of cases, then why should
> somebody want to expose it? All that Java/C# stuff, GC etc, can be happily
> thrown out of the language and provided as a set of libraries instead.

The concept of reference ( "that one" as opposed to "the one which is/has
...." ) is an important one.

Consider identical siblings (twins etc) .

In a domain that distinguishes them by human notions such as name, failure
is possible due to name change by deed poll etc. Physically, they are
indistinguishable (ie their "values" are equal) .

To guarantee identity, I would need the most precise GPS coordinates
possible (a box bounding their physical dimensions exacrly) . And those
coords would have to continuously change too. :-)

The questions are :

- how much additional domain information needs to be provided to ensure
that the notion of identity is correctly provided

- what are the consequences of managing that info (the GPS example etc)


Regards,
Steven Perryman
From: Dmitry A. Kazakov on 24 Oct 2007 17:17
On Wed, 24 Oct 2007 10:12:28 +0100, S Perryman wrote:

> Dmitry A. Kazakov wrote:
>
>> On Sun, 21 Oct 2007 17:22:16 +0100, S Perryman wrote:
>
>>>One of the benefits of weakly-typed prog lang envs is the ability to put in
>>>any old rubbish in and try to execute it. Some static type systems can
>>>affect that flexibility with the time taken to get the program correct first.
>
>> Why should I want to run incorrect programs? I never could understand this
>> argument.
>
> The "argument" is when doing exploratory coding etc, in prog langs where
> manifest typing is the norm, the time taken to declare all the types + the
> compilation times etc hinders the activity.

The standard answer to this, which you certainly know, is that instead of
exploratory runs of buggy code [on a fast neutron reactor (:-))], one
better should do it on the compiler.

> Apart from meta-typing problem domains (if an object supports this
> property but not that one, do this or do that etc) , there is nothing
> weakly-typed langs/envs can do appreciably faster/safer than a strongly-
> typed equivalent.

Yes, but there is a lack of simple constructs to produce new types without
excessive [keyboard] typing. I understand why some programmers get
frustrated. We need better type systems.

> If Y is substitutable with X, I want a declaration of that fact.
> Either by a developer (a contract - they take responsibility therein) , or
> by a proof system (as best they can) .
>
> And if/where possible, where substitutability is *not* guaranteed.

Yes

>>>The Eiffel SCOOP approach seems to use such orthogonality.
>>>For example, pre-conditions on 'normal' types become synchronisation
>>>conditions when that type is used in a concurrent env etc.
>
>> This is basically the "protected object" approach. In Ada one put much hope
>> in it when it was introduced, but as 10 years of experience have shown it
>> is too weak in many cases. Further it is inconsistent with multi-methods.
>> It probably is not that efficient on true multi-processor architectures,
>> and certainly inefficient on distributed architectures. It would be nice to
>> let the compiler to program instead of us, but this is an utopia to believe
>> in.
>
> Can we take this bit into another posting (beyond the old Ada rendez-vous +
> select mechanisms, I am ignorant of current Ada concurrency mechs) , as
> some of the above is quite interesting to me ??

Protected object or protected type is an OO counterpart of task. It has
members which are all private. It has functions, procedures and entries (=
methods). Functions can read the members. Procedures see members and can
change them. Entries are like procedures but have waiting queues with
barriers. When a task calls a procedure or entry and that gets through that
is called a protected action. Such actions are mutually exclusive.
Functions can run in parallel (on a multiprocessor computer), but not when
a protected action is underway. Differently to Eiffel (though I don't know
Eiffel's mechanism in detail), a protected action can start on one object,
continue to another and end somewhere else. This is called "requeue"-ing.
This is a very powerful mechanism or gluing parallel code. For example, the
entry barriers cannot depend on the entry parameters. It is clear why. But
one can circumvent this by checking the parameters in the entry and then
requeueing the action according to the parameter values.

In their full power protected objects can live-lock. But with some
limitations, Ada defines it as so-called profiles, one can achieve full
static rate analysis, for example under Ravenscar profile. My impression is
that Ravenscar profile is a more or less a full equivalent of Eiffel's
approach, though with explicit tasks. But again, I am not an expert in
Eiffel.

Yet with all their power protected objects cannot replace rendezvous, and
reverse. (Philosophically this approves that OO and procedural are
complementary.)

>>>Simula realised the key OO semantic differences between identity and state.
>>>The latter is merely a set of values. The former (in s/w - and to a large
>>>degree in the real world) is something physical.
>
>>>That is why Simula has the ref(X) syntax, and a set of ops ( :- , == , =/=
>>>etc) to distinguish reference assignment/comparison from the value
>>>equivalents.
>
>>>Even in FP, the purist bastion of value-based programming, the notion of
>>>identity is acknowledged (AFAIK FP langs like Haskell have a 'mutable ref'
>>>type etc) .
>
>> IMO there is no identity other than from the problem domain. The language
>> shall not introduce new identities. If an identity is a solution space
>> artefact, as it is with references in the most of cases, then why should
>> somebody want to expose it? All that Java/C# stuff, GC etc, can be happily
>> thrown out of the language and provided as a set of libraries instead.
>
> The concept of reference ( "that one" as opposed to "the one which is/has
> ..." ) is an important one.
>
> Consider identical siblings (twins etc) .
>
> In a domain that distinguishes them by human notions such as name, failure
> is possible due to name change by deed poll etc. Physically, they are
> indistinguishable (ie their "values" are equal) .
>
> To guarantee identity, I would need the most precise GPS coordinates
> possible (a box bounding their physical dimensions exacrly) . And those
> coords would have to continuously change too. :-)
>
> The questions are :
>
> - how much additional domain information needs to be provided to ensure
> that the notion of identity is correctly provided
>
> - what are the consequences of managing that info (the GPS example etc)

OK, but to me this is not the concept of reference. It is rather the
concept of a non-copyable objects. I don't need to deal with addresses to
achieve that. I don't even need to have them physically non-copyable. The
compiler is free to move them around as long my program cannot discover two
copies. That might be very useful on a CPU with many caches or in a
distributed system. Reference represents the concept of aliasing. That is
based on the concept of non-copyable objects, but it is more than that.
Quite often this "more" is an overkill. Identity is a yet another concept.
It is just a function returning a comparable value. Ask a twin, what's your
name? and it is done. GPS box does exactly this thing, it responds with
longitude and latitude. What I don't want is the language dictating me how
I implement my identities. And reverse, if my implementation is a
reference, for some reason unrelated to the problem space, then I should be
able to hide that from the clients.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Construction of large object
Next: Free Session Tonight on Example Driven Development w Fit - London