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

171–180 of 278 posts

Re: Elm in Production: 25K Lines Later

#171

Post by tel »

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…

Your argument seems to be that "Real World Haskell" uses obscure features that I and many others don't understand, thus Haskell is complex. This is true if it is (a) impossible to write "Real World" Haskell without using these features and (b) that these features are truly complex and not just unfamiliar.

An alternative hypothesis to (a) is that Real World problems can be solved by simple Haskell, but more sophisticate Haskell features pay their way often enough that skilled practitioners choose to use them nearly always. I don't know if I completely buy this, but I also don't know that I completely buy that there aren't examples of Real World Haskell that are simple.

Of course (b) is easy to criticize and painful to do so since it'll ultimately be this indefensible argument of "if only you knew what I know then you'd agree with me" which I think is stupid. Unfamiliarity is a complexity since it forces investment on all that would learn it---languages which avoid unfamiliarity are faster and more valuable tools for avoiding forcing that investment.

The only counterargument is a global one: if these techniques _are_ worth the investment then they will over time have an increasingly large impact on the culture of programming at large. Already this is coming true with first class functions, immutable data, preference for stronger typing, option/maybe types. Your personal investment into learning further ideas may be worth it if they pay out over a longer time period either by preparing you for where things are going (speculative) or by diversifying your thought process immediately (less speculative).

So you get people encouraging folks to learn Haskell because they personally have made the judgement that learning these things is great. If you're unconvinced that's a totally reasonable position to take. OTOH, learning new things can be fun and there's at least a small hill of anecdotal evidence that these things can pay their way at times.

Re: Elm in Production: 25K Lines Later

#172

Post by willtim »

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.

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

No this isn't true! Again, you clearly do not yet understand Monads. Please read Phil Wadler's paper.

What you have successfully demonstrated, is that the JavaScript snippets you have been advocating are not sufficient to understand Monads.

Re: Elm in Production: 25K Lines Later

#173

Post by seagreen »

dmitriid wrote: post #134
willtim wrote: post #129

Earlier quoted context omitted.

Now you have the condescending tone! However, it appears you don't understand the IO monad. Programming using the IO monad is pure functional programming with full referential transparency. Please read Phil Wadler's paper, you will not understand this from that JavaScript snippet. The only backdoors are escape hatches like unsafePerformIO which are used for low-level libraries and FFI, they can be disabled with pragm…

As soon as you have side-effects (an IO is a side-effect) you can through your assumptions about "strict conformation to definition" out of the window: --- treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. --- > It is much harder to stay true to that definition using the other languages, multi-paradigm or not. I doesn't matter if it's "hard". Your argument was…

You're making some good points here. Neither category theory informed typeclasses nor laziness are required for pure functional programming (henceforth PFP). Up until recently Haskell was the only PFP language in common use, so all those things got conflated in a lot of people's minds. Now we have PureScript (which doesn't have laziness) and Elm (which doesn't have laziness or typeclasses).

That said, you really should listen to @willtim about the `IO` type. Purity really is a big deal, and `IO` doesn't break it at all.

Re: Elm in Production: 25K Lines Later

#174

Post by computerex »

antouank wrote: post #150
StreamBright wrote: post #125

Earlier quoted context omitted.

I am more interested in the details that just this blank statement that everything is better. After trying Elm several times we failed to implement even basic things in it that we could do in React/Redux easily. For an average JS developer Elm is totally alien tech compare to React or Angular. For Haskell programmers Elm is pretty appealing because of the familiar syntax and type system, but the intersection of Haske…

For an average JS developer Elm is totally alien tech compare to React or Angular To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact. For example, I just got into a new team, and I have to now use what they use.…

Nothing is forcing you to use the trendiest JS libraries. Feel free to do your side projects in vanilla JS or with whatever library you want.

The constantly churning and evolving JS ecosystem isn't necessarily a bad thing, although it does demand some attention. On the flip side, there is a lot of pre-written reusable code and more gets added daily.

From an ecosystem point of view, elm doesn't hold a candle to JS. Also, you don't have to learn every single JS library out there. You don't have to use redux-sagas. Use whatever you want.

Yes, I know there are a lot of tools and a lot of options and that can be exhausting. But I don't think that's necessarily a bad thing.

Re: Elm in Production: 25K Lines Later

#175

Post by tomtheelder »

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 would disagree strongly with this, but I don't quite know how to put my objection into words. The enforced functional purity, "true" and incredibly friendly compiler, and the robust message system are all things that I don't think you really get in those other languages. To me, it's a bit like saying that you get all the benefits of Haskell in Java, because Java is also statically typed.

Re: Elm in Production: 25K Lines Later

#176

Post by antouank »

computerex wrote: post #174
antouank wrote: post #150

Earlier quoted context omitted.

For an average JS developer Elm is totally alien tech compare to React or Angular To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact. For example, I just got into a new team, and I have to now use what they use.…

Nothing is forcing you to use the trendiest JS libraries. Feel free to do your side projects in vanilla JS or with whatever library you want. The constantly churning and evolving JS ecosystem isn't necessarily a bad thing, although it does demand some attention. On the flip side, there is a lot of pre-written reusable code and more gets added daily. From an ecosystem point of view, elm doesn't hold a candle to JS. Al…

I don't want to, but the "market" is forcing me.

Being a contractor, I change teams and projects all the time. And most of the time when I join a team with an existing project, the devs that started it are pretty opinionated on everything.

So sadly simple vanilla JS is not an option if you want to be a preferable candidate for projects. Most of the teams prefer piling libraries upon libraries cause they think it will make things "convenient" or because it's the new exciting trendy library. Whereas I've seen the opposite in the long-term, they make things more complicated and eventually impossible to maintain/reason with.

I'm not trying to sell Elm to anyone, if you don't like it, don't use it. But to me the advantages are quite obvious and I'd take it over any JS framework/library out there. I just hope I could use it at work as well. There are only a few Elm jobs out there right now.

Re: Elm in Production: 25K Lines Later

#177

Post by tome »

runeks wrote: post #170
ykler wrote: post #61

Earlier quoted context omitted.

I don't think many people (and not the parent) "equate" FP with Haskell, but Haskell is in a way the most functional mainstream language because it is the only lazy one. You can have a purely functional language without laziness in principle, but, as Simon Peyton-Jones points has said, laziness, despite having serious costs, keeps a language designer honest by making it impossible to add side effects. The non-lazy la…

You’re mixing up laziness and purity. Purity makes side effects impossible, so to speak, not laziness. Haskell is the most functional language because a Haskell function is a mathematical function, which can only transform its arguments into a value. Everything is a constant in Haskell, and functions transform one or more constants into a single, new constant.

No he/she isn't. The argument (as advanced by SPJ) is that it is so awkward for a programmer to use side-effects in a lazy language that it is (practically, not theoretically) impossible for a language designer to add them.

Re: Elm in Production: 25K Lines Later

#178

Post by jnbiche »

tomtheelder wrote: post #175
jnbiche wrote: post #133

Earlier quoted context omitted.

> 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 would disagree strongly with this, but I don't quite know how to put my objection into words. The enforced functional purity, "true" and incredibly friendly compiler, and the robust message system are all things that I don't think you really get in those other languages. To me, it's a bit like saying that you get all the benefits of Haskell in Java, because Java is also statically typed.

Please read my comment again, I said "many if not most" of the benefits. And I was referring specifically to the tire system, not the language as a whole.

Listen, I love pure functional languages, but the step up from JavaScript to flow in program correctness is greater than the step up from flow to elm (in my opinion). Flow even has sum types.

Have you actually tried flow?

Re: Elm in Production: 25K Lines Later

#179

Post by mrkgnao »

Ar-Curunir wrote: post #163
mrkgnao wrote: post #69

Earlier quoted context omitted.

The solution isn't more "pragmatism", it's an actual "incredibly powerful type system" like Haskell's. In my projects JSON decoding is just instance FromJSON Foo and that's it.

It's the same with `rust` and `serde`; it's a great feeling!

I can imagine :) I think over in Rust-land it's something like

   #[derive(FromJSON)]
isn't it?

Re: Elm in Production: 25K Lines Later

#180

Post by _gi12 »

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/encoders in Haskell only work if the shape of your JSON perfectly matches your record definition.

Writing decoders in Elm is not hard. It's manual. It's explicit. It forces you to specify what should happen if the JSON object has missing fields, incorrect types, or is otherwise malformed. There's a slight learning curve and it can be time consuming at first, but it guarantees that your application won't blow up at runtime because of some bad data. Because of this, JSON decoding is frankly one of my favorite parts about Elm.

Typescript, on the other hand, offers no such guarantee. If you write a function that takes an Int and you accidentally pass it a String from a JSON response, your app will blow up and there's the nothing the compiler can do to help you. Personally, I'd rather write JSON decoders than have my app blow up because of a silly mistake.

Post reply on HN