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.
And on the app/application market we do not really know what language applications are written in. Total Commander is the one popular app that I know is written in Pascal. At least the Windows version is, I do not know much about the Android version. But in general we download and in stall binary applications from app stores or from the Internet. And 99% of those are made by small businesses, not by large corporations. While much of the FireMonkey information on YouTube is about how to make mobile apps and games there are not any really good way to know what languages are popular. There are some sources saying that over 80% of all games are made in Unity which is what small businesses mostly use but I neither know the accuracy of that number nor what the other 20% use.
As for sectors where Turbo Pascal and Delphi would have been used we don't really know. Yes there are few job adds but that doesn't mean that all TP/Delphi developers are unemployed. It just means that the need for new developers do not require job ads. As for the small business segment we don't really know how many there are out there. I know a bunch of several small businesses including myself that still work with VB6 although this is becoming increasingly problematic for us as VB6 support is dwindling. Many of course migrated to VB.NET but there are still a lot of VB6 code out there.
The most significant data we have is the interest in Pascal/Delphi/Lazarus online and that has certainly been trending upwards. The existence of FPC/Lazarus itself being part of that upward trend. Personally I have been closely watching both Delphi and Pascal
Small businesses has a lot of money and there is also a lot more of them than there are big corporations.
Small businesses have much more limited resources than big corporations.
That is completely bogus. By definition A small business has more limited resources than A big corporation. Small businesses collectively have A LOT more resources than bit corporations. At least in all countries that has a relatively free market. Those resources are of course by the nature of small businesses a lot more fragmented. Which is the reason why this market is open to us. There is a very large amount of small business owners who independently decide how to spend their money.
When you code for big corporations they usually demand to own the code
which is quite reasonable since they paid for the developer's time and talent.
So? It still limits how much profit I as a developer can make out of the code that I write. The reason that corporations does this is irrelevant to the point that I were making.
so you cannot sell your application to more than one customer, which seriously limits your ability to profit from your work.
Customized applications made for either, small businesses or big corporations, are rarely general enough to be sold on the open market.
That is about 1/3 true.
1. Quite often you can make a generic product and have customers pay for enhancement. Wine/CrossOver is a well known product with this business model. Of course right now their main customer is Valve so they have climbed up to the point where large corporations pay them money, but they started out with money from end consumers and small businesses. There are certainly other examples of this but the point was to explain the business model.
2. Custom applications do not have to be 100% custom code. Delphi developers that frequently use common control and libraries should know this. The entire point of RAD is to have a lot of generic code that can easily be weaved into an application. And this is exactly where I suggested that we cooperate in order to be able to provide lower cost custom application to customers.
3. In the case we do code applications from scratch then of course you are right. But then we still use the generic component that is part of the language ecosystem that we use. Where C, C++, C# and Java wins because it has more and better generic components to use in an application. Yes C is a horrible language to develop with but the fact that you do not use "bindings" in C is why it dominates. Other languages has bindings to C libraries, not the other way around.
Some corporations may put a lot of money into development.
More often than not, more money goes into on going maintenance than development. That's one of the reasons they insist on whatever they commission from an independent programmer to be written in a particular language.
Yeah. That is why they keep having headaches every time a new version of Windows or Office breaks their VBA scripts. Sure I have many times told others to use Java because of it's long term maintainability. But Pascal code as well is also very maintainable, at least a lot more maintainable than C and C++ that corporations insist on using a lot. Pascal is more consistent across platforms and across different compilers than C and C++ has been. Well at least a subset of it is.
However more important to Pascal developers the fact that this makes it harder for them to consider a new language. They might consider it for a completely new platform or for a component in an existing platform. But a 10 year old project is not going to switch form Java to Pascal.
[/quote]
More importantly getting corporations to use Pascal is futile.
That's true and one of the reasons for that is that there is no standard version of Pascal available from multiple vendors. Businesses, large or small, avoid vendor lock-in whenever they can.
I disagree. As I am currently learning Pascal I am using multiple versions from multiple vendors. I am using primarily Turbo Pascal and Free Pascal but also several variants for embedded systems such as Turbo51. There is a standard and that is Turbo/Object Pascal. What I want is exactly to avoid vendor lock in which is why I do not limit my learning experience to a single vendor. What is standard and not is not entirely clear from any consistent documentation and that is of course a problem
As for runtime libraries well there we have less standardization. But for embedded systems that are true for most languages. C and C++ for embedded systems rarely implement the standard libraries of the official C and C++ standards. Instead you will rely heavily on inline assembly. And for PC development there the intersection of code that works on both FPC and Delphi is what I would consider a standard.
As for vendor lock ins then it should be quite clear that I personally go to great leanght to avoid them. However corporations quite clearly demonstrate that they doesn't. They use Visual C++ with proprietary Microsoft extensions as well as C# with proprietary Microsoft components. They write SQL code that ties in to SQL Server or Oracle. And they often use Java + Oracle databases in a way that is completely dependent on Oracle.
No the reason that it is futile to get them to use Pascal is that they consider it an outdated and dead language. Even if all the developers would be convinced that Pascal is a great language that would not change anything. Corporations are inefficient and decisions are made by people that doesn't really know. The people that decided to go with C/C++ and Java do they actually know the differences? No. They live in a bubble where the norm is that those languages are modern and good languages. And we do not get to speak with them which is the final reason why it is almost impossible to change their minds.
I'd love to see Pascal grow in popularity but, the "ingredients" to make that happen are not happening.
Well again I disagree. First of all the question that we are discussing is how to make money writing Pascal code. The language doesn't need to grow in popularity for this, it needs to grow in cash flow. And for that to happen we developers must become better at selling our code. And I will claim that the ingredients to make that happen are happening. It's just happening very slowly. This because that it is not a well coordinated effort behind making it happen.
C/C++/C# and Java vendors are all very good at coordinating such effort. C/C++ is an ISO standard and that alone requires a huge amount of coordination.
A top of that they wrote operating systems with C so all the standard API:s for interacting with the OS is C libraries. When it comes to system development what needs to happen is that wee need libraries that can measure up with C in order to compete. That would not necessarily be C bindings. However I can testify that C bindings were a major thing that held me back from diving into Pascal. As it is both C# and Java has way better support for stuff that requires C bindings such as Windows API, POSIX, OpenGL, OpenCL etc.
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.
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.
Seen from a standardization perspective we have the Delphi only VCL, The Lazarus only LCL and the Delphi only FireMonkey. So we have NO standardized GUI library. Currently I am working on command line and server applications so this doesn't really bother me yet. But when I do start writing UI code it will be using the bindings OpenGL and/or SDL because that is more standardized. More specifically I will use EGL plus OpenGL ES because this can run without X11 on Linux, and is the standard API for Wayland for this reason. It can also run directly on the Raspberry Pi framebuffer as well as on Android.
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.
So Instead I will go directly to the low level API which has the advantage that it is rather easy to create binding and also the perhaps more important advantage that it is rather stable over time. Once I have bindings for EGL and OpenGL 2.0 I do not need to change this because a new version comes around. OpenGL ES 3 does not change the 2.0 API:s but add to them and is a separate library. This of course means that for each UI component that I need I will need to implement it. There are already several different game UI:s that I am looking into for doing this. And in my opinion this is exactly what needs to happen for Pascal to become popular again. A modern portable user interface with minimal platform specific components. If I understand correctly this is somewhat happening in the Android backend for the LCL.
It is also possible that the best way for me to do that is to use one of the game engines that exists for Pascal but I have not spent any significant amount of time digging in to those.
So to be more specific about that. What I want and need is a standardized UI that works consistently in Delphi, Free Pascal, Windows, Linux, Unix and non-x86 hardware. The closest that I get to this is using Qt or Java. However Qt for embedded targets are closed source and Java while being consistent is very not optimized for performance. Swing is rather horrible to work with. This leaves Xamarin and FireMonkey as additional alternatives but I find them even less satisfying than Qt or Swing.
For server programming I am exploring the Mormot framework and it seems rather impressing. It works in many Delphi versions as well as FPC. I cannot yet give it a final judgment as I am still learning how it works. However this is an excellent example of the kind of thing that need to happen and also is happening. A standard component that works in most relevant implementations of Pascal.
So as for "not happening". Well that is not an unsolvable problem. We can make it happen.
Recent
