programnature

Its a good strategy. But its no silver bullet either. If you're exporting to a "static graph" platform, your losing a major benefit of PyTorch. If you mostly just care about shipping to production, a case can be made to just use tf/caffe2/mxnet etc from the start.

While PyTorch is extremely cool, the fanboyism is out of hand, thinking that what's good for their corner of the universe must be awesome for every use case and therefore TF is a overcomplex turd. Its not like the people designing these systems are stupid.

If you want to run in production.

Even FB doesn't use PyTorch in production, and instead uses Caffe2.

Wolfram was there in 2002. Pretty cool examples though.

Actually not clear if there is an official affiliation with Facebook, other than some of the primary devs.

How?

This is a very thick talk, one Rich's best ever IMHO.

The first point is how we talk about 'change' in software, to center around what things 'provide' and 'require'.

Breaking changes are changes that cause code to require more or provide less. Never do that, never need to do that. Good changes are in the realm of providing more or requiring less.

There is a detailed discussion about the different 'levels' - from functions, to packages, artifacts, and runtimes, which he views as multiple instances of the same problem. Even though we now have spec, theres a lot of work to leverage it across all those different layers to make specific statements about what is provided and required.

Its an interesting question. One reason is Wolfram is extremely talented at language design, which is necessary to build an artifact of this size without self-immolating. Another is that it is a commercial company following a plan. A third is that few people have learned the lessons of Mathematica enough to apply them.

Yes, understandable. I encourage viewing this as part of the 'open' mandate.

While its useful to have this kind of info, IMHO its still far from 'infrastructure for deep learning'. What about model versioning? What about deployment environments? We need to address the whole lifecycle, not just the 'training' bit. This is a huge and underserved part of the problem bc people tend to be satisfied with having 1 model thats good enough to publish.

Did you also appreciate slide 28? "I used to think Wolfram was wrong. Now I am not so sure."

Theres a 160 people in the Om slack channel. There's more ways to contribute than sending patches, and theres quite a lot of community effort behind Om Next these days.