4 ms·

Sure, yes, not going to lie I use printlines all the time. There's nothing inherently wrong with it, and meant no offense! In fact, you can even add a hook with

Sure, yes, not going to lie I use printlines all the time. There's nothing inherently wrong with it, and meant no offense! In fact, you can even add a hook with Burr that adds as many printlines as you like :) https://burr.dagworks.io/concepts/hooks/ https://burr.dagworks.io/concepts/hooks/. Meant no offense. That said, logging stuff and using regexes (which is the common way to productionize printlines for live/post-hoc debugging) has a lot of challenges, and this is where we've seen a framework become useful. There's an obvious trade-off between adopting a framework and rolling your own -- we've seen both work in various contexts (we've been in MLOps for quite a while). Our hope is that this will make people more productive by constraining the space they need to think about and allow more mental room for application logic.

pama 3y ago
Thanks. Absolutely no offense taken. No worries. I am used to frank communication and it occasionally doesn’t come out well in quick writing on the phone. The main concern I have with frameworks is the inversion of control of the code logic, the lack of composition, the complexity of handling edge cases outside the scope of the framework. Frankly writing apps is not my thing typically. PyTorch is moderately unobtrusive, but other tools on top make tons of assumptions and break more often than they help in the long term. Of course with the current zoo of LLM and APIs and the coming popularity of agents, a lot of people will need some help to get started so I wish you the best of luck in your endeavors. Here is some unsolicited advice: as the LLMs get better, you might want to focus on detailed documentation so that the future AIs can master your framework and help your users. Maybe measure the power of your documentation by finetuning in-house LLMs on it and then evaluate known test cases or create new ones with the finetuned models.
- krawczstef 3y ago
  > The main concern I have with frameworks is the inversion of control of the code logic, the lack of composition, the complexity of handling edge cases outside the scope of the framework. Frankly writing apps is not my thing typically. PyTorch is moderately unobtrusive, but other tools on top make tons of assumptions and break more often than they help in the long term. 100%; lived that story. In my experience this is usually the result of some poor design assumptions on part of the framework. Other times people want to use something for which it wasn't designed for. In the case of Burr, we still have a few things to iron out, but given our platform backgrounds, we're trying to be cognizant of things that have annoyed us in the past, e.g. two big ones: ability to customize parts given esoteric deployment needs (e.g. persistence layer); adding in observability without it coupling you/getting in the way of logic. > the LLMs get better, you might want to focus on detailed documentation so that the future AIs can master your framework and help your users Even without LLMs I think this is required ;)
  - pama 3y ago
    Agreed that detailed documentation is required anyways. However, LLMs give you the ability to measure the quality of the documentation and the improvements in quality for changes in the documentation without having to wait for complaints by users.
- elijahbenizzy 3y ago
  Yep! That makes sense. As @krawczstef said, building a wrong abstraciton, an overly rigid abstraction, or an overly complex abstraction can all make things worse. With any abstraction there will also always be people who end up outgrowing it or customizing it. And good point re: good docs for LLMs! On a meta-level there's something very funny about having to write better human-facing docs for the use of computers. Who would have thought that some of our most powerful computing systems emulate how we think!

pama 3y ago

Thanks. Absolutely no offense taken. No worries. I am used to frank communication and it occasionally doesn’t come out well in quick writing on the phone. The main concern I have with frameworks is the inversion of control of the code logic, the lack of composition, the complexity of handling edge cases outside the scope of the framework. Frankly writing apps is not my thing typically. PyTorch is moderately unobtrusive, but other tools on top make tons of assumptions and break more often than they help in the long term. Of course with the current zoo of LLM and APIs and the coming popularity of agents, a lot of people will need some help to get started so I wish you the best of luck in your endeavors. Here is some unsolicited advice: as the LLMs get better, you might want to focus on detailed documentation so that the future AIs can master your framework and help your users. Maybe measure the power of your documentation by finetuning in-house LLMs on it and then evaluate known test cases or create new ones with the finetuned models.

krawczstef 3y ago
> The main concern I have with frameworks is the inversion of control of the code logic, the lack of composition, the complexity of handling edge cases outside the scope of the framework. Frankly writing apps is not my thing typically. PyTorch is moderately unobtrusive, but other tools on top make tons of assumptions and break more often than they help in the long term. 100%; lived that story. In my experience this is usually the result of some poor design assumptions on part of the framework. Other times people want to use something for which it wasn't designed for. In the case of Burr, we still have a few things to iron out, but given our platform backgrounds, we're trying to be cognizant of things that have annoyed us in the past, e.g. two big ones: ability to customize parts given esoteric deployment needs (e.g. persistence layer); adding in observability without it coupling you/getting in the way of logic. > the LLMs get better, you might want to focus on detailed documentation so that the future AIs can master your framework and help your users Even without LLMs I think this is required ;)
- pama 3y ago
  Agreed that detailed documentation is required anyways. However, LLMs give you the ability to measure the quality of the documentation and the improvements in quality for changes in the documentation without having to wait for complaints by users.
elijahbenizzy 3y ago
Yep! That makes sense. As @krawczstef said, building a wrong abstraciton, an overly rigid abstraction, or an overly complex abstraction can all make things worse. With any abstraction there will also always be people who end up outgrowing it or customizing it. And good point re: good docs for LLMs! On a meta-level there's something very funny about having to write better human-facing docs for the use of computers. Who would have thought that some of our most powerful computing systems emulate how we think!