Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Peter Damoc]

On Tue, Jul 25, 2017 at 3:32 AM, Erik Simmler  wrote:

> That said, what if we flip the question around? Given that we have
> facilities for encapsulation (unexposed types), what would we gain by
> adding a new set of concepts around mixing data/logic and syntactic sugar
> in the form of "this"? What would this enable?
>

We could have better polymorphism.  For example, we could have something
like traits.

trait Stringable =
{ toString : this -> String
}

type Msg implements Stringable  =
{ tags = Increment | Decrement
, toString = \this ->
case this of
Increment ->
"Add One"
Decrement ->
"Subtract One"

}

This would allow one to declare something like List Stringable that would
accept all String and objects that can be turned into a string because they
implement the Stringable trait.

We would not have to keep putting toString all over our code but rather
decide at the type declaration level how the string representation of the
type should look.

The same argument can be made for serialization too.

As far as I can see it, the prime target for this would be to implement
web-components like nodes that would be just implementations of some node
interface. Behind the scenes we would still get a single source of truth
but this single source of truth would be generated based on these
implementations. In my view, this would eliminate at least some of the
boilerplate.



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Peter Damoc]

On Mon, Jul 24, 2017 at 8:50 PM, Dave Ford  wrote:

> A lot of my early work was centered around UIs which made heavy use of
>> inheritance and mutation.
>>
> I really don't think this is related to the original question. The
> original question was not about inheritance or mutation or even about OO.
> It was about "this" and "combining data with logic". Which were described
> as a "systemic problem".
>
> No one (yet) has convinced me that they are even remotely a problem. No
> one has provided an example. Or any logic to support the claim.
>

I think the added complexity to the language that you mentioned qualifies
as a problem. ;)


>  The fact that "this" has nothing to do with immutability is unrelated to
> my experience.


Most programming languages that have a "this" construct allow mutation.
This is what you have to take into account when discussing this. The very
idea of OOP is that you have independent objects that communicate through
messages. This means that you send an object a message and it mutates its
state (if need be). This mutation is achieved through the use of this/self
or a similar concept.

You cannot simply ignore this historical reality.

Sure, we can have a fully immutable object system but this is not commonly
encountered. If Kotlin has something like this it is an exception not part
of the rule.

Once we acknowledge the issue of mutability we can move the discussion
forward and analyze the benefits of having data and behavior together in
the context of immutability.

I too would love to see an argument against having the data and logic
together in the context of immutability.


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Marcus Roberts]

Dave

Perhaps I'm being bit oversensitive, but this does seem to be a rather
argumentative approach.I know you said you learn by arguing, but this
seems to be turning into a dogmatic crossing of swords, rather like walking
into a British pub and declaring the local football team a load of rubbish
:)


On Mon, Jul 24, 2017 at 6:50 PM, Dave Ford  wrote:

> A lot of my early work was centered around UIs which made heavy use of
>> inheritance and mutation.
>>
> I really don't think this is related to the original question. The
> original question was not about inheritance or mutation or even about OO.
> It was about "this" and "combining data with logic". Which were described
> as a "systemic problem".
>
> No one (yet) has convinced me that they are even remotely a problem. No
> one has provided an example. Or any logic to support the claim.
>
> They have mentioned all sorts of other things that *are* problematic,
> like inheritance and mutation. But I already knew those were problematic. I
> also already knew that most OO languages also support mutation (although
> mutation is discouraged in Kotlin). But this is not what the question was.
>
> Sure, you could start naming off a dozen other things that are problematic
> (like inheritance and mutation). But that has nothing to do with the
> question.
>
>
>> In OO, mutation is very easy to do because of `this`.
>>
> No. As mentioned earlier, "this" has nothing to do with immutability.
> "this" is just an object variable like any other object variable.
>
> | Perhaps your experience with OO programming is atypical?
> The fact that "this" has nothing to do with immutability is unrelated to
> my experience.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Kasey Speakman]

Submit a PR for a documentation change. GL

On Monday, July 24, 2017 at 12:50:12 PM UTC-5, Dave Ford wrote:
>
> A lot of my early work was centered around UIs which made heavy use of 
>> inheritance and mutation.
>>
> I really don't think this is related to the original question. The 
> original question was not about inheritance or mutation or even about OO. 
> It was about "this" and "combining data with logic". Which were described 
> as a "systemic problem".
>
> No one (yet) has convinced me that they are even remotely a problem. No 
> one has provided an example. Or any logic to support the claim.
>
> They have mentioned all sorts of other things that *are* problematic, 
> like inheritance and mutation. But I already knew those were problematic. I 
> also already knew that most OO languages also support mutation (although 
> mutation is discouraged in Kotlin). But this is not what the question was. 
>
> Sure, you could start naming off a dozen other things that are problematic 
> (like inheritance and mutation). But that has nothing to do with the 
> question.
>  
>
>> In OO, mutation is very easy to do because of `this`.
>>
> No. As mentioned earlier, "this" has nothing to do with immutability. 
> "this" is just an object variable like any other object variable.
>
> | Perhaps your experience with OO programming is atypical?
> The fact that "this" has nothing to do with immutability is unrelated to 
> my experience.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[David Andrews]

As far as I'm concerned, this is just syntactic sugar.  I've noticed that
elm has a convention to use the last parameter in a function where an OO
programmer would use this.  Using this convention, code winds up being very
similar when used.

OO version:
model
.getSomeProperty
.withDefault(3)

Elm version:
model
|> getSomeProperty
|> Maybe.withDefault 3



On Mon, Jul 24, 2017 at 1:50 PM Dave Ford  wrote:

> A lot of my early work was centered around UIs which made heavy use of
>> inheritance and mutation.
>>
> I really don't think this is related to the original question. The
> original question was not about inheritance or mutation or even about OO.
> It was about "this" and "combining data with logic". Which were described
> as a "systemic problem".
>
> No one (yet) has convinced me that they are even remotely a problem. No
> one has provided an example. Or any logic to support the claim.
>
> They have mentioned all sorts of other things that *are* problematic,
> like inheritance and mutation. But I already knew those were problematic. I
> also already knew that most OO languages also support mutation (although
> mutation is discouraged in Kotlin). But this is not what the question was.
>
> Sure, you could start naming off a dozen other things that are problematic
> (like inheritance and mutation). But that has nothing to do with the
> question.
>
>
>> In OO, mutation is very easy to do because of `this`.
>>
> No. As mentioned earlier, "this" has nothing to do with immutability.
> "this" is just an object variable like any other object variable.
>
> | Perhaps your experience with OO programming is atypical?
> The fact that "this" has nothing to do with immutability is unrelated to
> my experience.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Dave Ford]

>
> A lot of my early work was centered around UIs which made heavy use of
> inheritance and mutation.
>
I really don't think this is related to the original question. The original
question was not about inheritance or mutation or even about OO. It was
about "this" and "combining data with logic". Which were described as a
"systemic problem".

No one (yet) has convinced me that they are even remotely a problem. No one
has provided an example. Or any logic to support the claim.

They have mentioned all sorts of other things that *are* problematic,
like inheritance and mutation. But I already knew those were problematic. I
also already knew that most OO languages also support mutation (although
mutation is discouraged in Kotlin). But this is not what the question was.

Sure, you could start naming off a dozen other things that are problematic
(like inheritance and mutation). But that has nothing to do with the
question.


> In OO, mutation is very easy to do because of `this`.
>
No. As mentioned earlier, "this" has nothing to do with immutability.
"this" is just an object variable like any other object variable.

| Perhaps your experience with OO programming is atypical?
The fact that "this" has nothing to do with immutability is unrelated to my
experience.

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Peter Damoc]

On Sun, Jul 23, 2017 at 1:39 AM, Dave Ford  wrote:
>
> It's not that OOP is bad, but it encourages mutation
>>
> OOP does not encourage nor discourage mutation. Java, Kotlin, Scala and
> OCAML all *allow* mutation. Kotlin, an OO language that I use a lot,
> actually *discourages* mutation. But regardless, my question was not
> about immutability. It was about combining data and logic.
>

I do not know Kotlin but all other OOP languages I've used allowed passing
an object to a function and potentially having that object be mutated by
that function. Maybe "encourage" is the wrong word here but this is an
affordance that will be used.

In any case, from what I remember from the discussions around object
oriented programming around this list, mutability was the key feature that
was brought forward as a source of problems that Elm avoids. It was linked
to state in objects getting out of sync in certain contexts and to the fact
that functions lose their purity.

Another issue is the one you mentioned about the surface area of the
language.
Implementing OOP features would require permanently and irreversibly making
the type system and the language more complex. The topic of typeclasses
(one of the options) has been raised several times. It has been promised at
one point as a feature that the language will gain in time but years
passed and the topic got shelved.

Outside of these two topics (immutability & complexity of the language) I
don't remember seeing arguments for problems brought on by joining data and
behavior together.

I am interested in the topic of web components (I believe that Elm could
benefit greatly from embracing this standard). I've even went as far as to
implement a web components system in Elm (with the help of a little bit of
Native code) and the only real argument against it that I remember is the
argument of mutability. I even tried to implement a mutability-as-service
component in order to try to see if this is possible. I failed. Still...
the intuition of some of the senior developers of Elm is that this would be
possible and that all the nice guarantees of Elm would fly out the window.

This is the main reason I pointed to immutability.
I think the complexity of the language issue is unavoidable but one can
avoid the problems generated by mutability by having an immutable way of
joining data and behavior (the FauxO system I hinted towards being one of
the ways).

I too would be very interested in seeing any kind of argument against
joining data and behavior outside of these two main ones (immutability and
complexity of the type system).


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Re: Systemic problem in Object Oriented languages

[Dave Ford]

First of all, I apologize in advance if I sound argumentative. It's just
how main brain learns.

Alex, thanks for your thoughtful reply. Below is how I would do your Square
example in Java and Kotlin. Both examples combine data and logic and both
examples are fully *immutable*.

*Java*

public class Square {

private final float size;

public Square(float size) {
this.size = size;
}

public float getSize() {
return size;
}

public float getPerimeter() {
return size * 4;
}

public float getArea() {
return size * size;
}

}


*Kotlin:*

class Square(val side: Float) {
val perimeter: Float get() = side * 4
val area: Float get() = side * side
}

In an object oriented language, what would be the point be of having
> immutable data?
>
Same as in a functional language. I do it all day and every day. I have
written huge and useful components in Java and Kotlin and Scala without a
single mutation.


> It's not that OOP is bad, but it encourages mutation
>
OOP does not encourage nor discourage mutation. Java, Kotlin, Scala and
OCAML all *allow* mutation. Kotlin, an OO language that I use a lot,
actually *discourages* mutation. But regardless, my question was not about
immutability. It was about combining data and logic.

*Conclusions*
Here is the original assertion from the Elm docs: "Elm encourages a strict
separation of data and logic, and the ability to say 'this' is primarily
used to break this separation. This is a systemic problem in Object
Oriented languages that Elm is purposely avoiding."

I have read the responses in this thread carefully and thoughtfully. None
of the answers addressed the question in my original question in a way that
satisfies my sense of logic.

So here are my conclusions:

*1. Immutability is a separate issue. *I only bring this up because many of
the replies in this thread brought up immutability*.* Immutability is not
really related to the issue we are discussing. But regardless, OO is
perfectly happy being immutable. I do it all the time.  Immutability *is* a
problem with JavaScript. But not with Java, Scala or Kotlin or C# or most
OO languages. As demonstrated by the examples above.

*2. Combining data and logic is not a systemic problem in object oriented
programming.* I would argue that it is an advantage for some use-cases. I
have, for many years, been happily and successfully writing code that is
both immutable *and* combines data and logic.

*3. "this" is not a systemic problem with OO languages*. It *is* a systemic
problem with JavaScript, but that is another topic. Java and Scala all deal
with "this" quite nicely and predictably.

Checkout this example of a Card class (as in a Card game). It combines data
and logic. And uses "this" (implicitly, as is usually the case). And it is
completely immutable:

https://github.com/StokeMasterJack/bj1/blob/master/src/main/kotlin/bj1/Card.kt

Please look at this code and explain to me the systemic problem I am
missing.

This may sound like bikeshedding. But before I delve into a solution (in
this case, Elm forcing the separation of data and logic) I like to
understand the problem. And it appears that in this case, unless I am
missing something, the problem statement seems based on an incomplete
understanding of object-oriented programming languages (other than
JavaScript).

I may be wrong. I am open to changing my opinion if someone posts new
information I haven't considered.

Side note: here is more logical reason for forcing the separation of data
and logic: it lowers the surface area of the language, thus making it
easier to learn for beginners

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.