Elm for live arts - hello

[Gaspard Bucher]

Hi everyone,

## Brief presentation

I am new to this community. I have contributed code to the Ruby, Lua and (recently) Node.js communities for more then ten years and am now evaluating Elm for the main product of my startup (Lucidogen).

## Similarities to Lua

I think the development of Elm is similar to how Lua evolves and this is fine with me: the core language is developed by a closed group of people and this gives the language some clarity and well thought decisions (as long as this group is good at listening :-)

Here is Roberto's (the creator of Lua) explanation of this: http://lua-users.org/lists/lua-l/2008-06/msg00407.html

## Elm for live arts ?

As my work touches "niche" areas (interactive graphics for live arts), I tend to create lots of supporting code that touch new areas. Maintaining all these pieces of code in Lua for every platform became foolish and I decided to move to an area where all this low-level stuff (even just reading an image in memory) exists: the web browser.

So I rewrote everything in Javascript (using electron) and in a couple of months, I had a complete new show up and running.

But the stage is a place where failure is either (a) very conceptually interesting or (b) a disaster. I want to prevent disasters and am tired of exploring failure as an art concept. I therefore decided to explore other ways to write code for the web, without the pitfalls of a fun but too hacky language.

My requirements while searching for a language were:

• Functional (ish)
• Access to web technologies (canvas, webgl, websockets)
• I can implement live coding in the language (functions hot swapping, glsl shader replacement, etc)

And I found Elm and it just clicked. That's it. The way reactivity is implemented is very intuitive and the constructs would go well with my project.

So here I am (with very tight development cycles and hard time and money constraints). I understand that Elm is a maturing language and that there are many areas were things could need polishing / improving. I don't mind having to adapt my code later on (it can never be worse then the early days of Ruby on Rails) and I will write ports whenever current abstractions do not fill my needs (webgl..., websockets...).

Anyway, I am very excited to finally jump in a statically typed language supporting an already rich ecosystem (the browser) !

And if anyone is working in similar fields (webgl, generative art, sync with DAW), please let me know so we can share some thoughts... :-)

Cheers,

Gaspard

PS: project page http://lucidity.io

[Kurren Nischal]

I have also joined Elm recently and like the ideas for similar reasons you have. I like that it guarantees no runtime exceptions which is the total opposite of javascript, giving you a runtime exception every few lines. 

Pleasure to meet you.

Kurren

[Max Goldstein]

Hi Gaspard,

That's really great! I agree that Elm's reliability ("safety") can make it an excellent choice for live performance.

You've already said that you're aware that Elm is a maturing language (art rarely happens in established places anyway, right?), so as long as you're aware of that things should be fine. Elm does have webGL support but I've found that it's unusably slow.

I'll shamelessly plug two of my libraries that might be of interest.  If you're using websockets, you can look at my socket.io library (works best when you also control the server, doesn't work for vanilla websockets). If you're doing anything generative, here's a better random number generator.

Regarding the artistic exploration of failure, it's hard to top this.

[Gaspard Buma]

Thanks for the failure video :-) !

Performance-wise, I'll see how much of current Elm to use and how much of Javascript to keep.

My main concerns right now is

• A. how to hot-plug new pieces of code (without full app recompile ?)
• B. (more interesting part) How to design object boundaries...
  

For (B), I am heading towards each "module" having two methods "setup" (to allocate required data structures once for each occurence in the graph) and an "update" function.

Here is some pseudo-code to implement a processing graph like this:

graph: main < anaglyph < bloom < cubes

https://gist.github.com/gaspard/ec52e11f23e9f9aeedee

With this solution, connections only happen in the processing graph and modules are stateless (which should help for hot-swapping).

I am using records to pass settings and data down the call chain. Looks like it's the solution that allows "bloom" to not know (or care) about camera but still pass it through from "anaglyph" to "cubes"....

Having Elm throughout is much better then JS since this is the part (connecting things together) where the types are most useful.

Cheers :-)

Gaspard

--
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/v7s9xpGCUtw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Max Goldstein]

Have you seen The Elm Architecture?

In my somewhat-paraphrased reading, every module defines:

• A Model type (usually a type alias of a record)
• An Action type
• init : Model (or a function that gives a model, or a random generator of a model...)
• update : Action -> Model -> Model
• view : Model -> Html (or a collage form, or something else useful)

Then Main puts it all together and winds up knowing a lot about everything but that's okay. Oh and if you need a Common.elm that defines some types that everyone uses that's okay too.

But if you can make modules stateless, that's a fine solution. No one is ever going to complain about stateless things in Elm :)

I think hot-swapping may be broken n 0.16, and has never worked well with custom JS. Sadness.

[Gaspard Bucher]

@Max, yes, using the Elm Architecture as guideline is a good idea. Not sure the 'view' part applies in my case. I will build the editor using this architecture and then I will probably have a better understanding of the overall language to clarify how the processing graph works.

dynamic svg and drag'n drop are my next challenges... ;-)

G.

[Janis Voigtländer]

Depending on what exactly your "drag'n drop" needs are, you could give http://package.elm-lang.org/packages/jvoigtlaender/elm-drag/latest/ a try.

--
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 elm-discuss...@googlegroups.com.

[Gaspard Buma]

@Janis, thanks for the pointer to elm-drag.

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/v7s9xpGCUtw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elm-discuss...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Gaspard Bucher

ch. Maison Neuve 7

1927 Chemin

mobile: +41 78 748 15 38

website  kegais.com

facebook kegais

twitter  @omkegais

[Janis Voigtländer]

I should add this example. It’s not in the docs of the elm-drag library currently, but does better than the others at integrating with Elm Architecture.

​

[Rex van der Spuy]

Hi Gaspard,

I'm also using Elm for interactive multimedia and game projects.

I used Flash for more than 10 years, JS for 5, and am now trying to do everything in Elm that I used to do in Flash.

I spent about 4 months learning Elm casually (thanks to the amazing support of members on this discussion list!) and am now deep into my first big commercial production Elm app.

Here are my general observations:

A) The good:

- Elm is a kind of programmer's Shangri-La: difficult to get to, but once you're there you never want to leave! Although it's still maturing, and the learning curve is steep (but short), the payoff in terms of bug free, readable, and beautifully structured code is worth all the effort. I'm also one of those people who can claim never to have had a runtime error in all my experience using Elm. And, I've had experiences using the compiler which border on the supernatural - it found bugs in my code that would have taken me hours or days to untangle if I'd just been using JavaScript and console.log. This saving in debugging time alone has already paid back all the time I've spent learning Elm.  Overall, using Elm has been the best programming experience of my career - from Basic, though to Pascal, Java, ActionScript and JavaScript - Elm comes out on top.

B)The... could be better.

It's just a matter of library support. 

Here are the weaknesses:

- There is no Elm library that handles asset pre-loading. So, you can't give your Elm app a list of your images, sounds and data files, get file loading stats, and run your app when they're done. For many kinds of games and interactive apps this is an essential feature. Elm needs something like this: https://github.com/englercj/resource-loader

- WebGL support is purely experimental. Elm needs a high level 3D API like ThreeJS or BabylonJS.

- Drag and Drop support is extremely weak and very DIY at the moment. Use at your own peril! There's no full-featured drag-and-drop library, like the fabulous Dragula.js that we have in the JavaScript world. 

- No WebAudio API interface. The only way to play sound files or generate effects is to use Ports. This works, but is not ideal. A nice high-level, pure-Elm sound library that matches the features of something like sound.js (https://github.com/kittykatattack/sound.js) would be really nice!

- A fast, low-level API for drawing primitive lines and shapes that integrates seamlessly wth elm-html and StartApp.

Hey, Elm Community, we need your help with these!! :)

[Max Goldstein]

Hi Rex,

I agree with most of what you said. Apparently a lot of things relating to effects are changing in 0.17, so library authors are holding off on some things. Regarding a drawing library, have you seen Graphics.Collage in core?

[Janis Voigtländer]

Will Graphics.Collage still *be* in 0.17?

> Am 20.03.2016 um 22:36 schrieb Max Goldstein <maxgol...@gmail.com>:
>
> Hi Rex,
>
> I agree with most of what you said. Apparently a lot of things relating to effects are changing in 0.17, so library authors are holding off on some things. Regarding a drawing library, have you seen Graphics.Collage in core?
>

[Max Goldstein]

I don't know, but if it's not, I would think it would be published as a third-party library. My intent was to tell Rex where Graphics.Collage can currently be found.

[Janis Voigtländer]

We'll see. I genuinely don't know, that's why I was asking. The thing about going third-party is that the library contains massive amounts of native code, so publishing and maintaining it as a third-party package will face hurdles.

At this point, having read many dismissals of Graphics.Collage on this list, and no determined defense, I would be wary of committing to its use for a new serious/production project. (And by extension, would also be wary of proposing its use for such a project to someone else.)

Am 21.03.2016 um 01:53 schrieb Max Goldstein <maxgol...@gmail.com>:

I don't know, but if it's not, I would think it would be published as a third-party library. My intent was to tell Rex where Graphics.Collage can currently be found.

--

[Janis Voigtländer]

So my question was really not about whether the library will still *be in core* in Elm 0.17, but whether it will still *be*.

[Emilien Taque]

Evan's point of view here:
https://groups.google.com/forum/#!topic/elm-dev/qYXM3qYPagU

[Rex van der Spuy]

Thank you, Max!

Yes, I actually love the Graphics.Collage API but have been cautioned against its use - as the above comments demonstrate.

I'd love to see a low-level canvas drawing API that integrates seamlessly with elm-html and Start App.

I have an interactive drag-and-drop project coming up soon that needs to be AODA accessible (hence elm-html) but will also have to draw lines (Bezier curves) and shapes (hence Canvas.) 

But, as I'm still very much an Elm beginner, I'm puzzled about how to a build an Elm app that straddles both these worlds.

(Maybe I'll start another thread on this over the next week and two and see what all of you in the Community suggest.)   

[Max Goldstein]

If it becomes necessary, I will write up a defense of why Graphics.Collage should be available in 0.17.

Although Graphics.Collage doesn't have primitives for Bezier (or stars, or a few other things), these could be added in a third-party library that makes use of polygon, which accepts an arbitrary list of points. Some canvas operations might be more difficult that you'd like, but pretty much anything is at least possible.

That said, trying make these drawings accessible to screenreaders, tooltips, etc sounds pretty challenging. Indeed it sounds challenging if you were working in JS with the low-level HTML canvas API. So I'm not sure how one would go about drawing accessible bezier curves in the browser, regardless of tool.

[Rex van der Spuy]

If it becomes necessary, I will write up a defense of why Graphics.Collage should be available in 0.17.

Please do, we really need it! 

That said, trying make these drawings accessible to screenreaders, tooltips, etc sounds pretty challenging. Indeed it sounds challenging if you were working in JS with the low-level HTML canvas API. So I'm not sure how one would go about drawing accessible bezier curves in the browser, regardless of tool.

That's not a problem for the work I'm doing now, as long Graphics.Collage and elm-html can live happily together in the same world.

I haven't yet tried integrating them into a single app yet... but I'm looking forward to attempting that soon :) 

[Christopher Anand [g]]

If someone is writing up a list of reasons why Graphics.Collage needs to stay:

Our outreach program (http://outreach.mcmaster.ca) we introduced 3500 students from ages 6-14  to CS, and over 2000 to ELM in 2015.  We couldn’t have done it without Graphics.Collage linked into elm-lang.org/try.  Anyone familiar with school IT environments know that it is very difficult for even the most confident teachers to get new software installed on their computers.  elm-lang.org/try gets around that.  It also works on the most basic computers, older iPads and bargain-basement Chromebooks.

We would be happy to switch to elm-canvas, or some other set of libraries, especially there were a path to introducing elm-html to beginners which was as well-documented as the current Graphics.Collage, but we need it to be supported in /try, and would like 1 or 2 months advance warning of the switch over.

Christopher

[Rex van der Spuy]

Hi Christopher,

(And hello from another sometimes Hamilton resident!)

The other thing that's important about Graphics.Collage, which you've experience first-hand, is its wonderfully innovative API.

You can teach a student to program with the student realizing they're programming :)

I'd be really sad to see that go, as I think its a really big a step forward in computer programming usability.

I actually wish there was higher-level library built on top of elm-html, that could let me write granular html/css with a similarly pleasant abstractions.

[Christopher Anand [g]]

Hey, if anyone out there can come to Hamilton on May 14th, we are organizing a hackathon at the public library, would love more mentors who can work with children.

Christopher

[Rob Scherf]

Christopher, I live in Toronto so I could potentially take part. Can you share more information?

[Christopher Anand [g]]

We will start at 9 with help installing ELM, but the competition will really start around 10. Librarians will present challenges related to literacy, and then the kids will form teams, brainstorm game ideas, and then the mentors will help them with the more difficult bits. I think judging will be at 3, and they can win summer engineering camp scholarships.

We will be doing a math-based hackathons in schools during the week, so hopefully we will have a pipeline of kids with at least 1 day of experience.

It is a stretch goal, but I think it will be great to say, “Look what kids can do after learning ELM the day before, with no previous programming knowledge.”

Remember that kids spend a lot of time learning algebra, and they are learning less and less imperative mathematics (long division, etc.), so there is good reason to believe this is the right way to introduce them to software development.

There will also be pizza.

Christopher

> On Mar 28, 2016, at 10:12 AM, Rob Scherf <rgsc...@gmail.com> wrote:
>
> Christopher, I live in Toronto so I could potentially take part. Can you share more information?
>

[Rex van der Spuy]

I will certainly try and be there, at least for part of the day!

Just drop me a line closer to the time and I'll confirm for sure: rvand...@tvo.org

Good old Hamilton Public Library!