Go, and that is sort of 10 years old at this point. Languages last longer than you think.

Fortran, which dates from the late 50s, is still very much alive and still very

much used by a lot of people, as is COBOL.

Algol lives on in its derivatives; Basic lives on its derivatives. So all these

languages never die, but then there are brand new languages that come along. I

think that of languages that anybody might have heard of that I use today,

yeah, Go would probably be the newest. I have experimented with other languages

briefly, mostly to try and understand them just enough that I can say

something in class. Rust is newer than C [Go] but not enormously so, so I've done that.

Scala -- I don't even remember the dates but it's, call it contemporaneous

with Go. I've done one program in that, one in Lua. I -- newer languages like

Kotlin, no, I've never tried. Sorry, I'm a late follower, not an early adopter.

>> Sean: Any functional stuff? I've seen your views on functional before but it'd be interesting to capture.

>> BWK: Yeah. Functional languages are really really important, I think,

because what they are - have proven to be - is a proving ground for ideas in

programming. So a lot of the things that we take for granted in modern languages --

mainstream languages, mainstream compiled languages like, let's say, C++ or Java or

Go, whatever. Many of the good ideas, the new ideas in those, came from functional

languages. For example, recursion originally is a Lisp idea and it shows

up everywhere. Functions as first-class citizens, pattern matching kinds of things --

all of these show up in functional languages and then move into the

mainstream in some way. I have never gotten over the hurdle of really

internalizing a functional language well. I have tried Haskell. It was a desperate,

desperately bad time. It took me two weeks to write a program that took me

probably an hour to write in Lua, another language I had never tried in my life. I

am not cut out; there's something wrong between my brain and Haskell. I can't

do it. But that's not to say that Haskell is a bad idea; it has many neat ideas and

it undoubtedly is providing something that will help people in the future in

programming. But I think mainstream use is probably always going to be dominated

by the more conventional compiled, imperative sorts of languages. >> Sean: The chap

who asked the question about newest language goes on to say what would you

like to see created, which I think is a tricky thing but, you know, what would you

take the best of from, and is there a way to answer that? >> BWK: I think the way I

would answer it is to say that in many cases the way we make progress in all

of these language-related things is when we get to the stage where what we're

trying to say is so mechanical you can almost say it mechanically. And once you

get to that stage and we say, well let's mechanize it so we'll add something

whether it's a language or a library or something like that, so that a whole

class of things that used to require us to do it over and over again have now

become something where you have a specification, or a very simple language,

and the language is taking care of a lot of it. That has the advantage you

understand it better. It's much more likely to be right if a computer is

doing it for you. And it's probably easier to teach it to other people as

well. And sometimes those languages are declarative, sometimes they're procedural,

but fundamentally I think that's the way we make progress: we understand more of

it what it is we want to do and how to express how to do that, and then we put

that into a program; we mechanize it. >> Sean: John Read asks: "If you could start from

scratch today and build a new processor architecture and operating system with what

we know today, where would you begin and what would it look like?" >> BWK: I would begin by

getting somebody who actually knows what that's all about. Sorry. I mean, it's true;

it's not my thing, I'm no expert. >> Sean: it's fair answer and he goes on to ask a

second question: "Will block-based drag-and-drop programming like Scratch

eventually replace traditional text-based programming?" >> BWK: That I at least

have opinions on. I think the answer is 'no'. I played briefly with Scratch or

at least a derivative. There was a program or a system that Google

provided called App Inventor. The idea was that it was basically

Scratch but with primitives that made it possible to build Android apps very

easily. And my experience with it was that for anything that fit within the

model for which they had provided the blocks [it] was perfectly fine but very, very,

very clunky. I tried to build something that would navigate around a building,

for example, and doing a distance computation with blocks was just -- you had

this much block to say give me the square root of x squared plus y squared.

It was hopeless. So I think using languages like Scratch as they were

constituted when I did this -- this was a while ago, so maybe it's moved on -- but I

think the problem with them is it's trying to ... sort of like trying to get to

the moon by climbing a tree. You know, the first 10 or 20 feet is really good. Now

you're stuck!. Can't get anywhere. I think the same thing is true. Now that's

for me as a sort of professional programmer trying to do things. As a way

to introduce programming to kids -- absolutely great. There's amazing stuff that people

do with Scratch and languages like that. Could you do something that would use

the block space part as something that is a nice way to get started with aspects

of it, and then extend it in other ways? That's what I was trying to do when I

was playing with App Inventor and it just, it foundered on the technology there.

But I think something like that might be useful. So they have their place but it's

not gonna replace other languages. >> Sean: What do you think about -- this is such a wide

wide brief -- what do you think about the future of computer science? Will the

manipulating bits era become obsolete in a few years or basics will never change?

>> BWK: I think basics will always be there; in some sense we will always have to worry

about how much memory we have, how much processor time we have. We'll have to

worry about whether the programs are correct or not, whether they're safe and

secure or not, so all of that is going to be with us I think in perpetuity, and I

think and, as a nominally computer science educator, that's something that

we want to make sure those so that students in computer science courses,

let's say at university, should actually understand the basics at that point. They

should understand how the machines work, what the limitations and realities are

of making them do things. They should also understand

some of the theoretical limitations: some things are hard to compute intrinsically

and that's important and sometimes useful. So all of that kind of thing is

going to be there. So let's call that core computer science. And then there's

all the things that computer science gets applied to, and that's the place

where all the growth is in some sense. I used to say to students in one of my

classes for non-technical people, "I don't care what your major or field is; you'll

find a use for computing, unless maybe you're a religion major". And then I

realized this is nonsense -- religion majors do really, really interesting

analysis of texts written in ancient languages and they did the same kind of

authorship questions that showed up in more recent issues like the Federalist

Papers. All of these kinds of things. So I don't care what your field is; it has

computing in it, the more you know about that the better off you'll be able to do

things in your field. >> Sean: that's a fantastic answer. I'm gonna ask you on the silly

ones now. What is the proper way to pronounce caramel? Is it 'car-mel' or

'car-a-mel? >> BWK: I think it's a three syllable word, 'caramel', to me, but I think so.

I don't know now that you asked me. >> Sean: Not necessarily silly ones but very difficult

to answer in a concise way: "What are your favorite books or what are your top few

books?" This came up a couple of times. >> BWK: Yeah. When I think about what I read and

let's call it reading for pleasure as opposed to reading for work. I think what

I find myself reading mostly is either junky detective stories. One of the

wonderful things about spending time in England is charity shops. There are

charity shops everywhere in every town, no matter how big or small, and you can

go in there and buy for a pound a really really interesting junky detective story

that you hadn't read already. And then in the next town, having read it, you drop it

off at the charity shop and pick up a new one. So I read a lot of those kinds

of things, probably half to two-thirds by British authors and the rest by American

authors. So I read those. The other thing that I read, and probably this is

more at home, tends to be history of one sort or another.

The Princeton library has a great collection of history books and so I

find myself reading that. Reading things on the Second World War just before I

left. I'm carrying a copy of 'A Distant Mirror' which Barbara Tuchman wrote years

ago about the calamitous era of the 14th century and so on, which has a lot of

English and French and Crusades. So lots of these things -- that's, that's what

I read for fun as opposed to for work. I think I don't do very much reading of

technical books, other than occasionally I will buy a book on something like: "How

do you use React?", or "How do you program for Androids?", or I got one on OCaml

recently because in spite of saying I don't know anything about functional

languages, I figure I ought to learn something and unfortunately I'm not sure

I've opened it yet. So technical books, I know I don't read as much as I probably should.