13 ms·

SVGs as Elm Code

77 points by webwielder2 4y ago

davidjfelix 4y ago
IMHO prefix commas is fixing one mistake with another mistake. Enforce trailing commas.
- klysm 4y ago
  Do you have a good reason for enforcing trailing commas vs leading?
  - masklinn 4y ago
    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 4y ago
      Do many/most feel this way? I always felt this argument was the diff tail wagging the code readability dog, so to speak
      - jgalt212 4y ago
        It does feel like a misplaced priority.
      - xupybd 4y ago
        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.
  - davidjfelix 4y ago
    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.
- benjaminjackman 4y ago
  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 4y ago
    > Precisely, or even find a way not to require commas. Here it is: https://news.ycombinator.com/item?id=33457176 https://news.ycombinator.com/item?id=33457176
- cardanome 4y ago
  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 4y ago
    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 https://news.ycombinator.com/item?id=32995047
    - cardanome 4y ago
      Another example would be Lisp. And yeah generally, fair point. In Elm though it would cause some ambiguity because of the function call syntax not requiring parentheses. For example: [foo bar baz] Is this a List with three elements or is it one element whose value is a function call on foo with the arguments bar and baz? Who knows. Sure you could have implicit commas on line break but that would be weird.
      - djedr 4y ago
        Yes, in Elm or Lisp this would be problematic. In this syntax though it isn't. Anything between brackets like this: [foo bar baz] that does not contain any nested brackets is a simple tree which contains "foo bar baz" as its sole value (called a suffix). In this syntax whitespace is not a separator. So you can store a single piece of text in such a simple tree. Now if you want to have 3 pieces of text you do this: [foo][bar][baz] 3 simple trees together -- they are subtrees of a top-level tree. If you want to have 3 of these you do this: [[foo][bar][baz]] [[foo][bar][baz]] [[foo][bar][baz]] The linebreaks don't change the tree structure, they are inserted purely for readability. There are no implicit commas or anything. Each subtree is also potentially a name-value pair. If you insert names before the opening brackets: [x [foo] y [bar] z [baz]] You have 3 pairs. The names themselves are also pieces of text (whitespace is not a separator), so you can have names like: [my x [foo] your y [bar] their z [baz]] Still 3 pairs. Now to turn trees like this into something useful, for example XML/SVG, you'd do a little bit of processing on them, e.g. you could transform the names like so: my x [foo] your y [bar] their z [baz] into: <myX>foo</myX><yourY>bar</yourY><theirZ>bar</theirZ> in this manner you could transform: svg [x=[0px] y=[0px] view box=[0 0 21 21] path [ fill=[#FFF] stroke=[#146AFF] stroke width=[2] d=[M11.1,1.4l2.4,...] ]] into: <svg x="0px" y="0px" viewBox="0 0 21 21"><path fill="#FFF" stroke="#146AFF" strokeWidth="2" d="M11.1,1.4l2.4,..." ></path></svg> Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children. I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevko/draft-informal-easyjevko.djevko https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/specifications/blob/master/easyjevko/spec.html https://htmlpreview.github.io/?https://github.com/jevko/spec... Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets. It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility. BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.
- 1-more 4y ago
  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.
carapace 4y ago
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/ 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.
- pessimizer 4y ago
  > That's a technician not a programmer. If a technician can handle a job, why would I hire a programmer?
  - carapace 4y ago
    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 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?)
protomikron 4y ago
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 4y ago
  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-company/ 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 https://www.vendr.com/job?gh_jid=4539989004
- culi 4y ago
  "Elm is dead" https://iselmdead.info/ https://iselmdead.info/
deleted 4y ago
[deleted]
culi 4y ago
I'm looking to work on implementing a simple hex-based puzzle game I used to play a lot as a web app so I recently tried to do some investigating of what libraries might exist out there for this I landed on Elm and the library that convinced me was seeing this demo for the elm library so seamlessly use SVGs: https://www.danneu.com/elm-hex-grid/ https://www.danneu.com/elm-hex-grid/

SVGs as Elm Code

77 points by webwielder2 4y ago

davidjfelix 4y ago

IMHO prefix commas is fixing one mistake with another mistake. Enforce trailing commas.

klysm 4y ago
Do you have a good reason for enforcing trailing commas vs leading?
- masklinn 4y ago
  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 4y ago
    Do many/most feel this way? I always felt this argument was the diff tail wagging the code readability dog, so to speak
    - jgalt212 4y ago
      It does feel like a misplaced priority.
    - xupybd 4y ago
      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.
- davidjfelix 4y ago
  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.
benjaminjackman 4y ago
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 4y ago
  > Precisely, or even find a way not to require commas. Here it is: https://news.ycombinator.com/item?id=33457176 https://news.ycombinator.com/item?id=33457176
cardanome 4y ago
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 4y ago
  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 https://news.ycombinator.com/item?id=32995047
  - cardanome 4y ago
    Another example would be Lisp. And yeah generally, fair point. In Elm though it would cause some ambiguity because of the function call syntax not requiring parentheses. For example: [foo bar baz] Is this a List with three elements or is it one element whose value is a function call on foo with the arguments bar and baz? Who knows. Sure you could have implicit commas on line break but that would be weird.
    - djedr 4y ago
      Yes, in Elm or Lisp this would be problematic. In this syntax though it isn't. Anything between brackets like this: [foo bar baz] that does not contain any nested brackets is a simple tree which contains "foo bar baz" as its sole value (called a suffix). In this syntax whitespace is not a separator. So you can store a single piece of text in such a simple tree. Now if you want to have 3 pieces of text you do this: [foo][bar][baz] 3 simple trees together -- they are subtrees of a top-level tree. If you want to have 3 of these you do this: [[foo][bar][baz]] [[foo][bar][baz]] [[foo][bar][baz]] The linebreaks don't change the tree structure, they are inserted purely for readability. There are no implicit commas or anything. Each subtree is also potentially a name-value pair. If you insert names before the opening brackets: [x [foo] y [bar] z [baz]] You have 3 pairs. The names themselves are also pieces of text (whitespace is not a separator), so you can have names like: [my x [foo] your y [bar] their z [baz]] Still 3 pairs. Now to turn trees like this into something useful, for example XML/SVG, you'd do a little bit of processing on them, e.g. you could transform the names like so: my x [foo] your y [bar] their z [baz] into: <myX>foo</myX><yourY>bar</yourY><theirZ>bar</theirZ> in this manner you could transform: svg [x=[0px] y=[0px] view box=[0 0 21 21] path [ fill=[#FFF] stroke=[#146AFF] stroke width=[2] d=[M11.1,1.4l2.4,...] ]] into: <svg x="0px" y="0px" viewBox="0 0 21 21"><path fill="#FFF" stroke="#146AFF" strokeWidth="2" d="M11.1,1.4l2.4,..." ></path></svg> Notice that here I used a convention where names which end with "=" become XML attributes, whereas names which don't become children. I have used the same convention here (except I don't bother with transforming names with spaces into camelCase): https://github.com/jevko/specifications/blob/master/easyjevko/draft-informal-easyjevko.djevko https://github.com/jevko/specifications/blob/master/easyjevk... to generate this HTML file: https://htmlpreview.github.io/?https://github.com/jevko/specifications/blob/master/easyjevko/spec.html https://htmlpreview.github.io/?https://github.com/jevko/spec... Now I intend to write specifications that codify conventions like this into different formats based on this fundamental syntax of square brackets. It can be useful for all kinds of things. Its advantage is extreme simplicity and flexibility. BTW, for clarity I have to say that the format that I used here: https://news.ycombinator.com/item?id=32995047 https://news.ycombinator.com/item?id=32995047 does a bit more transformations -- it actually sometimes treats whitespace as a separator (e.g. in `svg width[391]` space is a separator). That allows for extreme conciseness, but is not necessary and introduces complexity.
1-more 4y ago
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.

carapace 4y ago

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

pessimizer 4y ago
> That's a technician not a programmer. If a technician can handle a job, why would I hire a programmer?
- carapace 4y ago
  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 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?)

protomikron 4y ago

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 4y ago
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-company/ 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 https://www.vendr.com/job?gh_jid=4539989004
culi 4y ago
"Elm is dead" https://iselmdead.info/ https://iselmdead.info/

deleted 4y ago

[deleted]

culi 4y ago

I'm looking to work on implementing a simple hex-based puzzle game I used to play a lot as a web app so I recently tried to do some investigating of what libraries might exist out there for this I landed on Elm and the library that convinced me was seeing this demo for the elm library so seamlessly use SVGs: https://www.danneu.com/elm-hex-grid/ https://www.danneu.com/elm-hex-grid/