The future of Free Pascal

[marcov]

Age of multimedia. DirectX, DirectShow. Almost not implemented in Delphi.

I actually had a job doing audio (bidirectional) over network (to an already existing activeX client (this was 2004ish)). I bought components for about Eur 100, and had it running in two weeks.

There are DirectX and opengl headers. The DirectX headers are worse since not continuely maintained, and the 3D part heavily mutates every iteration. Directshow can be found (e.g. in DSPack to get newer webcams running)

Age of web (HTTP). Web pages become interactive - Flash, Java, JavaScript. Almost not implemented in Delphi.

It was implemented for the first wave of intranetwork webapps (intraweb, webhub). Late the accent went away from plugins (except flash) and the experience became less rich and mostly done with free tools.

Actually 2 out of 3 Delphi jobs I had were Delphi based web apps. One OLAP analysis site, one customer facing.

Age of portable devices. Small screens with big and simple controls. Not implemented in Delphi.

Delphi supports iOS and Android/arm. (Afaik not Android/Intel)

Age of clouds. Backend for web, distributed computing, hot-swap virtual containers. Not implemented in Delphi.

I've seen blurbs from Embarcadero that they have all kinds of stuff for that, but I never payed attention since I'm not working with higher Delphi SKUs (Enterprise, architect) or in that business.

Less enterprise more consumer and small business is the TMS cloudpack, also supported for Lazarus.

What can we do? Complete multimedia and web support. There is many libraries and components, but they not included in Lasarus.

And take maintainership in some of the libraries. A good, maintained directX set would be great.

Designed in IDE must be works on any local and remote device or browser without extra attention from programmer. Portable devices and web pages need some fundamental modifications in LCL/VCL - virtual controls connected to remote datasource, grids of controls. "Widgets - Data Object - Storage" model.

I don't think that you must try to do webapplications VCL/LCL style. That was one of the mistakes of the early Delphi web intraweb packages. Yes, it sounds nice to drag and drop a webpage together, but it simply doesn't work that way. Not even back then, and html is a lot more complex now.

Moreover, the website designers are often now separate from the programmers, and like to use other tools.

Personally I think it is smarter to be able to integrate with what's there in the web sphere than to replace it. Only in small business you can actually consider changing the webserver to some homebrewn. And depending on hosting not even there.

Distributive cloud computing in virtual containers is very promising, but still too young and evolving. May be PascalScript with simple variables/functions export/serialisation/marshalling will help.

I agree with too young, and from a different direction. Most of that comes from the enterprise, and not grassroots. 

One could also wonder if one HAS to do everything.

[marcov]

On topic: I see no correlation between "free pascal" as a language, another UI library and state of Delphi. Imho, all three are quite independent entities:
* FPC goes on its own, picking up delphi features here and there
* Delphi goes on its own
* UI libraries live on their own. Usually not using the latest language features.

We've gone through this before, with TP and Kylix, and speaking from that experience, I'll predict what happens when Delphi dies:

If Delphi dies, there is a big gulp of users that are quickly looking for a drop-in replacement. However, most have already written off their codebases or consider them legacy at that point, and are not willing to invest heavily, so their benefit to FPC/Lazarus is doubtful at best. A lot of argumentative threads on the forum (why isn't it drop in, you will get many more users if it was a blind dropin), and 99% will rewrite in C# and a few diehards in C++.

Some users with larger codebases might stick, and will contribute, but for many that is also maintenance only. That can still mean a few significant wins, but in general the benefits are  much less then most people hope for for such event

But it means the influx of Delphi users will wane over time, and the influx of student users (that we still had in times of TP and Kylix' demise) is already close to dead now. 

Moreover, all shared projects (Indy, Zeos, Synapse etc) might risk lose their main people that are usually delphi centric.

I think over a longer time of a few years, delphi dying is netto negative.

[serbod]

Designed in IDE must be works on any local and remote device or browser without extra attention from programmer. Portable devices and web pages need some fundamental modifications in LCL/VCL - virtual controls connected to remote datasource, grids of controls. "Widgets - Data Object - Storage" model.

I don't think that you must try to do webapplications VCL/LCL style. That was one of the mistakes of the early Delphi web intraweb packages. Yes, it sounds nice to drag and drop a webpage together, but it simply doesn't work that way. Not even back then, and html is a lot more complex now.

Moreover, the website designers are often now separate from the programmers, and like to use other tools.

Personally I think it is smarter to be able to integrate with what's there in the web sphere than to replace it. Only in small business you can actually consider changing the webserver to some homebrewn. And depending on hosting not even there.

There is set of very basic controls/widgets, that present in any user interface - image, button, text, edit field. And some aggregates - vertical and horizontal containers for basic controls (menu, toolbars, lists, accordeons, tabs..). They can be native on some systems, and can be emulated. Most of them already present in VCL/LCL, but many standard widgets come from MS Windows, and do not have implementations on mobile platforms. We can add to LCL set of GUI-independent controls, that not ancested from TWinControl, not contain position and dimension properties in pixels, can be exported to XML/HTML and works on any remote display, from TTY text terminals to future holocubes with mind control. And leave current desctop controls for legacy fine-tuned aplications.

Web/backend designers now is same, as application/system programmers some time ago. Delphi give opportunity build complex systems on designer/application level, without knowledge of OS and database internals, using visual and non-visual components created by system programmers. Same for web - if someone create mapper for visual forms to web page, and someone create web-server component, that do all stuff, that application become web application for browsers, then anybody can just design web applications same way as desctop applications, without learning of server backend internals.

About integration in present web sphere - it's compromise, but not ideal way. It's good for mature legacy projects, but very hard for starting over. It must be easy as software installation - specify place to deploy (local or remote), some options (database, account), and deploy! Target can be local WAMP/LAMP webserver or some online application service (Amazon, Google, etc..).

[marcov]

There is set of very basic controls/widgets, that present in any user interface - image, button, text, edit field. And some aggregates - vertical and horizontal containers for basic controls (menu, toolbars, lists, accordeons, tabs..). They can be native on some systems, and can be emulated. Most of them already present in VCL/LCL, but many standard widgets come from MS Windows, and do not have implementations on mobile platforms. We can add to LCL set of GUI-independent controls, that not ancested from TWinControl, not contain position and dimension properties in pixels, can be exported to XML/HTML and works on any remote display, from TTY text terminals to future holocubes with mind control. And leave current desctop controls for legacy fine-tuned aplications.

But that means a different designer, a different persistence etc, and you are already not enhancing the LCL + lazarus designer anymore, but having something parallel.

You have to, since coordinate systems are different (as you correctly state), they don't inherit from the same basecomponents (that the designer needs) and html has a more scrolling document layout system.

I have no problem with that, but that only takes over some principles and jargon, not actual code.  ASP.NET does the same and generates the related javascript needed clientside .

Though I think the audience will be small, since

• most website design are made by creatives (from the publishing world) not programmers. The programmers are responsible for the layout.
• the small business and private person users that don't have that work division will run into hosting. Shared hosting generally doesn't allow to run binaries, that makes deploying such web technologies hard

Same for web - if someone create mapper for visual forms to web page, and someone create web-server component, that do all stuff, that application become web application for browsers, then anybody can just design web applications same way as desctop applications, without learning of server backend internals.

That simply is very hard and limited, and what those initial webpackages tried (and frankly failed).

About integration in present web sphere - it's compromise, but not ideal way. It's good for mature legacy projects, but very hard for starting over. It must be easy as software installation - specify place to deploy (local or remote), some options (database, account), and deploy! Target can be local WAMP/LAMP webserver or some online application service (Amazon, Google, etc..).

The problem is that people want new technologies, but only on old principles. It doesn't work that way.

The best way to avoid is to have a good UI and logic separation, or simply skip some generations of technology :-)

[serbod]

But that means a different designer, a different persistence etc, and you are already not enhancing the LCL + lazarus designer anymore, but having something parallel.

You have to, since coordinate systems are different (as you correctly state), they don't inherit from the same basecomponents (that the designer needs) and html has a more scrolling document layout system.

Yes, exactly! Same for reports and diagram packages. They have they own visual designer and set of visual controls for documents, not applicable to TForm/TFrame/etc.

I have no problem with that, but that only takes over some principles and jargon, not actual code.  ASP.NET does the same and generates the related javascript needed clientside .

Though I think the audience will be small, since

• most website design are made by creatives (from the publishing world) not programmers. The programmers are responsible for the layout.
• the small business and private person users that don't have that work division will run into hosting. Shared hosting generally doesn't allow to run binaries, that makes deploying such web technologies hard

Modern websites is made from some standard CMS framework with creative templates. Shared hosting allow binaries in isolated sandboxes (virtual machines). You can have you favorite operation system on remote server, that actually run in virtual sandbox, as normal application with limited access to resources.

The best way to avoid is to have a good UI and logic separation, or simply skip some generations of technology :-)

Then, it must be implemented in FPC/Lasarus as soon, as possible. =)

[SymbolicFrank]

In pseudo-code:

The GUI:

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

1. var
2.   MyServer: TApplicationServer;
3. begin
4.   MyServer := TApplicationServer.FindServer('TestApplication');
5.   if not Assigned(MyServer) then Exit;
6.   MyServer.RegisterGUI('TestApplication', SupportedFunctionList);  
7. end;
8.  

There needs to be a server where all the services are registered. Like dns.

The server:

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

1. procedure OnRegisterGUI(Sender: TRemoteApplication; ThisName: string; SupportedFunctions: TGUIFunctions);
2. var
3.   i: Integer;
4. begin
5.   i := MyApplications.Add(Sender, ThisName);
6.   if i >= 0 then
7.   begin
8.     MyApplications[i].ApplicationType := atRemoteGUI;
9.     MyApplications[i].SupportedFunctions := SupportedFunctions;
10.     MyApplications[i].Notify('Registered');
11.   end;  
12. end;
13.  

The process/thread:

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

1. var
2.   MyServer: TApplicationServer;
3.   MyGUI: TRemoteApplication;
4. begin
5.   MyServer := TApplicationServer.FindServer('TestApplication');
6.   if not Assigned(MyServer) then Exit;
7.   if MyServer.GUIAvailable then
8.   begin
9.     MyGUI := MyServer.GUI;
10.     MyGUI.CreateControl(TEdit, 'MyEdit');
11.     (MyGUI.Controls('MyEdit') as TEdit).Text := 'Hello, world!';
12.   end;  
13. end;
14.  

All the communication is then done through messages (records, often with strings).

[Graeme]

Huh. Learn something new every day!
I always considered you the author of the library.

And fpGUI pre-dates Lazarus.

The original fpGUI was actually 3 projects: fpGFX (2D library), fpIMG (image support) and fpGUI (widget support). I merged them together when I started working on fpGUI back in 2005/6. Then after the fpGUI v0.4 release I started completely from scratch and rewrote the whole fpGUI from the ground up. Pretty much everything has changed compared to what Sebastian work on - all except the project name.

[Graeme]

Age of web (HTTP). Web pages become interactive - Flash, Java, JavaScript. Almost not implemented in Delphi.

Age of portable devices. Small screens with big and simple controls. Not implemented in Delphi.

Age of clouds. Backend for web, distributed computing, hot-swap virtual containers. Not implemented in Delphi.

All of the above can and often is implemented using Free Pascal. At least that is true based on the crowds of people I hang around with.

[Graeme]

We've gone through this before, with TP and Kylix, and speaking from that experience, I'll predict what happens when Delphi dies:

What still amazes me is that many companies or developers think Delphi has died many years ago... with Borland Delphi 7. They don't even know about CodeGear or Embarcadero taking it over. At least that was the case in my previous job. They were totally amazed that Delphi was still around. They were even more amazed (and impressed) that there are projects like Free Pascal and Lazarus around that can do what Delphi does [and more], but on multiple platforms.

In today's world, most companies are completely blinded by the "what's the latest language craze", they simply forget about anything that came before it. That's very sad.

[marcov]

Huh. Learn something new every day!
I always considered you the author of the library.

And fpGUI pre-dates Lazarus.

No it does not afaik. It does predate Lazarus'  win32 backend though, so you could claim first native win32 solution :-)

[Graeme]

All the communication is then done through messages (records, often with strings).

Maybe you should take a look at MSEide+MSEgui then. I believe MSEgui has something like that for some years already [I think it is called MSEifi]. I've never tried it, but from what I've heard it sounds similar to what you described.

[Graeme]

And fpGUI pre-dates Lazarus.

No it does not afaik. It does predate Lazarus'  win32 backend though, so you could claim first native win32 solution :-)

I don't want to claim anything, I was simply under the impression that Kassandra was started before Lazarus, and fpGUI/fpGFX/fpIMG was implemented at the time of Kassandra.  But this was all long before I even knew about the existence of FPC or Lazarus, so I might have the facts wrong.

[mse]

All the communication is then done through messages (records, often with strings).

That looks like remote MSEifi. In MSEifi the server sends the *.mfm form data (MSEgui equivalent for Lazarus *.lfm files) and Pascalscript snippets to the client MSEifi interpreter which could be a browser plug-in or a standalone application. Server and client are connected by MSEifi datapoint- and event-components and communicate with messages. MSEifi components can be used in order to separate GUI and business logic in a normal desktop application. It is also possible to have server and client in a single application so the same application source can be used in remote or standalone code.
MSEifi also exists since many years. :-)
A very old example with pipe connection and binaries is here:
https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/mseifi/ifipipedemo
Video:
http://mseide-msegui.sourceforge.net/pics/mseifiremote.mpeg

[skalogryz]

The problem is that people want new technologies, but only on old principles. It doesn't work that way.

The best way to avoid is to have a good UI and logic separation...

Some sort of "relaxed LCL", where UI design is based on system native tools and rules.
While the controlling code (logic) is shared for all target platforms.

Now, the problem is some of the target platforms, specifically desktop: Win32, Gtk2(?), Qt(?),  don't have a "system native" design tools. Thus the library has to provide some sort of substitution for them.

[jc99]

This thread drifts very much in the wana-have-new-gadget corner.
Let's start over with some questions:
What is the fundamental strength of free pascal over all the other languages ?
Why are people using free pascal ?
What do they mostly do with it ?
What is our weakness ?
(I'm really talking about Free PASCAL in general and not only about LCL/Lazarus, but also not excluding it)

When Apple seemed dead, some years ago, and Steve Jobs came back to Apple he asked exactly the same questions.
And then he concentrated on the strong parts, and build a stronger company on it.
So embrace our strength and diminish the flaws.
If we do so we have a future.
 
Here are some of my answers:
I use free pascal, because it's free (of cause) and it's reliable.
You have clear and rock-solid interfaces, and only very few hidden side-effects.
Also it is very tidy, everything has it's place, and there is a place for everything.
I very much like the write once, compile/run everywhere- aspect (so i don't have to reinvent the wheel for every new version of an OS).

BTW: There's life in the old dog yet.