Mathematica demos sure look pretty [0]. But I recently tried to get actual work done with Mathematica and found the experience utterly ridiculous.
The high level functions, while nice for demos, never quite do what you need. Want to display data vs. time with errorbars around the data? Sorry, no function for this completely exotic use case, please hack a DateListPlot on top of an ErrorListPlot [1].
The WolframAlpha integration "transparently" interprets code for you in the background. This interpretation can change any day [2] and leaves you guessing why your notebook doesn't run anymore.
The bugs I encountered were severe: One of the output function swallows the "-" sign if the result is between -1 and 0 [3]. Currently I am battling file corruption of notebooks that are saved on network drives and open while the drive is disattached/reattached.
Had it not been for the awesome support by the mathematica. stackexchange.com community, I would have quit Mathematica completely. Now I vowed to use it only for small hacks. And, if I want to impress someone, for demos.
is interpreted by Mathematica itself and yields an object equivalent to "1 Kelvins". The input
Quantity[1, "Kelvin"]
however is interpreted "transparently" by Wolfram Alpha. A few weeks ago it evaluated to "1 KelvinsDifference", but now has changed to "1 Kelvins". Don't get me started on the KelvinsDifference vs. Kelvins thing, which are both represented by the same symbol to maximize your confusion when your unit conversions are failing...
Really interesting, detailed comment. The problem is not that Mathematica has bugs - all complex software has bugs (except TeX). The problem is that you can't fix it, or even see how it works, because the source is secret. Nothing will get fixed until the company decides to fix it. Access to source is not an ideological imperative, it's a practical necessity.
>Access to source is not an ideological imperative, it's a practical necessity.
I have access to the source of tons of stuff, and yet I can't fix it.
Not without spending months on understanding their codebase and going out of my actual projects and work.
(And even then, my fix might not be accepted upstream, so it could be invalidated with any major or even minor version update).
That other's have access too, so someone might fix it, also doesn't work that much. Tons of projects, even extremely popular ones like GTK have but a few commiters, and tons of open bugs.
I’m not convinced open source would really help. I get the feeling that Mathematica’s underlying philosophy just isn’t a good fit for practical programming.
I disagree. If it was open source I think enough people would write libraries for it (or add-ons or whatever they would be called) that most if not everything could be done with functions found online. In the rare event that they could not be done you could just create your own. This is similar to my annoyance over Wolfram Alpha being server side when some sort of client side solution would be way better but would involve the source code being available.
You are describing the LaTeX model. You have a lot of packages. When you are lucky all the packages get well together. If you are unlucky the pacakes are slightly incompatible. And if you need to use \usepacage[spanish]{babel} then you are out of luck.
Two recent problems I had with LaTeX:
* If you put a \dfrac inside a table, the table thinks that the fraction is smaller and the line of the borders of the table collide with the numbers.
* If you need a different header height in your first page, you need some black magic macrology to get a not so good solution.
This is a point that many people seem to skip when discussing Mathematica. I think it would be great if they open sourced all of the code but I doubt that that alone would bring a surge of new package developers. If anything, I would expect it to bring IPython, Sage, etc. people to pick around for useful bits to reimplement in other projects.
Actually, the source code for most things that aren't implemented in C are available. They're just distributed in the compiled MX form, so there isn't a source file to read. But you can still easily 'disassemble' parts of the language at runtime.
Here's a very simple way to do it for DateListPlot:
This produces a hyperlinked 'code browser' in your notebook that lets you chase down function definitions out of the live kernel. Here's an example of what it looks like:
So the OC could actually rewrite DateListPlot to add error bar support, if he wanted to. He could even overwrite the original MX file in his installation once he had done this, if he so desired.
So the OC could actually rewrite DateListPlot to add error bar support, if he wanted to. He could even overwrite the original MX file in his installation once he had done this, if he so desired.
Even thought it's true, probably he couldn't legally distribute his own modified copy of DateListPlot. Right know you can hack together error bars for a plot even if you only know the output format of DateListPlot (FullForm and patter matching helps a lot).
> The high level functions, while nice for demos, never quite do what you need. Want to display data vs. time with errorbars around the data? Sorry, no function for this completely exotic use case, please hack a DateListPlot on top of an ErrorListPlot [1].
'Never' seems like quite a generalization. What about e.g. Classify and Predict, or FormFunction, or Interpreter, or Nearest? Do those all not do quite what you need? Conversely, does other software do better, on average, in 'doing what one wants'? Which software?
There are gaps, definitely, one small example you've pointed out. My pet peeve, for example, is that it is unnecessarily difficult to map colors and sizes onto graph vertices based on vertex properties, which I needed to do for [1].
Still, the scope of visualization functionality is so vast [4] that it's not surprising there are gaps (which we continue to plug, the whole language is a never ending project). And having users report to us what they want lets us prioritize those things. Anyway, clearly DateListPlot should learn about error bars, and I'm sure in a year or two it will. Although it is frustrating you can't just go in there and tweak the source code yourself, I agree.
> Don't get me started on the KelvinsDifference vs. Kelvins thing, which are both represented by the same symbol to maximize your confusion when your unit conversions are failing...
I think Quantities should probably gain a little box, like DateObjects have [2], that lets you mouse-over for more information, which should make this problem easier to diagnose. But the distinction is apparently important [3], although I don't want to "get you started" :-). Either way, Alpha shouldn't change its interpretation from under you, that's definitely a bug.
Unfortunate, but fixed within a day of being reported! 10.0.2 has passed many weeks of SQA and will ship shortly. So at least this bug will only have been around for 0.0.2 versions :-)
> 'Never' seems like quite a generalization. What about e.g. Classify and Predict, or FormFunction, or Interpreter, or Nearest? Do those all not do quite what you need?
Certainly, there are many functions that do what I need - but in my experience, the "higher" the level of the function is, the smaller the chances that it fullfills my needs.
> Conversely, does other software do better, on average, in 'doing what one wants'? Which software?
Over the years I have come to appreciate Matlab. Like Mathematica, it also has some maddening idiosyncrasies [0] and is mostly closed source, but it let's me inspect its high level functions. For instance, if I am not happy about the errorbar plots, I can execute the command "edit errorbar" to get an idea what I have to change. If the change is complex, Matlab is a decent enough IDE to implement it anyways. In comparison, Mathematica seems like a front-end to the kernel to me. It is not a proper IDE. I heard there is a Mathematica IDE called Wolfram Workbench [1], but it costs extra.
For me, my biggest problem is not about the sofware "doing what one wants", but that it is doing things I don't want. File corruption and sign error bugs are absolutely not ok for software that I base my publications on, and I have not encountered them in the alternatives [2].
Mathematica is a powerful piece of software and has many use cases. Of course it can't be a "eierlegende Wollmilchsau" that is good at everything [3]. But personally (disgruntled customer rambling here) I wonder why Wolfram Research is devoting so much energy into developing all these new, shiny features while the foundation is crumbling.
[0] Try running a Matlab script that has - gasp - a space in its name. It will fail and produce an "undefined function" error message. (Not very helpful to new users.) The newer versions at least warn you if you try to save a script with an illegal name - but they still allow you to run it and produce the non-descript error message.
[2] The alternatives I actually use are Igor Pro, Matlab, and Excel. Excel can easily lead to sign errors because of the unexpected behaviour of the unary minus. It takes precedence over the power operator, so if you evaluate "-1^2", the result is +1. While you can get used to that behaviour, you can easily forget it when you work with references. Say A1 contains 1, then "-A1^2" evaluates to +1. If, like me, you prefer working with named cells and name A1 as x, then "-x^2" also evaluates to +1. I once botched an analysis due to this behaviour. Ironically, this was one of the reasons why I wanted to base my current analysis on Mathematica.
> Certainly, there are many functions that do what I need - but in my experience, the "higher" the level of the function is, the smaller the chances that it fullfills my needs.
Ok. It's hard to argue with a generalization absent more examples. I don't see DateListPlot as one that supports your point: it's relatively specific to plotting lists of dates. Whereas e.g. Classify and Predict are much more level: they're single-function wrappers around the most common use cases of machine learning.
But in a sense what you say must be true: the higher level you get, the more likely there will be some low-level detail you will not be able to change. That's kind of inevitable -- if you don't write it yourself, it is unlikely to do exactly what you want to do.
But that doesn't make the high level functions ridiculous, at all, or the entire project of building them ridiculous. When the high-level functions provide, they're beautiful. Plus, the low-level functions (in this case, Graphics) are still there.
Look, I don't want to discount your experience -- you're a customer, after all :). But it's a vast system that I know in some amount of detail, and despite my obvious bias, I think you are vastly overstating the case that it's a "demo language". People generally like to form opinions and then rant on the basis of little data, so I guess I'm challenging you there.
> Over the years I have come to appreciate Matlab. Like Mathematica, it also has some maddening idiosyncrasies [0] and is mostly closed source, but it let's me inspect its high level functions.
While not as friendly as seeing a source file, you can inspect almost all the high-level Mathematica code via tools like Spelunking: https://github.com/szhorvat/Spelunking (see my comment below)
> In comparison, Mathematica seems like a front-end to the kernel to me. It is not a proper IDE.
Agreed there, our 'package editor' isn't appropriate for serious programming. Workbench is fairly decent, but as you say, not free. Still, in my view Sublime* surpasses almost all other text editors, anyway, so it's much of a muchness. [* replace with Emacs or Vim to taste]
> File corruption and sign error bugs are absolutely not ok for software that I base my publications on, and I have not encountered them in the alternatives
I have often found network file systems (and their integration in modern OSes) to be unreliable with many kinds of software. Perhaps the FE could be more defensive about the OS lying to it ("I wrote those bytes, I promise"). Or perhaps there is a genuine bug where we don't check that some buffer got flushed successfully. Either way, I don't think this can be adduced in support of your crumbling foundations claim.
> I wonder why Wolfram Research is devoting so much energy into developing all these new, shiny features while the foundation is crumbling.
A function like TextString, which is new in 10.0.0, is not I think an indication of a crumbling foundation :). But sure, there are sections of entropying code. But we spring clean them with some regularity, at least.
One thing I think we can agree on: the whole grandiloquent project of Wolfram Language does make those flaws, when they come up, somehow infuriating. I wouldn't be infuriated if I found them in an open source project (partly because I could just contribute a fix, but also partly because my expectations wouldn't have been built up).
It makes working on the language a rollercoaster. When you add something really tight and clean, or when you rationalize some domain that was previously irrational, or when you see things fit together really beautifully, it can be incredibly satisfying. But when you see problems, or it lets you down, or you see when someone in the past took a shortcut, it can be very frustrating. Irrationally so.
[0], [2], ... wow... It reminds me of how the Glasgow Haskell Compiler used to delete your source code if it didn't type check. Apparently people didn't complain: "fair enough, I deserved it..." :)
[3] That's a glorious image I will carry with me for the rest of my life. Thank you.
I wish that the Wolfram articles would describe a little more about what their algorithms do, rather than the mechanics of how to use their primitives. The articles remind me some of the era of web engines optimized for a specific task -- there were plenty of MVC frameworks that work really really well for writing a todo list in 25 lines, but doing anything more complicated than a todo list meant dissecting the guts of the framework.
It'd be great to hear how they did an efficient implementation of texture synthesis. But if you want to read at least about the basics, the dissertation they linked [1] gets into the details on page 18, anyway, in section 2.2 (and beyond).
That is from my favorite texture synthesis paper of all (Efros & Leung '99), for these reasons:
- I know Efros, and he's a genius, and also an absolutely adorable human being.
- This paper was inspired by Markov text generators, its the two-dimensional equivalent, e.g., http://en.wikipedia.org/wiki/Mark_V_Shaney. Its very simple, produces great results, - AND - this texture synthesis algorithm will synthesize written text from a picture of written text. Almost none of the faster texture synthesis algorithms do this, and it seems meta; I like to think there is some deep fundamental truth hiding in there somewhere.
He also has a habit of not talking about how things work. All the time. Source code, mathematical proofs, citations, all of these things are relatively unimportant in Wolfram's world. He even thinks you should not try to find out how things work:
Particularly in more advanced applications of the Wolfram System, it may sometimes seem worthwhile to try to analyze internal algorithms in order to predict which way of doing a given computation will be the most efficient. And there are indeed occasionally major improvements that you will be able to make in specific computations as a result of such analyses.
But most often the analyses will not be worthwhile. For the internals of the Wolfram System are quite complicated, and even given a basic description of the algorithm used for a particular purpose, it is usually extremely difficult to reach a reliable conclusion about how the detailed implementation of this algorithm will actually behave in particular circumstances.
Yeah, I find this article very insulting and condescending. "Don't worry your pretty little head, our ideas are far too complicated for you to understand!"
FTA: The “TextureSynthesis” method is based on the algorithm described in “Image Texture Tools,”[1] a PhD thesis by P. Harrison. This algorithm is an enhanced best-fit approach introduced in 1981 by D. Garber in “Computational Models for Texture Analysis and Texture Synthesis.”[2]
There's an oldish plugin for the GIMP called Resynthesizer, but there are better algorithms out now. G'MIC has one called "inpainting". http://gmic.eu/repository.shtml
Wolfram has a habit of not giving a lot of citations or hiding them under the small print in order to make it seem like he or his company came up with everything in a void.
Although this article isn't by Wolfram I agree that the philosophy of his company seems to be to hype products like any normal consumer company does. The problem is this doesn't really work when your selling and academic product. No programming language management organization will claim they are "revolutionizing programming" without strong qualifiers.
Such an approach might be useful to the print industry for generating seamless "bleed" around images, which is required to allow some margin for error when trimming the physical prints.
Not to be totally grumpy here, but this is classic mathematicians-think-art-is-images-looking-like-famous-art. The expanded "starry night" isn't an interesting painting, of course. And it adds nothing to Mr. V. V. Gogh's work. It just mimics aspects of the extant work, in a spatially naive manner (e.g., what more do we learn except that the new rendition exists on a black mesa surrounded by more village-with-church?).
SIGGRAPH-style research shouldn't validate itself merely because it teaches the computer to adopt a cliched mode of image-making.
I'm going to agree with the critics - I think you may be confusing technical problem-solving with artistic awareness.
They're all interesting as technology demonstrations, but none of them improve on the original compositions, and some of them are almost completely unsuccessful as visual art.
I think that makes the whole just as interesting. Photographers often frame a tiny portion of the entire view available to them. That frame is where their art is, not the expanded view. So in a sense the wall just highlights that what's inside the frame is special and it contrasts nicely.
The high level functions, while nice for demos, never quite do what you need. Want to display data vs. time with errorbars around the data? Sorry, no function for this completely exotic use case, please hack a DateListPlot on top of an ErrorListPlot [1].
The WolframAlpha integration "transparently" interprets code for you in the background. This interpretation can change any day [2] and leaves you guessing why your notebook doesn't run anymore.
The bugs I encountered were severe: One of the output function swallows the "-" sign if the result is between -1 and 0 [3]. Currently I am battling file corruption of notebooks that are saved on network drives and open while the drive is disattached/reattached.
Had it not been for the awesome support by the mathematica. stackexchange.com community, I would have quit Mathematica completely. Now I vowed to use it only for small hacks. And, if I want to impress someone, for demos.
[0] https://www.youtube.com/watch?v=EjCWdsrVcBM
[1] http://mathematica.stackexchange.com/questions/18962
[2] The input
is interpreted by Mathematica itself and yields an object equivalent to "1 Kelvins". The input however is interpreted "transparently" by Wolfram Alpha. A few weeks ago it evaluated to "1 KelvinsDifference", but now has changed to "1 Kelvins". Don't get me started on the KelvinsDifference vs. Kelvins thing, which are both represented by the same symbol to maximize your confusion when your unit conversions are failing...[3] http://mathematica.stackexchange.com/questions/65600