An agent, or something that has agency, is just something that takes some action, which could be anything from a thermostat regulating the temperature all the way up to an autonomous entity such as an animal going about it's business.
Hugging Face have their own definitions of a few different types of agent/agentic system here:
As related to LLMs, it seems most people are using "agent" to refer to systems that use LLMs to achieve some goal - maybe a fairly narrow business objective/function that can be accomplished by using one or more LLMs as a tool to accomplish various parts of the task.
JSON wins because it can be casually inspected by people testing bizarre theories. The importance of this is lost on people who don’t treat triage as a skill that can be honed.
I like to solve problems - or at least bringing them to me doesn’t result in a loss of status for either party. People notice this about me and bring me problems. Someone recently described to people what is essentially my process: the likelihood of the cause divided by the difficulty of verification. Partially sort and just start checking off assumptions.
A lot of cheap but low probability options get shuffled higher, and just sending the wrong data is a common enough problem, especially with caching. And if it’s nearly free to look at the payload, it’ll get checked. If it isn’t people will try everything else to avoid it.
Looks cool. Just out of curiosity, how does this compare to other OpenLLMetry-type observation tools like Arize, Traceloop, LangSmith, LlamaTrace, etc.?
From personal experience, they're all pretty simple to install and use. Then mileage varies in analyzing and taking action on the logs. Does Velvet offer something the others do not?
For my client projects, I've been leaning towards open source platforms like Arize so clients have the option of pulling it inhouse if needed. Most often for HIPAA requirements.
RAG support would be great to add to Velvet. Specifically pgvector and pinecone traces. But maybe Velvet already supports it and I missed it in the quick read of the docs.
* To catch passive voice and nominalizations in my writing.
* To convert Linux kernel subsystems into Python so I can quickly understand them (I'm a C programmer but everyone reads Python faster).
* To write dumb programs using languages and libraries I haven't used much before; for instance, I'm an ActiveRecord person and needed to do some SQLAlchemy stuff today, and GPT 4o (and o1) kept me away from the SQLAlchemy documentation.
OpenAI talks about o1 going head to head with PhDs. I could care less. But for the specific problem we're talking about on this subthread: o1 seems materially better.
There is a balance between letting people run free, and controlling every tiny decisions. You have to keep the direction and vision, and you have to make sure everyone is going toward that. But you shouldn't trust they will do it by themselves (they may not have internalized it as much as you do either) and you shouldn't trust your ability to deal with every detail of the complex system you are trying to build. If you hired specialists that's also because you were lacking some abilities, not just because you want extensions of yourself by lack of time. And if you hired generalists that's because you needed glue to make the whole operation work with a level of understanding that you can't allocate your time to, and because you may lack the variety of skills that allow for efficient communication with the specialists.
As with any complex system, you have to be careful about degrees of freedom, too many and it can break down and too little and it can get seized.
Python building, packaging and deployment has two extreme states: the king's highway and the hall of a thousand knives. If the portable Python suggestions do not make sense to you, then consider yourself lucky, because you have managed to stick to the highway.
I don’t know in practical terms how Apple does it, I only know that they must do it because otherwise they couldn’t produce an artifact as complex as the iPhone. You can know for a fact they utilize modularity by opening up an iPhone and seeing… modules! A few things to read in the general area of this theory though…
An actual book that’s a bit broader but touches on system coupling/decoupling and is very practical for software people: Wiring the Winning Organization by Gene Kim
An excellent, very approachable primer on the overarching field of thought, which is systems theory, is Donella Meadows’ “Thinking in Systems”
Going back to more of the philosophical foundation (along with other valuable business ethics lessons), you should look into the work of W Edwards Deming and his “System of Profound Knowledge” — sounds pretentious but is EXTREMELY practical. This region of thought forms the basis of e.g. the Toyota Production System
And an absolutely excellent but more academic deep dive into precisely this topic of modularity is Carliss Baldwin’s “Design Rules.” It’s sort of a super-theory of Conway’s Law, but in a book-length argument.
The problem here isn't with the concept of Streams (which are good) but with specifically the "buffered stream" APIs provided by the futures crate (i.e. the buffered and buffer_unordered methods). Their lack of concurrency with processing before or after is a known problem as the blog post alludes to at the end; I would discourage users from using these APIs without considerable care.
I've explored this subject on my blog, including possible solutions to the problem with these APIs:
The photographer Michael Weseley did a number of long exposures (>12mths iirc) of Berlin during the 1990s as it was being transformed after the fall of the Wall and subsequent reunification.
Viewed as huge prints in a gallery they were impressively detailed, as layers of various rebuilding and urban planning projects were revealed in varying degrees of transparency, depending on how long they took and how recent they were:
I had a lot of fun learning Clojure. While I don't use it in daily practice, I learned a lot about elegancy, the advantages of data immutability and using code as building blocks. For learning I used the 4clojure website where you can solve interactive coding puzzles and learn from solutions of others. See: https://4clojure.oxal.org
1. Ideas That Created The Future[1]. It's a collection of fiftyish classic CS papers, with some commentary.
2. Wikipedia's list[2].
3. Test of Time awards[3]. These are papers that have been around for a while and people still think are important.
4. Best paper awards[4]. Less useful than ToT as not every best paper is actually that good or important, and sometimes the award committees can't see past names or brands for novel research.
5. Survey Journals[5]. Students often get their research started with a literature review and some go the extra step to collect dozens of papers into a summary paper. I subscribe to the RSS feed for that one, and usually one or two are interesting enough to read.
6. Citation mining -- As you read all these, consider their citation list as potential new reading material, or if an old paper leaves you wanting more, use Google Scholar to find a papers that cited what you just read.
I highly recommend browsing through the videos in Asianometrys channel if you want easily digestible summaries on this topic: https://youtube.com/@Asianometry
Co-opting my comment to add another thought. For me, Svelte's big superpower is that it does a great job of looking like plain JS sitting next to templated HTML, and the two just magically react to each other.
The reason this is huge is because 90% of my coding is not Svelte. Usually I'm working on app logic, so I might go weeks or occasionally months without touching any UI code. With Vue I used to dread making UI changes, because I always wound up needing to re-learn which properties I needed to put in which return value to which callback (or somesuch, I don't remember the details). I'm sure it's very intuitive if one uses it every day, but it never was for me after a six week gap.
In contrast with Svelte I feel comfortable doing UI work after a long hiatus, even with nontrivially reactive bits, because apart from the templating it's basically just plain JS (or looks like it). It took a bit of bother initially architecting stuff, but I don't think I've checked its docs since I first switched to it.
That said, the big tradeoff is that Svelte's reactivity is quite magical. Personally this doesn't bother me, because as a JS main I find it easy to intuit what Svelte must be doing behind the scenes in order to work the way it does. But if you're an occasional JS user you might hate Svelte's magicalness for the same reason I disliked Vue - e.g. you might keep needing to re-learn when to use $: statements, etc.
"I am looking for explanations that will help me build a conceptual understanding of macos UI development."
it depends on your learning style of course, but if you like lecture / course-style learning, i highly recommend paul hegarty's CS193P, it will definitely give you the in-depth, conceptual explanations you're describing.
while it is an iOS dev course (taught at stanford, lectures are freely offered online), the newest lectures are using swiftUI for UI, so pretty much all of it will translate to doing macOS dev.
paul is a cs prof at stanford and worked at NeXT and then on the objc lang many, many years ago, so he's been doing this a while and knows a thing or two :)
>they need to be complemented by at least one type A, no-nonsense delivery manager
And these managers need to report to them, not the other way around.
Truly great things either way, but an order of magnitude more accomplishments which is noticeable.
Kind of like a real rock star who is the one that hires the manager, even though the manager will be the one outlining and scheduling the grueling tasks for the performer, which the performer will adhere to as if the manager was his actual boss, except with none of the disadvantages.
Makes me think of this quote from Richard Hamming, to the extent that having an ear tuned into the news is like having your office door open:
"Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don't know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, ``The closed door is symbolic of a closed mind.'' I don't know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing - not much, but enough that they miss fame."
(from "You and Your Research," 1986)
You are describing the hedonic treadmill. Essentially, you become used to your surroundings, and while they are objectively great, from the perspective of inside your own head, this is now normal and you / your monkey mind wants more.
There have been a lot of post floating around the internet with various solutions, the most popular being Stoicism > Positive Psychology / Happiness research > Buddhism / Meditation. I've dabbled a little in all of them and they all have something to offer.
Essentially, you are experiencing a disconnect between how it feels to be you and how you expected to feel. As someone only a little older than yourself, I would say this: your job will never love you back, and especially in the software realm, it may not be as fulfilling as something like woodworking or therapy. It does pay the bills, though.
The above mentioned happiness research / positive psychology suggests that having multiple, meaningful social roles that you can fulfill outside of work will allow you to shoulder more responsibility and find meaning in your life.
What I'm trying say is that in the second half of life, it is our job to give back. So start there.
Without a doubt one of the best technical books I have ever read.
To me, it was a missing piece of the big puzzle of "how do computers work". I read many a book to answer this question, and came away with three books:
- CODE by Charles Petzold explains the CPU
- Operating Systems: Three Easy Pieces by Arpaci-Dusseau explain OSes
- Crafting Interpreters by Robert Nystrom explains programming languages
It doesn’t seem to exactly fit your description but Python Challenge (http://www.pythonchallenge.com/) has been incredibly fun and rewarding for me back in the day.
It’s a series of riddles that are meant to be solved using the python language. It’s really old now but I’m hoping that some library specific riddles are still relevant. Apart from those few, most of them should be language agnostic as well.
I’ve always wanted to create a similar thing to replicate the experience in JS but never gotten around to it.
Edit: oh also completely agree with most of the recommendations here. Particularly with TIS-100, Factorio and Human Resource Machine.
For 2, Codingame's bot programming challenges are excellent. To get high on the leaderboards you need to write super well optimized code and have clever ideas, which is about as fun as a programming challenge gets. To get started, I'd recommend their TRON lightcycle game, which has a great combination of approachable ruleset and deep gameplay.
