4 ms·

Shell scripting and JavaScript are strengths, any kind of server-side language like Scala or C# it really falls apart quite quickly. I think that integrating i

Shell scripting and JavaScript are strengths, any kind of server-side language like Scala or C# it really falls apart quite quickly. I think that integrating into existing APIs is the Achilles' heel, GPT-4 doesn't seem to do any better here either. It makes me wonder if someday we might not get better results completely eschewing libraries altogether and letting the transformers generate literally everything--perhaps recreating similar client libraries over and over and perhaps based on specific existing human-authored libraries, but each one unique to the service, e.g. no external dependencies at all.

manmal 4y ago
I think it will be quite the opposite. Generating a lot of code means generating a lot of bugs. LMMs should get the (battle tested) libs they have to use as part of the prompt, and they should just use those APIs.
- passion__desire 4y ago
  Just as nobody should roll their own cryptographic library, the same rules apply to LLMs.
- deleted 4y ago
  [deleted]
halfjoking 4y ago
I’ve also been wondering if no framework coding will be more productive for LLM driven software. How many times have frameworks like React changed since it was created? A changing framework means the LLM may mix training from multiple versions and create errors. Whereas libraries that don’t change can produce consistent results. So use stable libraries that choose backwards compatibility at any cost, over the ones that change with the times.
- surgical_fire 4y ago
  Frameworks and high-level languages exist as abstractions to make writing code easier for humans. Wouldn't make more sense for a machine to just write assembly directly?
  - halfjoking 4y ago
    They aren’t trained on assembly. Even if they were, the tools for debugging assembly wouldn’t be as helpful if the LLM wanted to iterate when given compiler errors. The compiler errors they’re trained on are errors humans run into. Now they also have training on frameworks but those keep changing. So I think the best abstraction is plain javascript - it has the most training data and javascript written twenty years ago still works today.

manmal 4y ago

I think it will be quite the opposite. Generating a lot of code means generating a lot of bugs. LMMs should get the (battle tested) libs they have to use as part of the prompt, and they should just use those APIs.

passion__desire 4y ago
Just as nobody should roll their own cryptographic library, the same rules apply to LLMs.
deleted 4y ago
[deleted]

halfjoking 4y ago

I’ve also been wondering if no framework coding will be more productive for LLM driven software. How many times have frameworks like React changed since it was created? A changing framework means the LLM may mix training from multiple versions and create errors. Whereas libraries that don’t change can produce consistent results. So use stable libraries that choose backwards compatibility at any cost, over the ones that change with the times.

surgical_fire 4y ago
Frameworks and high-level languages exist as abstractions to make writing code easier for humans. Wouldn't make more sense for a machine to just write assembly directly?
- halfjoking 4y ago
  They aren’t trained on assembly. Even if they were, the tools for debugging assembly wouldn’t be as helpful if the LLM wanted to iterate when given compiler errors. The compiler errors they’re trained on are errors humans run into. Now they also have training on frameworks but those keep changing. So I think the best abstraction is plain javascript - it has the most training data and javascript written twenty years ago still works today.