International Pascal Congress 2023

[Joanna]

To me it is easier to understand a lot of small functions each having a single purpose, than a large function that does many different things.

I do almost exclusively object oriented programming and use classes for most things. I think it is a good thing to not let any part of a program get too large and complicated. A previous version of my project had the factory and layout manager combined into one unit. Although it worked ok it was too large and complicated and someone suggested that I separate the functionality which I did.

In my opinion using procedures and functions primary purpose is to consolidate all identical code in one place.
For simplifying code inside a procedure with a nested procedure or function, the nested procedure could handle some of the code used inside of a loop which would make the code for the loop easier to read because it’s calling a procedure.
Sometimes I’m just struggling with code that is too complex and break it into small pieces to better understand what it is doing inside a procedure.

How long a procedure should be varies for different people. I don’t much care for doing a lot of scrolling so most of my files are fairly small. If you don’t need to do much with the code of course it could make sense to have more code in less files.

[sketch]

In Clean Code: A Handbook of Agile Software Craftsmanship, Robert Martin says:

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should hardly ever be 20 lines long.

Harold Abelson of The Structure and Interpretation of Computer Programs fame:

Programs must be written for people to read, and only incidentally for machines to execute

Martin Fowler whose 1999 book Refactoring popularized code refactoring:

If you have to spend effort into looking at a fragment of code to figure out what it's doing, then you should extract it into a function and name the function after that “what." Once I accepted this principle, I developed a habit of writing very small functions - typically only a few lines long.

The "Rule of 30" in Refactoring in Large Software Projects by Martin Lippert and Stephen Roock:

If an element consists of more than 30 subelements, it is highly probable that there is a serious problem:
a) Methods should not have more than an average of 30 code lines (not counting line spaces and comments).

[Bogen85]

Martin Fowler whose 1999 book Refactoring popularized code refactoring:

If you have to spend effort into looking at a fragment of code to figure out what it's doing, then you should extract it into a function and name the function after that “what." Once I accepted this principle, I developed a habit of writing very small functions - typically only a few lines long.

Much longer than that and they get very hard to fully unit test, regardless if those are methods or standalone functions.

[Bogen85]

If you think of a program as a dictionary, and functions and methods as some of the definition types in that dictionary (akin to words in a natural language dictionary), it would be hard to maintain and understand if every word had a several paragraph or several page definition.

[Bogen85]

Kevlin Henney also has few things to say about this:

https://www.goodreads.com/author/quotes/45368.Kevlin_Henney

“Instead of commenting sections in long functions, extract smaller functions whose names capture the former sections' intent.”
― Kevlin Henney, 97 Things Every Programmer Should Know: Collective Wisdom from the Experts

“Next time you are tempted to lump a few things together into one API method, remember that the English language does not have one word for MakeUpYourRoomBeQuietAndDoYourHomeWork, even though it would be really convenient for such a frequently requested operation.”
― Kevlin Henney, 97 Things Every Programmer Should Know: Collective Wisdom from the Experts

[Joanna]

Sketch those are some common sense concepts for sure.

Quote
Programs must be written for people to read, and only incidentally for machines to execute
 

This is the reason I prefer pascal to all other programming languages. Pascal is easy to read because of its English like syntax. There are far too many people who think that a programming language should be as terse as possible. Curly braces make a poor substitute for a solid begin end..

It is much easier to think of solutions to complicated problems in English and then translate it to pascal. The idea of small single single purpose blocks of code is by no means limited to functions and procedures. I use a lot of frames that alone don’t do very much and are easy to test but combined with other frames become quite powerful.

I think the optimal length of a procedure could be influenced by what you are trying to do but if it doesn’t all fit on one screen it begins to be more difficult to read.

[440bx]

All the pontification some book authors do about "small functions" sounds very good but, the claims are very rarely accompanied by solid reasons to justify them.

A function should accomplish a logical task, if that task can be done in 20 lines of code, great but, if that logical task takes 2,000 lines then 2,000 lines is what it takes.

The more code is broken into "pieces" (call them functions, procedures, methods, doesn't matter), the programmer has to "visit" that code (meaning jumping to them) and mentally assemble what all those pieces do.   A large number of small functions creates "jigsaw puzzle" programs that the programmer has to assemble.  OOP is notorious about creating that problem because many methods have no logical function, they only exist to be overriden thereby exacerbating the problem.

The more pieces a program is broken into, the more information has to be passed around among the pieces and that is often a problem (again, this problem manifests itself in OOP in a number of ways and OOP often makes it worse.)  More things for the programmer to have to keep track of, that makes things more cumbersome and more error prone.

Anyway... as someone has already pointed out, this thread is about an International Pascal Congress not about what programming should or shouldn't be but, I find it difficult not to express my strong disagreement with unsupported, mostly baseless programming dogma because it sounds "kewl".

[balazsszekely]

@440bx

Anyway... as someone has already pointed out, this thread is about an International Pascal Congress not about what programming should or shouldn't be but, I find it difficult not to express my strong disagreement with unsupported, mostly baseless programming dogma because it sounds "kewl".

This thread like many others derailed to a great extent. Anyways about programming dogma:
There is a well know theory about structuring a relational database in normal forms, the so called database normalization. The idea is to reduce data redundancy via normalization, great in theory but assumes infinite computer power. Start with a perfectly normalized database and watch how miserably fails as data grows.
The bottom line is theory <> practice. In my opinion this is also true about any programming paradigm, it all depends on the specifications.

[tetrastes]

Sketch those are some common sense concepts for sure.

Quote
Programs must be written for people to read, and only incidentally for machines to execute
 

This is the reason I prefer pascal to all other programming languages. Pascal is easy to read because of its English like syntax. There are far too many people who think that a programming language should be as terse as possible. Curly braces make a poor substitute for a solid begin end..

It is much easier to think of solutions to complicated problems in English and then translate it to pascal.

It seems you believe that every one person on Earth speaks (not to say thinks) English. 
For those, who don't, curly braces are better, as they can name them in native language.

[PascalDragon]

But, this is way off topic in regard to the International Pascal Conference 2023...

Perhaps, although this side discussion highlights a blurred distinction between the Pascal language philosophy and general programming best practice.  And I believe this is due to a nonexistent modern Pascal language philosophy, or alternatively a missing up to date language specification.

Let's hope the congress can come up with the next standard that might start a legal battle with Embarcadero. It's hard to move together when you rely on sales of development tools to live.

This isn't the task of the congress and even then there is no reason or obligation for neither Embarcadero nor FPC to follow such a standard. After all there already are two language standards for Pascal and they got largely ignored by history (though FPC nearly completely supports ISO Pascal and support for ISO Extended Pascal is supposed to be added piece by piece).

[Joanna]

It seems you believe that every one person on Earth speaks (not to say thinks) English.   

I certainly don’t. I’m sure programmers think of code in their own native languages. Regardless of that it doesn’t hurt them to learn the reserved words which happen to be in English. I’m not sure how this happened but I’d prefer a “begin end” in any language over curly braces.

A large number of small functions creates "jigsaw puzzle" programs that the programmer has to assemble.  OOP is notorious about creating that problem because many methods have no logical function, they only exist to be overriden thereby exacerbating the problem.

Using Oop correctly definitely takes skill and it isn’t for everyone.
It is true oop can be more complicated that non oop programming however there are many advantages to using oop when it comes to organizing and reusing code. Oop organizes code in ways that for me at least are easier to understand.
I try to use methods in the base class to perform the most useful default behaviors but this isn’t always possible and I sometimes do end up with empty methods in base class. I consider getting rid of empty methods a goal to work towards with better design.

[dbannon]

A function should accomplish a logical task, if that task can be done in 20 lines of code, great but, if that logical task takes 2,000 lines then 2,000 lines is what it takes.

The more code is broken into "pieces" (call them functions, procedures, methods, doesn't matter), the programmer has to "visit" that code (meaning jumping to them) and mentally assemble what all those pieces do.   A large number of small functions creates "jigsaw puzzle" programs that the programmer has to assemble.  OOP is notorious about creating that problem because many methods have no logical function, they only exist to be overriden thereby exacerbating the problem.

On the other hand 440bx, I'd absolutely hate to have to try and understand someone's (even mine after a week) hyperthetical 2K line function. Almost any task can be split into logical steps, even if those steps are used once. Give each step a reasonable name and suddenly we have "abstracted" away a lot of the detail. So, the code now looks like

Code: Pascal  [Select][+][-]

1. LoadData()
2. CheckData()
3. ProcessData()
4. DisplayData()
5. SaveData()

If I see that, and know the problem is that the data looks OK when displayed but is not being saved, I can skip 80% of your 2000 lines and just look at the 400 lines.

The more pieces a program is broken into, the more information has to be passed around among the pieces and that is often a problem (again, this problem manifests itself in OOP in a number of ways and OOP often makes it worse.)  More things for the programmer to have to keep track of, that makes things more cumbersome and more error prone.

Absolutely, but that would be an argument for making all our variables global too 

Davo

[440bx]

On the other hand 440bx, I'd absolutely hate to have to try and understand someone's (even mine after a week) hyperthetical 2K line function.

I have functions that are 2000+ lines of code and I find them very easy to maintain because execution is linear. I read/execute the code from top to bottom without any jumps and it's really easy to keep track of what has happened and what should happen next.

I've thought about what those functions would look like if they were split into smaller pieces and the result would be a difficult to understand mess of code.  The pieces would lack the coherency of the code when it is in one block.

Almost any task can be split into logical steps, even if those steps are used once. Give each step a reasonable name and suddenly we have "abstracted" away a lot of the detail. So, the code now looks like

Code: Pascal  [Select][+][-]

1. LoadData()
2. CheckData()
3. ProcessData()
4. DisplayData()
5. SaveData()

Think of it this way... each function/procedure name is a comment that says what LoadData, CheckData, ProcessData, etc do, each followed by the (estimated/averaged) 400 commented lines of code their implementation takes. The beginning and end of each "function" is made clear by comments to that effect. Note also that comments  inside a "function" can refer to actions that are being taken to set things up for code that is executed in another "function" (a comment in CheckData that is setting things up for something in DisplayData)  This kind of "forward comment" is counterproductive/confusing if the code is broken in discrete pieces. 

Absolutely, but that would be an argument for making all our variables global too 

On the contrary, the objective is to increase/maximize locality.  There is nothing more local than inline code.

The real downside of having long functions/procedures in Pascal (or any other language that doesn't support local scopes) is that the function/procedure usually ends up having a fairly large number of local variables (which are globals in the function) that wouldn't happen if there was support for inline scopes, the majority of the variables would be local to the scopes usually leaving less than a handful at the global function level.

It's interesting you mention global variables because one of the problems I have with OOP as a programming paradigm is that it spreads global variables all over the places.  Every field in a class is, pretty much, a global class-instance variable accessible by every method in the class and it is quite common to see groups of fields that "belong" with some methods and definitely don't belong with other methods but, those methods still have access to them.  The problem with having class-instance fields is so noticeable that they are by convention prefixed with a letter "F" to distinguish them from real local variables.

Again, I know I'm not going to convince anyone and actually, I'm not even trying to convince anyone, I just want it to be known that my dislike of OOP isn't capricious, it has a solid and large foundation (not that it will make a difference, it won't.)  Also, I should mention that, because of habit, I occasionally make functions out of code that should be inline, IOW, I'm not completely immune to programming dogma.

Lastly, in the 47 years I've spent programming, the one thing I've learned is that the most important activity when writing code is lavishly commenting the code.  What is brutally obvious when one is writing the code becomes an enigma six months (or less) later.   The comments should be a tutorial for how to solve the "problem"/"get the task done" because, any programmer, even the original author will need it a few months (or years) later.

I estimate that a program is reasonably well commented if _at least_ 1/4 of source lines are comments and, I mean _quality comments_ not, "this is a variable, this is another variable" ... those are not comments, that's junk. <chuckle>

Apologies to Sergio for hijacking the thread... it wasn't my intention.

[Joanna]

Every field in a class is, pretty much, a global class-instance variable accessible by every method in the class and it is quite common to see groups of fields that "belong" with some methods and definitely don't belong with other methods but, those methods still have access to them. 

Putting variables inside of a class encapsulates them so that there is more control of how they are accessed from outside of the class. Also if you only want certain class methods to access class variables you could put the variables and methods which access them in an ancestor class and have them private or protected .

Oop is probably not for everyone or every type of project but for things things like frame classes I find it useful.

[Sergio MT]

Dear Pascal-world colleagues,
I’m bringing you news I think you’ll like. I can announce the invited speakers who will give a plenary talk in the International Pascal Congress 2023. The invited speakers and their plenary talks are the following:

Dr. Johannes W. Dietrich:
Title: “Systems Endocrinology – Shaping an Emerging Medical Discipline with Object Pascal“

Michael Van Canneyt
Title: "Free Pascal: Past, Present and Future."

Marco Cantù
Title: "Delphi's Object Pascal Evolution"

Dr. Michalis Kamburelis
Title: "Developing games and graphic visualizations in Pascal"

Primož Gabrijelčič
Title: Parallel programming in Pascal: How we should stop focusing on threads and start writing functional code

Bruno Fierens
Title: "Object Pascal everywhere"

Daniele Teti
Title: "Developing frontend and backend in Pascal: past, present and future"

The International Pascal Congress (IPC) will be held from July 3 to 7, 2023, in Salamanca, one of the most beautiful cities in Spain and a UNESCO heritage site. The event will serve as a meeting point for all players in the software industry working with Pascal, and we’re aiming to boost the Pascal community into becoming an innovative and cutting-edge community again. You can find more information about the event on the website https://pascalcongress.com More news coming…