FWIW, this problem also existed for C#/WPF projects.
Then they embraced precompilation and it’s really not an issue anymore.
But it took them a very long time to find a workable solution for that! Those latency issues were one of the reasons that Longhorn failed, and it took MS many years to dig themselves out of these latency problems…
1 Like
This “one compilation delay per GUI interaction” is truly annoying, it’s also not so easy to precompile the callbacks because they are anonymous functions, so you couldn’t just call precompile on them without names. This really holds GLMakie back currently
1 Like
It’s not clear to me the issues for a GUI toolkit are comparable, to justify reinventing in the same way. Julia’s original developers were excellent programmers before (not saying you aren’t) and clearly knew older languages very well, to know their limitations.
Even if you’re right, and there’s a good reason to reinvent (very unlikely) and/or:
then I would take John’s advise and use some of the non-native GUI toolkits. The upside is e.g. learning GUIs. You can’t really improve on something until you understand the current practice well.
I can certainly understand the Julia-only desire, as in, I intentionally try to do everything in Julia, or see how it fits. However, I’ve made an exception, e.g. using Dash (for web dashboards, “GUI” more or less) from Python, even though it also has official company support with Dash.jl.
My reason was some stuff is very well documented for other languages. When I’ve learned it I may use Dash.jl that’s less documented still, but I’m confident, even more so now after my first project, that the next one (or porting the old one) will be simple with out Julia specific docs.
As much as I hate so say this, this may also apply to ML/ANNs, I may want to look into e.g. PyTorch and/or TensorFlow to learn stuff and be later better equipped to help with e.g. Flux.jl.
What is a bit different about [GUI (also web)] frameworks, is the “Hollywood principle”: “don’t call us, we’ll call you”. It’s a key thing to understand for all frameworks (i.e. callbacks). They are not just libraries, that you call, but libraries, the work the other way around. Maybe that’s what tripping you up?
GUI toolkit/frameworks made object oriented programming famous. I think that’s a fair statement. And why people want OOP, not too willing to go back. [Julia’s] multiple-dispatch is a superset of traditional single-dispatch OOP. It’s not clear to me that should make GUI/framework programming different or better (or worse). Am I wrong, and should it really help? And even if, does that require a rewrite, or just reusing already existing and debugged code (what Julia excels at at least for libraries) and you should just use a wrapper (adapter? in OOP/pattern speak).
Saying that I do want to do everything with Julia, doesn’t mean not using libraries, even from other languages. I couldn’t care less if something behind the scenes is implemented with BLAS or GTK or whatever, if it just works. When it’s a library (e.g. BLAS), that can work, and be transparent to you, since you only call some wrapper API. but I’m not totally convinced for frameworks (e.g. GTK), since it needs to call you. I’m just not sure the problems are related to that or lacking wrapper docs (or for docs for the wrapped code).
4 Likes
I agree with this, and also with @mhinsch that when compared to other UI ecosystems out there Julia is not the first tool many would reach for.
That said, I see potential with Julia features that would make it great as a prototyping language because of its dynamism and incremental compilation, but also great as a product-grade tool when combined with something like PackageCompiler. Another fit as the solution to the two-language problem.
I have thought about this for years, and experimented
(some of this echos snippets in other’s remarks).
(a) Easy bake, flexible, attractive GUIs in Julia is essential to bringing others who have been staying outside into the fold.
(b1) It is wise to take advantage of all the work and attention that has gone into GUI expression using HTML/CSS/Javascript.
(b2) b1 should be made available with Julia-styled API[s]
(c) The response must be quick … at least web page like.
3 Likes
If I’m not mistaken, part of the advantage of staying in Julia with e.g. Octavian.jl is that it could retain more Julia type information than Fortran could easily do. I’m guessing the same would be true for GUIs.
In this thread, we have been talking about compilation latency and how this makes may make it difficult to make responsive GUIs. The main focus on that solution thus far has been on improving precompilation or compilation caching.
I would point out that the experience with Python and GUIs is not terrible. Webpage GUIs are written in interpreted JavaScript and provide a decent experience. Certainly callback functions and other GUI responsive elements often do not hugely benefit from the potential speedup of compilation. Having talked to a few people making GUIs with statically compiled languages, this is not a developer experience they particularly enjoy.
Perhaps then what is needed is a better Julia interpreter experience. We do have one that is mostly used for debugging: https://github.com/JuliaDebug/JuliaInterpreter.jl. Perhaps the role of interpreted Julia should be expanded?
In the meantime, an option for some may to be to take advantage of Julia’s interop capabilities to write interfaces to Julia code in other languages.
11 Likes
I have seen this ‘pure julia’ requests a few times and i still wonder, what exactly is meant. Better support for dynamic dispach? Less dependecies on (external) binary?
At least in some cases it boils down to “fully documented and a lot of examples (in julia)” and a certain expectation about DWIM configuration. For me, a long term GUI programmer in a lot of environments and languages, there is a reason, why these are call “tool kits” and not “library of solutions”. You need to learn anyway to structure your problems so you can apply the tools - nobody can do for you.
2 Likes
A package being “pure Julia” means it’s not just a wrapper around a C/C++ library like GTK or Qt.
… while even Julia itself is not “pure Julia” …
1 Like
I’m still not sure what the upside would be? It sounds nice, but in practice GUI toolkits are massive codebases, and not just because they are written in e.g. C or C++. It takes a lot of work to
- Even create a usable GUI toolkit, that has a decent set of UI/UX elements and features, and that allows a programming style that fits with the language it’s used from (e.g. Qt’s code generation, versus wxWidget’s event tables, versus …)
- Make it cross-platform, building on top of system parts that will never be pure Julia (e.g. handling of kb/mouse events, displaying, 3D acceleration, compositing, etc). This still leaves open the choice of a using consistent look across platforms (FOX, FLTK), versus wrapping the native GUI elements (Qt, wxWidgets), both of which have their merits.
- Keeping it working in an ever-changing software environment. The more comprehensive GUI toolkits, like FLTK (
no longer under development) or FOX, already seem to struggle to keep under active development, leaving only a few big well-supported ones (Qt, wxWidgets).
Why not take advantage of the GUI toolkits that are there and are being maintained?
Edit: FLTK is still alive, fixed
3 Likes
It’s hard to tell in advance if there will be any advantages. Perhaps composability and extensibility turns out to be surprising strengths in the GUI domain, like it has elsewhere.
As a parallel, who would have thought some years ago that there would be any sense in trying to implement BLAS in Julia. Today it looks like a definite possibility. And I remember when the work on Plots.jl was proposed, similar arguments came up, and it seemed to basically be a fool’s errand to even try.
Perhaps this is bigger, and Julia’s strengths won’t shine as much here, but if someone is crazy enough to give it a shot, I think, after all these caveats have been brought up, why not just let them take on the ‘impossible’ task. Where’s the harm?
And even some bare-bones GUI library could be good as a proof-of-concept, or for doing simple tasks, so it wouldn’t all be a loss anyway.
11 Likes
Minor correction:
Development of Stable Versions FLTK-1.3.8 has now stopped.
All new development and bug fixing is focused on FLTK-1.4.x.
You can confirm this with the Monthly Commit Activity and the commit history on github.
Of course, the github commit history shows there are only three major contributors in the last two years, which makes it difficult to keep active development compared to large projects like Qt, wxWidgets.
Hmm, don’t know how I missed that when looking at the FLTK site earlier, thanks
Full disclosure, my perceived programming skills far far outweigh my programming ability and actual skills. I tend to think big and force my skills and knowledge to that level. Is it a good approach? I certainly wouldn’t recommend this as the best more efficient way of learning anything but it works for me, in fact I would actively try to prevent anyone from doing it this way.
1 Like
Supreme Court Justice Potter Stewart said when asked about the definition of hard-core obscenity he responded with “I don’t know what obscenity is but I know it when I see it” and I this is what I mean when I say “pure Julia”. It’s not pure as in no contaminates, or other programming languages, but existing primarily within the Juliaverse. It’s syntax is Julian, the code is primarily Julian, the ease of use is Julian, the documentation is written for Julian programmers in a jargon that Julia developers are comfortable with a recognize. If you would like to parse down the definition of “pure Julia” further and split hairs until there is nothing left, you can do so, but you are missing the entire intention and spirit of the discussion at large.
6 Likes
Hi,
Some good news from the libui side. Maybe development will proceed.
https://github.com/andlabs/libui/issues/547#issuecomment-1007763956
3 Likes
I relate to your concerns and desire for a native Julia GUI language.
To have an application to (easily) analyze data, you need a simple way to get some user input. This is in contrast to writing some program statements to specify the analysis you want to run.
Here is an example input box from SAS JMP:
Here the user can drag & drop columns from a data table into various roles, then press “OK” and the analysis is done and the output produced.
JMP has its own language, JSL, which includes allows one to program custom input windows like the one above. It’s user friendly in that it auto-arranges and sizes things automatically for the user (never need to specify box sizes or positions in pixels, for example). If you want to see details, it’s covered in Chapter 11 of the JMP Scripting Guide.
It would be nice to be able to do something similar in Julia.*
Without that, I’ve often found to let the best tool for the job do the heavy lifting. Writing your own input code is a pain in the keister – and it’s usually not due to the input, it’s due the need to support editing.
Often a good tool that already does that for you is . . . Excel. Use Excel as your front-end, then press a button to invoke Julia to grab the input and go.
From this thread, I’ve also learned that perhaps web forms would be a good way to go as well.
*JMP supports calling Python, R, and Matlab code. Waiting for the day it can call Julia code … then I could write the interface in JMP, then call Julia.
5 Likes
- JMP/JSP GUI example: How to create a JMP user interface using display boxes in JSL - JMP User Community
- GUI doc: Display Trees - Create and Use Windows | JMP 12
Declarative UI Yes!