You can write relatively robust applications with Gtk.jl on osx/linux with interactive plots since like 2-3 years. It’s just that bugs often results in a crash instead of an error message, since you are dealing directly with C objects. Windows support isn’t great though.
But you don’t really need to write your GUI in Julia, you could write it in whatever (Qt, Electron, …), call Julia and display the results. The problem is rather that’s it a lot of work to develop such a tool from scratch.
The problem is also that most Julia developers don’t seem to need such a tool, or they would have created it
Spending a lot of time to produce something like you show in the picture is certainly not my understanding of how best to spend scarce developer time right now. Unless you really want such a tool, then feel free to develop it! Julia currently has 2371 open issues and I bet there are at least that many in Julia packages. I suggest we start there instead
I think that using the plural pronoun (we) in the topic title has mislead some to think that this is the topic for asking what other people could do “for Julia”, which translates to “a specific group of potential or current users”.
With respect, I don’t think that is how it works. In free software, what contributors find indispensable or interesting gets written quickly, other stuff later, and neatly packaged GUI interfaces for commercial (or equivalent) purposes when someone pays for it.
Eg the “deluxe GUI debugger” is still lacking because the people who could write it don’t need one that urgently. Repeatedly asking for it probably won’t make it happen any sooner; in the meantime, there is Rebugger.jl. At this point, if someone finds the development workflow inconvenient they may benefit from a re-examination of how they are working with code, and learn about tools like Revise.jl.
Also, as have been said before, what exactly is the purpose of making Julia grow fast? Isn’t it already ambitious enough to have the best programming language we can make? R has 20.000 published packages, hundreds of which are really good. I’m not sure that’s what we should hope for for julia.
When I read these threads, which appear every once in a while, I feel like some people started using S, R or SAS or Python (my experience with programming comes from statistics) when they were already mature and had all the tools they currently use. But I’ve seen an old version of SAS that was pure command line, R-Studio is fairly new and R 2.x was also done mainly in command line, and the list goes on. I understand that as a user you want a mature language right now, and you just want to be able to do something, sometimes without thinking about it very hard. And Julia isn’t there yet for a lot of fields. And not just that, things are still moving around, packages are being updated and changed daily and that’s hard to deal with when you’re not used to these type of projects. As a biologist, I’ve found all this fascinating, lurking in Discourse, play with the code, test code snippets, go into the codebase and read the lengthy discussions about 0-index vs 1-index, or how to name things after rows and cols. But that’s me and that’s why I’m here.
I do believe, though, that we can do a better job in producing learning tools that are really simple. When I taught R in school for fellow biologists, simple things like “how to read data in R from Excel, csv file…” were enough to throw people off. Blogs, Stackoverflow answers, and resources that really solve easy problems for beginner users can help. My impression is that the idea for beginner here is someone who already knows programming and switches from Python, Matlab or something else into Julia and want to learn how to do complicated algorithms already. That type of beginner can read code, can read the documentation, etc, but tools for the absolute beginner, meaning the “I-have-no-idea-about-programming-but-want-to-run-an-ANOVA” kind of user are lacking, IMO. I know people work in Julia for free, in their own time and that doing and ANOVA in Julia probably has no intrinsic advantage over R or Python, but I think any community needs to cater to those users too. I’m confident it’ll happen with time and I really hope that Julia keeps growing.
Sorry for the long response, I’ve been meaning to write something like this in different threads and just saw this old one being revived.
This is a general problem with new languages. Anyone here recognizes a good thing when they see it, but most companies just see risk. They prefer a “tried and true” solution where they know recruiting will be easy. It’s the “no one got fired for hiring IBM” mentality.
The hurry, as I see it, is that lots of us would like to be using Julia more, and may even have problems that are good fits for it, but are limited because of the slow uptake of businesses. The social problem (slow tech adoption) leads to the worst kind of technical problem (using legacy tools, despite availability of better options).
I am working at a research institute and using Julia a lot for the daily work. However, most of colleagues use Python and Java. Years ago, very few people used Python at this institute and currently most of the colleagues use Python and Java for the daily work. This institute mainly focuses on big data and AI, and Python becomes very attractive in the recent years with several popular frameworks such as Spark and TensorFlow.
So, if there are popular frameworks as TensorFlow and Spark for Python, maybe Julia could attract more people quickly. Julia has some unique features and seems very suitable for these two fields, such as TPU, GPU support for AI computing, and Flux.jl. Currently, it only needs popular and mature packages, such as JuMP for Optimization. HPAT.jl stops maintaining the Julia version this year and put all efforts in developing the Python version. I guess the main consideration would be the popularity of the language and the package ecosystem, rather than the advantage of the language itself. If Flux.jl for AI could be as popular as JuMP in Optimization, it could increase the share of Julia a lot.
By the way, in an interview yesterday we add Julia language as a consideration, as some of my Julia code need more people to maintain. More and more people would know and use Julia.
My 2 cent is that Julia should push to get better ASAP, since C++ is getting easier to use while R and Python are getting faster. The two language issue may not be that severe in the future due to cheaper hardware or cloud services and improvement of other languages.
Rushing to “get better” without taking the time to let things develop naturally is a good way to end up with a language that’s just as bad as those 3 you listed. Except we won’t have the decades of hard work and experience that those languages have leveraged to make them more palatable.