Do you mean that stating it could piss people off, or that the fact itself would do that? I would be pretty surprised if anyone were pissed off either way.
4 Likes
I think this is the key point. When demand is pretty inelastic, the price is⌠whatever the market can bear.
Assuming I am an insider⌠I simply donât care that much about numbers of users. I care about contributors to the language or the package ecosystem, because thatâs what is going to determine the pace at which Julia develops. I care about having a high-quality, convenient language that I like.
Since commercial products have to make money from licenses, they have to pay a close attention to paying customers. For FOSS projects, it can be a red herring, or worse â eg a sudden growth of the userbase could just siphon off scarce resources for (free) support.
8 Likes
I suspect the reasons are very similar to why corporations use MS Office and not Libre Office or why they donât update immediately to the latest version of Windows (or use Linux).
Corporate IT departments have very clear priorities and those mostly revolve around stability and not upsetting production. They tend to avoid open source software for many of the reasons that we love it, like quick development and rapid updates.
If a dependency changes and breaks your program, you may be able to wait for a fix, or roll back to an old version without much being lost. In production any updates have to be thoroughly tested before roll-out so as to ensure no interruptions to production. While that is being done, a new update could already be available. This is not a scenario that your average IT department likes.
Matlab is competing with two advantages: a large sunk investment (many years of development have gone into proprietary code development) and stability. Management want to protect the former and IT support like the latter.
3 Likes
By analogy, the gas prices in Germany at gas stations close to the border are higher and not lower than within the country - even if the gas prices on the other side of the border are much lower.
I think it is important to note that Matlab is a product (subject more to business/economical constraints) while Julia is a free generic programming language (subject to more abstract sociological, technological and philosophical constraints).
Matlab has a large user base because it has been around for a very long time and established a strong industrial (and academic) user base. Julia is a very new language (7 years is little compared to several tens of years for the established languages).
Mathworks will have a problem in a recessionary economical environment (in which Julia would most likely thrive).
1 Like
Proposed conspiracy theory: blame the next recession on the Julia community. 
4 Likes
Large numbers of high quality contributors come when (1) large enough fields âstandardizeâ on a particular tool, as has happened with matlab, python, stata, and R (in various fields and subfields), so researchers can assume anyone has access to the product and the basic knowledge to run their code; (2) the funding foundations finance large amounts of resources to âprofessionalizeâ an open-source product; and/or (3) big corporations contribute technology to the open-source projects because they can use it for themselves or their customers.
All of my listed (1), (2), or (3) above is tightly connected to popularity and the number of users. And popularity and users come from accessibility and convenience (which is why python has been so expansive). Think about the staggering amount of resources that the numpy/etc. have at their disposal building on top of a language ill-designed for numerics but convenient and intuitive for pretty much everything else.
Of course, if your goal is to have a language purely catered to experts and professional developers, that is fine, but it is inconsistent with a goal of maximizing high quality contributors.
But to bring it back to my main point:
True, but potentially irrelevant. Donât forget to consider that Matlab is able to command high prices because, in many ways, it is an excellent product that does exactly what its users want.
7 Likes
I am not sure about this. Eg look at JuliaDiffEq: I would say it is high-quality, but it is not a consequence of standardization, AFAIK was not financed with large bags of money, and is not primarily contributed to by big corporations.
IMO high-quality contributions happen when smart and motivated people find a tool/ecosystem they like working in. Everyone else jumping on the bandwagon follows later.
I think it can be said that Julia was created because people found existing tools inconvenient, and wanted something better.
We must have a very different picture of the Julia community. I am under the impression that most package authors are not professional developers (in the sense of getting paid for software), but work in an academic/research intensive industry setting. Software for them is just a means to an end, and they like to do it well because they found it saves time in the long run.
5 Likes
As one of the IO economists using Julia informally, Iâd emphasize that we probably donât know how much of Matlabâs current userbase/pricing equilibrium is due to high quality vs. long-term lock-in. If you have a bunch of âworkingâ code that spans many years, whether or not the product is âexcellentâ in the static sense might be irrelevant to your purchasing choices. Sure, we could move the goal posts and say todayâs Matlab is great because it runs code we wrote (and need to use) many years ago, but I think to most users that isnât quite the definition of an âexcellent productâ thats doing âexact whatâ they want/need. My guess is that plenty of Matlab users are at least somewhat aware of its limitations and are constantly irritated by the fact that they are stuck using itâŚ
2 Likes
Have you ever tried to convince a cost centre owner that you should move to a new language and then spend the next 6-12 months translating existing code to the new language instead of developing new code? Once you add up the cost of the billable hours needed to translate existing Matlab code, Julia is no longer free as far as management is concerned. It is, in fact, very expensive.
We could shift to Julia as our primary language simply because we do not have a lot of Matlab code lying around. There is a lot of stuff in R, which will probably never be translated, because no matter how much faster Julia runs, the cost of translating the code will never be justified. Other code that was translated was justified only because the speed benefit was make-or-break for the specific project - ~100x faster than the statically compiled version that we had, thanks to the fantastic package ecosystem in Julia.
This is not unique to Julia / Matlab or commercial / FOSS. We have had several attempts by process simulator vendors to get us to convert from the system we use. With a few hundred active users sitting around here, there are so many simulations in use that we would never be able to justify converting them all, nor can we abandon the work of several man-centuries. We would have to keep both the old and the new package and train people in both. The result is simply that we donât move, no matter the technical or cost benefit. We rather put pressure on our vendor to add any nice features that their competition has and we want.
If it is Juliaâs intent to capture the Matlab market - and I donât know that it is, or should be - having a tool to automatically and accurately translate Matlab code to Julia would be useful. As someone who is already using Julia, I would rather (selfishly) that the effort be spent on further improvements to Julia.
You can play the long game and introduce Julia at universities, where most people who end up using Matlab would have started using it. At that level, with no existing code base to maintain, Julia will blow Matlab out of the water and the experience will be carried along once the students leave.
13 Likes
a large sunk investment (many years of development have gone into proprietary code development)
Itâs not a sunk investment if there is an actual asset (i.e. if the years of development have resulted in a code base that is actually useful).
I meant sunk, as in âsunk costâ, i.e. money / effort already spent. Not sunk as in the Titanic, or my career prospects if the code was not useful.
2 Likes
This thread is super interesting, enough that a publishable economics paper could be written about spread of disruptive open source technologies. Something like David Atkinâs work on manufacturing technology in Pakistan here. Other economists in this thread probably know more than I do. Thereâs probably a paper about the spread of excel in the 1990s somewhere. It seems to be the conventional wisdom that MS office increased GDP by a detectable amount, but what was the transition cost of firms?
1 Like
Sunk investment has the connotation of being irrelevant for decision making. In the context of your comment, the advantage of Matlab is not that the companies have spent millions on it and management irrationally wants to âprotectâ the investment. As you point out in other comments, the issue is that companies have Matlab systems and switching to Julia can have a high cost.
As an example, say a company has spent $5mn developing a system in Matlab. The interesting figure is not how much they have spent (thatâs indeed a sunk cost) but how much they would need to spend to swtich to Julia. If the cost is $10k, it probably makes sense to do so. If the cost is $3mn, it probably doesnât.
1 Like
Yes, if course. Under the assumption of rationality. The barrier here is a manager admitting that his original decision was not the best possible one. 
Good luck with getting Matlab code from a few years ago to run with your current Matlab.
Mathworks have been playing fast and loose with compatibility for a few years now.
Oh, this is an exaggeration. They have introduced new features, but old code very rarely breaks. I use Matlab all day, every day, for over 20 years, and itâs happened to me maybe twice.
3 Likes
Mirone has more than 150 k lines of Matlab code and I still compile it (true compiling) with R6.5 (~15 years). With some hiccups yes but it runs also in R2018.
Mirone waiting for the Julia GUI solution to be ported here.
1 Like
I suppose it depends on the type of code thatâs involved. I just tried with my toolkit that used to run in 2011:
Running actuator1
Error using matlab.graphics.illustration.ColorBar/set
There is no CLim property on the ColorBar class.
Error in graphic_viewer/draw_colorbar (line 58)
set(cbh,...
Error in actuator1 (line 126)
draw_colorbar(gv, struct('colormap',cmap,'label','Temperature',...
Your mileage may vary, but my experience was that I had to regularly go fix the code with each new release.
The introduction of HG2 (handles graphics 2) in 2015 lead to situations like that. Those have to be fixed/given an alternative to work both with HG1 & HG2
1 Like