The future of Free Pascal

[HappyDragon]

Hi!

This is my first post here but since I've been using Lazarus/FPC since a year back on hobbyist level I thought why not join the discussion? Especially since this thread seems it would be happy for new ideas.

Strength of FP? Same as for all Wirthian languages - strong typing and fast compilation. Working in a Wirthian language sometimes makes you cry due to verbosity and stiff type system but these drawbacks have been largely negated by wise design changes over the decades. TP4 basically solved the problems with its' hardware related additions.

I guess asking for Oberon-2 inclusion in the next FPC release is unrealistic?

My thoughts for the future of FPC or any RAD environment is that they look very much the same as they did around the turn of the millennium. When I started Lazarus last year i recognized most things immediately even though I haven't coded professionally (as in "coding for a living") for almost fifteen years.

I think we basically have the languages we need and future development should be to make tasks simpler by providing as many ready to run classes as possible and not trying to be all things to all people.

This means if the guy with his Atari ST cannot do all things then so be it. Try to do a few things well and drop the rest. I do not mean to remove support for all minor systems but don't focus on them. Apple has excelled at this. Also this deliberate removal of options is what made VB and Delphi great - they solved the everyday problems with a lot less coding.

If I am to contribute new ideas, I guess why not bring up the Internet of Things. I do not know if this is a hype or a dead end, but it is something I have not seen anyone bring up in this thread. I wonder if it might be possible to make FPC for embedded devices like Raspberry Pi, Arduino and similar devices.

The Arduino lacks a GUI and this might be a project that could bring real benefit. I'm also thinking about a complete framework that makes it easy to build a system from Arduinos or similar devices loaded with FPC/Embedded programs and make them communicate in a simple way. There are plenty of Arduinos and add-on boards but not so much in terms of framework and GUIs.

Basically this would require an event driven TCP/IP package similar to lNet, a simple 2D graphics library, a minimal set of custom drawn widgets using said 2D lib, a message passing mechanism like DBUS (but infinitely simpler) and some modifications to FPC. It would also be necessary to implement bindings to certain hw features like timers and add reserved words to implement processes. Maybe this is unrealistically much.

One idea is to attach variables to TCP/IP messages so that writing to a variable will send a message to connected tasks on other nodes and e. g. update a visual control. The idea is to connect signal from variables/inputs to messages and then to slots in e. g. visual controls.

Ok, I think I have dreamed enough for one post so I'll stop here.

[marcov]

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.

Development has become managed. If it is regularly not featured in the management periodical, it doesn't exist. At least not except for small business and more specialized firms.

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.

Indeed, what actually amazes me more when talking too such people, is not that they don't know minority players, but that even for the more popular techniques there is much confusion about what is new experimental and what is established.

[marcov]

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.

Afaik Kassandra was coined on the lazarus list, but maybe I remembered wrong and it was, like Lazarus, also announced on the Megido list.

BUT kassandra/kcl took a long time, and for the first products he used a simple OO gtk wrapper fpgtk (the same that the old fpdoc gui used iirc). Then later (and iirc several years later), while KCL/Kassandra was still not production ready, he made fpgui because he also had to deliver windows guis for some customer, this time owner drawn.

So while Kassandra and Lazarus might indeed be contemporaries (and in theory Sebastian could also have worked on Kassandra/KCL before going public, making it older), I'm pretty sure that fpgui was considerably younger, more at the end of actual work on Kassandra/KCL, not the beginning.

[kupferstecher]

Why are people using free pascal ?

One year before I started using FPC/Lazarus, the main reason was the "platform independence" without a runtime interpreter.

After some time I realized that the widgetset is tied quite close to the system and thus porting needs further efforts. But also within one system, in my case windows, the controls have many restrictions, as they are organised by the system and thus events or settings are not accessible by the programm, different controls have quite different techniques and properties.

Having a complete set of customdrawn controls as said in the initial post might help here.

I'm sure that the implementation of native controls on the several platforms as its done now, is a very high effort and the behaviour on two plattforms of one component will always differ a little.
If all controls are custom drawn, they probably all have the same system anchestor and could be abstracted from the system. So I guess even the design of the customdrawn control is somehow platform independent.
Like the TWinControl.PaintTo: while in Windows the control has to be set to visible to work correctly, in GTK2 it actually has to be visible on the screen to generate a correct result. In contrast a customdrawn control could provide its bitmap independently of the platform.

This means a unique look and feel wouldn't be the feature but a side effect.

Anyways a set of native controls would be still required. Like buttons in dialogs should always be system conform. File dialogs of course also have to be native.


The second reason why I choose FPC/Lazarus was the pascal syntax. Nevertheless I think in some aspects the syntax is kind of outdated and I'm sure it prevents and will prevent a number of programmers from starting with FPC.

For readability of the code I prefere having an "end;" instead of "}" delimiting a block (Reason for FPC). On the other hand the "begin" keyword always seems useless to me, the same holds for the semicolon on the end of each statement.

Changing the syntax of course is a major change and for a programmer already used to it, it's not worth to change. But if new programmers and non-Delphi programmers avoid FPC then FPC might fade out over the time. Backwards compatibility of course is obligatory.

[marcov]

Strength of FP? Same as for all Wirthian languages - strong typing and fast compilation. Working in a Wirthian language sometimes makes you cry due to verbosity and stiff type system but these drawbacks have been largely negated by wise design changes over the decades. TP4 basically solved the problems with its' hardware related additions.

Standalone executables.  Interfacing to other native libraries. (C++ could be easier but is unfortunately compiler and -version dependent)

I guess asking for Oberon-2 inclusion in the next FPC release is unrealistic?

Very. The frontend is a parameterized pascal frontend, not a multi frontend. And I would prefer Modula2 more.

I think we basically have the languages we need and future development should be to make tasks simpler by providing as many ready to run classes as possible and not trying to be all things to all people.

I do think the bottlenecks are in the libraries and multitarget support, and less in language as most people seem to think.   Compatible unicode support and the D2010 level RTTI are the most important ones there.

Anonymous methods, maybe but only because existing Delphi attempts at thread libraries use it heavily, and less because I think it is so great.

This means if the guy with his Atari ST cannot do all things then so be it. Try to do a few things well and drop the rest. I do not mean to remove support for all minor systems but don't focus on them.

An open source project like FPC and Lazarus have no assignable manpower. People work on what they want/need.

Apple has excelled at this. Also this deliberate removal of options is what made VB and Delphi great - they solved the everyday problems with a lot less coding.

Apple became a business success again, but it was quite a break on a technical level (for people with deep investments in Apple software). At lot of the small software vendors for Apple went under, several architecture changes (PowerPC,PowerPC64, i386) in fairly rapid succession, the carbon api was deprecated, change of languages to Objective C and later Swift etc etc.

So if you take Apple as an example for FPC's future course I shiver. That is exactly what I think is unrealistic, even if you would want to. FPC is not in a position to dictate market conditions like Microsoft, Oracle and Apple.

If I am to contribute new ideas, I guess why not bring up the Internet of Things. I do not know if this is a hype or a dead end, but it is something I have not seen anyone bring up in this thread. I wonder if it might be possible to make FPC for embedded devices like Raspberry Pi, Arduino and similar devices.

FPC runs on embedded devices a long time. I ran FPC programs on ARM PDAs in 2003.   FPC is in raspbian from very early on (though currently afaik an old and patched version)

The Arduino lacks a GUI and this might be a project that could bring real benefit. I'm also thinking about a complete framework that makes it easy to build a system from Arduinos or similar devices loaded with FPC/Embedded programs and make them communicate in a simple way. There are plenty of Arduinos and add-on boards but not so much in terms of framework and GUIs.

Arduino is mostly the shield format. There are actually several different architectures, one of which (AVR32) is supported by newer versions FPC.

For the rest Arduino is software, but if you don't use the standard IDE/software solution, that doesn't matter much, just like you don't use the default python interface on RPI

Basically this would require an event driven TCP/IP package similar to lNet, a simple 2D graphics library, a minimal set of custom drawn widgets using said 2D lib, a message passing mechanism like DBUS (but infinitely simpler) and some modifications to FPC. It would also be necessary to implement bindings to certain hw features like timers and add reserved words to implement processes. Maybe this is unrealistically much.

Why bother if there are X and VNC etc ?  I don't see any practical benefit in this, except that it will be very complicated (and multiply versioned, since client and server might not match)
 
And really embedded solutions might not even have ethernet, or too slow to manage lugging around the required bitmaps.

Maybe there is some specialized usecase, but I don't think it is anything mainstream.

[Laksen]

This is all my own opinion of course..
People talk a lot about the language. I don't think there are any problems in the language, or areas to improve a lot.

But looking over the RTL and packages, and working with it in a fairly low-level way I think there are a few spots where I continuously run into small missing pieces or fairly old crufty code.

Overall it's all great. I rarely hit roadblocks, but I very often run into:

• No simple sorting functions available
• No serial port access - Resort to using Synaser
• Too simple OOP sockets - Starting to get better, and not far off from being fully featured. Resort to synapse otherwise
• Very limited in crypto - Resorting to synapse or dcpcrypt
• No modern numerical methods or matrix functions - or at least not the right ones

Many of those are fairly easy to fix, and some not so easy of course..

I've tried to sum up my thoughts in the attached image where I've color coded to match what my thoughts of the different areas of the inbuilt offerings are at today, and added some areas I think would be nice to add. And some borders about where I personally will be focusing in the near and long future

[Leledumbo]

What is the fundamental strength of free pascal over all the other languages ?

As a language? I vote on strong static typing and safety features (e.g.: overflow and range checking AFAIK is defined as language feature instead of compiler feature)

Why are people using free pascal ?

Most articles I read praise the compilation speed while producing optimized enough binaries. Also the bunch of pre-shipped libraries so that people don't need to grab libraries from here and there anymore.

What do they mostly do with it ?

Rapid GUI prototyping, scientific computation, ethical hacking and the standard db driven apps.

What is our weakness ?

• Less optimized binary than top level competitors, though AFAIK we are still the best among truly free open source implementations
• Missing language level concurrency, I find this to be hard to be implemented in libraries as switching concurrent<->non-concurrent code is non-trivial
• Scattered and missing documentation here and there

[jc99]

This is just a thought:
Even if delphi seems dead, pascal isn't. In my line of work i use a "sort or pascal" called CoDeSys-StructuredText for process-automation. They have a nice feature called "online-change", it means you can (under certain conditions) update the executable while it is (keeps) running. Even Siemens-SCL looks/feels more like Pascal than C.

On topic:
One weakness at the moment is the FCL, many components seem to offer needed functionality, but they are limited to some OS only.
Im talking about the FCL-async, FCL-net and other FCL-Components. A good scrub through the code, some more OS-indepency, OS-independent examples, and (maybe) a better integration in Lazarus would help.
Integration in Lazarus as some sort of advertising, that there are these basic components, ready to use. e.G: I made a (Dummy-)Package putting the fphttpclient and fphttpServer in the fpWeb-Group. (See picture)
If anybody's interested, i'll share.

@leledumbo: I somtimes look at the Underhanded-C contest (http://www.underhanded-c.org/) and (gladly) see that these features are mostly not possible in pascal by design.

[ArtLogi]

Hah, it is not miracle that ST / SCL looks and feels like a Pascal,because it is based on it (or ADA / wirthian) atleast from sources I have read. Yes, that is one reason Pascal will not die any time soon. Everyone who have their first contact of serious programming through IEC 61131-3 languages (ST), will see Pascal as more familiar than non wirthian competitors, which means that there is lots of folks that would benefit of coding in Delphi/OPascal in industrial circles.

It is also one of the many reasons I felt like FPC is better solution to myself than C (with add ons).

[Leledumbo]

@leledumbo: I somtimes look at the Underhanded-C contest (http://www.underhanded-c.org/) and (gladly) see that these features are mostly not possible in pascal by design.

Add ioccc as well. Like I always said to non-Pascal programmers, Pascal is your friend while programming, it doesn't let you do many stupid things. You'll feel like doing pair programming with your compiler, while when doing that with C it's just a translator tool, although it's trying to be friendlier these days (but you need to specify -Wall all the time).

[SymbolicFrank]

Why bother if there are X and VNC etc ?  I don't see any practical benefit in this, except that it will be very complicated (and multiply versioned, since client and server might not match)
 
And really embedded solutions might not even have ethernet, or too slow to manage lugging around the required bitmaps.

Maybe there is some specialized usecase, but I don't think it is anything mainstream.

The simplest answer is, that most machines nowadays (except the simplest) don't run on a single micro-controller, but include many of them, all connected through various networks. They are all treated like devices, each with its custom interface. And there is a PC at the top level, that most often runs MS Windows, with the GUI application.

So, it's not a single application, but a collection of custom applications, networks and interfaces.

They all require some operating system, programming language, etc. And they all tend to have a different developer or team assigned, making their own implementation choices.

An obvious example is a car. A simple car contains more than 50 micro-controllers, with more than 100 for the luxurious models. And the dashboard is more and more becoming a set of displays, running GUI applications.


In the past, "embedded" was synonymous with small and low power, like a single 1 MHz 8 bit CPU, with 1 KB RAM and 8 KB ROM. Today, it is a collection of micro-controllers, of which the simplest might still be 8 bit, but it runs at 32 MHz, has 32 KB RAM and 256 KB ROM. And the fastest ones are 64 bit, run at 1GHz+, have 4+ CPUs, a DSP or SIMD processor, a GPU, and gigabytes of RAM. Like an average PC.

They are connected serially at the lowest level, and the highest level tends to use Ethernet.

In other words: it's a whole office full of PCs, smart phones and calculators, crammed together in a small space. Running a single application, split into many different tasks.

[marcov]

The simplest answer is, that most machines nowadays (except the simplest) don't run on a single micro-controller, but include many of them, all connected through various networks. They are all treated like devices, each with its custom interface. And there is a PC at the top level, that most often runs MS Windows, with the GUI application.

What you provide is not an answer. Nearly everything cross-device is either the worst kind of lowest common denominator, or very specialized for a certain app domain.

[SymbolicFrank]

Ok. How about this one:

Most applications today are also split into multiple parts, some of which run on a smart phone (like a dashboard to check the current status), in a browser (for the reporting), on a database server (the stored procs) or other back-end server (for the business logic) and on a PC (for the data manipulation).

[serbod]

What you provide is not an answer. Nearly everything cross-device is either the worst kind of lowest common denominator, or very specialized for a certain app domain.

May be for classic single-user desktop application it's true. But in network age data shared between multiple users over network. Current FPC/Lasarus can offer only shared database components and low-level network components.

Modern systems work with shared objects/documents/forms, not only shared database tables. Every modern programming language can easily put any data type into string and restore back from string. On FPC it's possible for Variants and some interfaced objects. But how to do that?

[tr_escape]

...

If I am to contribute new ideas, I guess why not bring up the Internet of Things. I do not know if this is a hype or a dead end, but it is something I have not seen anyone bring up in this thread. I wonder if it might be possible to make FPC for embedded devices like Raspberry Pi, Arduino and similar devices.

The Arduino lacks a GUI and this might be a project that could bring real benefit. I'm also thinking about a complete framework that makes it easy to build a system from Arduinos or similar devices loaded with FPC/Embedded programs and make them communicate in a simple way. There are plenty of Arduinos and add-on boards but not so much in terms of framework and GUIs.

...

This man hacked the Modbus TCP protocol where he stayed in a hotel:

http://mjg59.dreamwidth.org/40505.html


Also KNX is another protocol can be easly hack:

https://www.defcon.org/images/defcon-22/dc-22-presentations/Molina/DEFCON-22-Jesus-Molina-Learn-how-to-control-every-room-WP.pdf

At first all ideas starts with simple way and this simplicity must be change to complexity because of somebody want to make control them.

Actually I am still closing my jalousie (curtain) by hand... IoT is marketing ideas generaly not thinking what will be happen in emergency situations.

Laz/Fpc can provide to implement of your protocol in serial/tcp with by host OS's API.

Also there are some nice components for this:

LazSerial

LNet

EDIT: Word correction