taliesinb

> I suspect these are still underpinned by plaintext dumps internally, though, judging by http://reference.wolfram.com/language/tutorial/VariablesInPu.... .

You suspect wrong.

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

   Blur[<<picture of dog>>] 

or

   GeoLocation[<<NLP interpretation of "berlin">>]

For machines, the thing now known as the Wolfram Symbolic Protocol is used to talk WL expressions over the wire. And there are two efficient binary serialization formats: "MX" and "WDX".

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

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

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

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.

A brief note from experience: Viola Jones is only well suited to images that are oriented in a specific direction (e.g. faces), rather than rotation-invariant (e.g. cars as seen from satellites).

This is kind of a pattern with CV: it's still far more "art" than "science" at this point.

RemoveBackground in the Wolfram Language...

http://reference.wolfram.com/language/ref/RemoveBackground.h...

Nicely put.

> why not from code?

We build networks of lots of different kinds against our own codebases and databases. And personally I've done a bunch of experiments around visualizing code in the past.

Unfortunately, I don't think I, or anyone else at the company, has convincingly cracked the problem yet. Generally, the visualizations look pretty, but they aren't "tactile" or practical enough to be useful.

But you've convinced me that it would be worth digging up some of my old experiments and writing a blog post around them, so that at least any progress I've made can be carried further by other people.

> This seems like they have essentially codified wolfram alpha's many APIs and created the biggest, baddest standard library any language has ever seen, and slapped on some functions to access everything with.

Yes! I couldn't have said it better!

How do you represent queries? That's really, for me, the most interesting question.

Yes! The prospect of doing that deeply and seriously is probably the single thing I'm most excited about tackling next.

There's a whole tier of previously impractical metaprogramming that would come with being able to analyze and manipulate programs (and commit histories) as easily as data.

Syntactic macros are just the teeniest tip of the iceberg!

> recursive descent parsing

The parser is Java, actually. And it's not recursive descent.

> tasks well suited for it

Fancy that! Using a language for things it is well suited to! :)

> compiled and JVM languages stitched together with Mathematica

A lot of stuff is still WL though. Data curation, evaluation, scanning, typesetting, formatting, and, you know, the actual computation in doing something like http://www.wolframalpha.com/input/?i=regression+of+literacy%...

But it seems like you're complaining the backend isn't written in Wolfram Language? The JVM is great at that stuff! I don't call that ball-of-mud at all, just using the right tool for the job.

The video is great, I stayed up early into the morning watching it!

Indeed, I wish that more academics made the effort to create such accessible summaries of their work.

At http://deep.is/deepdb-genesis-of-invention-iii/, the chief scientist of this company credits the following four "axioms" for his "General Theory of Information":

Axiom 1: Information is a sequence of Information (self-similar) that is segmented by consistent (well-formed) order.

Axiom 2: Segmented Information is addressable by the First where a sequence of Firsts is a Segment of Summarization.

Axiom 3: Information of a Segment is equal distance to the sequence of Information between non-associated Summarizations.

Axiom 4: Sequenced Information is in direction relation to former and later Information of which Patterns can be Matched.

I don't know what any of that means. Worse, it sounds to me like "cargo-cult" computer science.

That was a fantastically entertaining analysis!

Not a typographical Easter egg, but one I noticed while reading: could the Eliza rescue team be a reference to the early 'robotic psychologist' ELIZA? That would fit with the other playful human/machine blurring in the movie.

Another fun example of braking are the electrodynamic tethers [1], in which you (a satellite) are the copper tube and the entire earth is the magnet!

[1] http://en.wikipedia.org/wiki/Electrodynamic_tether

You can also think of it as magnetic flux lines encountering "drag" as they pass through conductors.

The limiting behavior of this view is in type II superconductors, which entirely "pin" flux lines -- they present an effectively infinite resistance to the movement of flux lines. That's why a magnet levitates over such a superconductor. [1]

You can even image these "vortices" directly [2]

[1] http://en.wikipedia.org/wiki/Flux_pinning [2] http://www.youtube.com/watch?v=7_ZgiumS41Q

Yup, although there is a bit of design change from the templating in the RPi version.

Thanks for the help. Piecewise has the same problem, whereas the If is taking forever. How long should I wait before I kill it?

10 has Association expressions [1], which are a huge language addition (and long overdue). Seems there is some synchrony with Erlang on that front!

The features I'm most excited about in 10 (disclosure: my team is working on some of these):

[2] String, XML, file templating

[3] Hands-free machine learning

[4] Entity and EntityValue: semantic "hooks" to represent real world entities

[5] Dataset, a general data modelling and query framework.

Also, DateObject, TimeObject, interaction with external processes, multiple undo, a large number of updated data sources, the ExternalService "meta-api", device connections, time series stuff, GeoGraphics, and a long list of no less worthy features.

[1] http://reference.wolfram.com/language/guide/Associations.htm...

[2] http://reference.wolfram.com/language/guide/WorkingWithTempl...

[3] http://reference.wolfram.com/language/guide/MachineLearning....

[4] http://reference.wolfram.com/language/ref/Entity.html

[5] http://reference.wolfram.com/language/ref/Dataset.html

Really cool problem! And great animations.

I was disappointed to find that the associated notebook (http://math.bard.edu/belk/code/BilliardsHertz.nb) doesn't work correctly in either Mathematica 9 or 10 -- I think the author used 8.

It seems like NDSolve falls down:

NDSolve::smpf: Failure to project onto the discontinuity surface when computing Filippov continuation at time 0.`. >>

and the solution shows the cue bool passing through all the others..

What was responsible for the Amiga ultimately failing, if it was superior in all those ways?

Looks nice.

Slightly OT, but can anyone recommend a high-quality Mac-friendly alternative to Wireshark? (Paid is okay)

My team and I did an analysis on our Facebook dataset recently that might (or might not) have inspired this particular work.

You can find the geographic analysis within this blog post:

http://blog.stephenwolfram.com/2013/04/data-science-of-the-f...

There is a much higher resolution version of the "migration wheel" available here:

http://www.wired.co.uk/magazine/archive/2013/12/start/facebo...

Wouldn't memory layout on the stack be the same for a tuple vs a sequence of arguments?

My impression is that HN's link and comment data is too valuable for pg to give away.

Certainly, if I have had access to it I know I could do some pretty useful sociology on HN's audience (= the pool of startup hire material).

Interesting project!

I have some questions that I couldn't immediately answer from skimming either the BayesDB documentation or the paper linked from http://probcomp.csail.mit.edu/crosscat/

* The CrossCut paper seems to focus on binary features and categorical learning. How does BayesDB generalize that? Does it quantize continuous features first to make it all categorical, or does it generalize CrossCut somehow?

* How are we to think about what BayesDB doing? Is the underlying model most similar to a graphical model? A Bayesian network? A Markov field?

* On an informal level, how is the factorization structure learned?

* What's the time and memory complexity in terms of number of features and examples for different operations? Is insertion constant time? Is it storing sparse contingency tables of some kind?

Disclosure: I've recently been designing a rich type system for representing hierarchical datasets, and I've also worked on a large production system written in Go, so I have some skin in this game.

> Here's a long quote by Rob Pike, which whether you agree with the points he makes or not, explains why Go does not have generics.

Does it? It seems more to explain why Go doesn't have C++-style classes.

In fact, this quote is almost like hearing the concept of metaprogramming being dismissed because C macros are a disaster.

> To be fair he was probably saying in his own way that he really liked what the STL does for him in C++

The C++ STL is hardly the ambassador of type theoretic solutions to problems of software complexity and safety.

> What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden.

Writing things once is not the problem. If you want to write a red-black tree of inegers, you don't want to write the whole thing again for some other totally ordered type. So you're left with casting your way out of the problem on top of a boxed implementation. Great, you've sacrificed DRY for safety and readability because a rich type system was too hard [1]. Note: almost wrote "proper type system".

> Perhaps I'm a philistine about types but I've never found that model particularly expressive.

Or perhaps Rob Pike just hasn't explored the relevant literature in enough depth. At one point he admitted that he didn't know that structural typing had already been invented previously! This isn't to criticize Rob, I find his talks fascinating, I think he's awesome, he's a friend of my boss, etc. But he's hardly the first hard-core hacker to be ignorant of the degree to which type theory has seen dramatic advances since the 1980s.

Just think of John Carmack, who after a very long and successful career using C and C++ is only now beginning to espouse the benefits of rich type systems and static analysis, going as far as to rewrite Wolfenstein 3D in Haskell.

> Type hierarchies are just taxonomy.

Here is the crux of the problem. Rob has silently switched from the ideal of "generic types" -- which 20 years of programming language research has taught us requires engaging with ideas like type classes, higher-kinded types, type covariance, and algebraic data types -- to the straw-man of "type hierarchies". Of course type hierarchies are crap. But that doesn't mean you have to return to the stone age.

Okay, well, structural typing isn't the stone age, but it's the beginning of the journey, not the end.

[1] to be fair, it is hard, Rust is still struggling to make the right balances, as Niko Matsakis's blog posts so entertainingly demonstrate.