For example if I wanted to create a GUI using Julia at some point I need to know another language like Javascript for web interface and C++ for desktops.
At least we can avoid the 3 language problem though.
In the case of web programming, I’d argue that what we have right now can be rightly termed the four language problem—you need to have a facility with each of Julia, Javascript, HTML, and CSS. 
There’s some very promising work being done by a few pioneering folks who are working variously on compiling subsets of Julia to Javascript or WebAssembly. One concern with WASM compilation is the size of the generated code. WebAssembly provides a very barebones runtime, so for the general case of arbitrary Julia code running in the browser you’d need to ship the entire Julia runtime to the browser along with your program, which is probably rather small in comparison.
I wonder whether there’s a useful subset of Julia that could be compiled to WASM in a minimal way.
Some language communities have attempted to provide a native solution, eg historically CLIM. The problem is that the related technologies move fast, and it takes a lot of work just to keep up, so generally these are semi-abandonned or severely constrained in features. Development happening in JS or similar is a way of pooling effort between different language communities. I think of this as a feature instead of a problem, as it frees resources for problems for which Julia has a comparative advantage.
I view HTML & CSS as orthogonal technologies to general languages like Julia, and would not even call them a “language”, just a form of data. HTML is really basic, and CSS provides things which would not make a lot of sense to duplicate in Julia or any other language natively. Even if you had a similarly expressive “native” DSL for a similar purpose, you would have to learn its semantics, which would probably take the same amount of effort, except you would not have the general resources you do now for either HTML or CSS.
IMO the “two language problem” is better used to describe the annoying situation where you do roughly the same thing in both languages, just have to switch because of performance reasons.
10 Likes
You can use Gtk.jl to write application in Julia, sure the internals deal with C code, but you don’t really have to see them.
Otherwise for a more native experience we would need to build some sort of GUI framework on top of GLVisualize/Makie or something like that. This is necessary to some extend since we need at least buttons for interactive plots.
There’s some GUI code already in GLVisualize, but ideally we would need a more generic separate package. The main issue is that it’s a huge amount of work.
https://github.com/JuliaGL/GLVisualize.jl/tree/master/src/gui
Exactly, in the case of GUIs arguably a domain specific language like QML is better suited to describing a GUI than a general programming language. It also encourages clean separation between GUI and backend, making it easier to switch to another toolkit if needed. All depending on personal taste and problem size of course 
6 Likes
That’s an interesting point: while I think that QML is extremely useful for more complex UI design (and looks extremely nice cross-platform), it’d be nice to have a simple solution to display a plot and some buttons for interactivity just with Julia code (for such a simple thing learning qml language seems like overkill). I think doing that in Julia is much more complicated than it should be.
As @jonathanBieler mentions, I guess that could be done by either adding this functionality to GLVisualize, or by simplifying the process of drawing a plot on a Gtk Canvas (as Immerse does using Gadfly) with some interactivity (panning, zooming…) and generalizing it to all backends that can draw on Gtk (such as InspectDR, GR, etc…).
Why would you need C++ for desktops? You might need to use a library written in C++, but that doesn’t mean you need to write C++ code, does it? I’m not a GUI programmer, but couldn’t you use either GitHub - JuliaInterop/Cxx.jl: The Julia C++ Interface or GitHub - JuliaInterop/CxxWrap.jl: Package to make C++ libraries available in Julia to interface with C++ graphics libraries?
Isn’t having to use libraries from a different language exactly what is meant by the “two-language problem”?
Not really.
Solving the two language problem doesn’t mean throwing DRY out the window: in fact, it means taking DRY more seriously.
1 Like
No, not at all. It’s having to write (or rewrite) code in another language, to get acceptable performance.
This is quite common in most dynamic languages.
Especially for the initial target audience of Julia, who tend not to be CS types, but rather scientists, mathematicians, researchers, not having to rewrite their “prototype” code in a totally different language (usually much harder to learn! or even one with a lot of special restrictions, like Numba), makes a big difference in productivity.
2 Likes
We are mostly academics and former academics here. We don’t talk about GUI’s. They scare us. In my current job I’ve recently been asked about providing a bare-minimum interface for something and I’ve been having nightmares ever since 
.
I would have inserted a clip from Apocalypse Now here but that involves using the GUI on my browser and that scares me.
22 Likes
If one is willing to use a Jupyter notebook,
would work for that.
Otherwise, I have learned to be cautious of using “simple” to describe a GUI. They look simple to the user (that’s the point), but the programmer has to deal with a zillion minor problems to make that happen: what happens when the window is resized, how do units map to the screen (HiDPI taught people who thought they could use pixels a painful lesson), does it work OK cross-platform, etc.
I don’t think it is only academics. GUI programming is a discipline in its own right. CLI versions of very sophisticated tools exist for decades without someone coding up a GUI.
2 Likes
I see your point and I’m aware of the difficulties of GUI design. However I think that there is some middle ground where things are too complex for Interact (or its notebook-independent successor InteractNext) which does not include any layout capability, but still do not justify the complexity of a different language/sharing data between Julia and QML. The(abandoned? last commit is from one year ago) Escher was a nice example of that: simple widgets that work with reactive signals and vbox and hbox for simple layouting in pure Julia plus support for plots. I think that if that package is no longer maintained, it’d be nice if some other package could cover that use-case. As I mentioned, GLVisualized plus some basic GUI capabilities could be a possible solution.
1 Like
Even many of us who aren’t an academic or former academic feel the same way.
Give me a nice CLI, and benchmarking tools to judge if something is objectively “better” or “worse”, none of this wishy-washy subjectiveness of GUI design 
(I applaud the people who are able to come up with good graphical interfaces - it is very important, I simply don’t have that talent!)
1 Like
I like to humbly ask to consider writing similar constructive ideas!
Would you like to read something similar on math (or other interesting for you) topics from people who don’t like math?
1 Like
I’m always interested in learning diverse opinions - about everything in the world, not just programming!
an academics trying to write bunch of GUIs now tell you that it’s boring and verbose, some designers like the ones in visual studio is a must go if they exists. on the other hand, i really liked functional reactive way of GUI programming, this is especially useful for runtime dynamic GUIs, other than static designed one by XAML or QML.
I think most CS people(maybe all?) don’t like to write GUI code. I’m in the game industry and our product requires A LOT of consumer quality GUI.
There were good old days that all game programmers have to do is managing things like simple buttons, sliders, check boxes, popup windows with .NET framework. Those were annoying too, but tolerable. And after doing those things, they can get back to things they like to do. Like managing server-client communication, graphics optimization, developing a new game system. But now… well Steve Jobs came along with iPhone, and now our consumer expects applish GUI.
GUI are quite popular and important in the scientific field, e.g. people that use MATLAB like to make small interactive apps with a few buttons and a plot. Even though the language isn’t the best for this it’s surprisingly easy and efficient to put together a small tool. For repetitive manual task like data validation or annotation it’s actually very useful to have a custom interface in which you can tweak a few parameters, it not only saves you time but ultimately help you do better science.
Matplotlib also has some widgets that you can add to your plots.
If you want people that are not familiar with command line programs (like experimentalists) to use your tools it’s also good to provide a graphical interface for it.
5 Likes
Actually, jokes aside, I consider the UI to be one of the most important parts of games and it’s unfortunate that a lot of game developers don’t realize its importance (especially when it comes to choosing screenshots to advertise their game!). That doesn’t mean they have to be complicated though, I’ve been spending a lot of time lately playing classic rogue-likes Cogmind and Caves of Qud (check them out, they’re magnificent) in which I use an all-keyboard UI that more or less dates back to the original rogue and it works great.
Also, it’s really cool to see someone from the games industry in a Julia forum! I know this doesn’t necessarily imply you have written any games in Julia, but if you’ve attempted it I’m sure we’d all be really fascinated by your experiences.
2 Likes