I've enjoyed developing in the language professionally for many years. Truly, few things allow as rapid prototyping with such efficacy for so few lines across so many domains in a unified interface. There are some brilliantly innovative things across the language and, once you really get into the weeds of how to write efficient functional code, some of the things you can do are incredible.
Two things, though. Firstly, they are very stubborn on condoning a community to coalesce around the language other than through 'official' Wolfram channels. This comes from the big man himself, no doubt. As much as they want to drive adoption by coming up with (what they think are) "cool" sounding initiatives, they will never get devs to break from their core workflows and tools to do things the Wolfram way. There is no first-class support for daily-driver editing (vscode, emacs etc etc) for large-scale projects (other than an ancient eclipse package). Brenton Bostick at Wolfram has done some truly first class work in closing this gap though.
Secondly, this is the first major release that is a bit 'ho-hum' for a while. And it's reflective of the fact that whatever Stephen's pet interests are at a particular point in time will get attention in a release. For example, V11 was huge on Machine Learning and AI...now it barely gets a mention or extra development. Because SW is so focused on his Physics Project, this will likley be the case for a while.
To anyone thinking about using the language -- dive in. It's brilliant and expressive and fun. It's satisfying. You can do cool stuff. It just becomes very difficult when you want to scale it.
Anyone from WRI reading this: please, please, please let the community develop organically and support the toolchain everyone has wanted for so long. Or don't. But you need us more than we need you. Oh, and simplify the product line -- what a nightmare for newcomers to navigate. :-)
There's so much to it that it's easy to get lost. I don't even care for the "deep math" parts of it, it has _so many_ APIs for real-world data that "plain old exploration" is super-fun with it.
It'll also be great for anyone looking for "creative coding" (typically Processing.js etc is used for this), since the Graphics abilities are so quick and easy.
It has "a different shape" w.r.t. the languages and tools that are commonly used for programming, but it is a beast.
I haven’t used it in years, but I remember the Manipulate functionality being so great for exploring things. Its weird evaluation model always gave that some warts, but it was very useful nonetheless.
Perhaps I can add a counterpoint before anybody gets too excited and spends too much money on a tool they might not enjoy.
Having used Mathematica quite a bit for doing symbolic computation, my opinion on it is pretty much opposite to yours. While the extensive standard library is certainly nice, I think that the programming language used to access it is one of the worst programming languages in the world - certainly the worst I have ever used. I have never seen any other programming language where the basic scoping and evaluation rules are so badly designed and error-prone as in Mathematica.
Global scope (really global -- even between windows) is the default and the encapsulation tools are not particularly easy or convenient to use and not heavily promoted in the example material.
This leads to a dynamic where anyone without the CS background to recognize the foot-gun and the discipline to disarm it winds up with awful spaghetti code and the all-to-familiar consequences: a big blob of unmaintainable mystery code that becomes more and more difficult to modify until all project time is spent merely keeping it working rather than improving upon it.
We might laugh about this kind of newbie mistake here on HN, but even extremely intelligent people can't be experts at everything and the sheer number of physicist-hours and mathematician-hours I've seen needlessly flushed down this particular toilet is really quite unfortunate.
Thanks for this comment. Have the same experience at a Maths Department.
Each run of some specific code is “ouch, we must try and see when we have the time to understand how it works and how each error is handled.” Just because it is soooo difficult to properly write a module.
This isn't the language though. A runtime in Mathematica is called a kernel. By default, Mathematica uses one. I think base licenses allow you to run two simultaneous runtimes and you can buy more. When you start a new window you have to pick the kernel, it doesn't launch its own like Jupyter would do.
This is an annoyance with Mathematica: it's proprietary software so it's in a world of license servers, license keys, artificial limits and paid upgrades.
The main issue with the evaluation rules is that Mathematica doesn't distinguish between creating a symbolic expression and evaluating code. That is if I type
f[x]
and the function `f` is not defined, Mathematica will not give me an error but instead just assume that I meant to create a symbolic expression. If you know some Lisp, just imagine that everything came with an implicit `quote` which would automatically get invoked whenever a unbound variable or function would we encountered.
That issue alone has caused me so many errors simply from mistyping some function or variable name. For simple expressions, such bugs are pretty obvious to spot but if the same occurs deep inside a chain of function calls, this often lead to completely wrong results because the bug got masked by some other manipulations I did on the result of the function call.
Of course, there are tons of hacks and ad-hoc workarounds in Mathematica to get around this (imho fundamentally broken) behaviour to the tune of "just stick another `Evaluate` here" or "just change the function definition from `g[x_]` to `g[x_?NumericQ]` to call the function only when the argument is numeric and otherwise leave it unevaluated".
The situation with the scoping rules is not much better. Consider for instance the following code:
y = 1;
expression = Module[{y},1+y]; (* Module creates a new scope in which y is unbound *)
Can you guess what happens if I print out `expression` now?
Print[expression]
1+y$4066
Yes, Mathematica has just renamed our variable. If now we wanted to set `y` in our expression to some concrete value, of course the obvious thing to try doesn't work, but just gives me some bullshit:
Print[ReplaceAll[expression, y->10]]
10+y$4066
These are all only some simple examples of why doing any kind of metaprogramming in Mathematica just sucks.
> and the function `f` is not defined, Mathematica will not give me an error but instead just assume that I meant to create a symbolic expression.
I've dreamed about creating a language like this, but had to give up because it makes diagnostics impossible in case o typos and things like that..
My best bet now is to have some quote syntax to make a symbol stand for an abstract symbol, like
1 + x -- this sums 1 with x, and errors if x is unbound
1 + 'x -- this is an abstract expression, doesn't care if x is bound or not
Like lisp, except with some first class support to things like derive(1 + 'x, 'x), and, well, every operator needs to respect quoted symbols.. even if + were a user-defined operator or function, 1 + 'x needs to return (the AST) 1 + 'x. I suppose this is the same as Mathematica, except that Mathematica doesn't need quoting
I don't really know what more you wanted from `Module[{y}, 1+y] /. y -> 10`. You've explicitly asked for a new symbol that is unrelated to the global one, and then replaced any occurrences of the global one with 10. Of course there are no occurrences of the global one.
I claim any semantics which resulted in `11` would be extremely confusing, because it would imply the following also resulting in `11`, which is obvious nonsense:
> I claim any semantics which resulted in `11` would be extremely confusing, because it would imply the following also resulting in `11`, which is obvious nonsense:
> y = 10;
> Module[{y}, 1+y]
Yes that is precisely the point: because of Mathematicas weird evaluation model, you cannot have ordinary lexical scope as in every other programming language, but the only sensible thing to do is to rename variables under the hood. It is then very easy to leak those renamed variables accidentally in the global scope where you cannot do anything useful with them, because the symbols `y` in the global scope and in the subscope are different.
Another point that the example was meant to illustrate is that once you assign some value to a variable, you can no longer do symbolic manipulation with it (note that in the example, we have replaced 1 by 10 in the end).
If it’s not open source then it’s a non-starter, it doesn’t matter how cool it is. This is not an ideological free software stance, it’s a recognition that science has embraced the utility of open source tools and rejected black boxes. It’s essential for reproducibility and transparency in research. It’s no longer enough to provide your code in a paper supplement or on GitHub; the entire chain must be available for inspection, including the language itself.
EDIT: One common exception to this principle is the use of proprietary C or Fortran compilers for high performance.
They tried to get it out for freeon the raspi but I guess the uptake was really quite low. Either way the program for that has basically ended. https://www.wolfram.com/raspberry-pi/
The blog post was probably literally written in and hosted entirely on open source software which were highly innovative at their earlier stages and continue to be highly innovative. This is a very self-serving presentation of an idea. Also, I officially dislike the word innovation.
The Pi is built on a foundation of binary blobs. As I read it, https://www.raspberrypi.org/about/ is a lot more focused on free-as-beer than free-as-speech.
Because apparently you are writing a book about Julia. I assume people who write books about a language which are also in vogue in the scientific community, they are aware of the eco-system of said community. Mathematica is not exactly a new kid on the block.
The answer is that I did not know, and that’s why I asked. Mathematica is not a big part of the scientific research world as far as I’m aware. I don’t know anyone who uses it in physics research, for example. The last time I played around with Mathematica was in graduate school before Linux existed, when closed source and proprietary solutions were the norm. Back then I don‘t think there was anything like the Wolfram Language independent of the Mathematica product. So when I heard that this language now existed, I wondered if it was open and, therefore, something that might be interesting to use in research. From your tone I suspect that you won’t believe any of this. I’ll leave it up to your fevered imagination to divine how much I care about that.
I've heard they're working on creating an uncurated paclet repository, and the new paclet tools would appear to be the first step of that. Once that is complete we should finally have something similar npm.
For Mathematica, the graphical outputs and the vast pallette of functions is truly marvelous. IMO it feels a much superior product to Maple & MATLAB. If only they could make it bit more affordable to individual hobbyists. If I remember right, it is $200 per year (incl. tax). That does pinch the pockets a bit, specially if you are from a developing country.
EDIT: A thought that comes to my mind is that Jetbrains products are similarly placed in pricing. But YoY costs actually go down. Furthermore, you are allowed to retain the last subscribed version which you paid in full. You can use the same license on all your machines/VMs. This is not the case with Wolfram products. The pricing stays the same if you want the point updates to be fetched. You cannot use the product if your subscription ends and individual licenses are limited to 1 (or 2?) machines. This does hurt!
That service model purchases the available version of the product without any updates (patches are free for some (3?) months, but needs a recurring SLA if you want to update anything or call their online API).
That quickly turns out to be even more expensive than the subscription if you realistically want to develop something on that platform (for e.g a data analytics course, mapping overlays, queries - pretty much anything standard which one needs to teach or demonstrate to students. It isn't even a power-usecase)
PS: I made that mistake with v11.3. Abandoned it later.
I think updates are free for a year, the desktop version can still connect for 3,000 monthly Wolfram|Alpha API calls perpetually, and you can use the basic cloud version perpetually (but files are only saved for 60 days.)
Never done symbolic math in Mathematica but I have done it extensively in SymPy and Matlab. The symbolic toolbox is surprisingly powerful and performant compared to SymPy and I've never really been left wanting more.
Mathematica has a LOT more integrated into the base product. Matlab requires a toolbox for nearly everything and many toolboxes cost more than a Mathematica license. I enjoy Mathematica, but find Matlab to be inferior to Python development and very expensive.
I think Matlab is starting to realize this, at least at the institutional level they are starting to offer all the toolboxes for a fixed price (much much lower than buying all the boxes individually)
I don't care about home use. If my company wants to use Matlab, they shouldn't have to pay like $5k for the database toolbox and $5k for the optimization toolbox on top of my license.
MATLAB individual license for base product is actually lower, but toolboxes can cost a fortune. Student/Home version does not have several features inbuilt which have to be bought separately. Also the symbolic math support is dodgy. If I had to do Numpy type of operations only, I will take Numpy over MATLAB because its open source and free.
Symbolic math in matlab is vastly inferior to Mathematica, and the deep learning and reinforcement learning toolboxes are vastly inferior to the offerings in python.
However for control system design or digital signal processing I think matlab is superior to both, I also think the matlab IDE is severely underated.
These are just from my experiences, I’m sure each of these languages have other applications where they are superior to the other too.
I also speak with privilege as someone who has access to all these packages for free so..
It is practically unusable to the point of being a joke on Raspberry pi. Mathematica still takes couple of seconds on my 8-core/64GB rig to compute a non-trivial expression, notwithstanding any manual simplification. There is a noticeable time to boot the program where you stare at the Wolfram Spikey. The benchmarks are brutal no matter which Raspberry pi you choose:
Yes, with a rpi you are going back 15-20 years in performance. I don't know that I would call that unusable. People used Mathematica on the G5 PowerPC, which was in the same ballpark in the benchmarks you cite.
So I guess... for hobbyists, it just depends on your hobby.
I am okay with a G5-spec if everything else remained as they were 20 years ago. They haven't.
Datasets have grown in size exponentially. You deal with images which are no longer few kilobytes. Window managers in the GUI have to paint over a much larger display area even if you consider whitespace. To do a hobby project like for e.g build a toy spam-filter or a toy classifier, the prompt to execution takes over 6 minutes on a really tiny model. I don't see why this hobby project angle seems viable either. Hence, why I said its unusable practically.
It's tucked in a typical "help -> about -> credits" in the app just like the hundreds of other libraries. The language documentation never includes documentation on how the functions were built, it's for reading what things do and how to use them.
I don't use cloud so I'll take your word there is no such information anywhere but the originally linked post is the author saying they don't think it's used in Cloud anyways.
I know you're pointing out the author's concern about acknowledging his LGPL library, but I otherwise would have missed what is one of the cooler features in this huge post, CenteredInterval.
Indeed, the post essentially brags about how big it is:
> In Version 1.0 there were a total of 554 functions altogether. Yet between Version 12.0 and Version 13.0 we’ve now added a total of 635 new functions (in addition to the 702 functions that have been updated and upgraded).
With these batteries-included languages, mastery of the language really requires mastery of the library.
As another commenter pointed out they are pretty adamant about not going open source [1].
But then later they walked it back a little and claimed they are "like open source" [2]. Funny there are 12 reasons for being closed source and only 6 for being "like" open source. And the reasons they're like open source are pretty weak. The first one (free use) has a lot of restrictions like the way their cloud product locks you out of your files 60 days after they're created.
It's cool what Wolfam has achieved, but it's hard to justify going with a closed tool these days with all the interest in open science and the capabilities that are now available in the open source world.
>> Mathematica is amazing, but I wish it were open-source.
OSS or not, I fear for its future after Stephen Wolfram passes. Hopefully he has a good succession plan that's focused on the product and users rather than shareholders.
Mathematica is what it is because its design comes from a single brain. It does not matter which group or an individual takes over next, it will not be the same. Wish Stephen lives long enough until humans have solved aging.
The main cash cow of Mathematica is the library, not necessarily the language. They could certainly make the language more open, while keeping the secret sauce in the library. They could also open up some core parts of the library too.
In one of the vidoe Stephen Wolfram said he had discussed with RMS and was not convinced. I could not find what was the core argument. I like to know what his core argument is apart from making enough money to continue the work.
Statements like this are always biased by the perception of the writer i.e. you're walking into a no true scotsman here unless Wolfram is literally just too ignorant to remember that his business is likely reliant in some way upon open source.
It'd be interesting to analyze how the Python ecosystem stacks up against the points made in this blog. Naturally I don't have an insider's appreciation for what it takes to develop and maintain a language, so I can't really answer them myself.
Python is a good example of how open source can become quite problematic. A lot of the Python ecosystem, including the packages, is a confusing and slightly broken jumble. The lack of leadership/organization from the core group has led to problems.
But what he's missing in his points is that Mathematica is led by a company! They get to design it, they get to organize it, so they have full control of it still. Look at Terraform: it's horrible usability-wise and has tons of limitations. If it was open source, it would have had auto-import from day one, adding a version or depends_on to modules would've happened from day one, and something like CDK probably would have already been built in, so Pulumi probably wouldn't exist either. But since Hashicorp controls it, it only works the way they want, in spite of open source.
As long as Stephen's company is developing Mathematica, they can maintain full control (of their distribution of it), and it's extremely unlikely for any fork to be successful.
That's a valid point, something I've read a lot about. I'm a "scientific" programmer, so my usage is similar to how I used Mathematica (20+ years ago), at my desk or in the lab. I keep wondering to myself: Is Python really such a mess? Are the problems related to use cases that don't apply to me?
I also wonder (could download the trial version and find out) how Mathematica would be for things like hardware testing and lab automation. That's more of a side issue than directly related to the points of the blog post.
But you're probably right about trying to fork Mathematica. Python may owe its success to forking ideas from Mathematica, Matlab, etc., without vying head to head with the mother ship.
Being a company also has its drawbacks, such as having to invest a certain amount of effort into marketing-driven development such as trying to keep people buying upgrades. But maybe a company with a BDFL at the top of it can avoid that issue.
Python isn't really a mess (certainly less messy than MATLAB IMO) but the issue is that many practitioners are basically thrown at the language without any real caution or care.
A modern python (e.g. anaconda?) distribution is a pretty formidable tool (for some things I'd definitely take Mathematica any day, but I don't really code in mathematica vs. sketch) - the people using that distribution however may also not know anything about good practice. Python unfortunately is far too allowing of this, too, so some scripts are a genuinely hell. I'm a physics student currently working as a programmer, 2/5 lines of code I see in my department would be enough to request changes from a patch. I daydream about teaching them but that's never going to happen.
At work we actually developed a functional language (nee DSL) specifically to funnel people down exactly the places we want.
I'm a fan of WinPython, though it's only for Windows. It let me get started quickly, while also providing access to the standard tools such as pip. For virtually everything I've done, either pip or "python setup.py install" have been successful. The nicest thing about WinPython is that if I mess it up, I can just erase it and start over. I can also test my code on a "clean" distribution, to make sure that my installation instructions are valid.
The practice in my team is that you can start out any way you want, but you're expected to begin learning batter practices as your projects mature. And we have a couple people who can teach you. Though I was the one who introduced Python to my work site, I'm also one of the ones who needs to continue learning better programming practices.
It's sad that there is virtually no decent training for scientists who want to be better programmers. There's certainly a cacophony of advice, much of it conflicting or too complicated to be credible. Maybe it's not widespread, but when "scientific" programming is mentioned, there are always a lot of comments to the effect that we shouldn't be programming at all without a license. Likewise for the use of Excel. Instead, scientists are left to figure things out for ourselves, like we've been doing anyway since the dawn of time.
The issue as well, I think, is that prior to them leaving a lot of the programming enthusiasts are actually undergraduates, who might as well be vermin as far as some faculty are concerned so there is almost no spreading of information. I remember getting told off for saying tuple "instead of table" which was depressing.
If you think the python ecosystem is a mess I trust you have never used matlab and its toolboxes.
Also in the context of numerical/scientific programming I don't understand what is the issue with the packaging system. It's been working fine for myself and many others I know of.
I wish that I could really get into the Wolfram Language because in addition to symbolic programming I really like support for machine learning, semantic web, and data visualization.
I love using Lisp languages, I adapt to Python because I need it for my career in ML/DL, and Haskell for something different.
I have subscribed to the Desktop Edition (better interactivity that the cloud version) twice, so I have about four months of writing little bits of code and experimenting. I don’t mind the price (I happily pay for full up LispWorks with support). It is the language itself.
I have experimented with using WL from Common Lisp and Clojure, but there is some overhead for that.
Anyway, WL is an amazing ecosystem. I wish I could love the language.
Replying to my own comment: after reading through my collection of code snippets, I signed up a third time for a subscription, this tim for a year (not monthly).
> The most widely used rewriting engines often sit at the heart of programs and languages used for logic programming, proof assistants and computer algebra systems. One of the most popular of these is Mathematica and the Wolfram language.
I wonder if that's the difference. I ran this on 5950X but didn't know about that when testing with 12.3 but setting it on 13.0 isn't changing my results. According to some searching on this env var it could be because MKL 2020 Update 1 and later don't require this to use the AVX2 kernels but I don't have my 12.3 install anymore to verify if it was using an older version.
Our other giants in the history of programming language design have been far too modest. Imagine how APL might have changed the world if only it had been called Iverson Language. And nobody would still be using Word if the Knuth Typesetting Language were available.
Two things, though. Firstly, they are very stubborn on condoning a community to coalesce around the language other than through 'official' Wolfram channels. This comes from the big man himself, no doubt. As much as they want to drive adoption by coming up with (what they think are) "cool" sounding initiatives, they will never get devs to break from their core workflows and tools to do things the Wolfram way. There is no first-class support for daily-driver editing (vscode, emacs etc etc) for large-scale projects (other than an ancient eclipse package). Brenton Bostick at Wolfram has done some truly first class work in closing this gap though.
Secondly, this is the first major release that is a bit 'ho-hum' for a while. And it's reflective of the fact that whatever Stephen's pet interests are at a particular point in time will get attention in a release. For example, V11 was huge on Machine Learning and AI...now it barely gets a mention or extra development. Because SW is so focused on his Physics Project, this will likley be the case for a while.
To anyone thinking about using the language -- dive in. It's brilliant and expressive and fun. It's satisfying. You can do cool stuff. It just becomes very difficult when you want to scale it.
Anyone from WRI reading this: please, please, please let the community develop organically and support the toolchain everyone has wanted for so long. Or don't. But you need us more than we need you. Oh, and simplify the product line -- what a nightmare for newcomers to navigate. :-)