fyi, very interesting Ada paper OOP vs. Readability

fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

in case some did not read this paper, you might found
it interesting.

OOP vs. Readability
Jeffery Carter

It is avaliable for free now from

http://dl.acm.org/authorize.cfm?key=23959

Here is the conclusion. I thought it is worth copying
it here, as I found it very interesting and I have
to agree with it.

----------------------------------
"Conclusion
OOD emphasizes the software-engineering principles of locality,
encapsulation, and information hiding. Using OOD with
composition results in easy-to-read programs that
exhibit low coupling and high cohesion, it is curious
that OOP does not support OOD.

Inheritance gains us something- We had to write less code
using inheritance than we would have to write to
implement these examples using composition, so using
inheritance makes code easier to write. The price for
this benefit is reduced readability.

Using composition gains us something: The result is
easy to read and understand. The price for this benefit
is that we write more code.

There are always tradeoffs in language design. Ada's
expressed design goal, of emphasizing ease of reading and
understanding over ease of writing, means such tradeoffs
should be decided in favor of ease of reading against ease
of writing, This was clearly not done in the case of inheritance.

The goals of inheritance and dispatching, and so of OOP,
conflict with Ada's expressed design goats"
-----------------------------------------

Re: fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

On 5/9/2012 8:06 AM, Nasser M. Abbasi wrote:

> conflict with Ada's expressed design goats"
> -----------------------------------------

sorry, replace  "goats" --> "goals"  :)

This is what happens when one copies directly from PDF
and paste as text in an email reader

--Nasser
  

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 09 May 2012 08:19:47 -0500, Nasser M. Abbasi wrote:

> On 5/9/2012 8:06 AM, Nasser M. Abbasi wrote:
> 
>> conflict with Ada's expressed design goats"
>> -----------------------------------------
> 
> sorry, replace  "goats" --> "goals"  :)

[Scape-]"goats" is very good, actually. A Freudian error. (:-))

AdaCore guys did some OOP bashing too. I lost the link to the paper. It was
discussed in comp.lang.ada a couple of years ago.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Patrick]

Hi Nasser

Thanks for sharing this with the list.

I may be too dumb for the list though....

I can't seem to find the link to read this. On my end it says, "buy this article"
-Patrick

Re: fyi, very interesting Ada paper OOP vs. Readability

[Egil Høvik]

On Wednesday, May 9, 2012 3:39:13 PM UTC+2, Patrick wrote:
> Hi Nasser
> 
> Thanks for sharing this with the list.
> 
> I may be too dumb for the list though....
> 
> I can't seem to find the link to read this. On my end it says, "buy this article"
> -Patrick


try to access throught the author's own gateway:
http://pragmada.x10hosting.com/papers.html

-- 
~egilhh

Re: fyi, very interesting Ada paper OOP vs. Readability

[Randy Brukardt]

"Nasser M. Abbasi" <nma@12000.org> wrote in message 
news:jodq5f$j5f$1@speranza.aioe.org...
...
> There are always tradeoffs in language design. Ada's
> expressed design goal, of emphasizing ease of reading and
> understanding over ease of writing, means such tradeoffs
> should be decided in favor of ease of reading against ease
> of writing, This was clearly not done in the case of inheritance.
>
> The goals of inheritance and dispatching, and so of OOP,
> conflict with Ada's expressed design goals"

The problem with this conclusion, of course, is that inheritance in Ada long 
predates OOP in Ada (Ada derived types have always had inheritance, even in 
Ada 80). So clearly the most original of Ada's designers disagree with this 
conclusion.

I suspect the problem is that the contention that inheritance reduces 
readability is contentious. It's in the same category as use clauses and 
generic instantiation, both of which are original Ada 83 features that make 
declarations appear without appearing in the source code. You can make an 
argument that all of these things harm readability, but it is obvious that 
they all were considered important enough for the usability of the language 
to go in anyway.

I can imagine a language that offered none of these things (inheritance, use 
clauses, generic instantiation), but it's unclear that the result would be 
particularly usable, and whether the extra declarations needed really would 
help readability. (There is an argument that brevity also helps readability, 
after all, and a language with more text is not necessarily more readable.)

I tend to lean toward the explicit side of the fence (I try to avoid use 
clauses because of the maintenance headaches that they cause), but I do know 
that code can be too explicit. People hate it when I write:

          if Ada.Strings.Unbounded."="(My_String, 
Ada.Strings.Unbounded.To_Unbounded_String ("open") then ...

because I refuse to use use clauses in almost all instances. I surely can 
see why they might not find the above as readable as:
         if My_String = "open" then ...

                                      Randy.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> I tend to lean toward the explicit side of the fence (I try to avoid use 
> clauses because of the maintenance headaches that they cause), but I do know 
> that code can be too explicit. People hate it when I write:
>
>           if Ada.Strings.Unbounded."="(My_String, 
> Ada.Strings.Unbounded.To_Unbounded_String ("open") then ...
>
> because I refuse to use use clauses in almost all instances. I surely can 
> see why they might not find the above as readable as:
>          if My_String = "open" then ...

Well, you live and learn! I thought the 'renaming To_Unbounded_String as
"+"' trick was necessary - should have trusted the designers.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Maciej Sobczak]

On May 10, 4:33 am, "Randy Brukardt" <ra...@rrsoftware.com> wrote:

> People hate it when I write:
>
>           if Ada.Strings.Unbounded."="(My_String,
> Ada.Strings.Unbounded.To_Unbounded_String ("open") then ...
>
> because I refuse to use use clauses in almost all instances.

Interestingly, this is a single case where I'm ready to make an
exception and allow the use clause. The reason is not only to make the
above more readable, but to actually admit that Unbounded_String and
String should have equal treatment. The fact that they come from
different packages and one of those packages has the privilege of
having "implicit clause" is a details that should not be exposed.
After all, Unbounded_String and String both represent the same high-
level design concept (that is, they represent the same concept at the
data modeling stage, for example) and differ only in some tradeoffs,
like the set of operations vs. memory usage scheme. These low-level
tradeoffs are not enough to keep these two type so apart, so I usually
do use Unbounded and later write without hesitation for example:

procedure Do_Something (A : in String,
                        B : in out Unbounded_String);

without unnecessary package qualifications.

In short: String and Unbounded_String represent the same concept and
should have equal "coding look and feel".

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 9 May 2012 21:33:18 -0500, Randy Brukardt wrote:

>           if Ada.Strings.Unbounded."="(My_String, 
> Ada.Strings.Unbounded.To_Unbounded_String ("open") then ...

if Standard.Boolean'(Ada.Strings.Unbounded."="(Left => My_String, 
  Right => Ada.Strings.Unbounded.To_Unbounded_String
(Standard.String'("open")) then 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[J-P. Rosen]

Le 09/05/2012 15:06, Nasser M. Abbasi a �crit :
> in case some did not read this paper, you might found
> it interesting.
> 
> OOP vs. Readability
> Jeffery Carter
> 
> It is avaliable for free now from
> 
> http://dl.acm.org/authorize.cfm?key=23959
> 

You might also be interested in an (old) paper of mine:
"What orientation should Ada objects take?"

It's available free of charge if you get to it from the link at
http://www.adalog.fr/publica2.htm

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: fyi, very interesting Ada paper OOP vs. Readability

[Yannick Duchêne (Hibou57)]

Le Wed, 09 May 2012 15:06:55 +0200, Nasser M. Abbasi <nma@12000.org> a  
écrit:

> in case some did not read this paper, you might found
> it interesting.
>
> OOP vs. Readability
> Jeffery Carter
>
> It is avaliable for free now from
>
> http://dl.acm.org/authorize.cfm?key=23959

Do I have to be an ACM member to access it? I don't see neither a link to  
read it on‑line or get the PDF.

I often see links to ACM. Seems for some fees, a one year membership is  
available, with free access to Ada related contents. But I don't know it  
it's worth or not (anyway, not the time for me to pay for that, I expect  
it for a farer future day).

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

On 5/10/2012 8:32 AM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 09 May 2012 15:06:55 +0200, Nasser M. Abbasi<nma@12000.org>  a
> écrit:
>
>> in case some did not read this paper, you might found
>> it interesting.
>>
>> OOP vs. Readability
>> Jeffery Carter
>>
>> It is avaliable for free now from
>>
>> http://dl.acm.org/authorize.cfm?key=23959
>
> Do I have to be an ACM member to access it? I don't see neither a link to
> read it on‑line or get the PDF.
>
> I often see links to ACM. Seems for some fees, a one year membership is
> available, with free access to Ada related contents. But I don't know it
> it's worth or not (anyway, not the time for me to pay for that, I expect
> it for a farer future day).
>

The above link worked for me when I posted it.

Please try this

http://pragmada.x10hosting.com/papers.html

I got the above link from here:

---------------------------------------------

"The other day Jeffrey R. Carter announced that
all his SIGAda papers had been made available for free."

http://ada-dk.org/2012/04/the-jeffrey-r-carter-sigada-papers-freely-available/
-------------------------------------------

You do _not_ have to be ACM memeber.

--Nasser

Re: fyi, very interesting Ada paper OOP vs. Readability

[Georg Bauhaus]

On 10.05.12 13:46, Dmitry A. Kazakov wrote:
> if Standard.Boolean'(Ada.Strings.Unbounded."="(Left => My_String, 
>   Right => Ada.Strings.Unbounded.To_Unbounded_String
> (Standard.String'("open")) then 

   if Standard."=" (Left => Standard.Boolean'
     (Ada.Strings.Unbounded."=" (Left => My_String, Right =>
     Ada.Strings.Unbounded.To_Unbounded_String
     (Standard.String'("open")))), Right => Standard.True) then

Re: fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

On 5/10/2012 9:23 AM, Georg Bauhaus wrote:
> On 10.05.12 13:46, Dmitry A. Kazakov wrote:
>> if Standard.Boolean'(Ada.Strings.Unbounded."="(Left =>  My_String,
>>    Right =>  Ada.Strings.Unbounded.To_Unbounded_String
>> (Standard.String'("open")) then
>
>     if Standard."=" (Left =>  Standard.Boolean'
>       (Ada.Strings.Unbounded."=" (Left =>  My_String, Right =>
>       Ada.Strings.Unbounded.To_Unbounded_String
>       (Standard.String'("open")))), Right =>  Standard.True) then

The above made me make this little scale based on what
little I know about some programming languages I've used.

This is my scale of verbosity of a computer language.

On the left is the least verbose, and on the right is
the most verbose. Feel free to edit and add/adjust as
you feel. ofcourse this is all subjective and for fun.


perl   Matlab    pascal PLI  f77    f95  Java cobol
|       |         |      |    |      |     |    |
<-----------------------+------------------------>
  |     |    |       |            |     |    |
  |     c  scala    c++         SNOBOL HTML Ada
  |
Mathematica

I think too verbose is not good. It makes it hard to
understand the algorithm. Also, too cryptic is not
good. There is a sweet spot in the middle somewhere.

--Nasser

Re: fyi, very interesting Ada paper OOP vs. Readability

[Adam Beneschan]

On Thursday, May 10, 2012 7:47:06 AM UTC-7, Nasser M. Abbasi wrote:

> The above made me make this little scale based on what
> little I know about some programming languages I've used.
> 
> This is my scale of verbosity of a computer language.
> 
> On the left is the least verbose, and on the right is
> the most verbose. Feel free to edit and add/adjust as
> you feel. ofcourse this is all subjective and for fun.
> 
> 
> perl   Matlab    pascal PLI  f77    f95  Java cobol
> |       |         |      |    |      |     |    |
> <-----------------------+------------------------>
>   |     |    |       |            |     |    |
>   |     c  scala    c++         SNOBOL HTML Ada
>   |
> Mathematica
> 
> I think too verbose is not good. It makes it hard to
> understand the algorithm. Also, too cryptic is not
> good. There is a sweet spot in the middle somewhere.

I assume APL was so far on the left of your diagram that it fell off the page.

                     -- Adam

Re: fyi, very interesting Ada paper OOP vs. Readability

[Georg Bauhaus]

On 10.05.12 16:47, Nasser M. Abbasi wrote:

> On the left is the least verbose, and on the right is
> the most verbose. Feel free to edit and add/adjust as
> you feel. ofcourse this is all subjective and for fun.
> 
> 
> perl   Matlab    pascal PLI  f77    f95  Java cobol
> |       |         |      |    |      |     |    |
> <-----------------------+------------------------>
>  |     |    |       |            |     |    |
>  |     c  scala    c++         SNOBOL HTML Ada
>  |
> Mathematica

Cute! In all fairness, though, how can this Cobol
statement count as verbose?

  ADD a b c  TO  d e f  GIVING  g h i

I find this one-liner highly readable, too. I don't
know how to achieve this level of clarity with any
of the other languages. Maybe a vector/array language can
offer something.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Jeffrey Carter]

On 05/10/2012 07:47 AM, Nasser M. Abbasi wrote:
> ...

Adding APL gives:

   APL      perl   Matlab    pascal PLI  f77    f95  Java cobol
   |        |       |         |      |    |      |     |    |
  <---------------------------------+------------------------>
             |     |    |       |            |     |    |
             |     c  scala    c++         SNOBOL HTML Ada
             |
            Mathematica

-- 
Jeff Carter
"If you don't get the President of the United States on that
phone, ... you're going to have to answer to the Coca-Cola
Company."
Dr. Strangelove
32

Re: fyi, very interesting Ada paper OOP vs. Readability

[Niklas Holsti]

On 12-05-10 19:06 , Georg Bauhaus wrote:
> On 10.05.12 16:47, Nasser M. Abbasi wrote:
>
>> On the left is the least verbose, and on the right is
>> the most verbose. Feel free to edit and add/adjust as
>> you feel. ofcourse this is all subjective and for fun.
>>
>>
>> perl   Matlab    pascal PLI  f77    f95  Java cobol
>> |       |         |      |    |      |     |    |
>> <-----------------------+------------------------>
>>   |     |    |       |            |     |    |
>>   |     c  scala    c++         SNOBOL HTML Ada
>>   |
>> Mathematica
>
> Cute! In all fairness, though, how can this Cobol
> statement count as verbose?
>
>    ADD a b c  TO  d e f  GIVING  g h i
>
> I find this one-liner highly readable, too.

And how do you read it? I don't remember such an ADD format, with more 
than one identifier between "to" and "giving", and it does not appear in 
the OpenCOBOL Programmer's Guide at
http://opencobol.add1tocobol.com/OpenCOBOL%20Programmers%20Guide.pdf.

Just splitting hairs, of course...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

On 5/10/2012 11:06 AM, Georg Bauhaus wrote:

>
> Cute! In all fairness, though, how can this Cobol
> statement count as verbose?
>
>    ADD a b c  TO  d e f  GIVING  g h i
>
> I find this one-liner highly readable, too. I don't
> know how to achieve this level of clarity with any
> of the other languages. Maybe a vector/array language can
> offer something.


I forgot my COBOL now, but the above can be written
like this in matlab:

[g h i] = [a b c] + [d e f]

If I count tokens, I see COBOL has 20 and Matlab 17.

So, COBOL did ok in this case, but would not say it is
as clear the Matlab.  I find too many English words
makes it harder to read the logic. I like symbols over
long words, up to a limit ofcourse. For example I find
Perl very hard to understand. While Ada, when the
code is not verbose is easier to read. But I do not
like Ada code when it gets too verbose, and it can
easily become so.

--Nasser

Re: fyi, very interesting Ada paper OOP vs. Readability

[tmoran]

> ...code is not verbose is easier to read.
  Naming, including when to use Use, is very important for
maintainability.  I wonder if anybody gives potential new hires a
programming test "write code to do ..., for a system that will
still be in use 20 years from now."

Re: fyi, very interesting Ada paper OOP vs. Readability

[Zhu Qun-Ying]

>
> The above link worked for me when I posted it.
>
> Please try this
>
> http://pragmada.x10hosting.com/papers.html
>
It seems it only works when clicking the link from the above site. Direct  
access with a url like
http://dl.acm.org/authorize?23959 do not work.

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> Inheritance gains us something- We had to write less code using
> inheritance than we would have to write to implement these examples
> using composition, so using inheritance makes code easier to write. The
> price for this benefit is reduced readability.

inheritance always was definetely WRONG idea.
because inheritance purposely brokes incapsulation/modularity.
you not "gain" some code "for free" (and never will).
you just lose own control on modifications.
contract parent-child is so undefined and unspecific, so one-sided...

inheritance too tightly glues things, you can now reason about
all parts only as "whole". you lost two independent replaceable modules,
but get one complex artefact. that's impressive... but stupid.

OOP and OOD is wrong idea.

Only data abstraction and modularity (without inheritance and, maybe, 
polymorphism) is good.

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> OOP vs. Readability Jeffery Carter
> The goals of inheritance and dispatching, and so of OOP, conflict with
> Ada's expressed design goals

to be more constructive - Ada peoples may look at Standard ML
signatures/structures/functors for inspiration))

Re: fyi, very interesting Ada paper OOP vs. Readability

[J-P. Rosen]

Le 10/05/2012 15:32, Yannick Duchêne (Hibou57) a écrit :
> Le Wed, 09 May 2012 15:06:55 +0200, Nasser M. Abbasi <nma@12000.org> a
> écrit:
>> It is avaliable for free now from
>>
>> http://dl.acm.org/authorize.cfm?key=23959
> 
> Do I have to be an ACM member to access it? I don't see neither a link
> to read it on‑line or get the PDF.
> 
> I often see links to ACM. Seems for some fees, a one year membership is
> available, with free access to Ada related contents. But I don't know it
> it's worth or not (anyway, not the time for me to pay for that, I expect
> it for a farer future day).
> 
ACM made a recent policy that authors are allowed to offer their own
articles from ACM publications for free. They provide special links that
are connected to a given site, and the link gives you free access only
when accessed from that site.

Try it for example from http://www.adalog.fr/publica2.htm. Click on a
link marked ACM, you get the free version. Copy the link, paste it into
your browser: it asks for a fee.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Fri, 11 May 2012 03:01:35 +0000 (UTC), NatarovVI wrote:

> Only data abstraction and modularity (without inheritance and, maybe, 
> polymorphism) is good.

What is abstracted then?

P.S. There is no data without types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

On 5/11/2012 2:14 AM, Dmitry A. Kazakov wrote:
> On Fri, 11 May 2012 03:01:35 +0000 (UTC), NatarovVI wrote:
>

>
> P.S. There is no data without types.
>

I think the functional programmer guys will not be happy to
hear this.

For example, I use Mathematica, and in Mathematica, there is no
data types.  Only expressions. There are transformation
rules to transform an expression from one form to another.

A function called with an expression does transformation using
pattern rules on it. When no more rules can be applied, the resulting
expression is the function result.

But I think in the world of OO and procedural programming, what
you are saying makes sense. One defines a type, then declares
a variable of that type. i.e. data (i.e. variables) always has
a type.  But I do not think this is the case for all programming
languages?

I am now looking at JavaScript and HTML5 (to be part of the
wave of the future of software engineering), and I was
surprised to find it only has one data type for numbers. floating
points. That is it. So, one can't make an integer variable in
Javascript :)

--Nasser

Re: fyi, very interesting Ada paper OOP vs. Readability

[Maciej Sobczak]

On May 10, 4:47 pm, "Nasser M. Abbasi" <n...@12000.org> wrote:
> On 5/10/2012 9:23 AM, Georg Bauhaus wrote:

> perl   Matlab    pascal PLI  f77    f95  Java cobol
> |       |         |      |    |      |     |    |
> <-----------------------+------------------------>
>   |     |    |       |            |     |    |
>   |     c  scala    c++         SNOBOL HTML Ada
>   |
> Mathematica

Cute!

> I think too verbose is not good. It makes it hard to
> understand the algorithm. Also, too cryptic is not
> good. There is a sweet spot in the middle somewhere.

Hmm... You mean - PLI or C++?
After Jeffrey Carter added APL on the left, the "sweet spot in the
middle somewhere" is just where C++ is.

That would be the first post on this group with such brave
conclusion. :-D

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Fri, 11 May 2012 02:32:09 -0500, Nasser M. Abbasi wrote:

>> P.S. There is no data without types.
> 
> I think the functional programmer guys will not be happy to
> hear this.

No less as I am unhappy with functional programming... (:-))

BTW, there is a pun in the name. Functional programming is non-functional
in its core as it strives to remove side-effects while the only purpose of
any computing is side-effects. (:-))
 
> For example, I use Mathematica, and in Mathematica, there is no
> data types.  Only expressions. There are transformation
> rules to transform an expression from one form to another.

Yes, but as mathematicians have learned a century ago this approach does
not work. You cannot take an axiomatic set theory and the proceed like
1={}, 2={{}}, 3={{{}}}... coming to integer arithmetic, real numbers,
functional analysis (Hilbert's program). That does not work even
theoretically in much more powerful models than pitiful FSA, our computers
are.

A type gives you an opportunity to jump over all constructivist's
nightmares. You just define a type Employee and do not care to play God
creating real employees. That is the power of abstraction. Yes, there is a
price to pay. You have to define operations on Employee, you cannot get
them as theorems in the process of construction. This is what typing is all
about.

> But I think in the world of OO and procedural programming, what
> you are saying makes sense. One defines a type, then declares
> a variable of that type. i.e. data (i.e. variables) always has
> a type.  But I do not think this is the case for all programming
> languages?

This is THE case for whole mathematics since Bertrand Russell's time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Georg Bauhaus]

On 10.05.12 20:41, Niklas Holsti wrote:

>> ADD a b c TO d e f GIVING g h i
>>
>> I find this one-liner highly readable, too.
>
> And how do you read it? I don't remember such an ADD format, with more than one identifier between "to" and "giving", and it does not appear in the OpenCOBOL Programmer's Guide at

Somehow I was convinced the above was possible.
Not so, should have checked again. And then,
the ADD formats, while possibly assigning multiple
identifiers and adding multiple operands, do not
do what the above statement would have implied,
sorry. This is all not so clear, after all.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2y5p0sfyg.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> I tend to lean toward the explicit side of the fence (I try to avoid use
>> clauses because of the maintenance headaches that they cause), but I do 
>> know
>> that code can be too explicit. People hate it when I write:
>>
>>           if Ada.Strings.Unbounded."="(My_String,
>> Ada.Strings.Unbounded.To_Unbounded_String ("open") then ...
>>
>> because I refuse to use use clauses in almost all instances. I surely can
>> see why they might not find the above as readable as:
>>          if My_String = "open" then ...
>
> Well, you live and learn! I thought the 'renaming To_Unbounded_String as
> "+"' trick was necessary - should have trusted the designers.

I use that trick (and "use all") when I have many operations to do in a 
scope, but if there is only one or two, it's not worth all of the typing. As 
for putting it in a package and importing and using it, recall the original 
message about making it hard to find declarations...

Ada should have had a "conversion" operator ("#" has been proposed), and 
clearly Ada.Strings.Unbounded should use it. But that gets shot down every 
time it is proposed (and it has been proposed for every language revision 
other than Ada 2012); mainly because a minority think that "+" is perfectly 
good for that. And another minority think that uses "+" on non-numeric types 
is *disgusting*, so we can never get the operators added to packages. A 
perfect impasse.

                                               Randy.


                                         Randy.

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> the only purpose of any computing is side-effects. (:-))

nope. result is purpose. functional programming just
orders that things. it make result "written" in one place.
this result may be "state of world".
so... side-effects is just "undocumented" results.

in the modern parallel world, functional way better than imperative.
because data flows in parallel program will be clearer and more
deterministic.

>> For example, I use Mathematica, and in Mathematica, there is no data
>> types.  Only expressions. There are transformation rules to transform
>> an expression from one form to another.

this is only Mathematica problem, not FP problem.
you perfectly can have and expressions and types.
And check youself by types. look at Standard ML.

Ada has own goods. but process of their "modernisation" brokes
some of this goods. Gnat monopoly is bad.
Ada no more looks like clock mechanic, where any part is in their place((
Language get overcomplicated, because language developers
is changed. It's too young and have small wisdom yet.
instead of introducing simple predictable generally applicable
mechanic, they add many many corner cases.

is Ada+ML can be simplified to some reliable parallelisable language?
what if they modernise Ada packages in spirit of ML module sublanguage...
and send oop to trash.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Georg Bauhaus]

On 13.05.12 05:11, NatarovVI wrote:

> in the modern parallel world, functional way better than imperative.
> because data flows in parallel program will be clearer and more
> deterministic.

In all fairness, contemporary parallelism frequently needs to
handle signals, and emit signals, at well defined points
in time, and in an order dictated by the purpose of the
program. The signals are results of the program's parallel
computations.

In which ways does monadic IO simplify predictability of effects?

Re: fyi, very interesting Ada paper OOP vs. Readability

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> In short: String and Unbounded_String represent the same concept and
> should have equal "coding look and feel".

Good argument. Thanks.

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

>> in the modern parallel world, functional way better than imperative.
>> because data flows in parallel program will be clearer and more
>> deterministic.
> In all fairness, contemporary parallelism frequently needs to handle
> signals, and emit signals, at well defined points in time, and in an
> order dictated by the purpose of the program. The signals are results of
> the program's parallel computations.
> In which ways does monadic IO simplify predictability of effects?

"parallelism is not concurrency"
look at existentialtypes.wordpress.com for terminology explanation.
parallelism is not about predictability. it's only about computational
efficiency of achieving correct result. we can do parallelism without
concurrency.

FP <> Haskell!
i not sayed one word about monads or damned Haskell.
more, personally i do not like Haskell, his "benefits" seems badly 
founded for me. and not only for me.

those buzzy monads... programming with IO no better than imperative. by 
definition. sure it not helps to parallelise and never will.

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

>> Only data abstraction and modularity (without inheritance and, maybe,
>> polymorphism) is good.
> 
> What is abstracted then?
> 
> P.S. There is no data without types.

What do you try to say?
I try to say - there was "Data Abstraction" technology before OOP.
it's like OOP but without inheritance and polymorphism.
Only incapsulation. And that was good.
inheritance break those good incapsulation.
polymorphism makes program reading context-dependent, that can be bad 
also. only incapsulation is always good.
OOP makes problems, not solutions.

P.S. types is just alternative form of program, written purposely for 
checking programmist's errors. (Computer can not check programmer
errors because it don't know what prog needs. Computer can only compare
to equivalent definitions of some program)
So. Data CAN be "without types". Only this will be unsafe.
2+2=4. what type of 2 have? integer? enum? real? set of (2,4)?
until we write we not know. and just cannot check.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 16 May 2012 15:31:18 +0000 (UTC), NatarovVI wrote:

>>> Only data abstraction and modularity (without inheritance and, maybe,
>>> polymorphism) is good.
>> 
>> What is abstracted then?
>> 
>> P.S. There is no data without types.
> 
> What do you try to say?
> I try to say - there was "Data Abstraction" technology before OOP.

ADT was.

> it's like OOP but without inheritance and polymorphism.

A poor abstraction also, because it fails to capture any types relations,
beyond trivial containment.

> Only incapsulation. And that was good.

It wasn't good or bad. ADT predated richer algebras of types, as ad-hoc and
parametric polymorphisms did. There were obvious weaknesses in the ways ADT
worked in early languages. Some of them were overcame, some not until
today.

> inheritance break those good incapsulation.

How?

Containment breaks information hiding principle, separation of interface
and implementation, incapable to express referential semantics, enforces
tree-like structure of objects, break proper abstraction of semantically
integral types ... should I continue?

> polymorphism makes program reading context-dependent, that can be bad 
> also.

How reading can be context free?

> P.S. types is just alternative form of program, written purposely for 
> checking programmist's errors.

Type are not forms of program.

> So. Data CAN be "without types". Only this will be unsafe.
> 2+2=4. what type of 2 have? integer? enum? real? set of (2,4)?
> until we write we not know. and just cannot check.

Which is in self contradiction. If 2 is without a type why are you asking
which type it has?

Data does not exist without types, moreover they do not exist without the
agents interested in these data. In a larger context there are only values,
sets of values, types (sets of values bound by operations defined).

Data is a definite state of some input to some program. That state is
described in terms of values of defined types from the problem domain. So 2
could be data for the left argument of integer +, or an ASCII character
STX, or standard output descriptor, or whatever.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Georg Bauhaus]

On 16.05.12 17:00, NatarovVI wrote:
>>> in the modern parallel world, functional way better than imperative.
>>> because data flows in parallel program will be clearer and more
>>> deterministic.

Modern parallel world is what I'm asking about: the modern world
has a small niche, that of scientific computations, socio-economic
modelling, image processing and the like. But at large, any computation
in a modern world includes two mathematically sound variables in every
problem statement to be solved by programming: TIME and SPACE.
So does Harper (at existentialtype.wordpress.com). See below.
Which is what I am asking about.

Sometimes, well, most of the time, these notions need to be
more precise than those of general efficiency classes O(f(...)).
The modern world poses many problem statements that have more
specific time bounds. Examples:

- Stop the car/train/plain/ship/oven/recorder/saw, and turn
things 1 .. M off.
Now. You have 650 milliseconds for your algorithm, and
the budget allows for at most p processors, buses etc.

- How many traders will likely sell before tomorrow?

These examples include potentially parallel, not concurrent,
sub-computations, and see below what Harper actually says
about how to arrive at parallel.

Note that Harper mentions the "fork-join structure" of
a Quicksort example, and that Randy Brukardt mentions
the overhead that Harper delegates to "the engineers".
The overhead appears vaguely (somewhat imprecisely one might say)
in the following theorem mentioned by Harper.

To quote:

"*Theorem* A computation with work w and depth d can be
 implemented in a p-processor PRAM in time O(max(w/p, d))."

My question then translates into: How precise can O be
for each p?
Because the *problem* statement *requires* that we make
predictions of a certain precision, as outlined in
the modern real world examples above.

>> In all fairness, contemporary parallelism frequently needs to handle
>> signals, and emit signals, at well defined points in time, and in an
>> order dictated by the purpose of the program. The signals are results of
>> the program's parallel computations.
>> In which ways does monadic IO simplify predictability of effects?
> 
> "parallelism is not concurrency"
> look at existentialtypes.wordpress.com for terminology explanation.

That's existstentialtype<del>s</del> where, worth mentioning,
Prof Rober Harper, well known and respected ML guy, offers thoughts.
More specifically, the terminology is here

http://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/

From which I quote:

"Now I can hear you object, but isn’t concurrency
 required to implement parallelism?  Well, yes, it is,
 (...)! The point is that concurrency is not relevant
 to parallelism, even if the engineers who build our
 parallel computing platforms must deal with concurrency."

Paraphrased: How can we parallel programmers rid us of the
real work of implementing hardware and software for our parallel
programs and delegate the not-so-entertaining programming
and computer construction to "the concurrency engineers"?

Don't get me wrong. I rather like the idea of language-based
model of [parallel] computation that assigns "costs to the
steps of the program we actually write". I rather like that.
It is roughly equivalent to my question about predictability.
(Note: not determinism. Predictability of time, storage, and
effects.) And it is an ages old dream.

Note that Ada is between the "horrendous" programming
without language support about which Harper is complaining,
and the envisioned language that has parallel
constructs without all the concurrency things.
Ada, more than other languages, lets you define constructs
made from language that operate in parallel (not concurrent).
Without resorting to "locks, monitors, deadlock, dining
philosophers, …" 


> FP <> Haskell!
> i not sayed one word about monads or damned Haskell.

OK. ML has reference types. (Why?) Again, if they some day 
arrive at a language-based solution that will allow the
removal of reference types etc, and still allow precise
considerations of efficiency of parallel sub-computations,
and further processing of the results of sub-computations,
in time, in the modern world, perfect!

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> From which I quote:
> "Now I can hear you object, but isnt concurrency
>  required to implement parallelism?  Well, yes, it is, (...)! The point
>  is that concurrency is not relevant to parallelism, even if the
>  engineers who build our parallel computing platforms must deal with
>  concurrency."
> 
> Paraphrased: How can we parallel programmers rid us of the real work of
> implementing hardware and software for our parallel programs and
> delegate the not-so-entertaining programming and computer construction
> to "the concurrency engineers"?

this is just terminology. what deals with timings is named "concurrency".
it can be used in implementation for "parallelism" abstraction.
get the difference? parallelism is abstraction, concurrency used in one 
of it implementations (there exist implementations without concurrency,
like f.e. vectorisation for data-parallelism-only situation).

meanwhile, Harper talks about so-named deterministic parallelism. i think 
this kind of parallelism will be what most application programmers want 
use. programmers just want use "universal" runtime wich run their 
"parallel" program (with specified in it all possible parallelism) on 
_any_ modern computer, "efficiently enought".
such choice all programmers already done when select procedure languages 
(like Ada) over assembler.
now just time for next high-levelisation step, abstracting parallelism))

sure there will be niche for system programmers and runtime implementors,
dealing with concurrency. like as assembler programmers exist now.
but, sure again, they will be minority.

> Don't get me wrong. I rather like the idea of language-based model of
> [parallel] computation that assigns "costs to the steps of the program
> we actually write". I rather like that.
> It is roughly equivalent to my question about predictability.
> (Note: not determinism. Predictability of time, storage, and effects.)
> And it is an ages old dream.

"dreams come true"

>> FP <> Haskell!
>> i not sayed one word about monads or damned Haskell.
> OK. ML has reference types. (Why?) Again, if they some day arrive at a
> language-based solution that will allow the removal of reference types
> etc, and still allow precise considerations of efficiency of parallel
> sub-computations,
> and further processing of the results of sub-computations,
> in time, in the modern world, perfect!

why C have goto? legacy... interfacing with other world... etc.
references needed because "some tasks most effectively
solved with imperative solution". parallel solution for it
not found until now. that not means all algoritms must be such!
and references is not used by default.
and that not means that such imperative tasks can not be reformulated
to parallelisable tasks.

in the end, ML is old language. but until now good enought.
and lady Ada do not needs your guard from multyhead ML, knight))

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> ADT was.

in russian - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫

> A poor abstraction also, because it fails to capture any types
> relations, beyond trivial containment.

do you really need other relations? type is builded from set's.

> How?

directly. parent, changing youself, can do any changes on child
functions. child incapsulation broken, because it contains parts defined
elsewhere. and it is not rigorously defined containment, it's
much stronger glue. that is bad. there is no more parent and child 
objects. there is now one, parent-child object. big and complicated.
and developed by more than one programmers independenly.

> Containment breaks information hiding principle, separation of interface
> and implementation, incapable to express referential semantics, enforces
> tree-like structure of objects, break proper abstraction of semantically
> integral types ... should I continue?

nope, all remains isolated in "subcontainer". and if we change it,
"subcontainer" module interface changes and clients see it.
what bad in tree-like?
sure you may continue))
i also may say - i know "karate", "ju-jutsu"... and many other cool 
words))
but all that words not changed my words.

> How reading can be context free?

here is difference i talked about. when you read non-polymorphic prog,
you have "one static context" - language definition. you constantly
use it and know it. in polymorphic prog you must also know and
remember parts of program with poly-func definition. and remember,
which definition (from all definitions) in action now.
one part is no bad. but when such parts from libs interfered 
combinatorically...mmm door to wonders open))

> Type are not forms of program.

types represents categories of expressions.
program steps changing data's. and their types makes very
simplified representation of program steps.
"get int and int, return float".
type is socket-standard for expression jack.

> Data does not exist without types, moreover they do not exist without
> the agents interested in these data. In a larger context there are only
> values, sets of values, types (sets of values bound by operations 
defined).

not exactly. data exist independently. then we attach types to it and can 
do operations (of type). one data can have more than one type.
and operations can be varied with time. f.e. integer or natural or even.
(types can contain other types)
and one type can be attached to different data.

> Data is a definite state of some input to some program. That state is
> described in terms of values of defined types from the problem domain.
> So 2 could be data for the left argument of integer +, or an ASCII
> character STX, or standard output descriptor, or whatever.

yep. data exist independently, and we attach types to it at any time.
and make propositions and state invariants from that moment.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Georg Bauhaus]

On 21.05.12 18:35, NatarovVI wrote:

>  (there exist implementations without concurrency,
> like f.e. vectorisation for data-parallelism-only situation).

Harper's goal is more inclusive; he will, IIUC, ask for the cost,
in terms of O-notation, of vectorization, which is not free.

> now just time for next high-levelisation step, abstracting parallelism

U = 0?

> sure there will be niche for system programmers and runtime implementors,
> dealing with concurrency.

Do you have the facts to back this up?

> and lady Ada do not needs your guard from multyhead ML, knight

What?

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Mon, 21 May 2012 17:23:24 +0000 (UTC), NatarovVI wrote:

>> ADT was.
> 
> in russian - яПНяПНяПНяПНяПНяПНяПНяПНяПНяПН яПНяПНяПНяПНяПНяПН

In Russian it is: яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН яПНяПНяПН яПНяПНяПНяПНяПНяПН, which is a loan translation of
the original English term: Abstract Data Type.

>> A poor abstraction also, because it fails to capture any types
>> relations, beyond trivial containment.
> 
> do you really need other relations?

Sure. The relationships should:

1. reflect relevant relationships of the entities from domain space which
values of these types model.

2. serve purpose of software design per types decomposition, e.g. reuse,
readability, maintainability etc.

> type is builded from set's.

Certainly not. Which type is {-3, 'a', Pi, Employee}? A type cannot be
inferred from its values domain set. It need not to be. This is what gives
so much power to this abstraction. You can model galaxies on a PC because
of that.

>> How?
> 
> directly. parent, changing youself, can do any changes on child
> functions.

No. In a strongly typed language there is no way to have this scenario. It
is a type error.

> child incapsulation broken, because it contains parts defined
> elsewhere.

This is called modular design. In any case it is fully applied to
containment/aggregation. When you put an integer into a record, that brings
with it integer arithmetic defined elsewhere. I find it good.

Note also there is no way to override operations inherited for integer
components, because their type is sealed. On the contrary, inheritance
allows some operations re-implemented.

>> Containment breaks information hiding principle, separation of interface
>> and implementation, incapable to express referential semantics, enforces
>> tree-like structure of objects, break proper abstraction of semantically
>> integral types ... should I continue?
> 
> nope, all remains isolated in "subcontainer". and if we change it,
> "subcontainer" module interface changes and clients see it.

As I said, it defeats the information hiding principle. A leaking
abstraction is a poor one.

> what bad in tree-like?

Not everything is a tree..

>> How reading can be context free?
> 
> here is difference i talked about. when you read non-polymorphic prog,
> you have "one static context" - language definition.

1. You forgot ad-hoc polymorphism and statically parametric one, which are
still there without any inheritance. The operation "." (record member
extraction) is heavily overloaded, that is ad-hoc polymorphism.

2. There are visibility scopes bringing declarations of types, objects,
subprogram. The thing you envision exists only in Assembler, probably not
even there.

>> Type are not forms of program.
> 
> types represents categories of expressions.

Egh, which category of what expression Boolean is?

Type is a set of values bound by operations defined in terms these values
and values of other types.

>> Data does not exist without types, moreover they do not exist without
>> the agents interested in these data. In a larger context there are only
>> values, sets of values, types (sets of values bound by operations 
>> defined).
> 
> not exactly. data exist independently. then we attach types to it and can 
> do operations (of type). one data can have more than one type.

This is a model of weak typing. "Weak" is another word for inconsistent.
One reason why this is inconsistent is because you don't know the type of
the data. It could be any. That blows any formalism up. The concept of
typing appeared in mathematics in order to avoid antinomies.

>> Data is a definite state of some input to some program. That state is
>> described in terms of values of defined types from the problem domain.
>> So 2 could be data for the left argument of integer +, or an ASCII
>> character STX, or standard output descriptor, or whatever.
> 
> yep. data exist independently, and we attach types to it at any time.
> and make propositions and state invariants from that moment.

No, that is no data. Data is a definite state which means something for the
agent consuming them. Without a type, there is no meaning and no data.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Nasser M. Abbasi]

On 5/21/2012 1:53 PM, Dmitry A. Kazakov wrote:

>
>> type is builded from set's.
>
> Certainly not. Which type is {-3, 'a', Pi, Employee}? A type cannot be
> inferred from its values domain set.

It is clear that this is the case, one only needs to refer to the
definition of a type, as I remember learning it in class. Something
along the lines:

  a type is a set of values AND operations on these values.

Values alone can't define a 'type'. One needs to also define what
operations are allowed on these values to have complete type defined.

(at least this is what the teacher told us)

So, I agree with you here.

--Nasser

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

>>  (there exist implementations without concurrency,
>> like f.e. vectorisation for data-parallelism-only situation).
> Harper's goal is more inclusive; he will, IIUC, ask for the cost,
> in terms of O-notation, of vectorization, which is not free.

key words not "free". sure it's not free lunch, programmer must
write program with enough parallelism generality, think about work-depth,
then runtime must schedule it on concrete processor.

key words is "platform independence automatically".
peoples prefer to use deterministic parallelism tools because
they simplify their job. and peoples do not bother even if speedup will 
not completely linear. it just needs "enough" and simply and reliable
achievable speedup. peoples prefer to solve their tasks, not debug 
concurrency.
so... i wait SISAL or NESL type language for GPU or mcoreCPU+GPU ;)
NUDA?
dealing with concurrency is too low-level and unreliable for average 
programmer...

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> so... i wait SISAL or NESL type language for GPU or mcoreCPU+GPU ;)
> NUDA?
> dealing with concurrency is too low-level and unreliable for average
> programmer...

hmm... read some... no, Nemerle NUDA is not solution ;)
so... still wait.

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

>> in russian - О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫
> In Russian it is: О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫О©╫ О©╫О©╫О©╫О©╫О©╫О©╫, which is a loan translation of
> the original English term: Abstract Data Type.

say as you wish...

>> do you really need other relations?
> Sure. The relationships should:
> 1. reflect relevant relationships of the entities from domain space
> which values of these types model.

maybe data relations will be better represented in relational db
or just some datastructure like graph?

i really think, modular structure of program must not represent
or model "domain space" entities relations complications.
program structure can always be builded flat and modular.
and this will always be good for development and maintenance.
KISS. sure, it's just imho.

> 2. serve purpose of software design per types decomposition, e.g. reuse,
> readability, maintainability etc.

yep. small number of dependencies == good reuse, readability, 
maintainability. all interaction must be rigorously defined by
detailed interface, not just "class child inherits parent".
with such interfaces you can replace parent.

>> type is builded from set's.
> Certainly not. Which type is {-3, 'a', Pi, Employee}? A type cannot be
> inferred from its values domain set. It need not to be. This is what
> gives so much power to this abstraction. You can model galaxies on a PC
> because of that.

type = set of values for type plus set of operations on type

>> directly. parent, changing youself, can do any changes on child
>> functions.
> No. In a strongly typed language there is no way to have this scenario.
> It is a type error.

ooo... seems you find "strongly typed language of dream"...
but how you catch it really?)) child not bother about parents.
can be one or other - OOP have not mechanic to differ. they place
all "can it be" decisions to programmers erroneous brain as usual.

sure, there is checksum in _compiled_ packages etc.
but it not catched by _languages_, only by some language environments.
or by tools. or by development methodology. and this is different thing.

all OOP is "technology of patches", dedicated to one-way
developing. grow and grow. only from parents to childs, no other way.
no return to correct errors. only completely rewrite...

>> child incapsulation broken, because it contains parts defined
>> elsewhere.
> This is called modular design. In any case it is fully applied to
> containment/aggregation. When you put an integer into a record, that
> brings with it integer arithmetic defined elsewhere. I find it good.

hehehe...
such architecture is not "modularity". it's "student modularity".

modularity is about independently developed replaceable parts of system,
not about _internal structure_ of this parts.
mixing internal structure of parts in architecture of project is bad 
idea. they on different layers. do not show to other parts what must
not be showed. imho. but OOP pushes this bad method as law.

when you use containment, you have better defined interface for used part.
this is not just blindly all-trusting inheritance, interactions with 
defined part is checked by typesystem. it can be strong enough, like ML's.

how do you think, why all OOP gurus now recommends limit use of 
inheritance to one-level inheritance from abstract base classes.
and recommends wider use of composition, not inheritance?
meanwhile, such "only-from-abstract" inheritance may be replaced by
message buses.

> Note also there is no way to override operations inherited for integer
> components, because their type is sealed. On the contrary, inheritance
> allows some operations re-implemented.

how do you think, what is safer:
1) provide access to all, then let dumb programmer deny access to some 
parts by sealing, "protected", etc. let state what parts are changed or 
replaced. formulate system as "old base plus patches".
2) from begin provide only needed access and only real current 
functionality. fearlessly drop old unused parts to archive completely
and formulate only "current base".
so?

>> what bad in tree-like?
> Not everything is a tree..

if you wish, chop it to relational ))

>> types represents categories of expressions.
> Egh, which category of what expression Boolean is?

forgive me my country Humpty-Dumptyness of terminology))
maybe you do not attack my each word, sir?))

> Type is a set of values bound by operations defined in terms these
> values and values of other types.

yep, i also say it. set of values and set of operations.

> This is a model of weak typing. "Weak" is another word for inconsistent.
> One reason why this is inconsistent is because you don't know the type
> of the data. It could be any. That blows any formalism up. The concept
> of typing appeared in mathematics in order to avoid antinomies.

there is moment when typing gets strong. data exists before and forewer.
and there is difference between type and kind, sure.

>> yep. data exist independently, and we attach types to it at any time.
>> and make propositions and state invariants from that moment.
> No, that is no data. Data is a definite state which means something for
> the agent consuming them. Without a type, there is no meaning and no
> data.

...maybe you just confirm that data is not always typed and _can_ exist 
without types? (usefulness of such existance is other question)
or you really want make one more flame about terminology?

you need meaning or flame?

Re: fyi, very interesting Ada paper OOP vs. Readability

[NatarovVI]

> a type is a set of values AND operations on these values.
> ...Values alone can't define a 'type'. One needs to also define what
> operations are allowed on these values to have complete type defined.

and this _is_ what i sayed. "type is builded from set's".
"set's", not "set". two set's. set of values and set of operations on 
that values. sure i remember this definitions. and just say it in 
previous messages. there was no need to correct my correct words.

so... between types there is no need for complicated "relations".
inclusion, equivalence. that's all. it's easily formulated by set
of extending interfaces to some module. (set of interfaces to one
module can be attached in java or ml, for example)

there is no need to formulate complex dependencies,
and no need in OOP inheritance.

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 23 May 2012 17:39:25 +0000 (UTC), NatarovVI wrote:

>>> do you really need other relations?
>> Sure. The relationships should:
>> 1. reflect relevant relationships of the entities from domain space
>> which values of these types model.
> 
> maybe data relations will be better represented in relational db
> or just some datastructure like graph?

That has nothing to do with types. Data relations are ones between
individual instances = between *values*. All RDB relations are values of
just one type. (There was C. Date's "third manifesto" to change that, but
so far not much happen)

Relations between types is a very different thing. Compare:

1. 5 and -5 are in relation as a value and its additive inverse.

2. N (integers) and R (reals) are related numeric types, latter is a
continuation of the former. R is a field = implements the interface of a
field. N is a ring etc.

> program structure can always be builded flat and modular.

No, that would be unmaintainable with the programs sizes common today and
technically impossible too, due to lack of even minimal reuse.

>> 2. serve purpose of software design per types decomposition, e.g. reuse,
>> readability, maintainability etc.
> 
> yep. small number of dependencies == good reuse, readability, 
> maintainability.

Reuse is impossible without substitutability. Substitutability
automatically means that the corresponding types are related =
substitutable.

>>> type is builded from set's.
>> Certainly not. Which type is {-3, 'a', Pi, Employee}? A type cannot be
>> inferred from its values domain set. It need not to be. This is what
>> gives so much power to this abstraction. You can model galaxies on a PC
>> because of that.
> 
> type = set of values for type plus set of operations on type

q.e.d.
 
>>> directly. parent, changing youself, can do any changes on child
>>> functions.
>> No. In a strongly typed language there is no way to have this scenario.
>> It is a type error.
> 
> all OOP is "technology of patches", dedicated to one-way
> developing. grow and grow. only from parents to childs, no other way.
> no return to correct errors. only completely rewrite...

I don't see any relevance.

>>> child incapsulation broken, because it contains parts defined
>>> elsewhere.
>> This is called modular design. In any case it is fully applied to
>> containment/aggregation. When you put an integer into a record, that
>> brings with it integer arithmetic defined elsewhere. I find it good.
> 
> hehehe...
> such architecture is not "modularity". it's "student modularity".
> 
> modularity is about independently developed replaceable parts of system,
> not about _internal structure_ of this parts.

So, integer components are not modular? What is your point?

> how do you think, why all OOP gurus now recommends limit use of 
> inheritance to one-level inheritance from abstract base classes.

They must be eating or smoking something...

I don't care much about OOA/D literature. 90% of it is just garbage, in my
humble opinion of course.

>> Note also there is no way to override operations inherited for integer
>> components, because their type is sealed. On the contrary, inheritance
>> allows some operations re-implemented.
> 
> how do you think, what is safer:
> 1) provide access to all, then let dumb programmer deny access to some 
> parts by sealing, "protected", etc. let state what parts are changed or 
> replaced. formulate system as "old base plus patches".
> 2) from begin provide only needed access and only real current 
> functionality. fearlessly drop old unused parts to archive completely
> and formulate only "current base".
> so?

I don't see how this question proves your point, which was, I quote: 

"child incapsulation broken, because it contains parts defined elsewhere."

Operations of an integer component are defined *elsewhere*. So, why a thing
from "elsewhere" is good when composed and bad when inherited?

>>> types represents categories of expressions.
>> Egh, which category of what expression Boolean is?
> 
> forgive me my country Humpty-Dumptyness of terminology))
> maybe you do not attack my each word, sir?))

In order to understand the point, yes. There is nothing wrong with any
terminology when explained. But we seem agreed that type is a set of values
+ operations.

>>> yep. data exist independently, and we attach types to it at any time.
>>> and make propositions and state invariants from that moment.
>> No, that is no data. Data is a definite state which means something for
>> the agent consuming them. Without a type, there is no meaning and no
>> data.
> 
> ...maybe you just confirm that data is not always typed and _can_ exist 
> without types?

Data are *always* typed. This is why there is no data without a type. It is
meaningless to talk about a value without any operations defined. Because
without them you cannot operate it. You cannot copy it, you cannot compare
it, you cannot tell if it the same value, you cannot do anything.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 23 May 2012 17:59:15 +0000 (UTC), NatarovVI wrote:

> so... between types there is no need for complicated "relations".
> inclusion, equivalence.

Traditional OO inheritance *is* inclusion. Sometimes it is called
"subsumption relation": S<:T.

> it's easily formulated by set of extending interfaces to some module.

That is extremely difficult. Showing that two types are equivalent is
undecidable.

> there is no need to formulate complex dependencies,
> and no need in OOP inheritance.

See above.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[BrianG]

On 05/11/2012 08:37 PM, Randy Brukardt wrote:
> Ada should have had a "conversion" operator ("#" has been proposed), and
> clearly Ada.Strings.Unbounded should use it. But that gets shot down every
> time it is proposed (and it has been proposed for every language revision
> other than Ada 2012); mainly because a minority think that "+" is perfectly
> good for that. And another minority think that uses "+" on non-numeric types
> is *disgusting*, so we can never get the operators added to packages. A
> perfect impasse.
>
>                                                 Randy.
Why not unary "&", isn't that closer to the existing syntax?

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: fyi, very interesting Ada paper OOP vs. Readability

[Niklas Holsti]

On 12-05-30 04:09 , BrianG wrote:
> On 05/11/2012 08:37 PM, Randy Brukardt wrote:
>> Ada should have had a "conversion" operator ("#" has been proposed), and
>> clearly Ada.Strings.Unbounded should use it. But that gets shot down
>> every
>> time it is proposed (and it has been proposed for every language revision
>> other than Ada 2012); mainly because a minority think that "+" is
>> perfectly
>> good for that. And another minority think that uses "+" on non-numeric
>> types
>> is *disgusting*, so we can never get the operators added to packages. A
>> perfect impasse.
>>
>> Randy.
> Why not unary "&", isn't that closer to the existing syntax?
>

Please, not "&", that would make calls look too much like calls in C 
with pointer parameters. "&" being the C "address-of" operator. "&" is 
also a large glyph, as tall as upper-case letters, making a following 
identifier harder to recognize at a glance. How about "~"? Meaning, I 
want "approximately" this value, but converted as necessary.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: fyi, very interesting Ada paper OOP vs. Readability

[Yannick Duchêne (Hibou57)]

Le Wed, 30 May 2012 09:29:04 +0200, Niklas Holsti  
<niklas.holsti@tidorum.invalid> a écrit:
> Please, not "&", that would make calls look too much like calls in C  
> with pointer parameters. "&" being the C "address-of" operator. "&" is  
> also a large glyph, as tall as upper-case letters, making a following  
> identifier harder to recognize at a glance. How about "~"? Meaning, I  
> want "approximately" this value, but converted as necessary.

“~” also means “negation” to people accustomed to some languages.

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 30 May 2012 09:54:44 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Wed, 30 May 2012 09:29:04 +0200, Niklas Holsti  
> <niklas.holsti@tidorum.invalid> a écrit:
>> Please, not "&", that would make calls look too much like calls in C  
>> with pointer parameters. "&" being the C "address-of" operator. "&" is  
>> also a large glyph, as tall as upper-case letters, making a following  
>> identifier harder to recognize at a glance. How about "~"? Meaning, I  
>> want "approximately" this value, but converted as necessary.
> 
> “~” also means “negation” to people accustomed to some languages.

What about fixing the language instead of thinking about ugly kludges?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[stefan-lucks]

On Wed, 30 May 2012, Dmitry A. Kazakov wrote:

> What about fixing the language instead of thinking about ugly kludges?

Something like

  for String use Ada.Strings.Unbounded.Unbounded_String;

and then every "constant string" in the source code is read as 
Ada.Strings.Unbounded.To_Unbounded_String("constant string")?

-- 
---- Stefan.Lucks (at) uni-weimar.de, University of Weimar, Germany  ----
    <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: fyi, very interesting Ada paper OOP vs. Readability

[Dmitry A. Kazakov]

On Wed, 30 May 2012 14:45:59 +0200, stefan-lucks@see-the.signature wrote:

> On Wed, 30 May 2012, Dmitry A. Kazakov wrote:
> 
>> What about fixing the language instead of thinking about ugly kludges?
> 
> Something like
> 
>   for String use Ada.Strings.Unbounded.Unbounded_String;
> 
> and then every "constant string" in the source code is read as 
> Ada.Strings.Unbounded.To_Unbounded_String("constant string")?

Rather:

   type Unbounded_String is new String'Interface with private;

String literals are primitive operations of String's interface. E.g.

   function "abc" return String;

They are inherited by Unbounded_String and must be overridden per
compositions with To_Unbounded_String:

   overriding
      function "abc" return Unbounded_String is
         To_Unbounded_String ("abc");

Sorry, for not inventing a syntax for such sort of delegation.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: fyi, very interesting Ada paper OOP vs. Readability

[Jeffrey Carter]

On 05/30/2012 12:29 AM, Niklas Holsti wrote:
>
> Please, not "&", that would make calls look too much like calls in C with
> pointer parameters. "&" being the C "address-of" operator. "&" is also a large
> glyph, as tall as upper-case letters, making a following identifier harder to
> recognize at a glance. How about "~"? Meaning, I want "approximately" this
> value, but converted as necessary.

I've always promoted "\" as the conversion operator, primarily to confuse C people.

-- 
Jeff Carter
"He didn't get that nose from playing ping-pong."
Never Give a Sucker an Even Break
110

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

Re: fyi, very interesting Ada paper OOP vs. Readability

[BrianG]

On 05/30/2012 03:29 AM, Niklas Holsti wrote:
> On 12-05-30 04:09 , BrianG wrote:
>> On 05/11/2012 08:37 PM, Randy Brukardt wrote:
>>> Ada should have had a "conversion" operator ("#" has been proposed), and
>>> clearly Ada.Strings.Unbounded should use it. But that gets shot down
>>> every
>>> time it is proposed (and it has been proposed for every language
>>> revision
>>> other than Ada 2012); mainly because a minority think that "+" is
>>> perfectly
>>> good for that. And another minority think that uses "+" on non-numeric
>>> types
>>> is *disgusting*, so we can never get the operators added to packages. A
>>> perfect impasse.
>>>
>>> Randy.
>> Why not unary "&", isn't that closer to the existing syntax?
>>
>
> Please, not "&", that would make calls look too much like calls in C
> with pointer parameters. "&" being the C "address-of" operator. "&" is
> also a large glyph, as tall as upper-case letters, making a following
> identifier harder to recognize at a glance. How about "~"? Meaning, I
> want "approximately" this value, but converted as necessary.
>
So I guess we should ban 'C' as a variable name too.  Who cares what 
looks like C?  Does that somehow bring along with it the problems in C? 
  How?

We already have A := "This" & " That", Why not also B := &"The other", 
that makes it perfectly analogous with D := 1 + 2 and E := +3.  (Yes, I 
skipped C :-)  Function "&" already has an established meaning in Ada, 
why not use it for a (somewhat) similar purpose?

If that looks like C, you could always use
B := Ada.Strings.Unbounded_String."&"("The Other");  or B := "&"(A);
That doesn't look anything like C.

It sounded from Randy's message, that (some of) the problems were based 
on defining a new operator ("#") and unrelated reuse of an existing 
operator ("+").  This proposal fits in with existing Ada usage.

(Funny, today I was going thru Sun's (Oracle's) Java tutorial, and 
several places they had something like "+ is used for addition, and oh 
by the way, also for string concatenation".)

-- 
---
BrianG
000
@[Google's email domain]
.com

Re: fyi, very interesting Ada paper OOP vs. Readability

[Randy Brukardt]

"BrianG" <me@null.email> wrote in message news:jq68qj$de5$1@dont-email.me...
> On 05/30/2012 03:29 AM, Niklas Holsti wrote:
>> On 12-05-30 04:09 , BrianG wrote:
>>> On 05/11/2012 08:37 PM, Randy Brukardt wrote:
>>>> Ada should have had a "conversion" operator ("#" has been proposed), 
>>>> and
>>>> clearly Ada.Strings.Unbounded should use it. But that gets shot down 
>>>> every
>>>> time it is proposed (and it has been proposed for every language 
>>>> revision
>>>> other than Ada 2012); mainly because a minority think that "+" is 
>>>> perfectly
>>>> good for that. And another minority think that uses "+" on non-numeric 
>>>> types
>>>> is *disgusting*, so we can never get the operators added to packages. A
>>>> perfect impasse.
>>>>
>>> Why not unary "&", isn't that closer to the existing syntax?
>>>
>> Please, not "&", that would make calls look too much like calls in C
>> with pointer parameters. "&" being the C "address-of" operator. "&" is
>> also a large glyph, as tall as upper-case letters, making a following
>> identifier harder to recognize at a glance. How about "~"? Meaning, I
>> want "approximately" this value, but converted as necessary.
>>
> So I guess we should ban 'C' as a variable name too.  Who cares what looks 
> like C?  Does that somehow bring along with it the problems in C? How?
>
> We already have A := "This" & " That", Why not also B := &"The other", 
> that makes it perfectly analogous with D := 1 + 2 and E := +3.  (Yes, I 
> skipped C :-)  Function "&" already has an established meaning in Ada, why 
> not use it for a (somewhat) similar purpose?

That makes sense if you are *only* interested in conversions of strings. "&" 
makes no more sense for numbers than "+" makes sense for strings. The intent 
of the proposed "#" operator is that it be for the conversion of any type to 
any other type.

For instance, I could imagine using "#" to describe conversions of array of 
Element to vector of Element. Neither "+" nor your proposed "&" makes sense 
for that. The basic idea is that "#" would provide the effect of a 
user-defined type conversion.

An alternative idea that I've occassionally thought about has been to 
directly allow user-defined (value) type conversions. That is, provide a 
mechanism to allow the existing type conversion syntax to call a function in 
cases where there isn't already a defined conversion. This would work 
something like user-defined indexing does.

Then,

    Var := Unbounded_String("abc");

would be possible. (But note that this could end up nearly as wordy as the 
existing mechanism.)

                                          Randy.