VSCode already has a linter. A GSoC project was to add one to Atom.
I don’t see why an editor being worse at languages other than Julia is an advantage.
2 Likes
- I didn’t need it for work anymore, and I wasn’t interested in writing and supporting something I didn’t use
- At the time I didn’t find any collaborators with deep expertise in another database interface that were interested in synthesizing a common interface from the ground up
- I realized the limitations of the DBAPI approach around SQL dialect; it’s almost impossible to write generic SQL for any meaningful interaction
- I needed access to deep libpq features and I didn’t want to block those by trying to standardize for theoretical other databases
2 Likes
I completely agree with this, especially the part about it being impossible to write generic SQL. It’s amazing how limited sqlalchemy is when you really dig into it, not because they didn’t try, but because all the SQL dialects behave differently and have different API’s (here I’m referring to details other than the query itself).
My biggest motivation for taking this on is that I completely agree with many of the posters here that many (most?) data science people will be extremely resistant to Julia as long as nothing like this exists. Having this won’t magically get thousands of people on board and making valuable contributions, but it may go a long way. I personally have a stake in this if only to make it easier for me to interact with my colleagues who are still using Python.
That said, I think for us to do something meaningful here we’d need a number of things:
- A simple, uniform interface across all Julia database packages that allows users to query with any SQL string and dump into any DataStreams
Sink. - An unobtrusive design that makes it easy for users to use special features of individual packages that may not be universal (this is the one place where, if we are very careful, we might be able to offer something that sqlalchemy can’t).
- Simple for package maintainers to implement (at least the minimum features).
- Some level of compatibility with Spark, or at least carefully checking that this is feasible.
- A path toward ORM.
What do you guys think, is this asking too much? I think DataStreams.jl sets an encouraging precedent, though this might be more ambitious.
(I’ve included this list in my issue for now.)
3 Likes
What about the plugin style of Atom and VSCode means that they cannot have a debugger? Atom already has a debugger, it just needs breakpoints which has to deal with implementing those in the debugger. I’m not sure how this is a valid argument for why the IDE has to be Julia-specific, when the point you make is that the plugins could be more full-featured.
What about being part of Atom doesn’t allow Juno to have a linter? It does have a linting plugin for Julia code, but it’s built on Linter.jl which highlights far too much right now. But I’m not sure how it being not part of the default means that it’s not possible…
A Julia-specific IDE would be a huge task and would only make it take longer to get these features. If you’re going to argue for a Julia-specific IDE, you have to argue for a feature that cannot be done in Atom. One might be having multiple windows, though someone like @pfitzseb would have to let us know whether there’s a fundamental Atom limitation there or whether Juno could in theory be extended to allow this.
1 Like
I replied to this posts
where there is no implication that the wish is to have a Julia-specific IDE. Only that current atom and VS code (what I use) is no match at all to the Matlab IDE (that I use too, and a lot).
And directly supporting object databases? (I’m not a big fan of “object-relational-mapping”)
Atom (and Juno) already allows multiple windows: https://github.com/atom/tabs/pull/134
(just right-click a file in the navigation pane and select “Open in New Window”)
Of course it depends on the users.
The way I see it, you think and like the things current Julia users like, those who are already persuaded with Julia.
The question is, Is this group large enough? Do you want to expand to users who are different?
I’d argue that MATLAB’s IDE is the best out there for non compiled languages (Well, Visual Studio is untouchable, so we must put it a side).
Its integration with the language and how fast it assists the user to use the features of the language is really great.
Julia currently misses 2 main things (In my opinion and in my priority order):
- Debugger.
- MATLAB like IDE.
Regarding MATLAB like IDE, Spyder is a good starting point.
The project isn’t dead and work based on donations.
Its next version should be able to handle more languages and not only Python.
I really hope the Julia community will step up and assist with making Julia a first class citizen in Spyder.
Regarding Debugging, I read it is a real challenging feature given Julia architecture yet it will become one of the most prioritized features once Julia 1.0 is out. So it only requires some patience as I’m sure Julia developers will find creative and effective way to tackle it.
P. S.
MATLAB’s editor in R2018a allows column based editing in Live Editor mode.
3 Likes
But they are not connected to the same session, so Atom hasn’t but Juno doesn’t. Just try running the code on the two windows and see.
I am sure you know your own mind best, but unpaid work on making tools so that a particular group of users would consider Julia may not be very rewarding, and efforts like this are frequently abandonned for this reason. A good rule of thumb is that we will have X for Julia when a person or a group of people want to use X in Julia and is willing and capable of putting in the work.
What spyder has that Atom lacks? Can you be more specific please?
Basically everything can be done in Atom. Even if there’d be no way to implement some feature in plugins only we could either try to get what we need into Atom base (they’re pretty open to that) or ship a custom build of Atom.
Connecting multiple frontends to one Julia process isn’t super far fetched, but not trivial either. For now there are way more important things for me to work on. A compromise would be to make connecting to an external REPL more first class, which would mean you could have the editor on one monitor and an external terminal of your choice on another.
I’d also be very interested in what you’re missing in Juno that you use in Matlab/Spyder.
Feel free to open feature requests at the Juno.jl repo (maybe take a look if there’s one open first).
As a loong time Matlab user, and a former user of Spyder, I don’t think creating a dedicated, single language IDE for Julia is a good idea. It would entail a Herculean effort to duplicate already existing features in current open-source alternatives, and then a losing battle to keep up with those editors, as they keep pulling away from you.
The main reason to use something like Atom or VSCode isn’t that it supports multiple languages, but that each language reaps the benefits of features and plugins created from all the communities surrounding those languages. There is no way Matlab or R studio are going to be able to keep up with the development of Atom/VSCode or others in the long run, much less would Julia, where the interest in even using such a tool is lukewarm.
Matlab is a good IDE, but the editor is, frankly, primitive. For one example, they still don’t have support for column editing a decade after I started bugging Mathworks about it (“It’s hard to implement”), much less multiple cursors. If you’re not used to multiple cursors, and consider them ‘very low priority’, then you are missing out big time.
Juno is very close to being a (superior) alternative to Matlab/Spyder. Most of the missing features are not intrinsic to Atom, they are just ‘stuff that’s not yet implemented’. Implementing them for a dedicated IDE wouldn’t be any easier than getting it into Atom, you would just have many fewer people to share the work with.
So what does the Matlab IDE have over Juno? In my view:
- Integrated debugger with breakpoints
- Juno will have this in the moderately near future. Since it’s the core functionality that’s missing you couldn’t put this in a dedicated IDE yet anyway.
- Integrated profiler
- There’s a graphical profiler for Julia, though I guess it’s not integrated in Atom
- Slick integrated plotting experience, easy to juggle many plot windows, etc.
- This is where I’m unsure of the state of Julia/Juno. Especially the part where you’re juggling many plots.
- More toolbar buttons
- I guess you can add more buttons to Juno/VSCode if you like (?)
What else?
Most, or maybe all, of these shortcomings are probably easier to address with the current Julia editor efforts, than in a dedicated, stand-alone IDE. As a bonus, you get vastly superior text editing support and a bazillion plugins to cater to your every need, whim and aesthetic preference. And, even if you don’t use other programming languages, you presumably write ordinary txt-files, latex, markdown, css, json, what have you, and it’s really nice to be able to use a single editor for everything.
12 Likes
Thanks for the in-depth answer 
I definitely agree that building an IDE on top of a good, extensible editor is the way to go.
Regarding some of those points you brought up: A big issue with Juno is visibility of features (I’d hazard the guess that many Juno users don’t know about all its features, much less use them) – in an effort to address that I’ve prepared a concept for a new website that exposes Juno’s features better (see here for now).
So yes, we do have an integrated graphical profiler and a mostly nice plotting experience.
7 Likes
Very nice! As for the plotting part, my main problem has been that I like to throw out lots of plot windows that float around, in their own windows, and then, to be able to modify or interact with those plots. So far, I’ve not been able to re-create that workflow in Julia/Juno.
I’m using multiple cursors maybe twice a month, but I’m zooming and comparing plots 20 times a day, so compared to interactive plotting it is low priority for me. I think there’s a bit of a divide between the activity of doing science and the one of developing software.
Juno does have interactive plots, but they are not as good as matlab’s (it’s just a zoom button instead of the rectangle zoom thing), and you can only compare plots by going back and forth in plot history.
3 Likes
Right, that’s something I’d quite like to have as well.
Imho it’s not really something Juno can/should handle though – a plotting package can just display as many plots as it wants (e.g. in a Blink.jl or ElectronDisplay.jl window, or natively like Makie.jl or GR.jl). I suppose we’d need a slightly nicer way to switch between integrated and external display though (I’m not actually sure how that works right now).
That depends on what plotting solution you use. What you’re talking about is basically a very rudimentary image viewer so you get at least some kind of interactivity for plotting solutions that provide an svg or even pixel graphic as output. If you’re using something like PlotlyJS then you do get proper interactivity in Juno; and if you want multiple plot windows then you’ll need to disable Juno’s plot capturing and rely on what your plotting solution provides.
1 Like
I’m not a software developer either, just using it for R&D work, so I do lots of plot inspection and interaction. But multiple cursors are awesome, every time you want to make similar changes in several places. I’m pretty sure you’re not using them as much as you could 
1 Like
You’re right, but I was probably exaggerating that aspect of it.
- Though ideally a database API should be carefully planned out, I don’t actually anticipate it being a lot of code, it is just an interface.
- There was a reason I said “SQL strings”: indeed I am not going to spend my effort on any kind of domain-specific language extension or anything resembling that, though it would be nice to build something that doesn’t get in the way if somebody wants to do that.
- I already have a “hacked together” tool in my company’s git that serves many of the functions we’ve been talking about here, I’d be happy to abandon that in favor of something more general.
- If it’s possible to do some level of integration with Spark, this might go from being a “nice-to-have” to a vital tool for me.
- It’s true that I don’t feel in desperate need of this right now, but it’s still something I’d use every day, I wasn’t suggesting I’d build something I’d never use purely out of charity. I’ll never do that.
So indeed, if it turns out that this has to be some huge 100 hour project I’m not going to do it. Also, as I said, I’d be willing to be the primary on an interface package as well as JDBC.jl, but for this to work would depend on some level of enthusiasm from other package maintainers and committers.
(Sorry, this stuff really should be in the other thread now, but I can’t move it.)
2 Likes
I only use Matlab IDE for very basic analysis. I really can’t program in anything besides Vim. The source code starts to have a lot of :w 
But I totally agree with you about the Debug tool. I really miss this.
2 Likes