Wolfram Programming Cloud Is Live(blog.wolfram.com)
blog.wolfram.com
Wolfram Programming Cloud Is Live
http://blog.wolfram.com/2014/06/23/wolfram-programming-cloud-is-live/
113 comments
For people new to the Wolfram Language: it's essentially a new version of the programming language of Mathematica. if you're looking for help on StackExchange, go to http://mathematica.stackexchange.com/
The new "fast introduction for programmers" is also a good place to start:
http://www.wolfram.com/language/fast-introduction-for-progra...
http://www.wolfram.com/language/fast-introduction-for-progra...
I should also add that the "Things to try" notebook has some simple examples that demo various kinds of functionality: https://programming.wolframcloud.com/objects/7ea9a27a-1ea8-4...
Yes, exactly. I should have said, try Mathematica.SE for questions after having read through the inroductory tutorials. :-) Thanks for the link!
<cough> http://cloud.sagemath.org </cough>
Thank you for posting this. It wasn't immediately clear for me what Sage was though, so I'm pasting the project's description from their home page [1] here in case others were confused as well:
Sage is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more.
Access their combined power through a common, Python-based language or directly via interfaces or wrappers.
Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.
[1] http://www.sagemath.org/index.html
Sage is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more.
Access their combined power through a common, Python-based language or directly via interfaces or wrappers.
Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.
[1] http://www.sagemath.org/index.html
This looks more interesting than the (pricey) Wolfram offering, but they certainly have a weird password fetish if you try to open an account. Never found anything so fierce before, and I just wanted to take a look...
Agree completely. For onboarding tentative users just interested in trying out a product, front-ends should be using email-only or even URL-only authentication instead.
[deleted]
In a way the progress of Sage actually does remind me that Mathematica and the new Wolfram stuff are pretty impressive. I think eventually Sage will overtake it, and I personally feel much more comfortable doing science on top of an open-source stack. But Mathematica was pretty ahead of its time with some of the ideas that are now being implemented on the open-source side of things, like the live "notebook" interface (which Mathematica has had since the '80s). I think it had/has a lot of the right ideas about how to build an interactive workbench that ties together a bunch of built in functionality, with both graphical and REPL/language interfaces to it. And I think the Wolfram Language stuff is making the right moves in generalizing that to data-mining/ML, cloud integration, domain-specific things like built-in mapping support, etc. It's less of a revolution than Wolfram wants you to believe, but it's still good, quite well designed.
There are bits of that concept that come from elsewhere, so it's not 100% novel coming from nowhere. E.g. older computer-algebra systems, Matlab, etc., all have bits of the ideas that this particular class of mathematics+data systems is converging on. But prior to the current wave of open-source stuff, I think Mathematica had the best example of integrating it all into a usable system. It might still be the most polished and integrated one out there; parts of Sage still very much feel like libraries with different conceptual/interaction models, glued together with a thin layer of Python glue. Though Sage does have the advantage of being able to add functionality at a more rapid pace, and I assume the integration will get more seamless in the future.
There are bits of that concept that come from elsewhere, so it's not 100% novel coming from nowhere. E.g. older computer-algebra systems, Matlab, etc., all have bits of the ideas that this particular class of mathematics+data systems is converging on. But prior to the current wave of open-source stuff, I think Mathematica had the best example of integrating it all into a usable system. It might still be the most polished and integrated one out there; parts of Sage still very much feel like libraries with different conceptual/interaction models, glued together with a thin layer of Python glue. Though Sage does have the advantage of being able to add functionality at a more rapid pace, and I assume the integration will get more seamless in the future.
Interesting how 'meh' the comments are. I thought that building live APIs on the web looked pretty amazing.
[deleted](1)
The blog post was a lot of 'this is amazing and will change everything'(which wolfram thinks about everything he does, lol) without a convincing demonstration as to why. To me it sounds like they added more features to the Mathematica language. Which while potentially cool, it isn't likely to become a mainstream development language anytime soon. Seems most useful for quick data visualizations.
The thing is that it's impossible to read an interview, article or anything by Wolfram and not be washed over with hyperbolic statements about what his products mean and do.
Last time I saw The Wolfram Language, for example, on HN it was full of statements like how there finally was a language that made functional programming possible, etc., and when you look at the feature set there's absolutely nothing new that makes any kind of difference.
While this platform certainly seems interesting and it actually does seem to do something new, listening to Stephen Wolfram talk about how great his stuff is has gotten tiresome in general.
Last time I saw The Wolfram Language, for example, on HN it was full of statements like how there finally was a language that made functional programming possible, etc., and when you look at the feature set there's absolutely nothing new that makes any kind of difference.
While this platform certainly seems interesting and it actually does seem to do something new, listening to Stephen Wolfram talk about how great his stuff is has gotten tiresome in general.
I think one should judge the quality of the product not the author and his ego. But I agree, sometimes it can be tough. :)
It's a shame because he really is THAT smart. It's almost like the hype deters from the message.
Really? You read A New Kind of Science and were awestruck by his genius?
I've read parts of it a few times, and it just reads like a summary of other people's work[1], but if you don't read the appendices, it seems like that all of that other work was also Wolfram's. He's got a nasty habit of saying stuff like "cellullar automata theory teaches..." instead of saying "Marvin Minsky showed that...", as if the theory existed in a vacuum, independently of those who developed it.
Wolfram is well-known for claiming other people's work for himself and suing anyone who claims otherwise. That's how he acquired Mathematica, but trying to find the origins of that story is difficult, because he succeeded in suing everyone into silence.
[1] Plus a lot of "look at the beautiful pictures... LOOK AT THEM!" He's got a weird sense of mathematical rigour, something akin to believing that whatever the computer computes is right. Probably part of his idea of why it's ok to hide mathematics behind NDAs.
I've read parts of it a few times, and it just reads like a summary of other people's work[1], but if you don't read the appendices, it seems like that all of that other work was also Wolfram's. He's got a nasty habit of saying stuff like "cellullar automata theory teaches..." instead of saying "Marvin Minsky showed that...", as if the theory existed in a vacuum, independently of those who developed it.
Wolfram is well-known for claiming other people's work for himself and suing anyone who claims otherwise. That's how he acquired Mathematica, but trying to find the origins of that story is difficult, because he succeeded in suing everyone into silence.
[1] Plus a lot of "look at the beautiful pictures... LOOK AT THEM!" He's got a weird sense of mathematical rigour, something akin to believing that whatever the computer computes is right. Probably part of his idea of why it's ok to hide mathematics behind NDAs.
Jordigh, that's not the first time you've made that evidence-free claim. Let me make my own: your hostility has less to do with Wolfram and more to do with you.
You develop an open source alternative to Matlab. But if the Wolfram Language is really successful, it would make the work you've done fall short of its goal, which is to put all science and math computation on a free, non-proprietary basis.
Which claim? That he sued everyone in order to acquire control of Mathematica?
Like I said, it's hard to give evidence of that because he sued everyone into silence, but here's some vague allusions about it:
I suppose your next move is to discredit this source, but this isn't the first time I hear about it. I remember other vague allusions to this incident, and it fits with Wolfram's overall litigious nature, which is well-documented. I'll try emailing the parties that were probably involved (I think it included at least partially the SMP crowd).
In the meantime, you can keep defending Wolfram, but I don't think you really need to. He's got no shortage of shills.
Like I said, it's hard to give evidence of that because he sued everyone into silence, but here's some vague allusions about it:
Wolfram quit Illinois, took the program private, and entered into
complicated lawsuits with both his former employee and his
co-authors (all since settled).
I suppose your next move is to discredit this source, but this isn't the first time I hear about it. I remember other vague allusions to this incident, and it fits with Wolfram's overall litigious nature, which is well-documented. I'll try emailing the parties that were probably involved (I think it included at least partially the SMP crowd).
In the meantime, you can keep defending Wolfram, but I don't think you really need to. He's got no shortage of shills.
I thought so too but when I actually tried using "the language" it was more like using an application (excel?). For example there are no sockets. You can't create a hello world protocol. I was disappointed.
I think its because Stephen Wolfram built it. If anyone else did it it would be super awesome. While I don't share the hate I see this every time with anything 'Wolfram' on HN.
It's a bit disappointing that I have to sign up for an account, there doesn't appear to be a free-tier that is completely signup free (e.g. like tryruby.org, or a plethora of similar sites). I'm not denying them the opportunity to make money, but there is a user friction issue here to even take a peek.
I wonder if folks would be less cynical about this if they gave it a name other than 'the Wolfram Language' (how about 'Sym'?)
I wonder if folks would be less cynical about this if they gave it a name other than 'the Wolfram Language' (how about 'Sym'?)
I wonder if folks would be less cynical about this if they gave it a name other than 'the Wolfram Language'
That's a non-starter. Have you ever seen a copy of A New Kind of Science? Stephen figured out how to get his full name printed on every single page. That was no accident.
That's a non-starter. Have you ever seen a copy of A New Kind of Science? Stephen figured out how to get his full name printed on every single page. That was no accident.
There will be "playgrounds" that demonstrate different features and domains for you to live-code in your browser, and those will be AFAIK signup free, but that feature isn't quite ready yet.
Try it out here: https://programming.wolframcloud.com/app/
I find the conflation of language with runtime in the flag example to be especially obnoxious. All the Wolfram Language looks like to me in this example is a bunch of key value pairs with some hidden calls to a runtime that costs me money to use.
Not that I'm against spending money for something that's useful, nor am I against Stephen Wolfram trying to make a buck. It just seems a little misleading to bid this product as a "language" when really it seems like it's just a giant library/extended runtime for Mathematica.
Not that I'm against spending money for something that's useful, nor am I against Stephen Wolfram trying to make a buck. It just seems a little misleading to bid this product as a "language" when really it seems like it's just a giant library/extended runtime for Mathematica.
Let me correct you: Mathematica is a desktop product, specifically an IDE for the Wolfram Language. It is not a language, though before we had the name "Wolfram Language" it was used to mean that. Other such IDEs are Wolfram Desktop, the Eclipse-based Workbench, and the cloud-based Programming Cloud that is being announced here.
And although I'm biased, I don't think it is unfair for our language to meter access to an expensive resource in the form of real world data. There are complex translation layers that mediate access to a diversity of different databases, real time and static, and merge them to present a nice, clean logical view.
On top of that, cleaning and curating the data is expensive, and it has to be done in perpetuity -- think how often PersonData (http://reference.wolfram.com/language/ref/PersonData.html) needs to be updated, for example. Some data we also have to buy outright.
Should this prevent us building such real-world data into the language? I suspect in 20 years this idea will be common in new languages, and probably free.
For now, it needs to be subsidized, and the basis is fair: we charge Cloud Credits on the basis of the amount of time our servers are kept busy: 0.3 cents per second of computation time on our API servers. As we make our APIs faster, that effective cost will only go down.
And although I'm biased, I don't think it is unfair for our language to meter access to an expensive resource in the form of real world data. There are complex translation layers that mediate access to a diversity of different databases, real time and static, and merge them to present a nice, clean logical view.
On top of that, cleaning and curating the data is expensive, and it has to be done in perpetuity -- think how often PersonData (http://reference.wolfram.com/language/ref/PersonData.html) needs to be updated, for example. Some data we also have to buy outright.
Should this prevent us building such real-world data into the language? I suspect in 20 years this idea will be common in new languages, and probably free.
For now, it needs to be subsidized, and the basis is fair: we charge Cloud Credits on the basis of the amount of time our servers are kept busy: 0.3 cents per second of computation time on our API servers. As we make our APIs faster, that effective cost will only go down.
> Mathematica is a desktop product, specifically an IDE for the Wolfram Language
Presenting Mathematica (or, rather, FrontEnd?) as IDE is harmful for its reputation among hackers:
1) Workflow differs from one in traditional IDEs, and lots of build tools are simply not there
2) It has different goals, being a bottom-up environment: users start with tiny one-cell programs; IDEs like Eclipse suggest to “create a new project” by default
It's a tool for discovery and improvisation, not for building large programs, with multi-modular source code provided by different independent authors, that is sometimes (often?) written in different languages.
“Improvisations and Experiment Environment” or something like that would be a more adequate description.
It's not that FrontEnd can't be an IDE too. I believe it can be a better IDE than anything else out there but experienced programmers disagree unanimously. Part of it is personal tastes, part is mind being closed by means of classical IDE heritage, part is not-so-rational disgust towards proprietary software, paid software, S.W., etc.
FrontEnd and the language itself encourage users to add features themselves. Those who persist probably end up with the highly personalised product the majority of them could never buy. (+) Still, some features would be universally needed, so one might want to install a package from a public hub, but FrontEnd lacks this feature. (–)
I think hackers would appreciate it more if Mathematica (FrontEnd?) were marketed as emacs-like tool. Still, without a proper package manager (and an open package server, or at least an open standard for package server) it would be a hopeless take. — Though I heard something like package manager is coming. :-)
Presenting Mathematica (or, rather, FrontEnd?) as IDE is harmful for its reputation among hackers:
1) Workflow differs from one in traditional IDEs, and lots of build tools are simply not there
2) It has different goals, being a bottom-up environment: users start with tiny one-cell programs; IDEs like Eclipse suggest to “create a new project” by default
It's a tool for discovery and improvisation, not for building large programs, with multi-modular source code provided by different independent authors, that is sometimes (often?) written in different languages.
“Improvisations and Experiment Environment” or something like that would be a more adequate description.
It's not that FrontEnd can't be an IDE too. I believe it can be a better IDE than anything else out there but experienced programmers disagree unanimously. Part of it is personal tastes, part is mind being closed by means of classical IDE heritage, part is not-so-rational disgust towards proprietary software, paid software, S.W., etc.
FrontEnd and the language itself encourage users to add features themselves. Those who persist probably end up with the highly personalised product the majority of them could never buy. (+) Still, some features would be universally needed, so one might want to install a package from a public hub, but FrontEnd lacks this feature. (–)
I think hackers would appreciate it more if Mathematica (FrontEnd?) were marketed as emacs-like tool. Still, without a proper package manager (and an open package server, or at least an open standard for package server) it would be a hopeless take. — Though I heard something like package manager is coming. :-)
You're right, it is more of an emacs-like tool. Probably in the next year or so we will consolidate some ideas of what an IDE should (or could) be for WL. Some Brett Victor like things should be in there, no doubt...
And yes, we need to get PacletManager into a state where it is easy to use as a package manager. The only thing (and a big, crucial thing) it is missing right now is explicit dependencies, and a solver. If you have ideas about this please offer them (are you on the Mathematica stack exchange?)
And yes, we need to get PacletManager into a state where it is easy to use as a package manager. The only thing (and a big, crucial thing) it is missing right now is explicit dependencies, and a solver. If you have ideas about this please offer them (are you on the Mathematica stack exchange?)
I'm at mma.sx, yes, and I love the community. :-) https://mathematica.stackexchange.com/users/1859/akater I'm interested in the topic and discuss it sporadically in chat but can never find enough time to give it the attention it deserves. (For now.)
Dependencies hell is a tough nut, yes. Though, every language has this problem, AFAIK, and the more high-level the language is, the more perfect solution it tries to implement, it seems. :-)
But unfortunately I don't have any ideas for now, due simply to lack of empirical evidence: there's yet no stack of independently developed packages meant to interact with each other, to experiment with. One probably can't derive successful solution purely from general [even if expert] understanding of contexts, packages and shadowing in WL; real-life practice should be taken into account which is almost non-present for the time being.
Dependencies hell is a tough nut, yes. Though, every language has this problem, AFAIK, and the more high-level the language is, the more perfect solution it tries to implement, it seems. :-)
But unfortunately I don't have any ideas for now, due simply to lack of empirical evidence: there's yet no stack of independently developed packages meant to interact with each other, to experiment with. One probably can't derive successful solution purely from general [even if expert] understanding of contexts, packages and shadowing in WL; real-life practice should be taken into account which is almost non-present for the time being.
The Front End isn't very good at taking the job of an IDE ...
But it is a very good notebook interface (doesn't the notebook concept come from Mathematica originally?). Notebook interfaces are excellent for interactive work (a large part of scientific computing) and improvisational programming. It's a pity that they're only becoming popular recently (IPython). Many people still don't get it what notebooks are really good for. For example, the R community seems to think that a "notebook" is for report generation, and none of the "notebooks" for R allow any interactive work (knitr).
What's good about the notebook interface is the workflows it allows. Even MATLAB adopted "cell mode" a few years ago which enables the same basic workflow (except it does't have the equivalent of output cells, so it's not quite as good).
But it is a very good notebook interface (doesn't the notebook concept come from Mathematica originally?). Notebook interfaces are excellent for interactive work (a large part of scientific computing) and improvisational programming. It's a pity that they're only becoming popular recently (IPython). Many people still don't get it what notebooks are really good for. For example, the R community seems to think that a "notebook" is for report generation, and none of the "notebooks" for R allow any interactive work (knitr).
What's good about the notebook interface is the workflows it allows. Even MATLAB adopted "cell mode" a few years ago which enables the same basic workflow (except it does't have the equivalent of output cells, so it's not quite as good).
> doesn't the notebook concept come from Mathematica originally?
Yes. It stems naturally from Lispy core of Wolfram language, IMO. Hypothesis: whenever you try to develop a user-friendly environment with a Lisp-like language, given enough effort and being consistent, you end up with notebook interface. :-)
> The Front End isn't very good at taking the job of an IDE ... > But it is a very good notebook interface
Actually, notebook interface is the key here, I believe.
How do people start writing large programs, anyway? They invariably start with small things (~ “evaluating Plot[…] in one cell”). Then they join communities, accept certain practices and fashions, and pick the tools that dominate the community.
Workbench (Eclipse + Mathematica Kernel caller + some build tools) is a universally recommended solution for large programs written in Mathematica. Having no experience with programming, I honestly tried it, used for several months only to come to believe people only recommend it because of fashions and traditions currently dominating the area. There was absolutely no benefit in using it for a [relatively] large project instead of a bunch of notebooks with their cells properly and consistently (and automatically, of course) tagged. I deploy, call unit tests and show project directory tree, with one-word command for each task, it all happens inside FontEnd, and I have no idea why people repeatedly try to float away from notebook interface.
I don't have years of experience, and may be stupid, but I strongly suspect it's only due to old habits, community influence or plain unwillingness to innovate when you have traditional environments at hand.
Multi-language projects could present a challenge, though (given that we have to represent text with boxes and not pure strings), but it can be overcome as well, if only people invested their time and effort.
Yes. It stems naturally from Lispy core of Wolfram language, IMO. Hypothesis: whenever you try to develop a user-friendly environment with a Lisp-like language, given enough effort and being consistent, you end up with notebook interface. :-)
> The Front End isn't very good at taking the job of an IDE ... > But it is a very good notebook interface
Actually, notebook interface is the key here, I believe.
How do people start writing large programs, anyway? They invariably start with small things (~ “evaluating Plot[…] in one cell”). Then they join communities, accept certain practices and fashions, and pick the tools that dominate the community.
Workbench (Eclipse + Mathematica Kernel caller + some build tools) is a universally recommended solution for large programs written in Mathematica. Having no experience with programming, I honestly tried it, used for several months only to come to believe people only recommend it because of fashions and traditions currently dominating the area. There was absolutely no benefit in using it for a [relatively] large project instead of a bunch of notebooks with their cells properly and consistently (and automatically, of course) tagged. I deploy, call unit tests and show project directory tree, with one-word command for each task, it all happens inside FontEnd, and I have no idea why people repeatedly try to float away from notebook interface.
I don't have years of experience, and may be stupid, but I strongly suspect it's only due to old habits, community influence or plain unwillingness to innovate when you have traditional environments at hand.
Multi-language projects could present a challenge, though (given that we have to represent text with boxes and not pure strings), but it can be overcome as well, if only people invested their time and effort.
Notebook interfaces are nice for interactive work (I love the concept and advocate for it), but they're no replacement for an IDE for writing packages. I spend most of my time in the notebook interface, but when it comes to writing a polished package, I use an IDE or a separate text editor. (Check out http://www.mathematicaplugin.halirutan.de/)
Having worked on a medium-large project collaboratively (http://matlink.org/), I can't imagine how we could have managed without using plain text files and version control (notebooks currently cannot be efficently used with version control systems).
IDEs are not used just out of habit. They have their uses, and notebooks can't replace them, just as IDEs or simple REPLs can't replace notebooks.
Having worked on a medium-large project collaboratively (http://matlink.org/), I can't imagine how we could have managed without using plain text files and version control (notebooks currently cannot be efficently used with version control systems).
IDEs are not used just out of habit. They have their uses, and notebooks can't replace them, just as IDEs or simple REPLs can't replace notebooks.
> Check out http://www.mathematicaplugin.halirutan.de/
I'm aware of this plugin. That's exactly what I'm talking about. People obviously put lots of thought, effort and care into it. If it was invested in modifying notebooks, I argue, the results wouldn't be less impressive.
The only difference between notebooks and traditional editors is the latter being strings-oriented; the former being trees-oriented.
So, what exactly can a traditional IDE (or a command line, for that matter) do that notebook can't? :-)
> I can't imagine how we could have managed
> without using plain text files and version control
I haven't yet collaborated, that's important, of course. Still, I have plain text files that can be version controlled, and this doesn't seem to have anything to do with interface. I never edit them directly. Programs' text and metadata (comments, preamble, datestamp, sections markup) are all compiled into package files from notebooks. Git will diff as it does usually, so your colleague doesn't have to use tree-oriented editors. There's even a default feature like that in FrontEnd but the functionality is very basic and it's not meant to be extendable.
I don't collaborate, so I don't have a package to notebook converter but there's nothing conceptually difficult about it. You import someone's changes to a local notebook (or to a newly created copy of it): your drafts, experiments, test results and overall interactive canvas all stay, only definitions become modified. Drafts and experiments from collaborators' notebooks could be merged, as well. Notebooks don't have to be a part of version control at all.
Again, it's not conceptually difficult to write a version control aimed not at strings but at cells, or maybe cells with datestamps. If I want to merge notebooks I'll have to implement that. — An ad hoc merger I've written right now is merely 4loc, though.
The question at its lowest level is very simple: what is a better medium to organise data (and code — which is the same, in our case), strings or trees?
I'm aware of this plugin. That's exactly what I'm talking about. People obviously put lots of thought, effort and care into it. If it was invested in modifying notebooks, I argue, the results wouldn't be less impressive.
The only difference between notebooks and traditional editors is the latter being strings-oriented; the former being trees-oriented.
So, what exactly can a traditional IDE (or a command line, for that matter) do that notebook can't? :-)
> I can't imagine how we could have managed
> without using plain text files and version control
I haven't yet collaborated, that's important, of course. Still, I have plain text files that can be version controlled, and this doesn't seem to have anything to do with interface. I never edit them directly. Programs' text and metadata (comments, preamble, datestamp, sections markup) are all compiled into package files from notebooks. Git will diff as it does usually, so your colleague doesn't have to use tree-oriented editors. There's even a default feature like that in FrontEnd but the functionality is very basic and it's not meant to be extendable.
I don't collaborate, so I don't have a package to notebook converter but there's nothing conceptually difficult about it. You import someone's changes to a local notebook (or to a newly created copy of it): your drafts, experiments, test results and overall interactive canvas all stay, only definitions become modified. Drafts and experiments from collaborators' notebooks could be merged, as well. Notebooks don't have to be a part of version control at all.
Again, it's not conceptually difficult to write a version control aimed not at strings but at cells, or maybe cells with datestamps. If I want to merge notebooks I'll have to implement that. — An ad hoc merger I've written right now is merely 4loc, though.
The question at its lowest level is very simple: what is a better medium to organise data (and code — which is the same, in our case), strings or trees?
"You import someone's changes to a local notebook" <-- there are no existing tools that reliably automate that. (I'm aware of the notebook diff utility in the AuthorTools package, but that's not reliable). There are many tools if you're working solely with plain text.
I hope one day it will be released, either by me or by someone else. :-)
> There are many tools if you're working solely with plain text.
…which means, people choose plain-text due to time preferences: a certain gain in short-term is preferred to uncertainity of the outcome when they build tools for themselves. String-oriented environment is thus preferred not because notebooks' functionality is somehow bounded ultimately.
> There are many tools if you're working solely with plain text.
…which means, people choose plain-text due to time preferences: a certain gain in short-term is preferred to uncertainity of the outcome when they build tools for themselves. String-oriented environment is thus preferred not because notebooks' functionality is somehow bounded ultimately.
Yes, I agree with you assessment :-)
[deleted]
> Should this prevent us building such real-world data into the language?
You didn't build it in to the language, you connected the language to a standard database via the hosted, proprietary runtime.
I'm not against this in principle - it's clearly a useful thing - but it's hardly revolutionary.
I already pay a company for essentially the same thing (where I use a DSL embedded in a programming language to interact with their database of social media).
Again, I'm not against the idea as I understand it, but the misuse of terminology and generally the way that various people associated with the project talk about it is a huge turn off.
You didn't build it in to the language, you connected the language to a standard database via the hosted, proprietary runtime.
I'm not against this in principle - it's clearly a useful thing - but it's hardly revolutionary.
I already pay a company for essentially the same thing (where I use a DSL embedded in a programming language to interact with their database of social media).
Again, I'm not against the idea as I understand it, but the misuse of terminology and generally the way that various people associated with the project talk about it is a huge turn off.
Entity is part of the documented language -- we've standardized the representation of millions of real-world things. Looking up properties of Entities and parsing text into Entities depends on Wolfram|Alpha, just like the ServiceExecute function relies on Twitter and Facebook to work, and just like Graphics relies on a front-end executable to actually render.
These aren't libraries as you might call (say) core.logic in Clojure, because Entity and co integrate tightly across the rest of the language, and because they all share the same System namespace. They aren't quite DSLs either, because if they were the entire language would be a DSL -- rather the language is symbolic, which gives it some properties in common with DSLs.
If there is nomenclature that is different or new, it is mostly because the language is different. The only thing I can't defend is the pure in our "pure functions". They're not pure functions, they are lambdas.
These aren't libraries as you might call (say) core.logic in Clojure, because Entity and co integrate tightly across the rest of the language, and because they all share the same System namespace. They aren't quite DSLs either, because if they were the entire language would be a DSL -- rather the language is symbolic, which gives it some properties in common with DSLs.
If there is nomenclature that is different or new, it is mostly because the language is different. The only thing I can't defend is the pure in our "pure functions". They're not pure functions, they are lambdas.
Thank you for your reply.
Looking through examples, it still appears very much that domain specific calls were added to the very flexible language typically used in Mathematica to essentially extend computation to these new domains using domain specific widgets. (Also, some exchange data types.)
I'm still having trouble seeing how this is a radical departure from say, embedding a bunch of domain specific tie ins in a Lisp using macros (or similar constructs) to get a similar syntax across them.
I get that the constructs are likely tightly integrated, but I guess I'm still not seeing where it's more than a framework for dealing with particular classes of data running on top of a programming language that targets a hosted run time with a database of facts.
I'm not saying that this isn't a useful thing, and entirely worth it for well curated data. As I mentioned, I pay for essentially that service targeting a database about social media. I'm just trying to see if there's something key to understanding the features that I'm missing.
If you'll excuse one quasi-dig: it can sometimes be hard to see what something really is and what its use cases are through the hype and marketing.
Looking through examples, it still appears very much that domain specific calls were added to the very flexible language typically used in Mathematica to essentially extend computation to these new domains using domain specific widgets. (Also, some exchange data types.)
I'm still having trouble seeing how this is a radical departure from say, embedding a bunch of domain specific tie ins in a Lisp using macros (or similar constructs) to get a similar syntax across them.
I get that the constructs are likely tightly integrated, but I guess I'm still not seeing where it's more than a framework for dealing with particular classes of data running on top of a programming language that targets a hosted run time with a database of facts.
I'm not saying that this isn't a useful thing, and entirely worth it for well curated data. As I mentioned, I pay for essentially that service targeting a database about social media. I'm just trying to see if there's something key to understanding the features that I'm missing.
If you'll excuse one quasi-dig: it can sometimes be hard to see what something really is and what its use cases are through the hype and marketing.
Have you actually used the computable data functionality in Wolfram products?
If you think its a matter of just connecting to a standard database, you are missing the whole point.
People in the data business tell you cleaning and preparing the data is 80% of the work. Wolfram has done that for you. And then taken it farther: integrating it directly into language constructs.
I think SW's post did a poor job of explaining these capabilities, but in some domains this integration totally trounces what is possible in other systems. A great example of this is how GeoGraphics works:
http://reference.wolfram.com/language/ref/GeoGraphics.html
Notice how semantic entities like countries and landmarks are interoperable with the graphics language.
If you think its a matter of just connecting to a standard database, you are missing the whole point.
People in the data business tell you cleaning and preparing the data is 80% of the work. Wolfram has done that for you. And then taken it farther: integrating it directly into language constructs.
I think SW's post did a poor job of explaining these capabilities, but in some domains this integration totally trounces what is possible in other systems. A great example of this is how GeoGraphics works:
http://reference.wolfram.com/language/ref/GeoGraphics.html
Notice how semantic entities like countries and landmarks are interoperable with the graphics language.
I think we're operating on a different definition of "language". Unlike natural languages a programming language has extension points to define new vocabulary, it doesn't mean that all available words are part of the language. Otherwise it's like saying that everything that is in perl's CPAN is part of the language.
Usually there is a distinction that's made where the language is the syntax + the semantic defined by the compiler or the runtime. Then comes the standard library, then comes the user libraries. The "wolfram language" seem to mash everything together into a single thing.
Usually there is a distinction that's made where the language is the syntax + the semantic defined by the compiler or the runtime. Then comes the standard library, then comes the user libraries. The "wolfram language" seem to mash everything together into a single thing.
In what way is anything in that example different than say, a DSL implemented in Lisp macros connected to a database?
Am I missing something here?. The number of API calls per month seems to be extremely low?
With 100 or 1000 API calls, how can you make a "dynamic" application? This would only be useful for static / stale content.
What good is purchasing more credits, if I only have a very low number of API calls?
http://www.wolfram.com/programming-cloud/pricing/
With 100 or 1000 API calls, how can you make a "dynamic" application? This would only be useful for static / stale content.
What good is purchasing more credits, if I only have a very low number of API calls?
http://www.wolfram.com/programming-cloud/pricing/
I'm pretty sure you can purchase more API calls.
However I want to make clear that those API calls are to Wolfram's servers for things like natural language parsing and data. You can write an APIFunction that does not use API calls, but just uses cloud credits to do computation.
I understand it can be confusing, but there is a difference between API calls to your CloudObjects and API calls from your CloudObjects.
However I want to make clear that those API calls are to Wolfram's servers for things like natural language parsing and data. You can write an APIFunction that does not use API calls, but just uses cloud credits to do computation.
I understand it can be confusing, but there is a difference between API calls to your CloudObjects and API calls from your CloudObjects.
Thank you for making this clear! :-)
Ouch, cloud credits at $180/M. That's 0.18c for 1000, or 100s of compute time. $6.50/hr for computation, and that's buying in bulk, it's almost $11/hr if you buy in blocks of $15.
Note that's API and knowledgebase computation time, not notebook computation time, which doesn't cost cloud credits.
Cloud credits come with each plan, as well, so you have some leeway for development and testing before you have to buy additional cloud credits at a base price 0.03 cents per credit.
http://www.wolfram.com/cloud-credits/ has more info.
Cloud credits come with each plan, as well, so you have some leeway for development and testing before you have to buy additional cloud credits at a base price 0.03 cents per credit.
http://www.wolfram.com/cloud-credits/ has more info.
Can anyone enlighten me about why the title of the post got changed? I tried to squeeze all the relevant information in there, to make it easy for people to decide whether they're interesed or not. I really hope it's not because some of the commenters don't like this system not being open source, and find the "try it for free" bit not politically correct.
I'm not sure what is was before, but as per HN guidelines:
> Otherwise please use the original title, unless it is misleading or linkbait.
> Otherwise please use the original title, unless it is misleading or linkbait.
Thanks, that explaines it!
Does anyone (taliesinb?) know if there is any additional benefit to the Desktop version over Mathematica?
Wolfram Desktop has built-in integration with the cloud -- it can save and load straight from your cloud files.
It also sheds a lot of the historical computer algebra baggage of Mathematica -- palettes for entering equations and so on are gone.
And although it doesn't support this yet, Wolfram Desktop will soon let you connect straight to a cloud kernel. It'll be really cool: you'll write ParallelMap, and (say) 32 kernels in the cloud will be summoned for you.
It also sheds a lot of the historical computer algebra baggage of Mathematica -- palettes for entering equations and so on are gone.
And although it doesn't support this yet, Wolfram Desktop will soon let you connect straight to a cloud kernel. It'll be really cool: you'll write ParallelMap, and (say) 32 kernels in the cloud will be summoned for you.
Thanks for the reply; the last feature is pretty cool. I'll certainly have a play with the free 'dabbler' edition (I forgot what it was called), but it doesn't sound like there's much to tempt me away from Mathematica for the time being. I use the CAS stuff a fair bit now.
Mathematica 10 is being released shortly, that has plenty of new things (thanks to the Wolfram Language it shares with the Programming Cloud) to tempt you! GeoGraphics, Entity, computational geometry, machine learning, Association, Dataset, SemanticImport...
> computational geometry
Playtime! Awesome.
I'm just a Home Edition user, but as long as the upgrade price starts with a 1 then I'll be paying up.
That is, if you can tell me you've fixed undo in Notebooks :)
Playtime! Awesome.
I'm just a Home Edition user, but as long as the upgrade price starts with a 1 then I'll be paying up.
That is, if you can tell me you've fixed undo in Notebooks :)
What will it be able to do that Mathematica won't have? (Will Mathematica also have cloud integration?)
And what about the Discovery Platform and Data Science platform? How will these differ from Mathematica?
And what about the Discovery Platform and Data Science platform? How will these differ from Mathematica?
AFAIK, Mathematica 10 won't have cloud integration. And the semantic stuff will be present, but will be "trial grade".
The emphasis in Discovery and Data Science platforms will be around workflow and reporting, though the features there haven't been finalized yet.
The emphasis in Discovery and Data Science platforms will be around workflow and reporting, though the features there haven't been finalized yet.
I've been told I'm wrong, Mathematica 10 will have cloud integration, but with a product called Mathematica Online (see wolframcloud.com for the whole family of cloud products).
[deleted]
Kind of sounds like http://www.terminal.com but Mathematica-specific
If you like paying through the nose for hyperbole, this is for you.
Can anyone point to where pricing is described? I couldn't find any info.
meh
Is anyone else having trouble getting this site to load?
When I login I get either a blank screen or an error page.
I've been experiencing the same problem all day. The server keeps sending 500 errors and complaining about being down. I've been excited about this launch all year, and naturally trying to access the app all day. No dice!
Nope, it's working for me.
"Try it for free"... nope. Languages should be free, period, not free for trial.
Not to defend Wolfram, but to understand this you'll have to understand that "The Wolfram Language" is not like the traditional "programming languages". Traditional programming languages consist of a set of grammar, essential built-in libraries and a few development tools. The Wolfram Language is more than that. It includes the Mathematica language, a very rich set of libraries/algorithms, rich bodies of knowledge encoded in curated datasets in various kinds of physical and social sciences.
It might be best to compare the Wolfram Language to natural languages like English instead of programming language. The English language is not just a set of grammar, but also a rich collection of vocabularies that need to be compiled and maintained, and perhaps a rich collection of literature that need to be maintained and expanded to help learners understand the language.
Wolfram spent quite some time and resources to collect data for his Wolfram Alpha, and his new "language". It makes sense to charge money for such efforts.
It might be best to compare the Wolfram Language to natural languages like English instead of programming language. The English language is not just a set of grammar, but also a rich collection of vocabularies that need to be compiled and maintained, and perhaps a rich collection of literature that need to be maintained and expanded to help learners understand the language.
Wolfram spent quite some time and resources to collect data for his Wolfram Alpha, and his new "language". It makes sense to charge money for such efforts.
It's not like every other popular language doesn't include huge rich sets of free libraries and algorithms - Mathematica has few good competitors (not none) in many math and science areas, but competitors are obviously much richer in most of the rest (which is important for a general purpose programming language). It's just that those libraries are usually spread among many open source libraries written by different people rather than being all centralized.
Based on an accounting of the work involved, it's reasonable to charge, but based on the options available (and the relative unprovenness of the Wolfram Language), it's also perfectly reasonable for people like the parent to insist on free languages only. It's what Wolfram's competing with, at least in the view of the world where it's not singlehandedly "redefin[ing] the process of programming"...
Based on an accounting of the work involved, it's reasonable to charge, but based on the options available (and the relative unprovenness of the Wolfram Language), it's also perfectly reasonable for people like the parent to insist on free languages only. It's what Wolfram's competing with, at least in the view of the world where it's not singlehandedly "redefin[ing] the process of programming"...
> Not to defend Wolfram, but to understand this you'll have to understand that "The Wolfram Language" is not like the traditional "programming languages".
Of course not, its a New Kind of Programming Language.
Of course not, its a New Kind of Programming Language.
They also spend time and money keeping that dataset up-to-date.
Could you explain why you believe this and why it applies to languages but not other tools? I don't have a strong opinion either way, but to me it seems fair that people should be compensated for the innovative work they do.
I've done, and many of us do, tons of very valuable innovative work that we're not financially compensated for. There are other kinds of compensation, of course, and sometimes indirect financial benefits.
I just don't think the language will thrive as well as it could if the number of users is limited by a financial barrier. Sure, it will have users, and sure, they will find it useful, but a lot of its potential will go unrealized.
You could make the same argument with tools, so why are languages different? I think because they are more foundational.. other tools are built IN them not just using them. They become a substrate. Or not, if they're not widely used.
I just don't think the language will thrive as well as it could if the number of users is limited by a financial barrier. Sure, it will have users, and sure, they will find it useful, but a lot of its potential will go unrealized.
You could make the same argument with tools, so why are languages different? I think because they are more foundational.. other tools are built IN them not just using them. They become a substrate. Or not, if they're not widely used.
> You could make the same argument with tools, so why are languages different? I think because they are more foundational.. other tools are built IN them not just using them. They become a substrate. Or not, if they're not widely used.
What about the computer itself. I don't want to argue one way or the other but the hierarchy:
What about the computer itself. I don't want to argue one way or the other but the hierarchy:
Hardware (non-free)
OS (sometimes-free)
Programming language (mostly-free)
Programs (sometimes-free)
I think the important thing about the language being free is that it is key enabling feature of the list you just gave. If the Wolfram Language truly was free then Wolfram Research should be able to publish and distribute a language specification and it should be possible for a competing group like, say the team that made Octave, to create a competing platform for the Wolfram Alpha language. Besides a few bells and whistles in the IDE, a piece of source code written in the Wolfram Language should be portable to any platform that implements the language specification. At least, that is what I would like.
I think the reason this isn't done is because Wolfram Research would have to really take responsibility for calling this thing a programming language. They'd have to publish their sources or at least the requirements for what qualifies as a valid source. They'd also have to publish their curating methods so that anyone with access to their sources and the language specification could produce identical results to identical source code. Basically, their position would be no more privileged than Microsoft's with respect to CSharp and the .NET framework. I don't think Wolfram Research wants to face a Mono-like competitor for their language and that is why portraying the language as some general purpose tool for everyone rings hollow.
I think the reason this isn't done is because Wolfram Research would have to really take responsibility for calling this thing a programming language. They'd have to publish their sources or at least the requirements for what qualifies as a valid source. They'd also have to publish their curating methods so that anyone with access to their sources and the language specification could produce identical results to identical source code. Basically, their position would be no more privileged than Microsoft's with respect to CSharp and the .NET framework. I don't think Wolfram Research wants to face a Mono-like competitor for their language and that is why portraying the language as some general purpose tool for everyone rings hollow.
We talk about "commodity" hardware, and I wouldn't want to program on any other kind. My computers may not be free-as-in-beer but I can buy compatible hardware from many different sources, and the standards are published so I could build my own if I had the tools to. If there were a published standard and multiple independent implementations of the "wolfram language" I'd be willing to give it a go.
Price (and the possibility of future price changes,) is just one aspect of control in walled gardens.
There are good reasons some people want to steer clear of any vendor lock-in. If there can be comparable open implementations, I'll use those. If there can't be, then the prospect is that much more alarming.
There are good reasons some people want to steer clear of any vendor lock-in. If there can be comparable open implementations, I'll use those. If there can't be, then the prospect is that much more alarming.
Hardware is molecules, not bits.
What's the difference, in terms of this discussion?
They both have a cost.
They both have a cost.
The difference is that bits can be copied as well as transported for almost zero cost. The same is not true of molecules.
Marginal cost of zero doesn't mean total cost of zero. If you can't recover fixed costs, there is a problem...
But your argument implies that all video and audio and text content should be free. But it's not -- we pay content creators to create it, and if we didn't, a lot of that content wouldn't get created.
And to play the devil's advocate here: The supply of all video and audio and text content is ~infinite because of torrents, so the laws of supply and demand dictate that its price fall to ~0 for any finite demand.
As an example, if tomorrow I invented a machine that made unlimited free copies of soybeans and distributed those copies for ~$0 to any internet connected location on earth, the market value of soybeans would very quickly approach zero.
Whether or not my machine is illegal would be quite immaterial to the laws of economics, which would continue to propagate information about supply and demand through prices so long as my machine was working.
Of course, the same is true of corn and also intangible goods like massages [0]. By induction you might claim that the story for mp3's is the same.
[0] If you find a machine that gives unlimited massages at a distance, let me know immediately
As an example, if tomorrow I invented a machine that made unlimited free copies of soybeans and distributed those copies for ~$0 to any internet connected location on earth, the market value of soybeans would very quickly approach zero.
Whether or not my machine is illegal would be quite immaterial to the laws of economics, which would continue to propagate information about supply and demand through prices so long as my machine was working.
Of course, the same is true of corn and also intangible goods like massages [0]. By induction you might claim that the story for mp3's is the same.
[0] If you find a machine that gives unlimited massages at a distance, let me know immediately
And to play the devil's advocate here: The supply of all video and audio and text content is ~infinite because of torrents, so the laws of supply and demand dictate that its price fall to ~0 for any finite demand.
Nonono. The laws of supply and demand you're talking about only obtain under conditions of perfect competition, where goods are perfect substitutes for each other - commodity markets being the closest real-world example. By this argument, the price of opera should fall to zero because there's an oversupply of EDM and pop music. But if you want to listen to opera, chances are that you're not going to be satisfied by a new Katy Perry tune.
Nonono. The laws of supply and demand you're talking about only obtain under conditions of perfect competition, where goods are perfect substitutes for each other - commodity markets being the closest real-world example. By this argument, the price of opera should fall to zero because there's an oversupply of EDM and pop music. But if you want to listen to opera, chances are that you're not going to be satisfied by a new Katy Perry tune.
Of course you're right about that---the market value of a rare, non-torrentable opera recording ought not to be zero. But in practice the overwhelming majority of all content that anyone ever wants is eminently torrentable. I am not claiming that opera == Katy Perry, but rather that each of those has unlimited supply.
Who said our current state of affairs is optimal?
So really cheap hardware should be free, too?
Who should take on that cost?
Who should take on that cost?
I said almost zero, not zero. And even the cheapest hardware comes is still orders of magnitude away from the cheapness of copying bits. Also, I never said the parties involved in copying bits shouldn't bear the cost of doing so.
You said the cost for the copying/transferring of bits was almost zero, and I believe you said that programming languages should be free, because they are so cheap.
I countered that very cheap hardware would have to be free, following that logic.
Who are you to say what is cheap and what is not? Not to mention that orders of magnitude greater than almost zero is potentially still almost zero.
I countered that very cheap hardware would have to be free, following that logic.
Who are you to say what is cheap and what is not? Not to mention that orders of magnitude greater than almost zero is potentially still almost zero.
Hardware (sometimes free)
http://www.sparc.org/
http://www.sparc.org/
> I've done, and many of us do, tons of very valuable innovative work that we're not financially compensated for.
Arrangements in which you or others have previously engaged are not relevant, at least without an argument.
> I just don't think the language will thrive as well as it could if the number of users is limited by a financial barrier.
If this is actually your argument you should have lead with it. But it's not like Wolfram is new to the PL business, Mathematica has been pay since it was distributed on floppies and it has a large community. Making it free might make a stronger, larger community, but if you want to convince Wolfram to do that you'll need to propose a way to make up the lost revenue.
Arrangements in which you or others have previously engaged are not relevant, at least without an argument.
> I just don't think the language will thrive as well as it could if the number of users is limited by a financial barrier.
If this is actually your argument you should have lead with it. But it's not like Wolfram is new to the PL business, Mathematica has been pay since it was distributed on floppies and it has a large community. Making it free might make a stronger, larger community, but if you want to convince Wolfram to do that you'll need to propose a way to make up the lost revenue.
[deleted]
This is a platform, not just a language.
The same way that 'Mathematica' also has/is a language, but also a platform.
You can write whatever code you want, but you can only run it on their hosted platform which is not free to operate.
The same way that 'Mathematica' also has/is a language, but also a platform.
You can write whatever code you want, but you can only run it on their hosted platform which is not free to operate.
Ignoring all of the politics of "Free Software" and/or "Open Source Software", as a practical matter languages that are not available in no-cost implementations are rarely successful outside of very niche markets.
Though, arguably, the type of stuff Mathematica is used for is already sufficiently niche that this is less of a concern.
Though, arguably, the type of stuff Mathematica is used for is already sufficiently niche that this is less of a concern.
To be pedantic, Free/Open Source Software has nothing to do with the cost.
Except that they're not just providing a language, but a back-end for cloud computing.
I would be happy to do the computing on my own servers.
And should they give you the tera- or petabytes of data sets that constitute the actual value proposition of the Wolfram language? The data sets they keep current so when you ask for the flag of the largest country that says "good afternoon", you know you are getting the current largest country.
It seems to me that other people shouldn't demand the results of somebody else's efforts be released in any way other than the creator desires. Feel free to gather the data yourself, build a platform of your own, and then give it away, but the arrogance of expecting somebody else to do that for you is nothing short of shocking to me.
It seems to me that other people shouldn't demand the results of somebody else's efforts be released in any way other than the creator desires. Feel free to gather the data yourself, build a platform of your own, and then give it away, but the arrogance of expecting somebody else to do that for you is nothing short of shocking to me.
Servers include semantic update: I doubt you have the capacity to do that with the same commitment, or that Wolfram Language would make much sense without it.
OK, use something else then.
The Rasperberry PI contains a "free, period" release of the language: http://www.wolfram.com/raspberry-pi/
But no, the language is not open source, and that is unlikely to change in the future.
But no, the language is not open source, and that is unlikely to change in the future.
It looks like it is not a free trial but free with use limits.
IE You can use it for free forever, but just not too much each month. Pay for more CPU time after you hit your limit or wait until next month to get more free time.
IE You can use it for free forever, but just not too much each month. Pay for more CPU time after you hit your limit or wait until next month to get more free time.
It looks like there's also a 30-day limit on "deployments" in the free tier. It's not 100% clear to me what that means, but I'd guess it means public-facing apps built on top of the API need a paid account to deploy more than as temporary/test setups.