141–150 of 218 posts
Earlier quoted context omitted.
BTW, why lots of people think it's very wrong and immoral to criticize inanimate pieces of technology in rude and offensive language? Political correctness?
There are people on the other end of the screen who built the technology, and they have feelings :) Being nice is good.
Earlier quoted context omitted.
I don't think the response was as simple as "No, you can't have that because I don't want to". Reading the discussion about removal of this feature on Github there seems to be a few more points made that the author alludes to: https://github.com/elm-lang/elm-compiler/issues/985 Also, It's worth noting that Elm does have a BDFL. Evan makes the call and, as I'm sure a lot of python folks would agree, that setup means t…
It has a dictator for life, but given the article doesn't seem like the B is earned yet :P
I don't believe in Elm one bit. it's been 4 years guys. I follow its developement (it's not a hard thing to do after all, it's a snail pace) because its creator is intelligent and there are a few nice things in it. But as a practical platform to build real apps? No way. I mean you can build apps with any tech, so of course people will try and succeed with it; but it's just a bad choice. Elm is impratical because you…
For someone who hasn't worked with a statically typed language yet, perhaps. But someone who knows and works with Haskell would disagree here.
Earlier quoted context omitted.
You can go with the Diode [1] library for an Elm/Redux- like architecture. And with that you don't need to all the way down to cats or scalaz (although you sure always can if you want to). [1] https://github.com/ochrons/diode
Take two average JS programmers. Hand one of them the Elm docs, the other the Diode docs. What do you expect will happen?
I don't believe in Elm one bit. it's been 4 years guys. I follow its developement (it's not a hard thing to do after all, it's a snail pace) because its creator is intelligent and there are a few nice things in it. But as a practical platform to build real apps? No way. I mean you can build apps with any tech, so of course people will try and succeed with it; but it's just a bad choice. Elm is impratical because you…
> Meanwhile [...] typescript, [...] is [...] more than typesafe enough language. For someone who hasn't worked with a statically typed language yet, perhaps. But someone who knows and works with Haskell would disagree here.
Earlier quoted context omitted.
Well, you cannot use a mutable object as a key without some help. What would you expect to happen if the object is modified after being inserted into the dictionary? If you have a list or dictionary you want to use a key, you can convert it into a tuple which would make it immutable. If you don't care about performance for larger collections you could just use a list instead of a dictionary, which does not require ha…
> What would you expect to happen if the object is modified after being inserted into the dictionary? I would expect it to continue to use the object . Why would it matter if it was mutated or not? You can try it right in your browser with Javascript and the Map() object type. You can mutate the object all you want, as long as it's the same object(-reference) you access the same value in the Map object. Just as I wou…
It's also worth pointing out that user-defined objects operate the way you seem to desire (e.g. default to using the id() property of the object to derive the hash). So in my mind, this strikes the perfect balance?
StdLib types that are immutable bake in more comparative hash properties while making it trivial for a user to wrap them and override this richer behavior with default hash based on id().
Consider:
```
>>> class myList(object):
... def __init__(self):
... self.inner_list = list()
...
>>> x = myList()
>>> x
>>> x.inner_list
[]
>>> y = {x: 'hi'}
>>> y
{: 'hi'}
>>> x.inner_list.append(1)
>>> x.inner_list
[1]
>>> y
{: 'hi'}
>>> for k in y.keys():
... print k.inner_list
...
[1]
```
Earlier quoted context omitted.
Evan has several times said that he's open for typeclasses. Problem is that they have a profound effect on the language, and so they have to be done right. He doesn't know what the right implementation of that might be at the moment, so he's waiting until he comes up with what the right thing to add for Elm would be.
You think Evan is just waiting around for the right abstraction to dawn on him? It's been years with not one bit of code written in the direction of adding a mechanism for abstraction in the language (whether that be typeclasses or something else)
First you need to figure out what exactly the Elm community wants and needs. Once you have a pretty good idea of that, you can start prototyping things. Elm is still young, and the most pressing concerns for using Elm in production is not the lack of interfaces/protocols/typeclasses, but stuff like debuggers, which is what Evan is working on.
I'm sure we'll see some tool for ad-hoc polymorphism in the future, but not in the short term.
At one point, he said this witness "proved" something ... so is this coming from "propositions as types"?
Despite the abrasive tone of this article, it is true that Elm misses a convenient level of abstraction (whether that be type classes, module functors or whatever). I spent the first few weeks of my first Elm project fighting against the language, trying to emulate type classes, build abstractions, do things like I would in other languages and generally having a bad time. Eventually, and with slightly bad grace, I co…
That's unlikely, it is not the direction Evan wants to take, and so far the language has gone the opposite direction on purpose and by design.
> And hey, when these kinds of abstractions do arrive
Which they probably won't. Realise that the Elm platform is written in Haskell, Evan knows about these features, he could have used them and he very specifically avoided doing so. If you want these abstraction-building tools you'll be much better off looking at e.g. PureScript rather than wait for Elm to add them.