4 ms·

Interesting points, the matrix edge cases seem a bit weird. I program in Matlab all the time, but I basically can't imagine leaving it for Julia no matter how g

Interesting points, the matrix edge cases seem a bit weird. I program in Matlab all the time, but I basically can't imagine leaving it for Julia no matter how good the language is. The main reason being that the single most valuable part of Matlab, for me, is its amazing IDE. I've seen a lot of people caught up in debates about languages, obsessing about this feature or that one but it is much more rare to see people argue about the IDE, as if it was merely an afterthought. I find this article guilty of the same crime. The author also dismisses Matlab because a statement with no semicolon prints its result (something I take advantage of often) and other small issues , but there is no mention of everything else you lose when going to Octave. Really? Maybe I'm spoiled, but I now can't live without seeing all my variables and their size, types and values listed, my ability to quickly execute blocks of code at random, jump around all files, super fast and flexible visualizations, great debugger, profiler, docs at fingertips, etc etc etc all integrated into a single package that just works out of the box. It's development on steroids and I've never seen anything that lets me code faster. I feel sorry for people who code in vim.

etrain 15y ago
For a language as young as Julia, I'm really surprised that the author focused as much as he did on the Web REPL and development environment. These things can be added later, and I think at this point in the language lifecycle, the team behind it really needs to be focused on getting the fundamentals right (which they seem to be). For a good example of IDE as afterthought, look at RStudio (http://www.rstudio.org http://www.rstudio.org) - note that this came around after a decade of other, bad, GUIs for R. I actually see the matrix edge cases as pretty interesting - while they don't reflect the way I'd try to code things, they probably reflect the way someone codes things, and I imagine that their behavior is either due to a nasty implementation detail or oversight by the Julia core team. Either way, it's good to hash this stuff out now.
simonster 15y ago
I would leave MATLAB's IDE in a heartbeat for something that ran in the browser. In my experience, MATLAB's IDE is a terrible piece of crap. It's slow. It's particularly slow when accessed via X11 forwarding, even from the same network. It's memory-hungry. It crashes randomly on OS X (and semi-randomly on Linux). The plots aren't anti-aliased. If you open too many plots, it runs out of Java heap space and crashes. The only thing it has going for it is the tight integration with mlint, but even that's kinda stupid because they could have just written a better optimizing compiler.
- dkarl 15y ago
  Why the browser? In my experience, editing text in a browser is pretty horrible. It doesn't matter for banging out HN comments or emails, but for code, I don't think I could put up with it. It's bad enough having to use the text editors in Eclipse and IntelliJ; regressing all the way to browser text boxes would be a tragedy. Is it for the sake of having persistent server sessions that don't go away when you close your client? That could easily be done, and has been done, without resorting to using a web browser. I admit that Emacs with Slime is not a paragon of simplicity and reliability, but I suspect it would be easier to recreate the convenience and polish of a web UI in an independent client (possibly based on a hacked version of Chrome or Firefox, if you really, really like your browser) than it would be to turn a text box into a decent code editor.
  - simonster 15y ago
    My main reason for the browser is that it makes seamless to execute code on a remote machine. Text-based interfaces are not very useful because you can't see plots without saving them and copying them. X11 forwarding is slow. My current solution is NX, but it's not optimal, since I hate NX 4 and NX 3.5 doesn't run on Lion. Cloud9 IDE is already a decent browser-based code editor. It's already better than the MATLAB editor in just about every way but integration with the interpreter. Using a browser-based IDE will solve both the cross-platform UI issue and the remote access issue.

etrain 15y ago

For a language as young as Julia, I'm really surprised that the author focused as much as he did on the Web REPL and development environment. These things can be added later, and I think at this point in the language lifecycle, the team behind it really needs to be focused on getting the fundamentals right (which they seem to be). For a good example of IDE as afterthought, look at RStudio (http://www.rstudio.org http://www.rstudio.org) - note that this came around after a decade of other, bad, GUIs for R. I actually see the matrix edge cases as pretty interesting - while they don't reflect the way I'd try to code things, they probably reflect the way someone codes things, and I imagine that their behavior is either due to a nasty implementation detail or oversight by the Julia core team. Either way, it's good to hash this stuff out now.

simonster 15y ago

I would leave MATLAB's IDE in a heartbeat for something that ran in the browser. In my experience, MATLAB's IDE is a terrible piece of crap. It's slow. It's particularly slow when accessed via X11 forwarding, even from the same network. It's memory-hungry. It crashes randomly on OS X (and semi-randomly on Linux). The plots aren't anti-aliased. If you open too many plots, it runs out of Java heap space and crashes. The only thing it has going for it is the tight integration with mlint, but even that's kinda stupid because they could have just written a better optimizing compiler.

dkarl 15y ago
Why the browser? In my experience, editing text in a browser is pretty horrible. It doesn't matter for banging out HN comments or emails, but for code, I don't think I could put up with it. It's bad enough having to use the text editors in Eclipse and IntelliJ; regressing all the way to browser text boxes would be a tragedy. Is it for the sake of having persistent server sessions that don't go away when you close your client? That could easily be done, and has been done, without resorting to using a web browser. I admit that Emacs with Slime is not a paragon of simplicity and reliability, but I suspect it would be easier to recreate the convenience and polish of a web UI in an independent client (possibly based on a hacked version of Chrome or Firefox, if you really, really like your browser) than it would be to turn a text box into a decent code editor.
- simonster 15y ago
  My main reason for the browser is that it makes seamless to execute code on a remote machine. Text-based interfaces are not very useful because you can't see plots without saving them and copying them. X11 forwarding is slow. My current solution is NX, but it's not optimal, since I hate NX 4 and NX 3.5 doesn't run on Lion. Cloud9 IDE is already a decent browser-based code editor. It's already better than the MATLAB editor in just about every way but integration with the interpreter. Using a browser-based IDE will solve both the cross-platform UI issue and the remote access issue.