Recent

Author Topic: The future of Free Pascal  (Read 228310 times)

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
The future of Free Pascal
« on: March 16, 2016, 11:10:19 pm »
Well, Delphi is as good as dead. And, to be honest: good riddance. As the developments of the last ten years were nothing to write home about.

That does ask a question: without a Delphi lead, and Lazarus following and pushing specific Free Pascal changes, is there an overall goal where Free Pascal wants to go? Or is it over and done as well?

Like the ASML management said: at some point, all the competition was behind us, so we were the ones that had to come up with a good plan.

I can think of multiple expansions, although it is debatable if you would want to incorporate it in Free Pascal, or make a Lazarus library for it.

1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications. That would be the Apple way. Chance of success: low, without a strong and visible lead.

Why is this in this list, and on the first place? The main bottleneck is a unified compilation platform. No specific syntax, like with Objective Pascal or the JVM target. And coming from that, the incompatible event and widget models. And it would make the most difference in establishing Free Pascal / Lazarus as one of the main development platforms.

2. A slick, anti-aliased and zoomable OpenGL application GUI. Especially the text. That is easy to port, runs everywhere and looks much better than the current, pixelated ones. That would score major points with the customers of your applications. And it would be a requisite for the previous point.

3. Platform-agnostic, message-driven multitasking and multi-threading. Or, in other words: distributed processing.

Wow, tech alert! What is wrong with the current, event-driven one? Well, it doesn't scale beyond a single computer and CPU core. And the speed of that single thread/core barely increases over the hardware generations.

This happened more than ten years ago. Everyone expected, at that time, that by now every application would run across many computers and CPU's. But that didn't happen. Because everything is still single-thread based. There is very little development done in distributed processing. Mostly because there is this push going on for the last 15 years to web-based and mobile, which makes that futile. And so everything has stagnated over that period.

This is the best option to set Free Pascal / Lazarus solidly on the map from a technical perspective.


Well, I have more, but those are (IMO) the most important ones. And yes, I will help.

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
Re: The future of Free Pascal
« Reply #1 on: March 17, 2016, 12:14:17 am »
Free Pascal has for many many years come up with its own ideas and goals - it doesn't need Delphi to survive. Yes they tried to keep Delphi compatibility, but that is mostly to win ex-Delphi developers, or allow Delphi developers to target platforms Delphi never will.

As for your points (1) and (2) - take a look at fpGUI Toolkit. For years it already does what you describe, plus I've used it in many commercial application too. So its proven stable. As for an OpenGL backend - that can easily be written, but not by me. I don't like a GPU requirement for a desktop application. Saying that, 2 or 3 years ago somebody was working on an OpenGL backend for fpGUI. I never followed their progress, but if you search the fpgui.support newsgroup will should be able to find some URL or a contact email.
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

mse

  • Sr. Member
  • ****
  • Posts: 286
Re: The future of Free Pascal
« Reply #2 on: March 17, 2016, 08:10:33 am »
1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications.
That already exists since more than 10 years (MSEide+MSEgui):
https://sourceforge.net/projects/mseide-msegui/
There is also fpGUI:
http://fpgui.sourceforge.net
Quote
2. A slick, anti-aliased and zoomable OpenGL application GUI. Especially the text. That is easy to port, runs everywhere and looks much better than the current, pixelated ones.
MSEgui has an experimental OpenGL backend. Although I must say that OpenGL is a nightmare to serve as GUI-backend. There are so many different implementations, all with different limitations, extensions and bugs. Especially for text. ;-)
Quote
3. Platform-agnostic, message-driven multitasking and multi-threading. Or, in other words: distributed processing.
I'll probably will implement such elements in MSElang:
https://gitlab.com/mseide-msegui/mselang/wikis/home
Currently I am developping MSElang with LLVM backend for the Free Pascal dialect used in MSEgui. The quality of the code which LLVM produces is impressive. The compiling speed not so much...
Personally I think use of parallel computing will be limited to special tasks because its complexity normally is not worth the effort. Most of the Applications are fast enough if they use well written libraries without the need of parallell computing.
Quote
And yes, I will help.
You could implement a shader based OpenGL backend for MSEgui. The necessary functions:
Code: Text  [Select][+][-]
  1.  gdifuncty = (gdf_creategc,gdf_destroygc,gdf_changegc,gdf_createpixmap,
  2.               gdf_pixmaptoimage,gdf_imagetopixmap,
  3.               gdf_getcanvasclass,gdf_endpaint,gdf_flush,gdf_movewindowrect,
  4.               gdf_drawlines,gdf_drawlinesegments,gdf_drawellipse,gdf_drawarc,
  5.               gdf_fillrect,
  6.               gdf_fillellipse,gdf_fillarc,gdf_fillpolygon,
  7.               gdf_drawstring16,
  8.               gdf_setcliporigin,
  9.               gdf_createemptyregion,gdf_createrectregion,gdf_createrectsregion,
  10.               gdf_destroyregion,gdf_copyregion,gdf_moveregion,
  11.               gdf_regionisempty,gdf_regionclipbox,
  12.               gdf_regsubrect,gdf_regsubregion,
  13.               gdf_regaddrect,gdf_regaddregion,gdf_regintersectrect,
  14.               gdf_regintersectregion,
  15.               gdf_copyarea,gdf_getimage,
  16.               gdf_fonthasglyph,
  17.               gdf_getfont,gdf_getfonthighres,gdf_freefontdata,
  18.               gdf_gettext16width,gdf_getchar16widths,gdf_getfontmetrics
  19.               );
  20.  
That would be a big help. The MSEide+MSEgui code is here:
https://gitlab.com/mseide-msegui/mseide-msegui

Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: The future of Free Pascal
« Reply #3 on: March 17, 2016, 10:36:17 am »

1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications. That would be the Apple way. Chance of success: low, without a strong and visible lead.

Why is this in this list, and on the first place? The main bottleneck is a unified compilation platform. No specific syntax, like with Objective Pascal or the JVM target. And coming from that, the incompatible event and widget models. And it would make the most difference in establishing Free Pascal / Lazarus as one of the main development platforms.

About 1 - yes, with FPC, currently, MSEIde/MSEgui and fpGUI are the way to go for unique look and feel across all platforms. They are well written and their maintainers go forward and are willing to give as much support as they can.
However, these are one-man projects. One man develops, one man decides where the project will go... Martin (MSE developer) even decided to create his own one-man developed new Pascal-like language... :)
I think that one-man projects can hardly get wide acceptance you are talking about.

So, as I see it, the farther development of Lazarus IDE is the only chance for wide acceptance.

Lazarus LCL library with "native" OS widgetsets is a good way, but LCL still needs a good fpc-drawn library, independent from C-libraries gui backends, which can be used as widgetset and look and feel same everywhere. But only as an option - the "native" way must stay.

And yes, I will help.
There are two attempts to make this possible - fpGUI-LCL widgetset and CustomDrawn LCL widgetset. They are far from finished and currently not usable for serious development. The development of the fpGUI-LCL seems to be abandoned and the development of CustomDrawn also doesn't seem to move fast...

So, if you want to help, the way to go would be to take one of these two and commit to its development.
For the fpGUI-LCL widgetset, I think that if Graeme (fpGUI developer) doesn't get interested to seriously involve in this (and as I see he is not much interested) you will have hard time... and for CustomDrawn... I don't know...
« Last Edit: March 17, 2016, 10:41:34 am by Zoran »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: The future of Free Pascal
« Reply #4 on: March 17, 2016, 10:41:52 am »
All points have some merits, but IMHO none of them is a core part.

1 and 2 are not Lazarus points, and the other toolkits do all kinds of owner drawn work, so that is their turf.

I'd like to see a OpenGL toolkit for embedded GUIs, and thought about it (because some of my work app GUI is opengl), but there are practical issues to consider.

The problem is while many will pay lipservice to the concept, there probably is internal division. Some dream of fancy animated driven GUI that I don't care about at all, and because we generally only deliver new developments on new hardware, I wouldn't mind setting a quite high minimal level for the GPU (like Haswell, or even Skylake).  Sandy bridge has a defunct geometry shader, and Ivy Bridge's is slow.

As for 3, I don't see any reason for this to integrate with the GUI. It seems to me you have not exhausted the existing library options yet (like omnithread or Bero's), and expect to carry on doing Delphi like apps with just multimachine and threads thrown in.

That will never happen. Any significant expansion of the scope of a framework usually brings a new way of working, and more constraints.

For portable opengl font handling, you can borrow from my signed distance fonts demo
« Last Edit: March 17, 2016, 10:54:30 am by marcov »

Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: The future of Free Pascal
« Reply #5 on: March 17, 2016, 10:56:43 am »
1 and 2 are not Lazarus points, and the other toolkits do all kinds of owner drawn work, so that is their turf.
You don't think that having (1) as an option in LCL would help wider acceptance of Lazarus and FPC?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: The future of Free Pascal
« Reply #6 on: March 17, 2016, 11:07:29 am »
You don't think that having (1) as an option in LCL would help wider acceptance of Lazarus and FPC?

That depends on how you interpret (1).  Polish Apple a bit within the current lazarus constraints: go ahead, but that is no real change from current policies, so I didn't take it that way.

Make something universal as I read it: that will break the lazarus contraints too much or be very unwieldy, so I think there is no realistic outcome of such effort.  Not if we can't even get a simple working cocoa backend in 5+ years.

Nativeness on all targets is hard. Even Java GUIs with billions pored into them still feel non-native.




Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: The future of Free Pascal
« Reply #7 on: March 17, 2016, 11:21:14 am »
You don't think that having (1) as an option in LCL would help wider acceptance of Lazarus and FPC?

That depends on how you interpret (1).  Polish Apple a bit within the current lazarus constraints: go ahead, but that is no real change from current policies, so I didn't take it that way.

Make something universal as I read it: that will break the lazarus contraints too much or be very unwieldy, so I think there is no realistic outcome of such effort.  Not if we can't even get a simple working cocoa backend in 5+ years.

Nativeness on all targets is hard. Even Java GUIs with billions pored into them still feel non-native.

But fully working FPC-drawn LCL-widgetset, maybe will not feel native, but it will give you an option to have same look and feel everywhere. It must be nothing more but an option, the "native" widgetsets have to stay.

I believe that there are people who prefer this to "nativeness" and I believe that having it in LCL will be more helpful for wide-spreading FPC and Lazarus than telling people to go to one-man projects like MSE or fpGUI. Not because these projects are not good, but new user will certainly more likely decide to stay with FPC if we can offer it in one place with "native" widgetsets, that is inside Lazarus. Inside the IDE with community of developers and users, not one-man project IDE-s. Plus Lazarus would offer easy switch from "OS-native" to "Pascal-native" controls and the other way.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: The future of Free Pascal
« Reply #8 on: March 17, 2016, 11:32:21 am »
But fully working FPC-drawn LCL-widgetset, maybe will not feel native, but it will give you an option to have same look and feel everywhere. It must be nothing more but an option, the "native" widgetsets have to stay.

Maybe, but I don't think that will satisfy users at all, and if you go in that direction, the LCL (setup as a native widget library) shouldn't be your target in the first case.

Quote
I believe that there are people who prefer this to "nativeness" and I believe that having it in LCL will be more helpful for wide-spreading FPC and Lazarus than telling people to go to one-man projects like MSE or fpGUI.

I think it would be a good thing, but as stop gap for unsupported or incomplete targets, quick start on new targets and the odd embedded application. OTOH in practice it might actually inhibit making a proper port to a new target.

But no, I don't really expect that any significant amount of people will chuck out their win32 or *nix desktop LCL backend and start using customdrawn widgetsets on those targets for consistency of look and feel.

And therefore customdrawn widgetset probably would also be a one-man show, or one man per backend (e.g. customdrawn-bitmap and customdrawn-opengl) and non mainstream, just seriously hampered by LCL system architecture.

Still a good thing, but not "the future of Free Pascal". Not even remotely close.

Quote
Not because these projects are not good, but new user will certainly more likely decide to stay with FPC if we can offer it in one place with "native" widgetsets, that is inside Lazarus. Inside the IDE with community of developers and users, not one-man project IDE-s. Plus Lazarus would offer easy switch from "OS-native" to "Pascal-native" controls and the other way.

I think the attraction of customdrawn would be embedded users and new targets. Targets that can afford a minimal customdrawn driver, but not a full backend. I sincerely doubt the uniformity being an attraction, since it would degrade look and feel on popular targets in favour of minority targets.

There always will be exceptions to any rule, but I think those will be very rare, if they exist at all.  The glacial progress on customdraw says enough about the viability of this route. At least fpgui and msegui HAVE one continuously working person on them.

p.s. I feel very weird defending fpgui and msegui.
« Last Edit: March 17, 2016, 12:32:39 pm by marcov »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: The future of Free Pascal
« Reply #9 on: March 17, 2016, 12:29:40 pm »
Good points about the GUI, I'll have to think about it. And I have looked at signed distance fonts and the demo.

About the distributed computing: I already build one a few years ago (in vb.net) for a company. At the moment I'm looking into genetic sequencing, which has data sets of ~ 0.5 TB, and I would like to spawn thousands of processes (or more) if that much computers are around. As genetic sequencing is like making many, different jigsaw puzzles of the same (huge) picture, where all the resulting pieces exist multiple times but are all damaged, it is mostly a question of reconstructing the original image by comparing all the millions of pieces in a loose way ("looks like"). So I want to be able to have processes spawn other processes on demand, I don't care where they end up, and I want to broadcast messages like: "who has a piece that somewhat resembles this one?"


Zath

  • Sr. Member
  • ****
  • Posts: 391
Re: The future of Free Pascal
« Reply #10 on: March 17, 2016, 12:43:44 pm »
Well, Delphi is as good as dead. And, to be honest: good riddance. As the developments of the last ten years were nothing to write home about.


Is Delphi dead ?
Seattle might be a high cost line of products and out of reach of many hobbyists but it's hardly dead. In which case, do you still follow it's lead ?
If not, do we risk a fragmentation of pascal that will eventually be its deathknell.

Thaddy

  • Hero Member
  • *****
  • Posts: 14157
  • Probably until I exterminate Putin.
Re: The future of Free Pascal
« Reply #11 on: March 17, 2016, 01:07:00 pm »
Delphi is dead and has been dead for a couple of years. Hence the bitterness that whas publicly seen in the last blog post of Allen, who saw a 100+ development department turn into 1 + online available highly schooled but part-time payed specialists from
abroad. "Abroad" means to a US citizen either from Europe, [edit] Japan [/edit]or from mars. (really hard to understand).

That aside: as a language on its own, Object Pascal has a lot of strengths.
Most notably you don't have to write begin and end macro's to replace brackets. And it has parameter declarations in a rather good order (unless you are expecting Polish notation e.g. Forth).
And it is almost as readable (by convention, not by design) as Python.

But of course I am trying through the Dutch court to have my name changed into Donald Trump.
As in trumpety trump trump trump trump (child song, or the toydolls version: https://www.youtube.com/watch?v=9m7tPikH0UA)

Which basically means the US will end up with a female president who happens to be proficient in Pascal....
« Last Edit: March 17, 2016, 01:18:55 pm by Thaddy »
Specialize a type, not a var.

balazsszekely

  • Guest
Re: The future of Free Pascal
« Reply #12 on: March 17, 2016, 01:29:08 pm »
I think we should concentrate on the future of Desktop programming not pascal in particular. Native apps will have their place in the future, but desktop development it is going to be a very small piece of the programming pie. Not c, c++, python or other fancy(or not) language kills pascal but the web combined the lack of pascal related jobs.

mischi

  • Full Member
  • ***
  • Posts: 170
Re: The future of Free Pascal
« Reply #13 on: March 17, 2016, 01:29:47 pm »
My 2 cents about a platform independent UI:
I agree with Marcov. I can envisage a simple bare bones UI, suitable for embedded stuff, but the task for a general desktop UI is far too large. It is some time ago, when i dealt with the UI of a program. Only that made me actually aware of the amount of design work and investigating user interactions, which is required. As miserable as UIs of current desktop systems may appear, it is an enormous task to even get to that level. But this would not suffice, because you need to be much better than the existing ones. Otherwise users will not switch to such an UI, which is alien to them.

MiSchi

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: The future of Free Pascal
« Reply #14 on: March 17, 2016, 01:55:26 pm »
Delphi is dead

And STILL they push out new versions faster than us :-)

 

TinyPortal © 2005-2018