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.

Fwiw this is what Soumith has said: "Internally at Facebook, we have a unified strategy. We say PyTorch is used for all of research and Caffe 2 is used for all of production."

https://www.oreilly.com/ideas/why-ai-and-machine-learning-re...

Its not exactly a secret that PyTorch's tradeoffs favor research and not production.

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

This is extremely similar to DevCards for Clojurescript, https://github.com/bhauman/devcards, https://www.youtube.com/watch?v=G7Z_g2fnEDg

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.

If you have a bunch of tiny apps, how do their data models relate? Who runs them, and owns the data? Theres a lot of assumptions baked into the status quo described in the article, that technology has been developed around. Sweet spot for building this stuff might be a little different.

The faster people realize this the better.

What does the technology look like for achieving these kinds of goals?

You are the target audience of this book. The Wolfram Language has gotten huge, making it harder for beginners to find their way around the basics via reference docs.

That said, WL is in fact based on pretty simple primitives. If you are familiar with functional programming, things like NestList are familiar and you'll start learning by finding the analogues of your favorite FP constructs.

WL also has a lot of functions that you might call "optional": those that could be restated as simple combinations of other functions. The rationale there is pretty simple: if there is a well-defined, commonly used chunk of computation, it should be given a name (and design). The fact that a fair amount of work is put into both the name and design of these things gives a higher sense of coherence (and predictability) than you might expect from their number.

In the announcement they called this the "reference implementation".

tl;dr: lol.

The author is claiming Relay is a scheme to kill the open web. A simpler theory is just that Relay solves a problem Facebook (and many other people it seems) are having. The idea that REST has shortcomings for Facebook's use case is an unthinkable thought for the author.

No argument is given for why we should consider REST to be a foundation of the open web. REST != HTTP.

The post is full of logic-defying assertions like "Facebook wants to replace REST with Relay for the same reason they want to replace DOM engines with React Native."

Topological data analysis is amazing, too bad all the hype around DL is leaving it in relative obscurity.

Clojure/script already has this. Its called transients

Fukuyama's recent book Political Order and Political Decay goes into some detail on the forest service, from its origins as a model of a modern effective government agency in the Progressive era to one captured by special interests and turned ineffective by conflicting mandates from congress.

What's the rationale? Who are the target users? I go to the site and I have no idea what exactly this does that's better than the alternatives. It sounds like its trying to do everything.

at least 2 forces come to mind - 1. Humans want to believe they are special in some way 2. Theory of evolution is under "selective pressure" to explain complexity since the watchmaker analogy

Interesting that Wolfram predicted this in 2002, was mocked by Cosma Shalizi as having "absolutely no understanding of evolution"

Definitely a must-read. Also: Why Nations Fail, and Violence and Social Orders. People in tech would be well-served by a deeper understanding of the systems we operate in and hope to change.

Imagine being a woman and coming to HN and seeing this. Clearly a place for her?

We need to drop sexist article titles like this from HN.