[elm-discuss] Systemic problem in Object Oriented languages

[Dave Ford]

There is a line from the docs that I am trying to understand: "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."

What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?

I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.

Please help me to understand what the author is talking about.

Thanks.

Side note: "this" *is* a problem in JavaScript. But not in OO generally.

[Peter Damoc]

"this" is associated with mutation. Elm is an immutable language.

In theory, one could have immutable objects where data and logic are
grouped together.
The best expression I've seen so far is the FauxO system in Gary
Bernhardt's Boundaries talk.

Something like this would constitute a non-trivial expansion of the
language and, as far as I can understand it, there are other priorities.

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" *is* a problem in JavaScript. But not in OO generally.
--
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
For more options, visit https://groups.google.com/d/optout.

[John Orford]

It's ambiguous, I also imagine it means avoiding:

this.x = 123

But then again, why do you need 'this' in the first place? In Elm you can
access anything in scope in the module.

I suppose this is useful for accessing class stuff which isn't in your
immediate method scope... which again leads you down something like ideas
around local (object) mutable state...

Good question!

Post by Peter Damoc
"this" is associated with mutation. Elm is an immutable language.
In theory, one could have immutable objects where data and logic are
grouped together.
The best expression I've seen so far is the FauxO system in Gary
Bernhardt's Boundaries talk.
Something like this would constitute a non-trivial expansion of the
language and, as far as I can understand it, there are other priorities.

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" *is* a problem in JavaScript. But not in OO generally.
--
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
For more options, visit https://groups.google.com/d/optout.

--
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
For more options, visit https://groups.google.com/d/optout.

[Dave Ford]

Post by John Orford
It's ambiguous

It's not. In Java it's very clearly and deterministically defined.

this.x = 123
Immutability is a different issue. "this" has nothing specifically to do
with mutability. The use of "this" is orthogonal to mutability.

[Dave Ford]

Post by Peter Damoc
"this" is associated with mutation. Elm is an immutable language.

I don't think that's true. I might be wrong, but I'm pretty sure that
"this" has nothing specifically to do with mutation. I write immutable
objects all day long in java and kotlin making use of "this" and mixing
data and logic.

[John Orford]

I have minimised (almost 0% now) my use of this in JS, by using arrow
functions. Perhaps 'this' is a bad example, they're an arcane artifact...

Basically you're right, the guide isn't clear at best, wrong at worst : )

Post by Dave Ford

Post by Peter Damoc
"this" is associated with mutation. Elm is an immutable language.

I don't think that's true. I might be wrong, but I'm pretty sure that
"this" has nothing specifically to do with mutation. I write immutable
objects all day long in java and kotlin making use of "this" and mixing
data and logic.
--
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
For more options, visit https://groups.google.com/d/optout.

[Peter Damoc]

Post by Dave Ford

Post by Peter Damoc
"this" is associated with mutation. Elm is an immutable language.

I don't think that's true. I might be wrong, but I'm pretty sure that
"this" has nothing specifically to do with mutation. I write immutable
objects all day long in java and kotlin making use of "this" and mixing
data and logic.

I'm not saying that "this" implies mutation only that it is associated with
mutating the current object.

Of course one can write immutable objects using "this" but in OO languages
you can also use it to mutate the state of the object.

[Christophe de Vienne]

Regardless of immutability, saying "this" imply a bound between the data
and the function, which is the very thing Elm wants to avoid.

So I think the systemic problem referred to here is "separation of data
and logic", and its incarnation (sort of) is the ability to say "this".

Now, is it actually a systemic problem ? My intuition is that it is the
root of many difficulties OO languages can have, even though it does not
seem like a problem at first.

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of]
"separation of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" /is/ a problem in JavaScript. But not in OO generally.
--
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
For more options, visit https://groups.google.com/d/optout.

[Dave Ford]

Post by Christophe de Vienne
Now, is it actually a systemic problem ? My intuition is that it is the
root of many difficulties OO languages can have, even though it does not
seem like a problem at first.

Can you give an example? Specifically, without confusing the unrelated
issue of immutability?

[Christophe de Vienne]

Post by Christophe de Vienne
Now, is it actually a systemic problem ? My intuition is that it is the
root of many difficulties OO languages can have, even though it does not
seem like a problem at first.
Can you give an example? Specifically, without confusing the unrelated
issue of immutability?

Well, it is more an intuition after more than 20 years of coding that an
elaborated opinion.

But the first thing that comes to my mind is the resulting complexity,
and often confusion. I find that having a clean separation between data
& logic makes things a lot cleaner, easier to understand and maintain.

I do realize I would need to elaborate a little more to be convincing on
this, but so far it is all I got :-)

[Peter Damoc]

On Thu, Jul 20, 2017 at 12:49 PM, Christophe de Vienne <

Post by Christophe de Vienne
Well, it is more an intuition after more than 20 years of coding that an
elaborated opinion.
But the first thing that comes to my mind is the resulting complexity,
and often confusion. I find that having a clean separation between data
& logic makes things a lot cleaner, easier to understand and maintain.
I do realize I would need to elaborate a little more to be convincing on
this, but so far it is all I got :-)

Out of curiosity, are you keeping your Model, update and view in separate
modules?

[Christophe de Vienne]

Post by Peter Damoc
On Thu, Jul 20, 2017 at 12:49 PM, Christophe de Vienne
Well, it is more an intuition after more than 20 years of coding that an
elaborated opinion.
But the first thing that comes to my mind is the resulting complexity,
and often confusion. I find that having a clean separation between data
& logic makes things a lot cleaner, easier to understand and maintain.
I do realize I would need to elaborate a little more to be convincing on
this, but so far it is all I got :-)
Out of curiosity, are you keeping your Model, update and view in
separate modules?

At first no, then depending on how much of the module I want to reuse, I
separate them.

In the end, I have reusable models as submodules of a "Data" module, a
few model+update modules (mainly for the session data, which has no
global view), and the rest are single modules with model+update+view
(for pages mainly, and a few subcomponents).

It is in great part inspired by the SPA example from Richard Feldman:
https://github.com/rtfeldman/elm-spa-example

[Alex Barry]

Here's my take.

In C++ (Or Java, what-have-you), you could have something like this:

class Square {
private float size;

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

void size(float size) {
this.size = size;
}

float size(void) {
return this.size;
}

float perimeter(void) {
return this.size * 4;
}

float area(void) {
return this.size * this.size;
}
}


In Elm, you end up with a much different looking structure and code:

module Square exposing (Square, perimeter, area)


type alias Square = { size : Float }


perimeter : Square -> Float
perimeter square = square.size * 4

area : Square -> Float
area square = square.size * square.size





It forces immutability. In an object oriented language, what would the
point be of having immutable data? Why would `Square(oldSquare, newSize)`
ever be better than `oldSquare.size(newSize)`? You end up working against
the language. It's not that OOP is bad, but it encourages mutation, a thing
that Elm is strictly against.

Mutation can be a problem because it means there is more to debug. In C++,
if I had something like:

foo.bar = "baz";
foo.someSpecialFunction();
std::cout << foo.bar << std::endl;


What is the expected value of foo.bar? When we initially evaluate the code,
we make an educated assumption that foo.bar is probably going to be "baz",
but is that actually the case? We need knowledge about what
someSpecialFunction does, because we know it could, in a non obvious way,
change the value of bar.

In Elm:

type alias Thing = { bar : String }

someSpecialFunction : Thing -> a

foo = Thing "baz"
_ = someSpecialFunction foo
valueOfFooBar = Debug.log "value of foo.bar" foo.bar


This example is intentionally leaving out some parts, but we will always
know that foo.bar results in "baz". If someSpecialFunction where to return
a Thing, we could assume it is a copy of the original with some changes. In
this case, it's obvious that something about that result will be different
from foo, and we can deal with it appropriately.

Testing probably ends up being harder in C++ since you aren't just testing
results, you need to test mutations, so `this` may cause misdirection. It
tethers operations on your class to that instance. It means things can
change without you necessarily knowing they have changed.

In Elm, it is hard to do this. Not impossible, but hard. The idea is that
the less work a developer has to do to understand a piece of code, the more
productive (s)he can be.

I think the statement does boil down to a point about immutability and
guarantees provided by all constant variables. I'm not convinced that it is
a systemic problem, but it is just another layer of knowledge that a
developer must have every time (s)he runs an instance method on a variable.
There are always a set of rules that a developer can follow to minimize the
impact `this` and mutations has on his/her code, like a function can only
perform one thing, having well defined names for functions, following a
code guide for a project, etc..

In a broad and maybe stretched sense, perhaps the author is suggesting that
rather than developers having to opt into rules to keep good and tidy code,
perhaps it is better that those rules are strictly enforced outside of the
developers control, under the assumption that the forced rules will always
result in better code.

- Alex

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" *is* a problem in JavaScript. But not in OO generally.

[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

Post by Alex Barry
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.

Post by Alex Barry
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

[Peter Damoc]

Post by Alex Barry
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).

[Kasey Speakman]

Perhaps your experience with OO programming is atypical?

A lot of my early work was centered around UIs which made heavy use of
inheritance and mutation. Being a novice, my own work followed this pattern
too. A lot of UIs still work this way. React has to explicitly spell out
<https://facebook.github.io/react/docs/state-and-lifecycle.html#do-not-modify-state-directly>
for you not to modify state directly.

In OO, mutation is very easy to do because of `this`. Even when you know
better it requires a lot of discipline to do what you "should" do rather
than what is easy. Kudos on you for having that, but it is certainly not a
universal.

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" *is* a problem in JavaScript. But not in OO generally.

[Dave Ford]

Post by Kasey Speakman
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.

Post by Kasey Speakman
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.

[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

Post by Kasey Speakman
A lot of my early work was centered around UIs which made heavy use of

Post by Kasey Speakman
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.

Post by Kasey Speakman
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
For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

Submit a PR for a documentation change. GL

Post by Kasey Speakman
A lot of my early work was centered around UIs which made heavy use of

Post by Kasey Speakman
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.

Post by Kasey Speakman
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.

[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
:)

Post by Kasey Speakman
A lot of my early work was centered around UIs which made heavy use of

Post by Kasey Speakman
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.

Post by Kasey Speakman
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
For more options, visit https://groups.google.com/d/optout.

[Peter Damoc]

Post by Kasey Speakman
A lot of my early work was centered around UIs which made heavy use of

Post by Kasey Speakman
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. ;)

Post by Kasey Speakman
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.

[Erik Simmler]

Despite your desire to isolate this aspect from other factors such as
immutability, I don't think you can do that without missing the big
picture. Elm's strength does not come from a list of features (types,
immutability, controlled side effects, etc...), but rather from way that
they have all been thoughtfully combined.

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?

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" *is* a problem in JavaScript. But not in OO generally.

[Peter Damoc]

Post by Erik Simmler
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.

[Robin Heggelund Hansen]

First of all, let's agree that both Java and Javascript are successful
languages in that you can solve most, if not any, given software problems
in those languages. Does that mean the languages themselves are
unproblematic? What does it mean to have a problem? Does it mean you cannot
get anything done? Or could you still write a very successful program
despite those problems. Cold you, in fact, have a problem without
considering it one?

What constitutes a problem is highly subjective. It's good to keep in mind
in this discussion.

So, the line in the docs is not wrong. "this" effectively combines logic
and data, and Elm does maintain a separation there. The systemic problem
being referenced, is the comingling of data and logic, not that you can
write "this".

So why is this is a problem?

We've already defined that it is not a problem which prevents you from
solving problems, in fact, very few thing in Javascript or Java or any
other functional language pose such a problem. But there are some downsides
that is worth considering:

1. What is "this"?
In a single class, "this" is a very easy thing. It refers to this instance
of a class. But what does "this" mean in a context where the class is a
child? Does "this" refer to this instance, or a parent instance, or a
parent parent instance? This might not be conceived as a problem, since we
got fancy IDE's helping us keep track of things, but I would argue that
having "this" in any non-trivial piece of code makes it difficult to
understand such code if you're reading it for the first time. Avoiding
"this" makes code, IMHO, easier to read.

2. What's the downside of coupling data and logic?
Let's say we have the two following classes:

class Person { public int age; }
class Animal { public int age; }

Why can't we store both of these in an array? They look the same, the carry
the same information, but they are different. If I write a function which
operates on the age field, why do I need to write this twice for both
classes? I can of course write a `Ageable` interface which declares a
`getAge` function, but why is that necessary? What benefit do we get here
by combining logic with data?

In Elm, you would define these as type aliases, meaning every function
would work on one or the other, and you could store them in Lists or what
not. You can also easily create extendable types if you only care about one
or more fields.

Another downside: I need a function that works on all integers. Why do I
have a create a static class for this? Why can't I just have a free
function for this? What is the benefit of having it this way?

These aren't big things. But for me, combining logic and data makes it
harder to understand code and to re-use it. There also doesn't seem to be
any benefit in that combination.

Note: Javascript can avoid all these functions quite easily, but that's
because javascript really is just as functional as it is object-oriented.

I'd also like to leave this link here, great talk on the
subject:

Post by Dave Ford
There is a line from the docs that I am trying to understand: "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."
What is the systemic problem being reference? Is it the [lack of] "separation
of data and logic" or "the ability to say this"?
I have been programming in Java (an OO language) for a long time. I can
name dozens of systemic problems in the language. But the ability to say
"this" is not one of them. Nor is it the commingling of data and logic.
Please help me to understand what the author is talking about.
Thanks.
Side note: "this" *is* a problem in JavaScript. But not in OO generally.