# Can the two language problem ever be solved for GUI programming
**URL:** https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857
**Category:** Offtopic
**Tags:** guis, gui
**Created:** [February 6, 2018, 5:34am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857 "2018-02-06T05:34:25Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@xiaodai](https://discourse.julialang.org/u/xiaodai)
#### Post date: [February 6, 2018, 5:34am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/1 "2018-02-06T05:34:25Z")
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.
---
### Author:  [@yurivish](https://discourse.julialang.org/u/yurivish)
#### Post date: [February 6, 2018, 5:42am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/2 "2018-02-06T05:42:20Z")
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.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [February 6, 2018, 6:53am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/3 "2018-02-06T06:53:19Z")
Some language communities have attempted to provide a native solution, eg historically [CLIM](https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager). 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.
---
### Author:  [@jonathanBieler](https://discourse.julialang.org/u/jonathanBieler)
#### Post date: [February 6, 2018, 9:07am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/4 "2018-02-06T09:07:07Z")
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](https://github.com/JuliaGL/GLVisualize.jl/tree/master/src/gui)
---
### Author:  [@barche](https://discourse.julialang.org/u/barche)
#### Post date: [February 6, 2018, 10:29am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/5 "2018-02-06T10:29:09Z")
> [@Tamas\_Papp](#):
>
> 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.
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 🙂
---
### Author:  [@piever](https://discourse.julialang.org/u/piever)
#### Post date: [February 6, 2018, 11:16am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/6 "2018-02-06T11:16:21Z")
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…).
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [February 6, 2018, 12:11pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/7 "2018-02-06T12:11:38Z")
> [@xiaodai](#):
>
> 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.
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](https://github.com/Keno/Cxx.jl) or [GitHub - JuliaInterop/CxxWrap.jl: Package to make C++ libraries available in Julia](https://github.com/JuliaInterop/CxxWrap.jl) to interface with C++ graphics libraries?
---
### Author:  [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)
#### Post date: [February 6, 2018, 1:15pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/8 "2018-02-06T13:15:18Z")
Isn’t having to use libraries from a different language exactly what is meant by the “two-language problem”?
---
### Author:  [@oatlzzvztd](https://discourse.julialang.org/u/oatlzzvztd)
#### Post date: [February 6, 2018, 1:18pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/9 "2018-02-06T13:18:27Z")
> [@mkborregaard](#):
>
> Isn’t having to use libraries from a different language exactly what is meant by the “two-language problem”?
Not really.
> [@Tamas\_Papp](#):
>
> 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.
Solving the two language problem doesn’t mean throwing DRY out the window: in fact, it means taking DRY more seriously.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [February 6, 2018, 1:21pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/10 "2018-02-06T13:21:21Z")
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.
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [February 6, 2018, 3:05pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/11 "2018-02-06T15:05:11Z")
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.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [February 6, 2018, 3:15pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/12 "2018-02-06T15:15:23Z")
> [@piever](#):
>
> it’d be nice to have a simple solution to display a plot and some buttons for interactivity just with Julia code
If one is willing to use a Jupyter notebook,
> **[GitHub - JuliaGizmos/Interact.jl: Interactive widgets to play with your Julia...](https://github.com/JuliaGizmos/Interact.jl)**
>
> Interactive widgets to play with your Julia code. Contribute to JuliaGizmos/Interact.jl development by creating an account on GitHub.
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.
> [@ExpandingMan](#):
>
> We don’t talk about GUI’s. They scare us.
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.
---
### Author:  [@piever](https://discourse.julialang.org/u/piever)
#### Post date: [February 6, 2018, 3:25pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/13 "2018-02-06T15:25:52Z")
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](https://github.com/shashi/Escher.jl) 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.
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [February 6, 2018, 6:59pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/14 "2018-02-06T18:59:56Z")
> [@ExpandingMan](#):
>
> We are mostly academics and former academics here. We don’t talk about GUI’s. They scare us
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!)
---
### Author:  [@Liso](https://discourse.julialang.org/u/Liso)
#### Post date: [February 6, 2018, 8:26pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/15 "2018-02-06T20:26:27Z")
> [@ScottPJones](#):
>
> > [@ExpandingMan](#):
> >
> > We are mostly academics and former academics here. We don’t talk about GUI’s. They scare us
>
> Even many of us who aren’t an academic or former academic feel the same way.
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?
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [February 6, 2018, 11:01pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/16 "2018-02-06T23:01:09Z")
> [@Liso](#):
>
> Would you like to read something similar on math (or other interesting for you) topics from people who don’t like math?
I’m always interested in learning diverse opinions - about everything in the world, not just programming!
---
### Author:  [@babaq](https://discourse.julialang.org/u/babaq)
#### Post date: [February 7, 2018, 3:25am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/17 "2018-02-07T03:25:27Z")
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.
---
### Author:  [@YongHee-Kim](https://discourse.julialang.org/u/YongHee-Kim)
#### Post date: [February 7, 2018, 11:41am UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/18 "2018-02-07T11:41:49Z")
> [@ExpandingMan](#):
>
> We are mostly academics and former academics here. We don’t talk about GUI’s. They scare us.
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.😱
---
### Author:  [@jonathanBieler](https://discourse.julialang.org/u/jonathanBieler)
#### Post date: [February 7, 2018, 1:38pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/19 "2018-02-07T13:38:01Z")
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](https://ch.mathworks.com/matlabcentral/mlc-downloads/downloads/submissions/64984/versions/3/screenshot.png). 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.
---
### Author:  [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)
#### Post date: [February 7, 2018, 1:57pm UTC](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857/20 "2018-02-07T13:57:56Z")
> [@YongHee-Kim](#):
>
> I’m in the game industry and our product requires A LOT of consumer quality GUI.
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](http://www.gridsagegames.com/cogmind/) and [Caves of Qud](http://www.cavesofqud.com) (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.
[Next page](https://discourse.julialang.org/t/can-the-two-language-problem-ever-be-solved-for-gui-programming/8857.md?page=2)