Forum > Other
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 [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---generic procedure Foo<T>(A: T);begin A.Bar;end; But the following, assuming this T could be a function pointer type, does not work:
--- Code: Pascal [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---generic procedure Foo<T>(A: T);begin A();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 [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---type generic TMapFunc<T, U> = function(const AItem: T): U;generic function Map<T, U>(AList: specialize TList<T>; f: specialize TMapFunc<T, U>): specialize TList<U>;var i: SizeInt;begin Result := specialize TList<U>.Create; for i:=0 to AList.Count - 1 do Result.Add(f(AList[i]));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:
--- Quote from: Shpend on March 03, 2022, 02:09:29 pm ---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?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page