[HN Gopher] SVGs as Elm Code
       ___________________________________________________________________
        
       SVGs as Elm Code
        
       Author : webwielder2
       Score  : 63 points
       Date   : 2022-11-03 00:13 UTC (22 hours ago)
        
 (HTM) web link (blog.noredink.com)
 (TXT) w3m dump (blog.noredink.com)
        
       | [deleted]
        
       | protomikron wrote:
       | So, how's the state of Elm?
       | 
       | I am familiar with all the social media drama on Elm - are
       | serious things missing, or is it possible to write competitive
       | software (you may define that as you wish) and using the web
       | elements FFI, if things are missing?
        
         | sdeframond wrote:
         | Vendr uses Elm as its main front-end tech. It's valued 1B I
         | hear.
         | 
         | https://elm-radio.com/episode/elm-at-a-billion-dollar-compan...
         | 
         | PS: they are hiring Elm developers
         | https://www.vendr.com/job?gh_jid=4539989004
        
       | carapace wrote:
       | If you haven't already, do also have a look at Scott Wlaschin's
       | talk "Domain Modeling Made Functional with the F# Type System"
       | (it seems he has a whole book out on it now too)
       | https://fsharpforfunandprofit.com/ddd/ (F# and Elm are similar
       | enough that the concepts map directly.)
       | 
       | I've been challenging folks for a while now: What's the
       | _economic_ argument for using JS in a world where Elm exists?
       | 
       | In other words, if you want a front-end app, and you do not care
       | about the technology used to make it (you're not using a
       | particular stack just because you like it) then you should pretty
       | much just use Elm, eh?
       | 
       | If I'm some business owner who wants a web app that works
       | reliably and is cheap to maintain, I don't know or care about the
       | underlying tech stack, it seems like Elm is sooooooo much better
       | than all the JS frameworks and "ecosystem" in terms of the
       | metrics I care about.
       | 
       | Typical objections:
       | 
       | 1) JS devs are easier to find.
       | 
       | I would never hire a programmer who can learn and use JS but
       | refuses to learn and use Elm. That's a _technician_ not a
       | programmer.
       | 
       | It's easy to train non-programmers to use Elm. (If you can solve
       | Sudoku you can learn to program.)
       | 
       | 2) Elm doesn't integrate with some library or service.
       | 
       | That's an argument for wrapping that lib/service in an Elm
       | module, not against using Elm entirely. (E.g. in Rust you
       | sometimes must use _unsafe_ code but we do not give up the borrow
       | checker entirely.)
       | 
       | 3) Evan is mean.
       | 
       | I do not care.
       | 
       | 4) I can't control the Elm compiler development.
       | 
       | Elm is simple, write your own compiler.
       | 
       | - - - -
       | 
       | I've heard that there's work on an Elm-to-native app compiler...
       | Neat.
        
         | klysm wrote:
         | > It's easy to train non-programmers to use Elm. (If you can
         | solve Sudoku you can learn to program.)
         | 
         | Training developers is expensive. The less experience they
         | have, the more expensive it is (generally).
         | 
         | > Elm is simple, write your own compiler.
         | 
         | The economic argument against this is it isn't easy (expensive)
         | to write and maintain your own compiler.
        
         | stonemetal12 wrote:
         | If you want me to believe Elm is better where is the meta
         | analysis of dozens of research papers showing Elm produces
         | similar or better quality results for a lower cost than JS.
         | 
         | Instead all I got is "Trust me, it works", just like all the
         | other snake oil salesmen on the street.
        
         | xupybd wrote:
         | I present to you an alternative https://safe-stack.github.io/
         | 
         | You trade in some purity for practicality. Elmish on the front
         | end is really nice. You get F# on the back end. Fable remoting
         | makes RPC front end to back end really easy. The docs are
         | amazing https://zaid-ajaj.github.io/the-elmish-book/#/.
         | 
         | You get access to the .Net ecosystem so it enterprise ready.
        
         | pessimizer wrote:
         | > That's a technician not a programmer.
         | 
         | If a technician can handle a job, why would I hire a
         | programmer?
        
           | carapace wrote:
           | That's a good point. I like to point out that secretaries
           | were programming Emacs in Lisp back in the day:
           | 
           | > programming new editing commands was so convenient that
           | even the secretaries in his [Bernie Greenberg] office started
           | learning how to use it. They used a manual someone had
           | written which showed how to extend Emacs, but didn't say it
           | was a programming. So the secretaries, who believed they
           | couldn't do programming, weren't scared off. They read the
           | manual, discovered they could do useful things and they
           | learned to program.
           | 
           | https://www.gnu.org/gnu/rms-lisp.html
           | 
           | Our (programmers) whole business model is predicated on the
           | normies not realizing they don't really need us.
           | 
           | From that POV the JS ecosystems and all their churn are a
           | form of job security. I feel like it's kind of a scam, a
           | Potemkin village of complexity to hide the fact that computer
           | programming just isn't that hard, and most needful software
           | is already written.
           | 
           | (Excel is the most successful programming language and IDE in
           | the world, eh?)
        
         | skybrian wrote:
         | Elm is stagnant. There's been no release since October 2019.
         | It's a problem because there are known bugs.
         | 
         | Elm is also unstable; there's no guarantee Evan won't break
         | things in the next release.
         | 
         | It's a bad combination. A fork could in theory fix this. Has
         | anyone done it, though?
        
           | cardanome wrote:
           | > Elm is also unstable;
           | 
           | > no release since October 2019
           | 
           | Three years with literally not changes is pretty stable in
           | the fronted world.
           | 
           | The known bugs are not a huge blocker for most people.
           | 
           | Even if a new version with breaking changes would arrive
           | tomorrow you could still keep using the version of Elm that
           | worked fine for years. Really no issue.
        
           | dhucerbin wrote:
           | There is Gren, but I didn't use it.
           | 
           | https://gren-lang.org/
        
           | 1-more wrote:
           | > Elm is stagnant. There's been no release since October
           | 2019. It's a problem because there are known bugs.
           | 
           | There are. I have never encountered them in my life but yeah
           | there are. Fork it if they're really holding you back
           | 
           | > Elm is also unstable; there's no guarantee Evan won't break
           | things in the next release.
           | 
           | I'm showing my privilege as someone who started with elm with
           | 0.19 after all the big emergent patterns had emerged, but
           | here goes: the FFI workaround that was broken from 18 to 19
           | was telegraphed for years. Earliest mention about it being
           | disfavored I can find is from 2015 [1]. Conversely with
           | 0.19.1 we get "If you like what you see now, that's pretty
           | much what Elm is going to be for a while." [2] Ports and
           | Custom elements make it such a non-issue to interact with JS
           | while keeping your state in elm that it's just never held me
           | back _shrug_.
           | 
           | > It's a bad combination. A fork could in theory fix this.
           | Has anyone done it, though?
           | 
           | Gren, Derw, and eventually Roc compiled to JS/WASM could all
           | do it I guess. Remains to be seen, but it's a very exciting
           | space right now. It's a bit like The Velvet Underground: they
           | only sold 20k records, but everyone who bought a copy started
           | a band (or so the saying goes).
           | 
           | [1] https://groups.google.com/g/elm-
           | dev/c/1JW6wknkDIo/m/H9ZnS71B... [2]
           | https://github.com/elm/compiler/blob/master/roadmap.md
        
           | ollysb wrote:
           | https://www.roc-lang.org/ looks very interesting, it's from
           | Richard Feldman who's done a ton to promote Elm over the
           | years and also happens to work at NoRedInk.
        
           | aarpmcgee wrote:
           | I am particularly interested in this project that transpiles
           | to TypeScript: https://github.com/eeue56/derw
        
         | gaze wrote:
         | elm doesn't have anything like unsafe blocks or much of an FFI.
         | It has ports, which make integration with many libraries rather
         | cumbersome. The elm philosophy seems to be to rewrite
         | everything in Elm, and to disincentivize binding.
        
           | sdeframond wrote:
           | > The elm philosophy seems to be to rewrite everything in
           | Elm, and to disincentivize binding.
           | 
           | Or to use web components
           | https://elmprogramming.com/interacting-with-web-
           | components.h...
        
           | 1-more wrote:
           | once you write a custom element you'll never go back to ports
           | if you can help it. So ezpz. You can keep your state entirely
           | in Elm with no issues.
        
         | davnn wrote:
         | It really depends on the app. There is a lot of functionality
         | that is cumbersome to use with Elm, i.e. everything requiring
         | Ports. Additionally, if your app depends on some functionality
         | that is not yet available in Elm, you'll have to solve a hard
         | problem not related to your app, before actually developing
         | your app.
        
           | sdeframond wrote:
           | You can also encapsulate things into web components, then use
           | them in Elm.
           | 
           | https://elmprogramming.com/interacting-with-web-
           | components.h...
        
       | davidjfelix wrote:
       | IMHO prefix commas is fixing one mistake with another mistake.
       | Enforce trailing commas.
        
         | benjaminjackman wrote:
         | Precisely, or even find a way not to require commas.
         | 
         | I don't think we've seen a language that is explicitly designed
         | to be as ergonomic / accommodating as possible to developers.
         | 
         | Something that is the good protocol truism equivalent of "be
         | liberal in accepted input and strict produced output".
         | 
         | Granted that flies in the face of another programming language
         | design best practice of having 1 way to do a particular thing.
        
           | djedr wrote:
           | > Precisely, or even find a way not to require commas.
           | 
           | Here it is: https://news.ycombinator.com/item?id=33457176
        
         | cardanome wrote:
         | I absolutely love prefixing commas. Super readable and good for
         | diffs.
         | 
         | Sure trailing commas also solve the same problems but you need
         | language level support for them. Plus they add one additional
         | character compared to the prefix solution.
         | 
         | I wish I could use prefix comma formatting in other languages
         | but not chance to convince coworkers to use that not to mention
         | getting code formatting support.
         | 
         | Why would you think they are a "mistake"? What is your hang-up?
        
           | djedr wrote:
           | The only solution to this war is no commas!
           | 
           | To roughly translate the first example in the article (I
           | shortened the value of `d`):                 svg [
           | x=[0px]         y=[0px]         viewBox=[0 0 21 21]
           | path [           fill=[#FFF]           stroke=[#146AFF]
           | strokeWidth=[2]           d=[M11.1,1.4l2.4,...]         ]
           | ]
           | 
           | You can remove all whitespace and it's still unambiguous.
           | 
           | It's a perfectly viable lightweight syntax for SVG.
           | 
           | See also https://news.ycombinator.com/item?id=32995047
        
           | davidjfelix wrote:
           | They're a mistake because correcting the language level issue
           | with trailing commas to fix diffs was the correct solution.
           | Instead everyone had to convince themselves that they prefer
           | leading commas, which is not how commas are used, over
           | whitespace. Have you ever considered maybe your coworkers are
           | right?
        
         | 1-more wrote:
         | Once I used a really REALLY good formatter like prettier for JS
         | or elm-format for elm I got it. I realized that I don't care
         | about the format, I care to see the jump from unformatted to
         | formatted that means what I wrote is valid syntax. The leading
         | commas (a convention but not actually necessary for elm) make
         | diffs easy and make lists a bit easier to read. The syntax is
         | almost the same in Haskell, but Ormolu puts the commas at the
         | end and somehow it's harder to pick apart complicated list
         | entries. Can't really explain why.
        
         | klysm wrote:
         | Do you have a good reason for enforcing trailing commas vs
         | leading?
        
           | davidjfelix wrote:
           | I did prefix my opinion with "IMHO". But no. Leading commas
           | are, in my opinion, less common in life and a distracting,
           | surprising style for the sake of fixing a syntactic language
           | mistake. "Enforce" might have been an overly demanding word.
           | Enforcing when there's a newline is probably more apt or
           | simply allowing it to prevent giving leading comma folks
           | ammunition.
           | 
           | something like `[hello, world]` should probably be allowed
           | since `[hello, world,]` feels extraneous.
        
           | masklinn wrote:
           | Leading is necessary to minimize diffs when you don't support
           | trailing commas:                   Prelude> [1,]
           | <interactive>:4:4: error: parse error on input ']'
           | Prelude> [1]         [1]
           | 
           | This means if you go multiline in the "usual" style:
           | [             1,             2,             3         ]
           | 
           | any time you need to append a new item, you need to modify
           | the existing last line as well:                    [
           | 1,              2,         -    3         +    3,         +
           | 4          ]
           | 
           | Meanwhile:                    [ 1          , 2          , 3
           | +, 4          ]
           | 
           | If you support trailing commas, you can just use one on the
           | last line for the same effect:                    [
           | 1,              2,              3,         +    4,          ]
           | 
           | Incidentally, some crazy people put the closing symbol on the
           | last line:                   [ 1         , 2         , 3 ]
           | 
           | That completely defeats the point:                    [ 1
           | , 2         -, 3 ]         +, 3         +, 4 ]
        
             | asplake wrote:
             | Do many/most feel this way? I always felt this argument was
             | the diff tail wagging the code readability dog, so to speak
        
               | jgalt212 wrote:
               | It does feel like a misplaced priority.
        
               | xupybd wrote:
               | It's very important to me. I don't feel readability is
               | impacted by having commas before or after. As long as
               | it's consistent.
        
       ___________________________________________________________________
       (page generated 2022-11-03 23:01 UTC)