To be fair, a CEO of Nvidia would be telling those things even if he didn't believe them at all. Funnily enough, the question on the first screen is never answered.

heh, good point. As I watched this I thought of Bret Victor's talk https://www.youtube.com/watch?v=agOdP2Bmieg which also presents the idea that it's our job to create radically accessible programming tools. But I found myself disagreeing somewhat with the opinion that AI is The Answer.

"Upskilling" also known as purchasing more Nvidia GPUs.

Alternate translation: renting access to LLMs trained on Nvidia GPUs

there is something not right about these forecasts. I understand programming will look very different in the future, however, I don't think it will just human language. If human language (as in English arabic .. etc) is enough, why do we have mathematical symbols? There will be significantly less boilerplate code and anything that's just repetitive. But we still need logic and abstractions and ways to manipulate them

That's because "this neat trick will let you be productive while having to learn exactly nothing" sells well. :) Of course, I'm not trying to detract from all the amazing achievements. But we're not there yet. And I don't think "there" will come all that soon. And once we are there, we'll have a host of new problems to deal with for which AI will not be suitable by its nature.

I agree, Aziz--Bret Victor talks about this too, in a sense (e.g. in Inventing on Principle he talks about a new kind of UI for designing circuits--an alternative abstraction to cirtuit diagrams). It's also important that we can manipulate them quickly and intuitively, and even with a really smart AI that could "do it for us" the process would still be really clunky. In Bret's framing, you could say that what we need is not (only) tools that are more human-like, but tools that are more humane.

Something Primeagen said in one of his rants is that AI seems like it can do image generation or video generation well enough because our eyes and visual processing are charitable. We overlook and fill-in a lot of stuff during seeing. If you generate an image that gets 99% correct, that might be good enough. However, a program is either correct or not. It's mostly 1/0. A program which gets everything correct (and even passes the compiler) but has one simple bug isn't correct and might cost money. This seems to me a decent enough take.

> a program is either correct or not. I guess this is an advantage for using AI though since you can immediately tell the AI it got it wrong and it can try again. Helps with iteration. Which means software development becomes more like an evolutionary algorithm where you are deleting solutions which don't satisfy the fitness requirement.

There is also this idea of the "https://en.wikipedia.org/wiki/Lindy_effect" which may apply. Since people have been programming computers by plugging symbols into them for many decades, it's likely at least some people will still be doing that for more decades. Maybe it's not an either-or but a "why not both?" and we will have both people plugging symbols into computers and also people talking english to produce programs, and there will be different tradeoffs associated with doing both of those things.

Since LISP and s-exps have been around longer than most (1958?) maybe they are particularly "lindy". 😁

I believe programming is mostly about getting concepts clear, and is thus irreplaceable. "Boilerplate" is part of that, in the same sense as explaining something follows established patterns ("Introduction", "Summary", bullet points). These patterns can be pre-filled, but their raison d'être is to be part of the overall reasoning, which has eventually to be articulated in code. As @U02Q6L92FEJ says, there are reasons for the existence of logical symbolism. AI and any kind of automation will only work with tasks which are conceptually clear, and where pre-built solutions are usually sufficient.

Grace Hopper changed computing forever when she developed the idea of programming “languages”, something separate than machine specific instructions. To sufficiently describe a problem and desired outcome is to create an adhoc programming language

Saying that AI will replace programming is to say that there is no need to be specific in both problem and desired outcome

That! Which explains, on the other side, why AI is good business for the mass market. - And thank you for pointing to Grace Hopper, I didn't know that there was an actual historical "move" towards promoting the idea of programming languages.

In the same vein as some other comments in the thread, IMHO there are many aspects to writing programs. One is the automation aspect, to make a computer do something. Another is to write down a process in detail, to our future selves, and to other people, so we can reason about it while we grow it through evolution, as a tool for thought. For this later aspect, using languages like English is pretty inefficient. There are probably many other aspects like an artistic one. What I think is nice about the current approach is that by writing a program as we do today we cover both the automation and documentation aspects with the source code. I can see how AI can replace the "make a computer do something" as a black box, by creating computer instructions and tests for the things we care about. I think this can be expressed in English to a certain extent, unless you want to be expressing a lot of details, where English is inefficient. But I don't see how we can completely leave behind more formal languages (programming languages) for spoken ones, since they are not only related to computers but to our way of understanding. Maybe in the future new languages are created just for this purpose, to have a more efficient and formal way for humans to talk about processes but that don't deal with anything computer related.

But I don't see how we can completely leave behind more formal languages (programming languages) for spoken ones, since they are not only related to computers but to our way of understanding. Maybe in the future new languages are created just for this purpose, to have a more efficient and formal way for humans to talk about processes but that don't deal with anything computer related.Reminds me of a quip I read somewhere in SICP. That we are really at the very beginning of expressing how to do stuff with information and we don't know where this goes.

It's amazing how history repeats itself. I remember somebody saying almost the same thing about COBOL - like, "it's a programming language that's closer to English, so everybody is now a programmer"

@U02Q6L92FEJ I agree with you in the sense that we should be moving to have less boilerplate and repetitive things but what I am seeing with this AI trend is the opposite: AI writing the boilerplate for you.

The L in LISP stands for Lindy :thinking_face:

@U3Y18N0UC I think our definition of what boilerplate will change. For example, CRUD apis is a sense a boilerplate. Anything we can see clearly where it starts and ends will be and should be automated.

Pour some (syntax) sugar on me?

I actually played with the above def. Got ArityException due to wrong number of arguments to some. You may want to use ->> instead of -> and do something to partially apply identity to some.

@U06BDSLBVC6 - what version of Clojure? Mine works.

user=> (def leppard (-> some identity))
#'user/leppard

@UE1N3HAJH - bang on 😄

@U06BDSLBVC6 - you are right in that you can’t really apply the leppard

@U8VE0UBBR I use Clojure 1.11.1. I can compile the function, but when trying to run it, I get the exception, about which I reported above.

All seems fine to me:

(def leppard (-> some identity))

(leppard string? ["Step inside" "Walk this way" "You and me babe" "Hey hey"])
;; => true

When reproducing the way you invoked the function, it works. Turns out I did not understand that I have to provide my own predicate.

Reported for being on-topic

Due to the global move from PulseAudio to PipeWire, I now need to rewrite my audio widget for Awesome WM. So I need to deal with C and Lua. It. Is. Miserable. And infuriating. So infuriating. So much dumb shit is going on. Flags are integers and the same value can store semantically different tags. "How come NEW got changed? What is NEW? Oh, it's an event with ID 0, but I need to check the device type enum where SINK has ID 0 as well." Lua C API is stack-based. Good luck remembering that you put a table in there and that it's at a very specific index. The things that I need to do are so, so simple. Just call a few functions and provide a few callbacks - that is it. It is now the second day that I am busy with this bullshit.

@U2FRKM4TW You are reporting this because Clojure rules?

Yeah. I am cursed to feel the contrast. :)

to be fair, that is kinda how TypeScript was "sold" to the masses/companies

”Python developer… but fluent in Rust” 😋

As different as the American and British dialects of English? How does the colourful difference among TypeScript and JavaScript differ from the colorful difference among Python-with-type-hints and Python-without-type-hints?

I think over time TS has become a larger and larger superset of functionalities over vanilla JS, I'd bet if you removed all type definitions from a given TS file, it'll brick--as opposed to "just working without the assurances given by strict typing"

The problem is that the mindset is different. There are a lot of type-based development in TS, and some "types as first class citizens" libraries, to the point that it's basically a different language already.

As an example, it's common in TS to create interfaces and then classes that implement said interfaces, and then create a "mocked" version of the class to test stuff; in JS, interfaces don't even exist...

So a better analogy than Python type hinting would be looking for a C developer and then in the interview asking him "hmmm, by the way, how fluent are you in C++?"

Yes, like you're interviewing for C and then ask the person to make something using C++ templates 😄

It’s an interesting view on the human psyche to see how the pull of types is so absolute. Our kind really, really likes the idea of control.

Reading JFR output with JMC gives you way more data and insights than with VisualVM

#C05006WDW or #C06B40HMY if you're looking to hire someone.