LLM frameworks like LangChain are causing a java-fication or Python .
Do you want a banana? You should first create the universe and the jungle and use dependency injection to provide every tree one at a time, then create the monkey that will grab and eat the banana.
Id just like to point out the source of the Gorilla Banana problem is Joe Armstrong. He really had an amazing way of explain complex problems in a simple way.
Ah didn't know that. IIRC I first heard this analogy with regards to Java Spring framework, which had the "longest java class name" somewhere in its JavaDocs. It should have been something like 150+ chars long. You know... AbstractFactoryTemplate... type of thing.
Holy moly this was _exactly_ my impression. It seems to really be proliferating and it drives me nuts. It makes it almost impossible to useful things, which never used to be a problem with Python - even in the case of complex projects.
Figuring out how to customize something in a project like LangChain is positively Byzantine.
Langchain was my first real contact with Python development, and it felt worse than Enterprise Java. I didn't know that OOP is so prominent in Python libraries, it looks like many devs are just copying the mistakes from Enterprise Java/.NET projects.
Well it's not:D
Sure there are 4-5 fundamental classes in python libs but they're just fundamental ones.
They don't impose an OOP approach all the way.
What you're alluding to is people coming from Java to Python in 2010+ and having a use-classes-for-everything approach.
It's funny because I was using Langchain recently and found the most confusing part to be the inheritance model and what type was meant to fill which function in the chain. Using Java would make it impossible to mistype an object even while coding. I constantly wonder why the hell the industry decided Python was suitable for this kind of work.
Reasons for using Python: it is easier to find code on github for reuse and tweaking, most novel research publishes in PyTorch, there is a significant network effect if you follow cutting edge.
Second reason - to fail fast. No sense in sculpting novel ideas in C++ while you can muddle with Python 3x faster, that's code intended to be used just a few times, on a single computer or cluster. That was an era dominated by research, not deployments.
Llama.cpp was only possible after the neural architecture stabilized and they could focus on a narrow subset of basic functions needed by LLMs for inference.
I feel this too, I think it's because Java is an artifact of layers of innovation that have accumulated over time, which weren't present at its inception. Langchain is similar, but has been developing even more rapidly than Java did.
I still find LC really useful if you stick to the core abstractions. That tends to minimize the dependency issues.
The OOP concept described by Smalltalk is message passing. The closest OOP-ness rivals are Ruby and Objective-C (and arguably Erlang). Java has no such facilities. Java is much more like C++.
Maybe. Developers love to invent new definitions for existing terms all the time, so Java is OOP under one or more of those definitions, but Java is not OOP in the original sense. So, it depends on the definition of OOP arbitrarily chosen today.
The "original sense" argument is frankly nonsense. Simula 67 was the original OOP language, predating Smalltalk, and it already had "classes" and "objects". It also looked a great deal like Java and the OOP parts of C++.
Simula 67 long predates OOP. Which, when you think about it, means that when OOP was coined it referred to a "message passing" paradigm, not "classes" or "objects". "Oriented", not "object", was the operative word. Having objects does not make a language object-oriented, at least not as it was originally conceived.
Simula 67, like Java, may fit into some newer OOP definitions that have come about over the years, but it was not considered OOP at the time of its arrival. The term OOP hadn't even been invented yet. And when OOP finally did get used for the first time, it most definitely did not refer to Simula 67. Where on earth did you get the idea that it did? Whatever gave you that idea was, frankly, nonsense.
"Object-oriented" ipso facto refers to programming using objects. Simula had objects, and they were objects in the same exact way as Smalltalk objects are objects - a bundle of state with identity and behavior. Whether the exact term "OOP" was used by Simula authors is immaterial. The usual claim is that what makes Smalltalk special is message passing as opposed to method calls, but they are obviously isomorphic.
Simula is basically C++ before C++, and we know C++ is not OOP in the original sense. When OOP was first defined, it was quite explicitly noted that C++ is not OOP. Java's object model follows in the same vein as this lineage. These are not OOP languages, as originally conceived.
Furthermore, message passing was the defining feature of OOP. Of course it was. That is the distinction OOP was calling attention to – what made OOP different from the other object-based languages that had been around for decades beforehand. Nobody was going to randomly come up with OOP out of the blue to describe a programming model from the long ago past. Method calling may be superficially similar, but OOP was coined to call attention to what difference there is.
You are, of course, quite free to come up with your own redefinition of OOP that includes Simula, C++, Java, whatever you wish. You would not be the first. However, as we are talking about the original definition, whatever you want to define it as does not apply. It is not your definition that is under discussion.
Well. I'm working on a product that relies on both AI assistants in the user-facing parts, as well as LLM inference in the data processing pipeline. If we let our LLM guy run free, he would create an inscrutable tangled mess of Python code, notebooks, Celery tasks, and expensive VMs in the cloud.
I know Pythonista's regard themselves more as artists than engineers, but the rest of us needs reliable and deterministically running applications with observability, authorization, and accessible documentation. I don't want to drop into a notebook to understand what the current throughput is, I don't want to deploy huge pickle and CSV files alongside my source to do something interesting.
LangChain might not be the answer, but having no standard tools at all isn't either.
That's the central idea here. Most guys available to hire aren't. Hence why they get constrained into a framework that limits the damage they can cause. In other areas of software development the frameworks are quite mature at this point so it works well enough.
This AI/LLM/whatever you want to call it area of development, however, hadn't garnered much interest until recently, and thus there isn't much in the way of frameworks to lean on. But business is trying to ramp up around it, thus needing to hire those who aren't good to fill seats. Like the parent says, LangChain may not be the framework we want, but it is the one we have, which beats letting the not-very-good developers create some unconstrained mess.
If you win the lottery by snagging one of the small few good developers out there, then certainly you can let them run wild engineering a much better solution. But not everyone is so fortunate.
LLMs are, at least at present, exactly the kind of thing where trying to use an abstraction without understanding what it actually does is exactly what's going to create a mess in the long run.
Some hiring teams just don’t operate in unlimited venture capital land and have tight boundaries in terms of compensation. There’s someone good in anything if you can throw enough money at the problem.
"More artists than engineers": yes and no.
I've been working with Pandas and Scikit-learn since 2012, and I haven't even put any "LLM/AI" keywords on my LinkedIn/CV, although I've worked on relevant projects.
I remember collaborating back then with PhD in ML, and at the end of the day, we'd both end up using sklearn or NLTK, and I'd usually be "faster and better" because I could write software faster and better.
The problem is that the only "LLM guy." I could trust with such a description, someone who has co-authored a substantial paper or has hands-on training experience in real big shops.
Everyone else should stand somewhere between artist and engineer: i.e., the LLM work is still greatly artisanal. We'll need something like scikit-learn, but I doubt it will be LangChain or any other tools I see now.
You can see their source code and literally watch in the commit history when they discover things an experienced software engineer would do in the first pass.
I'm not belittling their business model! I'm focusing solely on the software. I don't think they their investors are naive or anything.
And I bet that in 1-2 years, there'll be many "migration projects" being commissioned to move things away from LangChain, and people would have a hard time explaining to management why that 6-month project ended up reducing 5K LOC to 500 LOC.
For the foreseeable future though, I think most projects will have to rely on great software engineers with experience with different LLMs and a solid understanding of how these models work.
It's like the various "databricks certifications" I see around. They may help for some job opportunities but I've never met a great engineer who had one. They're mostly junior ones or experienced code-monkeys (to continue the analogy)
What you need is a software developer, not someone who chaotically tries shit until it kinda sorta works. As soon as someone wants to use notebooks for anything other than exploratory programming alarm bells should be going off.
Do you want a banana? You should first create the universe and the jungle and use dependency injection to provide every tree one at a time, then create the monkey that will grab and eat the banana.