So welcome everyone to Lighting Talks.
We're continuing with Flavio, which is an amazing project for running Pearl.
Okay.
Thank you for coming.
So, yeah, this is about Pearl Programming Language.
It was developed in the 90s to get a bit of internet.
And Pearl was basically created on top of seed language,
a way to make things easier,
parted to many different computers.
So basically Pearl ran everywhere that seed language was available.
And when the internet came, Pearl was the easiest way to put things online.
So it got a really popular at that time.
So this is the Pearl Port page.
It shows where Pearl currently runs.
And you can see a long list of unix derivatives,
does even windows and really some less popular computer computers.
Yeah, the MS and things we probably don't have access to,
like ABCD platforms, mainframes.
So it's a bit of surprise that Pearl doesn't run in the JVM.
So why not, is several attempts were made,
but traditionally Pearl runs on top of seed language.
And yeah, running seed on top of JVM is actually making it very slow.
Pearl has its own VM, its bytecode interpreter.
And parting VM to run on top of another VM makes it,
yeah, consider that you have the raw CPU,
a VM makes it maybe two, three times slower.
If you create another VM on top of it, it would be ten times slower.
So that's really, yeah, not going to be practical.
But yeah, running Pearl without seed means rewriting.
And there's a lot of problems with that,
especially the semantics, what help our works.
It's a very fine tuning of features.
It's very hard to describe this in a different language from scratch.
So what makes this project possible is that, yeah, AI.
I made a small, so I figured I could make this, but with help.
I wrote a small prototype in Pearl and Java,
to figure out if the concepts would work,
like closures, the parser,
and they figured way to make it lookable,
like a very small parser with sub languages.
And yeah, it actually worked.
I used the Pearl tests, the standard protests,
as a target for test-driven development.
And yeah, once the main objective was in place,
having this basic language in place,
I started going test by test, simplest ones first,
and then the most complex, until we get enough Pearl working.
This is now one and a half year on.
And yeah, it started with a discussion with architecture on
chatGPT and how to build the documentation.
So there's a lot of things going on.
It's not an AI project.
I made this myself, but I asked AI for help.
For example, very frequently,
feature was implemented, the broken other feature.
And AI helped figure out, okay, this is what this is actually
in this to be done.
So what is the logic to make those features compatible
in implemented in the same source code?
And you see, I didn't mention looking at Pearl source code,
and never looked at Pearl source code.
This is all made in terms of behavior,
in terms of test-driven development.
So what the tests show me, I need to implement.
So currently, we have a number of CEPAN modules.
CEPAN is a repository for Pearl contributions.
And currently, Pearl and Java runs DBI,
which is database connectors.
It has HTTP support.
It has several file types support.
And many CEPAN modules, Pearl, Pearl modules,
also run directly in Pearl and Java.
The standard Pearl has interface with the C.
It's called access.
And Pearl and Java also has access, but it connects to Java.
So, for example, for DBI,
it connects to JDBC directly.
It doesn't need the internally conventional Pearl uses database drivers,
but in case of Pearl and Java,
it only needs one driver, JDBC.
So it was really easy to port.
It's a large, relatively large file on Java,
but it's a single database driver.
So let's go to features.
I built this feature matrix for myself to keep track of what's going on,
how much of Pearl is implemented.
And currently, it has a lot of greens,
and a few reds.
Red is things that are not really compatible between Pearl and JVM.
For example, this dry blocks,
this dry is called when a variable is no longer used.
It's when Java does garbage collection,
but there's no hook in Java to tell me when a variable is destroyed.
Currently, no dry blocks.
There are worker rounds,
but I don't want to go there.
At least not yet, or maybe optionally,
because it would make the language slower.
Yeah, and access itself is different.
It's Java related, not C.
So it's a simple module that you see.
We'll not be directly vulnerable.
But, yeah, AI can fix that.
I already pointed a few modules, and it's relatively easy.
C integration is actually doable.
There are hooks in Java to call C modules,
so that's not really a big problem.
Yeah, things partially supported.
I think most important is rejects.
So there is a preprocessor in Pearl and Java
that transforms the Pearl specific rejects
into to be runable by Java rejects engine.
But there are some things that Java rejects engine,
just cannot do.
So I think maybe in the future,
the Reimplementer rejects engine,
or use something like rubby, library,
it'll come in some way.
But a lot of rejects are already in place.
Yeah, some things like back tracking controls,
they don't exist in Java.
And also some optimizations.
There are some special cases in rejects that they take a long time.
In Java and in Pearl it's fast.
So maybe custom rejects engine actually makes sense.
Yeah, for operators and statements,
this is all done, all implemented.
Yeah, smart match was deprecated, so not there.
Let's see what else.
Yeah, special control flow operators, Pearl has go to.
And it can do some really interesting stuff.
Some things are actually implemented,
but not everything.
And yeah, and then party modules.
There is, yeah, IO layers is something Pearl supports
to read files in different encodings.
It's supported.
Variables modules.
Yeah, like I said, DBE is there, DBI.
Pragmas version features.
Features is something in Pearl that allows it
to be backwards compatible.
So you have a old Pearl program.
It features and what experimental features.
You can make it make Pearl behave as a specific version.
And finally, I think most important at the moment is
Java segment size limitation.
Java originally was implemented as system B64K blocks.
And if you try to compile a method that gives more than 60,000 bytes,
it dies with a method too large.
But Pearl doesn't have this limitation.
So the fix is to split methods into smaller methods.
This is already implemented, but has still some problems.
And finally optimizations.
Yeah, I'll make a small DBI test.
Yeah, let's open this example, DBI.
Yeah, so this is standard Pearl.
The only special thing here is the database connection string
is start with JDBC.
Yeah, and everything else is exactly the same as Pearl.
This actually runs in Pearl or Pearl on Java.
If you have the right driver.
Yeah, I think it's interesting to show as a last thing.
Because it has enthusiastic people doing testing the limits of the syntax,
Pearl can do things like this.
This is toy in Pearl.
You write a program that is just for fun.
And try to make it as different as possible.
And the game is that this should print another Pearl hacker.
And with J Pearl can actually understand this.
So it shows how the syntax integration actually works.
Yeah, the success story is performance is actually very okay.
It's about the same as Pearl.
And it's now running a quarter million unit tests from Pearl.
If you run Pearl with all the methods, all the modules,
it's about two million tests.
But the core Pearl is not that big.
So it's over, I think, 95% of Pearl Core is already in place.
We probably don't have time for questions.
Maybe one question, no questions.
Then we can talk later.
And yeah, thank you.