what tools we need to make those decisions based on real values, not just ideas. Delphi is an old language. It was very popular when Windows XP first got out in 1995.

It was called the derived language. It was used to build lots of rich client applications on all kinds of Windows platforms. It was widely used before .NET came out.

It's now largely replaced by C-Sharp systems and Java systems and I think going to mobile, but there are still lots of old systems where things have to be done.

Moose is a big engineering environment based on Faro. It allows you to visualize code. It allows you to create browsers. It's something we first discovered when we had to do a conversion of a legacy COBOL system

to get all the data out of it. We noticed that we can really fast build tooling to help us with that. We can make visualizations where we can see what's happening with the data. We can take a look at complexities, dependencies

and we can create browsers very fast where we can just look to the code. On the left you have a system with about 60 browsers. Each browser is about between 10 and 100 lines of code and helps us take a look at some aspects of this COBOL data

that we had to analyze. That's where we found Moose and because Bijo and I, who are working on this, have a Delphi background, we decided that we wanted to apply this to a Delphi tool.

So why do we think we need to visualize? We think that we need to provide much denser information than we can by just taking a look at the text screen. We feel a need to look at multiple dimensions at the same time, not just the one dimension that we have been filed,

unit to class to method. We need lots of help restructuring and migrating systems.

The top of this sheet is not visible. It says provide dense information and the bottom is visible. We have been working with larger systems, the systems which are several hundred thousand K lines of code, and if we start working with them,

then it's clear that just reading all that code is not going to scale. A hundred K lines, reading it takes weeks, and mostly we want to be able to see where we are and find what we should change within days or much faster.

We tend to find larger programs because programs grow as they are used and Delphi code is 70 years old.

Really small programs we no longer find in Delphi because they were already migrated, that's easy. The problems are in the larger programs. Well, so what do we mean when we say we can provide dense information?

Well, we have pictures like this where we see 300 files, and we see for each file which other file is experiencing. We try to get some more information in there, so we give them a color and we say that the white ones are very small files,

and the black ones, or the blacker ones are larger files, and we see here that the human brain is very triggered by color and immediately notices the bad blocks

which are the files we had missing from the system. So that's an easy way to show where you find problems. You can also provide an overview of an enormous amount of information.

This is 50,000 lines of code, this is a system. And well, you take a look at it and there are immediately a few things which are interesting. This is a part which seems to have a very regular structure.

That's right, that's the refactoring browser notes part, which is very regular. Other parts are very complex, high, something wrong. The highest tower is morph, which is a very complex class.

When I look at code, which is large, maybe complex, absolutely,

so large in terms of lines of code, classes, that still not makes it clear to me if it's a problem for me. If that code never changes or is not often used,

then it might not be a problem. If I only have one measurement dimension where I'm looking at this code, then I cannot say if it's a problem. I always have to look at multiple dimensions

to find out if this really is a problem. Of course, larger code is more of a problem, but not necessarily a relevant problem for me now.

A good example for that in Delphi is VirtualTrees. VirtualTrees is a nice widget component, which is the red part in this. It can do lots of things, so it's very large. It's 1.4 megabytes of source. This is a one point description of the interface only.

So it's complex. If I want to know if I should be using this component, just knowing that it's large doesn't help me much.

I take a look in the news group to see if there are many bugs reported on this component, how many users are there for this project, and how many people are maintaining it. Then I get a better idea of if this is a problem.

So just looking at the one dimension size doesn't help me. I need to do something else. And what kind of things I need to measure

depends on the kind of problems I have. This is a Delphi project where we show the forms, which is the visual components, and for that we decide to have four different measurements.

The edges show the inhabitants, so this form is based on that one, and it's based on that one, all up to the T-form. The next thing shows that a form has some methods.

The color tells me something about the complexity of those methods, and the height of each inner block tells me how large it is in terms of lines of code. This is a typical Delphi problem. In Delphi, people can write event handlers directly in the forms.

So we see here that that happened here, and we see that it did not happen with a few of the blocks to the left, which have little complexity. If the complexity is white or yellow, then it probably means that they only had a guard there saying when the event should be triggered,

and then they delegated to the model what should happen when that event was triggered. So if a button was clicked, then there might be a guard telling me that only something should happen if some condition is true,

and then that model actually must have clicked. Here it's about 100 lines of code doing something, lots of things, which makes it difficult to change this code. So the complexity... The cyclomatic complexity.

What is cyclomatic complexity? Cyclomatic complexity increases with loops, with if-then's, so if you have them there, they will be larger than that. And normally good form code in Delphi is supposed to only test at the beginning

if you have some guards which should be true, and then it should just ask another object to do the thing it needs.

This is of course only interesting for code where we need to make changes. If it's code which is not going to change and you are just going to use it like it is for the next 20 years, then we are not talking about this problem. But normally we need to adapt to new requirements.

We need to be able to move to new platforms, and the code needs to be open to new developers who have to replace people who are retiring. In the case of Delphi, we have older style Delphi which has to move to modern style Delphi,

where there was an old library, VCL, and it's moving to BioMonkey. The database support changed a few times in the different versions, and that needs different code. The latest versions of Delphi support mobile, and of course we have the things we have everywhere

that we move from ANSI to 64 bits and unique code. So do you only analyze the Delphi code, or do you also have the tools to rewrite the code? We are currently at the point where we have the analysis working,

and are moving towards effecting support. Test ID, yeah. So when we find Delphi projects, the most important things we have to do with the code themselves, which are independent of the version of the code,

is the removal of duplication, moving of event handles to the domain objects, and making sure that you have a unit test, and move to a hexagonal architecture to have better maintainability.

For migration support, we took a look at the work that the original authors of the Effectoring browser did with MaxiC. They wrote a paper where they showed that they could migrate a 1.5 million line of Delphi code project to C-Sharp

in about 18 months with four people, which is about 10 times better than we would expect if you just do a rewrite. So we are looking at copying that, basically. Good.

Now we can see what we did. So we have a mouse model for the file.

Then we see that it starts parsing. And this is a very small sample for the demo. So we can already do some visualization to see what of this code we already understand.

As we are building this Delphi parser to make it possible to import this, we wanted to see which units we could read, what dependencies we had, and what we didn't understand.

So here you can see that the green files are well read. The top part is the interface. So in the interface, we have the small blocks, which tells us how many classes there are. Below that, there may be an implementation that was met.

And the orange files are the ones which we did not find. Well, that's also shown on the left-hand side. And the red ones are the ones we have parsing errors, which are to be expected because we did not define any of the ifdev code, which helps us switch between, for instance,

Windows and Linux support. So that would be things that would not parse us. So if I take a look at this,

then we can see that we have two forms. And we have this same... This is the same picture, but this is a very simple one. So we have only one form depending on...

And it has two event handlers, which are simple, which is nice. Unlike in the other projects.

If you now take a look at the source, which is part of this, then you can see that this visualization helps us navigate to the code very fast.

We have this yellow method. That's this method, and we can see that the complexity is not very high, but it is still about the maximum that we want.

And with the red one, we can see that we have here an if statement and a for statement. And that's supposed to be more complex than we should have

in the method of the classes.

And here we see dependencies at the unit level and we see for each unit the size of the classes

where the number of methods is in the horizontal direction and the number of lines of code is in the vertical direction. It is very easy to make these kinds of pictures. They are mostly about a hundred lines of code.

So we often make a lot of them before we find something which helps us show something interesting. So, this was what I wanted to show. Oh no, that's one more video.

That's the part where... This is the part which did work on my machine at home,

but not on this laptop. So that's something I will fix. We can not only do two-dimensional pictures, but you can also do the three-dimensional ones. This is the picture we showed before

where we have the three-dimensional view of the whole system, the whole HAVOC system, and we can move through that and take a look at it, select elements, and also show something about those elements.

And we also just recently, last week, managed to make the same kinds of pictures for a Delphi model. We exported the data.

So this is a picture of the same model. It's a code city model where the grey blocks are the units

and these are the classes. And we showed here that we have different kinds of measurements. We have done up to 20, and we have selected three of them to show in this picture.

It's not the right ones to show because you don't see anything interesting from this, but that's mostly because we don't have the right measures for that.

Good. Thank you. Any questions? Is there no inheritance information in this one? No, I have not put the inheritance information in this one. I could, but no. This is just something which we made work last week.

So the important thing was that I was able to create the buildings and make them have nice colors. Yeah. Thank you. Any other questions? Is this possible?

So imagine you have a library.

Well, the thing we mostly start with visualizing is having the units, the classes, and the methods in them and showing how large they are and showing what all our methods they are calling,

how the dependencies are, both at the unit level and at the method level. Is that not at the code level? The code lines? In the same sense, like finding duplication?

Well, for duplication, we have different tools. We can find duplicates and can find duplicates who are templates, or template-like, so have a slight difference or have a few lines between them,

and we have tools that I'm not sure of. That's based on Dukes by Deepak Vettel, I think.

This is, well, the CD thing is not yet open, so we'll talk about it, but the parser is part of the Moose project, so you can download the Moose image and run the configuration of the parser up in Delphi and then you can import Delphi code.

Talk to me afterwards, then I'll write it down. Yes? Have you tried the, have you tried the Moose on the 3Pascal or Lazarus project? Not yet. Well, we need to change the parser for that.

The language is a bit different, and we noticed that we have now a larger parser than the Java parser. Didn't know that before, but the Delphi language is larger than the Java language.

Are you aware of anybody using Moose for Fortran? Fortran, Marcus? I don't think so. COBOL, there is a COBOL support for Fortran, I think. Maybe something older, but some years ago someone did something.

Yeah, but we now know how to do that. Now we built some COBOL support and things, and we did Delphi, so we can also do Fortran. But that's a question of building a parser, making sure that you have the name resolution right, so you can find which method call is calling what.

It takes some time, but it's doable, and it helps a lot with refactoring the project. How much time did it take you to write a parser for an adult?

That's about two months now. But then you don't have the name resolution yet.

Depending on how good it has to be. Good. Thank you very much. Is it mixed?

Yes. I think we need to close the door. We need to close the door. Oh, then we can open the door.

This one?

So, time for the next presentation.

Walter Gassenden is going to tell us about a modern new small talk, Gravel.