Elm in Production: 25K Lines Later(charukiewi.cz) |
Elm in Production: 25K Lines Later(charukiewi.cz) |
> 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, Show)
instance ToJSON Person
instance FromJSON Person
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.
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.
For example, here's how you rename a JSON field while serializing/deserializing a data type in Rust:
https://play.rust-lang.org/?gist=1b382bc1572858841d5e392435d...
You just annotate the field with #[serde(rename = "..")]. Here is a list of such annotations
https://serde.rs/field-attrs.html
Serde is also generic in the serialization format; the example I linked uses serde_json, and was adapted from its README here https://github.com/serde-rs/json
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.
data Person = Person
{ personFirstName :: Text
, personLastName :: Text
} deriving (Generic)
instance ToJSON Person where
toJSON = genericToJSON $ aesonPrefix snakeCase
instance FromJSON Person where
parseJSON = genericParseJSON $ aesonPrefix snakeCase
{
"first_name": "John",
"last_name": "Doe"
}I've worked on various ways to do JSON encoding in Purescript through datatype generics, but the recent RowToList machinery lets us use record types directly. I have a post and some links collected if anyone is interested:
https://www.reddit.com/r/purescript/comments/6mss5o/new_in_p...
You can go through the tutorial and know the language in two days. Seriously if you ever want a weekend project, try learning elm.
Even if you don't want to use it, but just to be exposed to the ideas.
You csn be writing productive code in a week. If anyone tell you Haskell (or Purescript) is less than months to be productive is not being honest about what production level productivity entails. You can learn the fundamentals in less time, but the prized significantly more complex abstractions makes ramping up significantly slower. And this is coming from someone who likes haskell and is enjoying learning the language.
As someone who has used a lot of languages over the years, I really do say spend a weekend trying it out. The language has great ideas and a great philosophy.
But perhaps it wouldn't save much code compared to custom-made parsers.
The amount of work you need to do in Elm instead is huge.
When you only have thousands of items in an array, you end up with performance discrepancies between older browsers like IE 11 and Chrome that are unacceptable outside of a toy application.
Can you explain what you mean here? Your explanation below suggests a runtime cost for the type system, which just isn't true.
I'm aware Argonaut's approach generates slower code. The nice part of any such happenstance in PureScript is that if you do find an issue it's easy to bang out some Javascript in a foreign call to do what you need.
I find outside of Slamdata, folks are keen to do this. PureScript is a very new language and is still finding ways to generate code efficiently in it's target environment.
In every single aspect. I just wish that it will get mainstream as soon as possible.
His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.
What all these things have in common is: it's easier to reason about the values in a program than the program counter, and that destroying information makes it harder too. And that, to a great extent, is why FP is useful. Even really basic FP in C# or Java.
and then
> 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. Doing this will require an understanding of how JSON decoding works in Elm and will usually result in quite a bit of code (our application contains over 900 lines of JSON decoders alone).
What a great pragmatic language
Programming in Elm had been a delight, especially when you let go of OOP and embrace functional concepts and practices. On one hand, you lose mental tools that you've relied on, but you gain the other tools you didn't even know existed before.
Where I really disliked about Elm is when I had to encode or decode JSON. It's a giant royal pain in the ass. Also, when you find you have to break out to JS often for libraries you don't want to write yourself, it's not a good fit--as I found out when write a toy interactive notebook to render markdown in Elm.
But for most SPA that just manipulate form data and communicate with the server, it's a pretty great fit.
- json-to-elm http://json2elm.com
- swagger-elm https://github.com/ahultgren/swagger-elm/
- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql
- elm-export https://hackage.haskell.org/package/elm-export
Once you've got the hang of it, it's not that hard either. Just time consuming. That's where json2elm comes in :)
Also, once you get the hang of it, you can use it as your safety layer for incoming data. To guard the app from any invalid response.
I've even used GraphQL for one of my projects, decoding worked fine as well.
Clojurescript's 're-frame' lib implements something similar to the Elm architecture and is quite pleasant to work with.
How does the Elm experience compare to the Clojurescript experience ?
More freedom on type-level programming would help, but that would certainly complicate the type system, and the only language I know that lets you fold over arbitrary record types is Ur/Web, which has a richer type system than even Haskell, and I don't see Elm adding things to its type system (other than type classes, hopefully), given that other interesting features were already removed because very few people used them.
> Want to measure the height of an element on the page at the moment a user clicks on it? Hard, in order to do this we had to make heavy use of event bubbling and writing JSON decoders for the native event.target object that is produced by an onclick event.
What would be considered best practice?
Is it best practice to re-implement this sort of thing? Seems one could easily find vanilla JS code and encapsulate it, or add a helper lib?
In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve.
As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.
I'm not making a joke but this is a valid point. And if it had ELMON (Elm object notation), things would be more straight forward.
- json-to-elm http://json2elm.com - swagger-elm https://github.com/ahultgren/swagger-elm/ - elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql - elm-export https://hackage.haskell.org/package/elm-export
It's worth noting that JSON decoding is not _hard_ as such, but it's harder than other parts of the language. It is more time consuming. Tools like these can help reduce the amount of time you spend hand writing decoders.
For an average JS developer Elm is totally alien tech compare to React or Angular
For example, I just got into a new team, and I have to now use what they use. I've been doing JS for 4+ years, and that stack I'm facing now, is alien and confusing to me. I have to invest time and learn what the hell those redux-sagas are, or what "magic" create-react-app tools hide, and in general, it's very confusing so far.
With Elm, I spent a few weeks 1 year ago to learn the language, and that was it. All the libraries are very simple to use because of the language. I doubt that learning "redux-sagas" will help me a year from now.
Also, Elm, gives a very coherent package. You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed. No webpack or babel or eslint or immutable.js or typescript or flow or any of those.
Not to go into the part of the safety and confidence the compiler gives you. Typescript or flow are not even close to that quality and guarantee level. Note that again you have to learn their syntax and configure them, so that's again a cost on top of learning JS. And they are as much alien as Elm.
FWIW, I start now side-projects in Elm, and I get things done way faster than with JS. And that's also what I see from other people as well, regardless of whether they come from JS or another language.
>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 compiler. It went from being that thing you have to "pass" to see your code work, to instead a faithful companion. Like having a trusted dog with you in the woods - an extra set of senses to help you out on your way.
Elm is not perfect (no language is) -but being perfect isn't the goal. A practical transition story, huge productivity gains and extremely maintainable code.
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 analyzers for JS.
And sure, when more people join Elm, bad-written libraries or silly paradigms will crop up, but I'm confident it won't be as bad as the JS landscape is today.
Time will tell I guess. -- Now back to stitching those JS libraries to write some code that might work. Bills have to be paid :)
Here are some JSON tools for Elm:
- json-to-elm http://json2elm.com
- swagger-elm https://github.com/ahultgren/swagger-elm/
- elm-graphql https://github.com/jahewson/elm-graphql, https://github.com/jamesmacaulay/elm-graphql
- elm-export https://hackage.haskell.org/package/elm-export
Because this [1], even though it seems to be just a experiment so far, looks really good.
I.e: doing
type MyTestStrMap = { a :: Int , b :: StrMap Int }
and then just calling
let result = handleJSON """ { "a": 1, "b": {"asdf": 1, "c": 2} } """
let newResult = doSomething (result:: Either MultipleErrors MyTestStrMap))
is kinda all I ever wanted in these haskell inspired languages?
[1] https://github.com/justinwoo/purescript-simple-json/blob/mas...
Was wondering whether it might be a slow server, but the app.js for the TodoMVC appears to be over a megabyte (1.21 MB, have a 4000 line Mithril app which is 500k uncompressed). What's up with that?
>> https://github.com/dmjio/miso/blob/master/examples/xhr/Main....
There’s no reason to use genericParseJSON here, you can just write “instance FromJSON APIInfo”. Or leave the instance declaration as it is and safely rename your record fields to e.g. currentUserUrl instead of current_user_url.
The purpose of the camelTo function is to convert “camelCaseExample” into e.g. “camel_case_example” by passing ‘_’ as the first argument. But the APIInfo data structure already uses record fields with underscores in them.
[1] https://fable-elmish.github.io/elmish/
[2] http://fable.io/
Now maybe Elm should stay simple and not jump all the way to multi-parameter type classes with functional dependencies, but it is already forced to pay some of the complexity burden to decide which types admit equality testing, comparison and so on.
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.
You have to do that in Haskell as well (where »you« can be you or the compiler via DeriveFunctor); the key difference is at the use site: there is one map function (called fmap) that does the mapping, whereas in Elm (and pretty much all other languages that don’t have higher kinds while we’re at it) you have to use the specific map function for that type.
Erlang is FP. Javascript is FP. Ocaml is FP.
Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.
JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object.
In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve.
As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.
And you don't have to write that bit by hand:
http://eeue56.github.io/json-to-elm/
will generate the decoder for you for straightforward cases and give you a great starting point for more complex cases.
You also get proper ADTs to manage state: not asked/loading/loaded/error something that is tedious and error prone in Javascript.
An online converter is definitely not something I would advertise for a "production-ready highly productive amazing pragmatic language to be used in a serious company"
instance FromJSON Foo
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 experience into the "Elm way" of doing things
This could be said of a lot of PL environments. How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is? Sure feels like a lot to me.
> The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community.
Right but... what do you want? Acknowledgement? My friend, literally everyone here is agreeing it's harder than JSON.parse. No one argues it is "easier." I can't find a handy example in this thread of anyone saying, "Yeah this is great." There are tools to ease this pain, and there are ways to call external JS code that does this.
At the end of the day though, validating data structures on the wire both structurally and for content is a lot of work. Most Javascript projects don't do it. Hell, most typescript projects just say, 'Well if it breaks it breaks.'.
By pure coincidence this redacted typescript snippet is up on my other screen:
function validateTaskArgs(cdata: any, ldata: any): [boolean, IDomainObject1, IDomainObject2] {
if (cdata === null || ldata === null) {
return [false, null, null]
}
const cdkeys = ["key1", "key2", "key3"]
const ldkeys = ["key1", "key2", "key3", "key4"]
const checkKeys = (keyset: string[], obj: any) => {
const result = keyset.reduce(
(p, c) => { return p && !!obj[c]},
true)
return result
}
return [
checkKeys(cdkeys, cdata) && checkKeys(ldkeys, ldata),
cdata as IDomainObject1,
ldata as IDomainObject2
]
}
But earlier I actually linked a much more sophisticated piece of purescript that's about the same size and not only is easier to read and is self-describing (the code to build the objects IS the spec), but it uses those properties to report console errors. You can see it here:
https://gist.github.com/KirinDave/9af0fc90d005164743198692f3...
If you want to make Elm better at JSON, that's the sort of stuff you wanna ask for. And folks will rightly be resistant. Because the programming concepts that make that work (free applicative, in this case) are not things the elm target audience has learned about, yet. Elm's leadership is acutely aware of how big a stack of new concepts they're putting on everyone's plate, and they're cautious about offering more.
> 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.
> Just start by changing your type definition and the compiler errors will help you find everywhere that needs updating.
This is how most of Elm development gets done. I change the types and let the compiler tell me what actual code needs changing.
Clojurescript, on the other hand, doesn't have this "assistant", unless you're using Typed Clojure or Schema (it's been a year or two since I tried that, so can't speak from current experience).
The Elm Architecture is worth pursuing even in dynamically typed languages though :)
1) Re-frame and Elm are both backed by a virtual dom (Re-frame leverages React behind the scenes, Elm uses virtual-dom)
2) Both impose a single app state
3) Both require user events and outgoing state mutation to be explicitly defined somewhere outside of the context of a view
4) Both operate on a sort of "game loop" style of processing events and calling view functions
5) All data is immutable in both languages (though Clojurescript provides explicit mutable structures if desired, which require special syntax so any mutation is evident)
Differences:
1) Elm's model is pure FP -- data is passed to a function, and then it calls other functions. An individual view function in Elm cannot independently subscribe to any kind of data event, either a state change or a socket message, etc; it must receive the data it needs as an argument to the function only. Depending on who you talk to, this is either limiting or properly restrictive. It does mean that a branch of your Elm user interface should generally correspond to a single branch of your app state, or that view functions in complex interfaces must take quite a lot of arguments; this is a pattern for which re-frame explicitly offers a workaround (though you can also do it the Elm way in re-frame if you want). In general, these differences lead to more re-usable components in re-frame than in Elm.
2) Elm has no real asynchronous library for high-level concurrency. Most Clojurescript projects (at least large SPAs) often leverage core.async as an abstraction for large UIs that handle many independent processes simultaneously. Core.async makes clojurescript particularly versatile for accomplishing things in a single-threaded environment as if it were modelled with multiple threads.
3) Elm has its own compilation story that is separate from the JS ecosystem. The Elm devs are working on dead code elimination. Clojurescript projects are all built on Closure, which provides DCE, compression, and global inlining which can provide some projects notable speedups. The Closure libraries also give Clojurescript cross-browser abstractions for hundreds of common tasks in front-end development that have been battle-tested by Google in all of their web services, so it can greatly reduce development and debugging time for complex apps that run everywhere.
4) Elm controls JS interop much differently than Clojurescript. The tradeoff is that in Clojurescript you will inevitably spend more time debugging runtime errors, while in Elm you will spend more time developing your JS interop code and testing cross-browser compatibility.
5) There are many UI libraries available for re-frame because it can wrap existing JS tools (including wrapping UI libraries built for React). There are fewer for Elm, and it's more common to roll your own UI in Elm. There are pros and cons here. I've worked on two large projects in Clojurescript, one which was all custom UI components and another that leveraged polished libraries in the wild. The former took much much longer to make but looked more unique. Having the choice to go either way is a big benefit since project goals widely vary. If you are primarily a developer/coder and not a web/graphic designer, you may be frustrated at UI design in Elm. If you work with a designer, this is not a problem. But if you work alone, having access to a lot of UI tools can free up your time and efforts quite a bit, and Clojurescript has an edge here.
6) Types: Elm has static types, while Clojurescript offers clojure.spec (which is optional though widely used). Spec is a runtime contract system so you can guarantee that all args passed to functions or setup in data structures meet specified criteria; not just types of the args, but also any other predicates, such as a valid range for an integer, etc. For example, an Elm union type would be a Clojure set, where each element could be a specific data structure with other specs attached to it. However, Elm has proper static types, which are caught at compile time, not runtime. There are benefits of both styles. If you want to tightly catch very specific data aberrations that flow through an app, clojure.spec is easy to use for that purpose; but if you want more general checks before the program runs, Elm would be preferable.
7) Performance: All of Clojurescript libraries that wrap React (including Re-frame, vanilla Reagent, and Om) offer an interesting runtime optimization that I've not seen in other languages, and is not available in React itself. If the data that a view function requires (either via its arguments or subscription) has not changed from the prior render frame, then the entire view function is skipped without running, since its output would not be any different. What this means is vast sections of your app's code don't even need to run on each render frame, and this is not trivial. In a small app, it would make no difference, but in complex SPAs this can be very significant. Elm offers a library, Html.Lazy, that attempts something similar, though my impression is that most Elm projects do not use it since it can be tricky to explicitly add this behavior; in Clojurescript, it is built in automatically. In Re-frame, they go an extra step by de-duplicating any queries or subscriptions so that multiple views which use the same data context do not query, fetch or calculate the required data more than once, which is then passed to all requested functions. If you are working on an app that processes lots of data frequently, this can be the single selling point of using Clojurescript, as it frees up the CPU to deal with only those things that are guaranteed to require processing.
Clojure's syntax is very tight and concise, while Elm's language is elegant but more verbose. I have found that there is approximately a 2.5X increase in code size in Elm when trying the same ideas out in both languages.
All other things being equal, you can probably get a re-frame app going very quickly; if you need to prototype something or get to an MVP as soon as possible, it is really hard to beat Clojurescript compared to any other compile-to-JS language. If however you are going for application purity and a reduction in runtime debugging, Elm (or Purescript or some other statically-typed languages) would be a better fit.
Ultimately, Clojurescript is a general purpose language, while Elm has a very specific use-case; if you fit into the Elm model, it can be nice. If you need to reach outside that model, it is a challenge.
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 this is entirely your choice while in Elm you just have to write function signatures and types/structures definitions from the beginning.
ClojureScript has a very easy interop with JavaScript. Actually this is one of design goals. Consuming JavaScript library is super easy. For example most of virtual DOM libraries are built upon React. This is good because writing performant virtual DOM with older browsers support isn't an easy task.
The toolchain has code splitting and dead code elimination. It had it long before Webpack and can even optimize imported JS libraries code. As far as I know Elm still can't do it.
Another good thing is you can use Clojure(Script) both on the client and the server. This allows you to nearly skip data serialization/deserialization using powerful "transit" library. Actually you can use transit on server with several other languages. So it's not a lock in but it's much smoother with Clojure.
The libraries ecosystem is rich. For example Clojure(Script) has a mature WebSockets library (it's both server-side and front-end) with any kind of fallback you can imagine.
https://www.stackage.org/haddock/lts-9.0/aeson-casing-0.1.0....
Giving you automatic encoders/decoders like so:
instance ToJSON Person where toJSON = genericToJSON $ aesonPrefix snakeCase instance FromJSON Person where parseJSON = genericParseJSON $ aesonPrefix snakeCase
And the implementation of that package is like 4 simple lines for snake case; it's totally doable on your own for whatever you need https://github.com/AndrewRademacher/aeson-casing/blob/260d18...
I haven't had to do snake_case to CamelCase with Aeson before, but I have dropped a prefix before, like "userName" -> "name", "userAge" -> "age", and it was pretty easy and well supported.
Also I would note that this isn't as big of a deal for Haskell and Rust, because they're primarily backend languages, so they're more often sending out JSON in whatever form they please, rather than consuming it. In my experience the main consumers (Javascript on the web, Objective-C on iOS and Java on Android) use CamelCase anyway, so there's a natural compatibility.
Custom JSON which people invent as they go along is just going to present your system with pain over time.
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) mWith that said, VS Pro still has one of the best debuggers on any platform. To the extent that I think C# developers sometimes cut corners because the debugger helps so much.
It can run basically any Haskell library. That includes the ability to run multithreaded Haskell code -- the JS RTS includes a scheduler. You also get Software Transactional Memory. Lazy evaluation works just as usual -- and so on.
The tradeoffs become worth it when you have a sufficiently valuable base of Haskell code that you want to run in the browser, and when your users aren't very constrained by page load time. Say, if you have some complicated tricky logic that you don't want to rewrite in another language, but you want to use it in your web app.
It's likely a design decision to force people that otherwise wouldn't to represent their data in a more structured way.
Unless they are really really good at keeping backwards compability in both language and build tools.
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.
Generate JavaScript with great performance and no runtime exceptions.
Here's a short example in Typescript:
import fetch from "node-fetch"
interface Post {
user_id: number,
id: number,
title: string,
body: string
}
const postUrl = 'https://jsonplaceholder.typicode.com/posts/1'
const show = function(post: Post) {
console.log(post.user_id)
console.log(post.id)
console.log(post.title)
console.log(post.body)
}
function getJSON(): Promise<Post> {
return fetch(postUrl).then(x => x.json())
}
getJSON().then(show)
Everything in programming is about tradeoffs. If you don't care about strong type correctness, use something like Typescript. If you do care, Elm is a great choice.
[1]: http://elm-lang.org/
And yes, it is. Here is code from my own project:
Json.map3 HintTemplate
(Json.field "ID" Json.int)
(Json.field "Text" Json.string)
(Json.field "Image" Json.string)
Instead, there's this temporary hack[0]:
> Note: Equality (in the Elm sense) is not possible for certain types. For example, the functions (\n -> n + 1) and (\n -> 1 + n) are “the same” but detecting this in general is undecidable. In a future release, the compiler will detect when (==) is used with problematic types and provide a helpful error message. This will require quite serious infrastructure work that makes sense to batch with another big project, so the stopgap is to crash as quickly as possible. Problematic types include functions and JavaScript values like Json.Encode.Value which could contain functions if passed through a port.
As you say, Haskell's version of (==) has the type Eq a => a -> a -> Bool, and function types do not belong to Eq.
[0]: http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Bas...
#[derive(FromJSON)]
#[derive(Serialize, Deserialize)]
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.
Aside from the repl, you are right that you can get a proof-of-concept going in Clojurescript extremely fast so if you want to see if an idea succeeds or fails before investing lots of time, you can't beat Clojurescript.
The Elm toolchain is slowly evolving to include things like dead code elimination (which it doesn't have yet but probably will in the near future). However, I think it will be a long time (if ever) that Elm will support global inlining, automatic variable renaming and some other optimizations that come for free with the Google Closure compiler support. The other important difference is that as the Google Closure compiler adds features or further improves its optimizations, these are mature and widely used and immediately available for free without much (if any) extra work on the Clojurescript team. It's a philosophical difference that the Elm devs prefer to solve these problems on their own rather than leverage existing tools in the industry, but since the Elm dev community is small (much of it is only one person), this means that lots of time must be spent on these solutions at the expense of features more specific to the Elm language.
Also I think you are right that Elm as a language is a little easier to learn than Clojurescript (though to someone new to FP, both Elm/Haskell style syntax and Lisp syntax might be equally bizarre). But I think that ease is made up for by some of the concepts in Elm that can be difficult to learn (decoding, Tasks, ports, etc), so it's probably a net flat difference on the learning curves between the two systems.
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.
But of course ClojureScript's JS is generated carefully so as to be better optimizable by Google Closure Compiler, and that's not the case with Elm. IIRC, in version 0.19 Elm will change it's JS so that it's better optimizable by uglifyjs.
No, you can't use the advanced optimizations from Closure compiler in Elm. This is unlikely to change any time soon because Elm's compiler emits JS that directly violates one of the restrictions that Closure requires for advanced optimizations, namely the referencing of field names as a string.
Let's take Wikipedia:
-- start quote --
In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements. In functional code, the output value of a function depends only on the arguments that are passed to the function, so calling a function f twice with the same value for an argument x will produce the same result f(x) each time
-- end quote --
Haskell doesn't strictly conform either, because it allows side effects (event though it's "only through escape hatches"). There's no such thing as a "pure functional programming language".
Let's take it from the top:
"In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data."
All of the languages I listed support this style. The moment you write an IO monad inside a function in Haskell, you break the illusion of Haskell's strict conformation to the definition.
Doesn't really answer the question I posed though.
It's introduction is: "You know how it takes so much effort to produce even the simplest of programs when JSON parsing is involved? Wouldn’t it be nice if you could breeze right on by that step and get on with writing your business logic? This is what you’ll get with The JSON Survival Kit, a short ebook on JSON decoding in Elm."
Wut
instance FromJson HintTemplate where
parseJson = withObject $ \o ->
HintTemplate
<$> o .: "ID"
<*> o .: "Text"
<*> o .: "Image"
liftA3 f a b = f <$> a <*> b
Industry uses everything and anything. Heck, Javascript is (arguably) world's most popular programming language, used everywhere.
Haskell is used by Chase Bank. J and K are used by banks (J is used by SAP AFAIK). There are stories of Smalltalk running entire factories. There's Active Oberon in a nuclear plant in France. Excel is the world's most widely used FRP environment (unsurpassed, I might add, by anything anyone can offer).
For almost any programming language you name, I will probably find examples of people using it in an industry somewhere, no matter how good, or bad, or obscure, or popular, or well designed, or badly designed a language is.
"You need a PhD in type theory" is a hyperbole which I use to say "to proceed to any advanced level in Haskell you will need to dive quite deep into type theory as it's highly likely you will not even understand how most of the libraries you use work. Most of documentation and material around Haskell is riddled with incomprehensible jargon that often assumes the reader is already versed in any number of obscure Haskell things. Haskell has always been and remains a language designed to specifically test multiple theories of language and types design, and will remain such a language for a foreseeable future, no matter how people try to make it 'more approachable' or 'more pragmatic', and no matter how many people 'use it in the industry'."
Also a ton of other financial services companies: Morgan Stanley, Standard Chartered, and so on. Facebook has, in the recent past, hired a lot of well-known Haskellers. Bunch of hedge fund-ish things do too. Jane Street uses OCaml and does a lot of AdWords targeting at Haskell users :P
I don't know a shred of "type theory" (although I'm interested): you probably mean something else. Monad transformers aren't even categorical abstractions; they evolved from the needs of Haskell users.
> Haskell has always been and remains a language not opposed to testing multiple theories of language and types design
There, fixed that for you. Seriously, why don't you make a good-faith effort to dive into Haskell (as opposed to learning just enough of the jargon to be able to troll with apparent seriousness) before lambasting the things that make it a joy to work with?
Basically, in an ideal world we would have a "pragmatically typed" programming language. Basically something in between "weak dynamic typing of Javascript" and "strong static typing of Haskell".
No such language currently exists, and this makes me sad. It's also hard to come up with a proper definition for such a language :)
Souunds like one of the many strong dynamic languages with optional static typing/typechecking.
That's not exclusive with being a troll.
> Basically, in an ideal world we would have a "pragmatically typed" programming language.
Yes, it's called Haskell. Or, if you don't like purity, either OCaml or F#.
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.
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.
>>> You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed.
Elm is still in alpha, and is adding and removing breaking features all the time. (See ports for example) [1]
>>> No webpack or babel or eslint or immutable.js or typescript or flow or any of those.
If you are integrating elm into any kind of existing application, you will likely need webpack. [2]
>>> I doubt that learning "redux-sagas" will help me a year from now.
Given redux is an order of magnitude more popular than Elm is, and Redux Saga is the most popular effects handler library for Redux, I would not agree with this statement. Learning about generators is valuable regardless.
[1] https://github.com/elm-lang/elm-platform/blob/master/upgrade...
[2] https://www.elm-tutorial.org/en/04-starting/03-webpack-1.htm...
Elm has had 2 releases since 2015 which had breaking changes. The elm-upgrade[0] tool has automated away a lot of the upgrade progress, and the compiler tells you about all the remaining things that need to change.
Put another way, Elm doesn't actually change very often, and when it does, it is typically a smooth ride. (I've been around for 5 breaking releases, and all but one of them were very easy.)
> If you are integrating elm into any kind of existing application, you will likely need webpack.
If that existing application is already using webpack, then sure, you'll probably keep it. But you don't need it for Elm.
For example, we use Elm at work (on a 150,000 LoC Elm code base) and we actually moved away from Webpack because Elm doesn't need it and we weren't happy with its UX. :)
Easy to develop and maintain, big check.
Widely used so you can hire - it's usually easier to hire Elm developers because there are more people who want to use it than jobs hiring for it. The opposite is true for JS. So...better than check, at least for right now! :)
Here is a CTO giving a talk about his company's experiences with Elm:
"Elm from a business perspective" - https://www.youtube.com/watch?v=DvQI1KntMhk
For example:
https://groups.google.com/forum/#!msg/elm-discuss/92dXqmB4nJ...
But this is common in niche languages. Most of my background is in Clojure, which has a vastly larger userbase than Elm, but it can still be very difficult to find good developers for it. Many of the professional Clojure developers I know learned the language on the job when they went to work for a company that used it. I wouldn't doubt it is similar with Elm. I saw a presentation once by a CTO of a company that started using Elm in production, and he mentioned that hiring is one of the larger risks to adopting it. But that shouldn't necessarily stop anyone, depends on a company's goals (and spirit).
As a CTO and the author of the OP, I can say with confidence this statement is false. Elm works correctly, is easy to develop in, and is easy to train developers that have experience in other languages to write Elm.
Basically every obscure overly complicated concept that Haskell throws at you (all the while pretending to be the only true FP language out there) can be explained in 5 to 10 lines of Javascript: https://github.com/hemanth/functional-programming-jargon
Compare and contrast.
- Monad explained in Javascript: https://github.com/hemanth/functional-programming-jargon#mon...
- Timeline (sic!) of monad tutorials for Haskell: https://wiki.haskell.org/Monad_tutorials_timeline
The worst crime against humanity though is Haskell crap seeping into other languages (such as ramda, for instance: http://ramdajs.com)
That is extremely false. Haskell isn't even a good playground for academic type theory -- you'd want Agda etc. for that. The development of the language over the last few years has been characterized by pragmatism and a focus on backwards-compatibility, which is why you can take code from something like ten years ago and have it run without issues on modern versions of the Haskell compiler with little to no modifications. (Let's not talk about how long code written in "modern" JS lasts.)
And I'd really like to see type class constraint resolution with functional dependencies, or Hindley-Milner type checking, or something of that sort implemented in "5-10 lines" of JS.
"There he goes again with his mumbo-jumbo," you say. That's right, you don't need to care about those things to write Haskell. What you meant is implementations of typeclasses ("interfaces") like Monad, Functor, and so on: they don't take much more code in Haskell.
Array.prototype.chain = function (f) {
return this.reduce((acc, it) => acc.concat(f(it)), [])
}
instance Monad [] where
xs >>= f = concat (map f xs)
return = pure
whenM :: Monad m => m Bool -> m () -> m ()
whenM cond action = do
condition <- cond
if cond then action else pure ()
--
As for an example of why I think Haskell has the right ideas (few of us will say it's the "best language evar"):
I'd really like to see a JS version of the Servant library, which takes an API spec for a server and actually generates a fully functional server from that. Here's a description:
https://news.ycombinator.com/item?id=14149200
Does this strike you as idle theoretical self-enjoyment?
almost immediately followed by
> And I'd really like to see type class constraint resolution, or Hindley-Milner type checking
You don't even see the irony in that, do you?
> they don't take much more code in Haskell:
riiight. I won't even go into the number of things that need to be explained there before you even start explaining what the code does.
> Notice that your 5 - 10 lines of JS don't let you write code that works in any monad, whereas I can easily write
Maybe, maybe not. Depends on your requirements, really. The core language might never get this, but these 5-10 lines of code do some very important things:
- they explain monads faster and clearer than any of the countless monad tutorials that exist for Haskell
- they demystify monads and show that: hey, you've probably been writing monads all along (and re-implemented them yourself countless of times, no doubt)
- they (by necessity) dumb down the jargon-heavy lingo for easy consumption by average Joes like me :)
Edit: that page in particular has also shown me that I have used easily half of Haskell's things (functors of all flavors, monads, comonads, etc. etc. etc.) countless times over the years in Javascript and Erlang. I didn't even know I did, because no one scared me off with the theory, and strange explanations and names :)
It does.
How many PhDs does one require to understand/correct/debug all the :> and :<|> etc.?
"Go and read", "anti-intellectualism".
So presumably the same concepts can be explained in 5 to 10 lines of Haskell too.
I think you're confusing the refinement and polishing of ideas that's taken place in Haskell over the last two decades with the succinct presentation of those ideas once they've been worked out.
The funny thing, this is the trouble that plagues other Haskell-inspired work (such as Purescript)
Why don't you make a good-faith effort to assume that your opponent has actually done some good-faith efforts?
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.
Laziness matters less in a FP language because if we consider non-termination an effect (impure), all pure functions should behave exactly the same regardless of whether they're "lazy" or not (plus in FP sameness is defined as same values, due to "value-semantics" - unlike OO where every object has a unique identity, different from all others) because in the absence of side-effects order of evaluation is not important.
Of course reality is different, and laziness has very visible and important effects when Haskell programs run on today's computers :)
1. Is it the most functional language because it's lazy? No
2. Is it the most mainstream language because it's lazy? No
3. Is it the most functional mainstream language because it's lazy? No + no = no
Laziness does not a functional language make.
> You can have a purely functional language
What would be the purpose of a pure FP? Oh. There would be no purpose.
> laziness ... keeps a language designer honest by making it impossible to add side effects
wat
Laziness is delayed execution. That's it. There's _nothing_ stopping you from delaying a side effect.
Laziness is about more than just side effects.
I think "evaluation" or "reduction" would be better words than "execution" here. Laziness (call by need) is an evaluation strategy for (beta-)reducing expressions, which has two nice properties:
- If an expression can be reduced without diverging by some evaluation strategy, then it can be reduced without diverging using call by need.
- Efficiency, in the sense that no duplicated work is performed.
The other common evaluation strategies are call by name and call by value. Call by name has the first property, but not the second; so there are cases when it's exponentially slower than call by need. Call by value has the second property, but not the first, so there are cases when it diverges unnecessarily.
This 'unnecessary divergence' is a major reason why most programming languages end up overly complicated to understand (at least, mathematically). For example, consider something like a pair `(cons x y)`, and its projection functions `car` and `cdr`. We might want to describe their behaviour like this:
∀x. ∀y. (car (cons x y)) = x
∀x. ∀y. (cdr (cons x y)) = y
This is why Haskell programs can focus on constructing and destructing data, whilst most other languages must concern themselves with control flow at every point (branching, looping, divergence, delaying, forcing, etc.).
This is true, but unconstraimed side effects are too difficult to reason about in a lazy language to make them practical. So in practice, very few lazy languages have unconstrained side effects.
This reminds me, I need to write a blog post (which is tangentially about Haskell, but mostly about statically typed languages)
This is not a valid analogy (and no analogy is ever valid).
> In js it might be error handling and state management. In Elm, its decoding json.
Yeah, and Go has trouble with generics.
It doesn't mean it's a feature that has to be vigorously defended. Especially if it's basically the very first thing anyone will have to do in any web application in a language that is meant for client-side web programming
I'm not sure anyone is defending it. At least, I'm not. Basically Elm's compromise is safety, and less runtime complexity then Haskell. The trade off there is boilerplate. As with most things, there is no free lunch. I've stopped using Elm precisely because of these issues, but I understand why Evan made the choices he did.
Surely, if we agree that Eq, Ord, and Foldable are useful, they’re probably not the only useful type classes in existence.
Even more importantly, deriving doesn't change the semantics of the language. You could in principle do exactly the same things without deriving as you can with.
It is much harder to stay true to that definition using the other languages, multi-paradigm or not. That is why Haskell is so often mentioned in the context of FP.
--- 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 that "Only Haskell strictly conforms to that definition."
No. Haskell conforms stricter. It doesn't mean that none of the other languages are not FP, or cannot be used to program in functional style.
> That is why Haskell is so often mentioned in the context of FP.
Yes. And the problem is that people treat the features that Haskell has as requirements to be considered a functional programming language.
- Typeclasses/Liquid types/Dependent types are not FP
- Pattern matching is not FP
- Laziness is not FP
- A whole bunch of anything else is not FP
Again, you are unfortunately quite wrong. You do not understand the IO Monad. No IO is ever performed in any code written inside the IO monad (unless using unsafePerformIO).
Please take some time to fully understand Haskell before criticising it so openly on a public forum. Perhaps then it might not all seem rather pointless.
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.
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 the IO Int is a value, it’s a constant which describes how to perform something at runtime (also called promises in some languages). It’s like a callback function, which takes a value as an argument that will be available when it’s called (at runtime).
The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object (missing field, in this case). But nothing in Elm forces you to handle it well, so if the programmer forgot to handle it well in TypeScript, they will do the same in Elm, and the end result will be the exact same: a runtime failure.
I think that's a totally fair criticism. I also believe that the Haskell resources can provide further value to you (and others in your position) over time if you choose to study them. Similarly, studying category theory or type theory or logic could.
Are these practical things to do? It depends upon your goals.
Also, #haskell on IRC has been, without a doubt, one of the friendliest learning environments I've ever seen. Drop by sometime if the mood strikes you. :)
Monads are a very general and powerful abstraction that are not adequately described by your example. My advice to anyone is to read Phil Wadler's seminal paper, it is very easy to read.
No.
> The only difference in your example probably is that Elm will force you to handle the case where your interface doesn't match the response object
Which means that no exception have been thrown. You've handled it, however poorly, and so you've made a conscious decision about how to deal with it.
In TypeScript, this is much easier to forget, because you don't have a compiler that forces you to deal with it. If you're lucky, this causes a runtime exception at the place the error occurs. More likely, however, no exception is raised, and you get an error down the line which is hard to notice and hard to debug.
Like, there's nothing in TypeScript that forces the developer to use the correct types. A lazy developer could just use "any" everywhere. So if the programmer doesn't handle this well in JavaScript, they will do the same in TypeScript, and the end result will be the exact same: a runtime failure. This, however, doesn't mean that TypeScript isn't a great tool that helps developers avoid runtime errors, it just means that this particular programmer doesn't take advantage of the tools at his/her disposal.
What I have a problem with is using an example where the programmer is lazy in TypeScript, then assuming the programmer is NOT lazy when coding in Elm.
If you just print an empty error string and your app continues running assuming it decoded successfully, you can be in as bad a place as the app that crashed. Actually, in some mission critical cases, failing hard is safer than continuing with corrupt data.
In both cases, TypeScript AND Elm, you must do work to handle the failure to decode gracefully, it will actually be less work in TypeScript because you have less to specify. The only difference is that in Elm, you are reminded more often to do that work.
This is completely false. Elm's type system will force you to handle the decoding failure at compile time. The `decodeString` function has the following type:
decodeString : Decoder a -> String -> Result String a
This is not a "runtime failure". This is the compiler forcing you to explicitly spell out what you want to happen the case of a decoding problem. The difference between Typescript and Elm is that Typescript's compiler will happily let your program crash when this type of issue occurs, whereas Elm's compiler won't.
So, no, what I said is not "completely false"
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?
* Lack of purity. You can unintentionally trigger side effects from a function that's a supposed to simply return a value.
function add(x: number, y: number): number {
fireTheMissiles()
return x + y
}
I agree. Which is why I said "many if not most" benefits, not all benefits.
> It's impossible to validate that external JSON data is the correct type at runtime.
Not sure I understand what you're saying. Of course you'll get a runtime error if your external JSON is the wrong type, what else could you do? Accept the data and enter an inconsistent state?
However, similar to the Elm JSON validation, in Typescript and Flow, you can write schemas to to runtime validation of external JSON. There are multiple libraries for this.
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.
1. https://github.com/gajus/eslint-plugin-flowtype#eslint-plugi...
I'm not saying that typescript/flow is bad. Whenever I have to use node.js, I end up using typescript. But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be.
You have one case branch that looks like:
GotUserList (Ok userList) -> ...
GotUserList (Err _) -> ...
> 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" :> Get '[JSON] [Poll]
:<|> "polls" :> Capture "question_id" Int :> Get '[JSON] Poll
:<|> "polls" :> Capture "question_id" Int :> "results" :> Get '[JSON] PollResults
urlpatterns = [
# ex: /polls/
url(r'^$', views.index, name='index'),
# ex: /polls/5/
url(r'^(?P<question_id>[0-9]+)/$', views.detail, name='detail'),
# ex: /polls/5/results/
url(r'^(?P<question_id>[0-9]+)/results/$', views.results, name='results')
]
Easier to maintain? Check.
Easier to read? Check. (If nothing, because of the lack of regexes.)
Defines the response type too? Check.
Easy to refactor? Check! Tired of typing "polls" at the beginning? Just lift it out: turn
type API = "polls" :> Get '[JSON] [Poll]
:<|> "polls" :> Capture "question_id" Int :> Get '[JSON] Poll
:<|> "polls" :> Capture "question_id" Int :> "results" :> Get '[JSON] PollResults
type API = "polls" :>
( Get '[JSON] [Poll]
:<|> Capture "question_id" Int :> Get '[JSON] Poll
:<|> Capture "question_id" Int :> "results" :> Get '[JSON] PollResults
)
> How many PhDs does one require to understand/correct/debug all the :> and :<|> etc.?
Definitely less than it takes to become comfortable with the quirks of literally everything in JS: perhaps you should give something an honest shot before telling people who have derived real-world benefits from using it in production that it's useless?
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 than it takes to become comfortable with the quirks of literally everything in JS: perhaps you should give something an honest shot before telling people who have derived real-world benefits from using it in production that it's useless?
A real app is not just "hey, memorize this DSL and type it". I've found Haskell unapproachable on multiple occasions. And yes, I've completed my obligatory "Haskell from first principles" and "Learn You a Haskell for Great Good!" :)
If you've picked up the stuff in LYAH, you're ready to learn what type operators are (that's where :> and friends come from, they're just things like Maybe but written infix, so they're probably defined as
data a :> b = ColonPointyThing a b
or something like that.) Servant then pattern-matches on these types, essentially. For instance, if I can handle an API that serves endpoint A, and one that serves endpoint B, I can handle an API that serves both:
instance (Handler A, Handler B) => Handler (A :<|> B) where
handle req = ...
You'd hardly expect a beginner to pick up, I dunno, using React and Redux on a Webpack hot-reloadable setup on day 1 of "Javascript 101", but React is one of the best ways to sell modern web development (at least when I've been buying).
> 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.
I'm claiming that:
- the concept of monad can be explained in 5-10 lines in Javascript (demonstrable)
- the concept of a monad requires multiple years and tens of tutorials in Haskell (also demonstrable)
Lots of people get excited about "monads" and then rush out to write tutorials to try and capture whatever mental model they're using. These mental models may arrive at correct results most of the time, but they're often not really transferrable to another human.
Learn You A Haskell takes a different approach, in which you arrive at creating monads because you naturally derive them as a way to deal with the tedium of functional code w/out such mechanisms.
"Monad tutorials" are becoming much less frequent now that such approaches are offered. Everyone just says, "Go read this chapter or two of this freely available book and you're good to go."
You know, just like any major feature in javascript.
I do not mean to be condescending, but I feel very strongly about this.
Please rethink this approach. It is a bad approach. It fails to capture (what I think you) your argument (is) and antagonizes people needlessly. And quite frankly, a lot of people are being VERY nice by not following in the tradition of absolutely burying javascript for its nonsensical primitive type semantics.
--- start quote ---
> :> 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.
--- end quote ---
This is exactly what's recommended: just blindly type these things, your understanding is not required.
It becomes worse. Link: https://news.ycombinator.com/item?id=14890937
You need 10 language extensions to implement the simples things. Answer to that complain?
Oh, five of them are just workarounds [so, just blindly copy-paste them]
Yes, as long as you lint those libraries, too.
> A thing that typescript and/or flow doesn't support, is JSON. What if a JSON object doesn't match the type?
That's why you do runtime validations of your incoming JSON if you feel like you can't trust the data (and if it's an external API, you probably can't). How is this different from Elm?
> But I've been bitten several times by the fact that typescript isn't as strict as Elm forces things to be
In my experience with Flow, between the Flow analyzer and accompanying linter, you can make it just about as strict as you want with respect to types. The main thing you'll miss (as discussed elsewhere) is that unlike Elm, there's no way to guarantee referential transparency with JS and Flow.
Me, personally, I take short-cuts when I'm pressed for time, stressed, or in a bad mood (which happens more often than I'd like to admit). I can always improve the code later (which turns into never). In Elm, I can't cut corners (as easily). This makes me write better code using Elm, which in turn makes me happier.
You --can-- get the same experience with Javascript, but it does require more from you, the developer.
To catch this bug in TypeScript, you'd have to write runtime validation, which you are less likely to do, since you can just do JSON.parse. Elm, again, forces you to write runtime type validation, and handle the potential error (which could be something simple as crashing the entire application).
When it comes to reliability, that makes all the difference.
And I'm not arguing that Elm is great because of poor developers either. I do theese sort of things when I write typescript, simply because I just don't think about the error case that often. Elm is a wonderful straight jacket that makes me a better developer <3
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 handle failures, which I think is very valuable and I'm not arguing against (and is what you're arguing for). But you still need to write a correct handler, and Elm won't force you to do that!
Basically: what does it take to define (or even to just understand) a type-level DSL in Haskell, and a sufficiently advanced library in Javascript.
I can take apart almost any JS library and see/understand how it works. How much type-foo do I need to understand Servant? Or any other sufficiently complex Haskell library (a friend of mine has struggled mightily with Yesod and gave up after a month or so).
https://haskell-servant.readthedocs.io/en/stable/
There are definite advantages, and if you're willing to put in as much work as one, say, unconsciously puts in while setting up JS frameworks, understanding libraries like this is definitely doable. (Without the dissertation.)
Basically to actually understand what's going on, I'll need to learn DataKinds (at the very least).
And just to implement something as simple as BasicAuth, this is what I have to start with (https://haskell-servant.readthedocs.io/en/stable/tutorial/Au...):
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE UndecidableInstances #-}
Basically this is (in my mind) what's wrong with Haskell: it's overly concerned with the Platonic ideal.
Meanwhile that one page on jargon has shown me that I effortlessly implement any and all of those things daily (and understanding what I'm doing) without the need to understand "an idea". I just use the tool that solves the problem. If someone insists on calling this "monadic composition", or "lifting over typeclasses", or "zygohistomorphic prepromorphisms", so be it.
Haskell for some reasons insists that I should only go for "The concept of a monad, which arises from category theory, has been applied by Moggi to structure the denotational semantics of programming languages" and
A monad is a triple (M,unit,⋆) consisting of a type constructor M and two operations of the given
polymorphic types. These operations must satisfy three laws given in Section 3.
We will often write expressions in the form
m ⋆ λa. n
I read this and I think what's got you rustled here is that Monad is such a generic concept. It's quite higher level and so you can do novel things like write functions that don't know how they're executing, just that they are.
As an example:
-- Config is a typeclass that enables getting a
-- keyval from a config. The return type is MonadIO
-- because config might need IO.
loadTarget :: (MonadIO m, Config a) => a -> m a
loadTarget config = do
v <- grabKeyVal "host" config
w <- grabKeyVal "port" config
return (v,w)
But if the monad is an array and IO then you can specify many hosts and many ports and this code enumerates them all. If that's passed to a ping function like so:
loadTarget config >>= pingHostPort
-- alternatively
doPings config = do
hostPort <- loadTarget config
pingHostPort hostPort
tl;dr and finally:
You say this is stupid abstract stuff, but the folks delivering features to you in the Javascript world disagree. You have generators now, which are a much more real and fair explanation of how to model monads in Javascript than that silly code snippet you posted that doesn't capture the spirit of them at all.
What's more, careful application of these concepts leads to libraries which are just better than anything you can have without appealing to generators. A great example of this Purescript-config. Here is an actual (redacted) same of some code I use at work in an AWS Lambda function to read the environment:
https://gist.github.com/KirinDave/9af0fc90d005164743198692f3...
So I have complete error reporting (full sets of missing keys) just by describing how to fetch the values from the environment. I can transparently switch to any other file type under the covers by changing from using "fromEnv". I only know that there is a key-value store in there.
Doing this in OO is really, really hard to get right, because imperative OO code cannot easily parameterize the execution strategy hierarchically without appealing to generics and ad-hoc polymorphism. That's hard.
The applicative style adopted here is very simple to re-interpret, because we can parameterize code on monads and applicatives (which explain the execution strategy of this code beyond its coarse structure) as we see fit.
You can do that with generators but it's frustratingly hard. Doing it in a truly generic way? Even harder. For this approach, the results are free (and Free, but hey).
I can give you other examples of how Purescript makes certain difficult aspects of javascript simply vanish, if you'd like.
I have one complaint though:
> Doing this in OO is really, really hard to get right,
Why do you equate FP with monads? Moreover, why do you equate FP with Haskell/Purescript (statically typed FP with monads)?
In this case (an only in this case) would it strictly conform to FP definition.
* a description of the action to execute (e.g. read line from STDIN)
* a function that will take the result of the previous action (e.g. the line) and return the next action to execute (e.g. writeLine)
[readLine, \line -> writeLine(line)]
You could imagine this as a linked list of actions, where the "link" is actually a pure function you call with the result of execution the first part to get the rest of the list (or nil to terminate). This is still pure because the action itself doesn't do anything. If you return an action from a function, it doesn't actually execute, its just a value to be interpreted.
Does that make a real difference or is it just theoretical "purity"? Yes it does make a difference.
For example, if you create two action values, you haven't actually run anything yet, just created descriptions of actions. You could put them in a list and create an action description that will tell the runtime to run them in parallel, for example using: https://hackage.haskell.org/package/parallel-io-0.3.3/docs/C... ... or in sequence https://hackage.haskell.org/package/base-4.10.0.0/docs/Prelu...
For refactoring, it means that you can still take functions that return actions and substitute them with their values, e.g. if you have
readItems 0 = return []
readItems n = do
x <- readLine
y <- readItems (n - 1)
x :: y
main :: IO
items <- readItems 3
putStrLn "The first item is " ++ (head items)
read3Items = readItems 3
main :: IO
items <- read3Items
putStrLn ...
readFile :: FilePath -> IO String
writeFile :: FilePath -> String -> IO ()
And yes: I used the term "IO monad" incorrectly.
All composition of IO actions is performed with full referential transparency and adherence to the Wikipedia definition.
Moreover, if you invoke these functions multiple times they will produce different results.
Hence, no strict adherence to FP principles.
(You can argue about how justified that is, of course. I'm not going into that, but you might want to see what John Carmack has to say[0]. No, he doesn't end by saying "we should all convert to the church of Haskell now", but he does talk about how large-scale game programming refactors are made easier when you're working with no (or very disciplined) side effects.)
Monads are not the only way to deal with effects while keeping purity, although they were the first discovered and so on: algebraic effect systems as in Koka[1] (and as simulated in Idris or PureScript) are another alternative. Koka infers effects, so it's probably easier for a C-family programmer to pick up (I know little about it, though).
You can just use one of the raw HTTP servers, like wai or something. They expose an interface not unlike the ones you'll find in, say, Go or C++ or Node or something.
Also:
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE UndecidableInstances #-}
But that's not what I complained about ;)
It's funny how in a separate thread someone insists that I have to understand the whole concept of a monad, its three laws, read Wadler's paper etc.
In his thread however, it boils down to: oh, just memorise these lines of code, and just blindly copy-paste them wherever.
So, my complaint is: to actually understand what's going in the "simplest way to do BasicAuth" I need a whole lot more than just look at the code.
I need to understand why I need no less than ten (!) language extensions before I even begin to implement BasicAuth. And five of them just to workaround some Haskell limitation based on some report from 1998 (I'm guessing)? What happens when I move on to OAuth? What will I need then?
Also, "oh, you don't really need PhDs in type theory to use Servant" slowly descends to "oh, here are two things regarding types that you'll have to learn". On of them has no useable documentation except some comment on StackOverflow. The other one requires you to be well-versed in type theory.
Hence my complaint about "you need a PhD in type theory to work with Haskell".
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 average JS user knows how V8 optimizes execution of code, or whatever. That's what your insistent complaints about type theory amounts to: none of the articles I'm linking to mention inference rules or type judgments or what-have-you. That's what all the research papers about Haskell are for, which you do not need to read to use this language. Even advanced Haskellers don't do type theory (category theory, maybe, not type theory). Only a couple of people working on the compiler do.
More DataKinds:
https://stackoverflow.com/questions/20558648/what-is-the-dat...
http://ponies.io/posts/2014-07-30-typelits.html
https://www.schoolofhaskell.com/user/k_bx/playing-with-datak...
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.
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.
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.
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, never knowing what it is. Can't remember any unpleasantness that would "quickly arise".
There are other things than blind following after a Platonic ideal.
xs >>= f = concat (reverse (map f xs))
Array.prototype.chain = function (f) {
return reverse(this.reduce((acc, it) => acc.concat(f(it)), []))
}
xs >>= f = concat (map f xs)
Suppose you're going over some code, where you have something of the form
xs >>= someFunction
xs >>= return
xs
return x = [x]
[1, 2, 3] >>= return
= concat (reverse (map (\x -> [x]) [1, 2, 3]))
= concat (reverse ([[1], [2], [3]]))
= concat [[3], [2], [1]]
= [3, 2, 1]
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 execution of code
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?
> That's what your insistent complaints about type theory amounts to: none of the articles I'm linking to mention inference rules or type judgments or what-have-you.
No, they don't.
I'm looking at Servant and its examples. In order to write an extremely simple and basic piece of code, I, as a programmer:
- have to pull in no less than 10 language extensions
- five of those extensions are just workarounds some obscure Haskell rules (?)
- in order to understand just the basics of what's going on in there I need to know why when and where these extensions are used, how they work etc.
What happens the moment I step outside the bare necessities of the extremely simple BasicAuth implementation, for instance?
> More DataKinds:
This exactly what I wrote: as soon as you step outside into a real world of Haskell, oh "here's a list of increasingly obscure things you need to know. Maybe two people on StackOverflow know about them. For the rest, please proceed to your nearest university to obtain a PhD or two".
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.
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?
> 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. :)
Once again: THIS IS NOT WHAT I'M COMPLAINING ABOUT
I wonder if you have enough good faith to even see what I'm talking about.
If it's to imply that the answer is "obviously not" so as to project it to other readers then why are you trying to answer for them?
Clearly others have decided that what you suggest is either unnecessary or worth it. But it's your choice.