←back to thread

169 points mattmarcus | 6 comments | | HN request time: 0.885s | source | bottom
1. gopiandcode ◴[] No.43612615[source]
The visualisation of how the model sees nullability was fascinating.

I'm curious if this probing of nullability could be composed with other LLM/ML-based python-typing tools to improve their accuracy.

Maybe even focusing on interfaces such as nullability rather than precise types would work better with a duck-typed language like python than inferring types directly (i.e we don't really care if a variable is an int specifically, but rather that it supports _add or _sub etc. that it is numeric).

replies(2): >>43612696 #>>43612793 #
2. qsort ◴[] No.43612696[source]
> we don't really care if a variable is an int specifically, but rather that it supports _add or _sub etc. that it is numeric

my brother in christ, you invented Typescript.

(I agree on the visualization, it's very cool!)

replies(1): >>43613381 #
3. jayd16 ◴[] No.43612793[source]
Why not just use a language with checked nullability? What's the point of an LLM using a duck typing language anyway?
replies(1): >>43612904 #
4. aSanchezStern ◴[] No.43612904[source]
This post actually mostly uses the subset of Python where nullability is checked. The point is not to introduce new LLM capabilities, but to understand more about how existing LLMs are reasoning about code.
5. gopiandcode ◴[] No.43613381[source]
I am more than aware of Typescript, you seem to have misunderstood my point: I was not describing a particular type system (of which there have been many of this ilk) but rather conjecturing that targeting interfaces specifically might make LLM-based code generation/type inference more effective.
replies(1): >>43613791 #
6. qsort ◴[] No.43613791{3}[source]
Yeah, I read that comment wrong. I didn't mean to come off like that. Sorry.