Wolfram Programming Cloud Is Live(blog.wolfram.com) |
Wolfram Programming Cloud Is Live(blog.wolfram.com) |
http://www.wolfram.com/language/fast-introduction-for-progra...
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.
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.
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 wonder if folks would be less cynical about this if they gave it a name other than 'the Wolfram Language' (how about 'Sym'?)
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.
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.
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?
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.
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.
> Otherwise please use the original title, unless it is misleading or linkbait.
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.
And what about the Discovery Platform and Data Science platform? How will these differ from Mathematica?
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.
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 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.
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.
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"...
Of course not, its a New Kind of Programming Language.
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.
Though, arguably, the type of stuff Mathematica is used for is already sufficiently niche that this is less of a concern.
But no, the language is not open source, and that is unlikely to change in the future.
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 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.
The emphasis in Discovery and Data Science platforms will be around workflow and reporting, though the features there haven't been finalized yet.
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 :)
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.
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.
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.
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.
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.
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.
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?)
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.
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).
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.
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 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.
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.
They both have a cost.
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.
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.
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.
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?
> 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.
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
Who should take on that cost?
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.
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.