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.
