Okay, can you hear me back there? Okay, thank you. So, morning and thank you for coming,
and really I'd like to start with some thanks for all the organization that goes into FOSDN.
So I'm going to talk about a technology that goes back to the late 1960s and has essentially
stayed current and continues to evolve to this day. So this is from my company, the obligatory
marketing slide. I'm not going to go into it. So the first database was actually not a sequel
database. It was something called IMS. It ran on the mainframe and it was put together to manage
the bill of materials for the Saturn V rocket and the Apollo Moon program. And it was a key value
database because the key value database is the most general type of database and it was programmed
in IBM 360 machine language. And then there was Mumps, which is Massachusetts General Hospital
Utility Multi-Programming System. So if you can see that, you know, without needing to breathe
through the whole process, you can get a beer. But it came out of the Animal Science Lab and it was
also a key value database. It ran on a PDP7, which also was the machine that the first UNIX ran on.
So it's a good heritage that way. And it was a complete database machine. So you booted the
machine, it ran Mumps. Mumps is the operating system. There wasn't a separate file system. It was
the database. And the only way to exit Mumps was to shut down the machine. And the key value
database is basically key value tuples. So essentially, if you think of a tuple, there's a
hierarchical key and there is one single value. So in this case, you know, a key can be capital
followed by a country followed by a city. And at least in Mumps, it's always sorted. So one of
the sayings in the Mumps communities, Mumps means you never have to say you're sorting, because
everything is always sorted. The database is also completely schemalist. So what that means is
that you can mix, you know, the values and the keys can be numbers, they can be strings,
they can be just binary blubs. And essentially, there's a default sorting order for every key,
which is that the empty string collates first, and then canonical numbers collate after that. And
then anything else is not a canonical number collates in byte order. And one of the things is
that you can change this, you can customize it, but this is the default sorting order. And the
first key, that's something that always has, there's some rules. It has to be alphanumeric,
but other keys can be pretty much anything. And, you know, the schema is determined entirely by
the application programmer and not by the database. And you can mix key sizes. So basically, you know,
this is a little bit like playing poker on a boat and all wet cards are wild. So you can pretty
much put any number or any string as any key except the first one. And, you know, there's this
similarity to, it's a tree. So basically, you can take those key values and you can make them look
like array references where the, in those keys, the first key is like a variable, the other keys
are like subscripts. And then the value is the value. And this basically is a paradigm which is
very familiar to programmers. Every programmer in the world knows how to program arrays. And this
also looks like a tree. And the difference, you know, it's kind of like a JSON tree or an XML
tree, but the difference between a Mumps tree and a JSON tree is that, is that in Mumps,
you know, you can have a value at the root of a sub tree as well as the nodes of a sub tree
which you can't do in JSON. And the concept is, you know, basically, one of the things about
Mumps is they tried to keep things simple because it ran on a PDV7, which is not a very powerful
computer, and, you know, four kilobytes of memory. So you have variables which are called local
variables which are there only for the lifetime of the process. And then you have database
accesses. So if you see the little carrot in front of the variable name, that makes it into a
database access which is now shared across processes. It's persistent. Anything that doesn't have a
carrot basically is private to the process and disappears at the end of the process lifetime.
And the language standard was very simple. So the power was the language and the database were
tightly bound. Remember, you booted the computer, you type anything that's a database access. And so
there are only some simple commands, simple set of functions, and then there are, you know, what are
called intrinsic special variables which are certain characteristics like, you know, you to set an
error trap, you basically set a value to dollar e trap, and then that string gets executed. Now,
one of the interesting things about the standard is that the standard recognizes that here's a
standard. Here are all the things that implementations can do which may can be non standard. So now if
you're writing code, you know exactly how to write code that is portable across implementations. Plus,
you also know that if you want to port code, it tells you exactly what you need to look at. So
anything that starts with a Z or anything that there are these job parameters and device parameters,
those are the things you have to look at. Everything else is portable. So here's a real power.
Any database update is just a, you know, just a variable access. And because of the fact that,
you know, that the keys and values can be anything you can have. Like in this case, you can say
customer one, two, three, four is martin with a king. And then you can add a subscript and say
birthdays, given the birthday. And there's also database accesses like dollar order is the give
me the next subscript at this level. You can also, you know, set a local variable like next
customer to customer with account ID. And in this case, account ID is a local variable. So,
so database accesses are nothing other than simple programming statements. So the, the seamless
coupling between the simple language and a simple database is where the real power of, of bumps
lies. And the other thing is it just sort of works without any fuss. You know, you just start
using it and it works. So where are we today? So today, mumps is kind of an inside joke in the
healthcare environment where it started. And if you can imagine the CIO of a bank going to the
board of directors saying, we've chosen our future programming language on his mumps, it's kind of
like having mustard stains in your tie when you're making a presentation. So it became an ISO
standard and the ISO standard name is M. And today the world's largest real time core banking
systems and medical record systems use m databases. So the largest bank here in the Benelux, actually
their core system runs on an MMM database. And there is an electronic health record system,
which the entire country of Jordan is using. So there also runs in an M database. And where the
industry is, there's one major proprietary implementation. And there are two major related
FOS implementations. One is GTM. I actually led GTM from 1995 to 2017 and was responsible for
open sourcing it in 2001. Before that, it had a proprietary license. And then in 2017, I left
and started, YottaDB is a downstream database to take it beyond the, where the original M and GTM
were. So, where are we today also? The M language standard was abandoned by the major proprietary
implementation, which kind of, I think in retrospect, was good. And the other thing is that, you
know, with the M language, the language is kind of like a religion to a programmer, right? I'm happy
to change my religion. I'm not changing my programming language, but you go first. Right. And
the other thing is that C is going to become a lingua franca of computing. So when we started,
YottaDB, our vision was to say, the database is more important than the language. Okay, the
language is important, but the database is more important. And you need to have the seamless
coupling between the language and the database. That is a very powerful concept. So we extended
that to other languages. And what we did was we created, there's the core database. And what you
see in orange is the original M language. We also created a C API. So you basically do a
pound sign include, and then you have C functions. And then once you have C, then you have pretty
much any other language because every language in the world knows how to call C. So we have APIs
for a number of other languages. And by the way, since the key value paradigm is the simplest
paradigm, we also have a SQL layer that goes on top of it. And you can map the key value to
SQL tables. So that's what the C API looks like. And because of the fact that you could write APIs
for other languages, Lua's and other minimalistic language. So this is what the Lua API looks
like. And this, by the way, the Lua API was written by the University of Antwerp. So I'd like to
say thanks to them. So this is what the Hello World in Lua looks like. And you're basically doing a
database access. So you're setting a global variable called, called Hello, with a subscript
lower and the value is Hello World. And so languages are just tools to manipulate the database. So
these are the languages that we support. So at YataDB, everything we do is 100% free and open
source, mostly a GP, a V3, a couple of things are Apache licensed. So these are the, a way you can
go for more information. And one of the interesting things is people talk about Redis as a high
performance key value database. So we actually created a container and you can, in that container,
run YataDB and Redis side by side and you can make the comparison for yourself. So we actually
significantly outperform Redis. And that's my name and contact information. Please, you know,
email me at any time. And so any questions, comments, if you're throwing rotten tomatoes, I'll duck.
Yes, sir.
It seems to me from the first slide that M is decorative language, but the languages that you wrap
around is like C, Python, Goza, imperative languages. How is this market works?
There's nothing functional about this. You know, basically from the title of the dev room, it said
minimalistic. So this is minimalistic rather than functional.
So the question is, is M a declarative language? It's actually procedural language. And you don't
really need to declare anything. Think of it as a, as a form of like almost like a shell script,
except you're not calling for sieges.
So,
so when is the origin of the code base on which were the challenges for migrating to new hardware?
So the question was, what are the challenges migrating to new hardware? And at least for
the other dev, because that depends on the implementation. Obviously, if you're an implementation
as just an interpreter, it's easier to migrate. In our case, it's a, it's a compiler. And one
of the interesting things about the compiler, it actually generates indirect threaded code.
And so essentially, we have to generate the, you know, create these virtual op, there's
a virtual machine with a bunch of virtual op codes. And we basically have to create the,
the op codes in that machine. We basically have to deal with the stack frame. So it's
not a zero effort porting, but it's a relatively straightforward port. I will tell you that
the hardest thing we've done is actually putting the Java, I mean, the go wrapper on top of
the C API, because go thinks it controls the world. And that's offensive to those of us
that think we control the world. So there was a little bit of cultural mismatch.
How come you're the fastest? You have to ask the reddest people where it is slower than
your TV. I think it's a bunch of things. I think it's the fact that, you know, because
of the, of our heritage and the fact that we're used in these very large scale systems,
there, you know, we're, we're obsessive about performance. And so the only thing that's
more important than before, well, two things are more important in performance, functional
correctness and security. So, I mean, and, and plus, you know, the court base actually
went into production back in 1986. And it's had therefore a lot of time to evolve and
mature. Okay, in that case, there are no other questions. Thank you very much. Where's the
next speaker who can come up and set up?