Computational Conversations EP#6 | Which language should I speak with my computer?

Hello, I'm Conrad Wolfram.

And I'm John McLune.

And this week's Computational Conversation Podcast is on which language should I speak with my computer? If you are picking a language to speak to a computer without having learned one, which would it be? How human would it be? Like, can we just talk LLM speak and not in the computer's language at all? So I hope we're going to be banging our own drum for our own Wolfram language in this. But. But let's see. So I'm going to start, John, by asking, does anyone need to write code anymore, or can we just leave AIs to do all of that, to speak English or whatever your native human language is and just let them proceed?

Well, it depends what you mean by code, doesn't it? Because if you're speaking human language to the computer, that is code. This is what language is. We're encoding our thoughts into tokens that we share with each other that are decoded in your brain to share their similar thought. So we're already, if we're using in the LLM to ask the computer to do stuff, we're already coding. It's just we're coding in a very informal way, in a very sort of perhaps declarative way, where we're saying our intent, but not necessarily describing how to get there, which is the opposite of traditional languages, where we describe how to get there.

I don't know about you, but when I look at traditional code in whatever language, it doesn't look like what I normally speak. I mean, it's a very much. There's a lot of translation that's needed from what people would naturally utter and what the computer seems to accept. I mean, that's been the tradition, but potentially is not now, because you just type into a large language model and it will potentially write code in many, many different languages.

Yeah, but I think you've got to break down, what are the things that you're seeing that's different? Where do they come from? So one of the things you see in traditional code is formality. And actually we have formality in English as well. We have notions of punctuation, and we might apply them through voice, but the idea that sentence structures that should be roughly followed is a kind of formality.

Apostrophes as well.

Yeah. And just the idea that there's a subject, an object, and a verb, and these things are. We're just so used to them. We don't think about the fact that we have to formally say, who is the object? Of a sentence. Who's the subject of a sentence? Because we know our ending so well. It's just natural. But then there's a. So that's where all the kind of the brackets and notation comes from in computer languages is formality, just to be clear. But I think the other thing, and I think this is the bigger part of this story is you're describing to the computer how to do things. And that's the level at which you have to describe for the computer to make life easy for the computer by telling it how to do stuff. That's the thing that has been a journey for, well, whatever the hundred years of coding languages have been that we move gradually higher level and more declarative where we say what we want, but not having to provide all the details of how to get there.

And of course, aren't there a whole set of optimizations we're trying to put together, by the way, just on the apostrophes. I think I have been somewhat unsuccessful. I think one area where I thought I understood what to do was apostrophes and I don't think you did was for some of them anyway. Anyway, I've been trying to train you on this for many years, but this hasn't quite worked out. Still, I don't know.

Do you have you still slow down my writing. So I stop and think about.

It's an it's or whatever anyway, which is a. Basically a bug in the whole system. Aren't there a whole set of things we're trying to optimize between and over time with different technology, those optimizations potentially change. So one optimization seems to me to be, you know, there's a limit to what the computer was capable of doing. You had to make life easy for the computers. There's an optimization between the expense and power of computer time versus human time. So that's one that has moved a long time ago. There's another which you brought up, I think, which is how precise are we.

Being.

And what's the right way to write down the precision, in a sense. And this is by the way, of course, a big problem in law and separate issue, but related issue, I guess, computational law, where you're trying to write down in more precise than traditional human language, is a growing interesting area. Smart contracts, computational contracts we would call them.

You could argue even more. It's gone the same kind of direction that case law now allows us to assume higher level meaning to words because they've been argued out on previous occasions.

Certainly in the common law tradition. Yeah, so that's two of the optimizations. Then I think there's an optimization of sort of thinking style, I can put it that way. And in a sense you might take a problem and think about it in a multitude of different ways. And the question is, are you trying to have a mono paradigm language that basically forces you to write it down in a very fixed set of ways, so pretty much one way to write it for each problem, so to speak, or is it multiplying? We can write in a whole bunch of ways. They all have pluses and minuses, potentially. It means there's more vocabulary, it's bigger, et cetera. So these are all optimizations and there are more. Sure. We could mention there's also, by the way, just the intransigence of what humans have learned. I mean, you know, each generation tends to learn a particular language and the question is it's quite difficult to switch, et cetera. So LLMs are changing that optimization between all of us quite a bit. And. But I mean, back to my first question first, right. Do we ever need to explicitly write abstract code or work with it, or are we as LLMs develop, are we and other forms of AI, can we just dump it? We just say what we want and it works?

I don't think there's a straight answer. I think you have to say it depends on the situation because, you know, if we just take performance as an issue. You kind of alluded to the fact that computers have got faster, so performance matters less than it used to. But that's actually the lazy answer to it. There's actually a lot of work has gone into making performance better without you having to do the kind of guidance that a computer used to have to do. You used to have to write a machine code, you used to have to figure out exactly every operation the chip would do and think about whether this operation was faster than that. And then compilers came along and said, okay, you can write in a higher level and then we'll do some magic to figure out the low level code. And perhaps an analogy to case law, algorithms have come along and allowed us to now say, okay, we're going to use this algorithm rather than that one, without having to spell out the detail because it's a well established algorithm and allow us to work, you know, to direct the computer to do the fastest thing without having to get down in the details. And then there's work that we've done with things like super functions where we're automatically choosing the algorithm. So now you can, in many cases Say the task in a very declarative way. I want this solution and the computer can figure out which is the right algorithm and then having chosen the right algorithm can implement that in a way that's coded up and compiled down to machine code for the cpu. And all of these layers of abstraction, automating the things that we used to do by hand. So that's part of that.

There are many layers of automation. But the question, so you can argue, okay, so there might be a different abstraction, an abstraction that is less close to the computer in its own language. An abstraction that handles incompetence by the human or not. So even incompetence just, you know, I don't know, details of knowing how the machinery works to affect what you do better. Yeah, but still, given all of that, there is very abstract looking code. I mean, I would argue we can come back to this. But Wolfram language is less abstract looking and is higher level, has many positive facets and iteration, but it's still syntactic abstract code as opposed to, you know, English, which, Well, I mean, you can argue it's, I mean, you know, it's also an abstraction. Right? I mean, let's just, let's be clear about this human language, you know, I mean, certainly the written human language is a high abstraction. I mean it, you know, started off presumably, you know, started off hieroglyphs and things, pictures, hieroglyphs, and then it turned into the idea of, you know, actually it's not just a picture. We're going to form this into an abstraction of let's say a 26 letter Alphabet which has the concept of words and sentences and paragraphs and so forth. So actually there are many, many layers of abstraction. You can argue that that has given humans huge power in describing what they want to do because we have an abstract way of writing it down. So actually the abstraction has been part of the power of communication and of idea generation, even in a human level. But we've got a different level of that, different type of that for writing down code still for computers, at least up until LLMs.

So one way I take that as the LLM is taking our kind of super function idea. And it's the super level, it's one level further up that in Wolfram language, if I want the numerical integral of some expression, I say N integrate. And I don't care whether it, I don't say it's to be the Runge Kutta method or that's not the right one, but one of the dozen or so numerical integration Methods, we just say the task. In the LLM world, you could say, well, I want the area under the curve and that mapping to what's the kind of conceptual mathematics happens? So we've just moved up a level. So one of the questions then you have to ask is, do you ever need to go down the level that it's easier, it requires less training on my part, and therefore is easier. And it also can be lazier, therefore easier of just being able to say, I want this, and have as much automation done as possible. And that's the general direction of travel. But even within Wolfram language, there are times where we say, actually, I want to use a trapezoid method with the following step size and the following extrapolation method on top and give all of those details. So the question is, does the human have anything to contribute to the process? In which case you need to get below the abstraction? And LLMs can actually be a problem because the fuzziness of human language can make it hard to say, I want to use this algorithm, but I want this detail changed. And it becomes very hard to express that in English.

Yeah, I mean, my argument, you do want abstraction. Abstraction is a huge powerhouse for humankind in different areas. Mathematics has been a. A key abstraction system essentially for problem solving now, which is sort of metamorphosized in this broader computational area. And there's a power to the idea of abstraction because it does several things. I think it takes apparently a multitude of different contexts and it turns it into a single representation which then has, you know, you're kind of channeling all these different things into something where you've worked out how to make progress with that thing, and that thing is well specified. So you're doing two things. You're defining the problem better potentially, and you're taking multiple contexts into one type of problem, which allows you then to kind of put those through the channel of mass solutioning, if I can put it that way, and come out with an answer that has more precision and essentially more power behind it, potentially. So I guess. I guess I'm a big believer that abstraction really matters. And if one believes that explicit abstraction will be important, if one believes that, then I think one's into a question of, okay, but has it shifted as to when you need it? Are there cases where you don't need it now explicitly, but where you did need in the past, and how has that shift happened? What's happened? Has LLM technology changed that optimization effectively?

I think one of the challenges is having consistency as you go up and down this abstraction spectrum that. Yeah. And as you know, we've spent lots of time worrying about this within the language of when you can use automation without locking people into automation. And I fear that the LLMs, while they continue this fabulous journey towards higher levels, interaction with less knowledge requirements, less precision requirements on the user, they don't go down a level if you need to get more precise. And this is why we invented mathematics. We stopped talking about maths in words hundreds of years ago because it just wasn't formal enough. It was too verbose for detail. It was very un verbose compared to mathematics at a high level. But when you start getting into detail, it becomes more verbose than the maths. And I think this is the challenge for LLMs as a programming level is on the one hand you can treat them like a compiler. I say something at a high level and then it makes code at a lower level, which I can then interact with or experiment with. That's great. It can work for the high abstraction of I don't really know what I'm doing, but I know what I want to ask for. That's great. But it doesn't go very well in terms of staying within natural language when you want to get more precise. And so I'm not seeing it as being a replacement. It's just a kind of another user interface for me for interacting with something that ultimately will be a formal code. Now, even within formal code, there's a lot to be said about levels of abstraction. And as an observation, for example, when I use LLMs to write Wolfram language code, they're pretty good at it. The fact that we've got high level, high vocabulary language means you can do quite a lot with an LLM generated piece of Wolfram language code. But you do notice that they're influenced by traditional programming styles. So when you ask an LLM to write Wolfram language code, it has a tendency to write rather low level Wolfram language code, lower level than you would as an idiomatic expert programmer. So as an example, if you're working with data, it has a tendency to say, oh, we're going to solve this problem by looking at each element of data one at a time and doing something with it and building up a new thing one element at a time. As a Wolfram language person who's been doing this for a long time, I don't think like that at all. That's a last resort to this art.

But is that just because it's been trained poorly so far? Well, I don't see why that should be indigenous to what it does going forwards.

Yeah, yeah, that's true, that's true. It's because it's being influenced by lots of older fashioned languages that that's the only way they work. And our way of thinking of saying we've got a piece of data, operate on the whole piece of data in one go and do something with the big piece of data, as our way of thinking hasn't got enough training information.

Let me paint a picture of what I think we're saying a little bit here, which is that we do still need in the center of this abstraction, whether you as a human needs to interact with that may change a bit. And who writes the initial cut of the abstraction may also change. So I mean, traditionally kind of the humans were the only game in town for writing the abstract code, more or less. I mean there have been in a sense languages and interfaces to languages which meant you could pull blocks around and do stuff, which is sort of a semi abstract thing, which seems simpler. But for any general purpose language, in the end you're into abstract code at one level or another. Now we can get general language pretty much written by LLMs. I think that is a change. It seems to me that means that in a lot of cases, certainly of the problem is it seems to me there are professional developers like we hire for example, to build Wolfram language. One of the things we've been trying to pioneer a lot over the years is people, people who want to work things out and you know, are quite technical people, but they've just never actually become professional coders. That's not what they do. They'd like to use code to write. And of course there are many of these people now in all walks of life. I mean, you know, if you, if you're a biologist, this is a problem because there's a lot of computational biology. You want to get your computer, you want to be able to code what you, your ideas about working something out about cells into the computer. And the question is how you do that. And you're not probably a professional developer because that's not your specialty. Your specialty is biology of cells or whatever it is. And so one of the things we've been trying to do right is have a language, an abstract language that's high enough level for people like that to have the sort of best shot of doing things quickly and efficiently and effectively. I think we've done a pretty good job of that. But LLMs add a whole different perspective perspective to that. So it seems to Me, we're going to have a lot of people, particularly in that sort of, you know, well, even professional developers, but, but certainly people who are just using coding to get a result in another subject. Just starting off by writing English, getting a first cut of code and then maybe interacting with the code. And I think you don't have to get that complex before you actually need the abstract code. Certainly not at this point.

Well, I think one interesting thing that questionnaire poses for computer science education. Well, actually, no, I don't want to call it computer science education, but education on how to use computers, particularly for people like, say, biologists, who is not a core of what they want to do, is it shifts the balance between read and write. So up until very recently, if you wanted to use a programming language, the focus was can I write code? And you get a lot of people who can write code that is unreadable, but it works and it gets the result they want and then they move on. And you need to do a computer science training to be taught how to write nice readable code. For other people with LLMs, it reverses it. Because if you're going to say, I want to model my foxes and rabbits problem and here's the system I'm trying to describe and it writes some piece of code for you, your now contribution is you've got to be able to read that code enough to say, did it get what I meant? Or has it solved a slightly different problem? I've actually got to spend most of my time reading the code and fixing it rather than writing it in the first place. And I use this professionally now as well on languages that I'm not so proficient in, like when I'm writing SQL or JavaScript for a short snippet that can be written in 10 or 15 lines, I'll go to the LLM first and say, just write me this code and then I'll read and go, oh no, it's got it wrong, it's done, it's misunderstood me there, but I can see what bit to edit and it's just quicker than writing the whole thing by hand from scratch. Now, I wouldn't go there for a big architecting of a system, but that's because the LLMs aren't good enough for that yet. They don't have that kind of big picture and making sure that it's well commented and in a way that I understand. I'll often edit the code afterwards. But yeah, for those, but also about.

Learning, learning a new language, surely LLMs are incredibly helpful for that whether you're professional or less professional. I mean, you know, because you. I mean I would just start by typing what I wanted for some simple thing and seeing what came out. I mean I can read documentation, but this seems like. Or watch tutorial but this seems like kind of more. More directly at it. Which opens a very interesting question. So suppose you are going to always start for your level of need with English to write the first cut of code and indeed you're freshly going to start because you're not really a coder at all and you're going to start learning coding for the first time. It changes seems to me the optimization of the language you might use because if the LLM's writing the first cut of the code, what you then want is a very high level language that's easy to understand as a human and does a lot, but is fully precise.

Yes, readability becomes more important if you're going to be in a read first way of interacting with code and also.

Not only readability but multi paradigm ability. So what I mean by that is you want the ideas as directly written down as possible so that they're readable and so that they can attune to your own way of thinking about it as much.

Well, what you're really saying is the highest level possible of which having multiple paradigms for approach makes it more likely you can fit a high level descriptor without having to resort to lots of mashing.

But let's ask the question why hasn't everybody wanted that all the time anyway without LLMs? And it seems to me, I mean if I look at Wolfram language compared to low level things like R for example, given we're talking about biologists and.

Things.

It seems like there are a number of reasons why not. One of them is we have a very big vocab. If we were a human language it would be called vocab. So we have, I don't know, six and a half thousand built in functions at this point. So that feels like almost learning a human language. It's like oh my gosh, if you can't learn all these functions then somehow you can't use it. Just like you can't learn lots of words. There's a certain number of words you've got to learn in English. We can speak English. So that seems pretty daunting as an early.

Yeah, I think it's definitely daunting. Although I think a lot of people get the wrong idea about if I am learning the language I need to learn 6,000 things. There's still little corners of the Wolfram language I've never used because I've just never had the need to. There's a core which I know we failed to define in the past, but a core where you become productive, which is much, much smaller than that.

Right. And there's a lot of systematization. I mean, it's a bit like maybe learning Latin as opposed to English, right. Where, you know, it's been, well, systematized over the years. Maybe it was or wasn't exactly when the Romans were speaking it. I suspect it's been better systematized than it was then. But fundamentally there are certain declensions and certain ways that tenses work, which is sort of true. But in modern spoken languages they tend to get British English, I should say English is certainly pretty irregular, but so my. Yeah, but it does appear to be an energy barrier one has to get over more perhaps than lower level languages where there is a small number of things to learn initially. But of course, the other side of the small number of initial things is I always feel you've got to do mental gymnastics. Often. I mean, if you're very lucky in that the idea you've got fits neatly with the paradigm of that language, you're up and running. But usually it doesn't. So usually you've got to turn everything into the paradigm that it happens to be. And I want to come back.

I think that's why they seem easier. Because once if you use a really low level language and you're told that there's for loops and there's if statements, and then you're told when you get to a higher problem, oh yes, you solved that by building up layers of for loops and if statements, then you think, great, I know everything I need to know now, I just need to be good at doing it. And I think that's the opposite from us, where in the Wolfram language you'll be told, oh no, no, you shouldn't be writing all this low level code. There's a function for that. And they go, well, I didn't know that. So I feel like I haven't learned the language. So it's kind of a good thing. That feels like a bad thing. But the LLMs changed that because they have all the vocabulary and while they're not very idiomatic in Wolfram language for lack of training, they do actually know a good fraction of the Wolfram language in terms of knowing that there is a function for some high level operation that you might not have been aware of. So you know, from my point of view, LLMs are really good for Wolfram language adoption because you don't have to say, oh, I've got to do Python, because that's what I was taught when I was 16 and I was first taught to program. And you don't have to worry about this kind of big vocabulary problem because the LLM knows all of that and you can go straight to something that is then readable and usable, you know?

Yeah, I mean, switching us around even further, I mean, I don't understand why the hell you would get an LLM to produce a low level language at this point.

Well, there is still value in low level languages that sometimes, and where you can't be lazy and say computers are fast and have lots of memory these days, where you really need to be precise about making life easy for the computer at the expense of making life easy for the human, then there is value in low level stuff. And this is what our compiler project is about.

Yeah, I mean, so I mean even that, it doesn't necessarily mean you as a human, even when you want to interact at an abstract level for precision, necessarily are going to be able to make things faster for the computer because there's another potential layer in between, as you say, which is smart compilers, if I can put it that way.

But it's back to this. Can we move seamlessly up and down the scale of abstraction? If I need to say I'm going to help the computer by saying this variable will always be a real 64 and therefore it can do optimizations that otherwise it wouldn't be able to do. I'm doing work for the computer, but I'm still working at a relatively high level. I'm not down at the, it's, you know, the x86 operator number 742 that has to be applied to this, you know, that's all left.

No, correct. But, but, but I think there is a difference because I suppose another way of thinking about this is like when you take a photograph, whether you have lossless representation or whether you compress it and get losses. And so in terms of abstraction, I feel like, you know, in a sense there's a lossless move between a precise computer language and machine code. Effectively. I mean, you know, it's not. I'm not sure, do I believe what I'm saying here? Let me try this out anyway. There's a sort of lossless step there where it is precise. It is exactly what it is. You're saying the thing between human language and abstract Code, maths, whatever it is, is lossy, right? There's, there's a bunch of muddle in between there as to what you actually meant. There's a lack of precision. It's a bit like, well, it's.

I would produce ambiguity. There is more to take the words you've said to mean two different things than there is as you get more formal and more.

Well, well, or programming language, not even necessarily just that it might be they're just not sufficiently defined. You just haven't defined it sufficiently. I mean, part of what I think one's doing writing code, or indeed maths, is forcing one to be more specific about what one really is saying. I think that's one of the great powers of having people learn abstraction. I mean, call it coding, call it programming, call it computer science. I think one of the great things is precision in thinking, which one's not forced into necessarily with human language. So that's my loss. I don't know whether I agree with this, but the lossy versus lossless sort of abstraction. I mean, as you say, you can argue that language itself is an abstraction, human language, so to speak, is an abstraction anyway, but it's a sort of lossy abstraction, maybe, or you can say it's precise to what you were thinking, but what you're thinking isn't terribly precise. And at some point it needs to get precision to get a real good answer, I suppose. But so back to the types of languages. So I mean, I argue strongly that for most cases, for most people who want to use a computer, get problems solved now, the optimization is go to the highest level language that is precise and that you can then also interact with yourself and most directly correlates with the way you would want to think about the problem. Hopefully that language will be efficient at getting that to work on the computer. Now, there may be cases where you really, really need the ultimate speed of the computer. But I think as you start off right at the beginning, of course there are cases like that. And I think your argument would be that computer speed, I mean computer speed matters because we've made problems much harder. But it's still at the margin there, there's a smaller fraction of things, I mean, there's a smaller fraction of times where your computer's power is limiting thing of the generality of things you do with your computer than there was 20 years ago. Of course, we've massively stepped up what we do, so that's changed it back, but still net, there's a sort of reduction in the fraction of cases where the computer speed is the limiting thing.

I'm going to give you a slightly different angle on this I think, which is that you're looking at it from a person, what language should they choose, but actually another way of looking around this is what people are suitable for, what languages? And you know, I. You said earlier that you know, kind of dismissed graphical programming is not really programming. It is, it's still dragging blocks around and wiring them is a way of expressing yourself to the computer. I see it as programming and in that sense even things like point and click, GUI interfaces with pop up menus and buttons to click is a way you're expressing yourself through mouse clicks to a computer. And we've always had this kind of strong line between programmers who had an open ended way of expressing themselves to the computer and users who had a expressly defined interface, buttons and sliders and input fields that gave them no real flexibility. But it was the only way they could use the computer because they couldn't program. And I think one of the things that the whole large language model has opened up with its code synthesis and it's kind of with rack based control of algorithms, this middle ground where now you can give consumers, users more open ended access to systems than GUI point and click and menus could ever give them, but without having to make them learn the skills to make life easy for the computer of some formal language. And it's the formality because mostly what kills people I think when they learn to program is you get very frustrated when your brackets don't match and the computer goes nah, not doing that. And it's very dispiriting when you're learning to code especially.

There's also this interesting facet of how you end up. So there's the feedback effect, how you end up thinking based on the language you're using. I'm quite interested. I mean there's always the amusing thing in English that the practical words tend to come from German and the emotional words tend to come from French. And that has a feedback loop I think in those societies arguably. Right. I mean, you know, certainly the Persona of them is that.

And there's also kind of more precise languages. I got somebody I think from the Czech Republic complaining about my blog. I wrote doing analysis of synonym networks within English and saying in Czech there is only one meaning for each word. Your English is crazy. And it's like, well that's part of the poetry of our humor is very much based on puns and multiple meanings for words. Yeah, that's correct. There's all kinds of things that change the way you think about stuff, depending on the flexibility, the formality of your language.

Yeah, and I'm interested in these positive feedback effects. So I think to some extent, if you're thinking, I mean, look, I don't know, being finally educated in top British schools, I only speak one human language, so years of being drilled in French did basically nothing for me whatsoever. So I am ignorant.

Your Latin's still better than mine.

My Latin might be slightly better, but even in England that doesn't get spoken that often these days. So, I mean, I'm not really one to comment on people who are fluent in multiple languages, but I know, I've heard from many of them, you tend to think a bit differently because of the language you're using. And so another interesting question is for computer languages, which way we want people to learn to think first, to give them the best shot at, so to speak, the best thinking, if there is such a thing. And what different languages force in each case. We've often observed over the many years of Wolfram language that we can sometimes spot which languages people have come from into Wolfram language. But the reason for that is, just to be clear about that, we've always been massively multi parallel. We have virtually every imaginable language structure within Wolfram language, syntactically put together, but different in terms of what you can do. So when you get somebody who's come from, say in the olden days, Fortran, where most things are loops, it's very telling because they start writing Wolfram language and they'll immediately write everything as a loop because they basically turn. That's their brain has been set into loops, more or less.

The two main things I see are people who think low level operations first loops and conditions, and they're constantly slicing through things a bit at a time. But the other one which is, and I don't know if we have time to start a new strand of conversation here is the languages that have kind of imposed discipline, informality, where you have to declare types up front, which, you know, on the one hand is a barrier to getting things done and is a barrier to automation, but also can have positive effects to ensure that you've thought things through before you start.

And it's your definitional thing again.

Yes, exactly. It's, you know, all the sort of, I find a complete pain to write a code does make you stop and think like, you know, people who would argue that automatic cameras have made it easier for you to wave around and take Snapshots and the old setting the thing up on a tripod and getting the lighting right made you really think about the composition of the picture. There is some value in that, in those statements, particularly if you're really trying to write high production code and high robustness code. But I think perhaps we've gone on long enough that we shouldn't go down that alley.

Well, I also think that there's some fallacy to that, because people get used to a procedure that they follow, and sometimes when the procedure is stripped away, they don't replace it by an alternative procedure, even if more productive. I mean, look, I remember my father, I think, saying that he needed a typewriter early on in computers because he kind of got used to the pressure of typewriters for actually writing anything, which seemed like bullshit to me, but it was kind of like, you can see it a little bit. That's sort of what you're saying now. It's no good if you just literally composing a photograph. You just, you just say, I'll snap around, I won't think about it first. That doesn't work. I think for taking good photographs, might work for other purposes of photographs, but I don't think you need to set it up on a tripod and twiddle all the knobs to make it manual first. I think there are other things you can go through which are more efficient to make that happen. And I think it's the same with these languages.

Well, as I always tell people with wolf languages that, you know, we have a language that doesn't impose that kind of discipline on you. If you want to write good code, you have to impose the discipline on yourself. Now, you know, being lectured by the language to make you do things that you should be doing is, you know, you could argue is a good thing, or maybe you just can do it if you just care about it. But, you know, I think, I think it's a little bit like an analogy of, you know, if you're writing some code, which is the best approach? Do you sit down and write flow diagrams and write data schemas and architect the whole system in a big document and then code it, or do you just start hacking? And depending on the project, either is the best approach because for very large scale things, you can't just make it up as you go along. But very often, effort of mapping out formality of what your project is going to be before you start is a complete waste of time. Because it's only when you write the first few pages of code you realize that you've misunderstood the problem and it's only by doing you learn what you really want and how things should really work. So I think the same is true of formality, that sometimes if you're trying to write really bulletproof code, a lot of formality is a good thing, but sometimes it actually obscures you getting on with stuff and discovering the real solution. So I wish I could give a good definition of when to go down each track, but I think there is a.

Let's also talk about what you should do first, right? If you're not really a coder at this point, a programmer, I don't know why I'm using the word coding programmer. What should you learn first? Now I've argued for a long time that a multi paradigm language is best first because as the reverse of the Fortran problem, right. You really, really don't want people to be channeled to one way of thinking at the beginning. You really want them to be presented with all of the options and have some idea of how you select between those for the best code for a given situation. Not turn everything into sort of do the mental gymnastics, turn everything into one style. So I have a pretty firm view that, and I would criticize quite a lot of computer science courses and things that try and teach lower level multi mono paradigm languages first. And I know some people are very keen on Wolfram language in teaching that early on because of this issue. I think it's easier to go from a multi paradigm language to. Well, easier I would say and also less constraining to the future to go from multi paradigm to mono paradigm than the other way around.

I don't know if it actually is easy to go back. On the one hand you've got the negative, which is if you get into bad habits because you've got a very forgiving language, it's difficult to make yourself have good habits for good code. But I think that's hard bit but well, you know, things like making sure you cover error cases, locking your code down so that if it gets unexpected arguments they fail early and fail strongly rather than limping on. It's very easy to write bad words.

Yeah, yeah, of course, but it is in most languages.

But the other thing is just the, it's actually quite difficult, I think to go down from a high level language to low level language because you feel socially frustrated. Every time I learn a new language, you know, I, I learned some new technology and it's like, oh, that's a neat feature. Well, that's why I'm Here, and then you learn how to actually do it. It's like, why do I have to enter this? Why, what do I. All these things I have to do that are making life easier for the computer.

Well, it's the it. I think things go higher level over time.

Yeah.

And it's funny how, by the way, people don't change as quickly as you'd think. You'd think in the modern. The modernity of computer languages and programming shifts would be rapid, but they're not because there's a lot of intransig, you know, there's a lot of intransigence built into it because of what people know. And learning a language is quite a lot of effort. And so traditionally, again, this may all change somewhat with LLMs. I think traditionally people have stuck with languages for rather a long time because that's what they know. There's a lot of code there, there are a lot of other people there, then everybody gets trained in the same language and apparently they can read it all, even if it's pretty, pretty low level. I mean, back in the day, FORTRAN persisted for ages and ages and ages. It was crazy, absolutely bonkers. And I think we're going to see a similar thing. Python has sort of gone to its peak, we'll see. And it's got a long way to go, so I guess we should probably wrap up soon. But I guess where we're sort of, you know, ending here somewhat is, you know, the language you speak with your computer, I think can and should change, and it's easier to change than it would have been in the past because of LLMs, at least up to some level. But we absolutely do need abstract computer languages because you can't get the precision that you would otherwise have. And I don't see that really changing. It will be adjusted, I think, initial write. Often it will be much more editing than it will be sort of composition on a blank screen.

So many things simultaneously made it easier to flip between languages and to adapt to new languages and change the priorities of what languages need to focus on.

Yeah, indeed. So I guess, as I did try and summarize it, I wrote a book at some point with a heading, language Matters. And what matters has changed, I think, is probably. I believe that heading is still valid after this conversation, I guess.

Great.

Well, I hope you enjoyed this computational conversation and we look forward to seeing you again for the next one.

Goodbye.