9 ms·

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

by psyklic 11y ago

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.

jessriedel 11y ago
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.
- JadeNB 11y ago
  > 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.
  - nickpsecurity 11y ago
    They could redo it to make extra stuff download as you need it for a given application.
  - taliesinb 11y ago
    About 70% of storage used by the latest version 10.3.1 is the documentation, for what that's worth (maybe nothing).
    - JadeNB 11y ago
      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?
      - carlob 11y ago
        There are several thousands of documentation pages with very rich evaluatable examples, many of which return graphics.
        JadeNB 11y ago
        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.)
        carlob 11y ago
- psyklic 11y ago
  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.
- lmm 11y ago
  > 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-die/ 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).
  - jessriedel 11y ago
    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.
    - lmm 11y ago
      They've gone wrong that way for Python. I don't have enough experience with Mathematica to know how their history has gone.
jadbox 11y ago
> "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?
- psyklic 11y ago
  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-programmers/cloud-deployment/ http://www.wolfram.com/language/fast-introduction-for-progra...

by psyklic 11y ago

jessriedel 11y ago

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.

JadeNB 11y ago
> 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.
- nickpsecurity 11y ago
  They could redo it to make extra stuff download as you need it for a given application.
- taliesinb 11y ago
  About 70% of storage used by the latest version 10.3.1 is the documentation, for what that's worth (maybe nothing).
  - JadeNB 11y ago
    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?
    - carlob 11y ago
      There are several thousands of documentation pages with very rich evaluatable examples, many of which return graphics.
      - JadeNB 11y ago
        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.)
        carlob 11y ago
psyklic 11y ago
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.
lmm 11y ago
> 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-die/ 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).
- jessriedel 11y ago
  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.
  - lmm 11y ago
    They've gone wrong that way for Python. I don't have enough experience with Mathematica to know how their history has gone.

jadbox 11y ago

> "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?

psyklic 11y ago
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-programmers/cloud-deployment/ http://www.wolfram.com/language/fast-introduction-for-progra...