Pascal vs C#

[Shpend]

Have you gained experience with Delphi/FreePascal? How fast is today's Pascal compared to C/C++ or Java? What are the advantages and disadvantages of the Pascal/ObjectPascal language?

MMechanics July 7, 2016, 20:38
For what it's worth, I'd rather go with C# today. I started with Delphi over 15 years ago and used it for a long time. At that time, the language was pretty junk, no templates, Unicode support, etc., but that didn't bother me so much back then 😉 I wouldn't want to work with the version back then today, but in the meantime many features have been added. In detail I do not know myself there but.
In the meantime I see no reason to use Delphi anymore. Either you take C++, or if you want something "simpler", then rather .NET and C#.
I think the advantages of the "language" were never really decisive. As I said, Object Pascal used to be quite limited. But it was also easier to use than C++, you could more or less just start and see results right away without spending months on the language. Ok, that might have been one reason. But I think more important was that there were so many components that just worked. The GUI was easy to create, much easier than with MFC stuff back then (and probably today too), add database connections, different network protocols were available as components, COM, later Office Automation, reports.... I.e., even dedicated laymen (and 20 years ago there were much less professional developers than now), who were experts in their respective field, could quickly create relatively powerful software, with lots of "gimnicks", e.g. display and print reports, send info by mail, etc. And since the alternatives at that time were Java, C++ and VB, Delphi could establish itself halfway on the market. And not because of language advantages of Object Pascal.

Source: german website: https://www.c-plusplus.net/forum/topic/338741/meinung-zu-delphi-freepascal/2

[Edited to give meaningful title cf original "Do you agree on this?"]

[Thaddy]

At the moment C# is phased out with some of my customers. I like it, but you can run into lots of problems.
Note I use C# myself, even taught people.

[Shpend]

And, in terms of READABILITY and PERFORMANCE how would you compare in couple of sentences C#/.NET 6.0 and FPC 3.3.1 (also 3.2.4)

[Warfley]

I must say I somewhat agree, as a language Object Pascal is not really special in any way. In fact it is so much a jack of all trades, that it hurts itself with it. For the past few years I am trying to explore the possibilities of Pascal with respect to more modern (or sometimes old but different) paradigms, and I often encountered the limitations of the language in a way that I thought to myself "well, in XXX I could do this much more easiely" (XXX being another language like Python, Java or C++).

For example it is a low level language that tries to be high level at the same time. This results in this weird situation where you have the language abstracting away pointers, but the memory must still be managed manually, but because of the level of abstraction, you do not really control the memory.
As an example, in C++ you can put your classes on the heap, the stack, shared memory or even memory mapped files if you wish to do so, for this reason you have to manage classes either by value or as pointer. In Object Pascal you can only put them on the heap implicetly allocated and freed by the constructor and destructor, but you need to manage that manually. So you have all the annoyances of manual memory management with none of the advatages. For example creating a stack allocator for some classes is not really possible as it is in C++. But still managing memory is manual effort unlike Java or C#

Like Java it uses a lot of class hierachies with virtual methods and so on, but unlike Java it does not go all the way, which results in this weird situation that you sometimes want to customize an RTL, FCL or LCL class only to find that the one function you would need to orerride is not virtual. For example when I wanted to create a threadpool implementation I thought that I can easiely do so by overriding the start and stop methods of TThread, but only to find out that they are not virtual.
Or, ObjectPascal supports interfaces, but does not use them, this is one of the greatest things of Java or C#, that you have like your List interface that can be ArrayList, LinkedList, etc.

Also the approach of generics in Pascal is really weird. They sit somewhere between C++ templates, which basically allow you to do everything, are themselves a turing complete sublanguage, and Java generics, which allow you nothing but only having basically an implicit type cast from and to object at the interface.
This means things like this are allowed without any knowledge about T:

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

1. generic procedure Foo<T>(A: T);
2. begin
3.   A.Bar;
4. end;

But the following, assuming this T could be a function pointer type, does not work:

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

1. generic procedure Foo<T>(A: T);
2. begin
3.   A();
4. end;

Why? Because generics are seemingly not supposed to support function pointers.

Generally modern language design has shifted into the functional domain, all of the new and modern languages incorporate many functional paradigms. Python has pattern matching, list comprehensions and even lazy evaluation, Javascript is basically nothing more than lambdas and hashmaps, Java, C++, C#, etc. have all incorporated lambdas with typical functional list functions like map filter or fold.
ObjectPascal, at least what the FPC supports has none of that. Which puts it in some cases at an extreme disadvantage with respect to that

There is just one thing that I can think of where ObjectPascal through it's language design really excells at, and that is backwards compatibility. You can today still use code written in Ancient Delphi versions or even TurboPascal.

What the Delphi ecosystem nailed was easy GUI development, but this isn't that much unique selling point anymore with things like .Net forms or WPF and native Javascript webapps.
There still is the cross plattform GUI development of Lazarus which with it's widgetsets is actually quite neat, and there are not so many alternatives in this area, but this only matters for cross platform developers, most developers stick to either Windows or MacOS, so there is no need for cross development, and on those platfroms, .Net or Swift respectively are very easy to use.


All that said, ObjectPascal might not be the most modern language, but allows you more than one might think, and a lot of the new pascal code is very old fashioned, not because the language does not support more modern coding styles, but because the developers simply choose to do so.
Yes generics can be really annyoing, but they are powerful enough to be used in more circumstances than just generic containers, but even these are more rarely used (a lot of people still use the old pointer or TObject based containers rahter than fgl or generics.collections).

But a problem is also that you have to do a lot of such stuff yourself. You can have things like map and filter functions, but not provided by the standard library, you can't just call TList<T>.Map for map, you must write your own map function:

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

1. type
2.   generic TMapFunc<T, U> = function(const AItem: T): U;
3. generic function Map<T, U>(AList: specialize TList<T>; f: specialize TMapFunc<T, U>): specialize TList<U>;
4. var
5.   i: SizeInt;
6. begin
7.   Result := specialize TList<U>.Create;
8.   for i:=0 to AList.Count - 1 do
9.     Result.Add(f(AList[i]));
10. end;

There is a wiki article for a nullable type but there is no nullable type available by default.
I spent a lot of time just creating very simple modern concepts pretty much all modern languages provide, for pascal to have them when I need them, like my recutils. But this is very basic stuff, I don't understand why such things are not part of the standard libraries.
I've even managed to create co-routines with my STAX project, which is amazing that this is even possible on a pure language level, without any assemly or dirty hacks (and when I started that project I was fully prepared that this would not be possible at all). And in the end, this isn't that hard to implement, and is something pretty much all modern languages have, but not Object Pascal.

I mean I like it, because I do really enjoy building such things from scratch by myself, it's somethign that lets you really learn how those things are working. But if your goal is to just build an application quickly, you probably might not want to use the language where you have to do more work yourself and get less provided by the language and standard libraries

[marcov]

Have you gained experience with Delphi/FreePascal? How fast is today's Pascal compared to C/C++ or Java? What are the advantages and disadvantages of the Pascal/ObjectPascal language?

I think it is flamebait. Focussing it on very general language rather than a specific complete solution says enough.

Warfley: the C++ generics thing is afaik FPC specific. FPC approached it from the C++ side, and Delphi from the C#. Later FPC also supported the Delphi way, but the C++ origins still shine through.

[domasz]

There is no perfect programming language out there. Some are better for this and some are better for that.
For example I love PHP and making websites with PHP is super easy. I could make websites in Free Pascal but it would take me a lot more time.
On the other hand I tried writing image converters in PHP, Python and Matlab and my converters were painfully slow. After porting to Free Pascal the same converter was about 100-200 times faster.
C/C++ are primitive languages, only a tad above assembly. It's super easy to access unallocated memory and the quality of code available on the net (libraries, examples etc.) is super low. Even something so basic as strings is often not used in C/C++ programs and you have to deal with pointers to characters or array of characters. Stone age!
However if you want to write device drivers or heavily integrate with OS then C/C++ is the best.
For GUI applications Lazarus and Delphi are just awesome. C# seems as a nice alternative but it required .NET framework so the portability sucks.

In other words- choose your weapon for the battle and Pascal is still a great option for some of them.

[dbannon]

2016 ?  This quote is 6 years old. 

> something "simpler", then rather .NET and C#.

Back then, C# and mono was sounding like a good idea on Linux, not now. And it was never 'simpler' !
The mono runtime is close to 300Meg last time I looked. And try running some older mono code on today's release and then talk about 'simpler'.

But maybe the original writer was unaware of Linux, if that's the case, hardly authoritative.

Davo

[Warfley]

C/C++ are primitive languages, only a tad above assembly. It's super easy to access unallocated memory and the quality of code available on the net (libraries, examples etc.) is super low. Even something so basic as strings is often not used in C/C++ programs and you have to deal with pointers to characters or array of characters. Stone age!

What you are talking about only applies to C not C++, at least not for the past 10 years. In C++ since C++11 you normaly use smart_ptr and unique_ptr which solve pretty much all memory issues and std::string fro strings, which does not need you to concern with the pointer at all.
C++ is actually a really modern high level language, while still also allowing low level access. This is why it always invites comparisons with Pascal, because Pascal is in some respect in a similar position. But C++ has, for better or for worse, much more (in numbers) and much more powerful high level constructs that Pascal does not have (e.g. varardic templates), which allow to write much more high level code. On the other hand this is what gives C++ this very steep learning curve

[PascalDragon]

There is a wiki article for a nullable type but there is no nullable type available by default.

The nullable unit is part of FPC since 3.2.2.

[del]

In my world nobody uses C#. The "scientists" like Python because it's easy and as a result of it being easy it has a large community (as does fast food). But the scientists wouldn't be able to get anything done without a huge team of C++ programmers providing the "meat" under the Python skin. And this idea that pointers are bad is just BS. My only disappointment with Pascal is it lacks scope based memory management. But we don't need to have that discussion. My only concern about Lazarus is the situation with GTK-3. But we don't need to have that discussion either.

[SymbolicFrank]

In C++, almost everything is allowed, and it is up to the programmer to only use the things that actually work.

In Object Pascal, many things are not allowed, because they would result in errors.

In most comparisons with Object Pascal, there is a list of things you should be able to do, because you can do that in C++ as well. And most of those things are in the category: "don't use".

Like, don't use regular strings or pointers, but use std::string and smart pointers. Don't pass pointers as arguments, pass references.

Things like templates aren't the same as generics. Templates are macros. And the problem with macros is, that they make the meaning of the code dependent on the context. It's not a context-free grammar.

The main metric about C++ code seems to be if you programmed it for optimal speed, not correctness. Readability is never an issue.

Lastly, try to import a project or library into your project. Compare the effort needed in C++ and Object Pascal.


I agree, there are many interesting languages. I do like C#, but as said, the portability and longevity are bad. The bits up to version 2 were good, after that it went off in random directions. Python is ok, I guess. MatLab is very specific. Visual Basic is nice if you're mostly programming in Microsoft Office. JavaScript and PHP need stuff on top to turn them into real programming languages. Like they tried with C. That is probably the best thing you can say about C++: it was an early experiment and we have learned a lot from it.

Most programming languages have no staying power.

[PascalDragon]

Things like templates aren't the same as generics. Templates are macros. And the problem with macros is, that they make the meaning of the code dependent on the context. It's not a context-free grammar.

No, templates are not macros. And that the final meaning of the code depends on the context of the specialization (namely what parameters are used) is true for generics as well.

[Warfley]

In C++, almost everything is allowed, and it is up to the programmer to only use the things that actually work.

In Object Pascal, many things are not allowed, because they would result in errors.

C++ is actually quite restrictive, but the compilers accept a lot of stuff that is undefined behavior. Take for example this:

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

1. var
2.   b: Boolean;
3. begin
4.   b := True;
5.   PByte(@b)^ := 42;
6.   if b then ...
7. end;

Completely valid pascal, but the C++ equivalent:

Code: C  [Select][+][-]

1.   bool b = true;
2.   *reinterpret_cast<unsigned char *>(&b) = 42;
3.   if (b) ...

Is undefined behavior (UB), because typecasting between different, unrelated pointer types is not defined by the standard. If you use this, this is not valid C++.

Or Unions:

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

1. var
2.   test: record
3.     Case Boolean of
4.     True: (Int: Integer);
5.     False: (Bytes: Array[0..3] of Byte);
6.   end;
7. begin
8.   test.Int := 3678;
9.   WriteLn(Test.Bytes[0]);
10. end;

Completely fine in pascal:

Code: C  [Select][+][-]

1. union {
2.   int Int;
3.   byte Bytes[4];
4. } test;
5. test.Int = 42;
6. std::cout << test.Bytes[0];

Is UB and therefore not valid C++.

Or if you have ever written an infinite loop without a side effect of the form:

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

1. While True do
2. begin
3.   ...
4.   if Breakcondition than
5.     Break;
6.   ...
7. end;

This is valid Pascal, but undefined behavior in C++, because infinite loops should be avoided for a good coding style

In my experience C++ is much, much more restrictive than Pascal, due to the fact that it is standardized and everything the standard does not explicetly allow is UB, while Pascal has no standard, therefore pretty much everything the compiler takes without complaining is correct.

Therefore saying that C++ allows everything and Pascal disallows things that would cause errors, is not really correct, all of these things defined above are UB in C++ because they can cause errors and should therefore be avoided, while being perfectly fine in Pascal

[SymbolicFrank]

@Warfley, do you mean, that the compiler gives an error when you do the above, that it generates a runtime error when you do it wrong, or that you should refrain from doing it? Error or don't do?

[Warfley]

The compiler will usually throw a warning when you use -Wall and -pedantic, and as you should always compile with -Werror, the warnings will turn into errors.
That said, a lot of these things cannot be checked in general, for example the infinite loop can only be checked for very simple programs, as it is basically asking about a non trivial semantic property of a program, which is not computable.
For those things that are not statically checkable by the compiler, both clang and gcc provide the undefined behavior sanatiser, basically a compiler addon, that annotates your code with checks for undefined behavior. With UBSan active, such things as described above would at least create a runtime error, even if they cannot be statically detected for compiler errors

Also the thing with C++ is that different compilers allow different things. So you have features that GCC allows and are perfectly fine with GCC, but that Visual C++ does not. But make no mistake, if you use these features of the compilers, you are not writing valid C++ code, but GCC or VC++ code.
But in this thread we are arguing about C++ as the standardised language and not different compilers, we should only consider what the standard actually says.

This is generally the thing with standardised languages, like C++, to be able to use them correctly, you need to know the standard to a certain degree. This is not the case with QuasiStandard languages, where the language is more or less defined by the capabilities of the dominant compiler, like it is with Java, or the two ObjectPascal dialects Dephi or FreePascal.
So in some sense this might be seen as an advantage, in that you do not have to double check everything you do if it is actually valid C++, or UB, or Implementation specific (and in that case, what your compiler manual says about the matter), while in quasi standard languages like Pascal, you simply do something and if it works it works, if not it doesn't.

It requires a different way of approaching learning the language, and often results in many C++ programmers using UB, because they don't use -Wall, -pedantic, -Werror and UBSan, and never read the standard so closely, and approach the programming by the trial and error principle, which in such a language will inevitibly produce invalid code.
But on other hand with quasi standard languages like pascal, you then have things like in this thread where for the question, there was no real answer, there is something that works, but as the answer of PascalDragon shows, while it will work probably, there are a lot of ifs and buts that might influence this, which you would never have in a standardised language, where in such a case you would just open the standard and see either "Yes this works", or "No this doesn't", or "This is undefined behavior" and exactly know if you can use it or not