Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tensorflow sucks

nicodjimenez.github.io

Post reply on HN
Print view View original

111–120 of 133 posts

Re: Tensorflow sucks

#111

Post by eru »

bryanrasmussen wrote: post #108
eru wrote: post #106

Earlier quoted context omitted.

You should still be able to give the other side the best defense imaginable. (See 'steelmanning'.)

ok, I've seen stellmanning? https://www.google.com/search?dcr=0&source=hp&q=stellmanning... on edit: never mind, I see you mean steelmanning. However that does not really have anything to do with what I said, you should be able to give someone the best defence imaginable, but what if the best defence imaginable is shit compared to the other side. Then you cannot argue both sides equally, this does not mean you do not…

Sure. Eg you'd be hard pressed finding good arguments for 2=3 (without resorting to shenanigans around definitions).

Re: Tensorflow sucks

#112

Post by acjohnson55 »

rkangel wrote: post #94
yongjik wrote: post #54

Earlier quoted context omitted.

After being exposed to several declarative tools during my career, I must say they age poorly: make, autoconf, Tensorflow, and so on. They may start out being elegant, but every successful library is eventually (ab)used for something the original authors didn't envision, and with declarative syntax it descends into madness of "So if I change A to B here does it apply before or after C becomes D?" At least Tensorflow…

I believe that make's declarative is not the cause of it's problems at all - it's poor syntax and lack of support for programming abstractions is what makes it clunky to use. Something like rake, which operates on the same fundamental principles (i.e. declarative dependency description) but using ruby syntax has aged better.

SBT in the Scala world would also fit this description.

Re: Tensorflow sucks

#113

Post by pmarreck »

I can find no good empirically-based argument here against the declarative style other than an appeal to taste/preference.

The only effective difference IMHO is that the declarative style does deferred evaluation which makes it more difficult to examine "intermediate states" (aka "debugging") but as the author stated themselves, this is simply a matter of outputting those intermediate states/setting them as outputs... this is no different from examining intermediate state in every programming paradigm ever invented. Unit-testing every step is IMHO a far better way of debugging/ensuring validity, but this is possibly much more difficult in the "black box" environment of self-weighting neural networks than it is in your more traditional programming environment

Re: Tensorflow sucks

#114

Post by Gtifn »

hueving wrote: post #90
KirinDave wrote: post #82

Usually I'm on the hook for being open minded about programming languages in this forum, but I'm putting my foot down. I really hope at some point this entire universe gets liberated from Python at some point. Even R would be more palatable. Both these examples are awful , error prone, obfuscated, and beholden to Python's difficulties with large sums of data.

Can you turn your comment into something productive by showing a code example front another language that handles these cases better?

Julia: https://fluxml.github.io/

Re: Tensorflow sucks

#115

Post by Gtifn »

walrus wrote: post #86
KirinDave wrote: post #82

Usually I'm on the hook for being open minded about programming languages in this forum, but I'm putting my foot down. I really hope at some point this entire universe gets liberated from Python at some point. Even R would be more palatable. Both these examples are awful , error prone, obfuscated, and beholden to Python's difficulties with large sums of data.

Can you give a sketch of how you would like these examples to look? Any language is fine; you can pretend that libraries for GPGPU, backprop, and gradient-based optimization already exist. I tried to do so myself and couldn't come up with anything significantly better, but I've been writing Python for a long time and might just be stuck in a local minimum :)

https://fluxml.github.io/

In julia

Re: Tensorflow sucks

#116

Post by HillaryBriss »

_pmf_ wrote: post #80

Well, working with Android will tell you one thing: Google is abysmally bad at designing APIs.

yeah. one of my favorite things is the collection of FLAG_* constants on Intent: FLAG_ACTIVITY_CLEAR_TOP, FLAG_ACTIVITY_CLEAR_TASK, FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET, FLAG_ACTIVITY_FORWARD_RESULT ...

the android SDK appears to lack a coherent, overarching concept or set of guiding principles which the client programmer can internalize and rely upon. there are many special cases and inscrutable behaviors.

like, sometimes you ask for a piece of work to be done by the SDK and it calls you back on your implementation of a Listener class. but, other times, you have to register a BroadcastReceiver. still other times, you have to override OnActivityResult. but, then, there are these other times when you have to create and provide a PendingIntent.

you go through enough of this stuff and you start to wonder: "Did there really need to be soooo much variety in the way these SDK methods hand info back to the client? Couldn't they have standardized this?"

it's almost like Google turns their (very smart) programmers loose on the SDK and never looks back. google seems to just defer entirely to their opinions and judgments. smart as these programmers are, they seem to have different tastes, different approaches to API design.

and it all goes into the SDK.

Re: Tensorflow sucks

#117

Post by kleer001 »

eru wrote: post #110
dvt wrote: post #73

Earlier quoted context omitted.

Small correction: not brain parasites, but specifically prions (misfolded protein that fascinatingly self-replicate). Kuru[1] (closely related to Creutzfeldt–Jakob disease and Alzheimer's) was extensively studied last century in the Fore people of Papua New Guinea (which were practicing cannibalism as a funerary rite), culminating in the awarding of the 1997 Nobel Prize[2] for the discovery of the prion, a completely…

Do you get the prions only from rare meat? Would thorough cooking protect?

Kuru and CJD reside in the brain meats.

Prions are highly resistant to disinfectants, heat, ultraviolet radiation, ionizing radiation and formalin. ... Prions can be destroyed through incineration providing the incinerator can maintain a temperature of 900 F for four hours.

Re: Tensorflow sucks

#118

Post by KirinDave »

hueving wrote: post #90
KirinDave wrote: post #82

Usually I'm on the hook for being open minded about programming languages in this forum, but I'm putting my foot down. I really hope at some point this entire universe gets liberated from Python at some point. Even R would be more palatable. Both these examples are awful , error prone, obfuscated, and beholden to Python's difficulties with large sums of data.

Can you turn your comment into something productive by showing a code example front another language that handles these cases better?

Other people will.

But it is productive to say, "An excessively declarative style has been considered bad in programming for over thirty years."

That is reminding people this is a largely solved problem that the industry refuses to embrace because our legacy rube-goldberg contraption of software refuses to accept ever abandoning anything in favor of simplicity.

A great example: Why are both of these examples using the error prone pattern of explicit bounds iteration?

Re: Tensorflow sucks

#119

Post by KirinDave »

walrus wrote: post #86
KirinDave wrote: post #82

Usually I'm on the hook for being open minded about programming languages in this forum, but I'm putting my foot down. I really hope at some point this entire universe gets liberated from Python at some point. Even R would be more palatable. Both these examples are awful , error prone, obfuscated, and beholden to Python's difficulties with large sums of data.

Can you give a sketch of how you would like these examples to look? Any language is fine; you can pretend that libraries for GPGPU, backprop, and gradient-based optimization already exist. I tried to do so myself and couldn't come up with anything significantly better, but I've been writing Python for a long time and might just be stuck in a local minimum :)

Sure.

Another comment has already pointed out that Julia framework. I'll relink it for completeness: https://fluxml.github.io

You can also look at Haskell's Grenade examples: https://github.com/HuwCampbell/grenade

Fundamentally different because the notion of what the compiler should be doing is fundamentally different, and the notion of how data should be input is somewhat different.

Re: Tensorflow sucks

#120

Post by Sommersonn »

jacquesm wrote: post #97
TheMagicHorsey wrote: post #85

Earlier quoted context omitted.

One should also ask the question: would you want to work at Google today. This is not the Google of 2002 ... or even the Google of 2010. 2017 Google is like 1999 Microsoft. Lots of brilliant people working on heavily resourced projects ... but also significant bureaucracy and many political animals in what was formerly a pristine engineering "garden of eden". You can see a lot of Google projects struggling now, and m…

> Nobody ever got fired at Google for spending all day brilliantly arguing on Google's internal newsgroups There was a pretty high profile example of this not all that long ago.

Was that because he posted his article _outside_ of Google?
Post reply on HN