Algorithms + Data Structures = Programs - Episode 154: Programming Languages Galore with Jonathan O'Connor
Episode Date: November 3, 2023In this episode, Conor and Bryce continue their conversation with Jonathan O’Connor and chat about a plethora of programming languages!Link to Episode 154 on WebsiteDiscuss this episode, leave a com...ment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachAbout the Guest:Jonathan O’Connor in 1988 joined Glockenspiel, a small Irish company. C++ had no virtual destructors, but it did have a coroutine library! I spent 2 years teaching C++ and OOP. In 2000, he switched over to Java. But by 2010, he started 7 wonderful years writing in Ruby. In 2016, he returned to a completely different C++, where one never had to see a pointer if you didn’t want to. These days he is helping to make the world a better place writing C++ code for LADE GmbH, a company building electric car charging infrastructure.Show NotesDate Recorded: 2023-10-18Date Released: 2023-11-03Jonathan O’Connor Meeting C++ BioAlgorithms + Data Structures = Programs BookPascal LanguageAda LanguageWhy Did C Succeed Over Pascal?Carbon GithubZig LanguageNim LanguageUiua LanguageEiffel LanguageBertrand MeyerRichard Feldman on TwitterSoftware Unscripted PodcastWhy Isn’t Functional Programming the Norm? – Richard FeldmanJames Gosling Keynote “Thoughts on language evolution” - reClojure 2022Clojure LanguageArrayCast Episode 41: John Earnest and Versions of kIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8
Transcript
Discussion (0)
We had a course in second year where we learned Ada and we wrote this, we had this big, huge class project.
And that was the only Ada, but there was no compiler at the time.
It was too early.
Wait, but when you say there's no compiler, do you mean you just didn't run the code?
No, you couldn't.
The compiler that we had access to in New York University did not actually produce machine code.
It just said this.
It was like the first stage of a compiler.
It had no backend.
It had no code generation.
Wow.
So you only knew that your code was syntactically
and I guess semantically correct.
Welcome to ADSP the podcast episode 154 recorded on October 18th, 2023. My name is Connor and today with my co-host Bryce, we continue part three of our four-part conversation with Jonathan O'Connor.
On today's episode, we continue our comparison of Pascal versus C versus Ada, and go on to talk about a plethora of other programming languages.
Zig, Nim, Carbon, Eiffel, WeWa, Clojure are all languages that get mentioned in this episode.
So I don't know that we bottomed out on talking about Ada.
Oh yeah, no, wait. So, I mean, we're hopping all over the place. I was, while you were explaining
the power of visualization in paper, because at one point we had, so we're even rewinding more
back from Ada. We'll get back to Ada in a sec. I was trying to figure out what the internet has to say of why C won out over Pascal. And so the summary, first of all, Pascal is actually older
than C. I did not know that. C, according to Wikipedia's first year of appearance was 1972,
and Pascal's was 1970. And the general opinion of the internet, there are many different hot takes,
but the most popular one is that Pascal
was designed to be a language for teaching
and C was designed to be a language
for doing systems programming and getting things done.
And what that meant is that as a teaching language,
C isn't great because you got many foot guns,
you can make many mistakes as a beginner,
but that's the kind of power you want when you're trying to write a system. Whereas Pascal did not have those foot guns, you can you can make many mistakes as a beginner. But that's the kind of power you want when you're trying to write a system. Whereas Pascal did not have those foot
guns, but it kind of made things more difficult. I mean, one of the the top things that came across
answers was that Pascal, I'm not sure if this changed with all future versions of Pascal,
but at one point, all of your code had to be in a single source file, which does sound pretty crazy.
I'm not sure if you recall, Jonathan, if that was the case when you were using Pascal.
That might have been the case,
but I would have thought you could just type,
you just say, you know, Pascal or whatever,
PC or whatever the thing was,
and the list of files, I guess,
to compile all of them into one group.
But maybe that's true,
because I think that was the big thing with ada um because ada uh started they had this notion
of packages that was one of their big selling points it was for large application development
um with large teams and you could you could have a package specification
and a package body.
So you had the split between declaration
and implementation.
And that was huge.
I mean, that's what we spent most of our time doing
was just writing package specifications rather than implementations
in that project that we did.
But yeah, you had the huge thing about packages
and packages could have, they were like namespaces.
They're similar to namespaces in in c++ except you can also uh i guess
no they're not my classes but you could you had functions procedures um and you could
have data inside them so you can have what's the difference between a function and a procedure in? A function has all input parameters
and it returns a value.
And procedures can have input and output.
And I don't think they have any,
no, they don't have any return value.
But yeah, you could, I mean,
from what I remember,
Ada didn't have object orientation built into it.
You had a package.
You could create a global variable inside the package that was private to the package,
and you could refer to things in that.
You could hand out these, what was called limited something or there um where you
you'd have they were just like handles um to something and and people outside the package
couldn't do anything with them except pass them around um and that way you could you could
you could set up stacks and whatever but um you know there was no kind of
you could there was no such thing as a class um which was interesting i also just looked up so
ada was created in 1980 so that's a decade roughly a decade after both uh pascal and c
and it says right in the first line on the Wikipedia page that it was primarily inspired
by Pascal but that uh it was I didn't actually know this it was it was a created by a guy at
Honeywell whose name I'm gonna mess up yeah what's his name Jean Jean Icbia yeah I think so
probably that's something else but but that's how i pronounce it as well
and it was uh i guess so french computer scientist honeywell famously an american company though
and they were contracted by the us dod department of defense to create this language ada
specifically to replace a whole bunch of languages that the DoD was using at the time.
And it also has this little byline, in strong typing we trust. So it's clearly this,
you know, government funded for government purposes language. That's one of the things that Ada has that C++ still doesn't. It had strong typedefs. So you could create my, you could say using my int equals int, say, and that would be,
you can't do arithmetic between ints and myints.
They're totally separate and they don't go together.
So that's something that we don't have in C++ still.
Interesting. So it's a type alias that does not interrupt with the underlying type.
Correct.
Correct.
Interesting.
And then I assume that Ada has some facility for casting or static casting.
There probably was, but you'd probably, yeah,
there must have been some way of casting to the underlying low-level integer.
And the other thing you could do, you just had integer and you had float.
But you could specify that your integer had to have a range from like 0 to 1 billion or something like that.
And the compiler would figure out how many bytes to use for its integer type.
And so that actually,
so that was one of the things
that I did know about Ada
is that it has bounded and fixed point.
So it has a richer type system
for your integer types that you might want.
And I was perusing through ADSP,
the Virth book,
looking at a couple of examples. And it looks like they actually had the same similar syntax for that kind of stuff.
Oh, maybe, maybe, yeah.
It had this type keyword, and it said type digit, and then 0.9.
So my guess is that is defining an integer type.
I could be wrong about that, but combining this with the fact that Ada was, you know, inspired by Pascal, I wouldn't be surprised if Pascal is another example of a
language that has, I'm not sure about the fixed point type, but the bounded integer types. And
speaking of Pascal, again, that was the other thing the internet said, is that C is not really
known to have killed Pascal. It was actually Java, Because what Pascal was good at, and it was what
the domain that it was successful in, was being taught in universities. It was a teaching language.
And so that's where it kind of thrived. And then when Java came out in the 1990s, and there was a
huge marketing blitz, a ton of universities switched from whatever language they were using,
you know, insert a language, and a lot of those might have been Pascal. And then Java became the one of the de facto teaching languages up until when I was in
university, you know, in 2008, the first, I think it was the second course, the first
course taught Python and the second course taught Java.
So interesting that, you know, C and Pascal, even though they were quote unquote contemporaries,
it's at least the internet doesn't
think that it was it wasn't the success of c that like killed pascal it was more that it was a great
teaching language but then uh that was surpassed by something else but i think i think i maybe see
also because it was used as the the system language for for all these unix systems. And those Unix systems started getting very popular
and it became a language that you'd write code on PCs.
So I think, yeah, just you could, as you said,
you could get things done with C.
And then you had Microsoft producing compiler.
Do they also have a Pascal compiler?
I mean, Turbo Pascal was the big thing in the late 80s, early 90s.
And that had a nice IDE.
It was very, very fast to compile and build.
So that was kind of really nice to use.
Yeah.
I mean, that was definitely something that came up in the answers
was that the fact that Unix was written in C
and it shipped with, I think, the C compiler,
not only did that have a huge impact on educational institutions
that were getting Unix computers,
but also a ton of folks
that were at Bell or other places that had experience with Unix when they went to go do
their own companies. It was a very easy choice to build their whatever, you know, hardware or
software they were building on top of Unix, which, you know, C becomes a very good option because
it's there. And it's if you're doing stuff that interops with the OS, yeah, interesting.
So that brings us back to Ada.
So Ada is this government-funded, you know, language designed for the government.
Military Standard 1858 is the official, the original thing.
M-I-L-S-T-D 1858.
It was a military standard for for the department of defense
in america and they chose 1858 which because i think that was ada lovelace's date of birth or
date of death um interesting so it's just a random four digit number it's not it's not like
it's not a random four digit number no no it isn't um or be like it's it's just a random four digit number it's not it's not like it's not a random
four digit number no no it isn't um or but like it's it's not a number that it was the next number
in like a sequence of you know paper numbers like for the iso i don't believe it i don't believe it
no don't believe it was interesting um and so did you do any ada programming when you were in school
or yeah for for we had a course in second year where we we learned ada and we wrote
this we we had this big huge class project and that was the only ada but there was no compiler
at the time it was too early that they there was this wait but when you say there's no compiler do
you mean you just didn't run the code no you couldn't the compiler that we had access to in new york university did not actually produce uh machine code it just said this it was like the first
stage of a compiler it had no back end there's no code generation uh wow so you could own you
only knew that your code was syntactically and I guess semantically correct.
So what causes a professor or a university to teach a course in a language that doesn't
have a full end-to-end working compiler?
I think it's probably an experiment.
I suspect it was an experiment.
That is like, I'm not sure.
Is that the equivalent of like a university?
I mean, I guess it was government funded.
So they knew that at some point there was going to be Ada jobs.
But I mean, it sounds like a university choosing Carbon as like,
we're going to teach and Carbon has an interpreter.
You can, you know, write some code in it. people who did computer science in the 1970s. You'll find a huge number of them have got their
PhD by creating a language to investigate some aspect of computer science. And so there were
hundreds, if not, yeah, definitely maybe even thousands of languages created in the 70s. And that kept on for another few years.
And then people stopped creating languages, I think.
And, you know, from the 90s, I think,
didn't have that many languages created.
There were a few big ones.
And now we seem to, after maybe like 10, 15 years
of no new languages, now suddenly we're getting a whole load of new languages like Zig and Nim,
as well as the C++ once carbonate.
Wewa? Wewa?
And Wewa, yes.
The funnest language to say.
I wonder if there's a graph.
I wonder what causes these.
I mean, clearly in the 70s software
engineering computer science it's it's a a burgeoning you know uh what do you call it
emerging field and there's a ton of research topics um but then what caused you know the 90s
to to be what did they call it a nad nadir, a trough, if you will. Probably people started trying to make money out of, you know, by writing applications that actual people wanted to use.
So it went from, you know, the laboratory or from academia to the real world.
Oh, I'm going to insult somebody there.
That's all right we're we love maybe i'll maybe i'll insert the uh was it the the hot take or
spicy take uh yeah k-pop song but but yeah i think i think that's what happened and you had
and so we had i mean there was turbo pascal there was there was c plus plus was getting big. There was Eiffel briefly.
I remember going to a conference in Germany, a one-day conference in Germany with – who was the guy who headed Eiffel, who created Eiffel?
A French guy.
Very clever man.
I feel like I would know the name.
I know it was the language of contracts.
Yes.
And it had a terrific book.
He had a terrific book.
It was...
Oh, yes.
Bertrand Meyer.
And poor old Bertrand, he absolutely, he found it so hard to have to accept that C++ was the more popular language.
He found that very hard to take because he just saw all the inadequacies of C++ where his language Eiffel was beautiful.
And it is a beautiful language.
And he had a lovely standard library.
He had all sorts of very clever ideas on data structures
and how they were, what was common about them.
And I thought, yeah, I thought it was excellent.
But yeah, E ifl was another language
that seems to have come and gone um yeah what is bjorn is uh i mean whether you disagree or agree
with uh his takes over time he has that one quote is there's uh two types of languages languages
that people complain about and languages that people don't use which i mean is uh it's a good one there's definitely
some truth in that uh yeah i mean there's there's so many like ada i know has got much bigger i mean
the i'm yeah this is the ada reference manual you can only it's it's like a centimeter thick
this part that the second half of this book. So it's only about 120 pages long or so.
And I noticed there I downloaded the C Sharp standard.
There was a link that was sent out that I get.
And I looked at it, it was 400 pages long.
And of course, C++ is 2,000 pages long, the standard.
Yeah, hold my beer.
So I think, yeah, the languages were much smaller then
and they are not anymore.
I think it's so, I mean, I love thinking about it.
I've watched a couple different
talks, Richard Feldman, a fellow podcaster now of software unscripted.
He has a really popular talk called why isn't functional programming the norm.
And that talk talks about like, what, what is it that actually makes a language popular
as successful?
And just recently I watched a talk from Jamesames gosling famously the creator of java
and he was talking at a online conference in 2022 called reclosure so it was a closure event and
for those of you that don't know closure is a a lisp that runs on the jvm so it's kind of in the
java family of languages similar to Scala and Kotlin. And he
was talking about at one point in the talk, you know, what is it that the same thing? What is it
that makes a language successful? And you know, how much of it is familiarity and trying to meet
developers, you know, where they're at, because there's a lot of great novel ideas that exist in
these kind of unique languages. But if it's, different or feels too foreign, people are repelled from it.
You know, I think APL is a, you know, although APL had its heyday in the 60s and 70s.
But, you know, these days you make videos and people just are kind of shocked by it.
But I think there's like a more nuanced question to be asked is like, I think the things that
made languages popular in the 70s and 80s is now different than what
makes a language popular today.
Because back in the 70s and 80s, you had less history and existing code to compete with.
And now, in order for like a language to compete in the C++ space, you know, you're competing
with the whole infrastructure and ecosystem, as Bryce mentioned in the most recent episode.
There's millions, if not billions of lines of code that represents like, you know, technology and effort
and value that, you know, has to go get displaced if, you know, you, if that's your goal of your,
you know, whether it's Rust or whatever. And so the question is, you know, like, overall,
what is it that makes a language successful? But then also too, like, what is it that makes
a language successful today? Like, is it, you you know i don't have the answer to the question i mean jonathan you've
you've been in the industry a lot longer than we have and you've worked with you know c++
lisp uh ada pascal ruby java like you have thoughts or you know i don't know what makes
the language popular i do know that most of us want to use a single language
rather than multiple languages.
We want to have a single hammer
because we look at everything as a nail.
And so you see things like,
I don't understand why people want to use
things like React
in the JavaScript world,
where you use JavaScript to generate HTML and CSS for web pages.
There are three languages there,
JavaScript for dynamism,
HTML for static structure,
and CSS for making it pretty yes and styling and they all those languages do their job very well but there are
now javascript frameworks where you do everything in javascript and i i and that's an example. And in the C++ world,
we prefer, we like,
well, in any programming world,
we like to say
we want to use the same language.
Look at, what's that?
Web-asm.
Oh, yeah, WebAssembly.
Yeah, you can write C++ code
and it runs in your browser.
And people tend, or Node.js,
where both the server and the front end,
the browser, are running JavaScript.
That's another example of having a single tool.
And maybe it's just that, you know,
these languages have grown, they're quite big,
it takes quite some time to understand them and learn them and therefore you want to use them everywhere
because you don't want you don't have time or or it costs too much to train people in
another language so well so here's a related question what made you uh when you switched
languages was that just a what do you call it a byproduct of switching to a new role and it was
like a it was a necessity for what you were doing or like because at what you went from c++ to java
to ruby and you actually did explain why you went from java to ruby that was someone patted you on
the shoulder and said maybe check out this thing thing called Ruby might make your life simpler. But then you went back to C++.
Like, were there, you know, reasons, you know, that you.
I think what Connor is really asking is what makes a rational man go from C++ to Java.
Well, at the time, actually, actually there, Bryce,ce i can tell you i can tell you something
like when i moved to java in 2001 java had reflection you could you could
fair that's i mean i mean shots fired shots fired the 90s era C++ was pretty rough.
Yeah.
But, yeah, you can see in like Ruby was really popular from about 2005, maybe to when I stopped using it in 2016. But you could see that people who were the top people in Ruby,
they had decided that it got too popular
and they wanted to move on to the next new fresh thing.
And so a lot of them chose Elixir in the Ruby community.
And I think Elixir, well, again, people say they don't want to have to maintain
their old code. And so by changing languages, they don't have to.
I mean, I've never heard that one before, but that is, I mean, that's a good,
that is a solution to a problem that you don't want to solve.
Yeah, you don't want to, you don't want to have to look at your old code. So you switch languages, and then you get to write new code. And maybe you're solving similar problems that you solved before in a different language. So you have a better idea of how to solve them. And the new language gives you other interesting capabilities. That reminds me of the K-language guy
who would just every couple of years
just write a new version and then just delete.
It's a tragedy.
As time goes on,
the immensity of the tragedy of what he's doing like
don't get me wrong one of the smartest people i've ever met in my life the guy is is clearly
you know a genius and um you know there's some joke on the internet it's you know arthur whitney
was blessed by the coding gods but you know his curse with the the abilities that he was given is that you know the languages
he created in the code he wrote was you know in unreadable by by most people and i just think
it's such a shame that he hits the delete button because he effectively i don't think intentionally
but like is destroying the history and the community i mean mean, I've said this a couple of times, like the K programmers,
if you ask them as a group, like what version, or not version, because they're different languages,
but if I want to go learn K, what do I go learn? K4, K6, K7? And you'll get a different answer.
And there's different documentations for each one. And it would be like the equivalent of like,
imagine all the different LISPs were created by one person, you know, this godlike, you know, entity.
And every time, you know, the individual went from, you know, LISP to Common LISP to Scheme
to Guile to Racket to Closure.
And every single time, he just hit the delete button.
Didn't, you know, explain reasoning or anything.
And you would just have to follow it and like, keep this history in your head.
Like, luckily we got to talk to John Ernest on Arraycast and he sort of gave a oral history
of all the different Ks and what are the major differences in the, in the K languages.
But yeah, it's, it is, it's a, it's a mass.
I hope he, I hope he has a change of heart, you know, and he goes on a podcast or gives
a talk at some and gives the history and, you know, why did he make the decision from K2 to K3 to to change the data model or something like that?
Because I think there's a lot of genius in his work.
And it's it's it's not even getting lost to the annals of time.
It's getting lost because he's he's hitting the delete key.
Yeah, he is actively.
Now, do you think he's you think he's got a backup or you think he actually
i believe him 100 that he actually like wipes it from his computer and like most i think john
ernest when we talked to him he said that he actually locally has a bunch of the different
k languages as arthur was working on them but he can't even release them because they're under
copyright. And so like the versions of K that exist on the internet are versions that people
have reverse engineered. Like there's two different K6s, one's by John and one's by another individual,
one's like written in JavaScript and the other one in another language, I think maybe C. And
there's a couple other different K variants, but like they're all basically people
that had a executable of K,
whether they got it from Arthur or someone else,
or they just had the documentation
and they reverse engineered the behavior,
which is like, that's crazy.
Like, isn't that crazy?
That's crazy to think that like-
That's crazy.
The dialects or the versions that exist of,
you know, K4, K6 or whatever,
or K3 even,
which I know that there's a couple
companies that have licenses to K3, that, like, that's the history.
Like, you know, people might say, oh, Lisp is way bigger than just the different K languages.
But, like, I don't know.
I think there is some analogy there that, like, imagine, you you know someone was hitting the delete key on on
different different uh lisps anyways that was that was a tangent there uh i have a question
for the two of you i mean c++ is multi-paradigmatic language in that it supports procedural, object-oriented, functional coding styles.
We have languages like Prolog, which is a logic-based style.
We've got, I guess, well, you've got what?
EPL, BQN, array languages.
Yeah, okay, array.
Smalltalk is object-oriented.
And we now have these quantum languages.
So have we found all the programming paradigms
that are possible?
No, because I think the next programming paradigm
that's likely being invented today is the AI-assisted programming paradigm.
How do we program in a world where programming is really giving a prompt to some AI that goes and does the task for you or writes the code for you. And that's, I think, clearly the field of prompt engineering
and what it's leading to is going to lead to new programming paradigms.
Yeah, I agree.
It sounds crazy, but literally someone,
when we were having a research discussion in video, made that comment.
Imagine your new layer on your stack is like you are committing
to your git repository
your prompts and then the immediate reaction is like well you know that's not deterministic blah
blah blah but like think about all the different layers of the compiler stack from like the
different irs all the way down to assembly and it's like how much i mean there are definitely
assembly generation experts out there but like like me personally, how much do I actually understand about what a C++ compiler is doing at the end of the day?
Like stuff Bryce knows a lot more about like instruction level parallelism and the way that they're like reorienting your program to do something.
And I mean half the time, I think most of the time it's deterministic.
But there are times where like you end up, you know, it's rearranging the way that you would expect it to be done but it's it's for the benefit because you know you
use you type something but it knows oh when you're doing some you know testing whether a number is
even most people don't use the bitwise you know and one or whatever uh but you can you can get
the compiler to recognize that stuff anyway so it's it's i don't think it's that far of a fetch to any any limit like any limitation on the that uh it exists and seems to be written in stone today
for large language models or ai um take with a huge grain of salt because it's it's a nascent
field and it's an evolving it's an evolving field like yeah is the is the lack of
determinism that you get out of large language model the problem for doing things production
scale yes but that's a restriction that i don't think will always be around you know if you look
at large language models today like they're not they're not very practical um like cost wise uh
latency wise bandwidth wise they're not they're not the most practical or most efficient tool but practical, like cost-wise, latency-wise, bandwidth-wise.
They're not the most practical or most efficient tool,
but as the field matures and it becomes more commoditized,
it'll become more practical and we'll overcome a lot of those problems.
While you were saying that, Bryce,
I was thinking of like the original cell phone that you see in like the
Wall Street.
What is it?
There's a movie called wall street uh with
michael something and anyways they've got these like huge things and it's like you know only the
people that had you know oodles of money could afford these these quote-unquote cell phones but
it's like if you saw that and said oh that's going to be the future everyone's going to have one it's
going to completely change the way we go about our lives you'd probably be like yeah probably not
but like that wasn't that wasn't what cell phones went on to be, right?
And there was a few different iterations.
They had the flip phones and then the smartphones were, you know,
the iPhone was a complete, you know, game changer.
And, you know, I expect that that's what the next 20 years is going to be like.
You know, there's going to be a couple of these big innovations.
Is that not just a different way of, okay,
I suppose it is a different way of writing program. Whereas I'm thinking of the programming paradigms as being, oh, I suppose, yes, actually, paradigms are really a way of thinking, isn't it? It's so, if you're writing a prompt, that's thinking. Okay, fair enough.
I mean, quantum, you know, the paradigms for quantum programming are also very nascent, I would say that's a new thing. And there may be other things like quantum in the future, you know, the paradigms of quantum for me are also very nascent. I would say that's a new thing.
And there may be other things like quantum in the future, you know.
Be sure to check the show notes either in your podcast app or at ADSP the podcast dot com for links to anything we mentioned in today's episode, as well as a link to the GitHub discussion where you can leave comments, thoughts and questions.
Thanks for listening.
We hope you enjoyed and have a great day.
Low quality, high quantity.
That is the tagline
of our podcast.
It's not the tagline.
Our tagline is
chaos with sprinkles
of information.