Wolfram Programming Cloud(wolfram.com)
wolfram.com
Wolfram Programming Cloud
http://www.wolfram.com/programming-cloud/
16 comments
Mathematica is a product that uses the Wolfram Language. As will be the Programming Cloud.
"Mathematica in the cloud" would be Mathematica Online, a separate product from the Programming Cloud: http://www.wolfram.com/mathematica/online/
See http://www.wolframcloud.com/ for a wider overview.
The Programming Cloud is specifically focused around workflows and features that programmers are likely to want and need.
So I doubt any of us would have told you that the Programming Cloud is "Mathematica running on our servers with better data store and NLP integration." That's not the way we think or talk internally about our technology stack, and its certainly not the way we talk to customers.
"Mathematica in the cloud" would be Mathematica Online, a separate product from the Programming Cloud: http://www.wolfram.com/mathematica/online/
See http://www.wolframcloud.com/ for a wider overview.
The Programming Cloud is specifically focused around workflows and features that programmers are likely to want and need.
So I doubt any of us would have told you that the Programming Cloud is "Mathematica running on our servers with better data store and NLP integration." That's not the way we think or talk internally about our technology stack, and its certainly not the way we talk to customers.
Judging from the reactions in the press, and even in Mathematica user communities, there's a lot of confusion about what's coming. For some people, a bit of plain speaking, rather than marketing hyperbole and premature teasing, would be welcome. However, I'll admit that the WolframBuzzWord tactics are generating a lot of attention, which is probably the point.
"The Programming Cloud is specifically focused around workflows and features that programmers are likely to want and need." - that sounds like an awful marketing speak to me. What do you actually MEAN?
> "...this page seemed to be mostly marketing bullshit. For some reason that made them really defensive"
I do hope you were making a joke.
I do hope you were making a joke.
For what it's worth, I've also had a hard time recently understanding what the Wolfram Language and associated products are outside of the marketing bullshit.
There's only so much we can do before those products are released. The Programming Cloud will go live in the next few weeks, along with executable examples on various language and marketing pages.
For more information about the language, check out http://reference.wolfram.com/language/, as well as http://www.youtube.com/watch?v=_P9HqHVPeik
For more information about the language, check out http://reference.wolfram.com/language/, as well as http://www.youtube.com/watch?v=_P9HqHVPeik
Seems like lots of programmers despise advertising. It is an example of irrational religious behaviour, the very thing they claim to oppose.
How much of advanced technology was forgotten and eventually reinvented due to the lack of proper advertising?
Lisp and Smalltalk contained lots of ideas that made Wolfram products possible. Hackers who appreciate those ideas should probably be excited that a successful entrepreneur exists who makes larger audiences familiar with them at last.
How much of advanced technology was forgotten and eventually reinvented due to the lack of proper advertising?
Lisp and Smalltalk contained lots of ideas that made Wolfram products possible. Hackers who appreciate those ideas should probably be excited that a successful entrepreneur exists who makes larger audiences familiar with them at last.
> Seems like lots of programmers despise advertising. It is an example of irrational religious behaviour, the very thing they claim to oppose.
What is irrational or religious about despising attempts designed to obfuscate meaning? Good advertising would communicate clearly. If you can find programmers that also despise non-deceptive advertising you might be onto something.
What is irrational or religious about despising attempts designed to obfuscate meaning? Good advertising would communicate clearly. If you can find programmers that also despise non-deceptive advertising you might be onto something.
I know those guys are super smart and all, but I can't read any of their marketing materials without my bullshit detector going haywire.
Wolfram stuff is like a completely different world that doesn't acknowledge anyone else. In context to them it makes sense, but to everyone else it's WTF and meh and not much in between.
I remember the pre-Wolfram Alpha marketing. It wasn't nearly as impressive as they made it out to be. The product was cool but to hype it up like that only did damage.
To be honest it always reminds me of Futurama: "welcome to the world of tomorrow!" (which is actually pretty shitty).
I remember the pre-Wolfram Alpha marketing. It wasn't nearly as impressive as they made it out to be. The product was cool but to hype it up like that only did damage.
To be honest it always reminds me of Futurama: "welcome to the world of tomorrow!" (which is actually pretty shitty).
The problem for them of course is that they exist in context to everything else in the world. So a "huge" innovation to their local context, because they just realized something everybody else knows, is just "meh" or "already tried" and determined to be uninteresting or useless.
The problem for everybody else is that there's just enough interesting in Wolfram's output to make it hard to dismiss outright.
The problem for everybody else is that there's just enough interesting in Wolfram's output to make it hard to dismiss outright.
> determined to be uninteresting or useless.
Your thesis seems to be that we're so naive that we re-invent discarded or failed ideas and call them innovations. Can you give an example?
I'll give you just a two counter-examples off the top of my head.
1. Our frontend uses what turned out to be functional reactive programming to accomplish seamlessly interactive UI. And FRP is widely considered to be a Good Idea.
2. We invented the notebook-based REPL as the world knows it today, which is of course copied by iPython (to such rave reviews). In fact, our language embraces homoiconicity to such a degree that our notebooks are themselves Wolfram Language expressions -- iPython is just JSON.
Seems like we're ahead of the curve in those two cases.
Your thesis seems to be that we're so naive that we re-invent discarded or failed ideas and call them innovations. Can you give an example?
I'll give you just a two counter-examples off the top of my head.
1. Our frontend uses what turned out to be functional reactive programming to accomplish seamlessly interactive UI. And FRP is widely considered to be a Good Idea.
2. We invented the notebook-based REPL as the world knows it today, which is of course copied by iPython (to such rave reviews). In fact, our language embraces homoiconicity to such a degree that our notebooks are themselves Wolfram Language expressions -- iPython is just JSON.
Seems like we're ahead of the curve in those two cases.
Well the idea of building as much as possible into the language is old and has repeatedly failed. Languages like PL/1, APL, and to a lesser extent PHP have all tried and failed at this. People do not need huge languages with as much stuff as possible crammed into them. What they need are languages where you can be reasonably certain, and maybe even formally prove things about the execution of your code (putting everything in The Cloud (tm) also hampers this), and they need to be able to grow the language to fit their needs (e.g. Scheme, Haskell, Clojure, etc... are all pretty good at this).
The whole idea of claiming "moar data" solves everything comes across as incredibly naive and ignorant of what people like Tony Hoare, Dijkstra, or Alan Perlis have said about computing.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult -- Tony Hoare
The whole idea of claiming "moar data" solves everything comes across as incredibly naive and ignorant of what people like Tony Hoare, Dijkstra, or Alan Perlis have said about computing.
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult -- Tony Hoare
> People do not need huge languages with as much stuff as possible crammed into them.
I think you should replace "people" with "systems programmers" in order not to express an opinion that will in time (if not already) prove to be anachronistic and narrow-minded.
And the kinds of things we're "cramming in" (in reality, very slowly and methodically adding) have little to do with what you'd find in the languages you mention.
Think of it like this: standard libraries are great, but give you access to functionality that is effectively linear in the amount of stuff you learn, because they cannot be too tightly coupled in order to remain modular in the usual way.
With the Wolfram Language, you have more of a network effect: the more you learn, the more useful what you already know becomes, because the topic modelling you did over there can produce a network you can cluster over here and that you can then decorate with the graphics primitives you just learned about.
> The whole idea of claiming "moar data" solves everything comes across as incredibly naive and ignorant of what people like Tony Hoare, Dijkstra, or Alan Perlis have said about computing.
What is the "everything" that needs to be "solved"? Writing systems software?
I'm sure having graphs and images and timeseries built into your language isn't tremendously useful for writing a server. But people have already written servers. We don't need more languages to write servers (other than Rust or Go, perhaps).
We "need" the next generation of smart apps, things you couldn't even contemplate if you didn't already have access to curated data and algorithms that all work together. Or rather, that's what Wolfram Research is trying to make possible.
I think you should replace "people" with "systems programmers" in order not to express an opinion that will in time (if not already) prove to be anachronistic and narrow-minded.
And the kinds of things we're "cramming in" (in reality, very slowly and methodically adding) have little to do with what you'd find in the languages you mention.
Think of it like this: standard libraries are great, but give you access to functionality that is effectively linear in the amount of stuff you learn, because they cannot be too tightly coupled in order to remain modular in the usual way.
With the Wolfram Language, you have more of a network effect: the more you learn, the more useful what you already know becomes, because the topic modelling you did over there can produce a network you can cluster over here and that you can then decorate with the graphics primitives you just learned about.
> The whole idea of claiming "moar data" solves everything comes across as incredibly naive and ignorant of what people like Tony Hoare, Dijkstra, or Alan Perlis have said about computing.
What is the "everything" that needs to be "solved"? Writing systems software?
I'm sure having graphs and images and timeseries built into your language isn't tremendously useful for writing a server. But people have already written servers. We don't need more languages to write servers (other than Rust or Go, perhaps).
We "need" the next generation of smart apps, things you couldn't even contemplate if you didn't already have access to curated data and algorithms that all work together. Or rather, that's what Wolfram Research is trying to make possible.
Out of curiosity, would you classify this in the 4GL camp?
Not to denigrate the technology and functionality that the Wolfram language is exposing, but it sure sounds a lot like the 4GL pitches from the 90s. Is that a fair comparison?
Not to denigrate the technology and functionality that the Wolfram language is exposing, but it sure sounds a lot like the 4GL pitches from the 90s. Is that a fair comparison?
So in conclusion, it's not a systems programming language.
I think we got that.
So to break it down, and this is how I understand it as a user, it's a collection of algorithms, Lego bricks of math and a library of data sources glued together with a functional REPL that is semantically represented as a notebook.
Can you stick that on the web site somewhere without the millions of bullet points, marketoid spew and weaseling.
I think we got that.
So to break it down, and this is how I understand it as a user, it's a collection of algorithms, Lego bricks of math and a library of data sources glued together with a functional REPL that is semantically represented as a notebook.
Can you stick that on the web site somewhere without the millions of bullet points, marketoid spew and weaseling.
Maybe system programmers are “doing it wrong” now?
Even when you write a simple VGA driver you have to solve some equations. They are simple, so what does an average [good] C programmer does? He writes them down in his favourite inexpressive specialized language. Consequences: 1) a simple concept immediately becomes an incomprehensible mess; 2) approaches using more advanced ideas rarely get the proper attention because a system programmer is unable even to write them down, let alone reason about them and tweak them. There is no reason why a VGA driver for certain microprocessor could not be generated by a high-level language with the basic concepts behind it expressed more clearly, and nevertheless formally.
Even when you write a simple VGA driver you have to solve some equations. They are simple, so what does an average [good] C programmer does? He writes them down in his favourite inexpressive specialized language. Consequences: 1) a simple concept immediately becomes an incomprehensible mess; 2) approaches using more advanced ideas rarely get the proper attention because a system programmer is unable even to write them down, let alone reason about them and tweak them. There is no reason why a VGA driver for certain microprocessor could not be generated by a high-level language with the basic concepts behind it expressed more clearly, and nevertheless formally.
Agree with you entirely (especially after recently writing an SSDP and UPnP stack) but unfortunately the academics with all the supposed solutions have managed to deliver nothing with any momentum, so we're stuck with a 40 year old programming system and 30 year old abstractions.
Then again, you know what? It works pretty well so perhaps we're not doing it wrong
Then again, you know what? It works pretty well so perhaps we're not doing it wrong
My God, the keyboard courage runs thick on this thread.
Yeah it does. We've experienced the emperor's new clothes before so scepticism and rational analysis is important.
The notebook REPL has actually been around way before Mathematica. Probably 1972. Perhaps it wasn't semantically complete but it was essentially there. I would suggest the concept is obvious.
Great examples and way ahead indeed!
On a similar note, it would really help if the website for the Wolfram Programming Cloud had just one bloody-awesome/blow-me-away example or tutorial that would make it accessible to a lot of capable programmers who may not have used a Mathematica Notebook.
Folks who haven't used Mathematica ever - I recommend the Home Edition. Yes, it is worth paying for it!
On a similar note, it would really help if the website for the Wolfram Programming Cloud had just one bloody-awesome/blow-me-away example or tutorial that would make it accessible to a lot of capable programmers who may not have used a Mathematica Notebook.
Folks who haven't used Mathematica ever - I recommend the Home Edition. Yes, it is worth paying for it!
Thanks!
A blow-me-down tutorial (or better yet, video with updating live REPL) is definitely on the cards.
A blow-me-down tutorial (or better yet, video with updating live REPL) is definitely on the cards.
I'm willing to admit I lack imagination or vision here. I think the lack of killer examples to sort of show me the way here is hobbling me. Wolfram's demo video was interesting but viewed to me more like a demo of a fancy calculator than a path towards a new way of doing development. I have a drawer full of fancy calculators I don't use because my need to "compute" things in such a general sense as presented here is pretty rare, or is so narrow in scope that I can usually just go hunt down the relevant information myself in less time than it takes to learn all of this new stuff.
I'll probably wait on the sidelines for a while and wait to see what kinds of things come out of this work.
Please take my skepticism as a healthy challenge and not as dismissal. The day the Wolfram language shows me something that fundamentally transforms some aspect of my life I didn't know needed transforming, I'll sign up.
I'll probably wait on the sidelines for a while and wait to see what kinds of things come out of this work.
Please take my skepticism as a healthy challenge and not as dismissal. The day the Wolfram language shows me something that fundamentally transforms some aspect of my life I didn't know needed transforming, I'll sign up.
And they've written so much... that I can't even make sense of what it's all about.
This may be worth it for the transition from lab project to app prototype but I would be seriously wary of deploying anything significant on a proprietary cloud in a proprietary language. Does anyone remember when Google App Engine hiked their prices? A lot of people had to switch off the platform because the traffic patterns of their apps did not work with the new pricing. That could very easily happen here and you'd have to port to a different language, not just a different runtime.
In my senior year of college we built some computer vision stuff in matlab (pretty similar) that we ported to C++ to put in an iOS app. It would have been cool to get a quick prototype by exposing some of the functions as web services but there's no way I would release on the app store with that setup.
In my senior year of college we built some computer vision stuff in matlab (pretty similar) that we ported to C++ to put in an iOS app. It would have been cool to get a quick prototype by exposing some of the functions as web services but there's no way I would release on the app store with that setup.
There's no way a proprietary environment can be the future of programming, but Wolfram does have the right ideas.
Ctrl-F for "symbolic" in that page returns 14 results. The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext--a feat that Lisp and Smalltalk and a horde of gimmicky visual languages* couldn't do. Wolfram Language won't succeed here, but they'll get closer than anyone else has.
* Not saying that visual languages are inherently gimmicky; just that when you do write one, it's extremely tempting to fall into toyland.
Ctrl-F for "symbolic" in that page returns 14 results. The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext--a feat that Lisp and Smalltalk and a horde of gimmicky visual languages* couldn't do. Wolfram Language won't succeed here, but they'll get closer than anyone else has.
* Not saying that visual languages are inherently gimmicky; just that when you do write one, it's extremely tempting to fall into toyland.
> The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext--a feat that Lisp and Smalltalk and a horde of gimmicky visual languages* couldn't do.
I'm sure they are referring to how the code is evaluated [1] vs. how it is stored and manipulated by the programmer. Lisp and Prolog are the canonical examples of symbolic languages, and they are both based on plain text.
[1] http://en.wikipedia.org/wiki/Symbolic_programming
I'm sure they are referring to how the code is evaluated [1] vs. how it is stored and manipulated by the programmer. Lisp and Prolog are the canonical examples of symbolic languages, and they are both based on plain text.
[1] http://en.wikipedia.org/wiki/Symbolic_programming
That's right.
We can serialize any Wolfram Language expression as ASCII, if necessary (and functions like Save do exactly that -- traversing the symbol graph to find all definitions that a piece of code depends on) and dumping it out.
But you wouldn't want to do that in the case of packed arrays, timeseries, or images -- the result would be incomprehensible (and incomprehensibly large).
Ultimately, Wolfram Language code consists of expression trees, these trees are "conceptually" the equivalent of their FullForm (http://reference.wolfram.com/language/ref/FullForm.html). What makes a WL expression "code" instead of "data" is that evaluating it will change the state of the kernel so that it has new rules attached to various symbols (functions + variables).
Plaintext files are just one vehicle for WL expressions. And in many cases there are cool things you can do that require the code to live in an IDE that can render WL expressions natively, such as
We can serialize any Wolfram Language expression as ASCII, if necessary (and functions like Save do exactly that -- traversing the symbol graph to find all definitions that a piece of code depends on) and dumping it out.
But you wouldn't want to do that in the case of packed arrays, timeseries, or images -- the result would be incomprehensible (and incomprehensibly large).
Ultimately, Wolfram Language code consists of expression trees, these trees are "conceptually" the equivalent of their FullForm (http://reference.wolfram.com/language/ref/FullForm.html). What makes a WL expression "code" instead of "data" is that evaluating it will change the state of the kernel so that it has new rules attached to various symbols (functions + variables).
Plaintext files are just one vehicle for WL expressions. And in many cases there are cool things you can do that require the code to live in an IDE that can render WL expressions natively, such as
Blur[<<picture of dog>>]
GeoLocation[<<NLP interpretation of "berlin">>]
The way I interpret it, they're aiming (rightly) to dismount programming from its local maxima in expressivity that is plaintext
Where do you get this idea, out of curiosity? Every demonstration of Wolfram Language I've seen has been plain text. And what makes you think they'll get farther than everyone else?
Where do you get this idea, out of curiosity? Every demonstration of Wolfram Language I've seen has been plain text. And what makes you think they'll get farther than everyone else?
When I say plaintext, I mean like a .c file--a bag of bytes that may or may not parse into the AST you intend. Modern editors dress plaintext up with syntax highlighting, auto-complete, folding, and such--the code has a veneer of structure--but the basic representation remains plaintext. (And for good reason... plaintext is easy to edit with existing editors, tractable, easy to parse, somewhat easy to tool, moderately easy to version control, and hard but possible to transform automatically. But I believe plaintext is only a local maxima in code representation. We just don't have a good enough editor for code ASTs (yet)).
Now in the Wolfram Language REPL they have some rich input capabilities like http://reference.wolfram.com/language/example/BooleanOperati... . I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu... .
I should have said that they've gotten farther than anyone else so far, perhaps, but I haven't tried WL yet, so who knows?
Now in the Wolfram Language REPL they have some rich input capabilities like http://reference.wolfram.com/language/example/BooleanOperati... . I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu... .
I should have said that they've gotten farther than anyone else so far, perhaps, but I haven't tried WL yet, so who knows?
Yeah, with respect, I think you're being duped. What you're seeing is plain text being drawn as images, making you think the images are input. You only have to click the code to see the plain text (and its not pretty).
Not only have they not gone farther than others, I cant find a single instance of anything in WL that's not plainly plain text. They have interesting output, not particularly interesting input.
Not only have they not gone farther than others, I cant find a single instance of anything in WL that's not plainly plain text. They have interesting output, not particularly interesting input.
Damn, that's too bad. Oh well. It's a closed source dead end anyway.
Time to dust off the old side project.
Time to dust off the old side project.
I think the great thing here is the output; better than anything we have in open source so far. I takes a very large amount of effort to make something like that for your language of choice. For the input I agree; it's text and not very nice.
> I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu.... .
You suspect wrong.
You suspect wrong.
For API building this is a much needed paradigm shift to functional programming. I met some backend engineers who built the backend of an very large and complex system with OCaml, and they never wrote a single unit test because they didn't really have to. Although humans are wired to think procedurally, a pure functional style can eliminate many of the holes that are easy to miss in a procedural program.
The only problem I see is that Mathemati... I mean, the Wolfram Language, is not open source. This means that there could be some application-level bug in the service running your API, and no community to quickly identify and patch those bugs. Until things become more transparent, the handful of backend engineers willing to write in a functional style will keep using OCaml or Erlang.
The only problem I see is that Mathemati... I mean, the Wolfram Language, is not open source. This means that there could be some application-level bug in the service running your API, and no community to quickly identify and patch those bugs. Until things become more transparent, the handful of backend engineers willing to write in a functional style will keep using OCaml or Erlang.
> Until things become more transparent, the handful of backend engineers willing to write in a functional style will keep using OCaml or Erlang.
Hey Keshav!
I think it's a more complicated story than that. Our ambition is larger than converting existing functional language programmers -- a lot of whom are happy (and passionate) about their current tools.
I think it is a much wider stratum of smart people who want to do things that were hitherto impossible (or impractical) without a vast amount of built-in knowledge and algorithms. And their potential will be unlocked by the "curated computing experience" that we provide.
Personally, I want everyone to be able to do the kinds of cool things that I regularly do on weekend projects, and that I know cannot be achieved in anything other than Wolfram Language.
And frankly, it'll be good for all of us to have an influx of new people with new ideas from different backgrounds who want to build and compute new and different kinds of things. Our tribe is still quite homogenous.
Although I suspect that at first it will be threatening to those of us who derive our pride (and job security) from being masters of somewhat arcane tools, processes, and knowledge.
Hey Keshav!
I think it's a more complicated story than that. Our ambition is larger than converting existing functional language programmers -- a lot of whom are happy (and passionate) about their current tools.
I think it is a much wider stratum of smart people who want to do things that were hitherto impossible (or impractical) without a vast amount of built-in knowledge and algorithms. And their potential will be unlocked by the "curated computing experience" that we provide.
Personally, I want everyone to be able to do the kinds of cool things that I regularly do on weekend projects, and that I know cannot be achieved in anything other than Wolfram Language.
And frankly, it'll be good for all of us to have an influx of new people with new ideas from different backgrounds who want to build and compute new and different kinds of things. Our tribe is still quite homogenous.
Although I suspect that at first it will be threatening to those of us who derive our pride (and job security) from being masters of somewhat arcane tools, processes, and knowledge.
What do you say to people like Guy Steele who believe that small languages that can be grown by their users are the way forward, and do not want to pay to use a closed source programming language, ever?
(fyi I'm referring to this famous talk he gave http://youtu.be/_ahvzDzKdB0 )
(fyi I'm referring to this famous talk he gave http://youtu.be/_ahvzDzKdB0 )
Thanks for the talk, I'll watch it tomorrow (gotta catch Snowden's interview at 10am).
But in the meantime, I'd say: pick your battles.
Many developers, including me, moved from Linux to OS X so they could get on with their lives.
And we pay for things much lower on the abstraction hierarchy: CPUs and GPUs and their proprietary IP, physical hardware, various industry-group protocols and standards, OSes in some cases, hosting.
And we know from experience that the whole hierarchy tends to move down as we build on it -- maybe the time has come for that to happen to languages, too.
If, in time, the things that WL is doing inspire higher-level, free languages to raise the abstraction (and semantic) bar, I think we'll all benefit. For now, we can only do what we do because we're a private company.
But in the meantime, I'd say: pick your battles.
Many developers, including me, moved from Linux to OS X so they could get on with their lives.
And we pay for things much lower on the abstraction hierarchy: CPUs and GPUs and their proprietary IP, physical hardware, various industry-group protocols and standards, OSes in some cases, hosting.
And we know from experience that the whole hierarchy tends to move down as we build on it -- maybe the time has come for that to happen to languages, too.
If, in time, the things that WL is doing inspire higher-level, free languages to raise the abstraction (and semantic) bar, I think we'll all benefit. For now, we can only do what we do because we're a private company.
For some background on the language, check out Stephen Wolfram's intro video: http://www.youtube.com/watch?v=_P9HqHVPeik
The demos are all pretty impressive, and putting aside the breathless marketing of the programming cloud page, this looks awesome.
The demos are all pretty impressive, and putting aside the breathless marketing of the programming cloud page, this looks awesome.
As a long time Mathematica (MMA) user I can say I am confused and bemused as to where Wolfram is heading. They have their fingers in so many pies its hard to work out whats going on.
Recent Wolfram marketing on MMA/Wolfram language seem to be aimed at consumer, Facebook and Hedgefund users rather than their traditional base in the Sciences and Engineering.
There are plenty of pretty short examples, but the MMA kernel grinds to a halt when pushing into larger problem sets. The CUDA and Parallel processor commands are limited and haven't really been updated in the last few years (pushing you back to other tools).
Developing on Workbench is anything but a joy and without even considering speed one is better off developing on a regular programming IDE for programs requiring multiple libraries. The notebook interface just doesn't handle large programs well.
While functional programming is wonderful for some things, it is incredibly hard to debug with the current tools and effectively provides a level of self obfuscation when used exclusively.
The Computable Document Format (CDF) is a nice idea but the licensing terms are too restrictive for any commercial work. At present CDF also has a pretty slow, buggy interpreter.
All that said MMA is a great tool for early prototyping and a wide range of analysis, you just need to consider switching to something else if you get over several pages of code or utilize more than a few of your own libraries.
Like others have said, there are lots of tools out there and a combination of them will still be needed to produce the best outcome after the release of MMA10 and the Wolfram Cloud.
Recent Wolfram marketing on MMA/Wolfram language seem to be aimed at consumer, Facebook and Hedgefund users rather than their traditional base in the Sciences and Engineering.
There are plenty of pretty short examples, but the MMA kernel grinds to a halt when pushing into larger problem sets. The CUDA and Parallel processor commands are limited and haven't really been updated in the last few years (pushing you back to other tools).
Developing on Workbench is anything but a joy and without even considering speed one is better off developing on a regular programming IDE for programs requiring multiple libraries. The notebook interface just doesn't handle large programs well.
While functional programming is wonderful for some things, it is incredibly hard to debug with the current tools and effectively provides a level of self obfuscation when used exclusively.
The Computable Document Format (CDF) is a nice idea but the licensing terms are too restrictive for any commercial work. At present CDF also has a pretty slow, buggy interpreter.
All that said MMA is a great tool for early prototyping and a wide range of analysis, you just need to consider switching to something else if you get over several pages of code or utilize more than a few of your own libraries.
Like others have said, there are lots of tools out there and a combination of them will still be needed to produce the best outcome after the release of MMA10 and the Wolfram Cloud.
Is this another one of those Wolfram projects where the results are returned as images?
I worked at Wolfram about twenty years ago, where I met a guy named Dan who was (at the time) quietly hacking on a side project to put Mathematica on the web. Eventually this project became "The Integrator" (and surprisingly, seems to live on as integrals.com).
At first, The Integrator only returned results in mma syntax. If you entered the expression `Cos[x]`, it would return - literally - `Sin[x]`. This was neat and all, but once you had a result with exponentiation or division or what not, you'd want a prettier result. For example, if you asked for the integral of `Sin[x^2]`, it would spit out `Sqrt[Pi/2]FresnelS[Sqrt[2/Pi]x]`, which, you know, ew.
Twenty years ago, of course, there was no MathML - there wasn't even a working group. So in order to provide a prettier result, he returned a GIF with the Math-rendered output. Because this was back when we were still using client-side imagemaps and some browsers still didn't support inline jpegs. So this quick hack was totally reasonable.
Since The Integrator's compute backend was actually on his desk, he put a caching layer in front of the Mathematica instance. It was a trivial one, so if you asked for the integral of Sin[x], it would just look for Sin[x].gif in the cache directory and if that existed, it wouldn't send the query of to the Mathematica backend.
Unsurprisingly, this led to us kids just stuffing a bunch of crazy GIFs into the cache directory. Dan started it - if you tried to integrate his initials, it would return a picture of him. After that, though, we piled on and eventually you could integrate all our names, as well as a bunch of internal jokes.
I worked on The Integrator after Dan left, and of course I kept the easter eggs, but at some point it was handed off to another team who tried to create some more general web front-end to Mathematica. This team sadly lacked both Dan's cleverness and his sense of humor, so not only was the software slow and clunky, but it also lacked the easter eggs.
I'm always surprised that Wolfram Alpha - twenty years later - still renders its results and returns a GIF. You'd think that we could do a little bit better by now. I just hope that somewhere, one of the people working way too many hours to keep that site online has slid some easter eggs in.
At first, The Integrator only returned results in mma syntax. If you entered the expression `Cos[x]`, it would return - literally - `Sin[x]`. This was neat and all, but once you had a result with exponentiation or division or what not, you'd want a prettier result. For example, if you asked for the integral of `Sin[x^2]`, it would spit out `Sqrt[Pi/2]FresnelS[Sqrt[2/Pi]x]`, which, you know, ew.
Twenty years ago, of course, there was no MathML - there wasn't even a working group. So in order to provide a prettier result, he returned a GIF with the Math-rendered output. Because this was back when we were still using client-side imagemaps and some browsers still didn't support inline jpegs. So this quick hack was totally reasonable.
Since The Integrator's compute backend was actually on his desk, he put a caching layer in front of the Mathematica instance. It was a trivial one, so if you asked for the integral of Sin[x], it would just look for Sin[x].gif in the cache directory and if that existed, it wouldn't send the query of to the Mathematica backend.
Unsurprisingly, this led to us kids just stuffing a bunch of crazy GIFs into the cache directory. Dan started it - if you tried to integrate his initials, it would return a picture of him. After that, though, we piled on and eventually you could integrate all our names, as well as a bunch of internal jokes.
I worked on The Integrator after Dan left, and of course I kept the easter eggs, but at some point it was handed off to another team who tried to create some more general web front-end to Mathematica. This team sadly lacked both Dan's cleverness and his sense of humor, so not only was the software slow and clunky, but it also lacked the easter eggs.
I'm always surprised that Wolfram Alpha - twenty years later - still renders its results and returns a GIF. You'd think that we could do a little bit better by now. I just hope that somewhere, one of the people working way too many hours to keep that site online has slid some easter eggs in.
No. Results can be returned as plain text, images, Instant-APIs[1], WL-code and other.
[1] http://reference.wolfram.com/language/guide/CreatingAnInstan...
(Disclaimer: I work for Wolfram Research)
[1] http://reference.wolfram.com/language/guide/CreatingAnInstan...
(Disclaimer: I work for Wolfram Research)
Unless you pay, I guess.
No, it is same one.
For me the real achievement of Wolfram is the visualization capabilities. The knowledge bases are nice if you happen to be interested in a domain that is represented, and they make for great (controlled) demonstrations, but Wolfram Alpha (which taps these same knowledge bases) really fails often when making arbitrary but reasonable queries.
I think Wolframs visualization libs set a high bar, though, and I hope non-closed communities (like the python scientific/mathematic programming community, the R community, etc) will rally to meet the challenge.
I think Wolframs visualization libs set a high bar, though, and I hope non-closed communities (like the python scientific/mathematic programming community, the R community, etc) will rally to meet the challenge.
My favourite Alpha goof is it interpreting the Planck mass as Max Planck's weight.
That's fun, but seems to be fixed:
http://www.wolframalpha.com/input/?i=+Planck+mass
http://www.wolframalpha.com/input/?i=+Planck+mass
It shows up in more complex queries:
http://www.wolframalpha.com/input/?i=+Planck+mass%2Ftau+mass
That´s why I think that it can only be useful if its integrable via APIs and/or iframe widgets. I fail to see how can one do standalone apps with it.
"THE WORLD'S HIGHEST LEVEL LANGUAGE" <-- based on what?
A report from the International Language-Level Assessment Body.
Seriously though, it doesn't seem too far-fetched a claim after seeing all the stuff demoed in the screencast they put out:
http://youtu.be/_P9HqHVPeik
Getting pedantic, I suppose there's a distinction between the language in isolation and with its stdlib/environment.
Seriously though, it doesn't seem too far-fetched a claim after seeing all the stuff demoed in the screencast they put out:
http://youtu.be/_P9HqHVPeik
Getting pedantic, I suppose there's a distinction between the language in isolation and with its stdlib/environment.
Looks like mathematica in a web browser to me. Probably cheaper as well.
So it's not all that high level. It is compared to Fortran and floats somewhere between R and Octave.
So it's not all that high level. It is compared to Fortran and floats somewhere between R and Octave.
IMO, the only reason you would say that is that you either know nothing about Mathematica, or that your knowledge of it is very superficial (speaking as someone who uses it daily).
I actually used it for about 3 years (2009-2012) for stochastic modelling (insurance). We moved off the platform because to be honest we rewrote most of the functionality we used in C# over a couple of weekends.
When I make those comments, they are about the language, not the ecosystem or the product as a whole.
The language is merely ok.
The ecosystem, particularly with the amount of data feeds you can plug into it is pretty good as is the sheer enormity of the library of off-the-shelf functions it gives you.
When I make those comments, they are about the language, not the ecosystem or the product as a whole.
The language is merely ok.
The ecosystem, particularly with the amount of data feeds you can plug into it is pretty good as is the sheer enormity of the library of off-the-shelf functions it gives you.
Ok, your comment was not about what I thought it was (if I understand your response). It was really about how fast Mathematica is and not about the symbolic functional / lisp like / whatever of the language?
It's more about what people use it for and how they use it rather than capabilities. I was a little cranky and sarcastic initially and I don't think that came across clearly!
"It is compared to Fortran and floats somewhere between R and Octave."
I haven't heard a more amusingly wrong characterization of our language in a long, long time.
I haven't heard a more amusingly wrong characterization of our language in a long, long time.
Sorry there was a little intentional derision in that comment.
My gripe is more that for the multitude of problem domains that you can represent in mathematica, a huge amount can be done off the shelf for the same effort with something a lot cheaper if not entirely free. Very few people need or use the capabilities past the very basics.
My gripe is more that for the multitude of problem domains that you can represent in mathematica, a huge amount can be done off the shelf for the same effort with something a lot cheaper if not entirely free. Very few people need or use the capabilities past the very basics.
I think that Mathematica is innovative and love Mathematica. What I object to is that pretty much everything I've seen in the ads is touted as "revolutionary" when, in fact, it pretty much seems like a small upgrade to Mathematica as we know it today. One of the breathless accolades I read touted the "new" way you could type a one liner and have a video of an outline from your cam. Very nice, but I went to my old version of Mathematica, typed in the exact same thing with the exact same results. So while it's cool that Mathematica/Wolfram Language can do this, at this point in time it's hard to see where the new, circa 2014 revolution is coming about.
Here's a writeup by David Auerbach on the Wolfram Programming Language:
http://www.slate.com/articles/technology/bitwise/2014/03/ste...
It's hard to see this gaining traction in a world with the likes of iPython, Octave, R, etc.
Cool, is Wolfram programming language basically Mathematica + some special domain-area libraries?
Here is my take about the difference between Mathematica and the Wolfram Language: Mathematica is the combination of an interactive front end for writing code/functions etc., sending them to the Mathematica Kernel, and the displaying the results in the form specified by a functional wrapper you specified. The Wolfram Language is what you use to talk to the Mathematica kernel.
But you can also write and save WL code and submit it to the kernel directly. It will do whatever it's supposed to do: acquire and process data, save the results, and it includes all of the familiar Mathematica capabilities: image processing, integrating functions, finding the solution for an equation. You can do this in the kernel now.
The current development seems to be an extension of the range of the current WL as used in Mathematica (the front end/kernel package) into a general purpose language that includes all of the WL's current capabilities plus various new ones that were missing. The WL preliminary documentation site talks about the new stuff, but it's hard to know what's new if you aren't familiar with the current version.
But you can also write and save WL code and submit it to the kernel directly. It will do whatever it's supposed to do: acquire and process data, save the results, and it includes all of the familiar Mathematica capabilities: image processing, integrating functions, finding the solution for an equation. You can do this in the kernel now.
The current development seems to be an extension of the range of the current WL as used in Mathematica (the front end/kernel package) into a general purpose language that includes all of the WL's current capabilities plus various new ones that were missing. The WL preliminary documentation site talks about the new stuff, but it's hard to know what's new if you aren't familiar with the current version.
needs a tl;dr.
for its tl;dr. I mean seriously, this page must have 50 bullets on it.
I also told them that the community seems confused about the product and that this page seemed to be mostly marketing bullshit. For some reason that made them really defensive, and they explained "It's pretty clear from the page what we're offering and the people we're trying to reach will see the value."
FYI to those wondering.