Hacker News Reader

Comment by leephillips | Hacker News Reader

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.

View on HN

>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.

Sure, some limitations could be mitigated this way. But being open source does not in itself make it a good language/platform.

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.

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.

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:

   Get["https://raw.githubusercontent.com/szhorvat/Spelunking/master/Spelunking.m"]
   DateListPlot;
   Spelunk[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:

http://imgur.com/ZjWJvEO

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).

Thanks for "Spelunk", it's awesome.

Reply on news.ycombinator.com