Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm in Production: 25K Lines Later

charukiewi.cz

Post reply on HN
Print view View original

191–200 of 278 posts

Re: Elm in Production: 25K Lines Later

#191

Post by mrkgnao »

dmitriid wrote: post #135
mrkgnao wrote: post #122

Earlier quoted context omitted.

Yes, you should care about the laws! They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. I mean, you can't call something with a "flatMap" method and a "return" method a monad! There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly.

> They allow you to edit code without the aforementioned released-last-week test runner having to check all your code after a big refactor. Oh wow. How did I ever live with big refactorings before? > There are tons of nonsensical definitions that fit that which are going to become very unpleasant to use quickly. I recently learned that, apparently, I've been using "monads" and "monadic composition" for years now, nev…

The unpleasantness arises when writing Monad instances that don't follow the laws. Setting your disingenuity aside, try using

  xs >>= f = concat (reverse (map f xs))
or

  Array.prototype.chain = function (f) {
    return reverse(this.reduce((acc, it) => acc.concat(f(it)), []))
  }
(I don't know how JS works, but you get it) instead of

    xs >>= f = concat (map f xs)
and enjoy refactoring your code, blissfully and consciously ignorant of the laws that make a monad a monad. The laws aren't just supposed to enrich the "life of the mind".

Re: Elm in Production: 25K Lines Later

#192

Post by willtim »

runeks wrote: post #162
willtim wrote: post #33

Earlier quoted context omitted.

It we would be easy to add simple built-in constraints for things like equality, without jumping all the way to full-blown type classes. This would be a very minimal change to the type checker and should not require a rewrite.

This example with the absence of an Eq class is not related to just equality, it’s a symptom of a lack of generics. You’ll end up with a lot of special, built-in classes (e.g. Ord), while just adding simple type classes to Elm would make all of this solvable in a library (e.g. Elm’s Prelude). Surely, if we agree that Eq, Ord, and Foldable are useful, they’re probably not the only useful type classes in existence.

I think the Elm folks are playing a waiting game. There are alternatives to type-classes such as the proposed modular implicits for OCaml.

Re: Elm in Production: 25K Lines Later

#193

Post by empath75 »

dmitriid wrote: post #154
willtim wrote: post #151

Earlier quoted context omitted.

These functions do not perform IO, they return IO actions that can be further composed. They are invoked from other functions that also return IO actions, again no IO is actually performed until the top-level final composite action is run by the runtime. All composition of IO actions is performed with full referential transparency and adherence to the Wikipedia definition.

Potato potato. In the end, when the program is run, functions will be run, and side-effects will be executed. Moreover, if you invoke these functions multiple times they will produce different results. Hence, no strict adherence to FP principles.

> if you invoke these functions multiple times they will produce different results.

the io monad is a pure function that produces impure code for the haskell runtime to execute (this isn't exactly accurate, but i think is an okay way to think about it). It will always produce the same impure code, and so is itself pure.

Re: Elm in Production: 25K Lines Later

#194

Post by mrkgnao »

dmitriid wrote: post #145
mrkgnao wrote: post #143

Earlier quoted context omitted.

> "simplest way to do BasicAuth" The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying. As for resources, here's a great intro to type-level Haskell: http://www.parsonsmatt.org/2017/04/26/basic_type_level_progr... > For some reason, functions that operate on types are called type families. That's the kind of thing you need to know. I doubt the aver…

> The simplest way to do BasicAuth in Haskell isn't Servant. I feel like you're intentionally misinterpreting what I'm saying. True, I re-read what you wrote, and argh . I need to learn to read. > As for resources, here's a great intro to type-level Haskell: > That's the kind of thing you need to know. So, we're basically returning to the root of my complaints > I doubt the average JS user knows how V8 optimizes exec…

> I doubt the average JS user knows how V8 optimizes execution of code, or whatever. That's what your insistent complaints about type theory amounts to: [...] Only a couple of people working on the compiler [use type theory].

> Wait. Are you telling me now is that writing a BasicAuth implementation in a "simple library that doesn't require you to have a PhD in type theory" is on the same level of complexity as knowing the inner workings of an advanced Javascript VM?

I rest my case. You're not arguing in good faith here, although you seemed to be doing a pretty good job at times. I'm saying that knowing enough to be able to add big new features to the Haskell compiler, like the computer scientists who drive GHC development, is similar to knowing how V8 works. :)

Re: Elm in Production: 25K Lines Later

#195

Post by Skinney »

empath75 wrote: post #186
_gi12 wrote: post #180

Earlier quoted context omitted.

I really wish people would stop spreading the meme that decoding JSON in Elm is "hard". Yes, Haskell allows you to automatically decode/encode datatypes, but this only works in the simplest of cases. For example, if your backend returns a JSON object with snake-cased fields, but your model has camel-cased fields, `instance ToJSON Person` won't work; you'll have to write a custom decoder. The automatic decoders/encode…

> Writing decoders in Elm is not hard. At some point, after enough people tell you that they can't figure out how to do something, one should admit that it is difficult.

Or that the documentation can be improved, or the API could be improved, or a number of other things. But really, JSON encoding/decoding in Elm boils down to specifying what the type of an object's field is. If that is difficult, interfaces and classes must be a nightmare.

Re: Elm in Production: 25K Lines Later

#196

Post by charukiewicz »

_gi12 wrote: post #180
ToJans wrote: post #8

First: > Elm has an incredibly powerful type system Near the end of the article: >Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e. {-# LANGUAGE DeriveGeneric #-} import GHC.Generics data Person = Person { name :: Text , age :: Int } deriving (Generic,…

I really wish people would stop spreading the meme that decoding JSON in Elm is "hard". Yes, Haskell allows you to automatically decode/encode datatypes, but this only works in the simplest of cases. For example, if your backend returns a JSON object with snake-cased fields, but your model has camel-cased fields, `instance ToJSON Person` won't work; you'll have to write a custom decoder. The automatic decoders/encode…

Author here. I agree with your points, and in my article I specifically mention that there are benefits to some of the "hardness" of certain tasks in Elm (type-safety in the case of JSON decoding).

But to claim that JSON decoding in Elm is not significantly more difficult than it is in JavaScript would be misleading. A front end developer that has only written JS will be surprised when he/she cannot just drop in the equivalent of JSON.parse() and get an Elm value out of it. I call it "hard" because there is a bit of a learning curve, and it does require some thought, and quite frankly it takes quite a bit of time if you have a large application like we do.

Moreover, I am not complaining. And I do not think people should be. As I said in the article, the tradeoff is worth it.

Re: Elm in Production: 25K Lines Later

#197

Post by Skinney »

jnbiche wrote: post #133
BoiledCabbage wrote: post #95

Earlier quoted context omitted.

> I cannot emphasize enough how much better working with Elm is. >In every single aspect. I just wish that it will get mainstream as soon as possible. I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge. I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her comp…

> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static…

I've used both Typescript and Flow, and this breaks down in practice. At least, it did for me.

Problem with both Typescript and Flow is that it requires discipline from you, your team, and those who provide third party libraries. If someone was lazy and inserted `any` at a key location, you can start having familiar bugs even if the type checker tells you everything is fine.

Re: Elm in Production: 25K Lines Later

#198

Post by empath75 »

Skinney wrote: post #195
empath75 wrote: post #186

Earlier quoted context omitted.

> Writing decoders in Elm is not hard. At some point, after enough people tell you that they can't figure out how to do something, one should admit that it is difficult.

Or that the documentation can be improved, or the API could be improved, or a number of other things. But really, JSON encoding/decoding in Elm boils down to specifying what the type of an object's field is. If that is difficult, interfaces and classes must be a nightmare.

Here is what people are comparing it to, in terms of difficulty:

json.loads('foo.json')

I spent 3 days about 6 months ago, off and on, trying to figure out json decoding in elm, and gave up on the language entirely. It wasn't a matter of simply specifying types. The syntax is confusing the compiler isn't any help. I had very little difficulty working with anything else in Elm, so I think there is a lot of work to be done there.

If there were a more painless way to do it, there are a lot of api's I'd love to write front ends for in elm.

Re: Elm in Production: 25K Lines Later

#199

Post by Nekorosu »

hellofunk wrote: post #104
Nekorosu wrote: post #93

Earlier quoted context omitted.

Worth mentioning that Clojure(Script) comes from a different school of thought (Lisps) and has its own approach to development called REPL driven development. It allows you to experiment a lot and fail fast. Large projects are absolutely doable but require more discipline and experience with the language from developer. For example you can start with a crude prototype and introduce clojure.spec later. When you do thi…

I agree with much of your points but a few things to add clarification: While lisps do traditionally provide repl-driven development and you can do this in Clojure, most Clojure devs I know are not actively working right at the repl. If you do like some aspects of repl-like interactivity, Elm does have elm-reactor which has some similarities to Clojurescript's figwheel, though not quite as mature or comprehensive. As…

Thanks for clarifications. I actually pay some attention to Elm evolution and check the official blog from time to time. I was much more interested in Elm several years ago and I even tried to get a job at Prezi (Evan Czaplicki was still working there at that time). In the end I like ClojureScript more. It has a good balance of agility and guarantees. It's more generic. REPL enables exploratory programming and live coding. Btw ClojureScript developers I know do use REPL.

I probably wasn't clear enough but I don't think Elm is easier to learn. It's quite the opposite. The good thing about Elm is great default libraries for SPA development (or isolated widgets) and great toolchain. You just use what's given and it works perfectly fine. In the end getting productive fast is easier with Elm than with ClojureScript. And it's easy to do all by yourself. Everything is pretty strict and official site has a lot of up to date tutorials. I also like that Evan values simplicity and Elm gets better and better in this regard.

Every language has its place. ClojureScript is my personal preference. It's just a good fit for things I like doing.

Re: Elm in Production: 25K Lines Later

#200

Post by Skinney »

endgame wrote: post #4

I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the po…

I used several FP languages before coming to Elm, like F# and ClojureScript. I prefer Elm, been using it for about two years, and haven't missed something like interfaces at all.

Then again, I'm also one of those wierdos who think Go works just fine despite the lack of generics (though I think Go needs generics more than Elm needs something interface'y). Still, things are getting done and I'm happier than with most other languages.

Post reply on HN