The implementation of the layer technique showed by Gerald in this video seems to give ability of 'dynamically adding hooks to the continuation, under the convention of layer name' to programmer.
i wonder if the abstract(ed), "conceptual" structure of what electric implements generalises to other shapes of resource management, what a great piece of creative achievement / technology
Oh boy... I wanted to quit software development because the industry is forcing me to learn React/Angular just to slave away at my job and stay relevant to the latest js framework. I'll just quit my current job and start using electric. Thank you for this tool
Compare something like "lein new luminus guestbook +h2 +http-kit" versus "clojure -Tnew create :template io.github.kit-clj :name eric/guestbook". I prefer that lein command. I hope you guys can make kit command-line usage simpler.
Nikita (the author) loves the developer experience using Clojure. It's an elegantly simple language, and the ability to interact with a running program and evaluate any expression/form is amazing! Check out what Robert Cecil Martin says about Clojure on his blog, and check out any talk by Rich Hickey (creator of Clojure) if you are wanting to know more.
On the first point, I would like to say that yes, all tools have downsides. However, there are tools whose downsides didn’t originate as a trade-off, but rather as a result of unconsciously bringing what’s familiar into a newly created tool. There are so far tools that are objectively much better than others in their field. And we should improve precisely these tools, preferably by learning from the other awesome tools. Let’s enumerate the best so far: 1. Embedded and low-level: Zig. 2. Theoretical: Haskell. 3. Server systems: Erlang/Clojure. Does the world need more than these languages? No. Moreover, if Haskell, Erlang and Zig were Lisps, nobody could say that there is a language that is better at some tasks than them, since they could just be extended to be semantically like that better language. So, we can all do objectively better, and we should strive to do that.
54:17 about the name of this "interactive comment" pattern. I realized that the theoretical foundation of this thing might be "The Explicit-Control Evaluator" from SICP 2e Sec 5.4, because exactly what you do is to manually control the evaluator to interprete your source codes beyond the normal opearations of Clojure automatic tool chain. Oh my JVM, the lisp machines are back. Hence, the title may also be dubbed "Turning JVM(or node) into a Modern Lisp Machine".
Also in Sec5.4.1, one can read "The central element in the evaluator is the sequence of instructions beginning at eval-dispatch. " And I can see VSCode is the GUI for this eval-dispatch, while emacs could be the TUI.
There's a couple of other considerations I had on this topic that I didn't end up talking about: files are still useful by themselves if you don't have the database process anymore (e.g. a disk you leave around for 5 years), and files are still useful if you only have part of the total set (e.g. some of your data got corrupted). I think these two properties are really important for knowledge systems, and I don't think a lot of systems I interact with have their data in this way.
I find the way you explained the problem very useful as I never thought about using linear algebra directly especially when dealing with large quantities of data. It also help what actually happens inside libraries. Thank you Dragan!
*Abstract* This talk explores the challenges and opportunities of building LLM orchestration tools. The speaker examines the complexities of accommodating diverse application needs while keeping up with the rapidly evolving LLM landscape. He discusses the functionality of his tool, `bosquet`, including configuration, prompting techniques, caching, output formatting, and integration with vector databases. The talk concludes with a call for collaboration on optimizing execution plans for complex tree-based prompts. *Summary* *The Need for LLM Orchestration Tools (**0:05**)* * LLM orchestration tools like LangChain, LlamaIndex, and AutoGPT aim to simplify building AI applications by managing prompts, providing interfaces to different LLM providers, and enabling complex workflows. * These tools strive to offer a generic infrastructure for diverse applications while facing the challenge of keeping pace with the rapid advancements in LLM technology. *`bosquet`: Functionality and Features (**4:05**)* * Configuration: `bosquet` offers a flexible configuration system for managing calls to various LLM providers and models with parameters like API keys, endpoints, and model specifications. It allows for easy switching between providers and models for different tasks within an application. * Prompting Techniques: The tool supports three prompting techniques: * Simple Completion: For basic text generation tasks. * Chat Completion: For managing conversational interactions with an LLM, similar to ChatGPT. * Tree-Based Prompting: For defining complex workflows with dependencies between different prompt components. * Caching: `bosquet` implements a caching mechanism to avoid redundant LLM calls, improving performance and cost efficiency. * Output Formatting: While newer LLMs support function calling for structured outputs, `bosquet` provides support for generating outputs in specific formats like JSON, EDN, and boolean values. * Text Chunking: The tool offers various text chunking options for splitting text into smaller segments based on characters, sentences, or tokens. However, the speaker questions the long-term value of this feature due to increasing context window sizes in LLMs. * Document Loading: `bosquet` leverages the Apache Tika library to load and extract text from various document formats like PDFs and Excel files. * Vector Store Integration: The tool supports integration with vector databases like quadrant for building RAG (Retrieval Augmented Generation) applications. *Challenges and Future Directions (**46:39**)* * One of the key challenges in `bosquet` is optimizing execution plans for complex tree-based prompts, particularly identifying dependencies and parallelization opportunities. * The speaker invites collaboration from the community to address this challenge and improve the efficiency of LLM application development. i used gemini 1.5 pro to summarize the transcript Token count 10,711 / 1,048,576
Thank you for sharing this amazing project with us. Kit really helped me understand how to effectively use integrant to build a data driven web server architecture. Cheers!
Don't forget about getting into conversations with RU-vid creators like Primagen etc. I got into Closure because he started showing his audience OCaml, and so I started to get into functional programming because it was a new thing that looked interesting to me.
Can you write the URLs of alternative apps you mentioned at instant 06:00 ? The transcription says: ... I think like the appana is pretty great also has some downside like it's uh you know you don't own your data walki is also pretty great uh it's open source ... I don't find anything related to this with names appana or walki.
