Hacker News Reader

Comment by jessriedel | Hacker News Reader

I don't really get the complains about a kitchen sink of predefined functions, or the functional syntax. You can always fall back on defining a function yourself. (And with the amazing documentation and Google, it's quite easy to find most functions anyways.) Likewise, you can always use C++-style syntax for defining functions, for loops, etc.

Mathematica has plenty of problems, like it's extreme slowness for things that should be comiled, and awkward reference passing, but the ones you've pointed out don't really make sense to me.

View on HN

> I don't really get the complains about a kitchen sink of predefined functions

If you're running it locally, there's a very practical reason to complain: between Wolfram 7 and 8, the application bundle size went from 29 MB to 2.65 GB. That's not a typo.

About 70% of storage used by the latest version 10.3.1 is the documentation, for what that's worth (maybe nothing).

This is true for lots of programs. Try installing TeXLive or a similar LaTeX distribution from a package manager. Usually it pulls in a *-docs package that takes up well more than half of the download.

To be fair, though, it is very easy to customise TeXLive so that it doesn't do this; whereas, as far as I know, Mathematica offers no such option. To be sure, you can delete it afterwards, but I'm not sure how gracefully Mathematica deals with that; whereas TeXLive, for example, gracefully deals with incremental upgrades from a very basic installation. (I know, because that's exactly how I run it on my tiny SSD. My current installation is well under 1 GB.)

I didn't believe you, so I went to check, and you're absolutely right. That's amazing. What in the documentation is using up all that space?

There are several thousands of documentation pages with very rich evaluatable examples, many of which return graphics.

Surely the graphics that they return should be returned, live, rather than passively occupying space even while unread? (I don't just mean 'should' in the sense of "that's the way it ought to be"; I thought, though I don't know for sure, that part of the appeal of the 'live' documentation is that that's the way it is.)

Some stuff requires internet connectivity, some stuff takes a certain time to compute. If you had to wait one minute for all the stuff to evaluate when you open a new documentation page that would probably bad user experience. The appeal of live documentation to me is that I can modify the examples in place until they do what I need.

About 70% of the space is taken by documentation. You can delete that and read the docs online.

They could redo it to make extra stuff download as you need it for a given application.

> I don't really get the complains about a kitchen sink of predefined functions, or the functional syntax. You can always fall back on defining a function yourself. (And with the amazing documentation and Google, it's quite easy to find most functions anyways.) Likewise, you can always use C++-style syntax for defining functions, for loops, etc.

http://www.leancrew.com/all-this/2012/04/where-modules-go-to...

In the short term a kitchen sink of predefined functions are great, but in the long term they become baggage that holds a platform back (and there's no way to improve them without breaking backwards-compatibility). They're usually a sign that the platform has its priorities wrong: you need a good dependency management solution, and once you have that there's not much value putting things in the standard library. (Look at Scala, which is going to a lot of effort to carve things out of the standard library so that they can be maintained separately with their own release lifecycle).

You've described a hypothetical way things could have gone wrong. But have they? I don't think so. The Mathematica developers have in fact been impressively foresightful. When it has been necessary to make changes that break legacy code they have done so, but it's been very rare.

I really think this is like an Apple vs. non-Apple situation. Sure, the Apple ecosystem is closed and not as flexible and you can think of all these problems that it could get stuck on. But in practice for the large majority of Apple's target audience, these concerns don't pan out. And the benefits of that system are large.

They've gone wrong that way for Python. I don't have enough experience with Mathematica to know how their history has gone.

You could argue that standard libraries should be enormous and try to be everything to everyone. In fact, this is one of Mathematica's selling points -- they have many complex algorithms implemented.

However, this also means there is an enormous, aging codebase that Wolfram continually must maintain and add new features to. It means that coders from different communities (who use different sections of documentation) likely have very different standard practices. And, I am concerned that this philosophy of "always having to look everything up" really hinders their knowledgebase product due to lack of consistency.

However, I applaud Wolfram for the ambition and enthusiastically sticking with it over so many years.

Reply on news.ycombinator.com