Post AU3PReqfAlLQccSAPA by numist@xoxo.zone
(DIR) More posts by numist@xoxo.zone
(DIR) Post #AU31Cl05cSxYSUDyTI by simon@fedi.simonwillison.net
2023-03-27T17:21:47Z
0 likes, 0 repeats
So much of modern engineering is predicated on code being time-consuming and expensive to writeReact exists because writing native JavaScript DOM code without it is way more verbose and less pleasant to maintainI have an inkling of a suspicion that AI-assisted programming might change this balance - things like typing out long-form JavaScript isn't nearly as unappealing to me now I can get the computer to write more of it for me
(DIR) Post #AU31Uifj10aaRvGROK by apkoponen@mstdn.social
2023-03-27T17:24:46Z
0 likes, 0 repeats
@simon How do you see the maintenance aspect? As long as AI is not able to write bug-free code and/or explain code flawlessly maintaining this kind of code feels like a nightmare.
(DIR) Post #AU31mguoHkZiDItDZA by nat@ruby.social
2023-03-27T17:28:13Z
0 likes, 0 repeats
@simon Yeah this seems really plausible to me.If this is true one of the things I expect to see is AI tooling specifically for Go, since it makes a lot of productivity tradeoffs in pursuit of "easy to machine parse, and therefore to machine generate/transform."
(DIR) Post #AU31y5eycqzs8vv3Xk by simon@fedi.simonwillison.net
2023-03-27T17:28:25Z
0 likes, 0 repeats
@apkoponen AI generates code tends to be boring and predictable, which is exactly what I want from maintainable codeI don't commit any code to my projects without fully under data being it myself, so I'm not worried about thisFor throwaway prototypes I don't really care too much
(DIR) Post #AU32KeQq1bwsMD41Ee by simon@fedi.simonwillison.net
2023-03-27T17:30:37Z
0 likes, 0 repeats
@apkoponen but yes, we may well find that abstractions like React are worth keeping around because succinct code is easier to reason about and maintain even if we don't still have the benefit of from not having to type it all out ourselves any more
(DIR) Post #AU32X7YLZyG49LWQl6 by not2b@sfba.social
2023-03-27T17:34:55Z
0 likes, 0 repeats
@simon How can you know that the code produced by an AI generator is reliable and not full of subtle bugs and security holes? Seems more reliable to have a language that is easy to write and that can be compiled into native JavaScript. For most code, far more effort is spent in maintaining, fixing, and improving the code than was spent writing it in the first place. If you can speed up the original code production but maintenance becomes much harder you don't win.
(DIR) Post #AU32iEX5y7eGyzEexs by murb@todon.nl
2023-03-27T17:35:29Z
0 likes, 0 repeats
@simon i would still provide simpler and less code over generated code (not something that eg react typically brings either). Would be happy if AI would just optimise during some compile step (eg type checking without manually providing types)
(DIR) Post #AU32ug3hSCqNpNQ5KK by rmcomplexity@mastodon.social
2023-03-27T17:36:09Z
0 likes, 0 repeats
@simon I think there's another level missing here. React is used to avoid writing native JS but React is never used as-is. There are custom component per company/org/team and patterns.AI (LLM) assisted code won't necessarily give you the same suggestion for the same problem. Coming up with shared code is more valuable when more people knows exactly why/how it works.
(DIR) Post #AU32uhZHqFhkVdCpCS by rmcomplexity@mastodon.social
2023-03-27T17:37:46Z
0 likes, 0 repeats
@simon But, I think AI-assisted examples or learning the underlying platform, even if it's team specific only, it's probably where the best win is.Imagine how many meeting can we cancel if we don't need to pair up with someone else to correctly write CI/CD configuration that only gets touched once every 6 months?
(DIR) Post #AU339Zmd4GDIi0XV0C by Captainobservant@zeroes.ca
2023-03-27T17:38:16Z
0 likes, 0 repeats
@simon but what about abstraction? I'm not convinced AI assistants understand how to create layers of abstraction that make larger programs easy to understand, change, and test.
(DIR) Post #AU33MXUgtHaTNCKWfI by jesse@metasocial.com
2023-03-27T17:39:51Z
0 likes, 0 repeats
@simon More lines of source still means more places for bugs to lurk.
(DIR) Post #AU354kQoFcAsC49uLI by jakelazaroff@mastodon.social
2023-03-27T18:04:55Z
0 likes, 0 repeats
@simon Aren’t you just describing… programming, though? As opposed to “modern engineering”.Like, *all* abstractions exist because the layer below is time-consuming and expensive. It’s just as true for React as it is for Django, or HTTP, or even programming languages in general — otherwise, we’d all be writing machine code!
(DIR) Post #AU36racnbGzFvGcW6S by brianleroux@indieweb.social
2023-03-27T18:24:29Z
0 likes, 0 repeats
@simon personally think writing code against the browser it runs on is waaaay faster to author and maintain than chasing frameworks. Browser/Node native JS got really nice in the last decade and transpiling has so many tradeoffs. Sadly the bootcamps didn't teach any of the standards based stuff and kinda admonished it making a generation of devs believe bullshit they never personally have experienced.
(DIR) Post #AU376nEyydFZOTjJOy by jonn@social.doma.dev
2023-03-27T18:27:44Z
0 likes, 0 repeats
@simon and who maintains it? Maintenance via rewrites?
(DIR) Post #AU37IPI3qjWYaWhwA4 by Franky47@mamot.fr
2023-03-27T18:28:01Z
0 likes, 0 repeats
@simon we may see abstractions appear that are better suited for AI to understand/write/maintain, but more opaque for humans.This sort of "cross-species" gatekeeping and knowledge power transfer is worrying, especially as its impact on meatspace increases.
(DIR) Post #AU37Ue1IuW6XkLhluy by tonytw1@mastodon.sdf.org
2023-03-27T18:28:24Z
0 likes, 0 repeats
@simon This. Some of the devs at the current place are using AI to wade through 1000s of lines of Cloud Formation. I do wonder if it'll mean they stop questioning why there are 1000s of lines though
(DIR) Post #AU39Ho80DYZJEvqRCy by simon@fedi.simonwillison.net
2023-03-27T18:52:11Z
0 likes, 0 repeats
Plenty of push-back against this idea and I agree with all of it - more code means harder to maintain in the future, more risk of bugs, etc etc etcThat's why I said "an inkling of a suspicion" though... I think it's unlikely... but I'm also open to the possibility that we might be surprised at how our preferred styles of programming changes now that we don't have to type every character ourselves any more
(DIR) Post #AU39jHolwJfn8jx8oC by schizanon@mas.to
2023-03-27T18:55:52Z
0 likes, 0 repeats
@simon we didn't start using react because `document.getElement` is hard to type, that was jQuery.We started doing React because of what happens when the state of the app changes. People think DOM diffing is slow, but running an AI in the browser just to determine which elements need to be added/removed is gonna be WAY worse.
(DIR) Post #AU39zae5hqqcANjO1Q by pdcawley@mendeddrum.org
2023-03-27T18:59:51Z
0 likes, 0 repeats
@simon I never managed to get it working reliably enough, but when my coding by voice system was working at its best, it was really obvious that it had so much potential. If I'd managed to get it properly solid before I quit coding professionally, I wouldn't have gone back to typing 8 hours a day (I know. Allow me the simplification) for anything.If LLMs work out, then Conversational Programming might be nearer than I thought, but I'm still sceptical.It'd be lovely to be wrong though.
(DIR) Post #AU3ADrKWTG2vxyNktE by fancysandwiches@mstdn.social
2023-03-27T19:01:34Z
0 likes, 0 repeats
@simon I think it will get very difficult for these types of tools to really take off because someone still has to maintain the code, and these tools are basically just a form of copy/paste that is easier to use. If you are writing software without really understanding the underlying code you're going to have a hell of a time fixing issues with it.
(DIR) Post #AU3ARGmFAczCeak7yC by deivudesu@mastodon.social
2023-03-27T19:04:20Z
0 likes, 0 repeats
@simon A huge feature of *good* code, is being both efficient (to write and run) *and* highly readable.This generally means striking the right balance between concision and obfuscation.What you are describing, sounds a bit like the code equivalent of using AI to write endless verbose research papers, coated around small nuggets of results. Not sure that would be pleasant to read in either case…
(DIR) Post #AU3Ah6QvOdQ7CqJy4m by 22@octodon.social
2023-03-27T19:07:57Z
0 likes, 0 repeats
@simon reminds me of something Moxie Marlinspike (the Signal guy) tooted a few years back and that’s stuck with me:Many trends in modern programming language design seem to focus on developers pressing fewer keys on the keyboard. To me, that's a strange priority.For large systems where the industry spends most of its time, I think "readability" is much more important than "writability."For example, even simple features like "type inference" feel like misplaced priorities to me.People say "it's annoying I have to write String foo = new String()," but realistically, you're more often writing "String foo = bar.getBaz()"If that becomes "val foo = bar.getBaz()"...what is "foo?""The compiler can figure it out!" they say. But what I care about is whether someone looking at the code can figure it out.We're writing 3 fewer characters one time, at the cost of less information for the ~years people will have to read and understand it.Languages designed for "writability" have function signatures that require you to press very few keys on the keyboard:"def foo(bar):”It's nice to press so few keys to write it, but error prone for the thousands of times people have to read/modify it.Duck typing, no checked exceptions, type inference, last-statement-returns, etc etc require us to press fewer keys on the keyboard, but that is not the problem I see most organizations dealing with. Or if it is, I think giving everyone a copy of Mavis Beacon would do less damage.https://nitter.net/moxie/status/1256640033383051266
(DIR) Post #AU3COaVJZMswsKfotk by fancysandwiches@mstdn.social
2023-03-27T19:03:06Z
0 likes, 0 repeats
@simon As a result I think we'll see impressive demos where someone bootstraps something functional very quickly, but in the long run we won't see lots of people lean on the tools in such a manner for the whole lifecycle of a product because of how hard it will be to debug them when issues inevitably arise.
(DIR) Post #AU3CObMqMLhfYLiZKi by glyph@mastodon.social
2023-03-27T19:15:23Z
0 likes, 0 repeats
@fancysandwiches @simon I'd go a step further. We'll have an explosion of unmaintainable garbage created by a generation of programmers without the experience to realize the consequences of this sort of crutch, and a big new pile of legacy code which gets slowly cleaned up in the next generational tool shift which is too far out in the fog of the future to see. Maybe there will be a new generation of LLMs that parse and consolidate common previous-gen LLM antipatterns into maintainable code
(DIR) Post #AU3COcffVqM7b1X7JY by simon@fedi.simonwillison.net
2023-03-27T19:26:56Z
0 likes, 0 repeats
@glyph @fancysandwiches I liked this line by @geoffreylitt in https://www.geoffreylitt.com/2023/03/25/llm-end-user-programming.html> End-users already write messy buggy spreadsheet programs all the time, and yet we somehow muddle through—even if that seems offensive or perhaps even immoral to a correctness-minded professional software developer.
(DIR) Post #AU3COdqL9eUDEPX9aS by glyph@mastodon.social
2023-03-27T19:16:45Z
0 likes, 0 repeats
@fancysandwiches @simon like I think the tools will get good enough to get you to launch, but will hit a wall before they get good enough to get you past your first, say, PCI/HIPAA/GDPR audit.
(DIR) Post #AU3CZ6Jq8Z76RYJrX6 by simon@fedi.simonwillison.net
2023-03-27T19:28:09Z
0 likes, 0 repeats
@glyph @fancysandwiches @geoffreylitt the world really does run on a giant pile of horrible buggy spreadsheets already, how much worse is that going to get?(Maybe "a lot worse")
(DIR) Post #AU3Ctm74SQdprCClcG by fancysandwiches@mstdn.social
2023-03-27T19:32:42Z
0 likes, 0 repeats
@simon @glyph @geoffreylitt there tends to be some person or group of people who wrote the spreadsheet and have a decent understanding of it, and its limitations. When you're generating code out of thin air you're losing some of that. So yes, there will be similarities to what is currently happening, but I think these systems will be harder to maintain, because they'll be harder to debug.
(DIR) Post #AU3DjGKDtBnCKKuLHE by sminnee@mastodon.nz
2023-03-27T19:41:52Z
0 likes, 0 repeats
@simon tailored libraries – where AI helps write something similar to a core library but stripped back to just what you need – is another, perhaps more likely, alternative. Notably it’s something that teams sometimes choose to do if they have the time, but it can involve too much wheel-reinvention.
(DIR) Post #AU3E4jPuvCCidQoBRQ by Br3nda@cloudisland.nz
2023-03-27T19:45:48Z
0 likes, 0 repeats
@simon the problem is spotting the bug in the long form javascript
(DIR) Post #AU3IDF5bRppizxcWo4 by awkravchuk@functional.cafe
2023-03-27T20:31:51Z
0 likes, 0 repeats
@simon pardon me for being simplistic, but there already is exactly the tool to write native JavaScript without having to gouge your eyes out, and it is called ClojureScript
(DIR) Post #AU3IQyMMRft5AN0QZk by simon@fedi.simonwillison.net
2023-03-27T20:34:42Z
0 likes, 0 repeats
@awkravchuk I have an irrationally deep aversion to tools that require me to run a build script before I can execute my JavaScript - same reason I've stayed clear of TypeScript most of the Webpack/npm ecosystem
(DIR) Post #AU3IxzylRftjkFiV84 by scanner@apricot.social
2023-03-27T20:40:26Z
0 likes, 0 repeats
@simon I have thought the same for a very longtime. There are going to be a lot of accidents and we are not ready for it but I see it as inevitable. On top of that I think we will find many more doing things we only thought eccentric experts could do. So I feel it is vitally important to understand this new world, and how to make it safer without just denying it out of hand.
(DIR) Post #AU3JBkGGgE8v3GSVhQ by svetlyak40wt@fosstodon.org
2023-03-27T20:41:38Z
0 likes, 0 repeats
@simon but who will read and debug this autogenerated code if not we - meatbags?
(DIR) Post #AU3JMhEeGtIUqrvIwa by scanner@apricot.social
2023-03-27T20:41:39Z
0 likes, 0 repeats
@simon I used to to scoff at Star Trek being able to just say “reverse the polarity of the neutron flow” and solve problems.. but what if this is the beginning of that?
(DIR) Post #AU3M7zI3A4EiMnByfg by lornajane@indieweb.social
2023-03-27T21:16:09Z
0 likes, 0 repeats
@simon how will the next generation of software developers gain the experience and skill they need to supervise these tools? They won't get the hours of intentional practice that you did, so how do we help them get here by a route we didn't travel ourselves?
(DIR) Post #AU3McT0LFT4nDBRWT2 by Deeplearnest@emacs.ch
2023-03-27T21:21:19Z
0 likes, 0 repeats
@simon eventually, English is a good enough programming language especially for tedious and highly specialized tasks. If we run an LLM in a reproducible mode (fixed version; sampling algo; hardware), then the same sequence of inputs will lead to the same intermediate language and the same assembly code. Just like many other programming languages.
(DIR) Post #AU3Ns5UWXOQQsGZZaK by simon@fedi.simonwillison.net
2023-03-27T21:35:01Z
0 likes, 0 repeats
@lornajane their learning paths are going to be wildly different than ours and I honestly can't begin to guess if that's going to result in them missing out on crucial basics or if they'll find better ways of learning and working to compensate
(DIR) Post #AU3O363sl1wPpQMRNo by simon@fedi.simonwillison.net
2023-03-27T21:36:14Z
0 likes, 0 repeats
@Deeplearnest I'm not so sure about that - I think English is a pretty terrible programming language with respect to ambiguity and predictability, plus I'm very nervous about what happens when a LLM upgrade introduces subtle new bugs in existing prompts written against older versions
(DIR) Post #AU3PReqfAlLQccSAPA by numist@xoxo.zone
2023-03-27T21:53:21Z
0 likes, 0 repeats
@simon the "hand tool" era of software development is over
(DIR) Post #AU3S6BZL8Zk9avns9o by benjamineskola@hachyderm.io
2023-03-27T22:01:58Z
0 likes, 0 repeats
@simon wouldn’t improving the language / APIs be simpler (and more sustainable) than adding layers of AI-based tooling on top?(especially as AI-enhanced writing doesn’t address readability/maintainability.)
(DIR) Post #AU3SIxO3B3IzNGc2W8 by placeybordeaux@hachyderm.io
2023-03-27T22:13:46Z
0 likes, 0 repeats
@simon TBH I had a similar experience as I got better at VIM. Early in career and not experienced with tooling I really looked to DRY out all of my code. As I started to get good at mass edits (e.g. macros, gofmt -r) I started to feel a lot better with simple repetitive code as it became easier to both write and change.
(DIR) Post #AU3T3Q5YnTM3iD7SBE by simon@fedi.simonwillison.net
2023-03-27T22:33:50Z
0 likes, 0 repeats
@benjamineskola I genuinely wonder about thatI think we are going to see mass adoption of AI-assisted programming tools in quite short order, and it's very hard to predict what the knock-on effects from that will beI expect some of those effects to be quite surprising!
(DIR) Post #AU3TxCtR2pvv0H370i by glyph@mastodon.social
2023-03-27T22:43:47Z
0 likes, 0 repeats
@simon @fancysandwiches @geoffreylitt I think the consequences of buggy spreadsheets are sometimes laughed off, but like, this cavalier attitude to correctness *does* kill people on the regular https://www.ft.com/content/18db20d8-7726-43e2-87f1-c5861ad3dff5
(DIR) Post #AU3cohDZpMec2GUFEG by glyph@mastodon.social
2023-03-27T22:45:53Z
0 likes, 0 repeats
@fancysandwiches @simon @geoffreylitt there's also an asymmetry problem here. using an LLM to generate code vs. just having a regular ol' buggy spreadsheet is like Cc:ing an entire department manually vs. sending a message to a mailing list. It's a force multiplier for mediocrity, allowing you to generate mostly-correct junk so fast that without new tools purpose-built for this, there's no way you can scale the cleanup.
(DIR) Post #AU3cohuTFsxuBIYV5U by glyph@mastodon.social
2023-03-27T22:47:00Z
0 likes, 0 repeats
@fancysandwiches @simon @geoffreylitt one person writing some junk code, by contrast, can be, at worst, addressed by *one* other person refactoring and correcting it. one person using an LLM to create a rickety mess that makes it to production will require a team of experts to carefully dismantle and clean up. it will be like a tech debt superfund site.
(DIR) Post #AU3coidqXBGGS1mjoW by simon@fedi.simonwillison.net
2023-03-28T00:22:56Z
0 likes, 0 repeats
@glyph @fancysandwiches @geoffreylitt so this is is an interesting question for us: if we assume that LLMs are going to result in dramatic increase in the number of people creating automations, many of which will be bad, what can we do to help that happen as safely as possible (or at least limit the blast radius)?
(DIR) Post #AU3fuUs8wPWlLVv2qO by fancysandwiches@mstdn.social
2023-03-28T00:57:42Z
0 likes, 0 repeats
@simon @glyph @geoffreylitt make them output code that is syntactically wrong 😄
(DIR) Post #AU3kbvHj0zgDX2qbBY by corbin@defcon.social
2023-03-28T01:50:18Z
0 likes, 0 repeats
@simon @glyph @fancysandwiches @geoffreylitt First, notice that we don't want to just minimize environmental damage; we want to structurally prevent it.Here's my thoughts: what if we had programming environments which automatically simplify, refactor, prove, and prune code? What if we had build systems which automatically remove differences between packages, forget module boundaries, and permanently optimize compositions? We could destructure model-generated code and absorb it.I'm not thinking of e.g. Unison or Dark. I'm thinking of languages with genuine eta-equivalence, with structural types instead of nominal types, and IDEs designed to eat and digest code.It goes without saying that copyright can't be invited to the party.
(DIR) Post #AU42tpYqphb6ARXxFA by mariohamann@indieweb.social
2023-03-28T05:15:14Z
0 likes, 0 repeats
@simon Can absolutely relate to that. Instead of using oversized libraries to have a more pleasing API, I just let ChatGPT create the single thing I need.
(DIR) Post #AU4GCh4JvkrCjcahwe by glyph@mastodon.social
2023-03-28T07:44:26Z
0 likes, 0 repeats
@simon @fancysandwiches @geoffreylitt I am at a loss here. The right answer is "liability for faulty software" so that it becomes way too scary for commercial entities to rely on this stuff, but the most recent attempt at regulation of this kind was … the TikTok hearings, which were embarassing.
(DIR) Post #AU4vhlY1QKY9ixQ1YW by Deeplearnest@emacs.ch
2023-03-28T15:29:00Z
0 likes, 0 repeats
@simon I agree that versioning is a huge problem, however it may be solvable eventually. If everyone shared the same reproducible model, one could enforce all past inputs to be reproducible, possibly simply hashing them. (Of course that solution would only allow the model to expand or improve to new territory and it would be easy to poison the model.) Agree that English alone may not be enough, English with code or math is better, and all of these through an LLM is better yet and may allow for discovering and controlling ambiguity. I hope that now that LLM usage in code is obvious to everyone, people invent better programming languages and libraries for it. It’s an exciting time to be alive.
(DIR) Post #AU6jx9zI1rPojUfPm4 by almad@fosstodon.org
2023-03-29T12:26:50Z
0 likes, 0 repeats
@simon I think that depends on which version is more readable (where I think verbosity and conscience are a balance to strike)
(DIR) Post #AU8sVeasLBnozmRyy0 by AllWrightyThen@phpc.social
2023-03-30T13:12:09Z
0 likes, 0 repeats
@simon Exactly, being fearful that AI will take developer's jobs is like being fearful that frameworks, intellisense or stackoverflow will take developer's jobs. It's just tooling. Churning out code is the mildly inconvenient part in-between being a software developer.