Matt Rasmussen 2025-01-27 13:05:28 I've been thinking about what libs and pkg indexes might look like as coding assistants become the norm. What if instead of packages providing a post_install.sh script (to regex config, add symlinks), they had a post_install.md prompt to help integrate the code into your app.
Libraries and packages indexes (especially language specific ones) have been a boon for code reuse. But they can only be used for code that can be cleanly abstracted. I often encounter chunks of code I wish could reuse as a lib, but I can't because I can't abstract it well enough
But if you wanted to package up a partial table schema and some prompt about how it could be rendered in a UI, then the package manager+coding assistant could auto merge the partial schema into the user's existing schema and even make the right UI updates to show the new fields
This might really help when building apps using coding assistants. Having assistants write so much code from scratch still feels unpredictable. What I really want is to be able to suggest from an index of code fragments and prompts which things to glue into my app.
Such a package index would encourage open source contribution of prompts plus pre-made code fragments. I'm interested in others thoughts.
Bill Mill 2025-01-27 13:50:52 David Crawshaw’s article might be relevant to your interests; he says that he uses more local packages because it’s easier to keep context smaller to work with LLMs:
As LLMs do better with exam-style questions, more and smaller packages make it easier to give a complete and yet isolated context for a piece of work. This is true for humans too, which is why we use packages at all, but we trade off package size against the extra typing/plumbing/filing to make more readable code. With an LLM both doing and benefiting from a big chunk of that extra work, the tradeoff shifts. (As a bonus, we humans get more readable code!)
which I think meshes well with your idea about having small chunks that are integrated directly into the program, rather than isolated in a node_modules or site_packages or whatever
Matt Rasmussen 2025-01-27 14:10:33 Ah, thanks for the reference! That's a cool observation that this trend would encourage smaller packages since writing the extra glue code between them isn't a burden for LLMs. That's a nice way to put it.
George Campbell 2025-01-27 17:50:04 Also, LLMs, please save us from incompatible dependencies. I had a situation where external dependency A, which I was already using, depended on X-v1.0, and I couldn't add a library B that depended on X-v2.0.
Matt Rasmussen 2025-01-27 18:10:17 I would love that. Just have the llm solve the dep incompatibility either by finding the right versions or doing the refactorings in the main app to make it work
Karl Toby Rosenberg 2025-01-27 21:21:22 What if there were just a way to auto-import based on you using function calls from so-and-so library? The agent could suggest imports and handle everything by preprocessing your code.
Jim Meyer 2025-01-29 08:49:15 AI-coding (chat) to create UIs — working software you can own — is the "worse is better" existential threat to traditional design tools and no-code.
This is as big, or bigger, than the "worse is better" that JavaScript pulled off for the Internet.
Chat is slow, but it gets the job done in a super accessible way, hence the "worse is better".
The real prize will be to combine the best parts of chat with the best parts of the canvas in design tools / no-code tools.
Oleksandr Kryvonos 2025-01-29 09:41:59 I was sceptical about LLMs up till yesterday,
what changed? - arrival of Deepseek R1
Do I think it is "Sputnik moment" - not entirely,
I think it is more like an "Apple I moment" - in a sence that now more people can experiment with this idea,
And the tools are no longer in the hands of only big players.
I will explore the combined approach - I will use LLM with some simple workflows,
For example verification/critique of answer first.
And I will research the subject more carefully.
I do not have powerfull hardware - Apple M1 and SteamDeck ,
So I hope that these limitations will benefit me.
Mariano Guerra 2025-01-30 16:37:07 Guyren Howe 2025-01-30 20:15:31 When the efficiency of use of an input drops dramatically, so the price of the product drops dramatically, the demand will rise, maybe enough to raise the price of the input:
There may be a boom in demand for programmers.
Nvidia stock may yet go much higher.
William Taysom 2025-01-31 07:31:14 These are some great questions. Hot takes...
Will we never see another new programming language reach the mainstream?
Even at this point, you can drop your syntax into a prompt and LLMs can pick it up reasonably well. A better technique will to be to automatically translate a bunch of program and then use those to retrain. Similar sort of thing is happening with teaching LLMs math. What we're beginning to see is feedback between more analytical systems and "intuitive" pattern recognizers. It's all janky now, but results seem promising.
Will we see languages that are optimized for synthetic data generation? ... Will we change how we modularize code? ... When will we store the prompt alongside the code it generated?
I bet!
Will we see a melting of language servers and LLMs?
Again with the intuitive/symbolic distinction, there's benefit in delineating between creative and verification aspects of an assistant. Now I want you to try something new vs just check and refine what's already here.
Will techniques that trade code density for performance, such as loop unrolling, become popular because loops won’t have to be unrolled by hand?
Don't JITs already do this? I thought that was one of their superpowers.
Jason Morris 2025-01-30 23:56:43 Is it neuro-symbolic AI if a generative AI system is used to generate a symbolic representation, which is then modified by a human user, and provided back to the generative AI in a later phase? Or does neuro-generative AI specifically require automated reasoning over the symbolic knowledge? I'm playing with a system for editing propositional argument maps that were generated by an LLM, and I'm not sure that counts. Is it "reasoning over symbolic knowledge" if a symbolic data structure is only being used to generate a graphical UI? It seems borderline, but I'm inclined to think not, and if we aren't reasoning over it, it doesn't count...
Konrad Hinsen 2025-01-31 05:51:58 Is this just about jargon? That's so fluent around AI that I wouldn't worry about it at this point in time.
Jon Secchis 2025-01-31 03:37:09 Hey, folks. I'm experimenting with a universal structured input interface for my research project. The idea is that commands/functions will provide a schema and invoking them prompts the user with a form. I'm pushing for super tight constraints on information density (I want interfaces to spread over time to save screen space, non-negotiable). Now since inputs are going to be generated I cannot have exceptional designs/behavior – it's all going to be rigorously data driven and I can only affect the design/experience by changing the data model. Below are two videos showing how a user would invoke a function for data input. Each video represents a distinct data model. The one with a tabular data model yields a short "time-to-first-field" (less overhead) interaction. The one with a composable tree model (much much more powerful) yields more overhead (2 more steps to reach the first field). Can you share your opinions? Not seeking any specific kind of feedback, just wanna hear your thoughts.
Jon Secchis 2025-01-31 03:55:23 just to clarify the deal with spreading interfaces over time, since most tech minds find them so weird and wasteful: it's super easy to create arbitrarily complex interfaces where you cram lots of affordances in the screen, it can be done in an infinite number of ways; the opposite is not true; if you have minimal space to work, then there's a very small set of usable interfaces for any given interaction pattern. I want to find those minimal interfaces first, as the other kind I can do at any time
