We'll get that one.
Yeah?
We'll sit.
You can clear your mind.
Antation.
No.
We'll register allocation in this talk.
We're just going to talk about what programming is like and why we're doing it.
And whether we're doing it the right way, because there's a good chance we're not.
I came up with this idea for this talk because you might know there's a lot of work going on
and what they call safe languages these days.
Probably some of you are working on some of those languages.
And I began to wonder whether this was all as well whether we were going about this the right way.
The, the, the entities for a safe, safe programming languages is is connected to security.
And I'll tell you a little story.
Person I know 30 years ago.
She had become a unix administrator and she came out of a meeting.
And at the end of that meeting, one of the senior people in the organization said,
I want you to make sure when we're done with this operation that it's secure.
But she went home that night and I, time she got to work in the morning.
And there's the places that complete disaster.
The major systems were not working correctly.
That she was responsible for.
She was supposed to be secure because then I'd be for when she went home.
She used the command,
and capital R minus W.
Flash.
So security is,
it has a lot of components.
And language, the language we program is just one of them.
If you have control of the machine as our dreamcast person will say,
you have control of the machine.
You own the security that thing.
If you are mistrusting the people who are responsible for that machine,
you could wind up with a read-only main drive.
You have policies, you have enforcement of those policies.
So all that stuff goes into the security.
Programming language that we're using is just one small piece of it.
And the definition that I think,
isn't even all great.
Let's accept that you can crash your program with the simplest possible program
language.
It doesn't take much.
And you'd like to think that a compiler would help me with this problem.
I didn't.
I'd like to think that.
But often it does not.
You yourself can look at those few lines and see exactly what's wrong.
But somehow the static analysis and all of its intelligence came up with nothing.
So the purpose of this talk, the definition of safe languages,
the one I'm taking from what I read from those C++ guys,
actually wrote to Bjorn Stralstrup to ask him whether it was possible to use the cobalt
front-end in GCC as an example of safe programming practices in C++.
And he directed me to a lot of his papers.
I think that was no.
But we could still talk about it.
In any case, if you go, so herb-sutter went through proposals that the thing you'd like to tackle first,
the lowest tank, are these four items from the common weakness and
humeration database.
And you'll notice that they're all runtime errors.
And they're pretty simple.
You used an array outside of where it was supposed to be or used a pointer that wasn't yours,
or didn't apply to the thing was supposed to.
That's it.
That's all they're really trying to accomplish.
And they've got a lot of people working on it.
In cobalt.
Well, I want to make sure I did this in the right order.
I don't know if it's skip anything.
Yep.
So cobalt has a whole runtime exception system built into it.
In a way that I've never seen another language do.
You've got, I want to point out something before I go any further in this.
Everything I'm going to talk about is something you could write.
These are things that are built into the system you're writing it with.
You could write a copy constructor in C++ and create certain things.
But that logic's on you.
The things I'm talking about are things that built into the language that you're using.
But in cobalt, it was originally designed.
Back where Bocca's now our form was.
That's not it.
That's a low question.
I would say that's a low figure, right?
So our cobalt system today.
ISO cobalt 2,023 has a 120 runtime exception conditions.
What you're doing in cobalt is you set up at the beginning of your program.
Any of these things you want to handle.
You can handle them individually each 120 at a time or by class.
All of the ones that are boundary errors.
And you say, what do I want to do about that?
And then when you finish with that declarative section runs as a result of that,
of the exception handling, logic returns to where it came from.
Or it doesn't.
It depends on whether you tell it to.
So you don't have it at the function level or anything like that.
It's generally speaking, it's a global thing.
Yes.
So it can be handled exceptionally or by category.
The each of those 120 exception conditions is to find to be either fatal or non-fail.
Non-fail errors, exceptions return, flown immediately.
Fatal ones by default, stop the program.
And if it is, but you can continue it.
If you can figure out what to do about it, you can, there's a statement you can use to return
the control flow back to your program.
Most statements in cobalt themselves, cobalt has very high level language.
It has a very high level statement.
So it almost all statements have an exception feature built into them.
Again, the compiler knows what you're talking about.
So it says, I'm going to add these two numbers together.
If that thing, the result is too big to fit into the thing where it doesn't fit
where it's going, you can say, oh, there's an error.
So what do I do about that?
Do I round it off?
Do I report it?
Whatever I'm going to do.
But that's feature of the statement itself.
The advantage of that is you don't have to think about what kind of exception this thing
will raise.
Right?
If you're going to do something and it's going to throw an exception today, you go to the side,
but you're going to put in your catch function, whatever it's called.
But here, the on error aspect of the verb has decided already, which thing, it's handling,
whatever that thing can do, whatever that's already.
You're going to have to think about those things.
So what's different?
So those are the one time aspects.
We've already said we've taken care of null pointers.
We've taken care of out of bound accesses.
But there's a lot more that the language could do for you.
The compiler could do for you.
And the way we've been building compilers and languages for decades now is preventing
us from taking care of some of the, from taking advantage of something that could do.
I remember reading, because anyone read coders at work, the book from a few years ago,
where a Fran Allen was at, oh, gee, it might have been phased in 1968 when
Contamson, kidding, of course.
When Ken Thompson and Dennis Ritchie presented C as a new language,
so you could use to write programs with.
And she was horrified.
Fran Allen from, from IBM was perfectly,
horrified because all the work they've been doing at IBM to build a gigantic language,
that would encompass all the things that you need to do.
So you have one program that would be an end-to-end application for the whole problem.
The AT&T guys have done the other direction entirely,
and built a tiny little language with the while it all.
Yeah.
So, so if you make your problem small, if you can easily accomplish it,
but then, of course, that leaves to everything up.
So, now I'm going to, the next part of this talk is about the compile time features of cobalt
that are, that we, that most, and I haven't encountered any language that's
having anything like that, and I think that it's worth your time to think about
whether they should be.
So, cobalt, you can define exactly how big your numbers are, where the decimal point
goes, how many what the fractional component is, when you compute every element of that
computation, you can, you can control the rounding of it.
It knows whether or not the results fits in the, in the, in the, in the, in the variable
you're putting it into, and whether you, and you decide what you're going to do about that.
If you're going to do anything at all, you don't have to turn that on, but you can.
When you move things between you copy memory from one place to another in cobalt,
there's no men copy.
You're not relying on a standard library.
You're asked, you're saying, this thing goes in that thing, and if it's going to be converted,
it's going to be converted by the language itself.
File operations, cobalt most about the kind of a file.
It knows about the file as it's determined to be inside the file catalog,
and it knows what kind of operations can take place on which kinds of files.
We do character output.
I heard something about print after today, and I was thinking,
I'll tell you how you put things on the screen in cobalt.
You say display.
Whatever it is, that's where it goes.
So there's no name copy.
There's no standard layout.
There's no men set.
There's no aeronaut.
All the stuff's handled by the language.
You never are out there talking to some library asking it.
This is important because you're checking systems.
You're static analysis uses the function call as a boundary.
It doesn't go into your standard library to ask whether that thing is doing
something correctly.
It stops there.
Here, we're handing the entire program, the entire problem,
to the compiler.
All of the IO, as you'll see in a moment, is entirely defined within the application.
So here we have, here we have a signed fixed point number,
with three decimal point precision.
The decimal point itself doesn't take up any space.
You do fixed point arithmetic on this thing.
You can assign values at the beginning.
If you don't assign a value, they have values too.
Everything has a value, but we know what it is.
All of this is declared before the first instructions executed.
It's all static memory.
All the RIO operations are defined by the program, by the by the language.
This is a cheap amount of how many months that we put into this part of the problem.
Instead of libraries, a couple systems usually use a module system.
And pre-processors that bring the external information into the system.
So we use embedded SQL to operate on, you know, to turn rows in the database into records
in the application.
Again, the compiler knows what the structure of that thing is.
And to contract that, again, before it ever starts, we know how many fields
are going to be in the record and what their names and types are.
That's sort of thing.
Again, with CSS, those things are all predefined.
I haven't worked with the CSS system since 1988.
So I would say, that was the last time I had one language to control the whole end
and functionality of the application, where the entire system was defined by the one in one way.
The opposite of the way we build systems now, where we've got a whole cloud of systems that we're talking to.
So my intention is, this is how you build the safe language.
If that's what we're after, it's not clear to me that it needs to be what we're after.
It could be that we're going after good things for the wrong reasons.
But if you bring everything into the system, if the language defines the entire problem,
if all of the operations are fully defined by the language and by the compiler,
then the compiler has the chance to tell you, prevent you from doing things you're not supposed to do,
and tell you what you've done wrong.
Preventing those runtime errors that we're trying to capture to create a safe language.
I'm not slagging C++ here. Please don't tell me I am.
I'm not. I'm not. I wrote.
I was just telling someone in lunch today that the Cobalt front end is a written in C++ and not just that,
but C++ 17. I hope that's allowed.
And so yeah, I don't see++ fan to it, but let's not confuse ourselves about what the language that I'm using does and can do and defines and doesn't define.
Your values are always defined. If you didn't give it an initial value, you got one.
You got a zero for numbers. You got blanks for everything else.
The iterators are attached to the array definition.
When you bump it up or down, the compiler is watching you. If you manage to get it out of bounds, you have a place to handle that exception.
Computation checks to make sure that the thing you don't have overflow opportunities.
If you didn't manage to create one, that gets caught at runtime.
The system understands about the IO, so you can't operate on the file incorrectly.
In fact, before the thing gets launched, the system that does that is going to see whether the catalog definition matches the Cobalt definition for this file.
And we do have per statement of exception handling, but generally it's a centralized declarative system for determining what you're going to do with your errors.
You yourself, as a programmer, don't have to care about the kind of exception that gets raised by a particular statement because we know what we do with that problem.
It's handled up there in the declarative.
So because you control the whole thing, I think that's a different sort of a problem.
And my observation is that Cobalt is the last time anybody tried to design a language that would handle the application problem domain from front to end.
That all modern systems are all built on the C model where we're going to have libraries that are going to talk to each other and we're going to make the problem that we're talking about smaller and your static checker won't find errors.
And maybe we should think about ways to bring some of those ideas into the languages that we're building now because I don't see this any other way for the compiler to check where it can't see.
And that is, I think, the last slide.
Time's up.