Files
Lee Hanken 7c8efd2228 Initial commit: HPR Knowledge Base MCP Server
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-26 10:54:13 +00:00

240 lines
25 KiB
Plaintext

Episode: 926
Title: HPR0926: Heresies in the year of the apocalypse ep 1 - computer languages
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0926/hpr0926.mp3
Transcribed: 2025-10-08 05:03:44
---
music
Good morning, good afternoon, good evening, this is Mr. Gadget, and I'm calling in my first
show for the year of my Lord 2012, the year, of course, of the Mayan Apocalypse, so, and
in keeping with the whole Mayan Apocalypse, Apocalypse Year theme, I am going to do my first
event, at least two, maybe three or four, a different episode in a series. Now, speaking
of a series, I look out here on the calendar and everybody is responding so so well to
the better, please, from other people within the HBR organization, including the inethical
mole, Kim Falon, but also to my, you know, kind of challenges out there, to get more
new shows on there. So, it looks to be, like I'm not even going to have a plot, to have
the show be heard until, well, in January, and good on everybody who's doing that now.
Your goal is not only to call in the show, but for everybody together, keep on calling
in new shows, so that I am lucky to get in once a month, alright? That's really, honestly,
what I want. I want to hear lots of different shows this year, and throughout the year,
I need to keep this up. So, do it on everybody, keep it up. So, as I mentioned, the Apocalypse
Year, and I apologize for background sounds, I'm going to be driving, and even visiting
the Recycle Center and aloting various cam bottles and such at the recut, the CISOT, a little
a lot for a stay with the new Tom Recycle Center, as we talk here this afternoon. So, Apocalypse
Year 2012, and in keeping with that foundation, I am going to entitled this episode, Heresys,
in the year of the Apocalypse, episode 1. And this particular Heresy is about computer
languages. Now, I've mentioned before in some other episodes that I started way back
at the very start of the micro computer revolution, and I have written programs, in fact, I've
even written programs for a living. Now, back when I wrote programs for a living, I'm
not even sure the term developer had been developed yet. I'm not even sure that anybody
would use the term developer back then, but I taught myself programming on my first little
micro computer that didn't even have a assembler, and didn't even have a terminal hooked
up to it. I was hex-padking in machine code, and I went on to teach myself languages that
were available on the micro computers back then, and, as I say, ended up making a living
at that. So, yes, I am music major, which I've also explained before kind of how that
worked. Why a music major has become a technologist and has major living with micro computers
and other various computer systems for low the 30-some odd years. And, so, like I said,
I used to write programs for a living. Now, back in the day, all you had was machine
code, right? There wasn't even assemblers, and then eventually, if assemblers got developed,
their really first high-level language was cobalt. Believe it or not. And, I believe,
the equally investible Grace Hopper, who, if you do not know who Grace Hopper is, and
you are a technologist, male or female, you need to stop now, if you are in a position
to stop and Google something, not while you're driving, please. And you need to Google Grace
Hopper and find out more about this later. She is really an amazing story. And I believe
Grace was part of the committee. There was a committee who invented cobalt. Now, there's
an old joke that says, okay, what's the difference between a horse and a camel? And the punchline
is a camel is a horse designed by a condition. And, probably, through the years, you know,
a lot of the issues with cobalt, they have been because of certain kinds of, you know,
decisions that were made that were made by a committee. Low and behold, as we go a lot
here, we've had several languages that we continue now to this day to have several
languages that have been able to dictate for a life. They have someone who started out
with the development of the language and still has the final say on what it is that's
going on in terms of that language. And they've benefited, I think, probably for that
single-minded vision, same thing with a whole new job, single-minded vision thing, right?
But cobalt was a high-level language, and I can't remember what the first O was. But
I think it's just CO for common. And if I'm remembering right, cobalt stands for common
business oriented language. And when you think about it, it was a language that really
did allow for a lot of business oriented programming, lots of mathematical calculations,
crunching of numbers, et cetera, et cetera, keeping track of inventory, et cetera,
businesses needed to have done on their big computers that they had spent lots of money
on. And it was much more productive to have the programmer write programs in cobalt.
It was also more standardized and you could maintain that over time without a lot of
study and everything like that of the machine language or even assembly language code.
The company I worked for has a lot of cobalt code, legacy cobalt code that's been around
since before I was even programming computers. And the start of the company was in 69. And
there's lots of cobalt code that's been maintained by four or five, six, maybe even ten people
that's been handed down to here and the down to on the main phrase. So there was more
productive. It was more productive for the programming to be done there in that higher
level language. Now, when they initially wrote, and this is an interesting question about
the whole Cherigan and Richie, you know, Mr. Richie, of course, recently passed away, about
the same time, a little bit after Mr. Jobs. And a lot of people have actually been getting
the chronology slightly wrong, okay? When they first wrote the UNIX operating system on
the PDP machine that they had access to at the lab, they actually wrote it in assembly language,
okay? She did not exist. C came after UNIX, right? UNIX was originally written in the PDP
assembly language. And if you know anything about assembly language, if you've ever done anything,
assembly language is basically just a little bit better version than having to know all the
machine codes, right? But it's very specific to the architecture. And so they wrote it for whatever
that PDP was, a five or six, I forget, the one they had access to first. And then they
ported it to other PDP machines, which were very similar but not exactly the same. So then they
had to take their assembly language code and they had to rewrite it so that we compile on this other
machine and talk to the public reports from all the current things. Well, after about the second or
third time of doing this, this was way too much work. We need to invent a language that
makes it easier for us and we'll rewrite the code into that language so it will make it easier
for us to port it over to these other machines we have to deal with. And thusly, today came
up with this idea of inventing this language that we all know at sea. And so I have always
maintained that since I was around when all this first happened and was at least paying attention
to all these kinds of things that were related to this. And this might get a little loud because
we're in the glass portion of our recycling here. And they're full, so I'm going to have to kind of throw
into the bin. I'm sure that sounds just lovely, but the motion of the air across the
microphone is making this very, very visible. So essentially, sea is universal assembly
language, right? Sea is essentially really low level, but allows you to write
a program that is going to be extremely efficient and really, really almost as good as being
down there at the assembly level. Now, assembly level, assembly language program,
is going to argue with me in the yelling set there. You have PC play here at this
point. Man, you have it totally wrong. If I have it totally wrong, call in an
episode and explain to me why I'm wrong, okay? Essentially, it's universal assembly
language and all you have to do is write a little bit of libraries in the actual assembly
language of that machine and you're up and running, right? Cutting all the other
languages are actually written in sea. And by the time you have your basic
language started, then you can go on with the other kinds of things related to sea
could actually be kind of, you know, the library, et cetera, et cetera. So it is
efficient and it's very, very portable. I mentioned earlier and I'll state it again
back in this time frame. And I didn't hear about the software freedom until well
after this time frame or the time frame even that he actually wrote them. But I heard
a lot about portable code, okay? There was a lot of portable code back then. I
didn't hear about free and I didn't hear about open, right? And open really didn't
have been until late. So we have this kind of universal assembly language. Now
let's pass forward, shall we? I'll admittedly tell you that I've never, well,
I attempted to teach myself sea and I attempted to start down the sea path.
And this was at a point where I had actually made the decision that took me off
of the path of making a living full-time as a programmer and rather using other,
you know, using those technical skills to help support and, you know, work in the
technology field, training people on things, consulting people on things and things
like that, but not actually writing the code. But I did at a certain point and had a
job full-time where I was a porting engineer. So I wasn't actually writing the sea code,
but I was looking at other people's sea code and modifying it slightly to run under the
machine, fix the errors that were related to the particular kinds of things that I
was in charge of trying to, you know, detract other things like that. So I've
done a lot of porting, compiling, you know, of somebody else's sea code. I,
whenever I tried to learn sea, I always was going along at about 75 or 80 miles an
hour. Sorry, don't know the offhand what that is in kilometers per hour. But I
was going along at a very nice, you know, furlungs per fortnight pace and I would see
up in the distance the wall that is pointers. And I'd always hit that wall and never
break through. I just never got pointers and, thusly, you know, sea was probably not
the language for me to write because it's pretty soon in a field of pointers, one way or
another. And I just somehow in my mind just didn't wrap around pointers.
Anyway, it's got a great tip for me for what it is I should do. Be sure to call in
or leave me now, right? HBR, Mr. Gadget, that's a plural in RGAD, G-E-T-S dot com.
Okay. So I've modified the sea code, I've bored the sea code, but I've never written
anything except that. Very kind of basic, basic, simple, you know, Chergon and
the Chergon and Richie Sea program book, you know, first-view chapters kind of program.
All my own. And, thusly, I am not well versed in the whole aspect of object oriented
kinds of things. So I couldn't tell you exactly what the differences are or the fine kinds
of reasons why of legitimacy as opposed to FIFA Plus or any of those kinds of things.
I do, you know, understand the concept, of course, of it's not just about, you know, functions
that you call things like that. It's about methods, right? That can affect the object that you're talking about with
an object. And what is that object is a string or an array or, you know, whatever it is.
And so, you know, I get all the concepts of it, but I never dealt with any object oriented kind of stuff.
So feel free to call in an episode to explain to me all and all of the HBR listeners who may not
really understand what is it about object oriented, makes the improvements to see the fixes,
everything that I'm talking about here. But we have this object oriented version of the C,
whether it is C++, which is the most common and popular, I think, or we have C-short,
which is specific to Microsoft of course, which is oriented towards the .NET framework.
And not limited to that, because there's the model project, which has its detectors and its supporters, right?
I'm porting that to other non-Microsoft .NET kind of environment. And then we have Object to See,
which is of course the particular version that you use if you are an Apple developer, right?
And I know people are going to scream a word when I make an statement.
There are all variations on the same thing, right? They're all adding some forms,
their own particular brand of object oriented programming practices to the basic under one C language.
How much more higher level and how much more efficient is that in terms of writing programs?
In the modern world here, and I've made a decision in 2012, there's really going to be just a time for the end of the world,
I really am going to teach myself another programming language to be able to just have together some stuff that I want to do,
maybe contribute to an open-source project that uses it. And I've been doing a lot of research on different languages,
so that's what's the best one to learn. And I think probably I'm going to settle on Python.
And the reason I'm going to settle on Python is I really think, and I don't know whether I'm going to get my 10,000 hours in, right?
But to be really good, you have to set yourself and you have to practice that over and over again.
And I just don't think that I have enough time left in spare time because it's not my job to dedicate to trying to get at least reasonably good
at any more than just one language. And with Python, I get everything I want to do, right?
I can script with Python, I can write GUIs with Python, regular programs, and things like that.
I can use Python with Django, that's a particular framework I'm going to choose. And mostly it's because Django actually was written originally for a believe Lawrence Journal World in Lawrence, Kansas,
which is about 40 miles away from Kansas City. So it's kind of a local thing, you know, that I picked that one. These are very popular.
The other reason why I'm choosing Python is because there's lots and lots of resources for it. There's lots and lots of libraries for it.
So I think it's going to leverage best for all of the different things that I might possibly want to do with it.
But I've been looking, as I say, into other languages. Now one of the things that caught my eye, and one of the things I like about Python is
it is a scripting language. So there's that interactive thing. So it's going to be easier for me to learn, right, because of that interpreter kind of thing.
And I don't really think that the hit not being compiled, the situation is really going to affect me. And if it really does, and it's really my own project, I can figure out where that performance is needed and how somebody rewrote that into the E, right?
That's the common kind of thing with a lot of these scripting languages. It's tested up for 98, 99% and then that last little percentage, you can always write that empty.
I was interested, though, in the syntactical basis of it also, the things that I have read about Python and a little bit that I've learned so far, it seems to be that you can write fewer lines of code.
And they are a very much clearly stating they're easy to, for you to understand what the program is doing kind of self documenting if you will, right?
I specifically, I hate to, you know, start a religious war here. I specifically am not going to use hurl because there are so many cool things in different ways to do it with hurl.
I don't want a language where there's 18 different ways to do something. I want a language where there's kind of one way to do it and it's consistent. Now, call me stupid, but elegant code is not what I'm after here.
So, maintainable code, easy to understand code and code that I can leverage a little bit of time to write it and get a lot of stuff done. That's the things that I've interested in here.
And I know I'm starting a big, old, long discussion and I encourage you call in shows and tell me why I'm wrong about hurl and why, I mean, I understand the whole thing about elegance.
But sometimes ugly code that everybody can understand and fix is better than elegant code that only the guy who wrote it can really understand what he's doing.
And I know this from experience.
So, I've started the religious war way in and tell me why I'm wrong.
So, I want something that I can leverage what limited time I have.
I'm pursuing, you know, with my spare time mostly and leverage the amount of things I can accomplish.
But it's not untrue of most every project that's not there. Who has all the time in the world to work on a project?
The world's problems that can be fixed through a, you know, computer program are not such that we have all the time in the world.
And sometimes getting to run fast as possible in the C version isn't really what's important.
The slower, maybe even you could argue, uglier, interpreted code in the simpler language will accomplish what we need and we're done.
And if we need to fix it later, we won't have to go back to the original guy who wrote it because he's the only one who can figure out, oh man, I did 17 things, so this one one code, okay?
I know I'm overstating that.
So, one of the things that I ran into along the way in terms of the syntax and everything and, you know, I don't have a curly brace a version.
I'm not pro curly braces because I'm not anti curly braces.
I never learned this because of all the parentheses that didn't seem a little strange to me.
But, you know, the curly brace thing, you know, I don't have a problem with the whole white space indentation, I'm going to indent it anyway.
So, it does kind of make sense to me that, yeah, if I'm indenting it anyway to make it readable, why not just have that V, you know, what it is?
I know a lot of people think that that's just crazy though, you know, but it seems to make sense to me.
I ran into Valla and Genie, which is a particular kind of pre-interpreter, I guess, or something like that.
Anyway, Genie is to Valla, what Python is to see, I guess.
All right, so Python is interpreting to, Python's using an interpreter, right?
But Python is a syntax and ultimately it ends up being, you know, C code.
It's Python C. Okay, I give up that. That's not an analogy, okay. That's not true.
But what it is is Genie is very Python-like syntax that uses white space indentation and allows you to have the same kind of things that you get out of, a Python kind of code writing experience, right?
A lot of productivity out of it, fewer lines of code to accomplish what you're trying to accomplish as opposed to the equivalent indicates the Python C language that you would write.
The relationship between Genie and Valla is, Genie is actually something that compiled down into Valla code.
And then Valla is its own object-oriented compiled language, right?
And it, basically, you write Valla code in that object-oriented Valla kind of syntax and it compiles to see that will compile with the GCC compiler.
So Valla is already a higher level language and at least from my perspective, a little bit more productive, better syntax than my understanding of objective C or C++ or C sharp.
I may be wrong. Explain to me why I'm wrong in a show.
So Valla has that kind of efficiency of being able to not be quite as low level as see the universal assembly language.
It's a higher level language that compiles down to C and every machine has a C compiler and then you compile it to the machine language of the machine and you leverage off of the people who work on the GCC compiler to get it running on that machine and deal with the machine level things.
And you have a universal higher level language here Valla. Now, is that exactly what objective C does? Am I missing something with objective C? Am I missing something with C++?
Hey, just learn C++ because that's exactly what it does.
What I'm saying here is, why don't we have things that have this Python-like syntax that makes it easier to write programs with fewer lines of code and then has that compile to some intermediate thing like the C++ compiler.
And then the C++ compiler compiles it for the individual machine or take the same route at the genie Valla thing does, right?
Don't want to write it at the level of Valla, want to write it at the even higher level of genie, write the genie code, compile a Valla, tweak some stuff at Valla, take the Valla code, compile it to C, tweak some stuff if you need to see.
In my mind, there's no reason why some of these things that are quote unquote scripting languages in terms of their syntax and their implementation couldn't go on a similar path.
I guess the reason I'm going with Python is the cause of the huge amount of libraries that are available in Python.
And the whole gen Valla thing is still at its initial stages and doesn't have as much code that I can leverage off of.
But why isn't there a thing that I can take my Python code, a dual my development in that, and then take that same exact Python syntax and get a similar way, either compile it down to an interim step and then to
the code or just compile from the Python syntax directly into a bit of C code that I can then run through my GCC compiler and run as efficiently as possible on that actual machine.
What's wrong with this idea? Why are we still writing programs with a language that was written 30 some odd years ago?
Nothing against Mr. Caregrian and Mr. Richie, but did they really write the perfect language? Should we still be writing everything in universal assembly language?
Now you're going to argue with me, we're not, we're using C++ code, right? Explain to me how high a level that language is because I'll state it now and I've stated it the entire last 30 years.
C is not a high level language, I mean it's a high level language in that it's above assembly code, but C and C are not equal levels in their heights.
Does that make sense? Why are we still using things that are still almost down there at the bare metal level?
Unless it's a situation where we absolutely have to. And why aren't we taking some of these things that are easier for people to understand and get involved with programming and get them into efficient compiled versions of those.
And I know in the interpretive side Python isn't tight and it doesn't, you know, doesn't actually check these things until it runs.
Who's to say you can't have a typed version of that? If you write the right code, having strict typing or not having strict typing in your Python code shouldn't make a difference.
Explain to me why I'm wrong here. But my hair if he is, we're still writing code in too low a level and what we need to do is take some of these ideas from these more productive, simpler syntax to get more done scripting languages.
And we need to start thinking about that in this whole gene evolve GCC compiler kind of relationship. We need to start thinking about doing that because we don't have enough programmers people.
We do not have enough people out there who can understand to write the underlying C code. We don't have enough people who can understand and not everybody can be a computer programmer. Well, readily admit that.
But a lot more people could be writing productive code if we had a more efficient language that they could use to develop that code in a way to compile that.
And I have looked into some things where you know the Python, there are some things that will do this kind of thing. But I don't know what kind of support those have.
I'll refer back if I find something pleasant to report in regard to doing that kind of thing.
What kind of things out there are, what am I missing? What's that high level language that has that magical crossover of the simplicity of the syntax and productivity of the syntax of the scripting language, but compiled down into a fishing code.
Either automatically or there are ways to do it. Because I've been doing research and I haven't found any obvious find of what's out there to do that.
So with that end of heresy in the year of the apocalypse, the one why are we still writing universal assembly language that's 30 years plus old?
This is Mr. Gadgett, wishing you a happy new year and a safe and prosperous one. And we'll talk to you next time. Maybe even next month. Bye.
You have been listening to Hacker Public Radio at Hacker Public Radio.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself. If you ever consider recording a podcast, then visit our website to find out how easy it really is.
Hacker Public Radio was founded by the Digital.Pound and the Infonomicom Computer Club.
HPR is funded by the binary revolution at binref.com, all binref projects are crowd-sponsored by linear pages.
From shared hosting to custom private clouds, go to lunarpages.com for all your hosting needs.
Unless otherwise stasis, today's show is released under a creative commons, attribution, share a line, lead us our license.