From that discussion it seems that not much of this system was usable at that time. Fortunately it appears more complete now. He got his thesis done too.
MVC web app development test-driven development has always bothered me. I can easily test my models/controllers but to verify that the app HTML isn't borked I have to rely on strict HTML compilation tools (like HAML) and/or slow/painful frontend integration tests that require button clicking, HTML parsing, and form-element filling.
I've always wanted a higher-level way to author and test HTML and I always come back to a more programmatic/declarative way of generating HTML as the best way. I'm not sure if Elm is the answer but I think it's at least a good discussion starter.
Parse error at (line 1, column 1):
unexpected end of input
expecting reserved word 'module', reserved word 'import' or at least one datatype or variable definition
While this massive bit of speculation is exciting, this is not the case. It is a compiler error indicating that the poster somehow compiled an Elm file without any content in it. I suspect my servers are having a bad time right now, so the file may have been only partially read for some reason.
Thank you for posting this link again. It has led me to an interesting paper on a related paper co-authored by Martin Odersky called "Deprecating the Observer Pattern with Scala.React"
Interestingly, the farther I read into this paper, the more I think the Mozilla Rust community should get behind functional reactive programming. After all, an experimental language created with the intention of being used for creating an experimental browser should probably give serious consideration of the abstractions used for event handling.
I also found a talk on FRP, for anyone who's curious:
1) Is this a subset of Haskell, or a brand new language inspired by Haskell?
2) It appears that FRP (which by the way is a cool idea) isn't necessarily language-specific, is this true? My guess is that Elm just brings FRP to the forefront in the same way Lisp brings FP to the forefront?
2) That is totally true! The idea is quite general. I think it works best in a strongly typed language like OCaml or Haskell, but it could work anywhere. FrTime is a Scheme/Lisp/Racket version of FRP. My personal opinion is that it works best in Elm though :P
To be more concrete, in Elm you can work directly with signals if you want. In Yampa you cannot; you only get "signal functions" (which Elm has as well in the form of Automatons).
Flapjax[1], an FRP library for JavaScript, has been around for several years and can be used purely as a JS library[2], or you can use its compile-to-js DSL to build page/app templates[3]:
A couple of years ago, I began (somewhat naively, on my own) hacking together a "next gen" version which was intended to generalize the functionality of Flapjax-as-a-library. I learned a lot, and ended up coming face-to-face with monads and monad transformers (though I didn't realize it at the time) and the limitations and complications that mutable data structures (as opposed to immutable ones) imply for dataflow/FRP frameworks. My work on that library stopped when I shifted from NodeJS to Clojure/ClojureScript for my day-to-day work. Now that I'm a bit more experienced with functional programming, monads, etc., I hope to find some time to restart that effort, using ClojureScript (and protocol-monads[4]?) as the foundation.
Is this actually useful? Has anyone tried it? The examples are quite simplistic. I would like to see a more full featured app or site before I invest any time into investigating it.
I think so, but I am biased (lead dev and designer :P)
The entire site is written in Elm (excluding the code editor which relies on CodeMirror). If you click the "View Page Source" in the top right corner of every page, you can see the full source for it.
(Presumably that submission is why this one (is) was forced to (incorrectly) have an extra /)