Möbius: Pascal without begin/end?

Möbius stripOne recent announce of MSELang by Martin Schreiber reminded me of something I’ve been mulling over, code name “Möbius” which would be Pascal without begin and/or end.

Before you prepare the tar and feathers, read on, and vote at the bottom, if you get there 😉

Pascal is a verbose language, that’s why we like it, but sometimes it can be a bit too verbose with the begin/end, and some format conventions (with begin/end on their own line) make it huge. Personally I was raised on C, so I use the C-like format (with begin at the end of the previous line) which is a bit more compact, but still verbose

Also it’s not very consistent. Some constructs require begin/end for multiple lines (while, for, if/then/else), while others don’t (repeat until, case of else, try except, try finally, class declarations, record declarations).

The cases where begin is optional are those where you can get away with a single statement, but they break the visual balancing of indentation.

To get rid of the begin/end, there are basically two coherent ways:

  1. drop the “begin”, but make “end” compulsory, this is the route Martin chose for MSElang, and it has merit. Everything stays well balanced. The inconsistencies are gone, and it adds very little “end” verbose-ness in practice while eliminating a lot of “begin” verbose-ness
    while whatever do
       ...something...
       if someTest then
          ...do something...
       else
          ...do something else...
       end;
    end;
    ...further code...
  2. got for indentation-based blocks (like Python), where a block of code is determined by its indentation, rather than delimiters.
    while whatever do
       ...something...
       if someTest then
          ...do something...
       else
          ...do something else...
    ...further code...

One refinement that the first form (drop begin, keep end) allows is to qualify the end, f.i. rather than just “end” the compiler could allow “end while” for a “while” block, “end for“, “for” a for block, etc. The syntax could be extended to existing begin-less constructs (“end except“, “end case“, etc.)

For small blocks such qualifications are useless, but in more complex cases, they can come in handy, and avoid the (too often misleading) practice of adding a comment after the “end” for qualification purposes.

So what say you?

Pascal without begin or end

  • Heretic! I can't live without begin/end (51%, 168 Votes)
  • Dropping the "begin" could be nice (35%, 116 Votes)
  • No begin or end, indentations ala Python (14%, 48 Votes)

Total Voters: 332

Loading ... Loading ...

 

46 thoughts on “Möbius: Pascal without begin/end?

  1. 1) This removes a begin from large blocks and adds a mandatory end to all short one-liner blocks.
    So in case the goal is removing verbosity this one doesn’t work. Not convinced.

    2) I don’t think that indentation generally works too well. It’s way to fragile. Also Include-Files might cause a headache there – you can’t just insert the code like a simple preprocessor. You have to make your parser aware about the indentation-level of include-files…

    Pascal was created by quite clever people. Changing the way it works is rarely a clever idea.

  2. Eric, sorry to see you lose your precious time on this garbage.
    If you will not make Smart the nextDelphi, soon we will be remember Pascal and legendary begin/end statments only in the old and the apocalyptic zombie movies and historcal books…..

  3. > This removes a begin from large blocks and adds a mandatory end to all short one-liner blocks

    On the other hand one-liners like “if xxx then yyy;” are a PITA debugging-wise, and should be avoided. And if you place the “then” on a new line, then it’s feels weird when it’s not balanced in a block.

  4. I took Andreas to mean:

    if xxx then
    yyy;

    And would hate to have to make that:

    if xxx then
    yyy;
    end;

    Yes, sometimes the code is cluttered with begin/end pairs, but perhaps that is just Delphi’s way of reminding us that small is better?

  5. We already did this long ago. It was called Modula-2. Nikolas Worth corrected many of the errors in Pascal. No single/compound statement differentiation. Case sensitivity. Proper modules and imports that allowed encapsulation.

    But Python does it better still. The human eye reads the indentation so we may as well make the compiler do the same.

  6. @Andreas The clever person that created Pascal realised that he got some things wrong. Look at what Nikolas did next. Your argument falls over. As for indentation being significant, it has been proven to work well. Impossible to sustain that argument in the face of contradictory facts.

  7. making Pascal less verbose is an excellent idea and deserves admirations. I vote for getting rid of begin/end or at least renaming to something less obtrusive. The begin/end hell is the reason I adore all those breaking the normal codeflow keywords like: exit, break, continue. They save me from the visual garbage.

  8. If you don’t like begin/end, I mean really don’t like it, so much so that you are contemplating changing the language, it is probably time to switch to C#.

    There are much bigger fish to fry out there.

  9. I actually really like the verbosity of begin end – eventually it’s just me but I like fluent reading of the code.
    Even when I program C/C++ I tend to use extra lines for the { } . I myself just need to have simple lines
    I can evaluate in my mind. Everything that condenses code too much is (at least for me) hard to read.

  10. In the grand scheme of things, I don’t see these kinds of changes as necessary. As an intellectual exercise, sure, but as a practical matter not so much. I definitely don’t like the idea of using python-style indentation. If I liked that, I’d be using Python, which I don’t.

  11. I agree that use indentation is the worst thing. Old languages (FORTRAN, COBOL…) used that, but modern versions of that languages dropped it time ago. I don’t understand why “modern” languages like Python still uses such obsolete feature.

    About dropping BEGIN, then Pascal will be quite similar to QuickBASIC. That’s not too bad. Actually I thing QuickBASIC is language with nice ideas and goot to start with programming (much better than later VisualBasic, at least ’till VB3).

    And yes, Wirth fixed a lot of Pascal “mistakes” with Modula, and later with Oberon.

  12. Removing those keywords won’t change anything about there being no new begin for Pascal and it is reaching it’s end

    Sorry, I had to.. :^)

  13. @Modula-2 fans: Whether young Nikolas or old Nikolas was more clever is still an open question…

  14. @David:
    No single/compound statement differentiation. Case sensitivity. Proper modules and imports that allowed encapsulation.

    Well, two out of three isn’t bad. Case sensitivity is evil and needs to die in a fire.

  15. @Mason I disagree regarding case sensitivity. What’s your problem with it? Most languages choose case sensitivity and don’t seem to suffer as a consequence. Are you concerned with people writing methods like:

    procedure DoSomething(…);
    procedure Dosomething(…);

    and thus setting traps for consumers of the class? Of course, nobody would be insane enough to do that.

    My reasoning is as follows. When any Pascal coder writes code they try to make sure they use the same letter case consistently. So nobody writes

    SL.loadfromfile(…);

    Instead we always string:

    SL.LoadFromFile(…);

    Since we humans care about this we may as well get the compiler to care about it and force us to do what we already want to do.

  16. @C Johnson Then the begin is pointless. It carries no meaning. Pascal may be verbose, but syntax always carries meaning.

  17. Dropping Begin/End is fine with me. While you’re at, drop semicolons too. Well, make them optional so that they can still be used to put multiple statements on a single line. e.g. X=1; Y=2.

    As for case sensitivity in the language. No Way!. Too easy to obfuscate code. Source code is for humans to read, not machines. In a case sensitive language result and Result may be different to the compiler, but easily missed by a human reader.

    Clarity in source code is much more important for reading than it is for writing, because you (and others) will read it many more times than write it.

  18. Without a thought vote to remove begin end pairs or make them not obligated.
    Make it a feature of next gen Pascal language. Easy to write, so to understand.

  19. @David: The best argument for case insensitivity is that it prevents the abuse of case sensitivity. Not just with the example you described, but ugly things like using a different-cased version of a type name as a variable name. When I see a declaration like “HWND hwnd;” or “Map map = new Map();” I just want to smack whoever wrote that. It would be like if someone called you “human” instead of “David.” 😛

  20. WRT Case Sensitivity, my preference would be case insensitivity, but with imposed case, ie. if you declare “myVar”, then you have to use “myVar” (using it as myvar is an error), and declaring a case variant “MyVar” is another error. You’re free to call it pedantic strictness 😉

    Visually, case sensitivity is important, but for those of us that think in audio, case insensitivity is important as well.

  21. @Eric – About casing, a warning if there was a case mismatch from declaration would be the best I think. I just looked in XE3 source and found about thousand declarations of “integer” variables, where the correct declaration would be “Integer”.

    With an option to turn it on in specified units.

  22. The argument in favour of Python type indentation is that the compiler will compile the way you think it’s compiling, when you “look” at the code.

    I too, thought it was very weird, very old, very stupid, very Cobol. But then I had to use Python and it just worked. What I saw in front of me, logically, is exactly how I wanted it to be, how I intended it to be compiled, and the compiler got it without me having to add begins, ends or brackets. I realised then that it just worked.

    However, case sensitivity. Ugh.. I consider case sensitivity in languages to be the worst idea ever, a hang over from ancient C that stuck for no good reason at all.

    Stefan Glienke: Python accepts 2 space indentation. 1 also works.

  23. Sure `begin` after `do`, `then` and `else` is very annoying thing in Pascal syntax. When I write something more complicated than Writeln(‘Hello World’); I usually write a `begin end` block after `do`, `then` and `else` even if the block containes a single statement because it easier to maintain – you may need to add more statements into the block while working with the code. And yes, this improved syntax is called Modula-2.
    It this Modula-2 syntax could be supported by future Pascal compilers as an option that would be great.

  24. @Mason I quite like Map map = new Map(); although var map = new Map(); is perhaps better. But if you don’t like it don’t feel compelled to do it. I still believe that programmers are sentient beings and are capable of making their own decisions. I’m a libertarian in that regard.

    My philosophy in general is that I prefer it if the compiler can check the things that I care about, and I care about getting the letter casing consistent. So it would be better in my view for the compiler to check that.

    I’d regard Eric’s insensitive with imposed case as better than what we have now. But personally I like case sensitive.

    FWIW, Modula-2 resulted in pretty eye popping code because the reserved words were ALL CAPS. So you had:


    IF someBool THEN
    DoSomething();
    END;

    which I never ever got used to.

  25. @David

    “My reasoning is as follows. When any Pascal coder writes code they try to make sure they use the same letter case consistently. So nobody writes

    SL.loadfromfile(…);”….

    You are putting to much trust in humans and programmers. I see trash code everyday (some I write myself from time to time :)), mixed indentations, inconsistent case usage. Truly I have seen the same developer write loadfromfile, LoadFromFile and loadFromFile in a same unit 🙂

    So I am ok with case insensitivity. Never had any problems with it. As for begin end, I am for it. For a single reason that it makes things more readable for me. Its encapsulation, that is why I always write begin on the next line so it forms a block of code with end. It is very important for me as this way I can visualize code a lot better. Python type of indentation as part of code is a nightmare for me.

  26. @David H. “I still believe that programmers are sentient beings and are capable of making their own decisions.”
    Yes, but when reading their code, it can lead one to believe that some of them are of extraterrestrial origin.

    Regarding all caps keywords. I’ve worked with a few languages that it was all caps for everything other than quoted strings. Perhaps surprisingly, I don’t find it difficult to read, and there certain advantages to it. Since everything is caps, one can type only having to use the Shift key for symbols, and quoted strings intended for output. One is also never subjected to strange implementations of camel casing in variable names.

  27. @Itzok But my suggestions would solve all those inconsistencies that you mention!! You complain about inconsistent letter case and sloppy indentation. Case sensitivity and significant indentation solve those problems.

  28. I don’t think remove begin/end is a good idea. Pascal is loved because its readability even no comment. Each refinement shall keep this principle.

  29. @David

    Ok, I can agree with you on case sensitivity. It would solve problems that I described, but I still stand that begin / end is more readable. I did not consider that then everybody would be forced to write correct indentation. This would be a huge plus as I hate different indentations in the code. But on the other hand I really, really like that code wrap feeling that begin / end gives you. I also write { (same as begin in pascal) on the next line in javascript for the same reason.
    I would have to get used to loosing that.

  30. Just by looking at the poor/wrong indentation of some of the coworker’s source codes I’ll vote for “don’t drop begin end” 😉

  31. @Dennis The whole idea is that by dropping begin/end, the programmer is forced to indent the code properly. You never see sloppily indented Python code because it doesn’t work!

  32. So…
    – No begin, but mandatory end.
    – Not case-sensitive, but case-aware (iow: the declaration of an identifier determines its case)

    That’s exactly how Visual Basic (at least up to 6) does it… 🙂

  33. If Delphi had a pre-processor we could define our own alternatives for begin/end and do many other interesting things as well.

    For example,

    #define “{” Begin
    #define “}” End

  34. The “begin” statement as well as bracketing is a horrible waste of space and time. It has zero practical purpose and should be eliminated. The end statement makes sense as it blocks a subset of code making it more readable. Using a bracket would be acceptable but not very readable. No end statement/bracket causes more coding errors in my experience.

    As for how VB worked, it had no line terminator which made multi-line statements horrible. A modern language works better with a line terminator but doesn’t need an extra statement/bracket to determine the beginning of a code block.We already have that statement such as “for”, “while”, “try”, “repeat”, etc.

    Pascal without that would be a far more eloquent language.

  35. @Cameron: The problem with VB wasn’t that it didn’t have a line terminator. The line terminator was CR or CR/LF to be entirely accurate.

    The problem was it didn’t have a simple escape to indicate the next CR was *not* a terminator, al la \
    as is common in other languages. That simple addition would have solved it all 🙂

  36. @David:
    >We already did this long ago. It was called Modula-2. Nikolas Worth corrected many of the errors in Pascal.
    >…But Python does it better still. The human eye reads the indentation so we may as well make the compiler do
    >the same.

    You’ve just stepped on some live wires! By definition, anything I say in the Embarcadero Delphi forum has to be disagreed with by the regulars. 🙂 Recently I made positive comments about Modula-2 and its spiritual successor Modula-3 (Wirth didn’t personally work on this but blessed its development). Some people replied that Wirth should have “left well enough alone” and there was an indignant claim that Delphi advanced Pascal far more than Modula-3 ever did… which is ridiculous considering Modula-3 gave the language a form of generic programming in 1989 vs. 2009 for Delphi and also garbage collection which we still don’t have on the desktop today.

    I also frequently compare Delphi to Python (which I sometimes call Pascal++) so you’re going to initiate a flood of anti-python comments now. 🙁

    That said, I completely agree with you. There seems to be some sort of emotional/religious attachment among many Delphi users to begin/end and case insensitivity. Take any Pascal program and remove all the indentation. It can be read… with great difficulty. Take the same program and remove the Begins and Ends. It can be read just as easily as before. If you’re indenting, the Begin/Ends are superfluous. If you’re not indenting your code, then you should be as the Begin/Ends alone don’t help much for readability.

    As Raymond Hettinger has said, “In Python, the indentation doesn’t lie to you.” You never have to worry about something like:

    If x < 7 Then
    y := 3;
    z := 4;

    doing something other than what it looks like.

    I voted for the significant indentation. Plus, if approved, to borrow an example from Guido Van Rossum, it'll still have Begin/Ends….

    If x < 7 Then
    //Begin
    y := 3;
    z := 4;
    //End

    😉 😉 😉

  37. @Stefan:
    >As someone that hates reading code that does not use indentation of 2 spaces I would go crazy if indentation
    >would be used like in Python.

    While the Python style guide calls for 4 spaces, there’s nothing in the language preventing you from using any amount of indentation you like, only that code within a block possess the same level of indentation.

    @Anders:
    >If you don’t like begin/end, I mean really don’t like it, so much so that you are contemplating changing the
    >language, it is probably time to switch to C#.

    I admire Eric’s unceasing drive for improvement. “Love it or leave it” doesn’t make the language better. You could have made the same statement about love generics = switch to C++, love iteration switch to Python, etc. for many of the improvements Embarcadero and Borland have made to the language over the years. Eric’s not afraid to challenge sacred cows and if EMBT was sold to me tomorrow I’d offer Eric the role of chief scientist without a moment’s hesitation. As is, I still see a theoretical future combination of DWScript, Eclipse and/or VS plugin and Qt bindings as being a potential Delphi killer or successor.

    @JDemartino:
    > If I liked that, I’d be using Python, which I don’t.

    You’d choose a language tool based solely on its block delimiter scheme???
    “I’m not used to X” isn’t a reason not to do something, otherwise we’d never change anything.

    @Nuno:
    >I agree that use indentation is the worst thing. Old languages (FORTRAN, COBOL…) used that,
    This is not correct. While significant indentation did first appear in some older languages, they were academic languages and never had any commercial success. Fortran uses “ENDIF” to end “If” blocks. Indentation is not significant in Fortran. I had the displeasure of coding some COBOL, which you are forcing me to remember now. 🙁 COBOL had some specific column requirements, but this had to do with its origination with punch cards! This was also the reason for its section numbers – in case the cards got out of order. Today’s COBOL doesn’t have these indentation requirements.

    >I don’t understand why “modern” languages like Python still uses such obsolete feature.

    Python pioneered significant indentation in a mainstream language and it is often hailed as one of its most important features and a stroke of genius on Guido Van Rossum’s part. In fact, Haskell adopted optional significant indentation (also called “off-side rule”) based on its success with Python, and I think Erlang has too. It makes code easier to read and makes things simpler for new programmers to understand. In fact, there’s a paper on the web in which the author discusses the differences between teaching a CS1 course with Delphi and with Python and 3/4 of the students at the end preferred Python, actually citing not having to worry about all the begins, ends and semicolons as their top reason!

    The irony is that it’s Begin/End that really is an old feature, hailing back to dead languages like ALGOL. It’s an evolutionary dead-end, as Paul Graham might say, and no language other than Pascal ever adopted it.

    @David:
    >My reasoning is as follows. When any Pascal coder writes code they try to make sure they use the same
    >letter case consistently. So nobody writes
    >
    >SL.loadfromfile(…);
    >
    >Instead we always string:
    >SL.LoadFromFile(…);
    >Since we humans care about this we may as well get the compiler to care about it and force us to do what we
    >already want to do.

    This is another argument raging on the official forum with myself as basically the only defender of case sensitivity. I’ve made the same argument – it’s just like indentation: if you’re doing it anyway, what’s wrong with making it a requirement? The standard response is to construct a strawman and rephrase case sensitivity as wanting to declare lots of variables with the same name and only differentiate between them by capitalization. Seriously, I gave up after the 12th reply that complained about how hard it would be read code with three different variables named something, Something and SoMeThInG in it. They’ll all agree that capitalization should be consistent in a program, then in the next breath denounce case sensitivity in languages as “the stupidest idea I’ve ever heard of” to a man. I think, again, it’s because it originated in a blog post about bad code that had a Delphi example which inspired someone to comment about more flaws in the language itself that led to the code problem, including the language’s case insensitivity. The wagons are being rallied now.

    @Adrian: +1 for mentioning Nimrod! I’d forgotten about it and hadn’t heard it mentioned in quite a while.

  38. Pascal is definitely my preferred language but I too have thought there are some inconsistencies in the begin/end requirements. I would be in favour of removing the BEGIN (except for the start of procedures/functions/methods) and I would require explicit ENDs for all statements with a variation: the end of a WHILE loop would be ENDW, say, the end of a FOR loop would be ENDF etc.

    I don’t think it is a good idea to use indentation as a blocking construct. It should not enforce it but reflect it. I also don’t like the idea of case sensitivity as that introduces problems of its own – probably less in Pascal which requires all variables to be declared before use, but still it’s a pain if you accidentally type two capitals in the name of the variable.

    In any event it is refreshing to see a proposal for a language which doesn’t look like yet another variation of C with its ugl {} and cryptic statements.

    Just my 2c worht.

  39. I would really prefer an alternative where begin is not required in cases where other “operators” can be used as a beginning.
    IE:
    if this then
    ...
    end;

    While also supporting
    if this then begin
    ...
    end;

    I would really prefer to be without “begin”, but I like how we have end, rather then to be whitespace based. I have programmed in python for years, and whenever there is a lot of nested logic, it gets harder to follow, then the same nested logic in Pascal, or in any other “bracket” based language.

Comments are closed.