Anton (Jan 10 2025 at 16:27): Anton (Jan 10 2025 at 16:27):I've been thinking about this for a while https://x.com/VictorTaelin/status/1877750345838870668 (tweet was deleted, see below)
I think we should keep this in mind in our decisions.
Anton (Jan 10 2025 at 16:28):(I posted this in #ideas because it is related to our discussion of ideas even though it is not a proposal)
Anton (Jan 10 2025 at 16:31):The tweet got deleted :p
Sam Mohr (Jan 10 2025 at 16:31):Screenshot from 2025-01-10 08-31-37.png
Sam Mohr (Jan 10 2025 at 16:32):I had the tab open
Anton (Jan 10 2025 at 16:32):Thanks Sam :heart:
Sam Mohr (Jan 10 2025 at 16:32):100% accuracy take no matter how you feel about AI solving hard research problems, I hope we can all agree that manually entering characters in a code editor is already starting to feel archaic in 2025, and will absolutely be extinct by 2027
We will soon find it crazy that developers would sit down and hand-type lines of structured code all day. Each day it makes more and more sense for machines to handle that part for us.
Anton (Jan 10 2025 at 16:34):Like one implication would be to prioritize the code reading experience over the code writing (with current technologies) experience.
Sam Mohr (Jan 10 2025 at 16:35):I agree that all of my decisions (and ours as a team) should be read-focused, like 90%
Sam Mohr (Jan 10 2025 at 16:35):That's the source of #ideas > Warning for unannotated exposed symbols
Anton (Jan 10 2025 at 16:36):Anton said:
Like one implication would be to prioritize the code reading experience over the code writing (with current technologies) experience.
One specific thing would be the auto-complete benefit of static dispatch.
Anton (Jan 10 2025 at 16:49):Currently I feel that the static dispatch (with PNC) style is less readable than the old way. But it's hard to predict how I'll feel when I'm used to working with static dispatch.
Sam Mohr (Jan 10 2025 at 16:51):I think Rust gives us a pretty good understanding of how readable static dispatch Roc will be: Rust is very readable during the let x = y sections without type annotations, so long as you know the inputs and outputs of functions/blocks
Sam Mohr (Jan 10 2025 at 16:51):I think Roc will be very understandable with SD so long as SD-heavy sections are supported with type annotations for their inputs
Sam Mohr (Jan 10 2025 at 16:51):But like you, I could be wrong
Brendan Hansknecht (Jan 10 2025 at 16:57):As a note, being more autocomplete friendly and more linearly written should overall help ai.
Brendan Hansknecht (Jan 10 2025 at 16:58):I assume future ai will be able to get lsp hints as part of their input as they write code. They already manage to use tools for various things.
Brendan Hansknecht (Jan 10 2025 at 16:59):And ai currently (and for the foreseeable future) generate code from start to finish linearly. So they can get tripped up by being wrong about nesting among other things.
Brendan Hansknecht (Jan 10 2025 at 16:59):Not to mention, way more languages use PNC, so ai generally does better with it.
Brendan Hansknecht (Jan 10 2025 at 17:00):So I would guess that SD and PNC will make roc more ai friendly (even if arguably less human readable).
Sam Mohr (Jan 10 2025 at 17:01):I think you're right that these changes will make Roc easier for AI to write
Sam Mohr (Jan 10 2025 at 17:01):I think Anton is more trying to imply that any feature that's better for writing but worse for reading should be considered less valuable
Sam Mohr (Jan 10 2025 at 17:02):Because we won't have to do nearly as much writing in the coming years
Brendan Hansknecht (Jan 10 2025 at 17:03):Yeah, that's fair....I'm not sold which of PNC/SD and the old form is more readable. My gut feeling is under the guidance of a good code author, the old form. Under the guidance of the average code author, the new form
Sam Mohr (Jan 10 2025 at 17:03):A good assessment
Sam Mohr (Jan 10 2025 at 17:04):Roc is aiming to be very friendly to beginners and non-FP devs in general, so we'll definitely have more of the latter than average for an FP language
Richard Feldman (Jan 10 2025 at 17:36):I think the post is wrong
Richard Feldman (Jan 10 2025 at 17:37):I think there will be much less hand editing than today
Richard Feldman (Jan 10 2025 at 17:37):but if you've ever tried to have an LLM make small tweaks to existing code, it is obnoxiously slower than just using the keyboard to go in and make the change
Richard Feldman (Jan 10 2025 at 17:38):"no, like change the third letter from a to b. No, the third letter in the second string on line 476, put the other one back the way it was"
Richard Feldman (Jan 10 2025 at 17:41):I think the balance will continue to shift, where a much higher percentage of code is written using llms compared to by hand, but I think once you get to 100% LLM, you're working more slowly than someone who is doing a mix of both
Anton (Jan 10 2025 at 18:46):Richard Feldman said:
"no, like change the third letter from a to b. No, the third letter in the second string on line 476, put the other one back the way it was"
It is possible that the developer focus shifts substantially to the behavior of the code and they would no longer be performing small tweaks.
Anton (Jan 10 2025 at 18:51):Richard Feldman said:
"no, like change the third letter from a to b. No, the third letter in the second string on line 476, put the other one back the way it was"
Anyway the remaining need for these very small edits would probably not impact any of our discussions in #ideas to a significant degree.
Richard Feldman (Jan 10 2025 at 19:03):it's possible but I think it's very unlikely. One of the only things that's always been constant among building things for the past several thousands of years is "polishing details based on the taste of the tool user" and although it's possible that this would change, I think the likelihood is very low :big_smile:
Richard Feldman (Jan 10 2025 at 19:03):but yeah I agree that it doesn't change things much
Richard Feldman (Jan 10 2025 at 19:03):I do think it's relevant in the context of autocomplete though
Richard Feldman (Jan 10 2025 at 19:04):because autocomplete is one of those things where having it vs not can be the difference between "I can do this faster by describing what I want done vs directly editing" or not
Richard Feldman (Jan 10 2025 at 19:05):which is to say, I think autocomplete will still be valuable, although the coefficient on the multiplier will be significantly lower than it is today
Eli Dowling (Jan 10 2025 at 20:00):I actually have a theory that PNC/static dispatch will be worse for llms.
See one of the issues llms currently have, is kind of just forgetting what types things are when writing larger blocks of code.
I fairly often have the issue where when writing more complex stuff, it just kind of forgets that you need to fenagle a variable from one type to another.
I think that a language with few type annotations would be particularly susceptible to this issue.
Having the type as a prefix for function calls however, gives the llm a way to keep track, in code, of what type things should be.
I particularly worry that with static dispatch and not many type annotations, the infered types and the errors they show will be way less helpful. As in instead of seeing:
...
a= b |> Str.split "b" |> Dict.get "first"
# Dict.get expects a Dict you provided a List
...
a=b.split("b").get( "first" )
# Str doesn't have method get
Contrived example I know, but hopefully you get the point
Richard Feldman (Jan 10 2025 at 20:21):I haven't verified it experimentally, but I kinda suspect llms will be about as good at either style because above all else they're outputting variations on patterns in their training sets
Richard Feldman (Jan 10 2025 at 20:22):which is to say, if they've seen patterns of |> Result.map vs .map( I think either way they're not "building a mental model of the type" like we do
Richard Feldman (Jan 10 2025 at 20:23):but rather following patterns in similarly shaped code they've encountered before, regardless of what that shape happens to be
Brendan Hansknecht (Jan 10 2025 at 20:25):If types truly become a problem, long term I would expect the llms to just communicate with the lsp.
Richard Feldman (Jan 10 2025 at 20:25):ha, that's true
Richard Feldman (Jan 10 2025 at 20:26):actually that can already be done
Richard Feldman (Jan 10 2025 at 20:27):like instead of sending code snippets to the llm verbatim, the editor could send them with all the inferred types explicitly annotated absolutely everywhere (with comments if it wouldn't work syntactically) and then strip them back out when the llm responds with similarly over-annotated code :big_smile:
Brendan Hansknecht (Jan 10 2025 at 20:33):Yeah, could be done today. Llms even have tool use.
Brendan Hansknecht (Jan 10 2025 at 20:33):I just haven't seen it wired up today in a complete form
Ray Myers (Jan 11 2025 at 02:07):Brendan Hansknecht said:
Yeah, could be done today. Llms even have tool use.
Right, there have been some attempts to bridge that gap by integrating LLM with LSP, for example llmvm might be one of the more developed.
Last May I also blogged about a simple self contained workflow using LLM generate type suggestions in Python and then validate them with Mypy. This was meant as a demonstration that it was possible to guardrail LLMs into completely safe updates to a codebase with tool use. (To the extent the tools can ensure safety of it). Type checkers are very handy there, as is refactoring automation
https://nopilot.dev/blog/tiny-type-agent/
Luke Boswell (Jan 11 2025 at 07:44):Saw a quote from Charlie Parker applied to genAI today and thought it was really relevant;
You've got to learn your instrument. Then, you practice, practice, practice. And then, when you finally get up there on the bandstand, forget all that and just wail.
Luke Boswell (Jan 11 2025 at 07:45):I think the "power users" of AI tools will deeply understand how they work, and the problem domain -- so coding in the future will still require a deep knowledge of systems.
Last updated: Jun 16 2026 at 16:19 UTC