4 ms·

I would actually argue that the very first version of Tensorflow was great. I don't quite remember what version number that was, but it was well before 1.0. It

I would actually argue that the very first version of Tensorflow was great. I don't quite remember what version number that was, but it was well before 1.0. It was basically just a better version of Theano with a single way of doing things and very explicit graphs. I remember I ported all my Theano code without issues and loved it. From then on it all went downhill. Lots of duplicate APIs were added and the code grew increasingly complex and opque because everyone at Google wanted in. Everyone wanted a slice of the pie to pad their resumes and internal performance reviews to be able to say "Look, I contributed this to TF! Promote me!" - Now it's a typical example of Conway's Law - a big mess that mirrors how messed up the internal incentive structure at Google is.

logicchains 7y ago
Makes sense. I only started using it after it'd already been though tf.nn, tf.layers, and tf.estimators (which eventually got replaced by tf.keras, around the time I moved to PyTorch, and the time dropout was broken for two releases.. https://github.com/tensorflow/tensorflow/issues/25175 https://github.com/tensorflow/tensorflow/issues/25175). I remember though once spending half a day just trying to figure out why a graph that built correctly kept failing at execution time: I ended up having to binary-search the code changes because I couldn't find the cause of the error in the stack trace, something I've only experienced previously in template heavy C++ code. I don't imagine that situation was much better in 1.0.
- WnZ39p0Dgydaz1 7y ago
  The error message have always been an issue, even with early releases. That being said, it was much easier to trace errors when there were fewer high-level functions and you had to build the layers yourself. You fully understood what the graph looked like, and it was mostly obvious where something is likely to go wrong. Sure, it's a bit more work, but in the long run it saves times because it avoids the situation where you need spend half a day trying to understand opaque TF code touched and extended by 100 different developers. EDIT: Also, I LOVE the Github issue you posted. It's such a beautiful example of complexity cost when a large number of people is working on a project and there's no longer a single person that fully understands how code interacts across modules.
  - logicchains 7y ago
    I'd love to know what the solution is to prevent that eventually happening to a project, if one even exists. PyTorch seems to be doing better, but maybe that's just because it's a younger project. I'd be interested to see a blog post comparing Facebook's incentive structure for maintaining products to Google's.

logicchains 7y ago

Makes sense. I only started using it after it'd already been though tf.nn, tf.layers, and tf.estimators (which eventually got replaced by tf.keras, around the time I moved to PyTorch, and the time dropout was broken for two releases.. https://github.com/tensorflow/tensorflow/issues/25175 https://github.com/tensorflow/tensorflow/issues/25175). I remember though once spending half a day just trying to figure out why a graph that built correctly kept failing at execution time: I ended up having to binary-search the code changes because I couldn't find the cause of the error in the stack trace, something I've only experienced previously in template heavy C++ code. I don't imagine that situation was much better in 1.0.

WnZ39p0Dgydaz1 7y ago
The error message have always been an issue, even with early releases. That being said, it was much easier to trace errors when there were fewer high-level functions and you had to build the layers yourself. You fully understood what the graph looked like, and it was mostly obvious where something is likely to go wrong. Sure, it's a bit more work, but in the long run it saves times because it avoids the situation where you need spend half a day trying to understand opaque TF code touched and extended by 100 different developers. EDIT: Also, I LOVE the Github issue you posted. It's such a beautiful example of complexity cost when a large number of people is working on a project and there's no longer a single person that fully understands how code interacts across modules.
- logicchains 7y ago
  I'd love to know what the solution is to prevent that eventually happening to a project, if one even exists. PyTorch seems to be doing better, but maybe that's just because it's a younger project. I'd be interested to see a blog post comparing Facebook's incentive structure for maintaining products to Google's.