3 ms·

> Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations make

> Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact. If this was true, the programming languages that are very much on the left side of > https://danuker.go.ro/programming-languages.html#non-math-map https://danuker.go.ro/programming-languages.html#non-math-ma... > https://danuker.go.ro/programming-languages.html#overall-map https://danuker.go.ro/programming-languages.html#overall-map should be very ideal for LLMs, in particular if they are dynamically typed. What I can tell you is: I experimented with AI prompts for generating Wolfram (Mathematica) code using some LLMs, and I can tell you that the results were very disappointing: in my experience LLMs have difficulties with programming languages that are - very concise, and - for which there is less code publicly available. Wolfram (Mathematica) is a good example of such a programming language.

acchow 2mo ago
> omitting explicit type declarations makes the code more compact. I guess this ignores languages with type inference? Hindley-Milner and others
JoeyJoJoJr 2mo ago
I’ve actually found Sol delivers great results with Odin, despite there not being much Odin code available. I think it is able to work well with it because: - It is a rather simple language - It has a lot of very useful libraries already built in. With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.
- aleph_minus_one 2mo ago
  > I think it is able to work well with it because: > - It is a rather simple language - It has a lot of very useful libraries already built in. > With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like. Also Wolfram/Mathematica has an insane amount of useful libraries already built in (there even exists the saying "Python is 'batteries included', Wolfram is 'spaceship included'"), and also there in a single file you can do a heck of a lot stuff. On the other hand: - LLMs tend to hallucinate non-existing function when you ask an LLM to code something in Wolfram that is not commonly done (concerning this point, nevertheless keep in mind that Wolfram is often used for "one-of-a-kind programs", i.e. for writing very specialized programs that have possibly never been done before). - Wolfram code tends to be quite dense. - If there is a small mistake in Wolfram code, the code typically simply won't work.
  - petra 2mo ago
    Is there a way in Wolfram to check whether all function names exist ? And than give it as feedback to the llm?
    - aleph_minus_one 2mo ago
      > Is there a way in Wolfram to check whether all function names exist ? There is a way to check whether a symbol has been defined: ValueQ[FunctionName, Method -> "SymbolDefinitionsPresent"] See https://reference.wolfram.com/language/ref/ValueQ.html https://reference.wolfram.com/language/ref/ValueQ.html Replace FunctionName by the function name that you want to check.
- ch4s3 2mo ago
  It’s interesting I’ve been surprised by how well Claude sonnet can write code in a language I’m developing that probably has no code in the training set. It seems like anything with syntax like python/ruby/elixir is pretty LLM friendly, and layering on a HM type system seems to help catch most errors.
frollogaston 2mo ago
Training data is a factor too

acchow 2mo ago

> omitting explicit type declarations makes the code more compact. I guess this ignores languages with type inference? Hindley-Milner and others

JoeyJoJoJr 2mo ago

I’ve actually found Sol delivers great results with Odin, despite there not being much Odin code available. I think it is able to work well with it because: - It is a rather simple language - It has a lot of very useful libraries already built in. With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like.

aleph_minus_one 2mo ago
> I think it is able to work well with it because: > - It is a rather simple language - It has a lot of very useful libraries already built in. > With just a single main.odin file you can do a heck of a lot stuff, which LLMs seem to like. Also Wolfram/Mathematica has an insane amount of useful libraries already built in (there even exists the saying "Python is 'batteries included', Wolfram is 'spaceship included'"), and also there in a single file you can do a heck of a lot stuff. On the other hand: - LLMs tend to hallucinate non-existing function when you ask an LLM to code something in Wolfram that is not commonly done (concerning this point, nevertheless keep in mind that Wolfram is often used for "one-of-a-kind programs", i.e. for writing very specialized programs that have possibly never been done before). - Wolfram code tends to be quite dense. - If there is a small mistake in Wolfram code, the code typically simply won't work.
- petra 2mo ago
  Is there a way in Wolfram to check whether all function names exist ? And than give it as feedback to the llm?
  - aleph_minus_one 2mo ago
    > Is there a way in Wolfram to check whether all function names exist ? There is a way to check whether a symbol has been defined: ValueQ[FunctionName, Method -> "SymbolDefinitionsPresent"] See https://reference.wolfram.com/language/ref/ValueQ.html https://reference.wolfram.com/language/ref/ValueQ.html Replace FunctionName by the function name that you want to check.
ch4s3 2mo ago
It’s interesting I’ve been surprised by how well Claude sonnet can write code in a language I’m developing that probably has no code in the training set. It seems like anything with syntax like python/ruby/elixir is pretty LLM friendly, and layering on a HM type system seems to help catch most errors.

frollogaston 2mo ago

Training data is a factor too