Comment by psyklic | Hacker News Reader

Comment by psyklic | Hacker News Reader

As an experienced developer, I surprisingly enjoyed progressing through Wolfram's book for beginners. (I used Mathematica, not their online UI.) In particular:

+ Making instant web apps and APIs just by specifying two functions -- "front-end" and "back-end".

+ Easily creating impressive-looking programmatic 2D and 3D graphics and sounds.

+ Innovative idea making visible graphics and colors as arguments and outputs of functions.

+ "Knowledgebase" of facts accessible using natural language. (Though, this was often slow due to server calls.)

My main critique of Mathematica is that it is the epitome of a kitchen sink library. There is an overwhelming number of functions for every possible thing. So, it is often not feasible to know what is offered without a lot of reading. (In fact, Wolfram even states this in his book.)

This is the real problem with their "knowledgebase". I would love to enter any natural-language query and get an answer, but in reality I need to check their list of supported areas and know the seemingly arbitrary list of facts about each area. To really make this useful, Wolfram has to figure out how to make it work without requiring me to be so knowledgeable about what it contains a priori.

Also, having such a large standard library makes the language very "flashy". It is indeed impressive and inspiring to create a sphere or musical piece in one line of code. However, real programs end up being much larger. In practical programs, Mathematica's functional syntax results in long unwieldy statements with forced formatting. This is occasionally impressive, but it is just as often hard to decipher.

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.

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

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

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

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.

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

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

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.

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

> "front-end" and "back-end"

How exactly do these functions work? Can you specify a front-end that's outside of the wolfram platform/domain?

Here are two examples. The frontend asks a user for an image (or city+radius), and the backend edge detects the photo (or returns a map with a shaded radius around the city):

  CloudDeploy[FormFunction[{"photo" -> "Image"},
                           EdgeDetect[#photo] &]]

  CloudDeploy[FormFunction[{"place" -> "Location", "radius" -> "Quantity"},
                           GeoGraphics[GeoDisk[#place, #radius]] &, "PNG"]]

See more here: http://www.wolfram.com/language/fast-introduction-for-progra...

Reply on news.ycombinator.com