It's exciting seeing the dream of the 70s come alive. :-)
I believe it is now integrated with intellij as well.
No connection to the product, other than the fact that I paid for it. Unfortunately it doesn't seem to be very well marketed.
From what I recall (last few months I've been away from Java), you can't modify anything and re-run it (which Elm's debugger seems to be able to do).
I'm hoping more people in the browser world come around to the idea that concurrency and parallelism aren't so tricky if you start with language design. Passing immutable objects cheaply between web workers would be a huge deal for projects like Elm!
You can use vanilla javascript, step through the execution of each line of code, get a human readable description of what the line is doing, scrub constants, etc.
There's even a minecraft-like demo building a tower in voxel.js.
I spent some time reading Hewitt's PLANNER paper recently. I am tempted to think that something drawing from his ideas on hypothetical explorations could be implemented for debugging (more than just numerical adjustments). But it's been a while since I reviewed the debugging literature to say with confidence if such a thing once existed.
See: http://factorcode.org/ & http://concatenative.org/wiki/view/Factor/Features/The%20env...
I would invest some time in learning this if it's good for production ready applications.
With the two most recent releases ( http://elm-lang.org/blog/announce/0.11.elm and http://elm-lang.org/blog/announce/0.12.elm ) it is really easy to drop an Elm component into an existing JS application, which we are experimenting with both at Prezi and in the general Elm community.
So I'd (biasedly) say to give it a try. Even if it's still too young for you, I think you'll come out of it writing way better JS :)
Really, you can examine both systems and make your judgments. It's not like this is a paper with a comprehensive related work section.
[1] retailing for over $10,000: http://www.microsoftstore.com/store/msusa/en_US/pdp/Visual-S...
http://research.microsoft.com/apps/pubs/default.aspx?id=1793...
http://research.microsoft.com/apps/pubs/default.aspx?id=2112...
The former (2007) applies live programming to an FRP language; the latter is newer and supports imperative update along with time travel and retroactive update via a concept we call managed time. It is quite easy to do this with FRP, but harder to scale up to richer languages.
Videos are linked into the last paper (and embedded in the first...) but I haven't tried releasing a language yet.
For example, in a project I just completed where we implemented Scheme in C, perhaps we could just memcopy everything and add it to a stack upon each expression evaluation (much easier in Lisp dialects since expressions are nested and you could 'edit as you go' by just changing an inner expression).
Functional purity and immutability mean that functions can be evaluated speculatively, as demonstrated in the video where Mario's jump trajectory is altered as the gravitational force is weakened or strengthened. There is no need to save any state beyond the user inputs (mouse position and clicks, keys pressed) and the time at which they occurred. Once saved, they can be reevaluated safely (due to the purity and immutability), and live-modifying the code or adjusting the time is a simple matter of rerunning. It's a wonderfully designed feature, but the ability to implement with relative ease is a natural consequence of strict FRP.
In an impure, mutable, stateful language this would be quite challenging, and potentially dangerous. Given a line of code that spawns a thread, for instance, how would it be made clear that the inverse of this state is shutting the thread down? What if the thread has already modified shared memory - how will you track that? If you were to attempt to preserve the entire state of the running program (threads, open files, etc.), how would you quickly reproduce it upon modification?
Elm runs in a browser and is designed to be accessible to beginners, but there is still plenty of work to do. Don't expect it to scale very well yet.
Because of this, Mozilla developed its own record-and-replay system that is lower-overhead, but that again does CPU-specific and platform-specific work that needs to reimplemented for every OS and architecture, and relies on CPU features that aren't available at all on some processors and add some limitations of their own (like no recording of multiple threads with shared memory). [2]
In contrast, the Elm debugger apparently takes advantage of the language's pure FRP design to record and replay only input streams, rather than low-level machine/program state - a very different approach, with its own limitations, but also very different possibilities like interactively rewriting history by running different code on the same input stream.
[0] https://sourceware.org/gdb/wiki/ProcessRecord
[1] http://blog.pearce.org.nz/2009/03/setting-up-vmware-to-recor...
Now that I understand Elm is an esoteric system and these results are irrelevant outside its solution domain, I don't really care.
EDIT: Useless meaning there is 0 content that can be seen. It's not that it's ugly w/o JS, there is nadda, zilch, nothing without it.
Not all of them. It's just disturbing that people move so far away from the basics for such simple tasks as static HTML. What about those with disabilities and use screen readers or braille displays? I guess the author doesn't care about the blind or those who choose not to execute arbitrary code on their computers.
