1. 5

    Last couple of weeks I’ve been working on improving some of the Elm tooling that exists. In particular, I’ve added these things:

    • elm-bash-completion which gives you auto-complete for Elm tools in your bash/zsh terminals
    • elm-help which is a tool to give you information about a particular package or your local application from the command line
    • elm-documentation-parser, which is a “mostly works” library for getting documentation from Elm files that matches the docs produced by the --docs flag in the elm-make binary
    1. 7

      For fun(!) I wanted to make a client for MPD with Elm and display:grid. It now works more-or-less and was easy enough to do, but I’m not really happy with the default websocket library from Elm. Maybe there is one with a more explicit connection state? For this week to finish it I want to make the design presentable.

      1. 4

        What in particular are you looking for in controlling the connection state? The idea behind the websocket library is mostly built around the idea that you shouldn’t need to worry about handling the connecting or how messages are sent. You can use the low level functions to put together an explicit model of the state if that’s what you need

        1. 2

          I would like to know the state of the connection, so I can display that. Or not show certain parts of the GUI when there is no connection. The current magic reconnects by the high-level module can take quite a while, with the build in exponential backoff (and reloading does not force the establishing of a new connection, somehow).

          The low level functions are really rather low level :) Guess I’ll have to dig in them anyway…

          1. 2

            Indeed, for those types of situations you are best off using the low level stuff directly. If you need a hand, join the Elm Slack – there’s lots of people who can help!

      1. 2

        I’m improving elm-debug-decoders, a tool designed to help you visually iterate on your decoders.

        1. 5

          “a mere 450k” - that’s still a ton of JavaScript to load! I’m a JavaScript-first developer for the most part, but I just don’t understand how people have totally given up on making things small and efficient. Elm is probably great on its own, but I’m not buying it as a replacement at this point. 22k -> 55k LOC is ridiculous.

          1. 14

            That’s prior to minification. Luckily for you, the focus of 0.19 is on improving the SPA story: reducing data loaded from the server, DCE, etc.

            1. 2

              Good to know!

          1. 3

            We’re improving swagger-elm for work. Adding generation of http tasks so that you don’t have to write any of the network code on the client any more!

            1. 3

              While reading these announcements and considering most of the developments to be rather smart, some of the updates (not necessarily in this one, earlier ones had more “short cuts”) I wonder whether some features geared towards making things easier come at a high price for readability and getting into the language.

              Is there experience on this? Do people consider it a lot harder or read and understand Rust code compared to Go or Python (when they know them and have worked with them of course)?

              I understand that expressiveness of course comes with some price, but I am wondering on how well reading Rust code from other people works, when it remains somewhat idiomatic.

              1. 6

                I write Go and Rust pretty much daily and I don’t really experience any amount of trouble reading code in either one. But I’ve been using both languages for many years now.

                1. 8

                  I wonder whether some features geared towards making things easier come at a high price for readability and getting into the language.

                  It depends on the feature, really. For example, I wrote this code recently:

                  match item {
                      &Item::Module { ref name, ref docs } => {
                  

                  once https://github.com/rust-lang/rust/issues/42640 is implemented, this code will instead be

                  match item {
                      Item::Module { name, docs } => {
                  

                  much, much easier to read. This is what I actually wrote, but the compiler yelled at me, so I had to add in the &s and refs to make it work. This is geared at usability, but definitely makes reading and getting into it easier.

                  ? is another recent one that I think you’re thinking of, maybe; I was skeptical at first but it’s really grown on me. I find it easier to read than the old try!.

                  As always, YMMV.

                  1. 3

                    Coming from the language design of Elm, which takes readability and ease of understanding as a priority, I found the types in Rust in particular to be very counter-productive. For example, imagine you want to split a string. Simple, right? It should just be something like split : String -> String -> List String. Not so in Rust. In Rust, you have to first figure out this type which looks this: <'a, P>(&'a self, pat: P) -> Split<'a, P>. Figuring out what ', & and <> are quite a big wall to run into early on. For this reason, I would not personally recommend Rust unless you specifically have an interest in it or need a language like it for work. I would definitely argue that

                    Context: I have done a pretty large amount of Haskell and have written a decent of Idris. Types are not a scary thing to me, but when I run into types which are harder to read than they should be, it really frustrates me. That being said, Rust does do some really cool things, and complicated syntax can help complicated features exist. Different languages have different purposes :)

                    1. 14

                      I appreciate what elm does, but the Elm type signature and the Rust type signature express different things.

                      Elm describes: “given a String and a String to split, return a List of new Strings”.

                      We could easily have fn split(&self, pattern: &str) -> Vec<String>. But that would mean that you immediately heap allocate a number of strings. (That’s directly readable from the signature)

                      Rusts split signature describes something very different: “Given a String and a pattern, return slices into the original string. These slices cannot be used after the original String is removed from memory.”

                      Generics aren’t the weirdest thing in the world, so are references. I’m a bit surprised that languages that have a notion of them are now seen as weird.

                      Finally, you make it seem like Strings are the easiest in the world and their APIs all have to be dead simple. The opposite is true: Strings are the nastiest data type. Their APIs might reflect that.

                      I give you that the split signature isn’t the easiest to read at first, that’s why it comes with a lot of examples, which use very easily. It reads very clearly once you know the lingo.

                      1. 5

                        I appreciate and understand the difference, and I also understand the goal. But please remember that I am answering a question from a perspective “How easy was Rust to learn?”, and not “Is Rust a useful language?”. In a world where you have to care about memory, this kind of representation is important. But that does not make is an easy to learn language.

                        I appreciate what elm does, but the Elm type signature and the Rust type signature express different things.

                        The point of the split comparison isn’t quite “this is what Elm does, this is what Rust does” – I was rather saying “This is what I would expect, but instead the type signature looks like that”. In particular, there’s several layers of complexity:

                        • The new Split type
                        • & syntax
                        • 'a syntax
                        • <'a, P> syntax

                        This is why the split type signature is confusing and offputting to newcomers. It does not work nor look as newcomers expect it to.

                        We could easily have fn split(&self, pattern: &str) -> Vec. But that would mean that you immediately heap allocate a number of strings. (That’s directly readable from the signature)

                        It is entirely feasible to have a lazy data structure in the form of an iterator. It does not need to be a custom Split type. It would be easier to understand with that small change – introducing new types instead of using familiar names can have a counter-productive effect on aiding learners.

                        I give you that the split signature isn’t the easiest to read at first, that’s why it comes with a lot of examples, which use very easily.

                        To you, as a user of Rust, it is very easy. To others coming to your language, it is not. The first place I look at when figuring out a function is the types if it has it. The examples come only to clarify the knowledge I gained from the type. split in Rust does not give me sufficient knowledge from the type signature to feel comfortable reading the rest of the document. Of course, given enough examples, I could understand how to use it, but for me, having clear type signatures is more important than having lots of examples. This is why I say that I could not recommend Rust as a language that is easy to pick up, unless you need it at work. Obviously, polyglots and people with an interest in language design will try it out anyway. And they should! It does some very different and interesting things. Please don’t take this as me saying “Rust is bad, don’t use it” :)

                        1. 10

                          Yet, you don’t address my most important point: the comparison doesn’t fit, we have opted for a vastly more powerful implementation at the cost of a harder type signature.

                          The whole rest of the String docs mostly has very with plain signatures.

                          I find your insistence that having all syntactic options of Rust in one signature still a little weird, you will always find functions like that in any language. There’s certainly a problem for people that absolutely want to grok the signature before use, but then, well - that’s the moment where those people must go out and learn them. There’s not much you can do. It’s not even like these are fringe concepts of the language, you will be able to reuse them for years to come :).

                          (By the way, due to the issue of rust not having anonymous return types, it is indeed not possible to avoid the custom Split type)

                          I do know the problems of newcomers quite well, I make part of my income with training Rust and founded the largest training group. split is only shortly among them.

                          I didn’t find your post dismissive, just picking a local maximum and hitting very hard on it also isn’t very useful criticism. Also, your conclusion doesn’t seem quite right: almost every user of Rust currently is a hobbyist, and many find it very interesting that they can finally encode those things in their signatures.

                          1. 2

                            Yet, you don’t address my most important point: the comparison doesn’t fit, we have opted for a vastly more powerful implementation at the cost of a harder type signature.

                            I address this with this:

                            The point of the split comparison isn’t quite “this is what Elm does, this is what Rust does” – I was rather saying “This is what I would expect, but instead the type signature looks like that”.

                            Please re-read my comment carefully. You are coming across fairly hostile, and I don’t want a flame war – like I’ve said, I am not saying that Rust is a bad language.

                            I find your insistence that having all syntactic options of Rust in one signature still a little weird, you will always find functions like that in any language

                            I’d love if you could point out any of such complexity in a language other than Rust, Haskell, Idris or Purescript. For example, if “any” is to be taken to be true, could you find one in Elm or Mypy or Typescript or even Java? There is a restricted set of symbols that you need to learn for each of those, and they tend to come it later, after you have written your first production code.

                            There’s certainly a problem for people that absolutely want to grok the signature before use, but then, well - that’s the moment where those people must go out and learn them

                            Here’s the funny thing about using symbols in type signatures: they are literally ungooglable. It’s hard to learn what 'a means, because you cannot Google it easily.

                            By the way, due to the issue of rust not having anonymous return types, it is indeed not possible to avoid the custom Split type

                            This is another area where Rust trades power for readability and accessibility. Languages can and should be improved constantly.

                            I do know the problems of newcomers quite well, I make part of my income with training Rust and founded the largest training group. split is only shortly among them.

                            If that is true, then I am very surprised that you yourself say in another comment.

                            I’m a little confused by this, as the docs come with a ton of examples and usage is really easy. Yet people get hung up on the type signature, which is admittedly “all in” at first, but easy to read once you are a little in.

                            If your job is literally training people to understand Rust, then I assume you also take time to learn why they see things that way. I am telling you that examples alone are not enough for me: perhaps some documentation that explains why split is the way it is is needed. Just showing what it does is not enough.

                            I didn’t find your post dismissive, just picking a local maximum and hitting very hard on it also isn’t very useful criticism

                            It’s interesting, as I do find your post dismissive and hostile. I’m simply giving my opinion on the language design of Rust from the perspective of how easy it is to learn. That was the original question. I’m answering it from the perspective of someone who works with a language that is easy to learn.

                            Edit: I originally phrased part in a negative manner, due to bad English skills. Rephrased to be less negative

                            1. 4

                              Your original comment said this:

                              but when I run into types which are harder to read than they should be

                              And you (seemed to) back this up by a false equivalence.

                              This is very different than saying, “these are things that are hard for a newcomer to learn,” which would be entirely reasonable. I think you shifted more towards this position in your follow up comments, but it was not at all clear from your first comment. Your first comment makes it seem like Rust introduces needless complexity into its type signature, instead of acknowledging the tradeoffs that skade pointed out.

                              In general, I do agree with you that the type signature is hard to read. I personally think it’s hard to read more because of the conceptual burden rather than specific pieces of syntax though, which makes it a much easier pill to swallow. The conceptual burden is there for a very good reason. Nevertheless, I do take this into account when designing library APIs. Failing that, I rely on writing clear documentation with examples to counteract the complexity in the type signature.

                              1. 4

                                That’s fair enough, I guess what I meant was that is harder to read than I, as the learned, expected it to be, rather than it being harder than it needs to be. I did not meant the complication is fully unwarranted – some of it is, and Rust represents some things in types few other languages do.

                                1. 4

                                  Agreed. A big part of teaching Rust is managing expectations.

                      2. 2

                        As a beginner thinking “split” would be an easy, I tried reading the docs (i.e., parsing the type) and gave up. For things like these I bruteforced my way through the compiler errors or asked in #rust-beginners on irc.mozilla.org.

                        1. 6

                          I’m a little confused by this, as the docs come with a ton of examples and usage is really easy.

                          https://doc.rust-lang.org/std/string/struct.String.html#examples-52

                          Yet people get hung up on the type signature, which is admittedly “all in” at first, but easy to read once you are a little in.

                    1. 2

                      Is there some more info on who this is for? I filled it in, but would love to know a bit more about what it’s for. P.S: a real great way to make sure lots of people don’t give up half way through is to show a progress bar. I almost gave up on the 4th page before realizing it was the last.

                      1. 4

                        I released the initial public version of elm-sketch-importer, a tool for exporting your Sketch files into Elm. It’s a work in progress, but I’m pretty happy with how it’s shaping up. I will be converting it to use my elm-html-in-elm AST for Html, which will allow it to be generate straight HTML for free. Check it out if you’re using Elm and Sketch, or even just Sketch :)

                        I’ve recently changed jobs to work at a company called Schibsted. I’ve been getting familiar with Ramda and compile-to-JS languages which aren’t Elm. Out of Flow, TypeScript and ReasonML/BuckleScript, I am most fond of Typescript. They’ve really put a lot of love into it, and the tooling is amazing. ReasonML is very immature, and the error messages are sub-par. I found them harder to use than GHC’s errors. Flow required a lot of set up, and I felt tired by the time I had actually got into writing code.

                        1. 10

                          Server-side rendering — sending HTML with the initial response

                          Tree shaking — trimming out unused code (usually called dead code elimination or DCE)

                          Code splitting — cutting up code into smaller chunks for better caching

                          Lazy loading — only sending the code chunks needed for a particular page

                          Okay, Elm has gotten my interest again. Looking forward to these being available :-)

                          1. 3

                            Server side rendering has existed in Elm for at least a year, FWIW.

                            1. 1

                              I quoted the whole block, which was my bad. I most meant the last three.

                          1. 1

                            Hmm, why is this tagged unix? I assumed that OPy referred to ops-related things. This is a post about an alternative Python compiler.

                            1. 5

                              Because the “Oil Shell” is a new unix shell being built. Read the homepage.

                            1. 4

                              I’m doing an Elm Q&A tonight with fellow Elm contributor Luke Westby. The rest of the week, not too much planned.

                              1. 1

                                It bothers me that Elm’s type system allows any of these to compile. I’ve never seen a language that strictly guarantees a lack of undefined behavior - even Haskell has runtime errors, and the ability to throw a runtime exception. I’d like to see someone write a language where it really is the case that all compiled programs are guaranteed not to crash, and any other behavior is a specification or implementation bug.

                                1. 7

                                  First off, please don’t conflate runtime errors and undefined behavior. Errors in Haskell and most other languages are pretty well-defined in what they do.

                                  Wanting “guaranteed crash-free programs” is understandable, but the issue is they’re super tedious to write, and inevitably any program of size just has some variety of Result/Either threaded through that behaves like exceptions except with no stack trace. The other thing with the zero-exceptions ideal is it forces you to be defensive about things that need no defense. Example: regexes, like the article mentions. I shouldn’t have to write a runtime check to verify the compile-time condition of a correct regex. Same for indexing an array of known length: if I have code like let arr = [1, 2, 3] Just first = arr !! 0 in first the compiler should not force me to provide an exhaustive match on arr !! 0.

                                  Also note that even in Elm’s limited case, errorlessness forces them into some really questionable design decisions. For example, what’s n / 0? Well, for floats it’s infinity (fine) but for ints it’s 0 (super not fine!) Of course they did this because it would be incredibly tedious to have to unpack a Maybe for each integer division. I would rather have my program crash than be subtly broken by this silliness.

                                  1. 0

                                    In actuality, how often have you used n / 0 to actually crash the program and appreciated it? You can consider division by 0 to be a logic error - and therefore, it’s something that should be caught by tests, not by the compiler.

                                    1. 1

                                      Would be great if someone replied instead of just downvoting. One thing I like lobsters is that people don’t downvote just because they disagree, and instead comment to further the understand of the community.

                                  2. 1

                                    That is the case with Elm. All the the things I’m talking about here are implementation bugs, except for the single case of Debug.crash. It’s actually nice to be able to rely on your frontend code. With Elm, if my code compiles, it works. I don’t have to worry about it crashing at runtime – and that’s not something to turn your nose at.

                                  1. 8

                                    Neat. It’s nice to have some features like pattern matching in C-likes. It’s also very awesome to have a language spec for a language like this. For same reason, C– has ended up being used a lot in schools for teaching compilers. It would be great to include ML-like features in compiler courses for C-style languages, like pattern matching and unions.

                                    Sidenote:

                                    Mae Myrddin yn yr enw Cymraeg am Merlin. Ti'n dweud e fel “Muh-rh-th-in” mewn Saesneg! Mae dd yn swndo mor fel “th” galed mewn Cymraeg. Nagw e'n swndo fel d.

                                    Myrddin’s the Welsh name for a Merlin character. You pronounce it as “Muh-rh-th-in”. The double d is actually a letter, which sounds more like a hard th in English. It doesn’t sound anything like d.

                                    1. 3

                                      Cool, I’ve been looking for implementations of pattern matching compilers.

                                      https://github.com/oridb/mc/blob/master/mi/match.c

                                      If that’s it, it doesn’t look too long at 839 lines. As far as I understand, compiling to decision trees results in the fastest but largest code, and backtracking automata is the opposite tradeoff.

                                      https://hal.inria.fr/inria-00000763 (page 2)

                                      People say the decision tree requires exponential space in the number of patterns but I don’t quite get that?

                                      Also checking for pattern matching exhaustiveness is apparently NP-complete?

                                      http://trevorjim.com/finally--pattern-matching/

                                      1. 4

                                        Yes, that’s it. Note that it doesn’t try to be especially clever about optimizing things. Still, I’ve found that in practice, either the matches are often shallow, with the wildcards (captures) clustered near the end. So far, it hasn’t mattered too much, although I also haven’t put so much work into generating fast code.

                                        1. 3

                                          People say the decision tree requires exponential space in the number of patterns but I don’t quite get that?

                                          If there are N things to test, a decision tree might need height up to N to make decisions. A complete height-N binary tree has 2^N nodes. In practice not every decision path will be full-height, but depending on how you construct the tree, in the worst case you can still end up with size roughly on that order. One bit of intuition for why is that you can have exponentially many duplicate tests: somewhere down the tree, it might turn out that 6 of the 8 branches need to make exactly the same test, so this test is duplicated 6 times. Ways to avoid this include heuristics to ensure the tests needed by more paths end up further up the tree and therefore not duplicated, and explicit sharing between branches, i.e. a decision DAG rather than a proper decision tree.

                                          1. 1

                                            OK yeah, so then the way I think about it is that the branching factor of the tree is related to the number of patterns/cases… but the height of the tree is related to the number of variables tested (the depth of the patterns).

                                            The height is the thing that is exponential, so it’s the number of variables tested. You might need to test a single variable against like 20 things, but that doesn’t make it exponential.

                                            I guess it just doesn’t seem like a big deal in practice to be exponential this way. Am I wrong? Are there some examples from real code where just doing the naive thing results in a lot of bloat? I feel the patterns are commonly at most 3 or 4 levels deep, but I don’t have tons of experience with ML.

                                            I guess this could answered with some program analysis…

                                        2. 3

                                          Re. Your note about the pronunciation. Bengali has 5 (I think) d-like sounds. I wonder if your “dd” is then like the bengali dh “ধ”. This is pronounced like this

                                          1. 3

                                            Hmm, not quite. The dd doesn’t sound very much like d at all. At least not to my Welsh ears. Here’s a north Wales pronunciation -> https://youtu.be/nnH33183y2M?t=17

                                            1. 2

                                              Wikipedia’s Welsh phonology page groups it as a voiced dental fricative, like Greek δ. Your sample doesn’t sound identical to how I would pronounce Greek δ, but much closer than an English ’d' in either case.

                                              1. 3

                                                Yep, agreed, that is closer. When I make that noise, I push my tongue up behind my teeth, leaving a gap between the roof of my mouth and my tongue, and then sharply exhale, allowing my tongue to vibrate. I don’t know that helps much, but hopefully it does! It’s also important to note that the noise of a word in Welsh puts a lot of pressure on the first syllable - as dd is at the end in Myrddin, then it has a much softer sound than if you pronounce the letter alone.

                                                1. 1

                                                  That does actually sort of help explain why it sounds a little different, I think. I pronounce Greek δ as you describe, except with the tongue pressing against the gap between slightly parted upper and lower teeth. Whereas it sounds like your tongue is against the upper teeth, not against a gap between upper and lower? The linked Wikipedia article on voiced dental fricative briefly mentions an “interdental” variant (which is what I use). When I attempt both varieties, the interdental version sounds “harder” to me, i.e. if there’s a spectrum from the softer th in “think” to the harder th in “that”, both are on the harder end of the spectrum, but interdental is further there. Maybe?

                                                  Getting even more off-topic in this off-topic thread, but the first time I heard Welsh on a train, I thought it was Swedish. I’m not 100% sure why, because there is no actual linguistic relationship. The closest I can figure out by listening to some stuff on YouTube is that there’s a certain upwards intonation at the end of words like “bydd” that is very similar to an upwards intonation in the Swedish tonal system on words that end in “-iet” (example here). There is something else about the phonology and/or intonation that really minds me of Swedish though (specifically Swedish, not Danish… I lived in Denmark for years and Welsh sounds nothing like that).

                                        1. 10

                                          Blog posts! I’ve actually written 4 blog posts in the last few days. I’ve also taken some of my old, unpublished blog posts and written them in my new style. My latest is on how I implemeneted json-to-elm, if anyone is interested. I’m trying to blog about things that I end up answering on slack, or giving talks about a lot. So that includes problems with Elm, things people find hard to do with Elm, experimental projects, etc. My next blog posts will probably be about server-side Elm, or build tools. It depends if I get more motivation, but I have a blog post written for both right now.

                                          I’m also working some more on elm-fuse, but no big progress updates other than the rewrite I got done last week!

                                          1. 2

                                            Awesome! Can’t wait to read about server-side Elm and build tools.

                                          1. 1

                                            I wonder if they are going to try to do some kind of ML module thing.

                                            1. 2

                                              I personally find ML-style modules to be a stricter, but stronger abstraction for libraries than typeclasses.

                                              Also, I don’t quite understand the final point in the post: needing to look up viewSomething to understand viewCity etc. Isn’t the whole point of writing modular code that you don’t have to really care about what the implementation details are? If you need to understand the implementation entirely (as you might for a rendering function), having typeclasses vs modules vs some other abstraction mechanism becomes mostly irrelevant.

                                              1. 1

                                                Yeah, maybe I didn’t explain that last bit so well. I think my point was that you can already write things in a type-class style (by ensuring each record has a contract of record -> Html msg), but that that style does not give you much extra in terms of readability nor in boilerplate. Boilerplate is the problem that most people are facing with Elm right now - and the introducing of typeclasses may be either harmful or overkill for that problem

                                              2. 2

                                                It’s been discussed, and actually effect-modules have a syntax inspired by OCaml’s parameterised modules.

                                              1. 7

                                                For what it’s worth, the lack of Typeclasses is why I gave up on Elm. For an otherwise fairly usable language, it was just too inconvenient.

                                                Purescript is very promising. Unfortunately, I think the learning curve may be too high for many people. Elm has a simple and straightforward UI system that you’re basically required to use, whereas purescript gives you some options, and the one I found first (Halogen) uses concepts that are well beyond the experience of your average programmer. Elm’s nested tree system is relatively very approachable.

                                                1. 5

                                                  Do you have some example code of where you found it too difficult to go without typeclasses? In the majority of cases I come across, it is usually solvable in a different style than the person is used to. A lot of people come from languages like Haskell, and expect Elm to have all the features Haskell does – and therefore end up trying to solve problems in a Haskell manner, which can be very frustrating once you realize that Elm doesn’t have typeclasses. I’d be very interested in seeing what you came up against :)

                                                  1. 3

                                                    it is usually solvable in a different style than the person is used to.

                                                    All of these languages are Turing Complete. It’s always doable, but not always convenient.

                                                    The most prominent example I remember is wanting sets and maps with keys of arbitrary types.

                                                    1. 5

                                                      I actually discuss that exact problem in the blog post, including linking to the solution, a package called elm-all-dict which I wrote a long, long time ago and still maintain.

                                                      It’s pretty convenient - just use EveryDict anywhere where you might’ve put a normal Dict. There’s a small hit to performance, but nothing you would notice unless you’re processing info from Hubble or something.

                                                      1. 1

                                                        So you’re basically emulating typeclasses by explicitly passing the relevant functions. Like I said, that works, but completely eliminates any of the convenience or safety afforded by unique global typeclasses. It also doesn’t really generalize well to things more complicated than, say, Ord or Hashable. Soon you have to start passing around giant objects full of lots of functions, and now you’re just doing typeclasses by hand.

                                                        1. 3

                                                          Actually, EveryDict doesn’t require you to pass in relevant functions. AllDict does, but EveryDict hashes things for you. So no, not quite.

                                                          But also: the point is that typeclasses, for most things, are a nice-to-have. If you write your code in a different manner, then it’s not a need-to-have. Very few people have these problems in production - I’m among the people who have written the most Elm and have rarely thought “oh typeclasses would help me write this view in a better way”. Other things are more important to increasing Elm adoption and ease of use over typeclasses.

                                                          So I’m not trying to say that typeclasses don’t have a place - they definitely do, and they should be added in. But they need a lot of thinking about first, and there are other things to address first. Hence why the yet

                                                1. 3

                                                  I I quite like the approach of ppx_deriving_yojson, where you specify a type and add annotations how JSON should be deserialized from and also generates serializers to do the reverse. All this in a type-safe way which avoids the problem with the misordered fields in the record.

                                                  I could imagine something like this could be useful in Elm, considering that JSON in Elm is far more important than it is in OCaml, where this is implemented using two libraries and some macro.

                                                  1. 2

                                                    Yeah, this is very similar to the golang alternative. Just tag the fields in a struct as json and specify an incoming json name, and you’re good to go. In my experience, it doesn’t handle up so well when you need to decode a complex type (for example, recursive data structures that have optional fields), but it’s a lot better than what Elm has now.

                                                    The alternative I suggested isn’t really a good alternative - it’s one that solves one particular problem of the JSON API which new users rarely think about. My point of this blog post was to hopefully kick start this conversation and get people suggesting and providing alternatives, because I have pushed for automatic decoders/encoders long enough alone :)

                                                  1. 4

                                                    I worked on elm-fuse and got some core features working, like if..else branches. I’ve had to implement them slightly differently to standard Elm, but it actually ends up following the same patterns as production Elm. I’m pretty happy with were it is - I need to do some big refactors still in order to handle events in a better way, but it’s looking good. My next plan is an alpha release so people can play with it.

                                                    I improved elm-xml quite a bit by adding converters to and from JSON, which I needed for elm-fuse.

                                                    elm-ffi has been getting some attention and usage, so I’ve been thinking about making it work as a post-compile step. Should be pretty easy to do.

                                                    I’m also going through and reviewing a few community packages by request. Mostly just giving feedback on API design, bugs, etc.

                                                    1. 4

                                                      For anyone else simultaneously confused and excited, it’s Fuse the iOS/Android app framework, not fuse the userspace filesystem interface.

                                                      1. 1

                                                        Would it be more exciting if it was? I can make that happen too, I’m sure

                                                        1. 1

                                                          Honestly, I’m already excited about Fuse-the-app-framework!

                                                          This is the first time I’ve heard of this Fuse, though. How does it compare to React-Native?

                                                          1. 3

                                                            Disclaimer: I currently work at Fuse.

                                                            There’s actually a blog post about it here, though it’s slightly out of date. It discusses a lot about the design philosophy behind Fuse.

                                                            Without going into too much detail though, Fuse works by having a markup language which is designed to be declarative. React Native is designed so that you can write React but compile it to native components, which means that you can end up with some rather scary code. One of the problems that elm-native-ui[1] had was dealing with generating all this React Native code. Fuse, on the other hand, is really really easy to target from Elm. The model of using a UX markup language that is statically designed works really well with Elm, since it’s also declarative. Fuse has built in observables, which are trivial to map Elm’s ports to. I’ll have a full blog post on this at some point

                                                    1. 10

                                                      I phone interviewed for TSE at Google a couple of weeks ago.

                                                      • They setup TSE interviews with Hangouts. It doesn’t work, because the invitation they sent is unique to an email address an account for which doesn’t exist. At the time they were setting it up, the “requirements” webpage itself didn’t work, either; but my system doesn’t meet their requirements either way. I informed the recruiter; she informed me that Hangouts is mandatory for TSE; we both ignored our communication on the matter.

                                                      • They sent you a Google Drive link for a Google Doc. It, likewise, doesn’t work for the same reasons of a missing account. (Most departments make a scratch-pad link accessible regardless of an auth account to avoid this exact sort of bullshit, but not Google’s TSE!) Interviewer tries changing permissions to make it open for everyone; apparently, that only works if you have the Google Doc link, not if the link is from Google Drive — you still get no access if the link you see is a Google Drive one, whereas the interviewer has a Google Doc link. E.g., we had to reshare the link on the proper service during the interview. (Permissions couldn’t be changed because the recruiter setting it up went on a holiday; and, apparently, the other recruiters don’t have the permissions to fix the permission.)

                                                      • Writing code in Google Docs, where none of the keyboard buttons work properly (couldn’t go to the start of the line etc), and all code gets capitalised as if it’s an English sentence… Is horribly unsatisfying.

                                                      I’m expecting a rejection phone call tomorrow, probably because I am a “jerk” as I didn’t feel like playing their politics and registering my preferred email address as a new Google Account, nor going out of my way to have Hangouts ready on my own dime, especially considering that one of my prior jobs included building an XMPP server, and the proprietary Hangouts killing XMPP isn’t something I’m too happy about.

                                                      Sure, it’s TSE, but the whole process felt like they were more interested in selling me their half-baked products with a NIH attitude than hiring me to provide technical solutions for their customers (and, yes, on a completely separate set of products, I gather).

                                                      1. 3

                                                        TSE

                                                        What is a TSE here? I tried googling but found nothing related

                                                        1. 2

                                                          I think it’s Technical Solutions Engineer or Test Support Engineer.

                                                      1. 28

                                                        I’m not sure why this is share-worthy. What is the content here that people are upvoting? Not trying to be snarky - genuinely interested if there was something I missed.

                                                        1. 20

                                                          I’m not sure why this is share-worthy.

                                                          Not sure why it isn’t. It’s an interview about a [good] dev and an open-source maintainer, and the post fits perfectly under the person tag :)

                                                          1. 17

                                                            The title needs to be fixed to be more useful (is the link her personal site, a biography, some post about her?).

                                                            1. 9

                                                              She has been one of the more consistently public, helpful, and relatable faces of Docker for years. Good presentations and demos.

                                                              1. 22

                                                                It’s not really that much about her, though, unfortunately.

                                                                It reads like “docker kubermetes docker, a couple observations about open source, generic advice, plug for help for docker or kubermetes”. She seems like a perfectly nice person, but she doesn’t seem that much more noteworthy than any of a thousand other open-source developers paid to work on infrastructure projects. The interview doesn’t really cover anything personal about her, it doesn’t have her saying anything we haven’t heard a thousand times before or at least going in-depth on a story to explain her advice. The systemd->butts transform was amusing, to be sure, but otherwise why?

                                                                I hate to be this, well, mean, but shouldn’t we be using the person tag for people of, well, note?

                                                                ~

                                                                And yes, this is kind of a core problem with the person tag. This person isn’t that interesting–given the information in the submission–to me, for example, but I could probably pick some alternate submissions that might be equally uninteresting (a person I know who is a greybeard at GOOG and has some cool projects.

                                                                But where to draw the line without being petty? What makes articles under people good articles (instead of PR puff pieces)? Therein lies the rub.

                                                                1. 10

                                                                  I get that anger is in your username and stuff but if you describe your own post as mean it’s probably not constructive.

                                                                  1. 5

                                                                    She is without question “of note” in the open source community. Especially in the infrastructure / “devops” space.

                                                                    If you don’t know her, maybe that’s not your thing?

                                                                    1. 9

                                                                      I think the problem here is that the interview doesn’t really say enough to convince someone that she’s worth interviewing. If you know her, you get it. If you don’t, then… we’ll, this isn’t helping, unfortunately.

                                                                      1. 3

                                                                        You’re right. Unfortunately, I don’t know that anyone who’s already “soaking in it” will take the time to write the “Hey, all you folks not in Devops, this is why Jesse is awesome!”.

                                                                        Maybe a little bit of open mindedness on people’s parts would help?

                                                                        1. 2

                                                                          Maybe a little bit of open mindedness on people’s parts would help?

                                                                          Yes! This is the key. We should probably trust our community a bit more than suggest an post with a decent number of points is irrelevant.

                                                                      2. 2

                                                                        Clearly not “without question”, right? Perhaps in the Docker/Kubermetes realm, but the article itself really doesn’t give much information about her, why she’s a big deal, or what she’s done. And that sucks, because people here are pointing out waaaay more interesting accomplishments she’s had.

                                                                        But again, the problem with the person tag is that you and I can both draft up a list of at least a half-dozen devs that are “of note” and yet the other one of us will go “huh?”. And in a few decades time, probably none of the people on those lists will be remembered.

                                                                        1. 2

                                                                          IMO it comes down to what people want this community to be about.

                                                                          I can totally see the angle where “person” violates the spirit of the place - what makes Lobsters great is all hardcore tech - all the time.

                                                                          I can also see the idea that showcasing awesome community contributors could be a good thing.

                                                                    2. 5

                                                                      The person tag is for stories about people, not profiles. A link to one of her talks, an in-depth or technical interview, or any one of a number of her blog posts would not have been flagged as off-topic.

                                                                      edit: I’ll also point out that in general the person tag is used alongside another tag. Cases of “person” alone are generally of some historical significance, an interview, or a death announcement; all of which are more substantive and/or better discussion topics than a simple profile.

                                                                    3. 5

                                                                      I’m with you. The title alone means nothing to me. I thought it was going to be some sort of memorial when I first saw it. But there isn’t really much of any content there. There’s nothing technical in it. I don’t understand what we’re meant to get from it.

                                                                      It fits HN more because that site is full of fluff like this, but I wouldn’t expect it here.

                                                                      1. 14

                                                                        I completely agree, this is not the kind of content I want to see here.

                                                                        1. 2

                                                                          FWIW this was only posted in here because it’s in the front page of HN. @av consistently posts whatever is popular there here (most of the time it makes sense, though).

                                                                          1. 4

                                                                            I like this content, but I don’t think that something reaching the front page of HN is a good litmus test for if it should be cross-posted here

                                                                        2. 4

                                                                          Lots of people don’t know where to start, and stories like this can be helpful. Lobste.rs has previously made similar pages for some of our users.

                                                                          1. 1

                                                                            Well, the community has voted for it so I guess you’ll just have to avoid clicking the link and move on then.

                                                                            1. 3

                                                                              By the same argument tabloids are the best because there’s lots of demand for them!