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

261–270 of 278 posts

Re: Elm in Production: 25K Lines Later

#261

Post by Skinney »

hudon wrote: post #251
Skinney wrote: post #250

Earlier quoted context omitted.

The difference here, is that a lazy programmer, when forced to handle this particular case, would use "Debug.crash 'should not happen'", which causes the Elm application to crash at runtime. The TypeScript program doesn't force you to deal with it, so the lazy programmer can assume everything works, no exception is raised, and you're now running with invalid state. To catch this bug in TypeScript, you'd have to write…

> Elm, again, forces you to write runtime type validation But it does not force you to handle failures correctly (as your lazy programmer example proves). Forcing you to handle a Left value from an Either type is not the same as forcing you to handle a Left value correctly. Elm doesn't save you from bad failure handling , which is what the post I replied to claimed. What Elm does do is remind you that you should hand…

The original post did not make that claim. It said Elm made you handle errors where they can happen. It said nothing about handling it well. Typescript will not remind you every where an error will happen, and so it is very likely that you do not handle every error, even if it is your intention to do so.

Re: Elm in Production: 25K Lines Later

#262

Post by codygman »

dmitriid wrote: post #94
mrkgnao wrote: post #89

Earlier quoted context omitted.

Speaking from experience, zero. > debug But the whole point of a good compiler is that it tells you when you're wrong ! (Instead of having to write hundreds of tests (and thousands of Node test runners).) > :> and : You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later. Observe: type API = "polls…

> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later. So, basically, "learn this thing without understanding what it does" :-\ Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it". > Definitely less t…

>> Speaking from experience, zero. You can just treat them as syntax, like the largest proportion of every other language, but with the opportunity of actually being able to write things like that yourself later.

> So, basically, "learn this thing without understanding what it does" :-\

> Reminds me of teaching Java to newbies: "oh, just type this syntax, you have to memorize it, don't worry about it".

I don't think what's recommended is the same.

Re: Elm in Production: 25K Lines Later

#263

Post by kccqzy »

pyrale wrote: post #211
kccqzy wrote: post #13

Earlier quoted context omitted.

That doesn't handle custom JSON schemas at all. I don't know much about Elm but at work in Haskell we mostly write FromJSON instances manually. It's probably the same amount of code as the data type definition.

Do you have examples of things that don't fit the vanilla FromJSON ? From the top of my head, there's lensed things (which can easily be done once with a LensJSON typeclass), and things which use a different serialization (e.g. no "tag" field, etc) for which there is little you can do, if each of your data types has its own standard. If they do, though, you could easily define a typeclass for each source (e.g. Stacko…

We don't do type classes for this purpose. If you have to interface with some JSON with predefined schema, we just write the instances manually. It's not that hard at all—usually it's just calling withObject with a series of lifted function applications `Constructor (o .: "field1") (o .: "field2")`. Remember the Parser type is a Functor/Applicative/Monad/Alternative/MonadPlus so there's a whole host of utilities for these classes that make writing such instances both simple and concise. Of course if you are doing simple things like removing the leading underscore on lenses data typed, just use TH to derive the instance, passing slightly modified `Options`.

If you need to manually handle tags, here's a snippet that can help you:

    -- | Safely accesses a JSON object where the value at a key is text. It takes an
    -- object, a key, and a continuation of what to do when this key is present.
    --
    -- Example:
    --
    -- @
    --     data D = A | B | C Int
    --     instance FromJSON D where
    --       parseJSON = withObject "D" $ \o ->
    --         o .:=> "tag" $ \case
    --           "A" -> pure A
    --           "B" -> pure B
    --           "C" -> C  (o .: "theInt")
    --           t -> fail $ "Unrecognized tag in type D: " ++ unpack t
    -- @
    (.:=>) :: Object -> Text -> (Text -> Parser a) -> Parser a
    o .:=> k = \m -> o .: k >>= withText ("Object with mandatory key "  unpack k) m

Re: Elm in Production: 25K Lines Later

#264

Post by [deleted] »

_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…

[deleted]

Re: Elm in Production: 25K Lines Later

#265

Post by neerajdotname2 »

_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…

I found it hard. I have been learning Elm for a few weeks. I have a background in Ruby and in JavaScript. I have a repo where I am trying difference cases. https://github.com/bigbinary/road-to-elm

Re: Elm in Production: 25K Lines Later

#266

Post by noshbrinken »

KirinDave wrote: post #253
noshbrinken wrote: post #252

Something I find incredibly off-putting about Elm is the evangelical and generally unbalanced tone taken by many prominent members of the Elm community. I almost never come across Elm advocates accepting a valid criticism of the language. The response almost always amounts to "you don't understand" or "yes, but". They spend a lot of time celebrating the compiler's humanistic virtues but seem less clearly humanist in…

> less clearly humanist in their relation to original thinking or diversity of thought So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them? > So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experi…

Thanks for the code snippets. That actually helps me to understand quite a bit how Elm's JSON parsing situation can be improved within the FP paradigm.

> So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them?

I'm not frustrated with responses to criticisms I've made. In fact, I haven't made any criticisms (except of course, the ones in the last comment :P). So I don't have any experience of anyone not making room for me. But I have observed some smart people with well-articulated suggestions get shut down. It's not that their suggestions weren't accepted but it was the way that their ideas were received. I haven't actually seen someone who isn't Evan C. contribute something significant that isn't "doing X like Evan would do it." In the entire world of this language, there seems to be 1 architect and a community of implementers. Now, there's nothing wrong with being an implementer. I am an implementer. But it seems easy to see that cultures are healthier when there are a diversity of ideas.

I think that your characterization of the Elm community as a "group of likeminded individuals celebrat(ing) their common point of interest" is actually close to what I'm talking about. It's great when a programming language community is passionate about the language. If people enjoy using that language, it's certainly a good sign. But I wouldn't trust the judgment of a group of people who can't critique what they love and are unwelcoming to those who do.

The counterpoint here is Dan Abramov and the Redux community. Dan is continually pushing people to understand why they are using Redux and not to see it as a solution for everything. That kind of transparency, and the continual acknowledgement by Redux maintainers that there is more than one good way to do something, is the kind of intellectual honesty that I'm using as a standard in my assessment of Elm.

> How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is?

I couldn't say and it wouldn't change my opinion of Elm.

Re: Elm in Production: 25K Lines Later

#267

Post by dmitriid »

empath75 wrote: post #193
dmitriid wrote: post #154

Earlier quoted context omitted.

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.

Riight. The "Platonic ideal" again. "It's not the language it's the runtime!"

Re: Elm in Production: 25K Lines Later

#268

Post by dmitriid »

willtim wrote: post #172
dmitriid wrote: post #154

Earlier quoted context omitted.

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.

Riight. The "Platonic ideal" again. "It's not the language it's the runtime!"

Re: Elm in Production: 25K Lines Later

#269

Post by dmitriid »

runeks wrote: post #183
dmitriid wrote: post #134

Earlier quoted context omitted.

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…

> 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 You misunderstand what an IO action is. An IO action in Haskell is a value which describes a side effect . For example, an IO Int is a value that describes a side effect which, at runtime will produce a value of type Int inside the IO monad. The difference is that th…

Riight. The "Platonic ideal" again. "It's not the language it's the runtime!"

Re: Elm in Production: 25K Lines Later

#270

Post by dmitriid »

tel wrote: post #171
dmitriid wrote: post #145

Earlier quoted context omitted.

> 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 sophistica…

> 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.

Life is finite, number of things to learn is near-infinite.

Do I have the lifetime to learn 10 Haskell language extensions to understand how the most basic piece of code works?

Post reply on HN