The promise of never needing to really get dirty and debug live Elm code is real, and it's true that nothing else quite lives up to that.
I wrote some notes on getting ghcjs up and running earlier. The basic trick is to ignore the initial README documentation and look on the wiki, following the directions for your specific haskell version. For 7.10: I used ghc 7.10, which doesn’t work out of the box with ghcjs. I cloned ghcjs master and used these instructions: https://github.com/ghcjs/ghcjs/wiki/GHCJS-with-GHC-7.10 from the wiki to install it properly. The quick start on the ghcjs readme doesn’t quite mention everything. In particular, you must bootstrap like: ghcjs-boot --dev --ghcjs-boot-dev-branch master --shims-dev-branch master On Fri, Dec 30, 2016 at 5:27 AM, GordonBGood <[email protected]> wrote: > Art, thanks for your input. I do like Haskell-like syntax and programming > model (something like Elm) so I haven't tried Fable yet, although F# syntax > is alright. Based on what you are saying and my trials, everything (really > incluing Elm) is still in too unstable stage, although Elm is somewhat > usable (although slow) as it is. > > I did the following: > > 1. Tried PureScript in the browser on their "try" website and found > that although I could reasonably quickly get used to its changed syntax and > type class model from Haskell, libraries aren't very stable in that > although I could write and compile successfully a simple little > Data.List.Lazy progression, it would fail silently for some program > variations and blow up with a stack overflow for others; I think it is > inconsistent in applying force to the lazy stream with the library > functions. > 2. I tried installing GHCJS since it doesn't have a try website, and > found that not smooth at all, with broken version references in the cabal > file. Eventually I got it to install with a patched version that someone > had contributed, but couldn't get the ghcjs-boot to build the libraries as > per the instructions because some parts weren't installed where the OS > could find them (more patches, messing around required) - not stable enough > if it takes all this work! > 3. I haven't tried Fable, but from what you are saying it will > probably install but you are saying that the code output sometimes isn't > very good, with no package subsystem. > 4. I tried Kotlin for generating JavaScript but found that although it > generates code for the JVM fine, it still isn't very stable for producing > JavaScript code, and only versions in development have some success at all > (with tail call optimization that works for JVM not working for > JavaScript). > > So it's back to using Elm for the front end and TypeScript/JavaScript, > which are stable, for the stuff that needs to be faster until some of > these, hopefully GHCJS but PureScript would be acceptable get more stable > and work consistently. Elm compiling to more efficient code would also > fill my needs. > > By the dates on the latest PR commits and how much there is to do, > PureScript, and Fable have the best chance of getting there reasonably > quickly, with Elm also actively developed, but I think we are looking at a > minimum of a year for any of them to get to stable status. > > On Thursday, 29 December 2016 22:23:50 UTC+7, art yerkes wrote: >> >> I can comment a bit on purescript and fable (and ghcjs) from a n00b >> perspective in all three. >> >> - Purescript's type system is not as well polished as haskell and has IMO >> a steeper learning curve. >> - Purescript's package ecosystem is very immature. >> - Purescript's js interop is very easy and doesn't fight at all. >> - GHCJS speed was surprisingly fast and it has concurrency features >> builtin (such as calling haskell from javascript with and without a wait >> for a result, chans etc). >> - GHCJS has the full haskell package set, but pins some emulated packages >> at specific versions, so some caveats apply. >> - GHCJS interop allows you at the core to just define javascript to run >> inline, but seems to be in flux in recent versions. I was able to use the >> basic interop features but couldn't find current docs on advanced ones. >> - Fable's type system has everything from .net, including classes and >> interfaces that work as you expect. It's basically the same type system as >> kotlin plus proper sum types and convenient product types. The fable >> language output isn't as perfectly stable and mature as others however and >> the type system has a hole: some functions are invisibly curried >> (temporaries, non-exported functions in a module), and some invisibly >> javascript-style (exported ones in a module, interface methods). >> - Fable's package ecosystem is basically nonexistent, and pure F# >> generally won't work if it relies on unemulated stuff from System.* but js >> interop is easy. >> - Fable's interop is mature and pretty good. It lets you just formulate >> javascript to have in the literal generated code, replacing a specific >> function call. >> >> On Thursday, December 29, 2016 at 3:51:50 AM UTC-8, GordonBGood wrote: >>> >>> >>> >>> On Thursday, 29 December 2016 09:47:13 UTC+7, Martin DeMello wrote: >>>> >>>> On Wed, Dec 28, 2016 at 6:25 PM, GordonBGood <[email protected]> >>>> wrote: >>>>> >>>>> >>>>> Related to speed, it seems to me that the working Fable (F#) code >>>>> linked from your link above is more responsive than the working Elm code >>>>> from another link on that page, both for the same sample application; am I >>>>> imagining things or do you see that too? >>>>> >>>> >>>> yes, but it seems to be due to a slower load time from the backend >>>> rather than any perceptible frontend differences. >>>> >>>> martin >>>> >>> >>> Do you know anything about PureScript as compared to Fable and Elm >>> (according to the article it sits somewhere between as far as safety >>> goes)? It seems that it has an extensive Haskell-like syntax and >>> philosophy, but that may be overly complex for the types of people who >>> would rather choose Elm. >>> >>>> >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/elm-discuss/Um7WIBTq9xU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
