151–160 of 218 posts
Earlier quoted context omitted.
The restriction only applies to native modules (modules that ship with Javascript): https://groups.google.com/forum/#!msg/elm-dev/1JW6wknkDIo/H9...
If you want to write anything non-trivial in Elm you need to use native modules though because the language doesn't give you access to any of it's "magic"
Earlier quoted context omitted.
Keep in mind that Evan works at a company that has 55k lines of Elm in production. Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now.
This is unconvincing to me. Just because Evan and his friends are happy to write boilerplate and copy-paste the same stuff over and over doesn't mean it's the right thing to do.
The fact that NoRedInk are perfectly happy without typeclasses (or something similar) could be an indication that it really isn't as important that people would make you believe. After all, there are several languages out there with support for typeclasses (or something similar). Like purescript. And yet, people decide to use Elm.
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…
Unfortunately this is an opinionated piece with foul language and it is a bit offensive. Sandy should take into account that Elm is created by one person pretty much (Evan Czaplicki) who created it in his PhD thesis and has been maintaining it since. So it's someones baby still, and they might be offended. It is a remarkable for one person to create a language, runtime, repl, debugger, compiler to another quirky lan…
Yeah I read this a few weeks ago and was similarly put off. I will give him one thing: it got me to start thinking about what I wanted in a functional language that compiles into JS, which ultimately steered me towards Purescript. I think fundamentally he's correct, but the point that he is missing is the intended audience of Elm. He was not it. Elm is much easier to grasp than Purescript, for instance. There is less…
I investigated Elm just after the 0.17 release, decided I was fine with it but didn't really love the language. I've since moved to investigating F# and the Fable compiler. While it's unlikely that someone who prefers Purescript would prefer an ML derivative, I feel I should mention it for other people reading the thread from the front page and prefer having imperative escape hatches.
The Ocaml to JS compilers (Bucklescript/js_of_ocaml) also produce nice js output but my background with Clojure has left me enjoying the benefits of being a functional language that's part of a larger ecosystem and I'm comfortable enough with .net core to be willing to treat F# as a viable language outside windows.
Earlier quoted context omitted.
> 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…
This fundamentally reduces the usefulness of hash representations though. Instead of thinking of dict keys, think sets. 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…
> This fundamentally reduces the usefulness of hash representations though.
> Instead of thinking of dict keys, think sets.
By the way, I'm not talking about any particular implementation.
Earlier quoted context omitted.
Yeah I read this a few weeks ago and was similarly put off. I will give him one thing: it got me to start thinking about what I wanted in a functional language that compiles into JS, which ultimately steered me towards Purescript. I think fundamentally he's correct, but the point that he is missing is the intended audience of Elm. He was not it. Elm is much easier to grasp than Purescript, for instance. There is less…
Can I ask if you have found any equivalent to the Elm Architecture in Purescript? I have looked at Elm, and Purescript and now Bucklescript, but I have not yet seen, or wired up myself, something like the Elm architecture. I should probably buckle down and learn the wiring I need myself, but I have been finding the typing a little tough.
Earlier quoted context omitted.
Keep in mind that Evan works at a company that has 55k lines of Elm in production. Neither Evan, nor the lead-developer of the company, feel that typeclasses, or something like it, needs to be in the language right now.
This is unconvincing to me. Just because Evan and his friends are happy to write boilerplate and copy-paste the same stuff over and over doesn't mean it's the right thing to do.
We don't "copy-paste the same stuff over and over." That would suck. Why would we be excited about a language that made us do that? Our Elm code is about as DRY as our JS code was before, except the Elm code is way easier to maintain.
This post is way too angry. The problem it describes is legitimate, but still just a problem to be fixed. Having the language maintainer need to bless packages with native bindings is strange, though. Tag the packages so that people know they use native bindings, then people can decide whether or not to trust them. You cannot build an ecosystem through one person.
Earlier quoted context omitted.
This fundamentally reduces the usefulness of hash representations though. Instead of thinking of dict keys, think sets. 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…
> This fundamentally reduces the usefulness of hash representations though. If you want something immutable just put something immutable in? > Instead of thinking of dict keys, think sets. It's the same that I already wrote for sets, and also the same I just wrote: If you want something immutable just put something immutable in. By the way, I'm not talking about any particular implementation.
> If you want something immutable just put something immutable in.
My point is what do you expect if you do this:
>>> x = (1, 2)
>>> y = (1, 2)
>>> set([x, y])
I would argue that you would expect:
>>> set([(1,2)])
Since x is equal to y. But if you base the hash by default on id, you would get:
>>> set([(1, 2), (1, 2)]) # set([x, y])
Since x and y are different instances (have different id()) properties. I would argue that it's more useful/predictable for built-ins to hash based on content rather than id().
However, you can still hash based on id() but simply creating your own object (as I demonstrated). So you get sensible defaults for built-ins but also the option of hashing mutable objects.