Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Every time I approached LangChain, contrary to the attitude of my colleagues, I could never figure out what the point of it was other than to fetishize certain design patterns. Interacting with an LLM in a useful way requires literally none of what LangChain has to offer, yet for a time it was on its way to being the de facto way to do anything with LLMs. It reminds me a lot of the false promise of ORMs, which is that if you trust the patterns then you can swap out the underlying engine and everything will still just work, and is more or less a fantasy.


ORMs are useful though for a different reason. They let you creat typed objects then generate the schema from them and automatically create a lot of boilerplate SQL for you.

Admittedly for anything more than 1-2 joins you are better off hand crafting the SQL. But that is the exception not the rule.

Refactoring DB changes becomes easier, you have a history of migrations for free, DDL generation for free.

In the early 2000 I worked where people handcrafted SQL for every little query for 100 tables and yeah you end up with inconsistent APIs and bugs that are eliminated by code generation / meta programming done by ORMs.


Admittedly for anything more than 1-2 joins you are better off hand crafting the SQL. But that is the exception not the rule.

String disagree: if that’s true you likely don’t even need a proper RDBMS in the first place.

An ORM is not a replacement for knowing how SQL works, and it never will be.


> to fetishize certain design patterns

Yes; exactly. There's value in a Schelling Point[0], and in a pattern language[1].

> requires literally none

True, yes. There isn't infinite value in these things, and "duplication is far cheaper than the wrong abstraction"[2], but they can't be avoided; they occupy local maxima.

0. https://en.wikipedia.org/wiki/Focal_point_(game_theory)

1. https://en.wikipedia.org/wiki/Pattern_language

2. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: