Language comparisions/what is (Free) Pascal good for?

[graemex]

I am fascinated to find that Free Pascal has an active community and I was surprised by by how popular Delphi/Object Pascal were in the TIOBE index (still ahead of Swift!). I am not clear about what advantages it offers and what sort of work it is best at. The wiki has a comparison to C, and from the "future of free Pascal" I found a link to a brief discussion on Reddit.

The most obvious usees are rapid deveopment of desktop GUIs (which is what I always thought of Delphi as offering). It also seems to be be good for games (relying on what I read - I have no idea myself). What else is it good for?

I find the argument for it over C or C++ pretty compelling, but what advantages does it offer over all the other options: D, Swift, Go etc.? Why use it instead of Haskell, or Ocaml, or Nim (other than maturity in the case of the last)?

[Thaddy]

Well. Drop the RAD. That is actually not the language as such. It just means ObjectPascal in general has good two way IDE's that help you design a user-interface quickly and has some features - that's true, but not on the compiler level - to accommodate that.

For me the strengths are:
- still really strongly typed. If you need it, it's way superior to D--
- still very readable, not only by the language, but also for sociological reasons The community learns by example and therefor writes readable code by default. (Except Button1 programmers of course )
- I know a lot on how to do things in Pascal and its libraries and frameworks, so I am more productive then let's say in D flat.
- I grew up with it. (And with K&R, and with Fortran and with COBOL)

It is all very personal. I mean type inference is something that is still clearly lacking in modern Object Pascal

Except that Pascal is also very close to the almost default pseudo-code notation

[Leledumbo]

The most obvious usees are rapid deveopment of desktop GUIs (which is what I always thought of Delphi as offering). It also seems to be be good for games (relying on what I read - I have no idea myself). What else is it good for?

One word: everything. People here have used it for console, desktop, web, services, embedded platforms, etc. I myself use it for web a lot more than anything else these days due to its simple deployment and the ability to switch technology simply by changing single uses clause entry.

I find the argument for it over C or C++ pretty compelling, but what advantages does it offer over all the other options: D, Swift, Go etc.? Why use it instead of Haskell, or Ocaml, or Nim (other than maturity in the case of the last)?

The official website says this. In addition, the default distribution supplies with a huge collection of libraries that you can readily write many non-trivial applications right away without looking anywhere else.

[bee]

We can't compare programming languages head-to-head just like that. Because every single language brings the philosophies, ideals, and interests of the creator. It would be like comparing kids head-to-head. Of course every single kids is unique and special, according to their parents. That's why a new language still arises once in a while, despite there are so many languages available already. So, I don't think such discussion would give us any benefits. If we want to use a language, just study the advantages, and be ready to compromise the disadvantages. Any languages we pick as favorite is purely subjective to our preferences.

However, we can compare programming languages objectively by looking at each as a whole ecosystem. After all, in the reality, we don't actually use the language per sé. Programming language only defines the grammar (the structure or syntax). We're using the implementation of the language, which in some cases doesn't really implement all the language standards. We use the language compilers, we code within the IDEs, we participate in the community, we use the available libraries and frameworks around the compilers, we read the documentations of the compiler and the libraries/frameworks, etc so we can create apps for the available platforms, or at least for the platform we need. These supportive things around the language that matters most to us and shape our preferences. If there's none or not good enough of these things, most people just left the language in the dust and pick other languages with more living ecosystem, no matter how good the language structure is. 

For example… I do love modern Pascal, especially Free Pascal and Lazarus. However, in the real world, I can't use it to support my bussiness with all the limitations of mine and my surroundings, especially when I need to target a specific platform. I have no option but to embrace other languages and tools to create my apps in effective and efficient ways. On the other hand, for example… I hate C-like syntax, including Swift. But I got full support from Swift ecosystem so I could use Swift to create apps much faster and better than if I use Pascal. So, forgive me if I take Swift over Pascal any day, when I need to create apps for Apple's platform. Or if I take Java over Pascal, when I need to create apps for Android. It's not because I think Java or Swift is a better language than Pascal language, but it's the best ecosystem available for the platform. Whether I hate or love the other options, it's no longer relevant in the bussiness. In fact, I use many languages and dev tools to support my bussiness. All is well. After all, programmer's main job is to solve problems, right?

[Thaddy]

After all, programmer's main job is to solve problems, right?

Yes. And as you and I wrote: be able to choose the most appropriate tools to achieve that.

[Graeme]

What else is it good for?

One word: everything.

+1

I use it for Console apps, [cross-platform] Desktop apps (thanks to fpGUI), used to use it for CGI apps, UNIX Daemon & Windows Services applications, Client/Server and 3-tier Enterprise database apps. The last two, thanks to the fantastic tiOPF and Indy frameworks.

It is a very easy to read and understand language, strongly typed (which I love) and has pretty much all the latest language features other languages have too. The major benefit is that FPC generates a fast native executable that doesn't need a runtime environment - so an absolute breeze to deploy anywhere.

[graemex]

Thanks for the answers .

However, we can compare programming languages objectively by looking at each as a whole ecosystem.]

That is what I want. I end up doing everything in Python these days, largely because of the libraries and frameworks (I also love significant white space - I do realize not everyone does!). This is why I am looking to learn a language that is very different - and statically typed compiled languages are an obvious place to look for something different.

still really strongly typed. If you need it, it's way superior to D

Care to elaborate? I have not used D, but from what I have read it has a fairly good typ system.

I mean type inference is something that is still clearly lacking in modern Object Pascal

That struck me. That and the lack of garbage collection. I can see it is an advantage for some things, but, for most things it just means extra work.

The official website says this.

There is not much that really stands out for me in the way that say Haskell's type system or Smalltalk's image and introspection (the last two languages I made an effort to learn).

I can see the attraction of small, statically linked executables, but I have some reservations about them as well - when a library needs a security update you need to recompile. On the other hand being able to develop on one OS, cross compile for multiple OSes, and getting executables that can just be dropped in, seems very convenient. Is it really as relatively straightforward as the wiki makes is sound? GUI and all? Um, maybe that is the thing that does make it really stand out, as Graeme said.

It also seems relatively easy to learn (unlike Haskell!), is mature (unlike Nim), has a large enough (and friendly, from what I see on the forums) community, and is unlikely to disappear abruptly.

[molly]

I can see the attraction of small, statically linked executables, but I have some reservations about them as well - when a library needs a security update you need to recompile.

It seems to me that you read a thing and place it out of context :-)

If you want to make use of (external) libraries (dll and the like) then you are perfectly allowed to do so. And if that means you want to do that dynamically then please feel free to do so. In that case there is no need to recompile unless you want to make use of newly introduced functionality. e.g. you would need to accommodate your header files to add/introduce this new functionality and adjust your code accordingly. Just as you would need to do in every other (chosen) language.

edit: link

[Leledumbo]

There is not much that really stands out for me in the way that say Haskell's type system or Smalltalk's image and introspection (the last two languages I made an effort to learn).

Well, the page does not explain all the features, just general overview. Let your own experience tells the advantages to you. I admit that Haskell's type system is way superior (stronger, safer, yet flexible, but harder to learn), but that also due to its paradigm as a pure functional language. It's AFAIR impossible to implement Hindley–Milner type system in an imperative language.

I can see the attraction of small, statically linked executables, but I have some reservations about them as well - when a library needs a security update you need to recompile.

Actually, you will still need to reload the app anyway if you update libraries for an app that loads dynamic libraries that it uses statically. Even if it loads them dynamically, you will need to write the code to handle reloading of the libraries. That, to me, is a lot more complicated that a recompilation and simple reload of a single statically linked application, with
less code and less size bloat.

[graemex]

It seems to me that you read a thing and place it out of context :-)]

Not deliberately! I think I need to read up on how this works. If I can choose what to do, that sounds fine.

I admit that Haskell's type system is way superior (stronger, safer, yet flexible, but harder to learn), but that also due to its paradigm as a pure functional language.

My point is not that Haskell has a better type system (it does, of course), but that Haskell has defining features that make it different - the type system, being purely functional, and lazy. Obviously these are related. The point of this thread is that I want to know what makes (modern) Pascal different/better and possibly worth learning - my thoughts so far are:

The good:

1) It looks relatively easy to learn (well enough to do useful work, at least).
2) Fast development and easy deployment of cross platform GUIs.
3) Mature, with a fair amount of libraries.
4) Fast, if I need the performance.

The bad:

1) No type inference.
2) No garbage collection (not even as an option).
3) Quite verbose.

Another language that appeals to me is Nim, which seems to be more than a little influenced by Pascal. It has some nice features but is far from mature.... There seems a lot happening with compiled languages at the moment.

Actually, you will still need to reload the app anyway if you update libraries for an app that loads dynamic libraries that it uses statically. Even if it loads them dynamically, you will need to write the code to handle reloading of the libraries.

I am confused by this.

[Leledumbo]

2) No garbage collection (not even as an option).

Not directly, but people have invented tricks to do that by exploiting COM interfaces (its reference counting ability to be precise). I still believe my own hand when to destroy objects I created, though.

Another language that appeals to me is Nim, which seems to be more than a little influenced by Pascal. It has some nice features but is far from mature.... There seems a lot happening with compiled languages at the moment.

Indeed the author first wrote the compiler with FPC, which then got posted in FPC forum, until the point where it got rid FPC completely and doing full bootstrap by itself. He got a lot inspirations from FPC specifically (you'll get familiar right away with its modules' & procedures' name) and Pascal language in general (type definition, strong static typing, declaration block). I've learned it and still follow its unstable development, but won't use it in production until 1.0. The breaking changes are too major sometimes.

I am confused by this.

Dynamic library can be loaded statically or dynamically. In the former case, if the library is not found when the program starts, it will crash. The loading is handled by dynamic linker of the OS. In the latter case, even if the library is not found, the program can still start. The loading is handled by the program itself, so it's up to the program when to load/unload. With your wish to update a library on a running program, you will need the latter. And that means you have to write the (re)loading code.

[Thaddy]

It seems to me that you read a thing and place it out of context :-)]

The bad:

1) No type inference.
2) No garbage collection (not even as an option).
3) Quite verbose.

1) Type inference is, well, good for pro's but it isn't for students. Although I am a proponent of that.
2) Garbage collection has a performance hit either way. It is a silly way to get around incompetence. Hence "Garbage" in the original papers.....
3) Quite verbose is  GOOD I'd like to see begin end over {} any day... {except for comments}

Anyway I am quite happy the state we are in.

[molly]

It seems to me that you read a thing and place it out of context :-)]

Not deliberately! I think I need to read up on how this works. If I can choose what to do, that sounds fine.

Of course it was not deliberate so, no hurt was intended 

I understand you are trying to get yourself familiar with things so better to write down your interpretations and ask to make sure (better would be to actually experience of course  )

[Graeme]

2) No garbage collection (not even as an option).

Then simply code using reference counted interfaces - it does garbage collection for you.

3) Quite verbose.

I don't consider that a "bad" feature - its more personal preference. Move verbose normally means easier to read and understand. And with intelligent IDE's and programmer editors, they auto-complete much of the boilerplate code for you.

[graemex]

I think I am getting to the point where I need to go and start learning the language, and then come back with any remaining question.

I do think a lot of what I have learned from this thread should be more easily discoverable.

Indeed the author first wrote the compiler with FPC, which then got posted in FPC forum, until the point where it got rid FPC completely and doing full bootstrap by itself.

I did not know that. I did know it was heavily Pascal influenced.

I've learned it and still follow its unstable development, but won't use it in production until 1.0. The breaking changes are too major sometimes.]

Yes. It looks very nice, but not yet.

With your wish to update a library on a running program, you will need the latter.

Not on a running program. On restart.

Quite verbose is  GOOD I'd like to see begin end over {} any day... {except for comments}

Depends how verbose.... I agree about braces. I prefer significant white space myself, but prefer begin ... end over {}.

Of course it was not deliberate so, no hurt was intended

None taken. I just want to be clear I am a complete newbie with Pascal and I am not finding it easy to get a feel for the language. At this point I will probably start going through tutorials. There does not seem to be a Pascal mooc or an interactive tutorial. Where should I start?

Then simply code using reference counted interfaces - it does garbage collection for you.

That is interesting. Again, it was not information I had found . Are there any difficulties with this approach?

Move verbose normally means easier to read and understand. And with intelligent IDE's and programmer editors, they auto-complete much of the boilerplate code for you.

Yes and no. It is sometimes true that very terse code can be unreadable. On the other hand, concise abstractions can be more readable - e.g. a list comprehension instead of a loop.