| ▲ | Why care about programming languages(ebellani.github.io) |
| 48 points by b-man 5 days ago | 65 comments |
| |
|
| ▲ | ulrikrasmussen 14 hours ago | parent | next [-] |
| Can't remember who said it, but I think the most poignant commentary about the prospects of LLMs completely replacing humans is the simple observation that yes, you can delegate many if not all of your tasks requiring thinking to LLMs, but it is inherently impossible to delegate the task of understanding. If you hope to write an efficient prompt which gives you what you think you want, you need to actually understand what you want, which also requires you to understand what you currently have. Programming languages are a medium for transferring and - not the least - maintaining shared understanding of a software system in terms of the basic abstractions that the programming language provides. The need for good programming languages does not go away just because we use LLMs to write the code, on the contrary: would you rather review LLM-written assembly or LLM-written Haskell? |
| |
| ▲ | willtemperley 11 hours ago | parent | next [-] | | This is absolutely the headache I’m having today, an enthusiastic contributor pasting AI generated wall-of-text comments to justify their 500 line PR. How can we have a conversation and reach a shared understanding if one of the participants is avoiding attempting to understand the problem? I have no problem with AI generated code, provided it’s reviewed, but I might as well be talking to a brick wall if the person hasn’t understood. | | |
| ▲ | lelanthran 9 hours ago | parent [-] | | > his is absolutely the headache I’m having today, an enthusiastic contributor pasting AI generated wall-of-text comments to justify their 500 line PR. Easily solved - call that contributor into a meeting to explain their PR. If they cannot explain it verbally, it would be made clear to them why it cannot be approved without you having to actually say anything. In the good old days (SVN), code reviews at places I worked at were done by booking one of the many small rooms and throwing the diff up on a projector. The author could defend, explain, etc. Maybe we'll have to return to that type of code review from now on. |
| |
| ▲ | xscott 14 hours ago | parent | prev | next [-] | | > would you rather review LLM-written assembly or LLM-written Haskell? I wish we had a language that was targeted specifically for LLMs to write and humans and LLMs to inspect: - Simple robust syntax - One obvious way to do things - Static type checking - Purely functional encouraged, escape hatches for performance - Inspect-able, testable, and reviewable in small pieces - Something like formal predicates, preconditions, post-conditions, assertions, or effects typing Giving LLMs all the surface area of Python, JavaScript, TypeScript, or C++ seems like a huge mistake. It's amazing it works as well as it does. Well written Haskell is beautiful, but there are way too many ways to write Haskell: https://people.willamette.edu/~fruehr/haskell/evolution.html | | |
| ▲ | ulrikrasmussen 12 hours ago | parent | next [-] | | I don't really understand why we need an LLM-specific programming language - all of the properties you list are properties that modern programming language designers already try to achieve. > - Inspect-able, testable, and reviewable in small pieces This is more a property of the architecture than a property of the language, although some programming languages support it better than others. | |
| ▲ | NortySpock 13 hours ago | parent | prev | next [-] | | Gleam ? Elixir's exhaustive pattern matching and gradual type checking is also on my radar. I guess I don't know what you mean by effects typing. | |
| ▲ | B-Con 13 hours ago | parent | prev | next [-] | | Go seems like a pragmatic fit, even though it was obviously not designed for LLMs and nor is it purely functional. I review a lot of Go code, which means I review a lot of LLM Go code. Even though the human vs LLM authorship distinction has strong signals, Go's simple nature seems like a useful constraint on how LLMs can express themselves. | | |
| ▲ | jbreckmckye 12 hours ago | parent | next [-] | | - Too verbose, too much noise e.g. error handling. - Type system is too concrete, can't express sets or unions. - Not much support for functional programming except passing closures - Can't express immutability. Well, there's const, but it's crippled These things mean Go falls short of what GP wants. But Go has very distinct and (honestly kinda weird) design goals, it isn't really supposed to be "the simple applications language". It's supposed to be "C with NewSqueak", very much a systems programming language. You see that in its aggressively concrete type system | |
| ▲ | actionfromafar 12 hours ago | parent | prev [-] | | I agree it's easy to read. But you also have to read a lot of it, before anything interesting happens. |
| |
| ▲ | lelanthran 9 hours ago | parent | prev | next [-] | | > I wish we had a language that was targeted specifically for LLMs to write and humans and LLMs to inspect: How would this help? LLMs are fine with existing languages' syntax, semantics, idioms, etc. Where they fall over is in understanding intent of a prompt within the context of architecture, systems, roadmap, etc. | |
| ▲ | IsTom 13 hours ago | parent | prev | next [-] | | > escape hatches for performance These allow the model to cheat in ways that are harder to detect. In actually pure FP you can be sure that it's not counting function invocations to bypass tests. | | |
| ▲ | xscott 12 hours ago | parent [-] | | Yeah, but sorting algs, FFTs, matrix factorizations, backprop, and many other things just aren't the same with purely functional data structures. Maybe these well known cases could be hidden in the API, but it's easy to come up with other examples. I forget what Clojure calls it, but they have some notion about things where they're mutable during "birth" and then locked down. Someone smarter than me knows how to do this right. | | |
| ▲ | IsTom 10 hours ago | parent [-] | | That sounds like Haskell's ST monad and yeah, that could work. These are very specific "escape hatches" though and typically people want more. | | |
| ▲ | xscott 9 hours ago | parent [-] | | As far as I can tell, the good models will use whatever you give them. So it seems we should only give them language features that help humans understand and maintain what the model writes. Amusingly, a friend had Claude write some BrainF*ck the other day. Non-trivial algorithm, and it made working code on the first try. |
|
|
| |
| ▲ | sriku 12 hours ago | parent | prev | next [-] | | Lean seems to fit your ask fairly well. | |
| ▲ | empty_set35204 13 hours ago | parent | prev | next [-] | | I think ocaml is fairly close to this to be honest. | |
| ▲ | avadodin 11 hours ago | parent | prev | next [-] | | I always find it amazing that they can produce syntactically valid Python code —which is basically Whitespace with some syntactic sugar— most of the time while being utterly unable to count the rs in strawberry. | |
| ▲ | reichstein 11 hours ago | parent | prev [-] | | LLMs to inspect: - Simple robust syntax > - One obvious way to do things That always leads to more verbosity.
Much syntactic sugar is a more specialized way to do a subset of a more general thing.
Why have `a + b` when you could just write `a.add(b)`? Because it's easier to read. The general functionality needs to account for all cases, the specialized one can cut that down just the things that matter to a specific common use case. - Static type checking \<meme>Which one?\</meme> That's a very, very deep can of worms.
One could argue that of an LLM is generating the code, then the type system doesn't need to be understandable to humans, so throw in all the features you'd ever want and just have the LLM change the code if it's not valid. Unions of higher order generic functions, sure!
Or one could argue that there should be minimal magic, because the LLM understands the language only by its source, so everything should be explicit.
If the LLM can prove that something is sounds to the compiler, accept it. Give ways to give extra evidence of soundness, like declaring invariants and contacts. - Purely functional encouraged, escape hatches for performance "One obvious way to do things", except when you need two. Purely functional except when it matters. Why doesn't performance always matter?
(And how will an LLM know if it does?) Being purely functional is nice for data, but not for data structures that are updated in place. If all you do is stream data from one DB query into another, then your mutable state is the database. Otherwise might as well accept that it's a multiparadigmatic language with both imperative, functional and OO features. Just like all the others. - Inspect-able, testable, and reviewable in small pieces Good modularity and abstraction. No global scope.
Maybe something like dependency injection to decouple from dependencies?
(That does not make code readable, though.) - Something like formal predicates, preconditions, post-conditions, assertions, or effects typing That!
LLMs look at the source. The more explicit the source is, the less it has to infer from context or existing knowledge.
If the LLM can create its own predicates, accepted by the static type/analysis system, to prove that it's code is sounds, that allows more flexibility than having to fit into any fixed type system.
Do we want or need that flexibility? Maybe.
Most LLM-generated code is directly inspired by existing idiomatic code in the same language. Some is translated from other languages, trying to match up idioms. Some is just blindly trying to make unit tests pass. We could end up with generated predicates tailored to specific unit tests, not the actual concept. |
| |
| ▲ | byzantinegene 13 hours ago | parent | prev | next [-] | | we are already at the point where AI proponents are planning to have the review cycle be replaced by llms | |
| ▲ | hcfman 13 hours ago | parent | prev | next [-] | | That’s a little black and white though. It’s ruling out that the AI could make a pretty good guess as to what you likely wanted to convey. If it gets that right, then you didn’t need to understand it nearly much. When I observe its reasoning I see it doing this all the time. | | |
| ▲ | ulrikrasmussen 12 hours ago | parent | next [-] | | Sure, but at that point it hardly makes sense to discuss any of the details of the implementation since we are just treating the LLM as a black box. For all we know, it could be maintaining its own specialized programming language made just for the application. | |
| ▲ | geraneum 13 hours ago | parent | prev [-] | | How does the AI guess? | | |
| |
| ▲ | Nekorosu 12 hours ago | parent | prev | next [-] | | The original quote is from Andrej Karpathy as far as I remember. I do like a lot of his ideas but try to take them with a pinch of salt as he clearly has a technocratic bias regarding LLMs/AI. | |
| ▲ | jagadaga 9 hours ago | parent | prev | next [-] | | Do you understand every line of code written by everyone else on your team? I doubt it. But if you ever need to work with their code, that's when you might need to understand it. So, treat an AI agent like another teammate. | |
| ▲ | simianwords 12 hours ago | parent | prev [-] | | That was Yacine Twitter account and it’s false. You can delegate the task of understanding. This looks like a popular folk theory that also falls under scrutiny. | | |
| ▲ | ulrikrasmussen 10 hours ago | parent [-] | | Unless you have the technology from The Matrix which can inject knowledge into your brain, then no, you definitely cannot delegate understanding. You can delegate the responsibility of understanding to an LLM, but that is not the same. |
|
|
|
| ▲ | armchairhacker 12 hours ago | parent | prev | next [-] |
| If an LLM actually does think like a human, humans benefit from good programming languages, why wouldn’t an LLM? Programming languages allow LLMs to build invariants they can’t enforce themselves (type systems), reduce context window (syntax sugar) and represent abstract models in a way that may improve understanding i.e. increase the likelihood of predicting a correct next token. Plus, we want to understand LLM output, so it should at least be convertible into a language that’s easy for humans. EDIT: and actually reading the article, learning a new programming paradigm improves your ability to model even in your head, by noticing some
abstract thing fits some programming concept, then manipulating the concept (e.g. translation your data model into the algebraic data type,`(a | b) * (a | c)`, then realizing it’s isomorphic to `a * (b | c)`). |
| |
| ▲ | trinari 12 hours ago | parent [-] | | Yep, it helps llms, and the same is true for libraries. Technically neither are necessary. Imagine an llm that's restricted to assembly. |
|
|
| ▲ | xscott 14 hours ago | parent | prev | next [-] |
| There's a lot that's worth thinking about and discussing on this topic, but it's too loaded with emotional stuff for many people to hope for a productive discussion. I'm a programming languages nerd. I was paid to program in over 20 different languages over my 25 year career. I read up on many more languages along the way, and I wrote pet projects in a few of those. I've written a couple assemblers, compilers, and interpreters for my own languages. I think literally everyone should be taught to program in elementary school. It's arguably one of the best ways to teach logical thought and careful organization of ideas. I like Alan Perlis's quote: You think you know when you can learn, are more sure when you can write, even more when you can teach, but certain when you can program. With all of that out of the way, I think there are interesting questions to ask going forward: If you were starting a business for a great software idea, with your own savings on the line, would you hire 10 AI hostile programmers to implement the idea or 2 AI friendly people and get them some subscriptions to the top models? Remember: if it doesn't come together, it's YOUR money on the line. What are the best programming languages for LLMs to program with? Could someone design a better language that fits their strengths and weaknesses? I think the most popular human languages have way too much affordance for concerns that don't apply to models. I think letting LLMs program in human friendly languages makes the results more difficult for humans to inspect. There's a slight chicken and egg problem based on the training sets used by large models, but this can be addressed with LoRA tuning and similar techniques for open weight models. How can we make LLMs scale better so that people who don't like to program can get better "vibe coding" results? Tools like Excel are huge force multipliers for so many people who aren't interested in writing traditional code. I think it should be possible for non-programmers to solve their own problems and trust the results without becoming programmers. Anyways, I've got my own partially formed answers to those questions, but I'd like to hear what other people who aren't still suffering stages of LLM programming grief have to say and ask. |
| |
| ▲ | wwind123 12 hours ago | parent | next [-] | | As a side note, I previously commented somewhere else that, if a language has a terse way and a verbose way to do the same thing, preferring the terse way might be more economical because it saves bunch of tokens for the LLM. But for humans to review the code, we may need some mechanism to translate the code from terse way to the verbose way, if the human has a hard time understanding the terse code. > If you were starting a business for a great software idea, with your own savings on the line, would you hire 10 AI hostile programmers to implement the idea or 2 AI friendly people and get them some subscriptions to the top models? Remember: if it doesn't come together, it's YOUR money on the line. I know quite a few non-technical people that started vibe-coding this year and got good results for their ideas. What language did they use? They just asked the AI what language or tool would be best for the idea, then followed the AI's suggestions. All the setup, configuration etc. were done by the AI. They learned a bunch of things along the way, but their main focus is still on the big picture idea, not the technical details. After the project is done, they are still not technical experts, but at least they have something to run with in the real world. | | |
| ▲ | xscott 10 hours ago | parent [-] | | > we may need some mechanism to translate the code from terse way to the verbose way I completely agree. Nothing says humans need to read in exactly the syntax the model wrote. We could give the model a typed lisp, or forth, or rebol, or whatever works best, and it could be formatted into LaTeX with infix operators for the humans. This was true before LLMs though. So many people love curlies or love indentation, love 2 spaces or 4 spaces. Programmers have been married to text files as the authoritative source, using grep to search, patches to update. The expressions could be rows in a database. Then finding and formatting are done as views from that. > I know quite a few non-technical people that started vibe-coding this year and got good results for their ideas. Me too, but a few of them hit limits. A couple months ago, I'd say vibe coding fell apart at 2k loc or something. It goes further now, but I think it's fragile after you take the "one shot prompt" and try to make significant changes once the pattern is set. There's probably a way to push these limits much further out so that non-programmers can do more, focusing on what they care about, and not bogged down in programming details they don't. |
| |
| ▲ | js8 11 hours ago | parent | prev | next [-] | | IMHO, we need programming (formal) metalanguage, not just another language. Something in which can express e.g. an architectural discussion with LLM. Natural languages are not logically sound, because meaning of words can shift. We need to express ideas about programs, desired properties, and specification in a language that is semantically sound and thus gives consistent solutions to consistent requirements. Of course, the metalanguage can have the same foundation as the programming language itself. It could be expressed in Lean for instance. What is needed is to build a library of abstractions in the metalanguage that are similar to words understood by an LLM, but in a logically consistent manner. | |
| ▲ | steve1977 14 hours ago | parent | prev | next [-] | | > I think letting LLMs program in human friendly languages makes the results more difficult for humans to inspect. Does it? I think for example Ruby seems to work quite well with LLMs in this regard. Or is this not what you would consider human friendly? | |
| ▲ | byzantinegene 13 hours ago | parent | prev | next [-] | | why would you even hire 2 AI friendly people when you could just prompt it yourself? we wouldn't even need you anymore | |
| ▲ | kfreds 14 hours ago | parent | prev | next [-] | | I agree. I believe LLMs are ushering in a new golden age for programming language design and implementation. | |
| ▲ | slopinthebag 13 hours ago | parent | prev | next [-] | | > If you were starting a business for a great software idea, with your own savings on the line, would you hire 10 AI hostile programmers to implement the idea or 2 AI friendly people and get them some subscriptions to the top models? Remember: if it doesn't come together, it's YOUR money on the line. Actually a pretty interesting question. I think it depends on the software, if it's some web app or something fairly trivial and mechanical the AI friendly devs would probably be cheaper and faster. If it was like, a robotics platform or something I would hire the 10 AI hostile devs. But ideally I would hire 5 expert programmers who use AI in a pragmatic way. | |
| ▲ | latexr 12 hours ago | parent | prev [-] | | > If you were starting a business for a great software idea, with your own savings on the line, would you hire 10 AI hostile programmers to implement the idea or 2 AI friendly people and get them some subscriptions to the top models? Are you saying that 10 programmers cost as much as 2 random people and some LLM subscriptions? Sign me up for the 10 programmers, then. I wouldn’t even need most of them, I’ve done a lot with teams of two and three, and more may just get in the way. I couldn’t care less how “AI friendly” the other people are; if they’re not programmers, using LLMs to produce a program is going to lead to bad results. Why would I even hire them? Might as well do the prompting myself if the results are that good in your fantasy scenario. > Remember: if it doesn't come together, it's YOUR money on the line. So, if it doesn’t come together, I either empowered 10 people to feed their families, gave them opportunities to hone their skills, and possibly developed new friendships and contacts for future endeavours (where maybe next time they’ll even hire me); or I helped just 2 people with no return and lined the pockets of rich people who are actively exploiting everyone else and destroying the environment and social trust for personal profit. Your scenario is truly bizarre. Is it just an obvious ploy to detect those who lack in empathy and only think of personal profit? |
|
|
| ▲ | kusokurae 15 hours ago | parent | prev | next [-] |
| Any and all discussion that suggests the deprecation of human-held domain-specific, manually-able knowledge & skill, on the basis of LLM capacity, is propaganda. |
|
| ▲ | est 12 hours ago | parent | prev | next [-] |
| I think PL will have a second coming. Just like Linus Torvalds said: > AI is a productivity tool exactly like compilers were. Compilers boosted programming by 1000x. AI adds another 10x on top. Enormous. But nobody says "the compiler wrote my code." We witness more and more PL ideas re-invented in Agentic AI world. Branching, looping, task orchestration, workflow, etc. Heck even GOTO seems tempting these days. |
|
| ▲ | jagadaga 12 hours ago | parent | prev | next [-] |
| > Why spend years mastering language intricacies when an AI can generate code in any language on demand?
You can learn relatively well any programming language in a week. You don't need to master "language intricacies". |
|
| ▲ | lwansbrough 14 hours ago | parent | prev | next [-] |
| Why stop there though? My harness writes WAT directly and compiles with wasmtime. It’s very fast and very difficult to read. |
|
| ▲ | remiminnebo 14 hours ago | parent | prev | next [-] |
| English has become the new programming language |
|
| ▲ | alpha_trion 15 hours ago | parent | prev | next [-] |
| I think a lot of folks in the industry are feeling this way. It’s an existential crisis for many of us right now. Why bother progressing when slop is “good enough”? Some of us still care but I have a feeling there are a lot of people that don’t. |
| |
| ▲ | kusokurae 15 hours ago | parent | next [-] | | Good enough IFF you are dealing with a cute web app or simple SAAS or something. Software engineers feeling down should think about software designed to track medication administration, or validate their tax calculations, or to decide whether to flag you for a CIFAS marker, or whatever, and then imagine the generic "fuck it, that'll do" type vibecoder-level-engineer handling the code. | | |
| ▲ | yuye 14 hours ago | parent | next [-] | | >Software engineers feeling down should think about software designed to track medication administration, or validate their tax calculations, or to decide whether to flag you for a CIFAS marker, or whatever, and then imagine the generic "fuck it, that'll do" type vibecoder-level-engineer handling the code. That makes me feel even more down, because I know this will happen. | |
| ▲ | geraneum 14 hours ago | parent | prev | next [-] | | Even on a less dangerous level, repeated mistakes can be detrimental to your business. Imagine a typical ecommerce app for selling anything. Mess with people’s orders and money and you’ll go out of business or get sued or get a bad reputation. This not even about AI, it’s just how business works. | |
| ▲ | Foobar8568 12 hours ago | parent | prev [-] | | Novartis outsourced most of its development in India, also lots of medicine is manufactured there in dubious conditions and has been for years, if not decades, the ship has sailed long before AI slop. |
| |
| ▲ | ulrikrasmussen 14 hours ago | parent | prev [-] | | There's very little evidence, if any, to suggest that slop is actually "good enough". I have interacted with multiple apps that clearly were written using AI by people who did not actually spend the time understanding what was made, and it most certainly was not an experience that I would classify as "good enough". I know this may be some kind of reverse survivorship bias and that I simply do not notice all of the slop around me that somehow is truly "good enough", but I think I need to see some concrete examples to convince me. | | |
| ▲ | brabel 14 hours ago | parent | next [-] | | > I have interacted with multiple apps that clearly were written using AI by people who did not actually spend the time understanding what was made… That kind of proves the opposite point: you’re using those apps so they were good enough for the people who made it to get to you who would probably never even be able go write an app. Also are you comparing the apps to your average, bug ridden app written before LLMs existed? Maybe they’re not that much worse. | | | |
| ▲ | ozim 14 hours ago | parent | prev [-] | | Do you care about each and every single app you encounter? Maybe you use your 2-10 apps and that’s it? Do you even let’s say — for the excercise sake — use those apps fully, each and every screen? I use dozens of apps, most of functionality from the ones I need is a single flow or function. I don’t care about setting my avatars or filling „user details” unless it is a delivery app or a shop. Most frameworks have boilerplate for that but there are dozens of such screens that don’t have boilerplate yet those are nice to have even if not used by 90% of users. |
|
|
|
| ▲ | kimjune01 13 hours ago | parent | prev | next [-] |
| actor paradigm is huge for clamping down on agents |
|
| ▲ | bigstrat2003 13 hours ago | parent | prev | next [-] |
| You should care about programming languages because humans are still better at programming than an LLM (yes, even better than $currrent_newest_model). And if you care about what you are making, you should be writing the code yourself. If you don't care about making something good, then yeah you don't need to actually learn how to program, but that's no way to work. |
|
| ▲ | imtringued 11 hours ago | parent | prev | next [-] |
| My big problem is that nobody is working on truly innovative programming languages anymore. Everyone wants to build another iteration of a C style language with incremental improvement for little benefit. The problem is that we probably reached the general purpose frontier a long time ago and there are just a few surface level things that need to be changed here and there, which is not worth a whole new language. It goes against the programmer's ego, but the way forward is by adding more restrictions. The people complaining about the borrow checker in Rust just don't get it. If you want programming to improve, you will have to give up the ability to write every conceivable program. |
| |
| ▲ | yuye 10 hours ago | parent [-] | | >My big problem is that nobody is working on truly innovative programming languages anymore. How many languages are truly innovative? I'd say the most recent example is Rust, as you mentioned, being innovative with its borrow checker, but what other recent languages really are? Many modern languages are not innovative, but just add quality of life features. A good example is Kotlin: Just another JVM language, nothing revolutionary, but I enjoy writing it over Java. >It goes against the programmer's ego, but the way forward is by adding more restrictions. The people complaining about the borrow checker in Rust just don't get it. If you want programming to improve, you will have to give up the ability to write every conceivable program. I agree and also disagree. The "ability to write every conceivable program" also means writing programs that are faulty. Maybe that's your point, in which case I don't consider it a bad thing to limit the ability to do so. A language like C let's you fuck around and find out. It's powerful and "easy". As the saying goes, it gives you a gun and doesn't stop you from shooting yourself in the foot. |
|
|
| ▲ | cubefox 12 hours ago | parent | prev | next [-] |
| > In the AI age, understanding these concepts becomes more important, not less—they are what separate those who merely prompt from those who truly engineer. But doesn't that sound like cope? It's like an old ASM programmer telling himself that his obscure assembly knowledge will surely still give him great advantages as he is forced to switch to React.js development. |
| |
| ▲ | yuye 10 hours ago | parent [-] | | >It's like an old ASM programmer telling himself that his obscure assembly knowledge will surely still give him great advantages as he is forced to switch to React.js development. The engineers that are truly skilled in writing pure assembly wouldn't be forced to switch to React. The existence of higher level languages doesn't mean lower level languages are useless. | | |
| ▲ | cubefox 10 hours ago | parent [-] | | I'm pretty sure that nowadays much less assembly is written than a few decades ago. Even video games used to be written in assembly. So the demand for assembly programmers went down, and the skill became less useful, unless the supply went down by the same amount. | | |
| ▲ | yuye 8 hours ago | parent [-] | | You're right, but that doesn't mean those assembly programmers are suddenly forced to write React. Being an expert at assembly probably means you're an expert in low level programming. We still have a need for those people, because they'll probably also be able to write C/C++/Rust/Zig/etc very competently. I consider myself pretty competent in C(And C++ to some degree), and I have a pretty good understanding of how computers work on a lower level, but if you ask me to write React UI components, I probably wouldn't fare well. I understand Javascript/Typescript, sure, but I'm just not familiar with the best practices of modern day frontend engineering. | | |
| ▲ | cubefox 8 hours ago | parent [-] | | That's the thing with LLMs though. Assembly developers can switch to Rust or something like that. But LLMs probably write C or Go approximately as competently as they write Javascript. There is no commonly used language one could switch to which isn't automated yet. | | |
| ▲ | yuye 8 hours ago | parent [-] | | That I disagree with, though. First of all, Go is a garbage collected language, so can't be compared to C. C is a language that is able to target basically every platform under the sun. It's versatile: User-space applications, kernel modules, and embedded firmware applications with an RTOS or even running on bare metal. LLMs can produce basic C code, but (still) struggle with more specialized tasks. They can be incredibly useful for skimming through long datasheet PDFs, but it's still up to the engineer to actually make sure the code it produces is actually good. | | |
| ▲ | cubefox 5 hours ago | parent [-] | | > LLMs can produce basic C code, but (still) struggle with more specialized tasks. And for how many more months will this state last? | | |
|
|
|
|
|
|
|
| ▲ | jthomastelles 6 hours ago | parent | prev [-] |
| [dead] |
