Timeline for Why is MATLAB so common in Neuroscience?
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 25, 2014 at 13:29 | comment | added | Louis Thibault | @DylanRichardMuir, "But neither can any language with a large developer base." I think this is our point of disagreement. The good thing here is that time will tell =) In any case, Matlab certainly isn't going to disappear overnight and it's so extremely useful in some cases that I still (begrudgingly) use it myself for certain things. | |
| Sep 25, 2014 at 13:12 | comment | added | Dylan Richard Muir | @blz See my comment above about language evolution. Matlab's core language is evolving. It can't evolve very quickly, for reasons of not obsoleting everyone's code. But neither can any language with a large developer base. And the ugliness of Matlab is clearly not sufficient to drive existing developers away en masse. I think it will be a process of slow attrition, as new developers choose to start with a more modern (or post-modern i.e Perl :) ) language. | |
| Sep 25, 2014 at 13:08 | comment | added | Louis Thibault | @DylanRichardMuir, Indeed, but this doesn't even begin to touch on core language development, which is what I'm talking about. It's also not unique to Matlab (and neither is the writing of C/++ extensions). Again, Matlab has some very strong points but its closed-source development is a decidedly very weak point, even if you're not directly involved with improving the language (or particularly aware of the problem). [With the shift in tone, I feel the need to once again insist that I mean no disrespect, and that I'm finding this debate quite enjoyable :) ] | |
| Sep 25, 2014 at 13:05 | comment | added | Dylan Richard Muir | @blz The Matlab file exchange is open source and pretty extensive. And I think you'll have a hard time arguing that Matlab is not very extensible. | |
| Sep 25, 2014 at 12:58 | comment | added | Louis Thibault | @DylanRichardMuir, again I think I may have been unclear (character limits don't help!). I don't mean that open-source software is good because you personally can develop the language. I mean that small groups of researchers can make modifications to the core language or leverage internal implementation details to produce domain-specific code that wouldn't be given the time of day by a for-profit tool. The open-source issue is therefore relevant for researchers -- it's about having a responsive community. Matlab doesn't have this, and that's why it's slowly and steadily losing momentum. | |
| Sep 25, 2014 at 12:49 | comment | added | Dylan Richard Muir | @blz For me and for most programmers, open source vs closed source is utterly irrelevant. I don't want to spend time developing the language! I want a tool that works. Whether the language developers are part of a paid company or a loose-knit cadre of open-source programmers doesn't make much difference to me. Edit: I mean in a practical programming sense. Matlab licenses are expensive, which sucks. | |
| Sep 25, 2014 at 12:47 | comment | added | Louis Thibault | @DylanRichardMuir, "the question was not about why is Matlab better or worse than Python, the question was about its prevalence in neuroscience". I completely agree. I think this is the point that was raised about inertia. There's certainly a lot of value in having a system that's known to work -- perhaps I got a bit proselytic, in which case I do apologize! | |
| Sep 25, 2014 at 12:46 | comment | added | Louis Thibault | "maybe Anaconda does a good job (haven't tried it)". You should, if the only thing holding you back from Python is the difficulty in deployment! Again, though, I eagerly concede that there are some times where Matlab is the better, more sensible solution. I simply contend that these are corner-cases and no longer a general rule. =) | |
| Sep 25, 2014 at 12:45 | comment | added | Dylan Richard Muir | @blz In any case, the question was not about why is Matlab better or worse than Python, the question was about its prevalence in neuroscience. Life is a series of decisions about efficiency: What's the fastest way to get some code written that maybe myself and others in the lab can use? Switching platforms costs a lot, and researchers have little time to waste anyway. Starting from scratch in Python might be worthwhile. Switching over with a huge body of code to port probably isn't. | |
| Sep 25, 2014 at 12:44 | comment | added | Louis Thibault | @DylanRichardMuir, Agreed, but I think you're still missing the point. My point (and I suspect jona's as well) is that Matlab has two problems. (1) It's closed-source nature means that development occurs a the discretion of it's core developers, which is incurs extra development lag while offering no tangible advantage. (2) Because it's an antiquated language, we usually find poor implementations (c.f.: OOP) or worse, intentionally crippled implementations in an attempt to sell licenses (c.f. parallelization). What Matlab has now is what other languages had 5 years ago, but crappier. | |
| Sep 25, 2014 at 12:42 | comment | added | Dylan Richard Muir | @blz I'm not going to engage with the deployment debate. I have had to get Python plus some set of packages up and running on several systems over the last several years, and it's been excruciating every time. It's getting easier, but I think you will have a hard time convincing anybody that Python is as easy to deploy right now. Like I said, maybe Anaconda does a good job (haven't tried it), but I have tried the Enthought distributions previously which promised to take care of everything. They work reasonably well, but can't possibly fix mutual issues between theano/numpy / blas, for example. | |
| Sep 25, 2014 at 12:36 | comment | added | Dylan Richard Muir | @blz Jona's complaint was that Matlab gets these things after other languages. Yes. But it has them now. Matlab is evolving as a language; I don't know how you'd compare "speed of evolution" between languages, but every language evolves slowly or you very quickly throw out the entire body of existing code... My "argument" is that if two languages have the same features now, does it matter which one had them first? | |
| Sep 25, 2014 at 10:01 | comment | added | Louis Thibault | @DylanRichardMuir, which package incompatibilities are you referring to? Anaconda really does solve deployment issue, at least to the standard we've come to expect from Matlab. There's really no "tangled web of requirements" and there never was. The previous packaging woes came from something entirely different. Matlab also has it's fair share of cross-platform issues (cough cough psychtoolbox). For clarity: I don't mean to imply that these are deal-breakers for Matlab, and similarly, they aren't for Python. These arguments strike me as a rephrasing of "the devil I know..." :) | |
| Sep 25, 2014 at 9:51 | comment | added | Louis Thibault | @DylanRichardMuir, Concerning your response to jona's 5th point: Matlab's heritage is not an excuse. The complaint is that Matlab is a poorly-designed and slow-to-evolve language. Of course there are reasons for this, but it doesn't change the end result! :) Your argument is akin to driving a Ford Model T and exclaiming "Of course my car sucks! It's from the 1900's!" The issue isn't that of machine time, but that of developer time. That's what matters in the overwhelming majority of cases, and it's why nobody uses Fortran anymore. [Note: no disrespect intended! I'm enjoying the arg!] | |
| Sep 24, 2014 at 21:36 | history | edited | Dylan Richard Muir | CC BY-SA 3.0 |
added 133 characters in body
|
| Sep 24, 2014 at 21:13 | comment | added | Dylan Richard Muir | Point 5. So? Like I said, Matlab comes from the era of Fortran. 6. The benchmarks I've seen (Python vs Matlab: wiki.scipy.org/PerformancePython; R vs Matlab: sciviews.org/benchmark but I can't find a more recent benchmark) don't show a huge difference. They should all be using low-level optimised BLAS routines anyway. Besides, if you want blinding speed you should be writing everything in C. Which is not going to happen in Neuroscience. | |
| Sep 24, 2014 at 21:12 | comment | added | Dylan Richard Muir | Sorry, I don't agree with free == easy to deploy. Matlab is trivial to deploy: run an installer, everything just works. Anaconda aside, Python has been miserable to deploy at least until very recently. I don't see how Anaconda can possibly resolve the issue Python has with Python package incompatibilities and the tangled web of requirements. R seems pretty straightforward to deploy, but I haven't used it much. Numpy is the matrix-operation Python add-in I referred to. The core language of Python is not vectorised. | |
| Sep 24, 2014 at 20:46 | comment | added | jona | As another extensive MATLAB user, I don't agree with many of your claims. Just some examples: 1, Python and R, being Open Source and free, are practically easier to deploy. 2, neither R nor Python require any of these. 3, RStudio is arguably better than the MATLAB IDE (which I personally never use). 4, The appropriate comparison is Numpy, which offers all the vectorization MATLAB does; R also vectorizes easily. 5, MATLAB tends to get these (e.g., formula syntax, DataFrame formats) after other languages. 6, MATLAB is slower than R and Python in many benchmarks. | |
| Sep 24, 2014 at 15:57 | comment | added | Louis Thibault | Absence of namespace is is generally considered to be a Very Bad Thing, and forgoing these (small) hurdles is only a win in the most near-sighted sense; it's akin to saying a car without seatbelts is better for novice drivers because remembering to buckle up is a pain in the ass. I would also have placed the OOP support under the heading of "Things Matlab does badly" ;) Lastly, the Anaconda distributions have made it so that Python Just Works, so that is by and large a problem of the past. (In all fairness though, I agree with your other points!) | |
| Sep 24, 2014 at 14:37 | history | answered | Dylan Richard Muir | CC BY-SA 3.0 |