Author Topic: Looking For Remote Programming Job  (Read 2178 times)


  • Hero Member
  • *****
  • Posts: 1993
Re: Looking For Remote Programming Job
« Reply #15 on: September 14, 2020, 09:54:23 pm »
But the amount of people chasing just job is also much smaller. Contrary to e.g. Java job where you have to compete with every new graduate.
That's true but, I'd say the odds are better for a top-5 languages programmer to get a good job than for a Pascal programmer.

It not being a top 5 language doesn't mean it is entirely nothing either. This is all too black and white.
I agree that there are some Pascal programming jobs out there but, there are very few compared to jobs for other more popular languages.  Even a cursory search reveals quite a few more jobs for COBOL and FORTRAN programmers than Pascal.

In a programmer's repertoire of skills, Pascal is just a "nice to have" skill, not a primary asset.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.


  • Global Moderator
  • Hero Member
  • *****
  • Posts: 927
  • Former Delphi 1-7, 10.2 User
Re: Looking For Remote Programming Job
« Reply #16 on: September 15, 2020, 01:52:49 am »
The FPC + Lazarus Wiki's In the News page has an interestng entry for September - Top 10 Programming Languages that Pay Handsome Salaries in 2020.
o Lazarus v2.1.0 r63871, FPC v3.3.1 r46876, macOS 10.14.6 (with sup update), Xcode 11.3.1
o Lazarus v2.1.0 r61574, FPC v3.3.1 r42318, FreeBSD 12.1 amd64 (VMware Fusion VM)
o FPC 3.0.4, FreeBSD 12.2-STABLE r365646 amd64
o Lazarus v2.1.0 r61574, FPC v3.0.4, Ubuntu 18.04 (Parallels VM)


  • Hero Member
  • *****
  • Posts: 2103
  • Compiler Developer
Re: Looking For Remote Programming Job
« Reply #17 on: September 15, 2020, 09:25:42 am »
I just outlined what can reverse that trend. We focus on a market where we can be successful.
You provided an outline but, it remains to be proven that what you've outlined can reverse that trend.  There are quite a few markets out there and, Delphi/Pascal has been losing ground in probably all of them.
I proved that it can. As I myself is a small business owner my anecdotal evidence in itself is sufficient proof. That does not mean that it will. And no Pascal has not been losing ground in all markets. Delphi has but not Pascal. The embedded system have several commercial compilers that are still in active development by the providers that develop them. C is of course the dominant language in the embedded sector but that is not news. Also I will contest your last statement. Pascal has been gaining ground. This as a result of hitting rock bottom. I cannot see all the reasons why the interest in Pascal is increasing. An increased focus on embedded systems is of course important where many of the popular languages simply will not be an alternative. DOS development has also increased and I can find more information about DOS programming in Turbo Pascal being posted and viewed on YouTube than what I can find information on FPC/Delphi. This of course is because of a growing interest vintage systems and emulation.

Good thing then that FPC's support for embedded development is improving more and more. Not only do we have AVR and ARM support, but trunk also contains support for RISC-V, Z80 and Xtensa (think ESP32/ESP8622). :D Of course the library support for embedded targets needs to be improved further, but there are projects like the Microcontroller Board Framework. :)

However in some cases I would argue against bindings and focus on functionality. For example the LCL is commonly bound to high level C API's. On Windows this means a thin layer above the Windows API which in many cases haven't changed much since Windows 3.X. However the Windows API is considered legacy by Microsoft who is promoting their Universal Windows Platform (UWP) Where Windows Presentation Foundation (WPF) is the standard. WPF in turn renders using DirectX. As far as I know neither FPC nor Delphi has support for the WPF. Visual C++, C# and other DotNET languages are required for this as there are no native APU for WPF. To compete with C# we either need support of WPF which is a huge vendor lock in or we need something equivalent. However as it stands the LCL on Windows can hardly compete with the VCL that has many third party components that doesn't match anything for the LCL.

We need existing third party components for Delphi to support the LCL. That isn't something that can come from the Lazarus developers, because either the components are commercial ones or the devs are already busy with developing the LCL.

Outside of Windows the LCL uses a subset of Gtk and Qt Which are both in resent version based on an OpenGL Scene graph engine. The problem here is that we do not have a fully compatible and consistent API between platforms except for the Qt backend which can also be used on Windows. However when using Qt then C and C++ are both superior languages because they have full access to the Qt API. And same goes for Gtk.

Gtk is developed in C, so accessing from Pascal it is much less a problem than accessing Qt which requires an interfacing library. Qt however plays much more nicely with Windows than Gtk.

Why will I not just use Qt. Well Qt has gone partially closed source and when using embedded devices with direct frame-buffer rendering such as Raspberry Pi without X11 then I need to pay a licence fee for Qt and I do doubt that the current pascal bindings work with this.

The user facing side of the Qt API is very stable. And it's nearly completely irrelevant what the backend is (that's only important if one needs rather specific things). I wouldn't be surprised if the bindings would just work.


TinyPortal © 2005-2018