[fpc-pascal] Delphi's anonymous functions in Free Pascal

[印場 乃亜]

Hi,
On 2012/08/31, at 2:51, Jürgen Hestermann <juergen.hestermann at gmx.de> wrote:

> Am 2012-08-30 18:29, schrieb Ralf A. Quint:
> > Pascal has evolved since Wirth's original design back in the 70s
> 
> This is true. But there are two aspects of the Pascal extensions of the last years (decades) that contradict with what I would call the "spirit of Pascal":
> 
> 1.) Many "extensions" add to the learning curve of newbies (where will Pascal be in 10 or 20 years and how long does it take a pupil to learn it?). Adding extensions over and over again without much thinking will ruin the language some day because nobody will try this bloated software anymore. I have programmed with Turbo Pascal quite a lot in the 80s and 90s but when I read about the "recently" added concepts I don't understand a word (and I also never missed them!). It seems that these extensions cannot even be easily explained because the concepts are very obscure and require sophisticated knowledge about the compiler to understand them. Extensions in the past were very easy to understand and to handle.
> 
Perhaps, and I agree with you to some extent.  You can pick up Pascal and do something like:

program hello;

begin
  writeln('Hello World');
end;

hit compile, and watch it run - even now.  And that's great, but if you want to write a web browser, or an application server, or a GUI application, you need to do an awful lot of manual work in, f.e. TP7.  The first time I saw TurboVision, I thought "What a monster!", what with all those carrots for dereferencing the old style Objects, etc.  Yet writing something like the TP7 editor without OOP would have been more a of a chore chan learning TurboVision for sure.  

Anyone who says "I just want to save a value in a file" wouldn't want to learn SQL either - but once you have learned SQL, a lot more is possible.  Actually, one of the reasons I like Pascal is because you can do low level things and high-level things in the same language.  Normally I try to do everything high-level, but sometimes we have to do some dirty-work, and we can when needed.  A good example is that LCL and FPC itself is written in Pascal.  (Unlike, say, VB6, which is just  scripting language for components written in C, really).

> 2.) Many "extensions" come from other languages and break fundamental (Pascal) laws (as I would call them). For example, to me an identifier *has* to mean the same in all contexts of a program (whether declaration, function parameter, part of an expression, ..). Dynamic arrays violate this by meaning the address of a pointer or the address of the first array element depending on whether they are dereferenced or not. Pointers should be shown as pointers and not obscured. This leads to a very lot of misunderstandings. Borland should have looked for a cleaner solution for such dynamic arrays IMO. But now the sin has been commited and cannot be withdrawn. Nevertheless, no new sins should be added anymore.
> 
Well the extensions usually come because they are useful, and people have demanded them.  If you are only using Pascal, then of course, they may seem like unwanted fluff.  If you have used those features in other languages and then Pascal doesn't have them, then you would feel very limited.  For example, pascal has "With.. Do".  I use this all the time like:

With Object1 do
  begin
    size := 1;
    color := green;
    width := 84;
    Style := stNew; 
  end;

In other languages I use, I have to laboriously type;
  Object1.size = 1;
  Object1.color = green;
...

But for example, ABAP programmers who have never used pascal have no idea that they are missing this feature.
On the other hand, it would be super amazingly convenient if Pascal has the database integration that ABAP has, but most people who use FPC have no idea about this feature, so they don't know what they are missing.

The dynamic arrays thing also applies to LongStrings as well, but you should never have to dereference either in normal circumstances.

> The result is that Pascal is no longer that clear and easy to learn (yet powerful) language that it was. Of course, you can still ignore all the extensions that have been added but you cannot understand foreign code anymore (which is often necessary to understand what happens in the compiler or libraries when using them).

Well...  Understanding foreign code is difficult either way.  For example, though, I think understanding foreign code that uses standard features is easier than understanding old foreign code that fakes those features with older pascal versions that lacked a standard way of implementing the functionality.  For example, I have seen:

1. Hand-rolled dynamic array code full of pointer dereferences and malloc() calls.
2. Hand-rolled variant code full of structures with multiple interpretations and typecasting.
3. Hand-rolled generic features, full of typecasting random objects to "Pointer" or "PObject".  (This is very common in Delphi code, since StringLists, etc., can hold "Objects").
4. Hand-rolled OOP functionality with VMT in a record.... (Before OOP was introduced into Pascal).

All of these things are easier to understand if there is a common standard that people use, even if you have to learn that standard first.  For example, I don't consider myself a Java Guru, but for most basic things, there is one standard way of doing it which everyone uses, and I can look up that library to see what's going on.  That's better than trying to figure out a bunch of convoluted code where the program logic is intermixed with the implementation of features that should be in the compiler or (at least) a separate library).  

Either way, when you want to do complicated things, you will need to choose between three options
1. Implement the feature manually in code (if possible)
2. Do without the feature and write your program (if possible, may require much more effort)
3.  Have the feature implemented into the language, so that everyone can use it, and use it in the same way.

If you are only writing simple programs, though, you can of course ignore the extensions in most cases.  I personally ignore a lot of things.  I very rarely use Variants, TStream, etc.  I also prefer to write and execute SQL statements than to use the OOP database features.  On the other hand, some new features I used immediately as they became available because they allow me to do that much less work or stop using TypeCasting (Dynamic Arrays, Long Strings, Generics, etc.)

At any rate, it really comes down to what people want FPC to be:
1. A viable alternative to Delphi and the other compilers and an active language for developers to use.
2. A project to duplicate the antique TP7 compiler on modern hardware for enthusiast programmers.

I am not saying that option 2 is bad, but I think there is a lot of demand for option #1.  Personally, if I couldn't do #1 in Pascal, I would be forced to use Java or Mono for writing complex cross-platform software, so I hope FPC keeps on track.

Thank you,
     Noah Silva

> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal