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

[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: https://www.youtube.com/watch?v=-6BsiVyC1kM

torsdag 20. juli 2017 09.55.54 UTC+2 skrev Dave Ford følgende:
>
> 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 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 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.

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

[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?


On Thursday, July 20, 2017 at 3:55:54 AM UTC-4, Dave Ford wrote:
>
> 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 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.

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

[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 

 
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.

On Thursday, July 20, 2017 at 2:55:54 AM UTC-5, Dave Ford wrote:
>
> 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 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.

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

[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


On Thursday, 20 July 2017 03:55:54 UTC-4, Dave Ford wrote:
>
> 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 email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.