News for hackers. Stuff that matters.
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by sockfish on Saturday December 25, 2021 @02:04PM (#29685972)
I often wonder why so much effort is being put into shoehorning everything into a single language. Wouldn't it make much more sense to use a fully differentiable DSL for machine learning / xla, then call it from whatever host language you use? This approach has worked really well for SQL for the past couple of decades.
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by niklasd on Saturday December 25, 2021 @02:22PM (#29686123)
Has it worked really well? I feel ORMs are a sign it hasn't. Though I really enjoy having learned SQL and being able to interact with almost all relational databases.
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by handzhiev on Saturday December 25, 2021 @02:36PM (#29686253)
Imo ORM is mostly a sign that (for some odd reason) many developers don't want to learn / use SQL.

But what actual problem is ORM solving beyond that?

Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by cookieater on Sunday December 26, 2021 @02:34PM (#29695525)
Not much really... In many languages ORM's require just about as much boiler plate or careful error checking as copy pasting SQL strings with supportive structs... Not saying ORM's are bad, some are OK some are maybe even good. Project/team dependent...

That said, I find the concept of abstracting ML ingredients outside of languages a nice one although its not entirely novel(python's been doing this from day 1 :D). The strength for keeping it in 1 language can be profound though. Compilers can optimize across operations. Calling many atomic functions from an API/server from a client loses that unless implemented carefully. That one language benefit is a big part of what Julia has to offer.

I could see a value addition statement being made if the "whole market" solution included a lot of goodies. But every time I think of what that looks like - I think it looks like Julia in 2-5 years....

Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by baq on Saturday December 25, 2021 @03:02PM (#29686461)
Boilerplate. Writing serializers and deserializers by hand is not an efficient use of developer time.

Related to ORMs, but not quite on topic - query building. Type checked queries, parts of which can be passed around business logic, are very powerful and flexible.

Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by ithkuil on Saturday December 25, 2021 @03:56PM (#29686884)
There are more and more libraries that let you to write SQL and bind the results into native records (objects, structs) in the host language. I find it an interesting middle ground
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by viraptor on Saturday December 25, 2021 @03:50PM (#29686841)
They solve 99% of your queries in much less time while allowing to drop down to SQL when you really want/need it.
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by dnautics on Saturday December 25, 2021 @05:12PM (#29687461)
ORMs solve "don't accidentally introduce an SQL injection"
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by mbStavola on Saturday December 25, 2021 @05:44PM (#29687720)
Neither do prepared statements
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by woadwarrior01 on Saturday December 25, 2021 @05:03PM (#29687384)
Re:Trade-Offs in Automatic Differentiation: TensorFlow, PyTo... by fault1 on Saturday December 25, 2021 @06:05PM (#29687882)
that seems one of the points of enzyme[1], which was mentioned in the article.

[1] - https://enzyme.mit.edu/

being able to do interprocedural cross language analysis seems awesome considering how much code is written in C++, but used in higher level languages.