"Functions should always be short" is also one of those guidelines that people treat like a hard rule. There are occasions when a 100 line function is easier to read than 5 20 line functions, or god forbid 20 5 line functions.
Stop being overly dogmatic, it ALSO leads to worse code.
One would assume that, but in practice, the predominant style is not one of many short procedures. Instead it feels that there's a preference to just inline the code unless the resulting procedure will have more than one caller.
Control structures are deeply nested and this goes on for 64 (very dense) lines. The low line count but is an artifact of how Oberon is conventionally formatted. When reformatted to mimic the conventions of languages like C, Java or Python it works out to more than 120 lines.
When I program in Oberon (recreationally) I tend to follow this style even though I would extract the same code into a separate method were I writing in Java.
Me too! I have a software in production for a client made with Lazarus 3 (in Pascal of course) and everybody loves the "Windows feel" of the Gui.
On Linux there is Gambas [1] wich is like Lazarus but for Basic.
I had a client habing trouble with and old vb6 software they where using in production. Replaced it with a lazarus app, and been running for 10 years now without problems.
ALGOL-60 was huge, in around 1960. Niklaus Wirth had a detailed proposal for the next version of ALGOL, to be called ALGOL-X.
The ALGOL committee rejected it, choosing a competing and much more complex language headed by Adriaan van Wijngaarden. This became ALGOL-68 -- and killed ALGOL.
Wirth took what was known as ALGOL-W and turned it into Pascal.
Author here. It took quite a lot of time and efforts to implement this old model. The situation is worsened by `meliad` framework. Glad to see that `meliad` is not active now.
reply