IDE for Julia

[Deb Midya]

Hi,

Thanks in advance.

I am new to Julia and using Julia-0.3.7 on Windows 8.

I am looking for an IDE for Julia (like RStudio in R).

Once again, thank you very much for the time you have given..

Regards,

Deb

[Tero Frondelius]

From here: http://julialang.org/downloads/ 

• The Juno integrated development environment (IDE). http://www.junolab.org/

[Jeffrey Sarnoff]

Hi, Deb
You noted that you are using Julia-0.3.7. Unless you are required to use 0.3.7, your first step should be installing the current version. 
you can get it at http://julialang.org/downloads/
There are a couple of IDE efforts underway.  They do help, but there is no RStudio-like environment for Julia today.
In addition to Juno, you might look at http://jupyter.org/ , they have recently upgraded their effort, and Julia along
with a few other languages (Python) are of central importance to that project. 
(apology for writing links that don't link)

[Arch Call]

Deb,  I use Juno all the time.  It works good for me on Windows 10, and Julia version 3.11

I have used R-Studio extensively in R and it is a great IDE.  Juno is nowhere near as powerful, but Julia is a speed demon -- way faster than R.

...Archie

On Wednesday, August 26, 2015 at 11:12:22 PM UTC-4, Deb Midya wrote:

[Viral Shah]

Also, it is worth pointing out that a lot of the future IDE effort (Juno 2) will be focussed around Atom.

https://atom.io/packages/language-julia

https://github.com/JuliaLang/atom-language-julia

https://github.com/JunoLab/atom-julia-client

-viral

[Kevin Squire]

Hi Viral, just curious who is working on that development?  Your post seems to imply an officially supported effort, but that doesn't mean that development on other IDEs will be discouraged, I presume? :-)  (Not that I'm aware of other IDEs being worked on...)

Cheers,

  Kevin

[Nils Gudat]

Just check the contributor list here: https://github.com/JunoLab/atom-julia-client/graphs/contributors
Let's say it's fairly strongly tilted towards Mike at the moment (who also originally built most of the Juno LightTable IDE) :)

[Viral Shah]

It’s mainly Mike Innes. Certainly not to discourage any other efforts, but the number of people I have seen using Atom recently makes me feel like this could be the one.

-viral

[Nils Gudat]

I've been using JunoLT for about a year and switched to the new Atom client about 2 weeks ago - I think it's already really good, despite a long to-do list and some rough edges that need ironing out.

[Sheehan Olver]

Does Atom Support Gadfly graphics yet?

(I got it installed but the output from Gadfly is just "Plot(...)"

[Seth]

It does with the excellent Hydrogen plugin: see http://imgur.com/b8UGF1N for an example I whipped up.

[Jeffrey Sarnoff]

How are people who are using Atom+Hydrogen setting up Atom for Julia and are there other packages of particular help?

[Scott Jones]

The fact that Mike is working on it would make me confident of it.  Currently all of the developers I'm working with have switched to Atom (for Julia, C, C++, and Python work) [I've used it, and like it, but so far I'm still sticking with Emacs, in part thanks to Yuyichao's (and others) nice work on julia-mode.el, and also because my fingers just know Emacs without thinking, and I haven't had time to set up Emacs bindings for Atom yet, or find a Emacs key binding package for it].

Scott

[Jeffrey Sarnoff]

thanks

[Seth]

I followed the installation instructions at the repo site (https://github.com/willwhitney/hydrogen) and it just worked. It's really nice to set watches on variables - that graph I plotted can even be in a watch pane so that if I modify any of the variables and reevaluate, the graph updates dynamically.

[Jeffrey Sarnoff]

I will do that.

[Cedric St-Jean]

Scott, do you have a way to run the notebooks (IJulia) inside Emacs? I run IJulia in the browser and edit code in Emacs, and would love to combine both.

On Monday, August 31, 2015 at 9:04:28 PM UTC-4, Scott Jones wrote:

[Sheehan Olver]

I got hydrogen working but it defaults to the 0.3.7 kernel.  How do I change the default?

[Spencer Russell]

I think it uses the first julia kernel that Jupyter reports, and I haven't seen a way to switch it aside from ensuring that I only have one IJulia kernel installed. It was a bit ago, but I think I just deleted the one I didn't want from ~/.ipython/kernels/.

 

-s

[Andrei Zh]

@Cedric Unless you are interested specifically in notebooks, I'd suggest trying ESS mode for Emacs which has support for Julia including REPL. It looks something like this (though this video also uncovers sometimes annoying bug in ESS mode).

[Jeffrey Sarnoff]

Installing Atom+Hydrogen on Linux

Carefully following the directions on https://github.com/willwhitney/hydrogen does work.

First, install the most recent version of Atom.

If you have python installed and python3 is the default, or you dont have python installed you need a minimal python2.7 for the moment.

  at the command prompt: PYTHON=python2.7 apm install hydrogen

  (give it a minute)

[if you installed python2.7 just for this, you can delete it now]

you need python3 (or python2.7, I guess -- I know it works with python3)

when you want to use atom+hydrogen

at the command prompt: atom (starting it from the menu does not work!)

load a Julia source file, highlight some code and press Alt+Ctrl+Enter

(the first time takes a while, so highlight e.g. 1 and press Alt+Ctrl+Enter, after that it goes quickly)

[STAR0SS]

I think a good IDE should have:

- A proper console and a good way to send single line and block of codes to it (e.g. matlab's code section)

- A decent text editor

- Integrated plots

- Proper window management (docking, etc) so you don't have windows everywhere 

All this meet two others broad and important goals, namely having a good plotting solution and being able to make GUI applications in Julia.

For these reasons I feel like something like Julietta was the way to go.

[Seth]

Have you tried Hydrogen with Atom? It has all of those things (subjectively).

[STAR0SS]

It's pretty good but it's like lighttable, there's no console and the plots management is a bit wonky (plots on top of your code?).

[Seth]

You can create a watch window that has your plot in it so that it's not on top of your code. Bonus: if you change your variables, it updates after evaluation. See http://imgur.com/elLU3M7 for an example.

Of course, even with these features, it might not be right for you.

You can have a console window with the term2 plugin, but I've found limitations in colors and cursor display and for me it's just easier to have a separate terminal window open.

[Oleg Mikulchenko]

I agree. BTW, does someone consider Eclipse plugin for Julia? Similar to pydev. For scientific work I prefer Spyder, but for debugging Pydev is more powerful. Not that I like Eclipse, just no choice to avoid it :)

For some reasons, Python run on Atom with Hydrogen, but Julia doesn't, it is hanging forever when I put Ctrl+Alt+Enter with highlighted code. Any advice?  

On Tuesday, September 1, 2015 at 7:05:59 AM UTC-7, STAR0SS wrote:

[Jeffrey Sarnoff]

That happened to me when forgot to start atom from the command line and used the menu entry or shortcut instead.

[Jeffrey Sarnoff]

What is your environment?

[Oleg Mikulchenko]

Fedora 20. 

Difference with loading the file from the menu versus starting atom with filename as param exist for Python, and start from the command line solves the problem for Python. But not for Julia. 

[Jeffrey Sarnoff]

not knowing Fedora, but on linuxmint --

the best guidance I can give you is the entire process that worked for me -- the details really matter more than they should.
I have both python 2.7 and python 3.4 installed (I use python 3.4, sometimes other stuff wants python 2.7--this is one of those occasions),
python 3.4 is set as the default python (that is good for using Atom+Helium once it is all set up).
if you don't have it, now install ipython[notebook] (I think I did that for both pythons after a while of frustrations)
you also need zeromq -- for your system and the julia package and IJulia
I don't remember exactly how I got zeromq set on my system

If it were me, I would uninstall atom and helium. get the two pythons in place, and make 3.4 the default then ..
install the latest atom from the website (the latest one is important)
and make sure it opens fine from the command window (just never open it from the menu or link).
then close it and in a new command window: (you can try)
PYTHON=python2.7 apm install hydrogen
(I needed)
sudo PYTHON=python2.7 apm install hydrogen

it should take a little time and show that the install worked
close the command window, open a new one
$atom

when atom opens, click on Packages and verify Hydrogen is there
assuming it is ..
create and save test.jl
1+2

then highlight 1+2, select Hydrogen from the Packages menu and click it
(if Hydrogen is not there, go into settings [Ctrl+Shift+P and type settings view open (enter)
go to  install on the left and type hydrogen then install it from it there]

when Hydrogen is first used in atom, it takes time to get itself together,
   during that time the symbol moves and it looks like it may be stuck
   (and when it is stuck -- that is how it looks)  let it have a few minutes
   before deciding it is going nowhere.

hope this helps

[Scott Jones]

No, I wish! I just heard about something to combine Emacs and IPython, I'll let you know if I find out anything more.

I just run IJulia on one screen, Emacs on another.

[Ista Zahn]

I've also been looking for a package for interacting with Jupyter from
Emacs. Currently in Emacs land we have EIN[1] and ob-ipython[2]. The
ob-ipython dev appears willing to add support for other jupyter
backends but needs help[3].
https://github.com/gregsexton/ob-ipython/issues/9. Support in EIN is
also being considered[4], but help appears to be welcome there as
well.

In short adding support for other Jupyter backends in emacs is badly
needed, and help to make this happen is wanted.

Best,
Ista

[1] https://github.com/millejoh/emacs-ipython-notebook
[2] https://github.com/gregsexton/ob-ipython, but both only work with python.
[3] https://github.com/gregsexton/ob-ipython/issues/9
[4] https://github.com/millejoh/emacs-ipython-notebook/issues/40

[Michael Francis]

In case anybody runs into the same problem - Atom currently has issues with mouse selection/dragging under a linux virtual machine. This is a known bug with the version of chromium that they are using (more recent versions of chromium do not have the issue.) 

Otherwise it works very well, I do wish there was a console output though. 

[Oleg Mikulchenko]

Thank you, Jeffrey.

You pushed me to install python3.4.3/iPython/Jupiter/numpy/scipy/matplotlib and it works standalone and under atom. So I have two versions of Python working under atom and Julia - none. Tried different atom installations (with different default Pythons) – it doesn't change behavior. Not having the console prevents me from root causing and debugging. May be good time to switch back to Python with many good IDEs  ;) 

[Oleg Mikulchenko]

ok, after careful dozen of installations/de-installations, atom-julia works for basic features. But it fails for graphics: UndefVarError: @generated not defined while loading .../ColorTypes/src/traits.jl . Any suggestions? Thanks. 

[Tony Kelman]

You're probably trying to use an 0.4-only version of a package under Julia 0.3.

[Oleg Mikulchenko]

May be something wrong with messing up different versions of Julia and Python, agree. I have installed clean versions on Fedora 22 VM (Julia 0.4 only and Python 2.7 only) and it works fine, even at opening files from a menu. 

On the generic IDE side, I think, some mix of features of new contemporary text editors (LT, Atom) and traditional IDE (debug breakpoints, output consoles, inspections of arrays, tooltips, plots, etc.) can give productive usage of IDE. Nice text editors with plugins/packages, e.g. Atom, are not enough per se. Just IMHO.   

[kike]

I  agree with you, Deb

Hi, firstly thanks,i am new to the topic of the programming and i chose Julia i would like to say what i think to reflect on this:

Install the IDE Julia Studio in 5 minutes and to write code, i had to install packages, was ideal, then Forio not continued to maintain.

I have tried to salaried Juno, Atom, IJulia, Lighttable, Sublime text ... if all the IDE that there is information in the network ... i have not been able to find something minimally similar to Julia study in terms of practicality ,simplicity of installation and operation.

They say that Julia is a language that is simple and fast with a great future ... but if they want to extend and reach non-programrs, there is that make things easier and simple ... that is to say a IDE JuliaEstudio type.

There are more non-programrs, developers, which means that while for developers experts is necessary the integration of different languages in different applications and to work in the cloud, for the non- programrs with a high-level language fast, convenient to install and also with a great deal of support from the community in terms of packages that is Julia, but if you need to do a master to simply install it, something is amiss.

This is a comment from a simple non-developer.

Regards

[Stefan Karpinski]

Feel free to step up to the plate and help make any or all of that happen.

[Daniel Carrera]

On Saturday, 5 September 2015 21:03:28 UTC+2, kike wrote:

They say that Julia is a language that is simple and fast with a great future ... but if they want to extend and reach non-programrs, there is that make things easier and simple ... that is to say a IDE JuliaEstudio type. 

How do you make a programming language for non-programmers?

Look, there is no programming language or IDE in the world that will allow you to write a program without your having to learn programming. Here is my advice:

1) Forget IDEs. Just download a reasonable text editor (e.g. Notepad++ on Windows).

2) Download Julia.

3) Run the Julia interactive shell and go through the manual:

http://docs.julialang.org/en/release-0.3/#manual

 

There are more non-programrs, developers, which means that while for developers experts is necessary the integration of different languages in different applications and to work in the cloud, for the non- programrs with a high-level language fast, convenient to install and also with a great deal of support from the community in terms of packages that is Julia, but if you need to do a master to simply install it, something is amiss.

This is a comment from a simple non-developer.

Programming languages are designed for programmers. It takes a certain amount of time and effort to learn how to program in any language. Julia is easier to learn than most.

Daniel.

 

[Uwe Fechner]

While I understand your point, the success of a new programming language depends on the availability of a good IDE. Apart from the projects, mentioned so far I also want to mention spyder. Integrating Julia support would be easy and it would make the transition for Python users easier.
Not everyone, who needs some programming in for example in science wants to become a "hardcore hacker".

https://github.com/spyder-ide/spyder

[Sisyphuss]

Julia is still in its early stage. Even the document is not very understandable, how can there be a full fledged IDE? (If I remember, Julia hasn't a debugger yet.)

This lack differentiates the hardcore hackers and casual programmers (e.g., me). That's why currently Julia is only a carnival of hackers. 

Me, I'm quite satisfied with Juno, though I can't save the plot produced by it. 

When the language becomes mature, and has more reception, there will naturally be an IDE like Spyder mentioned by you.

[Sisyphuss]

Maybe I should also express my concern that the concept of IDE is also going through a revolution (e.g. notebook, lightable). They are more natural for dynamic languages. The matlab-like IDE is a bit old fashioned.

[Daniel Carrera]

On 14 September 2015 at 08:16, Uwe Fechner <uwe.fec...@gmail.com> wrote:

While I understand your point, the success of a new programming language depends on the availability of a good IDE.

No it doesn't.

C, C++, Perl, Python, Fortran, JavaScript, PHP, and arguably even Java became successful long before they acquired an IDE. I think that there are more languages that became successful without an IDE than with one, so let's not overstate the issue. An IDE is *good* to have because *some* people want them. Good documentation is more important. Having the right features and being at the right place at the right time is even more important.

 

Apart from the projects, mentioned so far I also want to mention spyder. Integrating Julia support would be easy and it would make the transition for Python users easier.
Not everyone, who needs some programming in for example in science wants to become a "hardcore hacker".

https://github.com/spyder-ide/spyder

Sure, why not. But it might be a bit odd to depend on Python to start work on Julia.

Cheers,

Daniel.

 

[Daniel Carrera]

On 14 September 2015 at 10:23, Sisyphuss <zhengw...@gmail.com> wrote:

Maybe I should also express my concern that the concept of IDE is also going through a revolution (e.g. notebook, lightable). They are more natural for dynamic languages. The matlab-like IDE is a bit old fashioned.

 Could you please clarify that for me? What are the features of LightTable that you find so compelling? What are the features of a Matlab-like IDE that you dislike? I'm just curious; I don't use either. I use Atom and that's mainly because I like multiple cursors.

Cheers,

Daniel.

[Tamas Papp]

On Mon, Sep 14 2015, Daniel Carrera <dcar...@gmail.com> wrote:

> On 14 September 2015 at 08:16, Uwe Fechner <uwe.fec...@gmail.com>
> wrote:
>
>> While I understand your point, the success of a new programming language
>> depends on the availability of a good IDE.
>>
>
> No it doesn't.
>
> C, C++, Perl, Python, Fortran, JavaScript, PHP, and arguably even Java
> became successful long before they acquired an IDE. I think that there are
> more languages that became successful without an IDE than with one, so
> let's not overstate the issue. An IDE is *good* to have because *some*
> people want them. Good documentation is more important. Having the right
> features and being at the right place at the right time is even more
> important.

You are of course right, but having a dedicated IDE is not the issue per
se --- programmers need a work environment that makes it easy to write,
compile/evaluate, run, test, load etc code (whichever is applicable),
and look up documentation.

I think that there are two cultures:

(1) people who prefer to learn and use a single, very powerful editor
for many tasks (vim, Emacs, Atom, ...),

(2) people who are used to each language/task having a dedicated IDE
(Matlab, Mathematica, etc, but it does not stop there, as they may use a
dedicated IDE for LaTeX, etc).

I would say that (1) is comparatively more prevalent among programmers,
but (2) is relatively common in the scientific community. If one has
always used an IDE, learning a new, powerful general editor and work
environment can look intimidating and unnecessary; also, when people ask
which one to use they can get conflicting advice. But IMO in the long
run it is a good investment so perhaps explaining this would be useful.

Best,

Tamas

[Sisyphuss]

I do like matlab-like IDE provided that its interface, font, color and so on are clean and aesthetic. However, they are only used as development tools. They could not be used in a presentation like Notebook could. LightTable is something between the two: it is more presentable than the matlab-like IDE, and easier to program than Notebook. However, it doesn't support markdown or LaTeX.

There is also another approach: knitr, designed by Yihui Xie, which is referred as literate programming by him.

[J Luis]

segunda-feira, 14 de Setembro de 2015 às 09:26:05 UTC+1, Daniel Carrera escreveu:

On 14 September 2015 at 08:16, Uwe Fechner <uwe.fec...@gmail.com> wrote:

While I understand your point, the success of a new programming language depends on the availability of a good IDE.

No it doesn't.

C, C++, Perl, Python, Fortran, JavaScript, PHP, and arguably even Java became successful long before they acquired an IDE. I think that there are more languages that became successful without an IDE than with one, so let's not overstate the issue. An IDE is *good* to have because *some* people want them. Good documentation is more important. Having the right features and being at the right place at the right time is even more important.

Yes it does (IMO off course)
 
I'm have many years of experience with Matlab and find its IDE a can't-work-without-it tool. When one experiments its debugger the reason becomes obvious.

[Tom Breloff]

"Julia is only a carnival of hackers".  I love this... Can it be the official motto of Julia Computing? Or maybe someone can make a theme song to be played at the next JuliaCon? (We should ask Snoop Dog to perform...)

I use Sublime Text 3... I think very similar to atom. I don't understand the big fuss about running your code in the same program you edit it (but then again I guess I fall into the "programmer" category)

[Daniel Carrera]

On 14 September 2015 at 12:40, J Luis <jmf...@gmail.com> wrote:

segunda-feira, 14 de Setembro de 2015 às 09:26:05 UTC+1, Daniel Carrera escreveu:

On 14 September 2015 at 08:16, Uwe Fechner <uwe.fec...@gmail.com> wrote:

While I understand your point, the success of a new programming language depends on the availability of a good IDE.

No it doesn't.

C, C++, Perl, Python, Fortran, JavaScript, PHP, and arguably even Java became successful long before they acquired an IDE. I think that there are more languages that became successful without an IDE than with one, so let's not overstate the issue. An IDE is *good* to have because *some* people want them. Good documentation is more important. Having the right features and being at the right place at the right time is even more important.

Yes it does (IMO off course)

This is not a matter of opinion. This is an empirical claim. With little effort we can define a criterion for language success, and determine whether any language has ever become successful before it acquired an IDE. A single example (e.g. Fortran) falsifies the claim. In fact, I would make a stronger statement: that MOST successful languages achieve success before acquiring an IDE. Off the top of my head, I offer the following successful languages:

Without IDE: C, C++, Perl, Python, Fortran, JavaScript, PHP, Java

With IDE: C#, VisualBasic, Matlab

I'm have many years of experience with Matlab and find its IDE a can't-work-without-it tool. When one experiments its debugger the reason becomes obvious.

Do you claim that Fortran, C and Perl never achieved success until someone wrote an IDE with a built-in debugger? ... Yeah, I know that's not what you want to say. Please understand that even if you find an IDE indispensable for Matlab, that doesn't make IDEs indispensable for all people for all languages. The fair thing to say about IDEs is that they are a really good idea to have because there are people who really really want them.

Daniel.

[Daniel Carrera]

On 14 September 2015 at 13:13, Tom Breloff <t...@breloff.com> wrote:

"Julia is only a carnival of hackers".  I love this... Can it be the official motto of Julia Computing? Or maybe someone can make a theme song to be played at the next JuliaCon? (We should ask Snoop Dog to perform...)

:-D

 

I use Sublime Text 3... I think very similar to atom. I don't understand the big fuss about running your code in the same program you edit it (but then again I guess I fall into the "programmer" category)

I fall into the "programmer" category too. I just asked my wife (who likes IDEs) what she likes about them and she talked about built-in debuggers, built-in documentation, and project management. I have to admit that those things sound useful.

Cheers,

Daniel.

[Scott Jones]

On Monday, September 14, 2015 at 7:17:43 AM UTC-4, Daniel Carrera wrote:

On 14 September 2015 at 12:40, J Luis <jmf...@gmail.com> wrote:

segunda-feira, 14 de Setembro de 2015 às 09:26:05 UTC+1, Daniel Carrera escreveu:

On 14 September 2015 at 08:16, Uwe Fechner <uwe.fec...@gmail.com> wrote:

While I understand your point, the success of a new programming language depends on the availability of a good IDE.

No it doesn't.

C, C++, Perl, Python, Fortran, JavaScript, PHP, and arguably even Java became successful long before they acquired an IDE. I think that there are more languages that became successful without an IDE than with one, so let's not overstate the issue. An IDE is *good* to have because *some* people want them. Good documentation is more important. Having the right features and being at the right place at the right time is even more important.

Yes it does (IMO off course)

This is not a matter of opinion. This is an empirical claim. With little effort we can define a criterion for language success, and determine whether any language has ever become successful before it acquired an IDE. A single example (e.g. Fortran) falsifies the claim. In fact, I would make a stronger statement: that MOST successful languages achieve success before acquiring an IDE. Off the top of my head, I offer the following successful languages:

Without IDE: C, C++, Perl, Python, Fortran, JavaScript, PHP, Java

Some more data points: Cobol, PL/I,  Lisp/Scheme, M/MUMPS (you may not have heard of it, but your healthcare systems (HMO, hospital, lab) probably use it), Basic, Pascal, Ada, Ruby, Rexx (and the list goes on!)

With IDE: C#, VisualBasic, Matlab

Yes, IDEs can be nice, mostly for debugging sessions, IMO, and I try to write code that I don't have to debug later.

I'm happier with a more powerful editor such as Emacs, most IDEs have comparatively fairly limited editors.

[Scott Jones]

On Monday, September 14, 2015 at 7:13:37 AM UTC-4, Tom Breloff wrote:

"Julia is only a carnival of hackers".  I love this... Can it be the official motto of Julia Computing? Or maybe someone can make a theme song to be played at the next JuliaCon? (We should ask Snoop Dog to perform...)

Yes!  Prefer that to "fresh approach to technical computing" 😜 (that's always seemed so limiting to me, as if Julia weren't great for general programming)

[Joshua Ballanco]

 
On September 14, 2015 at 14:17:43, Daniel Carrera (dcar...@gmail.com(mailto:dcar...@gmail.com)) wrote:

> On 14 September 2015 at 12:40, J Luis wrote:
> >
> >
> > segunda-feira, 14 de Setembro de 2015 às 09:26:05 UTC+1, Daniel Carrera escreveu:
> > >
> > > On 14 September 2015 at 08:16, Uwe Fechner wrote:
> > > > While I understand your point, the success of a new programming language depends on the availability of a good IDE.
> > >
> > > No it doesn't.
> > >
> > > C, C++, Perl, Python, Fortran, JavaScript, PHP, and arguably even Java became successful long before they acquired an IDE. I think that there are more languages that became successful without an IDE than with one, so let's not overstate the issue. An IDE is *good* to have because *some* people want them. Good documentation is more important. Having the right features and being at the right place at the right time is even more important.
> >
> > Yes it does (IMO off course)
>
>
> This is not a matter of opinion. This is an empirical claim. With little effort we can define a criterion for language success, and determine whether any language has ever become successful before it acquired an IDE. A single example (e.g. Fortran) falsifies the claim. In fact, I would make a stronger statement: that MOST successful languages achieve success before acquiring an IDE. Off the top of my head, I offer the following successful languages:
>
> Without IDE: C, C++, Perl, Python, Fortran, JavaScript, PHP, Java
>
> With IDE: C#, VisualBasic, Matlab

I suppose you could also take the counter-counterpoint of LISP. People not only built IDEs but entire *machines* tailored specifically to running and debugging LISP, and it still hasn’t (really) caught on (yet).

That said, I think the Clojure community provides a useful example for how to approach the editor/IDE debate. All the early Clojure developers used emacs, and much of the early community was either on emacs or vim (yes, there were a few of us). In the intervening 7 or so years, though, as new developers who were familiar with other IDEs entered the community, they began projects to develop plugins for their IDE of choice. As such, Clojure now has first-rate plugins for both Eclipse and IntelliJ.

It was really only later that projects were started to build “true” Clojure IDEs, and still I don’t think any of these surpass (or even really approach) the utility of the IDE plugins (the three IDEs of which I’m aware are: LightTable, NightCode, and clooj).

One important element that allowed much of this for Clojure was the early development of nREPL, the network-enabled REPL. With this, all editors/IDE plugins stand on equal footing with access to the REPL. I noticed in the code to REPL.jl there’s a function `start_repl_server`, but it doesn’t seem to be used anywhere.

If I had to pick someplace to focus effort on improving tooling for Julia in general, I’d look at improving/adding a network interface to the REPL.

[Scott Jones]

On Monday, September 14, 2015 at 8:21:41 AM UTC-4, Joshua Ballanco wrote:

...

I suppose you could also take the counter-counterpoint of LISP. People not only built IDEs but entire *machines* tailored specifically to running and debugging LISP, and it still hasn’t (really) caught on (yet).

Yes, I used the Lisp Machines back in the early 80's at MIT, absolutely wonderful, Lisp everywhere, and it was all integrated with a *real* editor (Emacs!), that was written in Lisp as well (so very very easy to customize / extend).

Way ahead of its time (or everything else was way behind)

 

That said, I think the Clojure community provides a useful example for how to approach the editor/IDE debate. All the early Clojure developers used emacs, and much of the early community was either on emacs or vim (yes, there were a few of us). In the intervening 7 or so years, though, as new developers who were familiar with other IDEs entered the community, they began projects to develop plugins for their IDE of choice. As such, Clojure now has first-rate plugins for both Eclipse and IntelliJ.

It was really only later that projects were started to build “true” Clojure IDEs, and still I don’t think any of these surpass (or even really approach) the utility of the IDE plugins (the three IDEs of which I’m aware are: LightTable, NightCode, and clooj).

One important element that allowed much of this for Clojure was the early development of nREPL, the network-enabled REPL. With this, all editors/IDE plugins stand on equal footing with access to the REPL. I noticed in the code to REPL.jl there’s a function `start_repl_server`, but it doesn’t seem to be used anywhere.

If I had to pick someplace to focus effort on improving tooling for Julia in general, I’d look at improving/adding a network interface to the REPL.

I thought Keno already had something like that?  (if it he doesn't already, I'm sure he could do it over the weekend, procrastinating a bit more on his degree!)

Scott

[Tamas Papp]

On Mon, Sep 14 2015, Joshua Ballanco <jbal...@gmail.com> wrote:

> It was really only later that projects were started to build “true” Clojure IDEs, and still I don’t think any of these surpass (or even really approach) the utility of the IDE plugins (the three IDEs of which I’m aware are: LightTable, NightCode, and clooj).
>
> One important element that allowed much of this for Clojure was the early development of nREPL, the network-enabled REPL. With this, all editors/IDE plugins stand on equal footing with access to the REPL. I noticed in the code to REPL.jl there’s a function `start_repl_server`, but it doesn’t seem to be used anywhere.
>
> If I had to pick someplace to focus effort on improving tooling for Julia in general, I’d look at improving/adding a network interface to the REPL.

I very much agree. Currently the Emacs interface uses ESS for Julia,
which is not well-adapted to Julia for historical reasons. Having
something like Swank or nREPL would make things much easier
(non-blocking evaluation, integrated introspection, debugging, etc).

Best,

Tamas

[Sheehan Olver]

Are there any open source languages with a "good" native IDE?

I think IDEs are probably too painful to develop unless paid to do so..

[J Luis]

I'm have many years of experience with Matlab and find its IDE a can't-work-without-it tool. When one experiments its debugger the reason becomes obvious.

Do you claim that Fortran, C and Perl never achieved success until someone wrote an IDE with a built-in debugger? ... Yeah, I know that's not what you want to say. Please understand that even if you find an IDE indispensable for Matlab, that doesn't make IDEs indispensable for all people for all languages. The fair thing to say about IDEs is that they are a really good idea to have because there are people who really really want them.

Daniel

 
You have to admit that it's not fair to do such comparisons for the simple fact that when those languages started (and long long time after) IDEs like we are talking simply did not exist. Not that they do, you can't live without them. I do but with pain and let just don't forget that we are talking of general acceptance and not only the "Carnival of hackers".

I've seen this discussion some here ago in the Octave mailing list. See how much it was adopted (rather poorly in my view), specially on Windows.

Joaquim

[Scott Jones]

On Monday, September 14, 2015 at 8:56:31 AM UTC-4, J Luis wrote:

I'm have many years of experience with Matlab and find its IDE a can't-work-without-it tool. When one experiments its debugger the reason becomes obvious.

Do you claim that Fortran, C and Perl never achieved success until someone wrote an IDE with a built-in debugger? ... Yeah, I know that's not what you want to say. Please understand that even if you find an IDE indispensable for Matlab, that doesn't make IDEs indispensable for all people for all languages. The fair thing to say about IDEs is that they are a really good idea to have because there are people who really really want them.

Daniel

 
You have to admit that it's not fair to do such comparisons for the simple fact that when those languages started (and long long time after) IDEs like we are talking simply did not exist. Not that they do, you can't live without them. I do but with pain and let just don't forget that we are talking of general acceptance and not only the "Carnival of hackers".

Did not exist?  The most *totally* integrated development environment I've used in my life was the Lisp Machine, and that was 35 years ago, long before many of the languages on that list.

Can IDEs be good, and very useful?  Yes (but to really be productive, you need to have a full featured editor integrated also).  I'm hopeful about things like Atom and Nuclide (which is built on top of Atom).

Keno Fischer is adding the debugger support that's been lacking in Julia (Gallium.jl), although that's still at the alpha stage (hats off to both Keno and Blackrock for funding him on the project)

[Michael Francis]

I'd take the neutral ground here  - for a language like Julia there is a continuum of users ranging from people happy to live in vim/emacs, through Developer IDEs to people looking for a 'Workbench'. This is dissimilar from many of the languages being argued about in this thread (C, Java, Lisp ... ), most never get to the point of the Workbench. I don't see it so much as a 'beginner programmer' as a person looking for a place to do their work, this is the beauty of the Workbench.

I do think Julia would benefit from a best in class Developer IDE, for most traditional languages the Developer IDE is the high point - Intelij products take the chore of writing Java and make it bearable. The integration with the debugger,  the package system and the ability to perform large scale refactors of code is stunning. It isn't essential for the success of the language but it helps.

For Julia to thrive in the 'I have a job to do which isn't programming' community Julia is going to something closer to a Workbench ( R Studio, Matlab like) - Juno et al have attempted to blur the line towards a Workbench quite successfully. The notebook is ok, but not a perfect environment. I suspect this is the area where innovation can really happen and I see the glimmers of that already.

Just my 2c

On Monday, September 14, 2015 at 8:56:31 AM UTC-4, J Luis wrote:

[Andrei]

To continue Michael's answer, I think it would be nice to collect list of most important features that existing editors for Julia still lack and think out what can be improved. So far I've seen following features: 

 * integrated debugger -- currently work in progress (Gallium.jl), so it may change soon

 * better integration with REPL -- AFAIK, Emacs is the only editor that has this integration (via ESS mode) so far

 * code refactoring 

 * built-in documentation (in addition to Julia's own help system, I suppose)

 * built-in plots

This doesn't look like a huge list. If this is what is needed for non-programmers to work with Julia without pain, I'd say we have a good chances to get it. 

[Tom Breloff]

And to continue Andrei's answer... all of these things need to work well in their own right, and that's what the community should be focused on.  IDEs will happen naturally, but they should be composed of things that exist in isolation (IMO).

[jonatha...@alumni.epfl.ch]

Instead of complaining like I usually do I've been making a rough prototype of IDE for Julia in Julia, and it seems to me that in the long term

it's the right idea. Using existing editors allow to quickly take advantage of their features, but past that it's really hard to integrate more advanced tools

tailored specifically for the language. 

I also find the idea of having a Julia IDE written in Julia very attractive, besides the other advantages like ease of modification and the few dependencies needed.

http://i.imgur.com/GHA37Ds.png

[Isaiah Norton]

If I had to pick someplace to focus effort on improving tooling for Julia in general, I’d look at improving/adding a network interface to the REPL.

If anyone is interested in working on this, one approach is to implement the server side of the Jupyter protocol in pure Julia. So far the network-integrated-REPL role has been filled by the Jupyter/IPython protocol, benefiting from the years of design iteration there. In many cases this also leverages a broader community of developers who are interested in (I)Python support for a particular editor. The main (and very moderate) disadvantage is the Python dependency, but that could be eliminated.

[Michael Francis]

I agree - each part should work well (and as far as possible be in Julia). We should keep the eye on compatibility though, for example many IDEs assume the gdb-mi interface for the debugger. If we go our own way in Julia it will make it much harder to adopt. 

[Daniel Carrera]

On 14 September 2015 at 14:54, Sheehan Olver <dlfiv...@gmail.com> wrote:

Are there any open source languages with a "good" native IDE?

I think IDEs are probably too painful to develop unless paid to do so..

There are many good IDEs for C and C++; and some for Fortran, Python and Perl. But al of them took a long time to develop and appeared fairly late.

Cheers,

Daniel.

[Uwe Fechner]

Well, Gambas for example:
https://en.wikipedia.org/wiki/Gambas

[Daniel Carrera]

On 14 September 2015 at 14:56, J Luis <jmf...@gmail.com> wrote:

You have to admit that it's not fair to do such comparisons for the simple fact that when those languages started (and long long time after) IDEs like we are talking simply did not exist. Not that they do, you can't live without them.

You can definitely live without them. Why are they suddenly so critical? I have been programming for 20 years and I do not use IDEs, nor do I know (personally) any other programmer who uses an IDE. The closest contact I have with IDEs is knowing that my wife learned Visual Studio in school.

 

I've seen this discussion some here ago in the Octave mailing list. See how much it was adopted (rather poorly in my view), specially on Windows.

That is completely irrelevant. There are excellent reasons why Octave would not be adopted. It is almost a Matlab clone, but it cannot run a lot of Matlab programs and it is terribly slow. Octave now has a nice IDE, which is great, but to my knowledge, adoption of Octave has not yet sky-rocketed. But look, I am not saying that IDEs are useless. I am merely disputing the trivially falsifiable claim that the success of a programming language "depends" on an IDE. That is simply not true. An IDE is helpful, and other things are helpful.

Daniel.

[Daniel Carrera]

On 14 September 2015 at 15:44, Andrei <faithle...@gmail.com> wrote:

To continue Michael's answer, I think it would be nice to collect list of most important features that existing editors for Julia still lack and think out what can be improved. So far I've seen following features: 

 * integrated debugger -- currently work in progress (Gallium.jl), so it may change soon

 * better integration with REPL -- AFAIK, Emacs is the only editor that has this integration (via ESS mode) so far

 * code refactoring 

 * built-in documentation (in addition to Julia's own help system, I suppose)

 * built-in plots

This doesn't look like a huge list. If this is what is needed for non-programmers to work with Julia without pain, I'd say we have a good chances to get it. 

The list looks sensible. Can you clarify what you mean by code refactoring? How do you think we should do built-in plots when we currently suffer from too much diversity in plotting APIs? Gadfly is popular, but I don't like it and it is immature, so I use PyPlot.

Chers,

Daniel. 

[Daniel Carrera]

I agree with Tom. For example, KDevelop and QtDevelop are apparently excellent IDEs with great debuggers, but they both use plain old gdb in the background. I suspect that some of the people asking for an IDE are really looking for a good debugger and easy access to documentation.

[Daniel Carrera]

Good work. Which toolkit are you using to develop this? Last week I was looking at GUI toolkits for Julia and I think that Gtk+ is the most developed. I think that an IDE written in Julia is the right goal for the long term.

Is the code published somewhere? Can I have a look?

Cheers,

Daniel.

[Tom Breloff]

we currently suffer from too much diversity in plotting APIs

Working on it, Daniel.  ;)

[Daniel Carrera]

Ooops, stupid question. I see that the screenshot actually shows the source code. You are using Gtk (yay!).

There is a project called GtkSourceView that extends Gtk+ with a source editor with support for syntax highlighting, line numbers, and so on:

https://wiki.gnome.org/Projects/GtkSourceView/

[Isaiah Norton]

There is a project called GtkSourceView that extends Gtk+ with a source editor 

See also https://github.com/tknopp/Julietta.jl

[Daniel Carrera]

I just had a look at Julietta:

"For code conributions: As the original author of this work I want to keep right to spin off a commercial version of this software."

:-(

Daniel.

[Daniel Carrera]

On 14 September 2015 at 17:16, Isaiah Norton <isaiah...@gmail.com> wrote:

There is a project called GtkSourceView that extends Gtk+ with a source editor 

See also https://github.com/tknopp/Julietta.jl

I think Julietta is exactly the right idea, but it looks abandoned (no wok in a year) and I don't like that the author says he wants to be able to make a commercial version of the product while everyone else has to use the super-restrictive GPLv3. The source for Julietta is only 1753 lines. It shouldn't be too hard to catch up to it.

Cheers,

Daniel.

 

[Tim Holy]

Nice. Are you familiar with Julietta?

https://github.com/tknopp/Julietta.jl

--Tim

[Andrei]

The list looks sensible. Can you clarify what you mean by code refactoring? How do you think we should do built-in plots when we currently suffer from too much diversity in plotting APIs? Gadfly is popular, but I don't like it and it is immature, so I use PyPlot.

Just to clarify, this is not my wishlist (I'm pretty much satisfied with Emacs + ESS already), but rather a list of things I've heard from other people wanting "real IDE". 

Can you clarify what you mean by code refactoring?

Massive renaming mostly. I often hear it from Java programmers, especially involved in enterprise-level projects (hundreds of people, thousands of lines of code, a lot of legacy, etc). I can't say I use it frequently in own practice, but in rare cases I do IDE really helps. 

(in non-ide-powered projects I normally use grep, though)

How do you think we should do built-in plots when we currently suffer from too much diversity in plotting APIs?

I'd say, we should either unify them (e.g. see Plots.jl), or just choose one to build in IDE. Both options are not ready yet, but we are moving in that direction. 

[Tom Breloff]

Agreed about the license... I'd prefer to have a community-supported IDE with MIT license.

[Matt Bauman]

On Monday, September 14, 2015 at 9:44:07 AM UTC-4, Andrei Zh wrote:

To continue Michael's answer, I think it would be nice to collect list of most important features that existing editors for Julia still lack and think out what can be improved. So far I've seen following features: 

 * integrated debugger -- currently work in progress (Gallium.jl), so it may change soon

 * better integration with REPL -- AFAIK, Emacs is the only editor that has this integration (via ESS mode) so far

 * code refactoring 

 * built-in documentation (in addition to Julia's own help system, I suppose)

 * built-in plots

This doesn't look like a huge list. If this is what is needed for non-programmers to work with Julia without pain, I'd say we have a good chances to get it. 

If you look carefully, you'll see work progressing on each and every one of these projects, in some cases very rapidly.

* The new 0.4 documentation allows all sorts of access and search features with extremely little amounts of code.

* Refactoring: https://github.com/jakebolewski/JuliaParser.jl/issues/22

* UI: There are two predominant threads of work, one in GTK and one in Blink (JS-enabled web-like DOM windows).  Take a look at the new Immerse.jl and https://github.com/JunoLab

* There's also interesting work in terminals themselves, making the REPL more full-featured there.  Take a look at TerminalExtensions.jl for iTerm2 on OS X: you can display arbitrary images (like plots) inline and capture backtraces in order to open an editor directly to the error with a double-click.

It's only a matter of time before more of these things come together.  I think it's really exciting!

[Sheehan Olver]

Could this all be done as plug-ins to Atom?  Sounds easier than developing an IDE from scratch. 

[jonatha...@alumni.epfl.ch]

GtkSourceView seems nice but I never managed to get it work on windows. The wrapper might be a bit outdated too.

[jonatha...@alumni.epfl.ch]

Gtk, the code isn't published but it's very similar to Julietta:

https://github.com/tknopp/Julietta.jl

[Daniel Carrera]

Last night I started experimenting with Gtk, and started making a sketch of what a Julia IDE might look like. In the process I am writing down a list of things that are probably needed before a Julia IDE

 getting a list of things that probably need to exist before a Julia IDE can be completed. This is what I have so far:

1) A Julia package for the GNOME Docking Library

I think most people expect that an IDE has docking 

Despite the name, it does not depend on any GNOME libraries, only Gtk. This is what Anjuta and MonoDevelop use to get docking windows. I think most people expect to be able to move things around in an IDE.

https://developer.gnome.org/gdl/

2)

[Daniel Carrera]

Crap... It looks like I accidentally hit "send" before my email was finished. Anyway, here it goes again:

Last night I started experimenting with Gtk, and started making a sketch of what a Julia IDE might look like. In the process I am writing down a list of things that are probably needed before a Julia IDE can be completed. This is what I have so far:

1) A Julia package for the GNOME Docking Library

Despite the name, it does not depend on any GNOME libraries, only Gtk. This is what Anjuta and MonoDevelop use to get docking windows. I think most people expect to be able to move things around in an IDE.

https://developer.gnome.org/gdl/

2) A Julia package for WebKitGtk

http://webkitgtk.org/

This would be useful to make a documentation browser.

3) Get GtkSourceView working on Windows, or get a Julia package for Scintilla.

Obviously needed to get a good text editor.

While we wait for these things to develop, one can move forward with a sketch using GtkBox instead of GDL, and GtkNotebook instead of GtkSourceView.

Cheers,

Daniel.

[Daniel Carrera]

Hi everyone,

I just finished putting together a basic mockup of what a Julia IDE might look like. I'm calling it JuliaBox:

Source: https://github.com/dcarrera/JuliaBox

Screenshot: https://github.com/dcarrera/JuliaBox/blob/master/screenshots/screenshot-01.png

This is literally just a shell and it doesn't *DO* anything yet. But I think this is a good way to start thinking about what it would take to write an IDE for Julia in Julia. The idea is that as we try to implement concrete features, we'll get a better idea of what are the missing pieces.

If you want write access to the Git repo just let me know. I know I'm not the best coder here, and I'd love to see a group effort going.

If you look at the README file, you'll see my current thoughts on what components are missing, and where we might get them.

Cheers,

Daniel.

[Sisyphuss]

Isn't JuliaBox a registered trade mark?

[David Anthoff]

Whether it is registered or not, please use a different name, given that this https://juliabox.org/ exists and is very much supported/run by the official julia core team. No need to cause naming confusion here.

 

Cheers,

David

[Daniel Carrera]

Ooops. I didn't mean to do that. I was trying to pick a generic non-committal name. Ok, I have temporarily renamed it "Julia IDE" which is a bit pretentious for a 200-line script that doesn't do anything, but the name does not seem to be in use:

https://github.com/dcarrera/JuliaIDE

If someone actually writes a Julia IDE and wants the name, I will be happy to remove this repository.

Cheers,

Daniel.

[Daniel Carrera]

Hi all,

So... I spent more time looking into how to write a Julia IDE... and I'm not sure it makes sense to write one.

I have been investigating the features of Scintilla and GtkSourceView. These are the most obvious components we could use to make the source code editor. But neither one has enough features that I would be willing to use it instead of Atom. GtkSourceView doesn't have code folding, and the issue has been pending for over 11 years and nobody is working on it:

https://bugzilla.gnome.org/show_bug.cgi?id=134610

Scintilla is better in that it does have code folding. But it does not have a minimap, and the recently added multiple-cursor feature does not behave the way I want when you press Return (it gives you only one new line at the end).

I realize that these are not show-stoppers, but I personally I'm not likely to see a lot of value in a Julia IDE based on Scintilla or GtkSourceView. Maybe Juno is already taking the right approach in extending Atom. Maybe it's possible to stick Atom inside an IDE like you do with Scintilla.

Is there any good reason why we should prefer that a Julia IDE be written in Julia? Just asking.

Cheers,

Daniel.

[Tim Holy]

If the IDE is supposed to include "docked" plotting, then (at least currently)
you're going to get a big loss of functionality if you're using a browser
compared to what's now possible in Gtk. That said, I don't see any reason that
you really need docked plotting.

Best,
--Tim

[Daniel Carrera]

Hi Tim,

I don't know what docked plotting is, but I suspect I don't want it. I like plots in free-floating windows. When I talked about docking I was referring to other parts of the UI. Things like the editor, the REPL, the variable browser, and online help. Think of this screenshot of Spyder:

https://en.wikipedia.org/wiki/Spyder_(software)#/media/File:Spyder-windows-screenshot.png

In Spyder those components can be moved around. Maybe I'm wrong about what people expect (I don't use IDEs). But I think that this is one of the features that IDEs typicaly have.

[Michael Francis]

@Tim  - can you point me at the gap between Gtk and browser based, I'm interested as I've spent a fair amount of time in d3/Escher recently and with the correct

wrapping seems to do most of what I was looking for. We can take this to a different thread. 

[Tim Holy]

Low-latency callbacks are the main issue, AFAICT. (Assuming you'd rather write
your callbacks in julia than javascript.)

--Tim

[Tim Holy]

Should have added: zero-copy ways of getting big piles of data to the browser.
With Gtk, you have direct in-memory access to the display; when e.g. Gadfly
wants to display in the browser, it writes an svg file and asks the browser to
parse it.

That said, once you get the data into the browser, modern browsers are
impressively fast at rendering.

--Tim

On Wednesday, September 16, 2015 07:28:57 AM Michael Francis wrote:

[STAR0SS]

I don't think docking is a big deal, at least it would be relatively easy to have a basic configurable layout. 

Multiple cursors might be feasible. You need an array of cursors (integers basically), and when the user does an action you can loop through them and apply the action at each position. You can display the cursors with tags. Things like selection might be a bit tricky though.

Code folding might be more difficult. It seems it's not super easy (or event possible?) to draw on top of a widget in general. 

[Michael Francis]

Aside from the oddities of websockets I'm not seeing much in the way of an issue. Though I'm generating custom events from d3 which get get sent back to Julia. Major interactions are defined in a declarative form in JSON ( and yes are handled by JavaScript ) but where events are relevant to Julia I propagate events all the way back.

[Stefan Karpinski]

In theory both fast native callbacks and fast direct data transfer could be done in Chromium. You could allow JavaScript to directly call ccallable functions, which Julia can generate via cfunction; you can present numeric data as typed JavaScript arrays sharing memory with Julia arrays. I'm not sure how hard these would be to implement.

[Tim Holy]

It would be great to see a demo of how well this works the reproduce the kind
of performance you can get with, e.g., ImageView (which in reality is no speed
demon, yet):

using ImageView
include(Pkg.dir("ImageView", "test", "test4d.jl"))
ImageView.view(img)

Now drag the sliders and watch how responsively the display updates. Without
some kind of direct ccall interface with javascript, you're going to have to
ship the data for each frame update.

Or, canvas-drawing like in the lasso selection with Immerse---each mouse drag
generates an event. I imagine that one could probably be handled reasonably
well over a pipe, because there isn't a lot of data.

--Tim

[Tim Holy]

On Wednesday, September 16, 2015 11:19:58 AM Stefan Karpinski wrote:
> In theory both fast native callbacks and fast direct data transfer could be
> done in Chromium. You could allow JavaScript to directly call ccallable
> functions, which Julia can generate via cfunction; you can present numeric
> data as typed JavaScript arrays sharing memory with Julia arrays. I'm not
> sure how hard these would be to implement.

I've been asking/hoping (for something like 2yrs) that those who advocate a
browser-based plotting-GUI for julia would do this. Would be great to find out
if it would work in a way that can satisfy all parties. Until that happens,
Gtk/GLFW will continue to seem like a firmer and more capable foundation for
our plotting infrastructure, and where we should be putting our efforts.

That doesn't mean the IDE couldn't be browser-based, as long as we don't mind
not having docked windows. Personally, I don't mind a bit.

--Tim