To add another lisp option. Racket has a built in GUI library that is pretty simple to use, and you can update it from the REPL which eases interactivity. Racket has strong C FFI so you may be able to call Julia directly.
https://docs.racket-lang.org/gui/Widget_Gallery.html
Not sure if it’d meet your requirements, but despite the lisp learning curve the language is quick to pick up and pleasant for small projects at least.
@venuur - Any resources for someone who once tried LISP and literally got scared? 
.
I’m not sure if this solution will work for my needs without a lot of effort but it does look elegant and clean! I could try at least.
This is blowing my mind… I’ve had people bring up LISP so much this week. is there some sort of project about to kick off that I’m not keen on? Quantum Computing maybe?
Small update: So here’s my plan… Going to try a few UI’s with Julia backends and even open up a repo where people can contribute different basic examples doing the same sort of thing if they want… The goal is just get some options of what’s out there for doing complicated-ish UI’s with Julia at the heart and soul of it.
I pressed forward with JavaFX + Java and have a simple interactiv-ish plot widget in a day (borrowed heavily from some examples). But I can select regions, and have built in event handlers in < 200 LOC, and it’s responsive. So it’s a start for my prototypey thing, nothing like Makie fanciness. Screenshot%20from%202019-11-24%2021-37-02|690x202
Probably not going to beat Java for robustness or completeness, but Racket is fun. Since you already know how to program, their quick tutorial may be enough:
https://docs.racket-lang.org/quick/
For a very gradual introduction consider How to Design Programs
https://htdp.org/2019-02-24/part_preface.html
It very slow introduces language features to learn programming from scratch.
FWIW, a seasoned Julia user is halfway to being a Lisp programmer (possibly without realizing it, without prior exposure to Lisp). Practical multiple dispatch started with the Common Lisp Object System (Julia made it parametric and very fast), a functional approach is well supported and encouraged by Julia, closures also, and of course we have macros even if not used as pervasively (possibly because other parts of Julia are more powerful).
What is really different (or “scary”) in Lisp is the S-expression surface syntax. Until, of course, you find out about Meta.show_sexpr. 
The relationship to lisp is actually one reason I like Julia. I’ve always wanted to use a lisp, but my scientific work has always been Python or R. But Julia has real potential if I can ever manage to convince myself to use it for a work project.
Though I have to admit I sometimes wish I could use S-expressions. I kinda picture Julia as lisp with arrays instead of lists.
Back on the topic of GUIs I feel like there’s a real gap in simple GUI tools for scientists. Sometimes I want to share a tool with a non-programmer for whom Jupyter is too much but for which Excel is not enough. (Or perhaps I just want to avoid writing VBA 
)
I guess the best analogy is I’d like to see something like the Python argparse library for GUIs. You specify the parameters and their types and you get. A minimal GUI for entering those. If I get the time, I’ll look at Blink or GTK and see if I could write up something. If I do I’ll post a separate thread since I suspect there’s interest in this forum.
R can be lisp-y
I forgot about that. I remember finding it interesting that many R classes are just lists underneath. Although I haven’t used R in a while, I remember finding it limiting for general purpose programming in ways that I feel Python and Julia don’t have. Though that may just be that I learned Python second so I had a better foundation.
I do miss the ESS emacs package. It made for an elegant interactive environment. Although Juno recovers a lot of that for me with its good REPL integration. Once I figure out how to do debugging in Juno I feel it will be super productive.
using Debugger
@enter fn()
if you like to use the GUI, you’d only need Juno.@enter.
So I made some more progress on the Java front end. But am quickly realizing… Writing an interface between Java and Julia is going to be pretty painful.
So like any other insane person I decided to see what the julia ecosystem had, literally if I could click on drawn shapes in a plot/canvas/whatever I’d be able to make everything in pure Julia. Even if it was clunky. It just doesn’t exist, but there are open issues, one made by me, (https://github.com/JuliaGizmos/GtkReactive.jl/issues/58, https://github.com/JuliaGizmos/Interact.jl/issues/345) to maybe try to get the ball rolling.
In the mean time, because I know 0 JS, I am going to go back to Java land and try to write the least painful, most generic interface I can to Julia… My journey for doing that will be documented here: Running Julia from JAVA? What is crazier? (just incase someone is following along in the future and desperate to see what people have done).
How is it done… Do you write a GUI that controls Julia code, or the opposite, you write Julia code that controls a GUI?
How is it done… Do you write a GUI that controls Julia code, or the opposite, you write Julia code that controls a GUI?
Under the architecture/framework I’m describing, I wouldn’t say that one controls the other. You have a Julia module that contains some code that you want to make available via a GUI so you write an API with Genie to expose your functions via an HTTP request. Your front end GUI simply makes calls to this API, gets a response back, and then does what it wants with it.
I’ll try to put together a simple example in the next couple of days and I’ll post a link here.
I put together a trivial example and deployed it to Heroku. The link is here:
https://julia-api-client.herokuapp.com
Heroku’s free dynos go into sleep mode when not being used so it will take long to load and because the API is running on a separate dyno, the first time you try to compute an answer it will take long. Subsequent computations should be fast. It’s obviously not very attractive but I may make it a little nicer in the future if folks are interested in seeing this kind of thing.
The front end is a simple Vue.js web app that calls the API, which is written in Julia with Genie.jl. The API sets up a single route /addxy that calls a function addxy and returns the response to the client as a json object.
I’ll post the code to GitHub and add more detailed explanation when I get back home. I’ll update this response with links to the API repo and the client repo as well.
Once we get good binary compilation support then it will be better
CImgui is pretty nice. A interesting approach might be to give Dart/Flutter a go. They recently added support for wrapping C native code, but the native app build process is still maturing (unless you’re on a mac). They already have GLFW integrated, multiple backend support, a nice drawing library via Skia, and I believe they’re roadmapping to get GTK support as well. Maybe not an immediate solution, but something to watch since they’re developing rapidly.
My arm chair prediction is that we may see a substantial shift from traditional GUI libraries to the cross-platform kits like ReasonML/Revery and Dart/Flutter in the next year or two…
Alright, the links to the API and Client are here:
https://github.com/mthelm85/JuliaAPIClient
https://github.com/mthelm85/JuliaAPI
The link to the app is here (the client and API are running on free dynos which go to sleep when not in use so it will take a while to load the client and then when you try to compute an answer it will call the API, which will have to wake up. It all works, just be patient and try it a couple of times )
https://julia-api-client.herokuapp.com/
Keep in mind that most of these files are generated automatically (it looks like an overwhelming amount of code but this is like an hour’s worth of work). In the case of the client, the Vue CLI does the vast majority of the heavy lifting and for the Julia API, I used PkgTemplates.jl and also copied the procfile and example from this repo:
https://github.com/milesfrain/GenieOnHeroku.git
The basic flow is this:
For the API, there is a file called Sum.jl which contains a single function addxy(x::Int64,y::Int64). There is a second file called ApiExample.jl which includes Sum.jl so that it has access to the addxy function. I then set up a route /addxy which is available to the world at https://julia-api-example.herokuapp.com/addxy. You can test this yourself by including query string parameters in the url like this:
https://julia-api-example.herokuapp.com/addxy?x=4&y=6
Go ahead and click on that and modify the x and y values and you’ll see the actual JSON object returned by the server.
The front end, which can be written with whatever you want, was written with Vue.js. It simply has two inputs that are used to construct the above URL (it just swaps out the x and y values with whatever you put into the inputs). It then makes the call to the URL and waits for a response from the server and displays the value on the web page.
Easy, right?
Thanks so much for doing this! Really clean example - the JS is still beyond me though.
Couple questions…
Is there any noticeble problem with passing large hunks of data around in this way? Say someone has a plot with many lines on it, and I don’t know, 5,000 points per line? Can this type of interface accommodate that? Or is it better to save it to disk/DB pass the reference and have JS load it?
@wsphillips I looked into Dart/Flutter on your suggestion. It seems pretty convenient! At least some of the JS things I don’t know are handled - the barrier to entry seems less high for a novice/solo dev. Still seems pretty high though.
I guess I am surprised that the UI/UX JS scene hasn’t found a way to make these things more convenient. I’m finding writing in Java to be painless right now. Sure I am comfortable in Java, but the workflow is much more concrete. Going from something like a simple input form to an interactive widget with visual components seems exponential in complexity for JS, while in Java it’s really not. Something I can do solo in Java in 2-3 days I feel might take a month with multiple developers if done in JS. Granted they’d do the job right, and I’m hacking away! I could be reading the wrong tutorials, being ignorant, or many other things. I remember when Flash ruled the internet - although those were dark times - it was trivial to stand up something a little fancy. Now JS is king, and I can’t seem to find my way over the bump.
The react paradigm for Julia UI’s is so easy and intuitive, GTK in python is cake, java event listeners are easy peasy. The abstraction involved in JS, workflow across languages, interfaces, etc is not a landscape I know. Nor do I see clear explanations of how people operate in this world.
Sorry if this is long winded I’m just trying to explain where I am at with this.
There is a heavy reliance on JS at the moment, but Dart and ReasonML are both trying to be a universal UX language for web, mobile, native etc. that isn’t necessarily a costume for JS. I don’t know how well it will spill over outside of the regular “app” world of mobile and web, but I think it could be a less painful alternative to what’s out there today. For instance, the guys working on https://github.com/revery-ui/revery are betting pretty hard it will be great for native UI design.
In the end, I guess it depends on how you plan to run your code and what level of integration you need between the GUI and the Julia bits doing the work. REST API > gRPC/custom socket API > local/in process API in terms of ease of implementation. For what its worth, I was able to get Interact and Blink running in a few minutes to do some hardware control and had zero issues with lag, although anytime you load Electron stuff it takes its time on initial launch. YMMV.
I had a horrible time with blink(I think it was blink) via port forwarding the UI from a remote server. I spent two weeks writing a multiwindow app it worked beautifully and all the data ops were scaling fine. I deployed it to a remote system(which was somewhat locked down) and it was unusable :(. In that case I don’t think blink was the issue, any other solution would have done the same but bad memories.
The real issue is, interactivity with custom widgets isn’t a reality right now. At least I haven’t seen it done and don’t know how to do it. Click and drag is essential to me. Deployment in pure Julia is the most ideal situation, it just can’t suit my needs so I’m balancing the two language problem and trying to keep it from being a 4-5 language problem. I’m a hobbyist working a day job, so I can’t possibly keep up with 2-3 bleeding edge tools undergoing frequent changes while trying to learn toooo many new things (even though I desperately wish I could).
Great suggestions and down to earth experiences. We could probably all benefit from some examples if you have time to make/share some :). It’s threads like these that save peoples brains when they are at their wits end trying to make something work out.