Lazarus

Free Pascal => General => Topic started by: SymbolicFrank on March 16, 2016, 11:10:19 pm

Title: The future of Free Pascal
Post by: SymbolicFrank 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.
Title: Re: The future of Free Pascal
Post by: Graeme 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 (http://fpgui.sourceforge.net). 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.
Title: Re: The future of Free Pascal
Post by: mse 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
Title: Re: The future of Free Pascal
Post by: Zoran 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...
Title: Re: The future of Free Pascal
Post by: marcov 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 (http://forum.lazarus.freepascal.org/index.php/topic,30556.msg194484.html#msg194484)
Title: Re: The future of Free Pascal
Post by: Zoran 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?
Title: Re: The future of Free Pascal
Post by: marcov 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.



Title: Re: The future of Free Pascal
Post by: Zoran 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.
Title: Re: The future of Free Pascal
Post by: marcov 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.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank 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?"

Title: Re: The future of Free Pascal
Post by: Zath 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.
Title: Re: The future of Free Pascal
Post by: Thaddy 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....
Title: Re: The future of Free Pascal
Post by: GetMem 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.
Title: Re: The future of Free Pascal
Post by: mischi 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
Title: Re: The future of Free Pascal
Post by: marcov on March 17, 2016, 01:55:26 pm
Delphi is dead

And STILL they push out new versions faster than us :-)
Title: Re: The future of Free Pascal
Post by: Graeme on March 17, 2016, 05:09:25 pm
However, these are one-man projects. One man develops, one man decides where the project will go...
Huh? I'm pretty open with fpGUI. Yes I obviously did most of the work, but I also accept many contributions... some were even massive contributions to the core of the framework itself.

A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me.  ;)
Code: [Select]
[fpgui (maint)]$ git shortlog -s -n
  2801  Graeme Geldenhuys
   867  graemeg
    85  Jean-Marc Levecque
    36  sekelsenmat
    32  drewski207
    26  Felipe Menteiro de Carvalho
    21  David Laurence Emerson
    19  Andrew Haines
    13  Jean-Marc
     5  Dibo
     4  Jean-Marc.Levecque
     4  Michael van Canneyt
     3  Andrew
     3  David Emerson
     2  Philippe Lévi
     1  Jean Pierre Anghel
     1  Micheal Fyffe
     1  Paul Breneman
     1  Rodrigo Aliotti
     1  Stéphane Aulery
     1  Charlie Root
     1  Fred van Stappen
     1  hinst
     1  jean-marc
     1  jp anghel
     1  ArtSvetlakov
     1  Clemens Capitain

Quote
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.
That's exactly what the LCL-fpGUI widgetset is. I don't actively develop it, simply because I think LCL is rubbish. Very inconsistent, slow, bloated and too Windows-like [on other platforms]. LCL-fpGUI also reduces the functionality, flexibility and power of fpGUI widgets. Saying that, I do contribute patches every now and again to make sure it still works with the latest stable fpGUI. I've also implemented all the basic widgets (excluding TLabel).
Title: Re: The future of Free Pascal
Post by: Graeme on March 17, 2016, 05:14:39 pm
And STILL they push out new versions faster than us :-)
Simply because that makes the people - spending thousands on Delphi licenses per year - feel like they are getting something for their money. ;) A good business tactic. It sucks for the developers though. Nobody upgrades their projects to new Delphi versions that quick.
Title: Re: The future of Free Pascal
Post by: marcov on March 17, 2016, 05:39:30 pm
And STILL they push out new versions faster than us :-)
Simply because that makes the people - spending thousands on Delphi licenses per year - feel like they are getting something for their money. ;) A good business tactic. It sucks for the developers though. Nobody upgrades their projects to new Delphi versions that quick.

Euh, the "people" and "developers" in your reply are the same?

The new mandatory subscription sucks indeed though, I hope it doesn't last. I bought Seattle in October though (mainly because 64-bit debugger is fast & more stable), so I'm good for a while :-)
Title: Re: The future of Free Pascal
Post by: skalogryz on March 17, 2016, 06:08:15 pm
A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me.  ;)
What happens to the project, if you would be gone tomorrow? 

What the "future of fpGUI" would be?

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.
Title: Re: The future of Free Pascal
Post by: Zoran on March 17, 2016, 07:02:38 pm
However, these are one-man projects. One man develops, one man decides where the project will go...
Huh? I'm pretty open with fpGUI. Yes I obviously did most of the work, but I also accept many contributions... some were even massive contributions to the core of the framework itself.

A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me.  ;)
Code: [Select]
[fpgui (maint)]$ git shortlog -s -n
  2801  Graeme Geldenhuys
   867  graemeg
    85  Jean-Marc Levecque
    36  sekelsenmat
    32  drewski207
    26  Felipe Menteiro de Carvalho
    21  David Laurence Emerson
    19  Andrew Haines
    13  Jean-Marc
     5  Dibo
     4  Jean-Marc.Levecque
     4  Michael van Canneyt
     3  Andrew
     3  David Emerson
     2  Philippe Lévi
     1  Jean Pierre Anghel
     1  Micheal Fyffe
     1  Paul Breneman
     1  Rodrigo Aliotti
     1  Stéphane Aulery
     1  Charlie Root
     1  Fred van Stappen
     1  hinst
     1  jean-marc
     1  jp anghel
     1  ArtSvetlakov
     1  Clemens Capitain

Graeme, sorry. Yes, you are open to contributions. I just think that fpGUI (currently at least, this might change in future) have much smaller community than Lazarus, and you just have to do most of the work yourself. I still think that it has to be taken into account that it is currently mostly one-man project.
Okay, you might get more fpGui developers in the future and I hope you will.

Quote
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.
That's exactly what the LCL-fpGUI widgetset is. I don't actively develop it, simply because I think LCL is rubbish. Very inconsistent, slow, bloated and too Windows-like [on other platforms]. LCL-fpGUI also reduces the functionality, flexibility and power of fpGUI widgets. Saying that, I do contribute patches every now and again to make sure it still works with the latest stable fpGUI. I've also implemented all the basic widgets (excluding TLabel).

Yes, I know that is what LCL-fpGUI widgetset is, but it is not fully working (like win32/64, GTK2, Qt, Carbon). Since you think LCL is rubish, I doubt LCL-fpGUI will ever get into fully working state unless someone else makes serious effort to implement it. And I'm sure he will get full support from you, despite what you think of LCL.

It is normal that LCL-fpGUI cannot reach the full functionality of fpGUI itself, but having it as fully working LCL backend will be just enough for the need I am talking about - a Lazarus user will be able to easily switch between OS-native and Pascal-native GUI library.
Title: Re: The future of Free Pascal
Post by: mica on March 17, 2016, 07:29:49 pm
just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention
Title: Re: The future of Free Pascal
Post by: taazz on March 17, 2016, 07:38:41 pm
just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention
If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.
Title: Re: The future of Free Pascal
Post by: JD on March 17, 2016, 07:58:50 pm
just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention
If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.

I think so too. There was a certain discussion about that when Orca was first introduced.

JD
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 17, 2016, 11:21:30 pm
Ok, a minimal OpenGL GUI to start, for devices that don't have an LCL, but do have a GPU, sounds low-entry. Very doable.

But, we could go much farther in that. Because of native controls requiring both a language interface for the events (hard problem in many cases), and support of the widget sets (lots of work). And the platform independent interfaces being pixel-based.

OpenGL is a standard. Yes, the implementation can be lacking, but with the shader model, we don't really need much more than surfaces (triangles and rectangles), textures and shaders. Most everything else is irrelevant.

Ok, a fast geometry shader would help immensely, for things like drawing controls and (especially) fonts. Or calculating the initial signed distance font texture. But those are all things that can be calculated up front.


As we are all programmers and not artists, making things slick looking is hard work. Nice to have and to look at, but that can be done at the end, to make it better.

If we start with the minimal requirements to make it work, it is very doable.


But, yest, that will be most of the work. I could do a distributed computing library in a few weeks time by myself, comparatively.
Title: Re: The future of Free Pascal
Post by: JD on March 18, 2016, 12:11:44 am
just about OpenGL:
Orca from Code Typhon is a OpenGL GUI.

just to mention
If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.

Some links

https://jonlennartaasenden.wordpress.com/2015/05/04/pilotlogic-and-codetyphon-in-clear-violation-of-copyright-law/ (https://jonlennartaasenden.wordpress.com/2015/05/04/pilotlogic-and-codetyphon-in-clear-violation-of-copyright-law/)

http://forum.lazarus.freepascal.org/index.php?topic=24006.0 (http://forum.lazarus.freepascal.org/index.php?topic=24006.0)

http://www.progtown.com/topic1898592-codetyphon-arguing.html (http://www.progtown.com/topic1898592-codetyphon-arguing.html)

JD
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 12:14:41 am
What happens to the project, if you would be gone tomorrow? What the "future of fpGUI" would be?
The same thing as what happened in the past... It continues with anybody interested. It's open source, the code is right there - available in the open.

I didn't start the fpGUI project, I found it [abandoned] in a FPC repository. Yes I might have completely rewritten in from scratch, and developed it for much longer than the original developer, but I enjoy the project so continue the effort. A huge bonus is that I now write all my personal and company software with it, simply because it is so easy to use, very consistent across platforms, and overcomes many LCL deficiencies.

The point being, somebody else created it [fpGUI], lost interest a while later, somebody else [me and others] picked it up again and carried it forward. The world is full of such open source examples.

Quote
I see no correlation between "free pascal" as a language, another UI library and state of Delphi. Imho, all three are quite independent entities:
Indeed. I fully agree.
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 12:49:32 am
I just think that fpGUI (currently at least, this might change in future) have much smaller community than Lazarus,
Also take into account that Lazarus [at the time] offered something extra that didn't exist in fpGUI. An IDE, Delphi compatibly, close ties to the Free Pascal project etc. Those were the promised features that drew the crowd towards the Lazarus project. That's what built its momentum.

I made many choices with fpGUI Toolkit. I didn't want to implement an IDE - I wanted it to be IDE agnostic (you should only require FPC). I didn't bother with Delphi compatibility because I saw better solutions, I wanted custom drawn because its more flexible and portable. Not everybody agrees with these choices, but it sure worked for me, and fpGUI is better now because of it.

The world is full of examples of inferior products finally winning the competition: Betamax vs VHS, OS/2 vs Windows, Netscape vs IE, Firewire vs USB, SCSI vs IDE etc. I'm not bothered about fpGUI's popularity vs Lazarus. fpGUI works for me, and that's what I care about [plus it was a great learning experience that I still enjoy].

Quote
Yes, I know that is what LCL-fpGUI widgetset is, but it is not fully working (like win32/64, GTK2, Qt, Carbon). Since you think LCL is rubbish, I doubt LCL-fpGUI will ever get into fully working state unless someone else makes serious effort to implement it.
Just so you know, I did not start the LCL-fpGUI widgetset. I believe it was Andrew Haines. The biggest lacking widget currently holding back LCL-fpGUI is the TLabel widget. It is that widget which also causes application crashes at runtime when used. TLabel is a classic example of LCL's over engineering and Windows-ism. A seemingly simple widget, yet in LCL it is quite complex to implement. I simply don't have the time [or motivation] to study LCL in depth to figure it out. Implementing the other LCL widgets [I have contributed a few] was actually pretty simple.

Quote
And I'm sure he will get full support from you, despite what you think of LCL.
Of course. If anybody wants to work on LCL-fpGUI and needs technical information about fpGUI, I will gladly help out where I can.

Quote
It is normal that LCL-fpGUI cannot reach the full functionality of fpGUI itself, but having it as fully working LCL backend will be just enough for the need I am talking about.
I've always believed that a fully implemented LCL-fpGUI widgetset will be hugely beneficial to the Lazarus project. I know I would instantly recompile the Lazarus IDE to use fpGUI instead of GTK2 or Qt.
Title: Re: The future of Free Pascal
Post by: skalogryz on March 18, 2016, 05:23:02 am
I didn't start the fpGUI project, I found it [abandoned] in a FPC repository.
Huh. Learn something new every day!
I always considered you the author of the library.
Title: Re: The future of Free Pascal
Post by: marcov on March 18, 2016, 09:51:50 am
I didn't start the fpGUI project, I found it [abandoned] in a FPC repository.
Huh. Learn something new every day!
I always considered you the author of the library.

No, that was Sebastian Guenther. And fpgui was a rewrite of earlier OO gtk wrapper fpgtk to also have non GTK windows support. He also had a stab at writing an own delphi like lib "KCL" and ide "Kassandra", but that took too long, and fpgtk and fpgui were written because he needed GUIs for his business quickly.

The last time I spoke him, he said he was amazed how far Lazarus has come and said he was using it.

Sebastian also did quite some work on the early Delphi related libraries (sysutils, classes, fcl-base), working together a lot with Michael. They also collaborated on fcl-passrc/fpdoc I think, but I'm not entirely sure there, it might be all Michael.
Title: Re: The future of Free Pascal
Post by: serbod on March 18, 2016, 09:55:01 am
Age of text consoles. Pascal was plain (without objects and interfaces), with inline assembler. Comfort way to deal with low level hardware/OS.

Age of text/graphics CGA, MS-DOS. TurboPascal/ObjectPascal is objective-based. TurboVision library. Comfort way to deal with interactive forms.

Age of graphics GUI desktops, MS-Windows. Delphi, VCL. Comfort way to develop GUI applications with database connectivity.

Age of networks. Client-server applications. Delphi up to 7 with wide set of components for GUI, networking and database. Comfort way to build almost any system for business.

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

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.



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

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.

See TTreeView and TListView - you care only about items contents and order, not for they coordinates, rows, columns and fonts sizes and styles. Sizes can be changed by user or automatically on whole list/tree resize. And virtual list not contain any data, it just show data from some source. You don't need to synchronize data in visual list and inside code. Same in "Data Controls", but they works only with tables, not with single objects.

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.
Title: Re: The future of Free Pascal
Post by: marcov on March 18, 2016, 10:33:26 am
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)

Quote
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.

Quote
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)

Quote
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.

Quote
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.

Quote
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.

Quote
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.
Title: Re: The future of Free Pascal
Post by: marcov on March 18, 2016, 10:53:45 am
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) 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.
Title: Re: The future of Free Pascal
Post by: serbod on March 18, 2016, 12:36:58 pm
Quote
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..).
Title: Re: The future of Free Pascal
Post by: marcov on March 18, 2016, 01:27:10 pm
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


Quote
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).

Quote
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 :-)
Title: Re: The future of Free Pascal
Post by: serbod on March 18, 2016, 02:54:04 pm
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.

Quote
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.

Quote
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. =)
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 18, 2016, 04:04:33 pm
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).
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 04:51:00 pm
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. ;)
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 04:55:37 pm
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.
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 05:05:28 pm
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.
Title: Re: The future of Free Pascal
Post by: marcov on March 18, 2016, 05:06:27 pm
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 :-)
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 05:09:33 pm
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.
Title: Re: The future of Free Pascal
Post by: Graeme on March 18, 2016, 05:14:24 pm
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.
Title: Re: The future of Free Pascal
Post by: mse on March 18, 2016, 05:36:49 pm
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
Title: Re: The future of Free Pascal
Post by: skalogryz on March 18, 2016, 06:17:13 pm
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.
Title: Re: The future of Free Pascal
Post by: jc99 on March 19, 2016, 12:08:49 pm
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.
Title: Re: The future of Free Pascal
Post by: HappyDragon on March 19, 2016, 02:12:01 pm
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? :D

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.
Title: Re: The future of Free Pascal
Post by: marcov on March 19, 2016, 02:26:46 pm
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.

Quote
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.
Title: Re: The future of Free Pascal
Post by: marcov on March 19, 2016, 02:44:43 pm
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.
Title: Re: The future of Free Pascal
Post by: kupferstecher on March 19, 2016, 02:58:49 pm
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.
Title: Re: The future of Free Pascal
Post by: marcov on March 19, 2016, 03:45:52 pm
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)

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

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

Quote
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.

Quote

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.

Quote
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.

Quote
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)

Quote
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

Quote
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.
Title: Re: The future of Free Pascal
Post by: Laksen on March 19, 2016, 03:50:41 pm
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:

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 :)
Title: Re: The future of Free Pascal
Post by: Leledumbo on March 19, 2016, 04:43:34 pm
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 ?
Title: Re: The future of Free Pascal
Post by: jc99 on March 19, 2016, 05:04:21 pm
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.
Title: Re: The future of Free Pascal
Post by: ArtLogi on March 19, 2016, 05:17:08 pm
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).
Title: Re: The future of Free Pascal
Post by: Leledumbo on March 19, 2016, 06:12:54 pm
@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).
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 21, 2016, 01:47:28 pm
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.
Title: Re: The future of Free Pascal
Post by: marcov on March 21, 2016, 02:09:37 pm
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.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 21, 2016, 02:31:14 pm
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).
Title: Re: The future of Free Pascal
Post by: serbod on March 21, 2016, 03:00:30 pm
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?
Title: Re: The future of Free Pascal
Post by: tr_escape on March 21, 2016, 03:28:27 pm
...

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
Title: Re: The future of Free Pascal
Post by: marcov on March 21, 2016, 03:39:06 pm
Ok. How about this one:

Most applications today are also split into multiple parts

And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.
 
Title: Re: The future of Free Pascal
Post by: ArtLogi on March 21, 2016, 04:04:27 pm
Imagine how bad the situation is in becoming years if that so called "internet of things" will roll out succesfully.  %) Someone just can put your firealarm off, stove on, toaster on and turn the freezer off and wait your house get on flames, if that not happen atleast your freezer just leaked on the floor.

...

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
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 21, 2016, 05:11:23 pm
Ok. How about this one:

Most applications today are also split into multiple parts

And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.

"Write Once, Compile Anywhere."
Title: Re: The future of Free Pascal
Post by: korba812 on March 21, 2016, 06:34:07 pm
The only thing missing in compiler are packages (like BPL in Delphi).
It is good that LCL uses native controls. I know that I do not have such control over the drawing as in the case of custom draw controls. I usually create database applications that use real people who may have poor eyesight. Usually, they set desktop environment first (like big fonts, high contrast). LCL application respects these settings. Some of them use tools like narrator (text to speech) that works in most of LCL controls. But it does not work for custom draw controls.
Title: Re: The future of Free Pascal
Post by: Zoran on March 21, 2016, 06:37:26 pm
Ok. How about this one:

Most applications today are also split into multiple parts

And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.

"Write Once, Compile Anywhere."

Should anywhere be taken so literally?? No, you actually cannot compile pascal code with a car.
Title: Re: The future of Free Pascal
Post by: ArtLogi on March 21, 2016, 07:43:08 pm
Ok. How about this one:

Most applications today are also split into multiple parts

And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.

"Write Once, Compile Anywhere."

Should anywhere be taken so literally?? No, you actually cannot compile pascal code with a car.
You can while sitting in the car, then you are compiling it in the car.  :P
Title: Re: The future of Free Pascal
Post by: tr_escape on March 21, 2016, 07:48:22 pm
Ok. How about this one:

Most applications today are also split into multiple parts

And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.

"Write Once, Compile Anywhere."

Should anywhere be taken so literally?? No, you actually cannot compile pascal code with a car.
You can while sitting in the car, then you are compiling it in the car.  :P


Also

Write once, compile to anywhere in somewhere: Means compile from supported OS to another operating system or system (like as embedded and has no operating system).

I can create in Linux to Windows like as :

https://github.com/mehmetulukaya/muterm (https://github.com/mehmetulukaya/muterm)

Also I can create in Windows to WinCE applications with Kol-Ce like as:

https://mehmetulukaya.wordpress.com/2011/02/04/lazarus-kol-ce-ve-windows-ce-uygulamasi/ (https://mehmetulukaya.wordpress.com/2011/02/04/lazarus-kol-ce-ve-windows-ce-uygulamasi/)

In this case Lazarus is most powerful Pascal compiler.


EDIT: Some grammar issue
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 21, 2016, 10:37:37 pm
If I have a project that requires something, I can write it myself. Whatever it is. It doesn't matter. That's not the issue.

I do like to choose FPC / Lazarus, when I have the choice. And it does tend to be the best / fastest choice. And for a bonus, it's free as well.

But it is very focused on single-task, database aware desktop applications. And while that certainly fit the bill of most applications I wrote 15 years ago, it doesn't anymore.

Almost every application, even if it is a simple tool, has interactions with many different platforms. From embedded, through databases to web. And I would really want to write it all in FPC / Lazarus. And regularly, I can, but only if I chop it up into multiple, independent applications, all with their own target. There is no awareness or interaction between them.


But, Frank, you're asking too much! That's not what Free Pascal is about! It is about porting the 15 year old VCL to as many platforms as possible, as LCL. And that's it!


Hm, yes, ok. So, no $3 WiFi targets, no splitting the workload between different tasks, and only a small chance of an independent GUI for embedded targets out of the box. DIY.

But still a large chance of implementing everything Delphi, even if it is extremely questionable if they have taken smart decisions about the developments in the last decade.


And the reason I choose FPC / Lazarus, is primary the rich library that is consistent and works out of the box.

That's also one of the reasons why I regard C++ as a language for masochists. Next to it being unreadable (the interpretation of everything depends on the scope and pre-processor) and encouraging you to shoot yourself in the foot. Not that I'm not often required to use it, because everyone and their manager thinks that's the smart choice, because it is what they think everyone else is using.

In C++ the choice is simple: you do have to write everything yourself. And in Lazarus, I have to write more and more myself as well.
Title: Re: The future of Free Pascal
Post by: marcov on March 21, 2016, 10:49:42 pm
"Write Once, Compile Anywhere."

So?  The question is if you really need 5 exactly the same webservers on the component systems rather than one web(app)server and various specialized clients. (and anyway I covered this under "lowest common denominator" already. Even if it works, it is fairly pointless. Nobody wants 8051 constraints on a PC and vice versa)

And as advanced as Lazarus is, it won't automatically add those roles for you O:-)
Title: Re: The future of Free Pascal
Post by: Thaddy on March 22, 2016, 07:30:35 am
Nobody wants 8051 constraints on a PC and vice versa)

And as advanced as Lazarus is, it won't automatically add those roles for you O:-)

Would be nice to have 8051 support for embedded, though ;) in the future  O:-)
https://en.wikipedia.org/wiki/Intel_MCS-51
Title: Re: The future of Free Pascal
Post by: tr_escape on March 22, 2016, 10:29:14 am
Nobody wants 8051 constraints on a PC and vice versa)

And as advanced as Lazarus is, it won't automatically add those roles for you O:-)

Would be nice to have 8051 support for embedded, though ;) in the future  O:-)
https://en.wikipedia.org/wiki/Intel_MCS-51

For now maybe this can help you:

http://turbo51.com/ (http://turbo51.com/)


For PIC Series :

http://justanotherlanguage.org/
 (http://justanotherlanguage.org/)

I used in small PIC16F84A project , jal was helped me.

Title: Re: The future of Free Pascal
Post by: Thaddy on March 22, 2016, 10:44:38 am
I already got and use turbo51 ;) I guess Marco has that one too... ;)
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2016, 11:05:22 am
But it is very focused on single-task, database aware desktop applications.
That is purely down to your choice. I use Free Pascal for all kinds of applications. That's what makes the Object Pascal language with a rich RTL and FCL so powerful. It is NOT a language designed for a specific task. You can write all kinds of applications equally well with it. eg: I've seen an operating system written in FPC (Object Pascal), a desktop environment with window manager for Linux, general desktop apps, console apps, daemon/service applications, database applications, web applications, mobile applications and the list goes on. Not many languages are so versatile, but that is what makes FPC and Object Pascal so great.

You saying "focused on a single task - database aware desktop applications".... that's your choice of applications, not something FPC or the Object Pascal language forces you to write.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 22, 2016, 11:16:12 am
In C++ the choice is simple: you do have to write everything yourself. And in Lazarus, I have to write more and more myself as well.

Well, C++ is almost as expressive as Object Pascal, Silly. C++ isn't very portable (basically it is one big set of macro's on top of C) between platforms or compilers. Now lean backwards and choose the tool(s) for the job at hand. That will always be the case. Or turn to scripting bar none, like php, and forget about performance.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on March 22, 2016, 11:25:12 am
@Graeme:

I know, and I do. If I have the choice and it fits, I use FPC / Lazarus. I really like it. I would like to use it for just about any programming task.

What I mean is, that it beats any other development platform for writing rich, desktop applications that display and manipulate database information.

And it has a lot of other highlights, most of them contributions from developers that needed a specific functionality. I always feel a bit ashamed that I don't take the time to make the things I write into generic libraries and upload them. But that tends to be more work than creating the functional modules and classes in the first place.

And it's probably just me that I want to build Next Gen applications. Because most code bases and methodologies tend to be more than 15 years old. I would say that the only new thing I encounter is SCRUM.

So, I'll focus on what Marco said. I m thinking about how and what. And it's unlikely I can use it at my next job anyway.


@Thaddy: I often use C++. C++ Builder is fine, C++ with just std and Boost is a lot of work.
Title: Re: The future of Free Pascal
Post by: marmin on April 11, 2016, 04:46:10 am
to have my take on the Original question..

havent been on forum for years..
still love pascal

thought about switching to c++, you can program much faster,

but Pascal is in my roots.  it could use some minor improvements, still. but maybe.. not. that;s why it is Pascal, strict, unforgiving, but so beautiful.

If pascal will survive it is in the hands of these fine lazarus devs. I only have a copy of Delphi 7. don't use it anymore.

But why, is pascal so beautiful compared to C++. Because it don't allow for the programmer to take easy shortcuts. and the code becomes more readable.Although you have to type and define more.

i hope to post some improvements on pascal that irritate me. in the future.  ::)

Title: Re: The future of Free Pascal
Post by: Zoran on April 11, 2016, 11:31:05 am
thought about switching to c++, you can program much faster,

Can you really?

Is it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?

Yes, you can also save typing by typing several commands in one line
Code: C  [Select][+][-]
  1. if (x == (y = (++z) + 3)) ...
instead of
Code: Pascal  [Select][+][-]
  1. Inc(z);
  2. y := z + 3;
  3. if x = y then ...
, but...

But typing speed is really unimportant comparing to time you spend thinking about code you are writing, time you spend debugging, time you spend maintaining. And a good C++ programmer will write the previous code in three separate lines
Code: C  [Select][+][-]
  1. z++;
  2. y = z + 3;
  3. if (x == y) ...
  4.  
because it is much more readable, to later save time and effort in maintenance.

When you maintain other people's code, Pascal cannot save you from bad programmer's bad and unreadable code, but at least in Pascal you can get a bit more help with it. You can at least be sure there is no such hard-to-maintain short code, where three different things is done in one line.
Title: Re: The future of Free Pascal
Post by: airpas on April 11, 2016, 11:57:51 am
one of major factors that make me prefer pascal over c++ , is the set data type (really helpful). Although it can be emulated with c++  by bits shifting , but in the end it looks really ugly .
Title: Re: The future of Free Pascal
Post by: marcov on April 11, 2016, 12:25:56 pm
one of major factors that make me prefer pascal over c++ , is the set data type (really helpful). Although it can be emulated with c++  by bits shifting , but in the end it looks really ugly .

I agree, though I think I use it more in combination with enums

Code: Pascal  [Select][+][-]
  1. if ( a in [descriptiveflag1, otherdescriptivenameforflag]) then
  2.    dosomething;

then for bittwiddling.
Title: Re: The future of Free Pascal
Post by: marmin on April 13, 2016, 01:53:28 pm
Quote
Is it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?
yes, one of the reasons. when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.

what really irritates me is the confusion when using lots of nested begin and ends.

i am not the only one who has constantly count and track where I left out any missing end. i know theres code completion but this never really worked for me.

we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends. etc. for example, when i define a pointer the compiler automatically creates a pointer type in the var section of a procedure.
 
suddenly i got an idea!

like procedure Test;
begin

for x:=1 to 5 do
begin1

while .. do
begin2
(do a lot of work here so it takes up lots of screen space)

 for y:=1 to 4000 do
begin3
.. lots of stuff here taking up lots of screen space
end3;
end2;
end1;

in this case i can see which end belongs to which begin
.
unfortunately i do not have the time, but i also would like to see a much smarter and more complex code explorer. like more graphical, and bigger.
Title: Re: The future of Free Pascal
Post by: Zoran on April 13, 2016, 02:11:54 pm
@marmin - In Lazarus code editor, when the caret is positioned on "end", then its corresponding "begin" is highlighted. It helps a lot.
Title: Re: The future of Free Pascal
Post by: sfeinst on April 13, 2016, 02:19:38 pm

like procedure Test;
begin

for x:=1 to 5 do
begin1

while .. do
begin2
(do a lot of work here so it takes up lots of screen space)

 for y:=1 to 4000 do
begin3
.. lots of stuff here taking up lots of screen space
end3;
end2;
end1;

in this case i can see which end belongs to which begin

You can mimic this some using comments:
begin //1
begin //2
end //2
end //1
Title: Re: The future of Free Pascal
Post by: wp on April 13, 2016, 02:27:46 pm
i am not the only one who has constantly count and track where I left out any missing end. i know theres code completion but this never really worked for me.

we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends. etc. for example, when i define a pointer the compiler automatically creates a pointer type in the var section of a procedure.

The smartest compiler is in your head. Why don't you indent properly? With proper indentation (each begin/end contents indent by 2 spaces) you can easily see what is missing.
 
Code: Pascal  [Select][+][-]
  1. procedure Test;
  2. begin
  3.   for x:=1 to 5 do
  4.   begin1
  5.     while .. do
  6.     begin2
  7.       (do a lot of work here so it takes up lots of screen space)
  8.       for y:=1 to 4000 do
  9.       begin3
  10.         .. lots of stuff here taking up lots of screen space
  11.       end3;
  12.     end2;
  13.   end1;
  14. end;
Title: Re: The future of Free Pascal
Post by: x2nie on April 13, 2016, 02:41:23 pm
@Marmin,
I've developed a markup (plugin) for synedit which can show you which end belong to which begin : visually.


Martin_fr (Lazarus developer) seem in heavy work now merging my works into official Lazarus's synedit.
so, hopefully in near future it will become enabled in Lazarus's editor.
(Actually, martin_fr is who giving me guidances from very beginning of this features.)


my markup work, is also will work for other PL (such JS, XML, HTML, C, any) but it has optimized for pascal, because modern pascal has more complex nested blocks (at least in my own opinion, compared with Java script).


If you are interest, you can get in-touch in topic Invite to Colorizing TSynEdit ! {Improving Editor for Editing Complex Codes} (http://forum.lazarus.freepascal.org/index.php/topic,30122.msg207910.html#msg207910)
Title: Re: The future of Free Pascal
Post by: x2nie on April 13, 2016, 02:59:11 pm
Code: Pascal  [Select][+][-]
  1. procedure Test;
  2. begin
  3.  
  4.  
  5. for x:=1 to 5 do
  6. begin
  7.  
  8.  
  9. while .. do
  10. begin
  11.      {do a lot of work here
  12.      so it takes up lots
  13.      of screen space}
  14.  
  15.  
  16. for y:=1 to 4000 do
  17. begin
  18.      {lots
  19.      of
  20.      stuff
  21.      here
  22.      taking
  23.      up
  24.      lots
  25.      of
  26.      screen
  27.      space}
  28. end;
  29. end;
  30. end;
  31. end;  


too hard to read with conventional syntax-highlighter ?
see above code when it colorized in attachment below:
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 13, 2016, 03:04:59 pm
for example, when i define a pointer the compiler automatically creates a pointer type in the var section of a procedure.

Not fully automated, but usually good enough: http://wiki.lazarus.freepascal.org/Lazarus_IDE_Tools#Variable_Declaration_Completion
read the rest of the page too, it really covers a lot of helpful features

Quote

suddenly i got an idea!

Code: Pascal  [Select][+][-]
  1. procedure Test;
  2. begin
  3. for x:=1 to 5 do
  4. begin // for x
  5. ...
  6. end; // for x
  7. end; // proc // this will have a horiz line below it anyway
  8.  
in this case i can see which end belongs to which begin
Also
- indent
- divider lines http://wiki.lazarus.freepascal.org/New_IDE_features_since#divider_lines_in_editor
- markup http://wiki.lazarus.freepascal.org/New_IDE_features_since#block_matching
- folding
- using the hints and quickfixes of the IDE, if compile failed
   add   -Se20 to your compile options, and in many case you get more than one error per compile.
- moving some of "a lot of code" into subroutines.


But NOT the compiler guessing. NO NO.

javascript does that, and as a result, it can happen that
Code: Javascript  [Select][+][-]
  1. function mytime () {
  2.   return
  3.     Date.now();
  4. }
  5.  
returns undefined, because it guesses the return statement ends at the end of the line. (And Date.now() is unreachable code)
Title: Re: The future of Free Pascal
Post by: Graeme on April 13, 2016, 04:31:42 pm
what really irritates me is the confusion when using lots of nested begin and ends.
The indent your code properly, or switch to TAB character indentation (instead of spaces). You can then set your indentation level very easy. eg: 1 TAB could visually be 4 or 8 Spaces. As for larger indentation causing horizontal scrolling... maybe in the past, but with widescreen monitors (or even multi-monitor setups) now being all the rage, that is not a concern any more.

Quote
i am not the only one who has constantly count and track where I left out any missing end.
As already mentioned, Lazarus's editor highlights begin..end pairs. Many other IDE's and programmer editors do the same thing.

Quote
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.
It's not a compiler issue, it's an editor issue. Get a smarter editor, or enable the "smart" features of your existing editor.

Regards,
  Graeme
Title: Re: The future of Free Pascal
Post by: Windsurfer on April 13, 2016, 05:51:53 pm
It looks like X2nie and Martin_fr are doing some fantastic development on the editor. 8-)
Title: Re: The future of Free Pascal
Post by: Leledumbo on April 13, 2016, 06:00:52 pm
But NOT the compiler guessing. NO NO.
Code: Javascript  [Select][+][-]
  1. javascript does that, and as a result, it can happen that
  2. [code=javascript]
  3. function mytime () {
  4.   return
  5.     Date.now();
  6. }
  7.  
returns undefined, because it guesses the return statement ends at the end of the line. (And Date.now() is unreachable code)
I second that. Compilers ain't any smarter than us when it comes to guessing what we actually want to do.
Title: Re: The future of Free Pascal
Post by: Edson on April 13, 2016, 06:19:10 pm
It looks like X2nie and Martin_fr are doing some fantastic development on the editor. 8-)

It will be fantastic if someone would do some devloment in the language too (Modula Mode).
Title: Re: The future of Free Pascal
Post by: skalogryz on April 13, 2016, 07:02:39 pm
(Modula Mode).
Curious. Is there a large Modula code-base that needs to be supported?
Title: Re: The future of Free Pascal
Post by: FPK on April 13, 2016, 07:16:13 pm
Quote
Is it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?
yes, one of the reasons. when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.

what really irritates me is the confusion when using lots of nested begin and ends.

i am not the only one who has constantly count and track where I left out any missing end. i know theres code completion but this never really worked for me.

we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.

And this is why you use C++? Strange. Which C++ compiler corrects missing }? How is keeping { ... } balanced from keeping begin ... end balanced?
Title: Re: The future of Free Pascal
Post by: skalogryz on April 13, 2016, 07:36:32 pm
...when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.
...
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.
And this is why you use C++? Strange. Which C++ compiler corrects missing }? How is keeping { ... } balanced from keeping begin ... end balanced?
It's self-evident that unlike Pascal, C++ compiler can correct missing "}". The feature comes from the fact "}" is taking only 1-byte, while "end" takes up to 3 bytes of memory (6-bytes for 64-bit platforms).

The same explains, while Pascal is not suitable for writing games. "begin" takes up to 5 bytes of memory (10-bytes for 64-bit platforms), causing a routine or loop to start slower and polluting program memory stack.

C++ compiler just disregards the missing byte. Pascal cannot do that since 2 remaining byes "nd" will cause a fault.
Title: Re: The future of Free Pascal
Post by: tr_escape on April 13, 2016, 07:47:23 pm

Code: Pascal  [Select][+][-]
  1. fun pos(subs,srcs:str):int;
  2. b
  3.   res := int_pos(subs,srcs);
  4. e;
  5.  
  6. pro shwmsg(s:str);
  7. b
  8.   int_showmessage(s);
  9. e;
  10.  
  11.  

fun = function
str = string
int = integer

pro = procedure

b= begin
e=end

Actually I am not sure this function how fast parsing in the fpc but it is very ugly.
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 13, 2016, 07:55:31 pm
It's self-evident that unlike Pascal, C++ compiler can correct missing "}". The feature comes from the fact "}" is taking only 1-byte, while "end" takes up to 3 bytes of memory (6-bytes for 64-bit platforms).

That problem may be solved soon. There is an ongoing attempt (everyone who does not yet support it, please join it) to get some unicode codepoints allocated and assigned to represent pascal keywords.

And the aim is to get unicode codepoints with an ordinal value in the range of 0 to 127. Yes! If that will be archived then using utf8 pascal keywords come down to 1 byte (sorry to all utf16 users).
And if there will be codepoints not just for begin/end, but maybe also for "procedure", "for", "if", ... and more, then pascal will beat c++.

Lets wait and see.

;)  (not sure there may be a single codepoint for ;), but I am old school)
Title: Re: The future of Free Pascal
Post by: skalogryz on April 13, 2016, 08:26:04 pm
;)  (not sure there may be a single codepoint for ;), but I am old school)
(U+1F609)

...future of everything :)
Title: Re: The future of Free Pascal
Post by: ArtLogi on April 13, 2016, 08:48:19 pm
...when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.
...
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.
And this is why you use C++? Strange. Which C++ compiler corrects missing }? How is keeping { ... } balanced from keeping begin ... end balanced?
It's self-evident that unlike Pascal, C++ compiler can correct missing "}". The feature comes from the fact "}" is taking only 1-byte, while "end" takes up to 3 bytes of memory (6-bytes for 64-bit platforms).

The same explains, while Pascal is not suitable for writing games. "begin" takes up to 5 bytes of memory (10-bytes for 64-bit platforms), causing a routine or loop to start slower and polluting program memory stack.

C++ compiler just disregards the missing byte. Pascal cannot do that since 2 remaining byes "nd" will cause a fault.
Mmmm.. Wait why the Begin-End structure is handled internally in ready to run binary in long way? Its main is for clarity and human readability on translation stage (programmin) not in translated state (machine code) right? Why it is not handled internally in one byte format, what I'm missing ... a newb is wondering.

There were a few post about begin-end highlight etc. for synedit. One thing that jumped to my mind once or twice is that sometimes it would be nice to have end-word telling you at which type of proces it is related (the IEC-61131-3 ST is hounting behind this idea). Just autoadding type comment (if, for etc.etc.) in IDE, but this is not pascal related, just IDE related add-on.
Title: Re: The future of Free Pascal
Post by: skalogryz on April 13, 2016, 09:01:21 pm
Mmmm.. Wait why the Begin-End structure is handled internally in ready to run binary in long way? Its main is for clarity and human readability on translation stage (programmin) not in translated state (machine code) right? Why it is not handled internally in one byte format, what I'm missing ... a newb is wondering.
It was an irony ;)
I cannot take seriously any discussions like "{" vs "begin" or supremacy of C++ over Pascal or vice versa.
Title: Re: The future of Free Pascal
Post by: ArtLogi on April 13, 2016, 09:11:25 pm
Mmmm.. Wait why the Begin-End structure is handled internally in ready to run binary in long way? Its main is for clarity and human readability on translation stage (programmin) not in translated state (machine code) right? Why it is not handled internally in one byte format, what I'm missing ... a newb is wondering.
It was an irony ;)
I cannot take seriously any discussions like "{" vs "begin" or supremacy of C++ over Pascal or vice versa.
I see.  :-[
Title: Re: The future of Free Pascal
Post by: skalogryz on April 13, 2016, 09:39:45 pm
I see.  :-[
your question also proves that you're not as newbie as you think about yourself ;)
Title: Re: The future of Free Pascal
Post by: Ñuño_Martínez on April 14, 2016, 02:24:31 pm
Didn't read every message, but this one (the first I've read today) has a concept that... er...  :o
Quote
Is it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?
yes, one of the reasons. when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing. (...)
I'm one of those who is making games with Pascal (I'm the Allegro.pas creator  8-)) and but I don't understand why the "BEGIN ... END" structure is irritating for game makers.  I find it as irritating as C and I did a lot of stuff in C before to port Allegro to Pascal.

Anyway, as people said, the IDE has tools to deal with it.  Lazarus is able to add the "END" just after you write "BEGIN", or you can create a key combination that adds both just pressing 2 or 3 keys, and SynEdit draws a line that marks where a block starts and where it ends, so I don't see any problem.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 14, 2016, 03:03:16 pm
It will be fantastic if someone would do some devloment in the language too (Modula Mode).

I have seen multiple requests for Modula 2 / Oberon extensions, but why?

As far as I understand, both are extensions to make Pascal Object Oriented. But Free Pascal already uses Object Pascal, which does the same.

So, I'm curious: what would Modula 2 / Oberon do better?
Title: Re: The future of Free Pascal
Post by: aradeonas on April 14, 2016, 04:02:10 pm
@Ñuño_Martínez just asking why there is multiple engine and wrappers for making game with Pascal? is it good really in compare of other popular engine? what games these Pascal ones are good at?
I like Pascal very much but I want to know what can these Pascal engines do in compare of existence big and reliable engines?
Title: Re: The future of Free Pascal
Post by: marcov on April 14, 2016, 04:11:45 pm
It will be fantastic if someone would do some devloment in the language too (Modula Mode).

I have seen multiple requests for Modula 2 / Oberon extensions, but why?

For me those are totally different languages.

Quote
As far as I understand, both are extensions to make Pascal Object Oriented. But Free Pascal already uses Object Pascal, which does the same.

Modula-2 is a procedural language and direct Pascal successor that pioneered the concept of modules. Parts of the Module syntax were later backported to Pascal as Units (in UCSD/Borland versions) and Modules (in Extended Pascal). Part because some parts are missing (specially related to mandatorily qualified identifiers and nesting)

Modula-3 and Oberon (and -2 and Component Pascal, which is Oberon inspired) are Wirthian OO languages.

The base syntax is Modula2 (and not Pascal) based, but otherwise these are different beasts in the sense that these cut out a lot of the procedural syntax, making them more Java's with Wirthian syntax. Arguments in favour are also largely the same as for Java (mostly based on OO purity).

To my best knowledge the original .NET language Component Pascal is actually a oberon/Modula derivative syntax wise. Oxygene also has some aspects from later wirthians but is further removed (e.g. the others still use procedure for both procedure and function, but oxygene uses "method")

Quote
So, I'm curious: what would Modula 2 / Oberon do better?

I never considered M3/Oberon very workable, but the relevance of Modula2 for discussions about block syntax is that it removes the "begin" or "{" except for procedure/function beginnings. Statements always trigger blocks. (so after if..then there is always a block, but because begin is omitted, that only means it must be terminated by an end)

So

Code: Pascal  [Select][+][-]
  1.    if bla then
  2.      onestatement;
  3.  
  4.   //or
  5.  
  6.   if bla then
  7.    begin
  8.     onestatement
  9.   end;
   
both become

 
Code: [Select]
   IF bla THEN
     onestatement;
     END;
   

Note the capitals, because Modula2 is case sensitive (something I was NOT very happy about).

Anyway I would love a M2 mode, simply because it is a better syntax, and I think embedded codebases would be better directly in M2 then Pascal. But because of the case sensitivity and the different block syntax of Modula2 it might be more involved than a new Pascal dialect mode, because the base syntax is already different.

For big apps, M2 lacks a decent string type and OO, and I don't consider the successors (M3,Oberon) a real practical improvement, and setting up an Object Pascal alike Object Modula2 too much trouble for too little gain. I'd rather port selected M2 features (opague types, import [qualified], from import [qualified] xxx etc)
Title: Re: The future of Free Pascal
Post by: tk on April 14, 2016, 04:40:08 pm
Sorry for interrupting you guys just seen this thread and reading the first post here:
Well, Delphi is as good as dead.

Well, I would not say that anymore for a language that is currently >2% on tiobe and steadily growing for last 2 years!
(I know it is not only for Delphi now, but still quite promising progress)
Title: Re: The future of Free Pascal
Post by: Edson on April 14, 2016, 09:49:48 pm
So, I'm curious: what would Modula 2 / Oberon do better?

The syntax. No need to use too many begin-end. It simplifies typing in most of the cases.
Title: Re: The future of Free Pascal
Post by: Leledumbo on April 14, 2016, 10:31:17 pm
So, I'm curious: what would Modula 2 / Oberon do better?
Oberon also has OO style that inspires other mainstream languages, Java and Go being the most prominent. I mostly like the amalgamation of interface and implementation section, by using markers for access modifier. Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP). And oh, the grammar is damn simple, much simpler than OP although providing less language integrated features, but proven to be sufficient to even write an operating system.
Title: Re: The future of Free Pascal
Post by: skalogryz on April 15, 2016, 03:11:20 am
Even Microsoft supports Pascal (https://marketplace.visualstudio.com/items?itemName=alefragnani.pascal) (both Delphi and FPC)  these days.
 :D
Title: Re: The future of Free Pascal
Post by: avra on April 15, 2016, 11:28:41 am
So, I'm curious: what would Modula 2 / Oberon do better?
The syntax. No need to use too many begin-end. It simplifies typing in most of the cases.
I also prefer such syntax. I have it in AvrCo Multitasking Pascal for AVR microcontrollers and it's really nice. The only thing I miss more is try..except..finally..end block written in one shot. These 2 things would make code even more readable.

Code: Pascal  [Select][+][-]
  1. try
  2.   if TestCondition then
  3.     DoThing1;
  4.     DoThing2;
  5.   else
  6.     DoThing3;
  7.     DoThing4;
  8.     DoThing5;
  9.   end;
  10. except
  11.   HandleException;
  12. finally
  13.   FreeAnythingCreated;
  14. end;
Title: Re: The future of Free Pascal
Post by: Windsurfer on April 15, 2016, 05:11:11 pm
I agree with the convenience of a try..except..finally..end written in one shot. I frequently use a try...try...except...end..finally... end block.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 18, 2016, 03:51:51 pm
I agree, that would both be nice.
Title: Re: The future of Free Pascal
Post by: serbod on April 18, 2016, 04:05:45 pm
Yes, 'begin' and 'try try' is annoying.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 18, 2016, 04:47:06 pm
Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP).

The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.

If you have two threads, that both access the same variable, you are encouraged to use a mutex to lock and unlock that variable. This is how it is done.

And that's totally the wrong way to do it.

Every time you lock the variable, you serialize the application. And not only that, but it incurs a large overhead and makes context switching take ten times as long:

- The shadow registers need to be cleared.
- The pipeline needs to be flushed.
- The cache memory needs to be partially flushed.
- the page tables need to be refreshed.

In the time that takes, the CPU could have done more work than a 8086 could do in a whole second.

Ergo, working like that makes your application slower instead of faster.

That's why the amount of CPU cores on Intel x86 processors first climbed up to 16, and is now back down to max four. Simply because few people have figured out how to use them effectively.

Essentially, you need to give each thread its own (thread-safe) message queue, which triggers execution on post. And use that for both events as well as data passing. That increases the latency, but the throughput as well.

There should be no shared memory. If you want to pass a block of data, allocate it on the heap, post the pointer and nil your own copy of the pointer.
Title: Re: The future of Free Pascal
Post by: Graeme on April 18, 2016, 05:14:58 pm
Code: Pascal  [Select][+][-]
  1. try
  2.   if TestCondition then
  3.     DoThing1;
  4.     DoThing2;
  5.   else
  6.     DoThing3;
  7.     DoThing4;
  8.     DoThing5;
  9.   end;
  10. except
  11.   HandleException;
  12. finally
  13.   FreeAnythingCreated;
  14. end;
  15.  
I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making. What if your code block has an if..else statement in it as well. The compiler might interpret it one way, each developer might interpret it another.

Code: Pascal  [Select][+][-]
  1. try
  2.   if TestCondition then  //  (1)
  3.     DoThing1;
  4.     if DoThing2 then   //  (2)
  5.       DoThing21;
  6.   else                //  (3)
  7.     DoThing3;
  8.     DoThing4;
  9.     DoThing5;
  10.   end;
  11. except
  12.   HandleException;
  13. finally
  14.   FreeAnythingCreated;
  15. end;
  16.  

Is (3) the else part of (2) or (1)?  You might figure it out eventually, but others might not. It doesn't make the code easy to read. Thus not very Pascal-like. No thanks - I'll prefer the begin..end block syntax. It adheres to the Pascal-style, making code easy to read, write and understand.

Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 18, 2016, 05:19:57 pm
You're missing an "end". It won't compile like that.
Title: Re: The future of Free Pascal
Post by: BeniBela on April 18, 2016, 06:10:38 pm
try .. except is also annoying if you have to catch multiple exceptions.

Like

Code: [Select]
try
...
except
  on e: E1 do ...
  on e: E2 do ...
  on e: E3 do ...
end

instead a simple on e: E1 | E2 | E3 do




The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.


Perl's variables are thread local at default.

Smalltalk has message passing

Qt has a similar signal/slot mechanism

Go has its channels

In functional languages variables are immutable, you do not need locking
Title: Re: The future of Free Pascal
Post by: Leledumbo on April 18, 2016, 06:54:13 pm
The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.

If you have two threads, that both access the same variable, you are encouraged to use a mutex to lock and unlock that variable. This is how it is done.

And that's totally the wrong way to do it.

Every time you lock the variable, you serialize the application. And not only that, but it incurs a large overhead and makes context switching take ten times as long:

- The shadow registers need to be cleared.
- The pipeline needs to be flushed.
- The cache memory needs to be partially flushed.
- the page tables need to be refreshed.

In the time that takes, the CPU could have done more work than a 8086 could do in a whole second.

Ergo, working like that makes your application slower instead of faster.

That's why the amount of CPU cores on Intel x86 processors first climbed up to 16, and is now back down to max four. Simply because few people have figured out how to use them effectively.

Essentially, you need to give each thread its own (thread-safe) message queue, which triggers execution on post. And use that for both events as well as data passing. That increases the latency, but the throughput as well.

There should be no shared memory. If you want to pass a block of data, allocate it on the heap, post the pointer and nil your own copy of the pointer.
And that's why concurrent programming is considered a different paradigm ;)
When coded properly, concurrent programming DOES make your app runs faster. Try my UPX wrapper (https://bitbucket.org/leledumbo/express), compress tens or hundreds of exes/dlls/whatever file type UPX can handle. Compare the total time taken with thread count = 1 and = number of cores in your CPU.
No problem with concurrency if one pays attention to the limiting factors. In my company, I create a concurrent message queue processor. If different kind of message are in sequence, they are processed in parallel without waiting. This increases the processing speed, A LOT, especially in case of heavy traffic situation because the request processing is less likely to timeout.
Title: Re: The future of Free Pascal
Post by: marcov on April 18, 2016, 06:58:21 pm

Bad example. If you do this, end becomes mandatory, and every block is terminated by end eventually. (since if then else end is considered one statement it only has one end)

So

Code: Pascal  [Select][+][-]
  1.   if TestCondition then  //  (1)
  2.     DoThing1;
  3.   end; // <- HERE
  4.     if DoThing2 then   //  (2)
  5.       DoThing21;
  6.   else                //  (3)
  7.     DoThing3;
  8.     DoThing4;
  9.     DoThing5;
  10.   end;
  11.  

The rest is perfectly valid in M2, and actually a better blocksyntax than Pascal (no dangling else)
Title: Re: The future of Free Pascal
Post by: guest58172 on April 18, 2016, 07:03:43 pm
Perl's variables are thread local at default.

Smalltalk has message passing

Qt has a similar signal/slot mechanism

Go has its channels

In functional languages variables are immutable, you do not need locking

D also has all its variables on the thread local storage (TLS), unless they are annotated with "__gshared" or "shared", and two multi thread paradigms: "MessageBoxes" that allow to easily send receive between threads and "Tasks". Even with mutable data you don't need to lock all the time, but only when you access non-TLS data. I think all modern compilers do something like that nowadays.

Actually I'd surprised if someone tells me that FPC doesn't put the variables declared in a class or a struct on the TLS.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 18, 2016, 09:58:04 pm
And that's why concurrent programming is considered a different paradigm ;)
When coded properly, concurrent programming DOES make your app runs faster. Try my UPX wrapper (https://bitbucket.org/leledumbo/express), compress tens or hundreds of exes/dlls/whatever file type UPX can handle. Compare the total time taken with thread count = 1 and = number of cores in your CPU.
No problem with concurrency if one pays attention to the limiting factors. In my company, I create a concurrent message queue processor. If different kind of message are in sequence, they are processed in parallel without waiting. This increases the processing speed, A LOT, especially in case of heavy traffic situation because the request processing is less likely to timeout.
Well, of course. I agree.

There will always be some overhead, but it can be minimized. Although the best way to do it would require a specialized OS (to swap the page tables).

If you do it right, your application will scale greatly.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 18, 2016, 10:04:05 pm
D also has all its variables on the thread local storage (TLS), unless they are annotated with "__gshared" or "shared", and two multi thread paradigms: "MessageBoxes" that allow to easily send receive between threads and "Tasks". Even with mutable data you don't need to lock all the time, but only when you access non-TLS data. I think all modern compilers do something like that nowadays.

Actually I'd surprised if someone tells me that FPC doesn't put the variables declared in a class or a struct on the TLS.
Yes, local variables in FPC reside on the stack, which is thread-specific. Unless they're objects.

The main problem is in passing the messages and have the thread activate when a new message is received.

Linux likes pipes, which aren't randomly accessible. And Windows likes message loops, where only the primary thread can send them. Both don't have a mechanism where any thread can send a message to any other random thread. And for distributed processing, you might want to scale that "any" up to "any thread on any computer".

Edit: I do agree that Smalltalk was the best way to go. Objective-C (while a watered-down subset of Smalltalk), still has an edge on most everything else, as far as concurrency and scaling goes.
Title: Re: The future of Free Pascal
Post by: avra on April 19, 2016, 11:17:28 am
I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making.
I don't think so. Unlike in 'old' Pascal, in newer Wirthian languages each if requires an end. Therefore your example would not be valid, and such syntax makes sense. You already use mentioned syntax with try..finally..end block. No need for begin/end and you can write more then one command inside of the block. If that is logical to you, I don't see any other reason beyond legacy for not liking it. Code looks much cleaner and easier to follow.
Title: Re: The future of Free Pascal
Post by: Ñuño_Martínez on April 19, 2016, 11:26:41 am
First, sorry for the late answer.  I was pretty busy.
@Ñuño_Martínez just asking why there is multiple engine and wrappers for making game with Pascal? is it good really in compare of other popular engine? what games these Pascal ones are good at?
I like Pascal very much but I want to know what can these Pascal engines do in compare of existence big and reliable engines?
There are multiple engine and wrappers for making games with any language.  Get C/C++:  You have Irrlitch, Unreal Engine and DooM engines, and you can go for older stuff and can use Build, Genesis3D and more.  If you go to libraries, you have DirectX, Allegro, SDL and more.

Since Pascal isn't a popular language, the most important advantage to use these engines/libraries in Pascal is to use our beloved language.  I think Pascal has some advantages over C in High Level development, and that's why I use it to build games.  But I use C some times too.  I never use C++ or C#: I don't like them.

About the topic, I think a lot of you would be happy using QuickBASIC.  Note I don't say VisualBasic, I've said QuickBASIC.  To be sincere, I miss QuickBASIC.
Title: Re: The future of Free Pascal
Post by: Edson on April 19, 2016, 11:29:21 pm
You already use mentioned syntax with try..finally..end block. No need for begin/end and you can write more then one command inside of the block.

In fact, Pascals include such construction from the beginning, in the "REPEAT ... UNTIL" sentence, and later in the "CASE ... ELSE ... END". Both of them, presents blocks without BEGIN ... END.
Title: Re: The future of Free Pascal
Post by: Thaddy on April 20, 2016, 09:13:49 am
To be sincere, I miss QuickBASIC.
Actually: I am missing Turbo/ PowerBasic.... Which once was QuickBasic on steroids.. ;)
Title: Re: The future of Free Pascal
Post by: Thaddy on April 20, 2016, 09:18:18 am
Both of them, presents blocks without BEGIN ... END.
You forgot to mention labels ;) Which can also be blocks without begin end.

Oh, well, I should goto sleep..
Title: Re: The future of Free Pascal
Post by: ArtLogi on April 22, 2016, 06:02:23 pm
Both of them, presents blocks without BEGIN ... END.
You forgot to mention labels ;) Which can also be blocks without begin end.

Oh, well, I should goto sleep..
Gosub sleep`?
Title: Re: The future of Free Pascal
Post by: Thaddy on April 22, 2016, 06:17:13 pm
Both of them, presents blocks without BEGIN ... END.
You forgot to mention labels ;) Which can also be blocks without begin end.

Oh, well, I should goto sleep..
Gosub sleep`?

Naahhhh, I knew Pascal before Basic.... :o Apple ][e UCSD Pascal.
Title: Re: The future of Free Pascal
Post by: kupferstecher on April 25, 2016, 01:20:07 pm
I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making.
I don't think so. Unlike in 'old' Pascal, in newer Wirthian languages each if requires an end. Therefore your example would not be valid, and such syntax makes sense.
In my opinion having both options (single statement and blocks) is quite usefull. I often use single line ifs and dos, it makes the code short and easy to understand.

In my code the if-structures always look somehow like this:
Code: Pascal  [Select][+][-]
  1. if x > 0 then SingleStatement;
  2.  
  3. if x > 0
  4. then SingleStatement;
  5.  
  6. if x > 0
  7. then SingleStatement
  8. else SingleStatement2;
  9.  
  10. if x > 0 then begin
  11.   Statement1;
  12.   Statement2;
  13. end else begin
  14.   Statement3;
  15.   Statement4;
  16. end;

A possible syntax could be using the line break after then-statement as indicator if its a single statement or a block with following end-statement.

The above statements then would look quite similar:
Code: Pascal  [Select][+][-]
  1. if x > 0 then SingleStatement;
  2.  
  3. if x > 0
  4. then SingleStatement;
  5.  
  6. if x > 0
  7. then SingleStatement
  8. else SingleStatement2;
  9.  
  10. if x > 0 then
  11.   Statement1;
  12.   Statement2;
  13. else
  14.   Statement3;
  15.   Statement4;
  16. end;

The following would be a syntax ERROR:
Code: Pascal  [Select][+][-]
  1. if x > 0
  2. then Statement1; //if-structure already finnished here.
  3.      Statement2;
  4. end;

The "single-line"-structure could even be extended allowing multiple statements in the same line:
Code: Pascal  [Select][+][-]
  1. if x > 0
  2. then found:= true; EXIT;

Such a syntax allows clear code without overhead.
Do-structures would look the same of course.
Title: Re: The future of Free Pascal
Post by: marcov on April 25, 2016, 01:30:51 pm
Line breaks are parsed as whitespace only. Changing that would be very massive. (not that this is all academical).

I use a lot of single statement too, but I also have to change a lot of them to accommodate more commands later. The advantage of the mandatory end is that the IDE can always generate an end; to match and if etc.

Because that is so sure, the typing overhead of the mandatory end is small, while you save ALL block begins except procedural.

But of course totally new blocksystems are rarely invented. I would go with either M2 or Pascal, not combinations or even weirder stuff. And since this is the FreePASCAL forum this probably will be the case till a M2 mode is submitted  O:-)
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on April 25, 2016, 01:38:52 pm
The only time I ever use single-statement ifs is these:

Code: Pascal  [Select][+][-]
  1. if not Assigned(SomeParam) then Exit;

Because of the chance I overlook it and do things like:

Code: Pascal  [Select][+][-]
  1. if Something then
  2.   DoSomething;
  3.   DoOtherThings;
  4. if SomethingElse then Exit;
  5.  

That's also why using line breaks as syntax elements is not a good idea.
Title: Re: The future of Free Pascal
Post by: BeniBela on April 25, 2016, 02:07:44 pm
Lazarus seems to parse the indentation to automatically insert an end; at the right place

Except for case statements. There it always puts the end; at the wrong place


Line breaks are parsed as whitespace only. 

They are?

Really?

Then why are there no multiline strings?

They are not! Checkmate

 
The only time I ever use single-statement ifs is these:
 ]

Because of the chance I overlook it and do things like:

Code: Pascal  [Select][+][-]
  1. if Something then
  2.   DoSomething;
  3.   DoOtherThings;
  4. if SomethingElse then Exit;
  5.  

 

Recently I overlooked a

Code: Pascal  [Select][+][-]
  1. if Something then ;
  2. DoSomething;
  3.  

and was confused. Never happened before. You really get too old for programming way too fast (https://xkcd.com/447/)
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 25, 2016, 02:19:20 pm
Quote
Code: Pascal  [Select][+][-]
  1. if Something then ;
  2. DoSomething;

See pic, that issue can be made easy to spot. Since code completion sometimes places a ";" while typing the if condition, the problem is not that uncommon.

I detect it with 0 or 1 space. But one can add more space too. As long as the ; is on the same line.
Title: Re: The future of Free Pascal
Post by: skalogryz on April 25, 2016, 03:33:26 pm
See pic, that issue can be made easy to spot. Since code completion sometimes places a ";" while typing the if condition, the problem is not that uncommon.

I detect it with 0 or 1 space. But one can add more space too. As long as the ; is on the same line.
Ugh... not sure about future of FreePascal, but looking at Lazarus configuration screen ... it is complex :)

btw, is the usage of "User defined markup" explained anywhere? I wouldn't guess to put the markup code into the column on the right.
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 25, 2016, 03:47:21 pm
F1 should take you right here: http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_User_Defined_Words

IIRC there was/is a request to make the list of word part more intuitive. Matter of time to spent on it.
Title: Re: The future of Free Pascal
Post by: skalogryz on April 25, 2016, 04:23:11 pm
F1 should take you right here: http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_User_Defined_Words

IIRC there was/is a request to make the list of word part more intuitive. Matter of time to spent on it.
indeed, F1 worked :) I guess I never realized that wiki help works by default.

Did you notice that "Delete List" is only refreshed on the opening of the dialog.
If I've no lists, it would be disabled on start. But If I add some lists (without closing the dialog) it remains disabled.
Once I reopen the dialog "Delete List" is enabled, but doesn't get disabled even if I delete the last of them.
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 25, 2016, 04:26:54 pm
Did you notice that "Delete List" is only refreshed on the opening of the dialog.
Please report on mantis
Title: Re: The future of Free Pascal
Post by: skalogryz on April 25, 2016, 04:28:31 pm
btw, why it's own tab, rather than under Colors?
Title: Re: The future of Free Pascal
Post by: skalogryz on April 25, 2016, 04:28:51 pm
Please report on mantis
Will do.
Title: Re: The future of Free Pascal
Post by: Edson on April 25, 2016, 04:38:39 pm
A possible syntax could be using the line break after then-statement as indicator if its a single statement or a block with following end-statement.

Pascal is not line-oriented language. It will destroy Pascal syntax.

Then why are there no multiline strings?

I ask the same. This is a feture I really love in other languages.
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 25, 2016, 04:45:13 pm
btw, why it's own tab, rather than under Colors?
Because it has plenty of settings other colors do not have. And they would not really fit on the color tab (keep in mind, that the option dlg may be resized, and quite small)

It is not just the word list, it is also the keysettings.
The other big use is that you can use it similar to "highlight word at caret". Define colors, and assign keystrokes, and you can highlight different terms in the editor by those keystrokes.
Can be very useful if you want to highlight a few identifiers that you try to trace through some code.
Title: Re: The future of Free Pascal
Post by: Martin_fr on April 25, 2016, 04:50:21 pm
Then why are there no multiline strings?

I ask the same. This is a feture I really love in other languages.
I know it is not the same, but the IDE can at least help a bit here.

it can add the necessary
Code: Pascal  [Select][+][-]
  1. ' + LineEnding +
  2.  '
if you press enter inside a string (or unfinished string)
Title: Re: The future of Free Pascal
Post by: skalogryz on April 25, 2016, 04:52:00 pm
Because it has plenty of settings other colors do not have. And they would not really fit on the color tab (keep in mind, that the option dlg may be resized, and quite small)
But "Preview" of "Colors" is very helpful.
In the case of "User defined markup", it might ever need a sort of sandbox (where the text could be typed in).

Trying to configure it by switching between dialog and the editor is painful (especially, if there're many user lists entered already)
Title: Re: The future of Free Pascal
Post by: skalogryz on April 25, 2016, 04:55:03 pm
Then why are there no multiline strings?
I ask the same. This is a feture I really love in other languages.
You must be hating JSON then :D

What line-break characters should be applied for such multi-line string? Should it be that's native to the system? or the one used in the source code?
Instead of leaving you guessing, pascal is just asking you to escape the line break explicitly, by adding #10 or #13#10 or a constant of you own choice. And then you'll be able to continue the constant from a new line.
Title: Re: The future of Free Pascal
Post by: BeniBela on April 26, 2016, 02:17:45 pm
There could be  a compiler switch

After all, there are already some for the encoding. Choose the encoding of the line break
Title: Re: The future of Free Pascal
Post by: marcov on April 26, 2016, 02:56:41 pm
Lazarus seems to parse the indentation to automatically insert an end; at the right place

I'm talking about Free Pascal, since block structure is language.

Quote
Except for case statements. There it always puts the end; at the wrong place

Right is relative.

Quote
Line breaks are parsed as whitespace only. 

They are?


Yes.

Quote
Really?

Then why are there no multiline strings?

I assume you mean string literals.

1. there are, just use ' '  +  ''  syntax.
2. literals

As said in the umpteen discussions about that dead horse: it probably could be done, it is just not very pascalish, and there are too many variables
  (like should indentation be part of the string?)

Anyway, the whole string literal bit is not really related to block syntax, though of course the base philosophy that textual layout should not matter (or as little as possible) affects both.

Quote
They are not! Checkmate

One counter example doesn't fully invalidate a principle. 

The only time I ever use single-statement ifs is these

Because of the chance I overlook it and do things like:

(about if then ;)

I guess the compiler could easily emit an hint/warning for an empty statement ? While I would
favour syntax without single statements like M2), such constructs are not undetectable and thus
not beyond repair.

I just favour the M2 syntax because it is more compact and easier to read without IMHO significant technical downsides.

I actually came from M2 back to Pascal because of the larger codebases though. M2 is too small an island, and suddenly there was an open source Pascal. (this was summer '97 or so)
 
Title: Re: The future of Free Pascal
Post by: Ñuño_Martínez on April 27, 2016, 10:29:44 am
That's also why using line breaks as syntax elements is not a good idea.
Agree.  But don't tell that to all those Python lovers:  They'll keell you...
Title: Re: The future of Free Pascal
Post by: AlexK on May 04, 2016, 11:30:20 am
C++ was mentioned.
C++ is а problematic, dead-end bloated language. C++ compilers are good only at optimizing(after many years of work of corporate employees).

GCC accumulated a lot of incomprehensible craft of optimizations, and it becomes difficult to maintain(rumors).
Clang(LLVM Machine Code) uses own meta-assembler for optimizations.

C++ as language is so unsound that IDE can be created only using compiler as a service(only C++ compiler can parse C++ code).
C++ semantic language tools are a impossible, but some companies try hard to create them and make them somewhat useful for something.
Compilation itself is slowest in industry(many hours for big libraries), and it's usually faster than analysis in semantic tools.

Creation of good C++ IDE became possible only after libclang appeared. In Emacs,  RTags using libclang in a separate process works by accumulating all compiler messages from terminal during initial compilation, deduces a lot of info from them, to navigate code, to parse macros, etc. Different build systems must be treated specially to collect compiler messages, for RTags process to create a database of compiled project. But in the end it's a most featureful and robust IDE.

QT GUI library requires additional compiler(code generator) for slots/signals in widgets, MOC - Meta Object Compiler.
The only reason to create it was that C++'s RTTI abilities are problematic(introspection and reflection).

Quote
The moc tool reads a C++ header file. If it finds one or more class declarations that contain the Q_OBJECT macro, it produces a C++ source file containing the meta-object code for those classes. Among other things, meta-object code is required for the signals and slots mechanism, the run-time type information, and the dynamic property system.

The C++ source file generated by moc must be compiled and linked with the implementation of the class.

"Signals" is how they called events. "Slots" are event handlers. Additional compiler MOC because C++ lacks in RTTI and type safety.
Compare:
http://doc.qt.io/qt-4.8/signalsandslots.html
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Events_(Delphi)

Another example, C's Gobject system in GLib for GTK+. Though it also allows creation classes at runtime, compatible with dynamic languages.

typinfo RTTI is important feature of the RTL in Free Pascal.
Title: Re: The future of Free Pascal
Post by: Thaddy on May 04, 2016, 01:47:47 pm
One counter example doesn't fully invalidate a principle. 
Well: https://en.wikipedia.org/wiki/Falsifiability (Karl Popper is my hero, so I am biased)

The rest is a nice write up Marco.
Title: Re: The future of Free Pascal
Post by: AlexK on May 04, 2016, 07:03:21 pm
Quote
Agree.  But don't tell that to all those Python lovers:  They'll keell you...

Python is OK.

Code: Pascal  [Select][+][-]
  1. {$modeswitch nestedprocvars}
  2. type TRetFunc = function: integer is nested;
  3. var func: TRetFunc;
  4.   function retNestedFunc: TRetFunc;
  5.   var num: integer;
  6.     function rf(): integer; begin
  7.       result := num;
  8.     end;
  9.   begin
  10.     num := 7;
  11.     result := @rf;
  12.   end;
  13. begin
  14.   func := retNestedFunc();
  15.   writeln(func()); { prints "7" }
  16.   writeln(func()); { prints "0", all subsequent calls of func return 0. }
  17. end.

I realistically don't expect it to create a closure, but nevertheless, why does first call to func() return 7...

EDIT:

That's actually an implication of the nestedprocvars mode switch, used only for backward compatibility with old pascal compilers.
Title: Re: The future of Free Pascal
Post by: ykot on May 12, 2016, 09:55:13 pm
Stumbled upon Free Pascal is very super mega ultra underrated. (https://www.reddit.com/r/ProgrammingLanguages/comments/4etdnc/free_pascal_is_very_super_mega_ultra_underrated/) post few days ago, which seems relevant to this discussion.

C++ is а problematic, dead-end bloated language. ...
Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.

When Delphi first appeared, the whole RAD approach coupled with a relatively sufficient language made it quite popular decades ago, but currently many other languages are quite enough and there are plenty of UI/RAD solutions out there. Really, there is nothing wrong with using C#, C, C++, Java or any other language these days (e.g. Swift) for application development and each of them, coupled with a huge collection of frameworks and libraries, are enough to work even on most challenging projects. Delphi, FreePascal / Lazarus work just fine as well, but since "Pascal" community is so small, it's difficult to convince companies and crowds to use a language that is unpopular and doesn't offer any significant benefits; in fact, at this point, no such language can possibly appear - existing languages already cover most needs, except, perhaps, for growing areas such as GPGPU, parallel computing, etc. - but these are pretty much saturated as well.

In this case, I think Lazarus as an IDE along with its LCL is the strongest bone. If Lazarus would switch to support C/C++ and LCL would be ported to that language as well - this, I think, *would* make it a killer product, at least for now. Designing UI outside of Delphi/Lazarus domain, although has become much easier, is still painful at times.

For instance, I can't help but to read posts regarding BGRABitmap with a bit of nostalgia attached to it - just to think of the things you could do in Delphi with TBitmap.Scanline some almost 20 years ago (and let's not forget about Graphics32 component too), and the whole thing of displaying more than 256 colors on the screen after DOS (please don't get me started with VESA) - these were some glorious days back then. I still remember walking like for two hours under the snow just to buy my first 3dfx Voodoo (was in Canada at that time) - it was so exciting! (Among many GPUs, Voodoo3, was the most exciting and pleasant to work/experiment with).

However, as almost every IT specialist who is old enough, would likely to experience this, even multiple times during lifetime, in computer world we have to realize that technologies that were so glorious many (and sometimes, maybe just few) years ago may become obsolete and we have to, un-learn and re-learn something entirely from scratch - and not necessarily because new tech is better than old one, but it's just happens. I'm not saying that this is necessarily going to happen (completely) with Delphi/FPC/Lazarus that some/all of us are using, but IMHO it's a tendency that becomes difficult not to see.
Title: Re: The future of Free Pascal
Post by: marcov on May 12, 2016, 10:57:37 pm
In this case, I think Lazarus as an IDE along with its LCL is the strongest bone. If Lazarus would switch to support C/C++ and LCL would be ported to that language as well - this, I think, *would* make it a killer product, at least for now. Designing UI outside of Delphi/Lazarus domain, although has become much easier, is still painful at times.

Yeah, just like how BCB killed Visual Studio. NOT.
Title: Re: The future of Free Pascal
Post by: ykot on May 12, 2016, 11:26:23 pm
Yeah, just like how BCB killed Visual Studio. NOT.

Actually, I meant adapting Lazarus to edit C/C++ sources (it already is capable of doing so, just adding code folding, code completion based off clang, for instance, etc.) and porting LCL to C++, using combination of GCC, Clang and MSVC. This would be kind of similar to CodeLite/Code::Blocks with wxCrafter, but using Lazarus as editor and LCL instead of wxWidgets. I didn't mean creating new compiler out of FPC to be kind of FreeC++ :)

BCB was actually a very smart move and I personally know several people who use it professionally for scientific projects. But how would you expect it to "kill" Visual Studio, when the latest one is provided by the same OS manufacturer? The whole idea is just ridiculous. It's kind of expecting Apple to discontinue XCode and adopt Delphi as their main dev tool.
Title: Re: The future of Free Pascal
Post by: marcov on May 12, 2016, 11:52:36 pm
BCB was actually a very smart move and I personally know several people who use it professionally for scientific projects. But how would you expect it to "kill" Visual Studio, when the latest one is provided by the same OS manufacturer?

Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.

Neither of which is going to work with gcc or llvm. 
Title: Re: The future of Free Pascal
Post by: ykot on May 13, 2016, 12:49:27 am
Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.
I understand what you are saying but don't quite agree. For one, to the best of my knowledge (and limits of NDA), there is no C++ port of VCL, at least not a complete port, and with purpose, so any changes/upgrades to VCL in Delphi would automatically be felt on C++ side, perhaps with some header adaptations. So you have IDE that can only run on Windows, VCL that can only run on Windows and third-party C++ compiler being a link between them, all of that against Visual Studio, which is native development tool on Windows and is the first one to receive all new bells and whistles from the same OS manufacturer.

Lazarus, on the other hand, runs on multiple platforms and, if not counting Pascal dialect, is a fully functional editor on its own, in many aspects, potentially best of its kind. Even if there could be issues porting LCL to another language, say C++ or Swift, for example, there is an existing functional Pascal port of LCL on many platforms, which has working solutions for many low-level cross-platform technical issues. As a result, creating a whole new framework based on LCL is still much easier than designing, creating and debugging a new one from scratch.
Title: Re: The future of Free Pascal
Post by: HeavyUser on May 13, 2016, 01:34:20 am
Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.
I understand what you are saying but don't quite agree. For one, to the best of my knowledge (and limits of NDA), there is no C++ port of VCL, at least not a complete port, and with purpose, so any changes/upgrades to VCL in Delphi would automatically be felt on C++ side, perhaps with some header adaptations. So you have IDE that can only run on Windows, VCL that can only run on Windows and third-party C++ compiler being a link between them, all of that against Visual Studio, which is native development tool on Windows and is the first one to receive all new bells and whistles from the same OS manufacturer.

Lazarus, on the other hand, runs on multiple platforms and, if not counting Pascal dialect, is a fully functional editor on its own, in many aspects, potentially best of its kind. Even if there could be issues porting LCL to another language, say C++ or Swift, for example, there is an existing functional Pascal port of LCL on many platforms, which has working solutions for many low-level cross-platform technical issues. As a result, creating a whole new framework based on LCL is still much easier than designing, creating and debugging a new one from scratch.
So the future of fpc is C++?
Title: Re: The future of Free Pascal
Post by: ykot on May 13, 2016, 02:15:00 am
So the future of fpc is C++?
Is that all you can synthesize from the above conversation? Only one of my points was that Lazarus/LCL can be extended and/or ported to different languages. As for future of adoption of FPC, that's quite speculative, but it really depends on where FPC devs will lead it to; in my opinion, focusing on finishing full support for embedded platforms will very likely increase chances for it to become more popular, as there is less competition there.
Title: Re: The future of Free Pascal
Post by: HeavyUser on May 13, 2016, 02:55:20 am
So the future of fpc is C++?
Is that all you can synthesize from the above conversation? Only one of my points was that Lazarus/LCL can be extended and/or ported to different languages.
Actually I got 3 points. 1) add c/c++ support to lazarus 2) Convert lcl to C/C++ and 3) everythings dies perhaps its time to leave pascal behind and move on. Then again I'm notoriously slow so I'm probably missing something. Then again I agree with you. Pascal's time reached its end. There is a new technological wave in the embedded front which they could take advantage of but the world is already C/C++ java and C# it has nothing to offer.
Title: Re: The future of Free Pascal
Post by: ykot on May 13, 2016, 03:54:04 am
Actually I got 3 points. 1) add c/c++ support to lazarus 2) Convert lcl to C/C++ and 3) everythings dies perhaps its time to leave pascal behind and move on. Then again I'm notoriously slow so I'm probably missing something. Then again I agree with you. Pascal's time reached its end. There is a new technological wave in the embedded front which they could take advantage of but the world is already C/C++ java and C# it has nothing to offer.
In a sense, yes. From what it looks like, the entire Pascal community (Delphi and FPC/Lazarus combined) now is rather small. I would speculate that many people who still stick exclusively to Pascal are those who have large codebase that cannot easily be moved somewhere else; some are realistically so, others just due to escalation of commitment (https://en.wikipedia.org/wiki/Escalation_of_commitment).

The reality, however, is that Pascal by itself is nothing special, it is just a language (just as others are, like C++, Java, etc.), and RAD paradigm that was revolutionary back in earlier Delphi days is no longer new - there are many alternative UI / RAD tools now, many of which are also cross-platform. This doesn't mean the language and/or its tools will die (a ridiculous statement by itself too), just they will be (or probably already are) a niche/exotic option that will either stick in that state for quite a while, fade away, or suddenly become super popular, for example, as Python has. This is why I mentioned embedded platforms - perhaps this could be a magical pill Pascal needs to get back to the throne. :)
Title: Re: The future of Free Pascal
Post by: HeavyUser on May 13, 2016, 06:38:11 am
The reality, however, is that Pascal by itself is nothing special, it is just a language (just as others are, like C++, Java, etc.), and RAD paradigm that was revolutionary back in earlier Delphi days is no longer new - there are many alternative UI / RAD tools now, many of which are also cross-platform.
Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards. I think that pascal has a lot of merit and it is compatible with my train of thought. So as a language it has its uniqueness that makes things different enough to be unpopular. As for the rad part, I haven't used any of the apple's  tools but even in visual studio only the windows form designer has a good flow and feel to it. even the wpf designer is lacking I'm not going to touch the open source designers where to even be able to place controls on a form you have to decide how they are suppose to behave when the form is resized. There is no RAD tool I found out there that comes close to what lazarus with all its problems has to offer. Sorry but there is nothing RAD to codeblocks, codelite or devc++ they are mediocre IDES at best or good editors at worst. Then again I might missed a good IDE other that visual studio.
Title: Re: The future of Free Pascal
Post by: marcov on May 15, 2016, 05:40:38 pm
Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.
I understand what you are saying but don't quite agree. For one, to the best of my knowledge (and limits of NDA), there is no C++ port of VCL, at least not a complete port, and with purpose, so any changes/upgrades to VCL in Delphi would automatically be felt on C++ side, perhaps with some header adaptations.

To my best knowledge the problem form streaming and loading, a problem QT has worked around with MOC in the past.

More recent C++ have some RTTI support, but I bet it won't cover loading DFMs from resources and setting all properties and event handlers.

Anyway, since that would be a forked codebase, I fail to see the relevance for the Lazarus project anyway.

For the rest of the discussion, I'll give you a few points:

And yes, many people stick with Pascal because they have codebases and existing knowledge. The fact that the main focus is on desktop apps is a dead giveaway.

That is the reality of choosing a development platform based on what you can actually achieve with it, rather than watercooler discussions "but there is some C++ project that does ... ", and "if you just port LCL to C++" on the back of a beercoaster.

The devil is actually finding the resources to do a project that is narrow enough in focus to have a chance of being finished in a finite time. That is/was the problem with Lazarus too.

Title: Re: The future of Free Pascal
Post by: AlexK on May 15, 2016, 08:15:20 pm
Stumbled upon Free Pascal is very super mega ultra underrated. (https://www.reddit.com/r/ProgrammingLanguages/comments/4etdnc/free_pascal_is_very_super_mega_ultra_underrated/) post few days ago, which seems relevant to this discussion.

C++ is а problematic, dead-end bloated language. ...
Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.

I never used Delphi. Was procrastinating once, and found Free Pascal.
It's a language to write a new modular OS(like Minix3 or Hurd) with a usage model of Gentoo(where users usually compile everything instead of downloading ready made packages, and they compile everything for many hours).
A language with balanced ratio of high level syntactic features and ease of portability to different architectures.
On the other hand, creation of self contained applications with needed versions of RTL/libs compiled in.
New wave of tech hobbyists' platforms, drones, new classes of devices that work on batteries.
"Internet of things" ideas(connect to internet everything you can, from vacuum cleaners to cars), that's embedded programming.

Object Pascal users were mostly on Windows, they just couldn't argument persuasively because they were detached from the open source world where ANSI C dominated due to existence of free compilers in the beginning of 90-s.
Now is a completely different context.

The only new language that solves many practical problems is Rust. But it's nailed to LLVM tools and completely depends on them, also Rust compiler is slow, and always will be, I guess. Rust is more difficult to read.

Object Pascal does not have GC, but it is compensated by a syntax that is fully amenable to static analysis tools in contrast with incomprehensible C++.
Besides, not all want GC in their program.
Title: Re: The future of Free Pascal
Post by: AlexK on May 15, 2016, 09:25:24 pm
Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards.

Repeat..until
For..in..do
For..to/downto..do
While..do

Variable declarations and types declarations are done right.

A good explanation what's a difficulty with C declarations - Go lang declaration syntax: https://blog.golang.org/gos-declaration-syntax

Quote
Go's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" (http://c-faq.com/decl/spiral.anderson.html) by David Anderson.
Though I like C, can't say the same about C++.
Title: Re: The future of Free Pascal
Post by: ykot on May 16, 2016, 12:07:30 am
Marco, I generally agree with what you said, but find it a bit difficult to understand what you tried to prove in your 1-3 points.

That is the reality of choosing a development platform based on what you can actually achieve with it, rather than watercooler discussions "but there is some C++ project that does ... ", and "if you just port LCL to C++" on the back of a beercoaster.
No need to be so too overprotective with this. Nobody said to take Lazarus away from FPC. :) I just simply acknowledged that Lazarus as IDE and LCL, in their own way, if could somehow get to C++ landscape, in my opinion, they would make a killer product. You think they won't? Okay, your opinion is just as good as mine. :)

Sorry but there is nothing RAD to codeblocks, codelite or devc++ they are mediocre IDES at best or good editors at worst. Then again I might missed a good IDE other that visual studio.
I think you didn't mention quite a few RAD IDEs (lists can be found somewhere in the middle of this (https://en.wikipedia.org/wiki/Graphical_user_interface_builder), this (https://en.wikipedia.org/wiki/List_of_graphical_user_interface_builders_and_rapid_application_development_tools), this (https://en.wikipedia.org/wiki/WxWidgets), and this (https://en.wikipedia.org/wiki/GTK%2B#Development), and probably many others, I doubt in finite time one can try them all to give accurate generalizations) and those that you mention are not UI RAD IDEs by themselves, they are editors and first two (can't say anything about DevC++ as I've never used it, especially since it's Windows-only) are pretty good at what they do.

Object Pascal users were mostly on Windows, they just couldn't argument persuasively because they were detached from the open source world where ANSI C dominated due to existence of free compilers in the beginning of 90-s.
Now is a completely different context.
...
The only new language that solves many practical problems is Rust. But it's nailed to LLVM tools and completely depends on them, also Rust compiler is slow, and always will be, I guess. Rust is more difficult to read.
It sounds like you haven't actually actually used many other languages for production, yet you still try to make large scale generalizations and predictions. You probably can do much better if you actually get to learn stuff that you easily dismiss (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect), so please stop this non-sense.
Title: Re: The future of Free Pascal
Post by: marcov on May 16, 2016, 12:36:07 am
No need to be so too overprotective with this. Nobody said to take Lazarus away from FPC. :) I just simply acknowledged that Lazarus as IDE and LCL, in their own way, if could somehow get to C++ landscape, in my opinion, they would make a killer product. You think they won't? Okay, your opinion is just as good as mine. :)

Well, that's what I also think, but then more the concept (everything under one roof and deeply integrated), then lazarus or VCL itself.

One of the biggest problems I have with C++ is the plethora of GUI libs without one being really dominant (QT and MFC comes closest). And QT is pretty but has MOCing issues, and no native windows offering and I never really liked MFC, it felt too much a macro set on top of winapi rather than an integrated offering.

The thing I like about VCL/LCL is that the windows apps are native, and the offering is still fairly portable.
Title: Re: The future of Free Pascal
Post by: AlexK on May 16, 2016, 01:13:03 am

Object Pascal users were mostly on Windows, they just couldn't argument persuasively because they were detached from the open source world where ANSI C dominated due to existence of free compilers in the beginning of 90-s.
Now is a completely different context.
...
The only new language that solves many practical problems is Rust. But it's nailed to LLVM tools and completely depends on them, also Rust compiler is slow, and always will be, I guess. Rust is more difficult to read.
It sounds like you haven't actually actually used many other languages for production, yet you still try to make large scale generalizations and predictions. You probably can do much better if you actually get to learn stuff that you easily dismiss (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect), so please stop this non-sense.

I don't use Lazarus because I prefer Emacs.
Using C++ in production means compiling for hours using ad hoc build tools.
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?

In the thread about future of Free Pascal you are posting about adding support to C++ in Lazarus(whatever that means) and advising to learn stuff.
Title: Re: The future of Free Pascal
Post by: ArtLogi on May 16, 2016, 07:09:01 am
Some talk have been made about embedded, I'm sure for most active readers/writers this project isn't nothing new, but for us newbies.  :)

https://ultibo.org/faq/
Quote
What programming language does Ultibo use?
Ultibo is written entirely in Free Pascal and is designed to act as a unikernel or a kernel in a run time library. That means when you compile your application the necessary parts of Ultibo are automatically included by the compiler so that your program runs without needing an operating system.
Title: Re: The future of Free Pascal
Post by: ykot on May 16, 2016, 04:59:03 pm
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?
1. Yes. 2. What do you mean by "fail"? Compiler bugs and internal errors? I got my dose of them, so yes and no. :) 3. n/a.

In the thread about future of Free Pascal you are posting about adding support to C++ in Lazarus(whatever that means) and advising to learn stuff.
That is correct. :)

One of the biggest problems I have with C++ is the plethora of GUI libs without one being really dominant (QT and MFC comes closest). And QT is pretty but has MOCing issues, and no native windows offering and I never really liked MFC, it felt too much a macro set on top of winapi rather than an integrated offering.
Yes and this is why I like LCL approach more, where it really uses native controls on multiple platforms and its usage is pretty clean and intuitive.

Some talk have been made about embedded, I'm sure for most active readers/writers this project isn't nothing new, but for us newbies.  :)
Ultibo is quite nice, curiously I just checked it out few days ago and had no idea it used FPC. Raspberry PI is great, but by embedded platforms, I primarily meant embedded ARM and AVR. One of the things I would really love to see on somewhere around this web site, is a precompiled FPC/Lazarus bundle that can arbitrarily target Arduinos, much in the same way as Arduino IDE does. FPC already supports great deal of AVR chips and combined with Lazarus as IDE, it would be a much stronger alternative to Arduino IDE. Even so, maybe someone from FPC dev team can contact Arduino, asking for their financial backup to support a superior development platform? (I know they are probably trying to develop something of their own, but still...)
Title: Re: The future of Free Pascal
Post by: AlexK on May 16, 2016, 10:32:19 pm
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?
1. Yes. 2. What do you mean by "fail"? Compiler bugs and internal errors? I got my dose of them, so yes and no. :) 3. n/a.

It's a consumeristic approach to a non commercial tool.
You propose as an alternative a problematic language(C++) because its compilers benefited from many years and millions of corporative support(despite everything).
Taking that into account, it still lacks something similar with LCL's architecture, which you are pointing out as interesting.

Once, compiler writer Walter Bright finally gave up on C++ and developed a new language.

Ultibo posted earlier is an entrepreneur's approach, which is good and expected since authors are aussies(not ex-users of pirated Delphi on pirated Windows in ex-USSR):

www.youtube.com/watch?v=XfR9iY5y94s
Title: Re: The future of Free Pascal
Post by: ArtLogi on May 16, 2016, 10:46:43 pm
It seems still to be distributed under some opensoftaware licence (I put it this way since I'm not too knowledgeable on these in general), even if does have enterpreteur aproach. Obviously if something like this is succesfull even as a standalone fork from the FPC it still benefits the whole object pascal community.  :)
Title: Re: The future of Free Pascal
Post by: HeavyUser on May 19, 2016, 03:25:42 am
Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards.

Repeat..until
For..in..do
For..to/downto..do
While..do

Variable declarations and types declarations are done right.

A good explanation what's a difficulty with C declarations - Go lang declaration syntax: https://blog.golang.org/gos-declaration-syntax

Quote
Go's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" (http://c-faq.com/decl/spiral.anderson.html) by David Anderson.
Though I like C, can't say the same about C++.
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.
Title: Re: The future of Free Pascal
Post by: Leledumbo on May 19, 2016, 08:37:23 am
or in the worst case a DIY document how to patch or convert one for that hardware.
So do we (http://wiki.lazarus.freepascal.org/TARGET_Embedded), in a more general way as the options still need to be tailored for the specific hardware. "The rich gets richer, the poor gets poorer" applies in commercial programming industry. Vendors are likely to pick up major languages that can fit their hardware. Fighting back from inside requires huge effort to turn the market, which sounds impossible when done sporadically without commercial backup. You must learn how Sun can convince the world to switch over to Java in a C++ domination, despite it's a weaker product by a lot of ways.
Title: Re: The future of Free Pascal
Post by: HeavyUser on May 19, 2016, 11:06:55 am
So do we (http://wiki.lazarus.freepascal.org/TARGET_Embedded), in a more general way as the options still need to be tailored for the specific hardware.
No you don't, you have a generic how to code for embedded systems. I'm talking about specifics. You missed the point completely.
"The rich gets richer, the poor gets poorer" applies in commercial programming industry.
That's BS. It is not the commercial environment that has that effect and open source does not help to stop poverty. Lets not confuse the issue with useless politics.
Vendors are likely to pick up major languages that can fit their hardware.
Vendors will pick up whatever benefits them the most, language is not a direct variable on the that equation, but that should be self evident.
Fighting back from inside requires huge effort to turn the market, which sounds impossible when done sporadically without commercial backup.
erm fighting what or whom exactly?
You must learn how Sun can convince the world to switch over to Java in a C++ domination, despite it's a weaker product by a lot of ways.
OK, I'll byte, share with us your inside insight. How did sun managed to propagate Java?
Title: Re: The future of Free Pascal
Post by: AlexK on May 19, 2016, 04:09:32 pm
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.

C and C++ are different languages.
C99 standard has some features not available in C++: https://en.wikipedia.org/wiki/Flexible_array_member.

C99 array initialization(for C++ it was implemented only in g++ -std=c++11):
Code: C  [Select][+][-]
  1. int widths[] = { [10 ... 99] = 2, [0 ... 9] = 1, [100] = 3 };

Initializing array of struct:
Code: C  [Select][+][-]
  1. struct { int x,y; } ar[ 4] = { [1].x=23, [3].y=34, [1].y=-1, [1].x=12};

On the other hand, it took decades for C to start promoting types with defined size: int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.
Also:
int_leastN_t - signed integers with a width of at least N
int_fastestN_t - fastest signed integers with a width of at least N

There's no Boolean type in C.
Some type hints in C prevent or advice compiler's internal optimizations: volatile, restrict("restricted pointers", a hint).

Free Pascal has "absolute" keyword, practically undocumented, although the de facto convention is that compiler does not perform optimizations that would lead to necessity of compiler hints.
This area is still grey for me.
Title: Re: The future of Free Pascal
Post by: HeavyUser on May 19, 2016, 05:05:16 pm
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.

C and C++ are different languages.
Well I have heard that many times over the years. Considering that C++ started as an extension that compiled code to C and not directly to cpu code it has more than 50% of language idioms shared with C that in my book makes them the same language, then again I consider turbo pascal 6~7 dialect the same language as delphi and object pascal, so interpretation is subjective and plays no major role on the syntax of those languages that was the topic on my comments not so much the features of each language. EE I do not think that FPC supports direct initialization of non local variable at all and I'm not sure it supports array initialization outside the const declaration. When I say got things backwards I mean declaration wise ee int X,Y; instead of X,Y : int; etc
C99 standard has some features not available in C++: https://en.wikipedia.org/wiki/Flexible_array_member.

C99 array initialization(for C++ it was implemented only in g++ -std=c++11):
Code: C  [Select][+][-]
  1. int widths[] = { [10 ... 99] = 2, [0 ... 9] = 1, [100] = 3 };

Initializing array of struct:
Code: C  [Select][+][-]
  1. struct { int x,y; } ar[ 4] = { [1].x=23, [3].y=34, [1].y=-1, [1].x=12};

On the other hand, it took decades for C to start promoting types with defined size: int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.
Also:
int_leastN_t - signed integers with a width of at least N
int_fastestN_t - fastest signed integers with a width of at least N
first time encountering these constructs but if my interpretation is accurate then I need to read up on them. Thank you.

There's no Boolean type in C.
Some type hints in C prevent or advice compiler's internal optimizations: volatile, restrict("restricted pointers", a hint).

Free Pascal has "absolute" keyword, practically undocumented, although the de facto convention is that compiler does not perform optimizations that would lead to necessity of compiler hints.
This area is still grey for me.
All those features are good and all but it is not the features that will help the future of a language. I think that  uniqueness, comfort and speed of development is. I'm all for the "complete form" (sorry I'm stuck can't remember the proper word for it) of code that pascal supports but it needs to add features to reduce code from somewhere else to give an impression of smaller and easier to understand code base. Let them find their unique position on the market. RAD is a good arrow on their quiver along with the homogeneous component library but they suffer a bit on granularity. By the way no C/C++ is not the  future of FPC nor Java, .NET, python or any other language. They need to focus on one section and make sure that it does it better than every other tool on the market in a way that 1) everyone using it can be productive in a small period of time 2) colleges can use it to demonstrate/teach all the aspects of that sector in a concise and easily understandable manner. In short become THE right tool for a job. That's my opinion, so take with a grain of salt.
Title: Re: The future of Free Pascal
Post by: AlexK on May 19, 2016, 10:42:53 pm
All those features are good and all but it is not the features that will help the future of a language. I think that  uniqueness, comfort and speed of development is.

It creates an impression that languages move into the future. That's a side effect of the hype created by corporative languages.
As an analogy, some say that there's nothing new in automobiles since 1920s-30s, just optimization of the production process(also now cars are made so that it would be difficult or impossible to repair them in non-authorized shops).

C# tried to take Java's place, didn't make it. Then they tried to make it the language for the game industry. Game industry continued with C++ in its main part. When asked about GC, their answer is - "we use memory pools, each type has its own characteristics in time and space, so using a generalized GC is not efficient, and specific libraries from the start were meant to be written in C++, and for the scripting we use interpreters with REPL".

C# has coroutines, but such features usually make compiler more difficult to port, and coroutine is a special case of a class with a dispatcher method(no stack manipulation magic is required, though things get to look verbose).

They need to focus on one section and make sure that it does it better than every other tool on the market in a way that 1) everyone using it can be productive in a small period of time 2) colleges can use it to demonstrate/teach all the aspects of that sector in a concise and easily understandable manner. In short become THE right tool for a job. That's my opinion, so take with a grain of salt.

The focus is on portability of compiler, as I understand. Everything else depends on libraries.
Low level language can be perceived as high level due to specific libraries(C). Or high level language like Python, by using native modules, can do things that low level languages usually do.
Title: Re: The future of Free Pascal
Post by: AlexK on May 29, 2016, 09:22:09 pm
One mistake(IMO) I noticed in the implementation, is making "program" statement optional. It was required in TurboPascal as I understand.

I use Emacs, and see benefits in that program statement, if it were required.
Given a large code base and required program statement, I could have just recursively grep(rgrep) a directory to find all "compilation entry points" of the code. In C it's a main function.

Would be usable in any other IDE.
Title: Re: The future of Free Pascal
Post by: Leledumbo on May 29, 2016, 09:30:57 pm
One mistake(IMO) I noticed in the implementation, is making "program" statement optional. It was required in TurboPascal as I understand.
Nope, in fact the optionality is a leftover from TP. It was required in ISO Pascal and FPC's ISO mode respects that.
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on June 17, 2016, 11:23:17 pm
C++ is for masochists, who like to be encouraged to do things that harm them.

You have to do nearly everything yourself, because libraries are not portable at all.

The few standard libraries available all introduce their own and completely different syntax.

Everything is IDE and platform dependent.

And it is really hard to read, because the definition and syntax are context-sensitive. That's also why no two compilers agree.
Title: Re: The future of Free Pascal
Post by: Akira1364 on June 19, 2016, 02:16:06 am
Stumbled upon Free Pascal is very super mega ultra underrated. (https://www.reddit.com/r/ProgrammingLanguages/comments/4etdnc/free_pascal_is_very_super_mega_ultra_underrated/) post few days ago, which seems relevant to this discussion.

C++ is а problematic, dead-end bloated language. ...
Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.

When Delphi first appeared, the whole RAD approach coupled with a relatively sufficient language made it quite popular decades ago, but currently many other languages are quite enough and there are plenty of UI/RAD solutions out there. Really, there is nothing wrong with using C#, C, C++, Java or any other language these days (e.g. Swift) for application development and each of them, coupled with a huge collection of frameworks and libraries, are enough to work even on most challenging projects. Delphi, FreePascal / Lazarus work just fine as well, but since "Pascal" community is so small, it's difficult to convince companies and crowds to use a language that is unpopular and doesn't offer any significant benefits; in fact, at this point, no such language can possibly appear - existing languages already cover most needs, except, perhaps, for growing areas such as GPGPU, parallel computing, etc. - but these are pretty much saturated as well.

In this case, I think Lazarus as an IDE along with its LCL is the strongest bone. If Lazarus would switch to support C/C++ and LCL would be ported to that language as well - this, I think, *would* make it a killer product, at least for now. Designing UI outside of Delphi/Lazarus domain, although has become much easier, is still painful at times.

For instance, I can't help but to read posts regarding BGRABitmap with a bit of nostalgia attached to it - just to think of the things you could do in Delphi with TBitmap.Scanline some almost 20 years ago (and let's not forget about Graphics32 component too), and the whole thing of displaying more than 256 colors on the screen after DOS (please don't get me started with VESA) - these were some glorious days back then. I still remember walking like for two hours under the snow just to buy my first 3dfx Voodoo (was in Canada at that time) - it was so exciting! (Among many GPUs, Voodoo3, was the most exciting and pleasant to work/experiment with).

However, as almost every IT specialist who is old enough, would likely to experience this, even multiple times during lifetime, in computer world we have to realize that technologies that were so glorious many (and sometimes, maybe just few) years ago may become obsolete and we have to, un-learn and re-learn something entirely from scratch - and not necessarily because new tech is better than old one, but it's just happens. I'm not saying that this is necessarily going to happen (completely) with Delphi/FPC/Lazarus that some/all of us are using, but IMHO it's a tendency that becomes difficult not to see.

Hey, that's me! :D I somewhat over-simplified my points for the Reddit crowd, but the thread was 87% upvoted so clearly there's a decent number of people out there who see the benefits of FPC/Lazarus! I do also fully agree with you about the tendency of some Object Pascal programmers to have an unwarranted hatred of C++ (it's a fine, useful language, perfectly worthy of the popularity it has....a comment like the one "SymbolicFrank" made above is objectively disingenuous), however, the concept of adding some kind of C++ Builder-clone functionality to Lazarus is just a bad idea. The Borland C++ compiler is and always has been the absolute worst (just embarrassingly bad) commercial C++ compiler available (there's a very good reason Embarcadero recently scrapped it completely in favor of Clang), and everything about the C++ Builder IDE is just "ok, this sort of works, it's kind of like Delphi I guess, but not as good". Any attempt to imitate it would just be an attempt to imitate something that was mostly a running joke to begin with.
Title: Re: The future of Free Pascal
Post by: Thaddy on June 19, 2016, 09:41:28 am
I might add - as I did before - that it is perfectly possible to write readable C++ (yes, really!) . And it is also possible to make Object Pascal as unreadable as some C++ (yes, really!). All these discussions are often based on comparing apples with pears. What is a fact, though, is that C++ oriented programmers tend not to know about the current capabilities of Object Pascal, refer to their "knowledge" that is at least 25 years old and therefor dismiss it for the wrong reasons. I simply recommend that you should be proficient and current  in/on at least more than one compiled language. And don't ignore scripting languages either. It may very well be that in that case we could consider such a person as being a serious programmer. Heck, if that person is capable of implementing the same functional specification in more than one language, we might even call that person a pro ;) And if that person chooses the right tool for the right part of the job, even a seasoned pro... O:-) O:-)
Title: Re: The future of Free Pascal
Post by: Akira1364 on June 20, 2016, 12:38:11 am
I feel like many people (Object Pascal programmers and also just people in general trying to learn C++) are often scared off because so many of the examples out there use the idiotic "K&R" bracing style (which if I recall correctly, only exists because Brian Kernighan needed to make sure each piece of example code in "The C Programming Language" would fit properly on one page when the book was being printed back in the late 70s, and that was the easiest way to cut down on whitespace... it was not a personal preference thing at all.)

I mean, compare these two examples (I'm using the JavaScript code tags as they're the closest to C++)

Code: Javascript  [Select][+][-]
  1. int main() {
  2.     cout << "Hello World";
  3.     return 0;
  4. }

Code: Javascript  [Select][+][-]
  1. int main()
  2. {
  3.    cout << "Hello World";
  4.    return 0;
  5. }

You can see exactly where the "begin" and "end" would go in the second one, right?  ;)
Title: Re: The future of Free Pascal
Post by: ykot on June 20, 2016, 03:57:07 am
...however, the concept of adding some kind of C++ Builder-clone functionality to Lazarus is just a bad idea. The Borland C++ compiler is and always has been the absolute worst (just embarrassingly bad) commercial C++ compiler available (there's a very good reason Embarcadero recently scrapped it completely in favor of Clang), and everything about the C++ Builder IDE is just "ok, this sort of works, it's kind of like Delphi I guess, but not as good". Any attempt to imitate it would just be an attempt to imitate something that was mostly a running joke to begin with.
I wouldn't say that C++ Builder's compiler is bad, but I personally am not fan of the whole trend (that started lightly with Turbo C) of adding proprietary extensions to the language, to a point where the code would become completely alien to a different compiler, requiring a significant rewrite. I have same issue with Visual C++, although I really like their introduction of properties (https://msdn.microsoft.com/en-us/library/yhfk0thd.aspx),  too bad GCC/Clang don't support it. But my point wasn't to create C++ Builder clone, rather than just porting LCL; in fact, initially, it doesn't need to have WYSIWYG editor - this can be done later. In fact, I don't think that any RTTI limitations in C++ should be a barrier for this - it is possible to create/load visual forms without it (in fact, Asphyre's UI and its WYSIWYG designer didn't use RTTI at all yet still worked).

I might add - as I did before - that it is perfectly possible to write readable C++ (yes, really!) . And it is also possible to make Object Pascal as unreadable as some C++ (yes, really!). All these discussions are often based on comparing apples with pears.
Absolutely agree. In fact, I think every language can have these extremes.

I also recall, back in 2000, when a friend of mine used Delphi to create some sort of logic analyzer, where in form's "OnCreate" event he would start application main loop and never return, calling "ProcessMessages" to handle UI events. In same application, he would use TListBox with size to fit exactly one item, which with its miniature scrollbar (just big enough to accomodate up/down arrows, no client area) would essentially work as some sort of "Top/Down Spin Box", but more obscure as you can have one or multiple items selected, that are not what you currently see in such "spin box". This might not be example of "unreadable code", but it's an illustration that you can screw up, if you really want to, in any language or development tool.

What is a fact, though, is that C++ oriented programmers tend not to know about the current capabilities of Object Pascal, refer to their "knowledge" that is at least 25 years old and therefor dismiss it for the wrong reasons.
Remember that the same happens in reversed roles, and IMHO, to a higher degree - especially because of complexity of C++ and intensive additions to the language, starting with C++11, then C++14 and still ongoing with C++17.

P.S. A question on topic, how hard would it be for FPC to create a back-end for non-Pascalish syntax? That is, still use compiler and its optimizations, but parse a different syntax, say something like C or JavaScript?
Title: Re: The future of Free Pascal
Post by: Thaddy on June 20, 2016, 10:25:24 am
@Ykot
I remember I had a C grammar from c. 1985 that I used c. 1990 to translate C into Pascal (not object pascal, but procedural pascal). I wrote it during compiler engineering classes. AIR there were some quirks on the input, with some language constructs like ternary operators not accepted as well as <var>++ (as opposed to ++<var> and the likes) but that was not very difficult. I used Yacc and Lex (Pyacc, Plex are in the bin directory) for that. I must still have that somewhere, but no clue where. It was really more like a transformation, but still ll(1). And the generated Pascal code compiled.
In general it should be possible to present the high level code generator back-end with a parse tree in the correct format and it *should* work, but I never tried that So, yes: it is possible. Is it easy? No, not really. Not for me. Maybe the real compiler engineers can shine a light on that. (I wasn't very good at that, not bad, just average, I am better managing things)
Title: Re: The future of Free Pascal
Post by: guest58172 on June 20, 2016, 11:58:31 am
I also recall, back in 2000, when a friend of mine used Delphi to create some sort of logic analyzer, where in form's "OnCreate" event he would start application main loop and never return, calling "ProcessMessages" to handle UI events. In same application, he would use TListBox with size to fit exactly one item, which with its miniature scrollbar (just big enough to accomodate up/down arrows, no client area) would essentially work as some sort of "Top/Down Spin Box", but more obscure as you can have one or multiple items selected, that are not what you currently see in such "spin box". This might not be example of "unreadable code", but it's an illustration that you can screw up, if you really want to, in any language or development tool.

That's a "library thing" and that's even not a "standard library thing". Actually I think that the Object pascal implementation in FPC is very robust because the language is itself very simple (for example if you compare it to D). It's really hard to shot yourself in the foot with the language itself. Major bugs come from libraries or from the other side of the screen.
Title: Re: The future of Free Pascal
Post by: jack616 on June 20, 2016, 12:42:36 pm
The future of free pascal depends on one thing and one thing only - marketing
(however you want to define that)
Title: Re: The future of Free Pascal
Post by: Thaddy on June 20, 2016, 12:43:02 pm
@BBasile
You hit on the big issue: the library thing, which is as you explained completely different from a compiler's capabilities.

@Jack616
Programming languages tend not to be marketable really easily. Marketeers forget that. There are almost no marketeer geeks. It is not a marketing issue and never has been. TP sold itself by being unique as a compiler and having a strong academic support at that point in time in the sense that the Pascal language was used in and the de-facto standard in academic education. And had an educational price-point. In that sense, oh well, maybe there was some marketing brilliantness by Philippe Kahn. Compilers at that stage used to be either  free (for academic use) or unaffordable (for commercial use). Nowadays compilers are free by default. The market got spoiled and many more languages compete in an arena that had been a pretty closed market between few general purpose languages. That certainly has changed.
Title: Re: The future of Free Pascal
Post by: AlexK on June 20, 2016, 07:29:24 pm
I feel like many people (Object Pascal programmers and also just people in general trying to learn C++) are often scared off because so many of the examples out there use the idiotic "K&R" bracing style

If they are idiots or rookies. Others are scared by the lack of a module system in C++, long compilation times.
Title: Re: The future of Free Pascal
Post by: Pasqualish on July 11, 2016, 09:53:06 am
Well, Delphi is as good as dead.

The company is still in business, the product is still being sold. On what basis are they "as good as dead"?
Title: Re: The future of Free Pascal
Post by: Thaddy on July 11, 2016, 12:34:55 pm
The company is still in business, the product is still being sold. On what basis are they "as good as dead"?

Well. It is still marketed and it still generates revenue (but not new sales volume) but is is half-baked maintained.
Real insiders consider it dead, like in the dead parrot scene of Monty Python, it's pushing up the daisies, gone to meet its maker,  it it is an ex-parrot. Amongst these insiders are the most eloquent engineers and scientists that once contributed to Delphi development but also many of the resellers that have to put up with that. The marketing is more or less the orchestra playing while the ship sinks.
Title: Re: The future of Free Pascal
Post by: Ñuño_Martínez on July 13, 2016, 01:00:11 pm
I think Embarcadero don't know what Delphi was/is and what they can do with it.  May be they look Delphi as a problem instead of an answer.  Pretty sad. :(
Title: Re: The future of Free Pascal
Post by: Thaddy on July 13, 2016, 01:25:20 pm
I think Embarcadero don't know what Delphi was/is and what they can do with it.  May be they look Delphi as a problem instead of an answer.  Pretty sad. :(

Don't mix up the product with the language. The product Delphi is no longer breathing. The language that is on many ways its heritage isn't.
 
Title: Re: The future of Free Pascal
Post by: marcov on July 13, 2016, 02:37:15 pm
Don't mix up the product with the language. The product Delphi is no longer breathing. The language that is on many ways its heritage isn't.

And that has also been said several times from D8 onward, with significant progress made after.
Title: Re: The future of Free Pascal
Post by: iru on December 12, 2016, 11:46:12 am
I have read this entire chain and it has been a great help in focusing my thoughts.

I have been in the computer business for 50 years working on hardware, OS, networks and the odd application or two. Programming was initially machine language and then assembler.

Pascal has been my tool of choice for over 30 years, Turbo Pascal, Delphi, FPC, etc.
Strongly typed, good syntax and good compilers which gave good diagnostics.
If you don't use it for a while the compilers and easy to use IDE inform you that you have forgotten syntax and not as smart as you thought you were

Recently I thought I would expand my thinking and looked at languages like Rust and Haxel. Haxel is good, a reasonable and interesting  language but then you get into frameworks to support somewhat basic GUI.
Then there are a number of IDE, all with their own issues and problems of integrating with OS and the Haxe/Haxelib environment.
Then there are issues with compiling for the various hardware and software environments, X86, ARM, HTML5,Linux,Windows......

Following a tutorial I made a change to an extension to "Kode" a fork of VisualStudio (I agreed with the tutorial, it was an improvement to the basic structure of the code).
It crashed with an exception at line 115, 361 of a 160, 000+ line JavaScript file.

So I am battling with a new languages (Haxe) and the supporting environment (JS, etc). If you do anything outside the basics there are problems everywhere.

FPC, Lazurus, fpGui, etc are known to me. Things work easily.

The problem is using it in the newer environments of web and clouds, etc. So I only have one problem, getting the Pascal compilers and IDE to develop run time code for the newer environments.

There are a lot of things around, here I go again.......
Title: Re: The future of Free Pascal
Post by: bee on December 12, 2016, 12:12:02 pm
The problem is using it in the newer environments of web and clouds, etc. So I only have one problem, getting the Pascal compilers and IDE to develop run time code for the newer environments.
What's your problem exactly? I've been writing server-side web apps on clouds using FPC just fine. For example, you could try CodeAnywhere (https://codeanywhere.com)'s VPS service (it offers free account with some limitations but you can use it without problem), install FPC on it, and write some web apps. Here's my account on CA, cak.lebah.web.id (http://cak.lebah.web.id) where I experiment with FPC and Swift.
Title: Re: The future of Free Pascal
Post by: lazie on March 05, 2017, 09:54:26 pm
“Only the best live twice”  8-)

In earlier times the big success of Pascal was concentrated in the company Borland.
- Thas was a problem:

Borland was renaming the company many times (some lost the connection to Pascal within the 90s)... - Some decisions of Borland did not be good for Pascal/Delphi. The Company was loosing developers to Microsoft (big money offers...)....

One could get other languages/compilers for free. - Turbo Pascal/Delphi was only a product for windows - so other languages which where costless and platform-independent could extremely easy win from that situation.

TODAY the situation of Free Pascal/Lazarus is much better for the future !
It is in hands of the community....
.. – it is not really important – that people (first trend-orientated) talk and talk to much theoretically about some details of the “Pascal language of yesterday” (before OOP).
There is ever a different point of view to talk about – til u USE it.

Lazarus is a big thing to build usefull applications for Linux... (- like they do it for Windows).

If there would have been Free Pascal/Lazarus in earlier times – I would have been with Pascal since the early 80s without interruption.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 05, 2017, 10:29:26 pm
Coming from C, C++, PHP, Python, Lisp - even though I actually did start out in Pascal in the 80's - I am pleasantly surprised to return (after 20+ years) to a language that is modern, and in many ways ahead of the 'competition'. ;)

I am also extremely happy to see that FreePascal and Lazarus are being worked on actively.
That makes me excited!

Object Pascal is not really that old:
PHP, JavaScript, Ruby and Java all went public in 1995, when Object Pascal did.
And Python is from 1993, AFAIK.

It was unfortunate that Borland screwed up, and that Microsoft screwed Borland by stealing their chief engineer and 30% of their staff.

What Lazarus/FPC has, that Delphi hasn't, is that it is community built and fully open source.

So, here's to long life!  ;D
Title: Re: The future of Free Pascal
Post by: eMko on March 18, 2017, 01:55:36 pm
The problem is using it in the newer environments of web and clouds, etc. So I only have one problem, getting the Pascal compilers and IDE to develop run time code for the newer environments.
What's your problem exactly? I've been writing server-side web apps on clouds using FPC just fine. For example, you could try CodeAnywhere (https://codeanywhere.com)'s VPS service (it offers free account with some limitations but you can use it without problem), install FPC on it, and write some web apps. Here's my account on CA, cak.lebah.web.id (http://cak.lebah.web.id) where I experiment with FPC and Swift.

Since FreePascal and C are both compiled into native code, there is no reason why their position in this environment should be that different from the technical point of view (if we won't think of number of programmers - staffing Pascal project (or any other which is not in a mainstream language) can be quite a nightmare for every corporate manager (trust me - last year we had a research project, we used F# for that - project was a success, but now it will have to be rewritten into C# because nobody here can understand functional programming)).

In my previous company (which I left 2 years ago) we had an old information system (early 1990s) with core written in C and PL/SQL (with tiny bits of C++) running on Unix with later addition of Linux support (mid 2000s). User interface was VB6 and VB.Net (Windows.Forms), web services in C# (Windows Communication Foundation) - that was my part. Systems like these are not unusual. Calling a native library from .Net is quite an easy thing (no matter whether it's C or Pascal if you stick to primitive types/pointers to structures with primitive types and think about memory in advance; C++ can be a little bit problematic), the same with messaging between Java/.Net/whatever on one system and a native code on another.

Would you write a complete web application (including a front-end) in C? Well, you definitely can via FastCGI. Does anybody do that? Of course! But 999 projects of 1000 are done in other languages. For most of the projects, the language or run-time inefficiency doesn't really matter that much. What matters more is either time-to-market ratio and cheap development with a ton of ready-made frameworks (PHP, Python, Ruby) or manageability of an over-grown over-complicated over-engineered system reflecting corporate business rules which nobody understands so much they can give you a "big picture" (Java). Compiled native code gives you some advantages, especially efficiency. The price is slow development and changes taking more time (compared to scripting languages) and worse maintainability (compared to Java and C#, projects in those languages and environments are quite manageable even if some programmers are "average at best"). This is sometimes a very good trade-off.

When comparing C++ and FreePascal, the latter gives you more readable code in a language with very few "dark corners and traps" and fast compilation times. Downside is smaller community and harder to find workforce. No pointy haired boss wants that, because those are no benefits for him. So there is very little reason why you couldn't use FP in your project even in cloud environment or on the web. However since the biggest benefit of doing that is comparative rapid development and a native code performance, i.e. things which are not a top priority in those environments, you can have quite a hard time finding a job for that.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 18, 2017, 02:03:58 pm
Object Pascal is not really that old:
PHP, JavaScript, Ruby and Java all went public in 1995, when Object Pascal did.
Wrong. Object Pascal dates from 1986. https://en.wikipedia.org/wiki/Object_Pascal.
I had a first view of Delphi in December 1994. It was public indeed in Februari 1995. Maybe you confuse Delphi and Object Pascal.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 19, 2017, 01:05:00 pm
Wrong. Object Pascal dates from 1986. https://en.wikipedia.org/wiki/Object_Pascal.
I said that it went public in 1995, which is correct.
I am not confusing Delphi and Object Pascal here because Delphi is indeed the foundation of modern Object Pascal.
With emphasis on 'modern'.

It's like C, if you treat it like you treat object pascal, you would include A and B, wouldn't you? :p

That is my definition of modern Object Pascal anyway.
I am aware that some form of object pascal went before it, but I don't count that as a public specification of the language.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 19, 2017, 01:27:57 pm
Wrong. Object Pascal dates from 1986. https://en.wikipedia.org/wiki/Object_Pascal.
I said that it went public in 1995, which is correct.
I am not confusing Delphi and Object Pascal here because Delphi is indeed the foundation of modern Object Pascal.
With emphasis on 'modern'.

It's like C, if you treat it like you treat object pascal, you would include A and B, wouldn't you? :p

It is most definitely NOT correct. Object Pascal went public in 1986.
TP5.5 also pre-dates Delphi with a good many years. That's the stupidest answer I have seen for decades. <grumpy mode firmly on  >:D >:D >:D >:D >
TP5.5 is the foundation of modern Borland flavored  object pascal as we know it. The Delphi language extensions merely bolted on to that.
Object oriented Wirthian languages were also available way before 1995. Don't be silly. Look at the facts.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 19, 2017, 01:36:17 pm
Don't be a fucking moron, Thaddy.

Modern Object Pascal := Delphi.

What went before that leads up to the language that we use now:

Quote from: Marco Cantu
After 9 versions of Turbo and Borland Pascal compilers, which gradually extended the language into the Object Oriented Programming (OOP) realm,Borland released Delphi in 1995, turning Pascal into a visual programming language. Delphi extends the Pascal language in a number of ways, including many object-oriented extensions which are different from other flavors of Object Pascal, including those in the Borland Pascal with Objects compiler (the last incarnations of Turbo Pascal).

That's flavors, precursors, in my book.

And I really don't think that it's stupid.
Title: Re: The future of Free Pascal
Post by: Artlav on March 19, 2017, 09:36:05 pm
To add an outsider perspective to the discussion, i would have liked to see a clean and modular pascal ecosystem.

Lazarus the IDE and Lazarus the rapid GUI designer should be two separate things, since all the desktop/RAD stuff is a rarely used ballast by now.
It's nice to see the IDE part had come a long way (since http://forum.lazarus.freepascal.org/index.php/topic,29210.msg183997.html#msg183997 ), it's almost as good as Delphi 7 with productivity mods now, with just a few annoying quirks.
But looking at it's code reveals a cheetah dragging a dead elephant of all the forms, components, objects and so on.
It would have been nice to be able to separate the two.

On the compiler level, a cleanly defined interface and implementation part - being able to have a completely agnostic compilation part separate from an OS- and environment-dependent I/O and UI part.
That is, being able to include some units unto a program, and have an interface that you can feed a string and a buffer pointer to, and get a compiled code spewed out into the buffer.
This would enable embedded compiler, just-in-time compilation, high-performance scripting, CGI-like web stuff and so on.

On the language level, i would have liked to see all the object oriented stuff dropped. It was always painfully ugly in pascal, and practically useless.
The parts i would have kept are abstract types like string and operator definitions.
Since these are my personal preferences, i don't expect that to ever happen, but if the compiler was modular it could have been a matter of some compiler definitions to build a "lite" version and "object" version, once again giving an option to unharness the cheetah from the cartfull of dead elephants.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 19, 2017, 11:18:45 pm
I am not sure what you are after, but FreePascal can be configured to use different modes:
http://www.freepascal.org/docs-html/user/userse33.html

Perhaps FPC mode ?
Quote
all language constructs except classes, interfaces and exceptions are supported. Objects are supported in this mode.
Title: Re: The future of Free Pascal
Post by: Artlav on March 19, 2017, 11:36:33 pm
I am not sure what you are after, but FreePascal can be configured to use different modes:
Not exactly.
I'm looking at the compiler and IDE as a piece of code, not as a binary to use, and easily 95% of that code implements features i don't need or won't ever use.
If it was more modular, removing the unused parts would have been practical.
Title: Re: The future of Free Pascal
Post by: howardpc on March 19, 2017, 11:57:05 pm
Seems to me you're looking for a (modular) DE (development environment), not an IDE (integrated DE), perhaps an editor with macros etc. for compilation and intellisense tailored to the language in use.
It is a feature of Lazarus' integration that nearly every part of the DE knows about (and hence to an extent depends on) the other parts, (else it would be a dis-integrated environment).
For example, Alt-Up takes you to the declaration of the class you are in, whether it is in the same unit, the same package, another part of the LCL, the FCL or a third-party package. That does not just depend on clever CodeTools as a modular plugin. It depends on fairly deep integration between the 'modules' in the IDE, and the whole 'project' and 'project group' concept.
That said, you can actually use CodeTools quite independently from the Lazarus IDE in your own projects, because it has been written in a modular way.
Title: Re: The future of Free Pascal
Post by: Akira1364 on March 20, 2017, 01:32:47 am
almost as good as Delphi 7

Uh, I think you mean "way, way better than Delphi 7 in every conceivable way." Seriously, have you tried to use Delphi 7 recently? It's not a good time. Open it and even just try dragging one of the dockable windows across the screen. Smooth, huh?  ::) And don't forget about the great and useful hints and warnings provided by that version of the Delphi compiler! Or how it totally didn't need FastMM to be viable for any sort of moderately high-performance application! (Not, on both points.)

i would have liked to see all the object oriented stuff dropped

Ah, that explains everything then. I suppose in your perfect world we'd all still be using Turbo Pascal on DOS? ;)

Seriously though, this kind of highlights what I think is a real barrier to the continued improvement/modernization of Object Pascal: there are simply far too many people who for whatever reason view ancient IDEs/Compilers through rose-tinted lenses. I've even seen people try to advocate for the use of Lazarus by talking about how it's "basically a free Delphi 7", as though that's somehow impressive, or something anyone would get excited about in this day and age. (It's not.) If you want to get people using Lazarus, then talk about the numerous features that make it unique, or more generally about the various high-quality libraries available for FPC that aren't available for Delphi, or so on and so forth. Don't compare it to a 15-year-old IDE that flat out sucks by all modern standards!
Title: Re: The future of Free Pascal
Post by: Bostjan on March 20, 2017, 09:21:52 am
Pascal and then Delphi was my first programing language/tool and I am still nostalgic about it.
I am impressed with how good the FPC/Lazarus become and I am using it to maintain few older applications ported over from D2007 and D7.

But truth be told FCP/Lazarus is no match for modern day Visual studio, C# and .net, especially now that you have free community edition of VS and .net being open sourced.
If you absolutely must use language compiled to native machine code then I would say that FPC/Lazarus is still the best option for general purpose development since I dislike C++ and other compiled alternatives are to obscure to to find developers.
But now days the managed languages are good enough for almost any task. And for really low level stuff like drivers, kernel, low level libraries the C is still de fact standard.

Just my 2c, don't shoot the me :)   
Title: Re: The future of Free Pascal
Post by: tr_escape on March 20, 2017, 09:44:52 am

But truth be told FCP/Lazarus is no match for modern day Visual studio, C# and .net, especially now that you have free community edition of VS and .net being open sourced.

Just my 2c, don't shoot the me :)

How can you describe the "Modern Day" ? I think you mean popular culture of desktop/backend(Server side) programming.

I am still using delphi and fpc for production lines , as scada solutions (pascal scada) , testing softwares in very hard conditions.

Ok we won't shoot you :)
Title: Re: The future of Free Pascal
Post by: Thaddy on March 20, 2017, 09:50:34 am
Don't be a fucking moron, Thaddy.

Modern Object Pascal := Delphi.

What went before that leads up to the language that we use now:

And I really don't think that it's stupid.
Well. Commercial interests are interesting. I would rather see that you stick to the facts.
The fact is that Delphi just introduced some syntactic candy and RTTI. I still use Freevision daily and also use it for KOL.
Object Pascal dates from 1986, not 1995. That's silly. >:D

The reason I use it (and many others do) is that öld school objects are stack based and more efficient than heap based classes. Classes are just another tool in the toolbox. The concept of Object Pascal dates from 1986. Period. And even TP5.5 dates only from 1998.(beta) and 1999 (release). I know. I worked for them.
Title: Re: The future of Free Pascal
Post by: Bostjan on March 20, 2017, 10:41:14 am

But truth be told FCP/Lazarus is no match for modern day Visual studio, C# and .net, especially now that you have free community edition of VS and .net being open sourced.

Just my 2c, don't shoot the me :)

How can you describe the "Modern Day" ? I think you mean popular culture of desktop/backend(Server side) programming.

I am still using delphi and fpc for production lines , as scada solutions (pascal scada) , testing softwares in very hard conditions.

Ok we won't shoot you :)

Modern day as the latest versions, so VS 2015 & 2017, .net 4.5 +, C# 6.0 +, and so on.
I remember when I was using D7 and then went to college where I started with Java and early versions of Eclipse and C# with visual studio .net 2002. For me it was like going back in time.
But now the situation is reversed VS studio, C# and .net is so much better and same for PyCharm + Python 3.5 or InteliJ + Java & Kotlin & Scala. These tools and languages surpassed FPC/Lazarus by a long way. It's understandable since their development is driven by companies and larger communities.

And yes FPC/Lazarus is still viable to use for existing projects, why change something just for sake of changing tools.
But for new projects I see less and less reasons to use FPC/Lazarus or any other compiled language, since modern managed or scipting alternatives are so much better.
Except for kernel, drivers or some low level libs, but for that I would use C which is still de facto standard. 
Title: Re: The future of Free Pascal
Post by: snowyforest on March 20, 2017, 11:31:16 am
Is there any machine  learning or sentific algorithm library written in pascal?  :(
Title: Re: The future of Free Pascal
Post by: tr_escape on March 20, 2017, 11:33:40 am
Is there any machine  learning or sentific algorithm library written in pascal?  :(

http://forum.lazarus.freepascal.org/index.php?topic=32620.0 (http://forum.lazarus.freepascal.org/index.php?topic=32620.0)
Title: Re: The future of Free Pascal
Post by: tr_escape on March 20, 2017, 12:02:07 pm

Modern day as the latest versions, so VS 2015 & 2017, .net 4.5 +, C# 6.0 +, and so on.
I remember when I was using D7 and then went to college where I started with Java and early versions of Eclipse and C# with visual studio .net 2002. For me it was like going back in time.
But now the situation is reversed VS studio, C# and .net is so much better and same for PyCharm + Python 3.5 or InteliJ + Java & Kotlin & Scala. These tools and languages surpassed FPC/Lazarus by a long way. It's understandable since their development is driven by companies and larger communities.

-- OK. We are a small community means they have got a lot of power we expect more powerful tools from them... ;)


And yes FPC/Lazarus is still viable to use for existing projects, why change something just for sake of changing tools.

-- Yes because it isn't easy to port whole project to new tools.

But for new projects I see less and less reasons to use FPC/Lazarus or any other compiled language, since modern managed or scipting alternatives are so much better.

-- What kind project will you start ? I would like to look into.

Except for kernel, drivers or some low level libs, but for that I would use C which is still de facto standard.

-- For information my advise this project:
https://github.com/ultibohub (https://github.com/ultibohub)

Title: Re: The future of Free Pascal
Post by: Handoko on March 20, 2017, 12:49:06 pm
Modern day as the latest versions, so VS 2015 & 2017, .net 4.5 +, C# 6.0 +, and so on.
I remember when I was using D7 and then went to college where I started with Java and early versions of Eclipse and C# with visual studio .net 2002. For me it was like going back in time.
But now the situation is reversed VS studio, C# and .net is so much better and same for PyCharm + Python 3.5 or InteliJ + Java & Kotlin & Scala. These tools and languages surpassed FPC/Lazarus by a long way. It's understandable since their development is driven by companies and larger communities.

-- OK. We are a small community means they have got a lot of power we expect more powerful tools from them... ;)

The words "better" depends on the person who use it.

I don't earn from programming. I'm okay to spend money, but it should be affordable. I write programs and share with my friends, I use Linux they use Windows. So it should at least be able to compile to Linux and Windows. This forum is very active, I visit here often enjoying reading others sharing their experiences and learning a lot from them.

So, do VS 2015 & 2017, .net 4.5 +, C# 6.0 + have these?
- Affordable
- Can compile to Linux and Windows
- Have good forum

If not, then for me Lazarus/FPC is better. I'm open to new thing, if anyone know VS can pass my 3 requirements lets me know, I will try them. Currently, I plan to learn C++.
Title: Re: The future of Free Pascal
Post by: minesadorada on March 20, 2017, 01:10:07 pm
For coding desktop apps which can be cross-compiled I think Laz/FPC is a great combination.  The IDE is fine and compilation is fast - and few auxiliary files to distribute.

It is a superb hobby language/IDE to quickly code a solution that looks pretty good on a desktop.

Internet and phone apps maybe not so good compared with other environments.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 20, 2017, 01:15:05 pm
Dear Thaddy - I see where you are coming from: Object Pascal, as an idea, is from 1986.
We just have different ways of defining what Object Pascal is.
My definition is Object Pascal in it's final form is from 1995. Hejlsberg did wonderful things for - and I know that he did it with Turbo Pascal before it evolved into Delphi - the language, until he started to put everything but the kitchen sink into it. ((And before Borland screwed up, and Microsoft bought the major part of their engineers))


I have programmed in C, C++, PHP, C#, Python, ... - and I tell you:

Free Pascal's version of Object Pascal is a modern language.
A very modern language, indeed.

The fact that Free Pascal is not owned / backed by a huge corporation is a good thing.

Yes, I wish that the community was bigger, but that's not a selling point for me.
I know quality when I see it.

I agree fully with what Kamburelis writes in his great overview of Modern Object Pascal:
http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html (http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html)

Edit:
Besides the elegance of the language, the fact that you can easily cross compile and distribute (read: xcopy) a fully self-contained executable, that is a killer feature!  ;D
Golang does that.
But it doesn't even come close to Free Pascal, which is fully native!
And, in my opinion: much more beautiful (as a language).
Title: Re: The future of Free Pascal
Post by: Artlav on March 20, 2017, 01:18:32 pm
Uh, I think you mean "way, way better than Delphi 7 in every conceivable way." Seriously, have you tried to use Delphi 7 recently?
Have been using it for over a decade, and seriously i'm only comparing to it because it's the only other pascal IDE with language&debugger integration there is to compare to.
Make no mistake, it's quite crusty and i had to tweak WINE in a rather unpleasant way to make it usable.
However, compared to it Lazarus still lacks some vital features like multiple source editor window support (how would you manage a project with 100 of files without that?).

Not all is lost - i've been giving Lazarus a try every couple years, and this time it's actually looking pretty good - nice, modern IDE, great code tools, works without crutches.
Pretty much the only show stopper is the scaling - give me a way to work comfortably on a hundred file project in Lazarus, and Delphi 7 would go down the drain.

I suppose in your perfect world we'd all still be using Turbo Pascal on DOS? ;)
Good horrors, no.
I wouldn't go back to TP7 and TMT pascal even if i was paid to.

I don't like object oriented syntax of both C++ and Pascal, it's ugly and does not fit the languages.
So, i would have cut it down to the parts that enable defining abstract types, and no more - constructor, destructor, operator overload. Things you need to implement a string type, a dynamic array, a big integer, etc.
On the missing features, i would have liked to see C++ style code templates added - these save a lot of copy-pasting.

there are simply far too many people who for whatever reason view ancient IDEs/Compilers through rose-tinted lenses.
Honestly, seeing where Borland went after D7, i'm not too surprised.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 20, 2017, 03:18:38 pm
Says somebody who is using a Delphi version so old it doesn't even know {$pointermath on} and then starts complaining. Rather odd isn't it..... Sigh... FPC even changed its semantics to be Delphi compatible... Sigh, again... You are definitively using D7 or below. Even Delphi evolved.... Sigh.... Sorry, your examples, both here and on the bug tracker simply work with recent Delphi's and FPC.
Title: Re: The future of Free Pascal
Post by: RAW on March 20, 2017, 03:20:23 pm
I would love to see FREE PASCAL and LAZARUS living forever and getting more important to programming in general...

I HATE  >:D DotNet-UpdatePackages and C++ RedistPackages and Java-Runtime-Crap and even more stupid developers and companies that aren't able to write down those requirements where I can see this immediately. I don't want so recognize that when installing or testing a new software.

It's so beautiful to write FREE PASCAL-Programs and LCL-Programs and LLCL-Programs and fpGUI-Programs within one nice IDE. And get a lot of nice libraries to work with it just for free too... that's a great gift! LONG LIVE FREE PASCAL..  :)

Yeaahhh, I don't know a .... about real world programming needs... , but I think TURBO PASCAL and DELPHI had once a great position on the market and without the power of the MS-machinery the PASCAL language would be as popular as it was once.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 20, 2017, 03:23:05 pm
I HATE  >:D DotNet-UpdatePackages and C++ RedistPackages and Java-Runtime-Crap and even more stupid developers and companies that aren't able to write down those requirements where I can see this immediately. I don't want so recognize that when installing or testing a new software.
Well, first do any course in computer science.  I would advise pre-beginner.
Title: Re: The future of Free Pascal
Post by: RAW on March 20, 2017, 03:36:04 pm
Quote
Well, first do any course in computer science.  I would advise pre-beginner.
Thanks for the tip, but I don't want to get brainwashed to love all this ... I think there are enough people who think this way and I just want to keep my position for a while...
Title: Re: The future of Free Pascal
Post by: snowyforest on March 20, 2017, 03:37:53 pm
Is there any machine  learning or sentific algorithm library written in pascal?  :(

http://forum.lazarus.freepascal.org/index.php?topic=32620.0 (http://forum.lazarus.freepascal.org/index.php?topic=32620.0)

Great! Thank you. :)
Title: Re: The future of Free Pascal
Post by: Handoko on March 20, 2017, 03:39:47 pm
I HATE  >:D DotNet-UpdatePackages ...

I don't have problem with dot Net framework. But I dislike it because it is not backward compatible. Some weeks ago, I helped my customer install his office computer. He own a license software cd. It failed to install because it requires .net 2. That computer is using Windows 7 and already has dot net 3.5 installed. I went to MS .net website to download .net version 2. But sadly, it said .net 2 can't install on 64-bit Windows. What  >:(
Title: Re: The future of Free Pascal
Post by: RAW on March 20, 2017, 03:47:22 pm
@Handoko: me too...
That's exactly the same with C++: I installed the 2010-Pack and several 2013-Packs and an old ChessPRG requires the 2008-Package. What ?! And of course that one won't install on Windows 7. Once I had the 2008 Package installed, but I can't remember how...
Title: Re: The future of Free Pascal
Post by: Deepaak on March 20, 2017, 04:18:30 pm
@Handoko: me too...
That's exactly the same with C++: I installed the 2010-Pack and several 2013-Packs and an old ChessPRG requires the 2008-Package. What ?! And of course that one won't install on Windows 7. Once I had the 2008 Package installed, but I can't remember how...

I don't agree at all.. I have installed 2008 packages many times ad not a single time any problem is faced. Dot-net have limitations. But it is all choice of the developer. No development tool/language is bad. Every one comes with its own advantages/disadvantages.


@Handoko Windows 7 have built in .net 2.0 package installed aside with .net 3.5. No separate package is required for .net 2.0.
Title: Re: The future of Free Pascal
Post by: marcov on March 20, 2017, 04:36:51 pm
Windows 10 has standard .NET 4.0, and 3.5 must be manually installed
Title: Re: The future of Free Pascal
Post by: Handoko on March 20, 2017, 04:38:09 pm
@Handoko Windows 7 have built in .net 2.0 package installed aside with .net 3.5. No separate package is required for .net 2.0.

That's strange. I found no .net 2 for 64-bit to download. I tried to install it several times, I just said .net 2 can't be install on 64-bit Windows. The problem had solved, by downgrading (I mean reinstall) the Windows to 32-bit. Before I downgraded it, I also tried to install .net 4.5, that software won't install it ask .net 2.

I'm not familiar with .net things, but this experience makes me thing MS .net is not backward compatible.

Note:
Actually that software can be installed without .net 2. But when starting it show error saying it require .net version 2.
Title: Re: The future of Free Pascal
Post by: Graeme on March 20, 2017, 04:49:58 pm
The future of Free Pascal?  As an open source project it will live forever. For real-world work there isn’t any future - use Java (the #1 language in the world) instead.

[and I run and hide]

 ;)
Title: Re: The future of Free Pascal
Post by: marcov on March 20, 2017, 04:52:19 pm
The future of Free Pascal?  As an open source project it will live forever. For real-world work there isn’t any future - use Java (the #1 language in the world) instead.

Doing it yourself is so 2000s. Hire IBM global services to do it for you!
 
Title: Re: The future of Free Pascal
Post by: Handoko on March 20, 2017, 05:20:57 pm
When installing Java runtime I get message "3 billion devices run Java". Really? Compare to Java, Free Pascal is too microscopic.  :P
Title: Re: The future of Free Pascal
Post by: Thaddy on March 20, 2017, 05:38:45 pm
The problem is that most programmers do not want to see their mistakes and start programming without any clue about what they are trying to do.
Object Pascal tries to prevent you from making those mistakes.
Code: C  [Select][+][-]
  1. {int (follows a macro explaining basically nothing)   i; // index declared somewhere else...
  2. ...several thousands  of  lines further, while i is supposed to be still valid.....but one of the team forgot....
  3. ..... i:= 100;{// oh, I forgot a variable, lets call it Z (not z)...\n
  4. }}
  5.  
People make mistakes. At least both Kernigan and Richie admitted that (both loath that they invented half a language) . Soustrup has - while he is still alive - a huge problem keeping the hornet nests in a somewhat regulated order. And Pascal is still readable and prevents you from making silly assumptions.

.. and: why can't I have a zero in my array of char?
Title: Re: The future of Free Pascal
Post by: BeniBela on March 20, 2017, 06:09:16 pm
The problem is that most programmers do not want to see their mistakes and start programming without any clue about what they are trying to do.
Object Pascal tries to prevent you from making those mistakes.
Code: C  [Select][+][-]
  1. {int (follows a macro explaining basically nothing)   i; // index declared somewhere else...
  2. ...several thousands  of  lines further, while i is supposed to be still valid.....but one of the team forgot....
  3. ..... i:= 100;{// oh, I forgot a variable, lets call it Z (not z)...\n
  4. }}
  5.  
People make mistakes. At least both Kernigan and Richie admitted that (both loath that they invented half a language) . Soustrup has - while he is still alive - a huge problem keeping the hornet nests in a somewhat regulated order. And Pascal is still readable and prevents you from making silly assumptions.

Actually it is the other way around.

Pascal:

Code: [Select]
var i: integer;
begin
  for i := .. to ... do begin
  end;
  // long code
  do something with another variable, but accidentally type variable i
end;

C:

Code: [Select]
{
  for (int i=..;i<=..;i++) {
  }
  // long code
  do something with another variable, but accidentally type variable i
}


Guess which language protects you from the mistake of using the wrong variable?
Title: Re: The future of Free Pascal
Post by: avra on March 20, 2017, 06:20:38 pm
However, compared to it Lazarus still lacks some vital features like multiple source editor window support
That exists for a long time: http://wiki.freepascal.org/New_IDE_features_since#Multi_Source_Editor

Quote
Pretty much the only show stopper is the scaling - give me a way to work comfortably on a hundred file project in Lazarus, and Delphi 7 would go down the drain.
This will also help: http://wiki.freepascal.org/New_IDE_features_since#Project_Groups
Title: Re: The future of Free Pascal
Post by: Handoko on March 20, 2017, 06:32:38 pm
Thanks avra. Many useful IDE tricks can be found from the link you provided.
Title: Re: The future of Free Pascal
Post by: JuhaManninen on March 20, 2017, 06:46:21 pm
Pretty much the only show stopper is the scaling - give me a way to work comfortably on a hundred file project in Lazarus, and Delphi 7 would go down the drain.
This will also help: http://wiki.freepascal.org/New_IDE_features_since#Project_Groups
A project group helps only with many related projects. I understood the hundred files belong to one project.
Artlav, what exactly does not work with hundred files?
I think the IDE scales well. For example the Lazarus project itself has rather many source files but I can work with them smoothly using the IDE.
Title: Re: The future of Free Pascal
Post by: RAW on March 20, 2017, 08:21:28 pm
Quote
...use Java (the #1 language in the world)
Maybe that's true, but the fact that many people use JAVA or buy a certain book or do whatever doesn't mean that this has something to do with quality. More often it's the other way around...

And of course if you all like to install again and again a new C++Pack or a new DotNet-Version or JAVA-Runtime then have fun with it... Quality is something else and somewhere else!
I really don't know why they don't create at least some kind of backward compatibility. Maybe they are not smart enough...  or C++/DotNet is not smart enough ... whatever ... :P
Title: Re: The future of Free Pascal
Post by: Artlav on March 20, 2017, 08:39:27 pm
That exists for a long time: http://wiki.freepascal.org/New_IDE_features_since#Multi_Source_Editor
Except it does not work like that - either you have to use non-docked mode, which is completely unusable due to a horrific amount of disconnected clutter on the screen, or you use docked mode and have to have all the editor windows on screen all the time.

Thanks for the link, however - this is quite a useful page, and i haven't even imagined looking for some of these features...

Artlav, what exactly does not work with hundred files?
Switching between them in a quick fashion.
In Delphi 7 you could group them into separate windows, and switch between the windows with either a hotkey or a list in the menu.
In Lazarus, i haven't yet found a way to either get several editor tab sets or windows without producing an explosion of clutter, or in some other way to quickly go to an arbitrary file in a project.

The closest think is right clicking on the tabs and selecting the file from the "other tabs" list, which is still somewhat unpleasant.
Title: Re: The future of Free Pascal
Post by: JuhaManninen on March 20, 2017, 10:11:38 pm
In Lazarus, i haven't yet found a way to either get several editor tab sets or windows without producing an explosion of clutter, or in some other way to quickly go to an arbitrary file in a project.
I often keep 2 editor windows open, side by side, both almost from screen top to bottom. More than 2 would be clutter, yes, but so it would be with Delphi 7.
This is also why I prefer the undocked layout with separate windows. I get high editor windows and can keep helper windows like Messages and Call Stack partly behind them. The helper windows get focus only when I really need them. This layout utilizes best the available space.

In Lazarus the editor bookmarks are global for all files, not local for each file like in Delphi.
Thus jumping in code with bookmarks is handy. 10 marks is enough because it is quite the max to remember (for me). Often I don't pay attention which file gets a bookmark. I find an important place in code by jumping in it or by debugging. It can be in .pas file or .inc file, who cares. The bookmark will take me there later.
So, for me it works very well.
Title: Re: The future of Free Pascal
Post by: avra on March 20, 2017, 10:19:03 pm
That exists for a long time: http://wiki.freepascal.org/New_IDE_features_since#Multi_Source_Editor
Except it does not work like that - either you have to use non-docked mode...
Like in D7? Sorry, couldn't resist  :D

Quote
Thanks for the link, however - this is quite a useful page, and i haven't even imagined looking for some of these features...
You're welcome.
Title: Re: The future of Free Pascal
Post by: Graeme on March 20, 2017, 11:45:07 pm
Maybe that’s true, but the fact that many people use JAVA or buy a certain book or do whatever doesn’t mean that this has something to do with quality. More often it’s the other way around…
Normally (but not always) quality comes from a lot of people using a product. Having millions of developers working with Java, and 100’s developing it definitely adds to Java’s quality. The massive eco system, and 3rd party support in very very impressive too.

Quote
I really don’t know why they don’t create at least some kind of backward compatibility. Maybe they are not smart enough…
I can’t speak for C++ or DotNet, but Java’s backward compatibility is once again very impressive. Just recently I used Java class files (I don’t have the *.java files any more) in a new program. Those original class files were written and compiled around 2002-2004, and they still worked with my program compiled in 2017, using the latest JDK!! If that’s not good backwards compatibility, then I don’t know what is. Either way, you can’t do that with FPC’s *.ppu or Delphi *.dcu files.

But then, I didn’t want to get into a Programming Language pissing contest. I simply posted about Java as a joke. I really do like Object Pascal and Java though, and use them daily in my paying work.
Title: Re: The future of Free Pascal
Post by: Artlav on March 21, 2017, 12:07:27 am
Like in D7? Sorry, couldn't resist  :D
Not quite.
In D7 windows are made out of a block of tabbed editor, code browser and message area, which means that i only have 2 visible windows to deal with - the top bar and the stack of editor windows.
More precisely, it is capable of a middle ground between all docked and all separate.

Plus, the way Windows handle windows, it all shows as one window on taskbar instead of filling the entire thing as Lazarus does.

In Lazarus the editor bookmarks are global for all files, not local for each file like in Delphi.
That's rather neat.
Which actually raises a question - is there a list somewhere of all these small differences?

Just recently I used Java class files (I don’t have the *.java files any more) in a new program. Those original class files were written and compiled around 2002-2004, and they still worked with my program compiled in 2017, using the latest JDK!!
What sort of dependencies did these class files have?
A .class file is like an .o or .dll file, and the bytecode haven't been changed in decades, so if they are reasonably self-contained i won't be surprised to see them work.
Title: Re: The future of Free Pascal
Post by: RAW on March 21, 2017, 12:40:57 am
Quote
I simply posted about Java as a joke.
Yeahh, I know...  :)

I can't remember the last time I used a program that requires JAVA RUNTIME, I just hate this never-ending C++/DotNet-PackageInstallBullshit. A little bit more and I got a lot more Packages than normal software... grrrrr...
Especially with C++2008 and not even a good and useful Error-Message that I or anybody else can understand...  >:(
I see a lot of posts in other forums about this ugly topic...

I hate it when I see a nice program and that program needs DotNet 4.5 for example... Then I always think "Hey why can't you use OBJECT PASCAL or FREE PASCAL or maybe C..."
Title: Re: The future of Free Pascal
Post by: Artlav on March 21, 2017, 02:20:21 am
Ran into another problem with Lazarus.
When you have a source file behind a symlinked directory, then the IDE will open the file in it's linked name when an error pops up, but will open it in the place the link points to during debugging - two different tabs of the same file!
That's nearly a show-stopper level of annoying.

Anyone know how to fix this?
Title: Re: The future of Free Pascal
Post by: JuhaManninen on March 21, 2017, 10:10:00 am
That's nearly a show-stopper level of annoying.
That may be a little exaggerated.

Quote
Anyone know how to fix this?
Symlink handling has improved in trunk. See:
 http://bugs.freepascal.org/view.php?id=31260
Please test and report back.
Title: Re: The future of Free Pascal
Post by: Artlav on March 21, 2017, 11:35:45 am
Symlink handling has improved in trunk. See:
 http://bugs.freepascal.org/view.php?id=31260
Please test and report back.
Tried out the latest SVN.
No difference at all.

Situation:
In /domain/prg/gr/scatter/src we have:
scatter.lpi
scatter.pas
ogla -> /domain/prg/baselib/ogla

In the IDE in scatter.pas i ctrl-click on a function from a file from ogla.
The tab opens, with path of /domain/prg/gr/scatter/src/ogla/raleygpu.pas

Now i set a breakpoit and run it.
It reaches the breakpoint and opens a new tab with (2) added to it's name and /domain/prg/baselib/ogla/raleygpu.pas as the path.

Now, let's say i close the first tab and keep only the one the debugger opened.
I run the program, and suddenly i have a breakpoint trigger where there is none.

If i try to type in the debugger's tab and make an error, then on compile the first tab will re-open with the error highlighted.
If i change it in the first tab, i would get a "reload changes from disk" dialog.

Am i missing something, or should i make a bug report for this?

That may be a little exaggerated.
Random breakpoints that you can't remove because it was set in another version of the file?
Duplicate tabs all the time over the place?
Constantly asking about reloading changes from disk?

Pretty darn annoying.
Title: Re: The future of Free Pascal
Post by: Graeme on March 21, 2017, 12:28:49 pm
I can’t remember the last time I used a program that requires JAVA RUNTIME,
I actually use a lot of Java based programs here. UMLet, jEdit, Eclipse IDE, trolCommander etc. Installing the JRE (actually the JDK - just in case) is one of the first things I do after a new OS install.

Quote
I just hate this never-ending C++/DotNet-PackageInstallBullshit.
DotNet is totally pointless for me. It’s a bad ripoff of Java, since SUN sued Microsoft all that years ago.


Quote
I hate it when I see a nice program and that program needs DotNet 4.5 for example… Then I always think “Hey why can’t you use OBJECT PASCAL or FREE PASCAL or maybe C…”
My issue with Java for years has been memory consumption. But these days I made peace with that. What modern PC doesn’t come standard with 8GB or RAM anyways? My desktop system has 32GB RAM and my laptop has 16GB RAM.

Saying that, I have recently seen a YouTube video where a guy debunks a lot of Java Myths. He managed to run a JVM with a small desktop application in less than 5MB or RAM. Obviously the more 3rd party libraries you include in your application, the memory consuption goes up. This guy also showed that you can run Java ME with less than 1MB of RAM (and some other embedded specific JVM with less than 20KB of RAM). Hell, even the Raspberry Pi v1 came out with 512MB RAM, and my phone has 4GB RAM.

As for speed, it should be well known that Java is no slouch these days. My recent tests (seen in the Graphics section of this forum) shows that my Java executable ran circles around the FPC based executable, and even a C executable.

As for security. The Java security issues that made so many headlines were mainly down to the Java Plugin used by web browsers. Java itself is very secure.
Title: Re: The future of Free Pascal
Post by: marcov on March 21, 2017, 12:36:00 pm
I can’t remember the last time I used a program that requires JAVA RUNTIME,
I actually use a lot of Java based programs here. UMLet, jEdit, Eclipse IDE, trolCommander etc. Installing the JRE (actually the JDK - just in case) is one of the first things I do after a new OS install.

I think since Libre Office no longer requires it, I only use MP LabX which is a NetBeans derivate.

Quote
Quote
I just hate this never-ending C++/DotNet-PackageInstallBullshit.
DotNet is totally pointless for me. It’s a bad ripoff of Java, since SUN sued Microsoft all that years ago.

DotNet got many things right (like mandatory JIT, generics, nullable types and autoboxing) that a sleeping Java fixed only in 1.5 and after. It's interoperability with native code is better/easier too. (pinvoke vs jni)

But most importantly I like .NET as a platform much more than Java with its keep everything at arms length attitude. Java might be fine for enterprise heterogeneous apps, but for small and medium biz, I think the .NET eco system is actually better

(disclaimer I abandoned these kinds of languages in 2005, might have changed since)

Title: Re: The future of Free Pascal
Post by: JuhaManninen on March 21, 2017, 12:40:35 pm
Am i missing something, or should i make a bug report for this?
This debugger issue seems different from the issue in bug tracker. I think it should be reported.
Further possible forum discussion about the subject should happen in a new thread. This thread is supposed to be about "the future of Free Pascal" but actually contains other things.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 21, 2017, 12:59:41 pm
Java is terrible!

The syntax is verbose, the libraries huge, ..

I remember around 2000 when Java was really hot, and new multi-volume books about it came out every year - you bought one, and it was already out of date, ..

Years later, and .NET was the new hot, with huge books that instantly became outdated when they were published..

The .NET family of languages, especially C#, is really a much better Java.
Sadly, it requires a runtime, and it is a hassle to have to deal with assemblies - they are even more cumbersome than regular DLLs! Horrible!

I blame .NET and Hejlsberg and Microsoft - they stole the Borland engineers, remember? for the fact that it is not Delphi and Object Pascal that dominates today.

Yes, .NET is fast and Java is quite close to be just as fast, but the runtime!

.NET is open source, Mono has been for years, and now Microsoft themselves opened up the rest of it, so it is much better than Java, that still suffers from being choked by a corporate entity (Oracle).
Remember the recent vulnerabilities, and just how slow they dealt with it?

I am a Linux guy, and I would actually reach for .NET before reaching for Java.

However, I like native code, and I like small and nimble executables.
C is much better than C++ in that regard, but Free Pascal is actually better.  ;D

Disclaimer:
I like my languages small.
Thus I do prefer PHP to Node.js, C to C++, and - in the end: .NET to Java.
Title: Re: The future of Free Pascal
Post by: BeniBela on March 21, 2017, 01:44:54 pm

My issue with Java for years has been memory consumption. But these days I made peace with that. What modern PC doesn’t come standard with 8GB or RAM anyways? My desktop system has 32GB RAM and my laptop has 16GB RAM.

My laptop has 4gb

i have huge issues running firefox, java ide and javac.

everyrthing freezes
Title: Re: The future of Free Pascal
Post by: Artlav on March 21, 2017, 01:49:25 pm
This debugger issue seems different from the issue in bug tracker. I think it should be reported.
Ok, submitted - http://bugs.freepascal.org/view.php?id=31577
Title: Re: The future of Free Pascal
Post by: Graeme on March 21, 2017, 05:15:35 pm
Java fixed only in 1.5 and after.
To be fair, Java 1.5 is a very long time ago. Yes there was a slowdown of Java development for a while (SUN exiting, Oracle finding its feet), but nowadays Java language progress is going very strong.

Quote
…but for small and medium biz, I think the .NET eco system is actually better
And with that decision you can’t target Linux, FreeBSD or OSX. So you are cutting out a huge chunk of potential business.

Title: Re: The future of Free Pascal
Post by: jacmoe on March 21, 2017, 05:20:32 pm
What kind of .NET are you referring to?

.NET core:
https://www.microsoft.com/net/core/platform

.NET framework:
http://www.mono-project.com/

For all platforms.
Title: Re: The future of Free Pascal
Post by: Graeme on March 21, 2017, 05:28:47 pm
Java is terrible!
The syntax is verbose, the libraries huge, ..
Then we agree to disagree. ;)  The more I use Java, the more I like it. As for syntax, I think Object Pascal is way more verbose. In java you don’t have to duplicate class method definitions (like in Object Pascal in the Interface section and the Implemenation seciton). Object Pascal is simply C/C++’s .c and .h rolled into one. Java simply said  - you don’t need to duplicate method definitions.

The libraries are huge, simply because they implement everything under the sun. I don’t think there is anything you can think of that somebody hasn’t already implemented in Java. You can’t say that about Object Pascal. Also if you don’t use every single class under the sun in your application, your applications end up being very small.

Note:
  Java still has 4K competions (remember those from the 90’s, but then using Assembler). If you don’t
  know what I’m talking about, it is competitions where the applications or demos must be smaller
  than 4KB in size. It is incredible how much functionality they can achieve with a 4KB java executable.
  You can’t do that with Object Pascal. ;)


Quote
I am a Linux guy, and I would actually reach for .NET before reaching for Java.
Who actually writes Mono applications? I’ve never seen any job adverts for that either. As for a Mono application, I think in all my years I’ve only seen and used one Photo Manager application under Linux - many many years ago. Also you can’t target OSX with Mono or .NET, but you can with Java.

Title: Re: The future of Free Pascal
Post by: jacmoe on March 21, 2017, 05:36:54 pm
Strange, isn't it, that both .NET core and Mono has downloads for OSX? Did you actually check it out? ;)

Personally, I really prefer the syntax of C++ over the syntax of Java, and actually over C# as well.

It's probably great and all, but not really my cup of tea. To put it mildly.

Java is still really slow and hungry for resources.
That's the main reason why I don't use any Java based IDE.
Even VSCode, based on Typescript, is faster than Netbeans, Eclipse, ..
The only thing that comes really, really close to being excellent is everything that JetBrains does.  8)
Title: Re: The future of Free Pascal
Post by: Thaddy on March 21, 2017, 05:56:02 pm
Personally, I really prefer the syntax of C++ over the syntax of
That's the problem... WHICH C++ syntax.... There isn't any.... Apart from curly brackets it is pretty much free for all.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 21, 2017, 06:29:30 pm
Exactly!  :)
Title: Re: The future of Free Pascal
Post by: john horst on March 21, 2017, 08:57:08 pm
Java is verbose, OBJPAS is also verbose, mystery solved. Java has its issues.. try it on a non Intel platform without 32gb of ram.  FWIW, I had to open a mono app to sign-in to the forum "keepass2". I should get a bloated Java app, right. You sound like you are learning Java, praise it 10 years latter. ;) Do something other than running a few little apps....

Some things I believe could improve Free Pascal.

An SSL cert.
A playground.
A package manager. (go get) is very nice.
An updated website.
Nice documentation, more examples. Laz and Console apps.

What else does a programmer need?


Title: Re: The future of Free Pascal
Post by: jacmoe on March 21, 2017, 10:23:20 pm
Are you referring to me, or someone else?
I was introduced to Java 17 years ago. We didn't click, but I know how to program in it.
Delphi and later C++ did click, however.
.NET never clicked either.

Verbosity?
Yes. But the verbosity is not the same.
I can live with the verbosity of Object Pascal.
It has some benefits over C++, for some things. Like desktop applications.

My main gripe with both .NET and Java is that you are basically sitting on top of  a large runtime.
I don't want and I don't need that kind of overhead.
Title: Re: The future of Free Pascal
Post by: Graeme on March 21, 2017, 11:56:49 pm
Java is still really slow and hungry for resources.
Sorry, but you’ll have to be more specific than that! As far as I, and many others on the internet, believe - the “Java is slow” in this day and age is just another myth that doesn’t want to go away. If it was that slow, then why to most financial institues, and trading companies run Java backends on their servers. To them every millisecond counts. 

Closer to home…. Like I mentioned earlier, have a look in the Graphics section of this form. I showed a 100% software rendering raycaster implemented near identical in C, Java and Object Pascal. The code is purposely badly written, because it was based on a Java 4KB competition, so small was a priority of well written code. Anyway, the graphics output is identical on all, but the Java version runs circles around the other two. On my system Java was hitting 30+ frames per second, C was in the mid to high 20’s, and no matter how many optimazations was applied, the Object Pascal version (compiled with FPC of course) as struggling at around 4-6 frames per second.

Eclipse IDE runs really fast here. No slower than Lazarus IDE. The same goes for other Java applications I run. jEdit for example loaded and syntax highlighted a huge 20MB source file much faster than Lazarus IDE could.

I can add that you do get good and bad applications, and one can always find examples of slow (and badly written applications), be that native executables, .NET based or Java based. But do yourself a favour, and do some new internet searches about Java executable performance. Java today is NOT the Java from 1996.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 22, 2017, 12:11:55 am
For Christ sakes, dude: what the gobbles do you think?
Yes, I have run Eclipse, Netbeans, etc. on my machine, right here, right now.
And they are definitely slower (and hungrier) than IDEs programmed in C/C++.
Yes, they are faster than they were 10 years ago. But they are still slower.
That's a fact.
And they also eats more RAM.
Sublime, VSCode, QtCreator, KDevelop, Emacs : all faster and speedier than anything powered by Java.
I have 8GB of RAM, and I don't intend to fill that up running an IDE.
The Java runtime needs to be run, that's a fact.
And native programs (not running Java) does not need to run it to run themselves. That's also a fact.
Title: Re: The future of Free Pascal
Post by: JD on March 22, 2017, 12:16:19 am

My issue with Java for years has been memory consumption. But these days I made peace with that. What modern PC doesn’t come standard with 8GB or RAM anyways? My desktop system has 32GB RAM and my laptop has 16GB RAM.

My laptop has 4gb

i have huge issues running firefox, java ide and javac.

everyrthing freezes

Same as mine. Since I routinely have about 15+ tabs open of Firefox, I never run Eclipse IDE and Firefox at the same time because 2GB of memory gets eaten fast. In addition, I have some background processes/Firefox plugins running to free memory so my system does not come to a halt. Java IDEs are resource hungry. There is no getting around it.
Title: Re: The future of Free Pascal
Post by: john horst on March 22, 2017, 12:56:17 am
Java is still really slow and hungry for resources.
Sorry, but you’ll have to be more specific than that! As far as I, and many others on the internet, believe - the “Java is slow” in this day and age is just another myth that doesn’t want to go away. If it was that slow, then why to most financial institues, and trading companies run Java backends on their servers. To them every millisecond counts. 

Closer to home…. Like I mentioned earlier, have a look in the Graphics section of this form. I showed a 100% software rendering raycaster implemented near identical in C, Java and Object Pascal. The code is purposely badly written, because it was based on a Java 4KB competition, so small was a priority of well written code. Anyway, the graphics output is identical on all, but the Java version runs circles around the other two. On my system Java was hitting 30+ frames per second, C was in the mid to high 20’s, and no matter how many optimazations was applied, the Object Pascal version (compiled with FPC of course) as struggling at around 4-6 frames per second.

Eclipse IDE runs really fast here. No slower than Lazarus IDE. The same goes for other Java applications I run. jEdit for example loaded and syntax highlighted a huge 20MB source file much faster than Lazarus IDE could.

I can add that you do get good and bad applications, and one can always find examples of slow (and badly written applications), be that native executables, .NET based or Java based. But do yourself a favour, and do some new internet searches about Java executable performance. Java today is NOT the Java from 1996.

All of the important / performance gains in Java are written in c/c++. You keep naming single use cases of who gives a .... I/O I/O I/O this will be your problem 99.9999999% time regardless, be it Java, C, Pascal or Go. Go and Java can be slow under certain condition on a hammered server during garbage collection. OMG C is faster...

The day I hear someone say lets rewrite this C in Java, it's faster, is the day I will love Java.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 22, 2017, 02:00:58 am
Not all applications are IO bound. Just want to mention that. ;D
IDEs are process bound more than IO bound, so that's actually one instance where you can really feel the difference between Java/Python/Node.js and native languages like C/C++/Rust/Pascal.
Title: Re: The future of Free Pascal
Post by: john horst on March 22, 2017, 04:33:53 am
Not all applications are IO bound. Just want to mention that. ;D
IDEs are process bound more than IO bound, so that's actually one instance where you can really feel the difference between Java/Python/Node.js and native languages like C/C++/Rust/Pascal.

Without a doubt. You are 100% correct. Lazarus is the only IDE I will use from time to time. I do all my work in vim, including Pascal. If I need a GUI app I will open Lazarus. I value battery life and being able to do 8 hours of work on my laptop vs being chained to a power source. I run low ram, slow cpu, 1 drive, crap video card, 99% cli apps, and firefox to achieve that. I would have to wait 15 mins for Eclipse to open, Lazarus opens instantly. The other dude just can't understand, we are in a time, we understand throwing more resources at it was a bad idea. Sure eclipse runs great on 32GB of ram, his system is not, avg,  commodity hardware. 
Title: Re: The future of Free Pascal
Post by: eMko on March 22, 2017, 07:12:56 am
DotNet got many things right (like mandatory JIT, generics, nullable types and autoboxing) that a sleeping Java fixed only in 1.5 and after. It's interoperability with native code is better/easier too. (pinvoke vs jni)

(disclaimer I abandoned these kinds of languages in 2005, might have changed since)

Luckily for me (Java & C# programmer) it has changed on the Java side.

.Net has always had 2 forms of calling a native code:
1) through C++/CLI (redesign of Managed C++) - all the hard work is done on the side of the library (C++), you just call .Net classes which it exposes. So you have to wrap the library in your C++ code.

2) through P/Invoke - all the work is done on the C# side, you just call a C library (or library with C interface, doesn't work for C++ classes) and marshall the data. Feels like calling a C library from FreePascal.

Java has also two:
1) JNI - similar to C++/CLI, just with plain C++, not with language extensions. Therefore the JNI libraries can be built by any compiler you want.

2) JNA (Java Native Access, since 2007) - similar to P/Invoke.

Many languages has these two forms, including Python (Python C modules vs ctypes). The 1st is usually faster and more efficient, the 2nd is easier and safer. I'd choose the 2nd any single day unless I'd run into problems. For the past 10 years, I had to use C++/CLI over P/Invoke only once in my daily job.
Title: Re: The future of Free Pascal
Post by: eMko on March 22, 2017, 07:33:24 am
Java is still really slow and hungry for resources.
That's the main reason why I don't use any Java based IDE.
Even VSCode, based on Typescript, is faster than Netbeans, Eclipse, ..
The only thing that comes really, really close to being excellent is everything that JetBrains does.  8)

You can't compare VSCode with NB/Eclipse. The former has very limited features compared to the later ones, it's simpler and its architecture is created with having Node.js, Chromium and Google V8 in mind with all their limitations.
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2017, 10:44:20 am
Java IDEs are resource hungry. There is no getting around it.
And "native non Java based" web browsers (Chrome, Chromium, Opera and Firefox) all are *very* resource hungry too! So there you go, it's not just a Java problem.

Have you ever monitored Lazarus IDE resource usage after you have used it for about an hour? It hogs up an awful lot of RAM too. At least Eclipse and IntelliJ IDEA do about 20x more code analysis and other functionality etc while running - compared to Lazarus IDE. So it makes sense the former two IDE's use lots of RAM.

In my experience, RAM is dirt cheap, so get as much of it as your system can handle. If you starve your system of RAM, any application is going to perform badly - no matter what SSD hard drive or CPU you have. Maybe the reason why my Java applications (yes, even Eclipse) runs at native application speed, is because I have enough resources available in my system (especially RAM, which I know every application, OS, desktop environment loves).

I also choose my environment wisely. FreeBSD seems to perform better than Linux or Windows in my experience. The GNOME/MATE desktop environment hogs 2GB of RAM easily, hence I run JWM window manager instead which only uses 8MB of RAM. I don't need the extra bells and whistles, and I'd rather that other real applications have that extra RAM.

Anyway, we are drifting off-topic, so I'll stop here.
Title: Re: The future of Free Pascal
Post by: marcov on March 22, 2017, 10:46:52 am
DotNet got many things right (like mandatory JIT, generics, nullable types and autoboxing) that a sleeping Java fixed only in 1.5 and after. It's interoperability with native code is better/easier too. (pinvoke vs jni)

(disclaimer I abandoned these kinds of languages in 2005, might have changed since)

Luckily for me (Java & C# programmer) it has changed on the Java side.

Thanks for the info. But the point was a bit that the innovation there came from the .NET/C# side, not from Java, same with e.g. Linq and support of multiple languages by the VM. Java only caught up.

P.s. I abandonned Java and C# because I changed jobs into a more embedded position where they were not relevant.
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2017, 10:53:03 am
Quote
I would have to wait 15 mins for Eclipse to open
I just tested this on my system. I did a reboot to make sure everything was out of memory. Then started both IDE's for the first time after the reboot. Lazarus IDE started in 4 seconds. Eclipse IDE started in 5 seconds. So based on starting time I'd call them pretty even. But if you have to take into account that Eclipse has to fire up the JVM, and that Eclipse has a ton more features and code analysis, I'd say Lazarus (the "native" app) looses badly.

...his system is not, avg,  commodity hardware.
In all the companies I've worked for over the last 10 years, I can't remember seeing any developers system (laptop or desktop) with less than 8GB of RAM. So if I used 8GB of RAM 10 years ago, using 32GB now is definitely not a far stretch. Hell, even using 16GB of RAM now should be pretty good. I chose 32GB because I also run about 2-4 VM's concurrently on my system for testing purposes.
Title: Re: The future of Free Pascal
Post by: JD on March 22, 2017, 11:40:34 am
Java IDEs are resource hungry. There is no getting around it.
And "native non Java based" web browsers (Chrome, Chromium, Opera and Firefox) all are *very* resource hungry too! So there you go, it's not just a Java problem.

Have you ever monitored Lazarus IDE resource usage after you have used it for about an hour? It hogs up an awful lot of RAM too. At least Eclipse and IntelliJ IDEA do about 20x more code analysis and other functionality etc while running - compared to Lazarus IDE. So it makes sense the former two IDE's use lots of RAM.

In my experience, RAM is dirt cheap, so get as much of it as your system can handle. If you starve your system of RAM, any application is going to perform badly - no matter what SSD hard drive or CPU you have. Maybe the reason why my Java applications (yes, even Eclipse) runs at native application speed, is because I have enough resources available in my system (especially RAM, which I know every application, OS, desktop environment loves).

That is very true. But to be honest I never really monitored the Lazarus IDE resource usage. So I didn't know it could use up a lot of memory. I just instinctively monitor Java & browser memory usage because of past experiences. Working with little RAM on my laptop forces me to try to code smartly. Anyway NUFF SAID!  :D
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2017, 12:08:31 pm
But to be honest I never really monitored the Lazarus IDE resource usage.
Maybe its time you start. ;)  I've been using Lazarus here for just under a hour now, and it's already up to 500MB of RAM usage. It normally sits around the 850MB mark with my average size projects. I've also seen it over the 1GB RAM mark in the past (all day usage and with many files open).

Quote
Working with little RAM on my laptop forces me to try to code smartly.
In that case, if you run Linux then switch to JWM window manager and code using MSEide (even for LCL based applications). Both use magnitudes less memory than a GNOME/MATE/KDE environment running Lazarus IDE.
Title: Re: The future of Free Pascal
Post by: Handoko on March 22, 2017, 12:09:19 pm
Working with little RAM on my laptop forces me to try to code smartly.

I recommend you to upgrade your laptop's memory. I work as a computer technician, I know that memory is very affordable now. If you're not willing to spend much money, buy the used one. It's less than $10 here for 2 GB and as good as new. All programmers can code but just a few can code smartly.

In all the companies I've worked for over the last 10 years, I can't remember seeing any developers system (laptop or desktop) with less than 8GB of RAM. So if I used 8GB of RAM 10 years ago, using 32GB now is definitely not a far stretch. Hell, even using 16GB of RAM now should be pretty good. I chose 32GB because I also run about 2-4 VM's concurrently on my system for testing purposes.

Here in my country is different, most computers I handle have 2 GB of RAM. My own computer has 6 GB. It can but I hate running VM, it slows my Core 2 Quad processor a lot. But I agree, memory is cheap, $10 memory upgrade is worth.
Title: Re: The future of Free Pascal
Post by: JD on March 22, 2017, 12:14:12 pm
Working with little RAM on my laptop forces me to try to code smartly.

I recommend you to upgrade your laptop's memory. I work as a computer technician, I know that memory is very affordable now. If you're not willing to spend much money, buy the used one. It's less than $10 here for 2 GB and as good as new. All programmers can code but just a few can code smartly.

I have to get a new laptop. This only reason why I haven't gotten one yet is Windows 10. I'm not a fan at all.
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2017, 12:23:07 pm
If I remember correctly, if you don't use Windows (ie: don't accept the user license agreement), they can't force you to use Windows, and you are entitled for a refund (the OEM prices of Windows). Then simply install any other OS you want.

DELL also sells laptops with Linux preinstalled.  But yeah, I hate the fact that consumers are forced to use Windows, and not give you much choice at the time of sale.

Alternatively, if you know somebody in PC wholesale, or in a company that is registered as a wholesaler, then you could ask them a favour and purchase through them - which means you can normally buy PC's and laptops without Windows preinstalled.

I still can't believe in this day and age that consumers don't have the right to choose.

ps:
   Nobody (except Microsoft) likes Windows 10. ;)
Title: Re: The future of Free Pascal
Post by: Handoko on March 22, 2017, 12:33:15 pm
ps:
   No body (except Microsoft) likes Windows 10. ;)

One of my client, asked me to downgrade her Windows from 10 to 7. Her company's computers use licensed Win7. Because of the free upgrade to Win10 offer, she did it. But not happy, she said Win10 is confusing.
Title: Re: The future of Free Pascal
Post by: eMko on March 22, 2017, 01:36:34 pm
   No body (except Microsoft) likes Windows 10. ;)

OK, I'll change my name to 'No body'.  O:-)

There are some changes in Win10 making it a better system (technically). There are two main problems however:
1) The appearance - Win7 looked better.
2) There are some changes in the UI and users who uses computers only as a productivity tool don't like such changes.

Win8 was a piece of you-know-what from the UI point of view and Win10 used to have its quirks esp. at the start. Sometimes you even have problem older hardware (it e.g. doesn't allow unsigned drivers etc.). But from the technical point of view, it's a better system. Users just don't see the changes in the internals.
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2017, 01:52:15 pm
But not happy, she said Win10 is confusing.
Not just confusing... the games Microsoft are playing to try and get (or force) people to upgrade are ridiculous. Auto upgrading overnight, whole system logging (keyboard logging, apps used, hardware used, forced apps store usage etc) and now the latest bulls**t - restricting updates for older versions with fake "warning" messages.

  https://www.youtube.com/watch?v=u5mFI9spp10 (https://www.youtube.com/watch?v=u5mFI9spp10)

Apple is just as bad - purposely breaking things so only their OS works with hardware. What an evil company! eg: Their external USB SuperDrive (CD-ROM/DVD). They purposely broke the hardware USB-to-IDE interface (which is standardised for a reason) in the device, so only OSX drivers work with it. Luckily some hacker figured out a simple 8 byte sequence sent to the device before usage will wake it up - then only does it act normally. It's a pretty device - you would think Apple would love to sell more (no matter the OS used) and see them on more desks, but no!   %)

Neither Apple or Microsoft will ever see a penny of mine again. Long live Linux, FreeBSD and anything Open Source.
Title: Re: The future of Free Pascal
Post by: Zoran on March 22, 2017, 03:46:04 pm
ps:
   Nobody (except Microsoft) likes Windows 10. ;)

If 10 came after 7, I would agree with you...
But after having seen Windows 8... At least I know things can be much worse!
Title: Re: The future of Free Pascal
Post by: john horst on March 22, 2017, 04:48:07 pm
Quote
I would have to wait 15 mins for Eclipse to open
I just tested this on my system. I did a reboot to make sure everything was out of memory. Then started both IDE's for the first time after the reboot. Lazarus IDE started in 4 seconds. Eclipse IDE started in 5 seconds. So based on starting time I'd call them pretty even. But if you have to take into account that Eclipse has to fire up the JVM, and that Eclipse has a ton more features and code analysis, I'd say Lazarus (the "native" app) looses badly.

...his system is not, avg,  commodity hardware.
In all the companies I've worked for over the last 10 years, I can't remember seeing any developers system (laptop or desktop) with less than 8GB of RAM. So if I used 8GB of RAM 10 years ago, using 32GB now is definitely not a far stretch. Hell, even using 16GB of RAM now should be pretty good. I chose 32GB because I also run about 2-4 VM's concurrently on my system for testing purposes.

Maybe if you throw 64gb in that bad ride you can get Laz to open faster. I call bullshit on on everything you said about where you worked in 10 years.. but whatever.

Me, I will stick with my 4gb, and mobile Pentium. I can open and close in half the time and still use a mouse doing it. I hate the mouse....

Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=x86_64-linux-gtk2 New=x86_64-linux-gtk2 FPC=True LCL=False
LAZARUS END - cleaning up ...
Hint: (lazarus) [TMainIDE.Destroy] B  -> inherited Destroy... TMainIDE
Hint: (lazarus) [TMainIDE.Destroy] END

real    0m2.464s
user    0m1.360s
sys     0m0.140s
john@oddio:~$ uname -a
Linux oddio 4.4.0-66-generic #87-Ubuntu SMP Fri Mar 3 15:29:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
john@oddio:~$

I also dont need 2000 VM's our servers are  all Ubuntu too.
Title: Re: The future of Free Pascal
Post by: Graeme on March 22, 2017, 04:57:49 pm
I call bullshit on on everything you said about where you worked in 10 years.. but whatever.
I hear little violins playing in the background now.   :'(

Quote
I also dont need 2000 VM's our servers are  all Ubuntu too.
As much as I would like everybody to run FreeBSD or Linux, I develop and test for multiple operating systems (as per my clients needs), and while contracting, each client gets its own VM to segregate the work.
Title: Re: The future of Free Pascal
Post by: john horst on March 22, 2017, 06:15:51 pm
I call bullshit on on everything you said about where you worked in 10 years.. but whatever.
I hear little violins playing in the background now.   :'(

Quote
I also dont need 2000 VM's our servers are  all Ubuntu too.
As much as I would like everybody to run FreeBSD or Linux, I develop and test for multiple operating systems (as per my clients needs), and while contracting, each client gets its own VM to segregate the work.

If you are trying to insinuate jealousy... lol. I'm less than 40, CTO of the company. Access or availability to hardware is not something I lack, nor has it ever been in the last 20 years. I have done OpSec and Programming in my day, I have seen many a system. 10 years ago the guys at Valve were lucky to have 8GB of ram.

Unless you were Science/Academics/Government in the US, 10 years ago 8GB was a lot. So yes I think that statement is BS, your average programmer at most companies s did not have it like that 10 years ago.  I like to see things for how they are and not the way I would like them to be. In conclusion maybe you did have access but most did not, especially outside of the US.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 22, 2017, 06:24:11 pm
Just my 2 cents:
10 years ago 8 or even 16 GB was common for a developer in the Netherlands.. Not Holland, Michigan - Not that you needed it...Often..
Two or more screens are more helpful and, yes, that was also common 10 years ago.

Note that 10 years ago nobody could beat the gaming PC my stepson had....That was even more over-specced. The morale is that in the western world in general serious companies provide their employee with serious hardware. Even then it was cheap. And this is still the case.
Title: Re: The future of Free Pascal
Post by: marcov on March 22, 2017, 06:38:35 pm
If you had a very serious business case as developer, I think you could get 8, or, more rarely 16GB in 2007, specially if you worked in a larger company.

But common, nonsense.  Even less so if your primary machine is a laptop, Hell, I had a 4GB machine till last summer.
Title: Re: The future of Free Pascal
Post by: Thaddy on March 22, 2017, 06:44:04 pm
Yes, laptop.
Title: Re: The future of Free Pascal
Post by: jacmoe on March 22, 2017, 06:52:43 pm
So, what you guys are saying: just throw more RAM/CPU at it, and all is well.
I suppose that's one way of dealing with it.

Just keep in mind that for the majority of the world - read: non-white, non-rich regions - there isn't an abundance of RAM/CPU/GB.
Title: Re: The future of Free Pascal
Post by: vfclists on March 22, 2017, 07:55:39 pm
I can totally understand were Graham is coming from. I must absolutely have 16Gb  on  my next laptop and 32Gb on  my desktop and they both must be using SSDs, i7 and preferably dual CPU E3/E5s for the deskop. If I set it to  anything less I will be wasting my time watching the hourglass.

Having to open browsers to look up information kills performance more than anything. If you have all the information in your at your fingertips and don't have to look up anything online that is fine. Lazarus will work fine on 2Gb. Open your browser have a few VMs running and everything will crawl to a halt. Try working across different technologies and OSs simultaneously and you will  need those. Visual Studio here, Eclipse there, Android Studio there and you are in for a rough time.

When you recollect having to pay 1000s for 386  and 486 systems with 16Mb of RAM, 32Gb systems in 2017 for 1000s are an absolute steal. The problem is development tools have become bloated when in the past they were tightly coded. C++ and Java and the culprits here.

https://www.xkcd.com/303/

Graeme you mentioned recently that you were compiling Firefox. How long did it take?

FWIW computer developers have become cheapskates who undervalue their work and/or allow their work to be undervalued. Other professionals pay far more for their tools and they don't even whinge. Even Uber drivers invest more in the cars and they don't gripe about costs so much.
Title: Re: The future of Free Pascal
Post by: vfclists on March 22, 2017, 08:03:39 pm
When it comes to performance I think Lazarus and FPC will not be fully optimized until all the modern/Delphi functionality bells and whistles that Maciej and co have been asking for have been added. It is hard for small teams to optimize software when they are adding new functionality to it.

It is only when things get stabilized that they can concentrate and squeezing every last drop out.

I am looking for automatic garbage collection but I don't see it  happening soon. Perhaps Maciej's ARC will help when it comes out, which will be nearer 2020 if not after.
Title: Re: The future of Free Pascal
Post by: marcov on March 22, 2017, 08:09:22 pm
When it comes to performance I think Lazarus and FPC will not be fully optimized until all the modern/Delphi functionality bells and whistles that Maciej and co have been asking for have been added. It is hard for small teams to optimize software when they are adding new functionality to it.

Those feature decrease performance not increase them.

Quote
It is only when things get stabilized that they can concentrate and squeezing every last drop out.
I am looking for automatic garbage collection but I don't see it  happening soon. Perhaps Maciej's ARC will help when it comes out, which will be nearer 2020 if not after.

GCt is the biggest performance sink of all.
Title: Re: The future of Free Pascal
Post by: john horst on March 22, 2017, 08:35:05 pm
FWIW computer developers have become cheapskates who undervalue their work and/or allow their work to be undervalued. Other professionals pay far more for their tools and they don't even whinge. Even Uber drivers invest more in the cars and they don't gripe about costs so much.

In the US programmers are generally in the top 1% when it comes to income. I don't see how you claim undervalued. Some of us have software that goes out around the world, to the average joe. If my constraints are 16/32 GB to write and ship this software, well I might as well close shop. I do understand the need to have the resources to run a VM. I personally have never seen a company have a group of developers all using multiple VMs. That would generally be a special use case, as was stated before.
Title: Re: The future of Free Pascal
Post by: Artlav on March 22, 2017, 08:56:23 pm
FWIW computer developers have become cheapskates who undervalue their work and/or allow their work to be undervalued.
Most programmers are in entry level and/or minimum income jobs due to the market oversaturation these days, and can't just spend a $1000 on a top-of-the-line computer simply for the sake of reducing compile time from 60 to 30 sec or something.

The ones who decide on developing big name tools, on the other hand, work for obscene money in places like the USA and have top-of-the-line hardware as a given, and so can't really understand what's the big deal is with making the requirements a little higher.

If I set it to  anything less I will be wasting my time watching the hourglass.
Case in point.
Time-money tradeoffs are a luxury.
Title: Re: The future of Free Pascal
Post by: RegNatarajan on March 23, 2017, 04:43:41 am
Well, Delphi is as good as dead. And, to be honest: good riddance.
I'm very late to this thread but I am interested why people feel Delphi is dead.  I was toying with buying it, even at its exorbitant price.

TIA
Reg

Title: Re: The future of Free Pascal
Post by: marcov on March 23, 2017, 06:59:52 am
Well, Delphi is as good as dead. And, to be honest: good riddance.
I'm very late to this thread but I am interested why people feel Delphi is dead.  I was toying with buying it, even at its exorbitant price.

Delphi isn't dead, but price hikes and periods of neglect have reduced its userbase. Delphi has been declared dead continously since before 2000, and survived a lot of the suggested alternative. If only because desktop apps are also continously being declared dead. If it aint a cloud running on IOT with VR glasses attached it doesn't exist nowadays.

It is a silly kind of remark that shows ignorance on behalf of the author.
Title: Re: The future of Free Pascal
Post by: mtanner on March 23, 2017, 07:49:42 am
programming languages never seem to die. Fortran is still around after all, if only as libraries of useful scientific routines. I remember that I got into Turbo-Pascal on very early PCs because it was the only reasonably-priced option for serious programming on PC's then. And Delphi gave a productive IDE and Windows access. But is has now got very expensive, especially when you need to pay for add-ons like TeeChart (if supplied version not enough). I still think it's a great language. C/C++ have rather tortured syntax, though obviously the dominant language. Python is fine, but again the non-free-form syntax can be limiting. And I want to stay away from C# because of it's dependency on MicroSoft environments ( and data marshaling can be a nightmare for interworking with other languages). Pascal is a great language for actually focussing of the task to be accomplished. And Lazarus now provides a path away from Windows, plus the very excellent TAGraph.
Title: Re: The future of Free Pascal
Post by: Groffy on March 23, 2017, 11:14:49 am
This thread is now almost going for a year, and without reading/remembering every single message I can't remember that I read something what suggests/leads into the future of this language. What do we mean when we are talking about the "future" of Free Pascal? Is it the further development of the language/compiler itsself? Is it the question whether we will have enough maintainer on volunteer base in the future? Is it the question whether the language itself will stay alive in form of a new young user generation which might be still in school or university right now? My generation who started on Z80 CP/M computers with Turbo Pascal might be out of profession within the next 10-15 years, in which timeframe we should think when we are talking about the "future"? The language "Object Pascal" will not die, but the user base is continious shrinking and there will be the day when it makes no sense anymore developing products like delphi (whoever will own it in the future) on a professional base. I'm pretty sure, that companies which are developing VCL products commercially already noticed the shrinking market years ago and its still going on year after year. 

In my opinion the future of Free Pascal is strongly connected to Lazarus and the ability to organize a structure around that package which signalizes that there will be a continious maintainance and development. Companies like TMS components gave a huge credit to the Lazarus project when they decided to enter the market for LCL products on a professional base. I just hope, that more companies from the classical VCL market will follow and trust Lazarus/Free Pascal.

I'm working with the Firebird database (moved with it to the .net environment 10years ago) for many years now, the users/developers founded the Firebird Foundation to bring the future development of this RDBMS into a kind of professional structures. Maybe thats a possible way also for Free Pascal/Lazarus(?). Lazarus will continue the legacy of TP/delphi one day. Nobody knows when that will happen, the project should be well prepared.

With best regards
Title: Re: The future of Free Pascal
Post by: Thaddy on March 23, 2017, 12:29:53 pm
The future always means future. So it doesn't matter how long the thread runs. If a goal is achieved, there's a new future feature..., etc.
Title: Re: The future of Free Pascal
Post by: Groffy on March 23, 2017, 12:50:47 pm
The future always means future. So it doesn't matter how long the thread runs. If a goal is achieved, there's a new future feature..., etc.

Thank you for your philosophical point of view. Can you propose goals?
Title: Re: The future of Free Pascal
Post by: Graeme on March 23, 2017, 01:02:34 pm
Just my 2 cents:
10 years ago 8 or even 16 GB was common for a developer in the Netherlands..
Maybe the USA is more backwards than the rest of the world thought. 10 Years ago I was based in a 3rd world country - South Africa. I worked in Science & Academics for a 30+ employees company. Developer systems were all desktops (laptops were simply not powerful enough) and RAM was a mix between 4GB and 8GB - *never* lower that 4GB. And yes, 2 monitors per PC was common too.

To put this in context, my personal laptop back in 2007 was a 15.6" DELL Inspiron (weighs a ton) with a screen resolution of 1920x1200 and 4GB RAM and some 3Ghz CPU and a 128MB Radeon video card. I still have that laptop today (fully working, but not used any more). Pity laptop designs went backwards since then, now sporting shitty 1366x768 resolutions as common place. WTF! And the consumer seems happy with that?? WTFx2!

It seems some people here forget that developers are not the standard end-user, so standard end-user equipment (like laptops with limited upgradability, or stock off-the-shelf PC's) simply doesn't cut it.

Maybe some here should read some of the "Joel on Software" blogs. If you don't have the time to read all the excellent articles, read this one and take a particular note of Item 9.

    https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ (https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/)

I can't agree more with that point.
Title: Re: The future of Free Pascal
Post by: Graeme on March 23, 2017, 01:14:09 pm
Graeme you mentioned recently that you were compiling Firefox. How long did it take?
7 minutes if I remember correctly - which I believe was faster than usual. I went and made a cup of coffee while it was churning away. :) Compiling LibreOffice takes magnitudes longer (35+ minutes)! Imagine the pain in debugging that.

Quote
FWIW computer developers have become cheapskates
Definitely. Every second I wait for a compilation is time wasted and costs somebody money.
Title: Re: The future of Free Pascal
Post by: Graeme on March 23, 2017, 01:19:40 pm
If my constraints are 16/32 GB to write and ship this software, well I might as well close shop.
As a CTO you seem to have a major lack of understanding when it comes to software development. A development machine does NOT equate to a end-user system. Developers don't have a normal workflow that end-users have. Developing with a high resource system doesn't mean your application requires those high resources too.

Quote
I personally have never seen a company have a group of developers all using multiple VMs.
Clearly you have been out of the programming scene for some time. VM's are quite common place now in development environments and in QA testing.
Title: Re: The future of Free Pascal
Post by: marcov on March 23, 2017, 01:36:54 pm
To put this in context, my personal laptop back in 2007 was a 15.6" DELL Inspiron (weighs a ton) with a screen resolution of 1920x1200 and 4GB RAM and some 3Ghz CPU and a 128MB Radeon video card. I still have that laptop today (fully working, but not used any more). Pity laptop designs went backwards since then, now sporting shitty 1366x768 resolutions as common place. WTF! And the consumer seems happy with that?? WTFx2!

Weird. I got an inspiron from a more expensive series (the Inspirons already upgraded to Core 2) at roughly the same time, and that was not even an option. It was the first time I didn't get a Latitude, so I maxed out the inspiron 6400 a bit. But that was still conroe processors (so 2.2GHz was a lot), 2GB Ram, 1280x1024 and a 128MB GF7300.  The laptop chipset could not do more than 4GB, and Dell didn't even support that configuration. (rightly so even, since when I later upgraded it anyway, instability started)

Later 2007 might have given you a 2nd generation core2 (kentsfield), but afaik the laptop processors there never reached 3.0 GHz. I think 2.66 was about tops. (https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#.22Merom.22.2C_.22Merom-2M.22_.28standard-voltage.2C_65_nm.29)

So either you have something really weird and exotic, or you got your dates wrong.
Title: Re: The future of Free Pascal
Post by: BeniBela on March 23, 2017, 01:43:53 pm
Weird. I got an inspiron from a more expensive series (the Inspirons already upgraded to Core 2) at roughly the same time, and that was not even an option. It was the first time I didn't get a Latitude, so I maxed out the inspiron 6400 a bit. But that was still conroe processors (so 2.2GHz was a lot), 2GB Ram, 1280x1024 and a 128MB GF7300.  The laptop chipset could not do more than 4GB, and Dell didn't even support that configuration. (rightly so even, since when I later upgraded it anyway, instability started)

I for one got a Latitude in 2011.   2.4  GHz, 4 GB RAM,  1440x900 and afair that model was all maxed
Title: Re: The future of Free Pascal
Post by: Graeme on March 24, 2017, 04:20:52 pm
Later 2007 might have given you a 2nd generation core2 (kentsfield), but afaik the laptop processors there never reached 3.0 GHz.
So either you have something really weird and exotic, or you got your dates wrong.
It was a DELL Inspiron 9100. This link shows the specs... 3.2Ghz.
   http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100 (http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100)

and here it shows that there was even a 3.4Ghz option.
  http://www.notebookreview.com/news/dell-releases-new-inspiron-9100-pics/ (http://www.notebookreview.com/news/dell-releases-new-inspiron-9100-pics/)

I ordered it with 2GB RAM, then later upgraded it myself to 4GB - supported or not the RAM upgrade worked. I spoke to my wife, and she believes I bought it somewhere around 2003/2004.

Either way, it was the best laptop I have ever owned!

On a side note:
  I was brilliantly designed too. At the time I did contracting work and commuted on my motorcycle. Every
  two weeks or so the graphics would go buggy. I eventually figure out that it was the graphics module that
  shook loose because of the bumpy motorcycle trips. I then travelled with a single screwdriver to strip, reseat
  and put back together for the next two weeks. Yup, you only needed a single screwdriver to remove every
   single component from that laptop. Brilliant design! Compare that to days shit Apple Macbook Pro's that
   can't even be opened or serviced with normal tools, and they don't even have a Kensington lock!! So how
   are you supposed to secure your laptop at your work place, coffee shop, library etc.

Title: Re: The future of Free Pascal
Post by: john horst on March 24, 2017, 04:54:50 pm
If my constraints are 16/32 GB to write and ship this software, well I might as well close shop.
As a CTO you seem to have a major lack of understanding when it comes to software development. A development machine does NOT equate to a end-user system. Developers don't have a normal workflow that end-users have. Developing with a high resource system doesn't mean your application requires those high resources too.

Quote
I personally have never seen a company have a group of developers all using multiple VMs.
Clearly you have been out of the programming scene for some time. VM's are quite common place now in development environments and in QA testing.

I understand perfectly well that the end-user does not need that much ram, nor did I state that. If my developers need 32gb to write and ship software im done.

I don't do "scenes". I do real life, get shit done kind of work. Iv'e written at least half a million lines of Go in the last year and still do my JOB. Nice try though.
Title: Re: The future of Free Pascal
Post by: john horst on March 24, 2017, 06:14:07 pm
To put this in context, my personal laptop back in 2007 was a 15.6" DELL Inspiron (weighs a ton) with a screen resolution of 1920x1200 and 4GB RAM and some 3Ghz CPU and a 128MB Radeon video card. I still have that laptop today (fully working, but not used any more). Pity laptop designs went backwards since then, now sporting shitty 1366x768 resolutions as common place. WTF! And the consumer seems happy with that?? WTFx2!

Weird. I got an inspiron from a more expensive series (the Inspirons already upgraded to Core 2) at roughly the same time, and that was not even an option. It was the first time I didn't get a Latitude, so I maxed out the inspiron 6400 a bit. But that was still conroe processors (so 2.2GHz was a lot), 2GB Ram, 1280x1024 and a 128MB GF7300.  The laptop chipset could not do more than 4GB, and Dell didn't even support that configuration. (rightly so even, since when I later upgraded it anyway, instability started)

Later 2007 might have given you a 2nd generation core2 (kentsfield), but afaik the laptop processors there never reached 3.0 GHz. I think 2.66 was about tops. (https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#.22Merom.22.2C_.22Merom-2M.22_.28standard-voltage.2C_65_nm.29)

So either you have something really weird and exotic, or you got your dates wrong.

He does not want to admit exotic for the era. In 2004 I had a 3GHZ/ HT Laptop. It was exotic for the era, as the commenter thought that rez was high at the time. http://sfuse.deviantart.com/art/blender-2-34-10575567

It was not common hardware, but possible.
Title: Re: The future of Free Pascal
Post by: marcov on March 24, 2017, 06:28:42 pm
It was a DELL Inspiron 9100. This link shows the specs... 3.2Ghz.
   http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100 (http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100)

Oh dear. P4. Most people rather forget that period :-)
Title: Re: The future of Free Pascal
Post by: Kays on March 25, 2017, 07:40:28 pm
[…]VM's are quite common place now in development environments […]
Containers. Containers are cool now.  ;)

It was exotic for the era, as the commenter thought that rez was high at the time. [… deviantart link …]
Yeah, it still is. I like my laptops small and mobile.
Title: Re: The future of Free Pascal
Post by: Akira1364 on March 26, 2017, 01:30:03 am
It was a DELL Inspiron 9100. This link shows the specs... 3.2Ghz.
   http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100 (http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100)

Oh dear. P4. Most people rather forget that period :-)

Yeah... "3.2 ghz". Extra emphasis on the quotation marks!  ;)

I can't imagine how hot that thing must have gotten after running for a few hours. Also, why would you even bother upgrading the RAM on a machine that still has a terrible, terrible GPU like a Mobile Radeon 9700 (with a whopping 128 MB of VRAM!)
Title: Re: The future of Free Pascal
Post by: Graeme on March 27, 2017, 05:50:10 pm
It was exotic for the era, as the commenter thought that rez was high at the time. [… deviantart link …]
Yeah, it still is. I like my laptops small and mobile.
Maybe now it is considered "exotic", simply because all laptop manufacturers started producing shit laptops after 2004. Things are supposed to improve, not take a hell of a step backwards!

At the time I definitely didn't consider that laptop exotic. It was simply a choice on DELL's website (like many others), and knowing full well that laptops are always overpriced and has very limited upgradability, I order the best I could for the money I had (it was going to replace an ageing desktop PC). I did this so it could last as long as it could. I used that laptop for 8 years, so I think it did pretty darn well.
Title: Re: The future of Free Pascal
Post by: Graeme on March 27, 2017, 06:06:40 pm
I can't imagine how hot that thing must have gotten after running for a few hours.
Running hot was never a problem. If I remember correct, it had something like 4 fans and a massive heat sink. What was an issue was the weight and battery live - 2 hours 30 minutes max on a fully charged battery. Luckily I always worked at a desk with a power point. Also, you could never work on the laptop on your lap - your legs would go numb in a few minutes from the weight. :)

Quote
Also, why would you even bother upgrading the RAM on a machine that still has a terrible, terrible GPU like a Mobile Radeon 9700 (with a whopping 128 MB of VRAM!)
I don't fully understand. I played loads of times at game LAN parties (Counter Strike, Half-Life, Quake etc). It was awesome. Everybody lugging around pimped out desktop PCs and massive 17 or 19 inch CRT monitors that took 30+ minutes to set up. And here I come with my awesome laptop in a single backpack. It turned lots of heads at the time. Oh, and the sound was fantastic too - even included a sub woofer built into the battery housing.

It also came standard with Windows XP. I downgraded it to Windows 2000 and ran modified desktop radeon 9700 drivers. The speed tests I did at the time outperformed ALL other DELL Inspiron 9100 ratings I could find.
Title: Re: The future of Free Pascal
Post by: Graeme on March 27, 2017, 06:13:10 pm
Oh dear. P4. Most people rather forget that period :-)
:)  At least I didn't get the Ghz rating or screen resolution wrong.  DELL also marketed in as a "desktop replacement laptop" - so its weight and short battery life was not too surprising.
Title: Re: The future of Free Pascal
Post by: Artlav on March 31, 2017, 09:42:17 pm
For example the Lazarus project itself has rather many source files but I can work with them smoothly using the IDE.
Sorry for the off-topic, but i ended up doing just that, and am curious what your workflow looks like?
Specifically, how do you quickly get to/switch to a particular arbitrary file in a project?
Title: Re: The future of Free Pascal
Post by: Ondrej Pokorny on April 07, 2017, 04:23:49 pm
For example the Lazarus project itself has rather many source files but I can work with them smoothly using the IDE.
Sorry for the off-topic, but i ended up doing just that, and am curious what your workflow looks like?
Specifically, how do you quickly get to/switch to a particular arbitrary file in a project?

I created the "Open Unit" command in Lazarus 1.7. If you execute it (e.g. with a key shortcut), you get a list of all available units. Then you type a few characters and you open the file you want.
Title: Re: The future of Free Pascal
Post by: JuhaManninen on April 07, 2017, 05:45:45 pm
Specifically, how do you quickly get to/switch to a particular arbitrary file in a project?
Sorry didn't notice this earlier.
See also my reply here about bookmarks etc.
 http://forum.lazarus-ide.org/index.php/topic,31971.msg241405.html#msg241405
Arbitrary file in project which is not open yet?
There is the Project Inspector and Project -> Units list. In big Lazarus project all files are not included in project explicitly. Sometimes I use the Open File button if I know the name of a file.
Most often however I use the Find in Files dialog. I am interested in some text inside a file. Usually I don't care about the file's name. When I find what I wanted, I put a bookmark there. Then I jump with Ctrl-Click and maybe put more bookmarks. I may move the interesting editor files next to each other. All together there can be like 50 or 100 files open in editor after searching and jumping but their names and locations are often not the main interest.

For example I recently did a big refactoring for AVLTree and related containers. I opened all those files for editing from Find in Files results window, except one file from FPC trunk sources using Open File button.

Also when haunting a certain bug, the biggest challenge is to find the right place. I often search for GUI strings or other keywords to get close to it.
Title: Re: The future of Free Pascal
Post by: hengky on June 01, 2017, 04:51:37 pm
Can free pascal porting to haxe ?
Title: Re: The future of Free Pascal
Post by: marcov on June 01, 2017, 05:01:00 pm
Can free pascal porting to haxe ?

If I search for Haxe, I only find some scripting language system. Did I find the wrong haxe, and is haxe some OS?
Title: Re: The future of Free Pascal
Post by: Scoops on June 01, 2017, 05:16:17 pm
Maybe its

https://haxe.org/ (https://haxe.org/)

the first thing google gave me
Title: Re: The future of Free Pascal
Post by: marcov on June 01, 2017, 06:21:46 pm
Maybe its

https://haxe.org/ (https://haxe.org/)

the first thing google gave me

That's what I also found, which is a programming system (compiler/library) with a non native (wxwidgets) GUI, not a target afaik.  So I don't really understand how FPC is supposed to be ported to it.
Title: Re: The future of Free Pascal
Post by: sky_khan on June 01, 2017, 06:32:41 pm
I guess either he/she meant a transcompiler to Haxe or compiling to haxe's own virtual machine target (neko). Neither of them are supported of course. There is no reason for this too, I think. Supporting all virtual machines on the world should not have been freepascal's goal.
Title: Re: The future of Free Pascal
Post by: hengky on June 21, 2017, 08:58:07 pm
About Haxe I think we can use library from other language , if we compile haxe to Java it mean we can use SWT, AWT, Java Bean etc, haxe to php we can use library from zend

so if we compile object pascal to haxe , we can use library from other language that support haxe
it will be pascal every where

haxe compile to native language , not like .net or jvm
Title: Re: The future of Free Pascal
Post by: marcov on June 21, 2017, 10:27:04 pm
About Haxe I think we can use library from other language , if we compile haxe to Java it mean we can use SWT, AWT, Java Bean etc, haxe to php we can use library from zend

so if we compile object pascal to haxe , we can use library from other language that support haxe
it will be pascal every where

haxe compile to native language , not like .net or jvm

FPC also, and has heaps of targets. Including Java. Maybe Haxe should compiler to FPC :_)
Title: Re: The future of Free Pascal
Post by: Thaddy on June 21, 2017, 10:34:46 pm
haxe compile to native language , not like .net or jvm

FPC also, and has heaps of targets. Including Java. Maybe Haxe should compiler to FPC :_)
And the jvm target is pretty good. And can be used to feed into a native code compiler for Java bytecode...
I started treating monkeys like monkeys some time ago. (Including myself  :D)
Title: Re: The future of Free Pascal
Post by: jc99 on June 22, 2017, 07:36:35 am
Speaking of transpilers, how is the progress in pas2js ? Last demo on "German Lazarustreffen" seems pretty promising, so I look forward to time it's released.
Title: Re: The future of Free Pascal
Post by: tr_escape on June 22, 2017, 08:59:43 am
I think (as I understand) he/she wants to say is it possible to use fpc like as haxe functions:

Code: Pascal  [Select][+][-]
  1. using StringTools;
  2.  
  3. class Test {
  4.         static public function main() {
  5.                 // uses static extension StringTools from the Haxe Standard Library
  6.                 var v = "adc".replace("d", "b");
  7.                 trace(v);
  8.         }
  9. }

For example:

Code: Pascal  [Select][+][-]
  1. function str_change:string;
  2. var
  3.   str : 'adc'.replace('d','b');
  4.   // or
  5.   str : String('adc'.replace('d','b'));
  6. begin
  7.   result := str;
  8. end;
  9.  

Title: Re: The future of Free Pascal
Post by: jc99 on June 22, 2017, 11:59:53 am
I think (as I understand) he/she wants to say is it possible to use fpc like as haxe functions:

Code: Haxe  [Select][+][-]
  1. using StringTools;
  2.  
  3. class Test {
  4.    static public function main() {
  5.       // uses static extension StringTools from the Haxe Standard Library
  6.       var v = "adc".replace("d", "b");
  7.       trace(v);
  8.    }
  9. }

For example:

Code: Pascal  [Select][+][-]
  1. function str_change:string;
  2. var
  3.   str : 'adc'.replace('d','b');
  4.   // or
  5.   str : String('adc'.replace('d','b'));
  6. begin
  7.   result := str;
  8. end;
  9.  

For example:

Code: Pascal  [Select][+][-]
  1. function str_change:string;
  2. var
  3.   str : 'adc'.replace('d','b'); // That is maybe difficult
  4.   // or
  5.   str : String('adc'.replace('d','b')); // Slightly better;
  6.   str : String = 'adc'.replace('d','b'); // can be done really easily;
  7. begin
  8.   result := str;
  9. end;
  10.  

I also would like to have initialized open array of String
Code: Pascal  [Select][+][-]
  1. const cText:array of string =
  2. ('Hello World',
  3.   '2. String',
  4. [...] ,
  5. 'Last String');
  6.  
Or even better:
Code: Pascal  [Select][+][-]
  1. const cText:array of string =({$I anytext.txt});
  2. {or}const cText: Tstrings.text ='{$I anytext.txt}';
  3.  
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 01:08:40 pm
I don't think anything that declares and initializes with non constant values will be added. It violates too much the spirit of pascal.

The functional/pipeline   xx.yy.zz  way of concatenating string is used in TStringbuilder and various other string libraries. It is not a language feature, but a library feature.

Personally  I abhor the style. I blame it on Turbo Vision traumas, which employed this style and was IMHO pretty much unreadable.
Title: Re: The future of Free Pascal
Post by: wp on June 22, 2017, 01:25:46 pm
For example:

Code: Pascal  [Select][+][-]
  1. function str_change:string;
  2. var
  3.   str : 'adc'.replace('d','b');
  4.   // or
  5.   str : String('adc'.replace('d','b'));
  6. begin
  7.   result := str;
  8. end;
  9.  
So, since 'adc' is a literal string and the 'd' is to be replaced by a 'b' then why not simply declare it directly?
Code: Pascal  [Select][+][-]
  1. var
  2.   str: String = 'abc';
Title: Re: The future of Free Pascal
Post by: jc99 on June 22, 2017, 03:21:41 pm
The functional/pipeline   xx.yy.zz  way of concatenating string is used in TStringbuilder and various other string libraries. It is not a language feature, but a library feature.

Personally  I abhor the style. I blame it on Turbo Vision traumas, which employed this style and was IMHO pretty much unreadable.
Personally I don't like this style too.
With One, maximum two functions in one line, it might be OK but some do it for Pages so at the end nobody knows the start. and they even call that an advantage ...
But the real trauma was the bracketed style I speak of new([..].init(new([..].init(new(... ))))))))...))))))); - Style, which is/was much worse.

The things I suggested don't violate the Constant Values only - Spirit.
Like all initialized values, the initialization (as long as it's about variable) can be seen as a hidden first assignment statment that is just moved up to the variable declaration.
What I mean:
Code: Pascal  [Select][+][-]
  1. Function XYZ:TValue;
  2.  
  3. var lVar:integer = 4 + 5;
  4.  
  5. begin
  6. [...]
Can without a los of functionality (or is internaly) replaced with
Code: Pascal  [Select][+][-]
  1. Function XYZ:TValue;
  2.  
  3. var lVar:integer;
  4.  
  5. begin
  6.   lVar := 4 + 5;
  7. [...]
So can all the other Statements prior mentioned(except for the TStrings-Variant). As long as every Parameter involved are Constants and (the Function only depend on these Parameters, (and have no Hidden Side-effects but even if they have the Coder has to know what he's doing then using these Functions ))
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 03:40:43 pm
So can all the other Statements prior mentioned(except for the TStrings-Variant). As long as every Parameter involved are Constants and (the Function only depend on these Parameters, (and have no Hidden Side-effects but even if they have the Coder has to know what he's doing then using these Functions ))

That's not how it works. Only builtins can be evaluated in constant expressions, not arbitrary functions (which can be called by the compiler without knowing how it works)

People that like Functional programming should IMHO use functional languages, and not try to convert imperative languages into functional ones.
Title: Re: The future of Free Pascal
Post by: ASerge on June 22, 2017, 04:49:24 pm
The difference is only in the place of initialization, the rest of the goodies are already realized in the library
Code: Pascal  [Select][+][-]
  1. {$APPTYPE CONSOLE}
  2. program Project1;
  3.  
  4. uses SysUtils;
  5.  
  6. function Test1: string;
  7. const
  8.   CStr = 'adc';
  9. begin
  10.   Result := CStr.Replace('d','b');
  11. end;
  12.  
  13. function Test2: string;
  14. const
  15.   CStr =
  16.     'Hello World'#0 +
  17.     '2. String'#0 +
  18.     'Last String';
  19. var
  20.   X: TStringArray;
  21. begin
  22.   X := CStr.Split(#0);
  23.   Result := X[High(X)];
  24. end;
  25.  
  26. begin
  27.   Writeln(Test1);
  28.   Writeln(Test2);
  29.   Readln;
  30. end.
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 04:58:49 pm
Complicated, just write (3.0.2+) :

Code: Pascal  [Select][+][-]
  1. {$mode delphi}
  2.  
  3. uses sysutils;
  4. function bla : string;
  5.  
  6. begin
  7.   result:='adc'.replace('d','b');
  8. end;
  9.  
  10. begin
  11.   writeln(bla);
  12. end.
  13.  

For a list of such functions see here (https://www.freepascal.org/docs-html/rtl/sysutils/tstringhelper.html). Note that some (like compare) have several overloads
Title: Re: The future of Free Pascal
Post by: ASerge on June 22, 2017, 05:09:36 pm
Complicated, just write (3.0.2+) :
[/code]
Only for demonstration purposes, with an attempt to preserve the original construction.
Also can be
Code: Pascal  [Select][+][-]
  1. function Test2: string;
  2. var
  3.   X: TStringArray;
  4. begin
  5.   X := ''.Join(#0, ['Hello World', '2. String', 'Last String']).Split(#0);
  6.   Result := X[High(X)];
  7. end;
Title: Re: The future of Free Pascal
Post by: hengky on June 22, 2017, 05:27:29 pm
I mean Like C# below

CS2HX converts your C# 4.0 code into haXe code. haXe is a multi-target language, so the resulting haXe code can be converted to many other languages.

This means CS2HX can be a:
- C# to ActionScript converter
- C# to JavaScript converter
- C# to Java converter
- C# to PHP converter
- C# to C++ converter
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 06:06:51 pm
I mean Like C# below

CS2HX converts your C# 4.0 code into haXe code. haXe is a multi-target language, so the resulting haXe code can be converted to many other languages.

This means CS2HX can be a:
- C# to ActionScript converter
- C# to JavaScript converter
- C# to Java converter
- C# to PHP converter
- C# to C++ converter

Actionscript is dead since flash is as good as dead, Javascript (pas2js) and Java jvm  are already supported or worked on.

Leaves PHP and C++. But then I rather have a direct translator pas2xxx then via yet another external tool. Nearly every converter limits the dialect, so two conversions doubly so.  a pas2haxe converter is too much work if it supports only trivial subsets and programs.

And subsets it always will be. Even C++ doesn't support enough to be an backend for the whole language. FPC/object pascal is massive.
Title: Re: The future of Free Pascal
Post by: Handoko on June 22, 2017, 06:18:43 pm
Pas2haxe may sound good, but if I can choose please put more efforts on pas2android.
Title: Re: The future of Free Pascal
Post by: Paul_ on June 22, 2017, 06:34:08 pm
Is there something like this for variable values?
Code: Pascal  [Select][+][-]
  1. TPoint = record
  2.   x, y  : Single;
  3.   color : TColor;
  4. end;
  5.  
  6. Var
  7.    Point : TPoint;

And assigning values in code:
Code: Pascal  [Select][+][-]
  1. Point( 100, 200, clWhite );

Instead of:
Code: Pascal  [Select][+][-]
  1. With Point do begin
  2.   x := 100;
  3.   y := 200;
  4.   Color := clWhite;
  5. end;

or making function SetPointValue( x, y : Single; Color : TColor) : TPoint;
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 06:41:17 pm
Is there something like this for variable values?
Code: Pascal  [Select][+][-]
  1. TPoint = record
  2.   x, y  : Single;
  3.   color : TColor;
  4. end;
  5.  

You can define a constant record of course, e.g.:

Code: Pascal  [Select][+][-]
  1. const mypoint : TMyPoint = (x:1;y:2;color:clwhite);

I used TMyPoint because TPoint is already predefined and used a lot.
Title: Re: The future of Free Pascal
Post by: bytebites on June 22, 2017, 07:41:15 pm
Code: Pascal  [Select][+][-]
  1. TMyPoint = record
  2.   x, y  : Single;
  3.   color : TColor;
  4.   Create(x,y:integer, color:TColor):TMyPoint;
  5. end;
  6.  
  7.  
  8.  TMyPoint.Create(x,y:integer, color:TColor):TMyPoint;
  9. begin
  10.   self.x:=x;
  11.   self.y:=y;
  12.   self.color:=color;
  13. end;
  14. Var
  15.    MyPoint : TMyPoint;
  16.  
  17. begin
  18.   MyPoint.Create(100, 200, clWhite);
Title: Re: The future of Free Pascal
Post by: Thaddy on June 22, 2017, 08:21:55 pm
Pas2haxe may sound good, but if I can choose please put more efforts on pas2android.
Huh? We have pas2Android: FPC compiles to Android-arm (and Android-Intel? never tried that).
Android is an OS, not a language.
And we have an extremely capable jvm target too.
Problem is that the toolchain is rather long and object pascal programmers are not used to that...
The programmers that I know to complain about the build environment for FPC-Android have the same problems with configuring and using, say, Eclipse.
Especially when it is packaging time or even make a release build.
In that sense tools like Delphi and Lazarus make you lazy.
Title: Re: The future of Free Pascal
Post by: Paul_ on June 22, 2017, 08:23:59 pm
Thanks for ideas. But constants are predefined and I can't compile bytebites code, It should be?
Code: Pascal  [Select][+][-]
  1. {$mode delphi}
  2. Type
  3.   TMyPoint = record
  4.     x, y  : Single;
  5.     color : TColor;
  6.     function Create(x,y:integer; color:TColor):TMyPoint;
  7.   end

I can declare function out of record, so I doesn't help much. The idea was in smaller and cleaner code.

And maybe define values in procedures or function in this style would be fine:
Code: Pascal  [Select][+][-]
  1. Type
  2. TMyPoint = record
  3.   x, y  : Single;
  4. end;
  5.  
  6. Procedure DrawText( Point : TMyPoint, Text : String );
  7. begin
  8.   // I will not use DrawText( x, y : Single; Text : String );
  9.   // Point is local "variable"
  10.   // some drawing code
  11. end;
  12.  
  13. begin
  14.   DrawText( (1, 2), 'Text 1');
  15.   DrawText( (3, 4), 'Text 2');
  16. end;

or:

Code: Pascal  [Select][+][-]
  1. begin
  2.   DrawText( TMyPoint(1, 2), 'Text 1');
  3.   DrawText( TMyPoint(3, 4), 'Text 2');
  4. end;
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 08:44:54 pm
But more unsafe, specially if your reorder or insert new fields. If we get some tuple feature I hope it is as in the constant definition case, that you have to name the fields.
Title: Re: The future of Free Pascal
Post by: jc99 on June 22, 2017, 08:51:47 pm
Code: Pascal  [Select][+][-]
  1. function Test2: string;
  2. var
  3.   X: TStringArray;
  4. begin
  5.   X := ''.Join(#0, ['Hello World', '2. String', 'Last String']).Split(#0);
  6.   Result := X[High(X)];
  7. end;
I Really like that one My Include-File already look's like
Code: Pascal  [Select][+][-]
  1. 'First line',
  2. 'Second Line',
  3. [... another 230 Lines]
  4. 'Last Line'
  5.  
I'd do it like
Code: Pascal  [Select][+][-]
  1. function Test2: TStringArray;
  2. var
  3.   X: string;
  4. begin
  5.   X.Join(#0, [{$I TextFile.txt}]);
  6.   Result := X.Split(#0);
  7. end;
That replace my
Code: Pascal  [Select][+][-]
  1. const st:array[0..232] of string =({$I TextFile.txt});
  2.  
Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!

@PaulG:
Solution: declare a Function:
Code: Pascal  [Select][+][-]
  1. function Mypoint(x,y:single):TMypoint;
  2. begin
  3.    result.x := x;
  4.    result.y := y;
  5. end;
  6.  
  7. // then This is valid
  8.  
  9.     begin
  10.       DrawText( MyPoint(1, 2), 'Text 1');
  11.       DrawText( MyPoint(3, 4), 'Text 2');
  12.     end;
  13.  

Title: Re: The future of Free Pascal
Post by: jc99 on June 22, 2017, 09:04:33 pm
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 
Code: Pascal  [Select][+][-]
  1. begin
  2.   DrawText( [1, 2], 'Text 1');
  3.   DrawText( [3, 4], 'Text 2');
  4. end;
  5.  
is Valid;
Title: Re: The future of Free Pascal
Post by: Thaddy on June 22, 2017, 09:06:17 pm
Maybe you want something like this. Only possible with trunk!
Code: Pascal  [Select][+][-]
  1. program Project1;
  2. {$mode objfpc}
  3. type
  4.   TMyPoint =Array of single;
  5.  
  6. Procedure DrawText( Point : TMyPoint; Text : String );
  7. begin
  8. // whatever...
  9. end;
  10.  
  11. begin
  12.   DrawText( [1, 2], 'Text 1');
  13.   DrawText( [3, 4], 'Text 2');
  14. end.
  15.  

That compiles and works!
Title: Re: The future of Free Pascal
Post by: Paul_ on June 22, 2017, 09:11:33 pm
Thank you, both looks much simpler than what I'm using.
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 09:12:56 pm
Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!

The problem is the whole "copy and paste in source" idea driven too far, a different solution would be to use resources.

I had the same problem with shader source code (not being recompiled after run), changed to resources and am very happy with it.
Title: Re: The future of Free Pascal
Post by: Thaddy on June 22, 2017, 09:18:03 pm
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 
Funny that your code fragment ended up the same  8-)
Anyway, since we now have implicit array constructors, going through a vararray scenario is not necessary in trunk. The code is also way more efficient.
But, trunk only!
Title: Re: The future of Free Pascal
Post by: marcov on June 22, 2017, 09:20:54 pm
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 
Funny that your code fragment ended up the same  8-)
Anyway, since we now have implicit array constructors, going through a vararray scenario is not necessary in trunk. The code is also way more efficient.
But, trunk only!

And array only. Though maybe you can work around it with some conversion operator. (e.g. from array of two singles to tpoint etc)
Title: Re: The future of Free Pascal
Post by: Thaddy on June 22, 2017, 09:25:11 pm
@Marco
Default property. Hasn't arrived yet... Will be... :D ;) O:-)
Title: Re: The future of Free Pascal
Post by: m.abudrais on June 22, 2017, 09:36:02 pm
i liked the string helper  :D, i didn't know about it before.
thank you.
Title: Re: The future of Free Pascal
Post by: jc99 on June 23, 2017, 12:21:51 am
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then 

And array only. Though maybe you can work around it with some conversion operator. (e.g. from array of two singles to tpoint etc)
Sorry, I meant conversion operator of cause. from array to TMyPoint
Title: Re: The future of Free Pascal
Post by: jc99 on June 23, 2017, 12:25:23 am
Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!

The problem is the whole "copy and paste in source" idea driven too far, a different solution would be to use resources.

I had the same problem with shader source code (not being recompiled after run), changed to resources and am very happy with it.
I also had resource in mind, but in this special case it had to be a hard-coded Array of Strings coming from an include-file.
Title: Re: The future of Free Pascal
Post by: segfault on June 29, 2017, 06:45:40 pm
I find it strange that there seems to be a widespread perception among many programmers that Pascal is a "dead" language. A typical comment is "What!, people still use Pascal?"

Delphi/Object Pascal is currently at position 13 on the Tiobe index, ahead of Go, Visual Basic, and objective C. That's hardly "dead".

I have a theory about this; it maybe because Pascal was once great (throughout the 80's and up to the mid 90's or so when I first learned it at Uni), but has since given way to C++, Java, and scripting languages like Python, so it's now relatively obscure. It's "dead" in comparison to what it once was, but still more popular than more niche languages such as Lisp or Fortran, which never really had a heyday as general purpose languages. Even though Lisp and Fortran are even older than Pascal, you don't seem to hear the comment "What!, people still use Lisp?".
Title: Re: The future of Free Pascal
Post by: RAW on June 29, 2017, 08:34:07 pm
Quote
I find it strange that there seems to be a widespread perception among many programmers that Pascal is a "dead" language. A typical comment is "What!, people still use Pascal?"
Me too...
On the other hand the "BIG MONEY" is telling people what is right and what is not or what to do and what not... so it's easy to take a look where the MONEY goes and who controls the MONEY and who creates the opinion for the vast majority of people.

Pascal was great and is still great...  :P
(Yeah, I couldn't deny myself...  :D)
Title: Re: The future of Free Pascal
Post by: Thaddy on June 29, 2017, 11:08:44 pm
http://blog.therealoracleatdelphi.com/2016/04/google-chrome-and-delphi.html

This is not Delphi specific. Same goes for FPC or Lazarus. The speed with which you can do serious programming in a compiled language still exceeds most other languages. At least for me. Even if I spend a lot of time doing C and C++ work and a (huge) bit of Java and Python, I usually prototype in Object Pascal.
Title: Re: The future of Free Pascal
Post by: segfault on June 30, 2017, 11:23:24 am
Pascal was great and is still great...  :P

Agreed! If the masses don't realize that, it's their problem.  :D
Title: Re: The future of Free Pascal
Post by: taazz on July 10, 2017, 06:45:10 am
What's wrong with
Code: Pascal  [Select][+][-]
  1. f:=open("file.txt")
?

Sorry, but you didn't bother to understand my point. It wasn't only about some techniques of opening a file.
I tend to think the task would require writing another compiler without backward compatibility.

For example, an interface that can declare only the name of a procedural type, without actual types:
Code: Pascal  [Select][+][-]
  1. IContextManager = Interface
  2.   deferred __enter__: FuncOrProcType;
  3.   procedure __exit__;
  4.   procedure __rescue__(ex: Exception);
  5. end;
  6.  

^^Here, the type of __enter__ would be determined by a compiler at an implementation site, in a class. Only the name is enforced by the interface, this opens an ability to create "object protocols".
__enter__ can be implemented as a function or procedure, with any arguments and return types.

Such interface leads to rich semantics that use those required methods in a compiler:
Code: Pascal  [Select][+][-]
  1. Using TheCustomer, SomeOtherObject to name1, OtherHelperContext to name2 do
  2.     begin
  3.     // here needed environment(context) is ensured by these "context managers" above
  4.     name1.someMethod;
  5.     name2.interestingMethod;
  6.     end;
  7.  

A compiler would insert calls to __enter__ methods for each object in "TheCustomer, SomeOtherObject to name1, OtherHelperContext to name2", where name1 and name2 would require that __enter__ is implemented as a function rather than a procedure.
On exit for a using statement compiler would insert calls to __exit__ methods.

More organized memory management.
Quote
So, that construction somehow partly replaces RAII of C++, gives some "design by contract" abilities.
Also it can be used to program transactions with rollbacks.
Or using draw procedures in some graphic contexts, or action procedures in a game.
Sorry but you didn't bother to understand mine, the only thing that is not supported currently is to the variable names, otherwise here is a short demonstration how to get exactly the same behavior that you demonstrated today no need for a new compiler.
Code: Pascal  [Select][+][-]
  1.   { TEvsFile }
  2.  
  3.   TEvsFile = object
  4.   private
  5.     FFileStream : TFileStream;
  6.   public
  7.     Constructor init;
  8.     Destructor done;override;
  9.     procedure Open(const aFileName:TFilename);
  10.     Function Read(var aBuffer; aCount: Longint): Longint; override;
  11.     Function Write(const aBuffer; aCount: Longint): Longint; override;
  12.     Function Seek(const aOffset: Int64; aOrigin: TSeekOrigin): Int64; override;
  13.   end;
  14.  
  15.   Constructor TEvsFile.init;
  16.   begin
  17.     FFileStream := nil;
  18.   end;
  19.  
  20.   Destructor TEvsFile.done;
  21.   begin
  22.     FFileStream.Free;
  23.   end;
  24.  
  25.   procedure TEvsFile.Open(const aFileName: TFilename);
  26.   var
  27.     vMode :Word;
  28.   begin
  29.     if Assigned(FFileStream) then FFileStream.Free;
  30.     if FileExists(aFileName) then vMode := fmOpenReadWrite or fmShareExclusive else vMode:=fmCreate;
  31.     FFileStream := TFileStream.Create(aFileName, vMode);
  32.   end;
  33.  
  34.   Function TEvsFile.Read(var aBuffer; aCount: Longint): Longint;
  35.   begin
  36.     FFileStream.Read(aBuffer, aCount);
  37.   end;
  38.  
  39.   Function TEvsFile.Write(const aBuffer; aCount: Longint): Longint;
  40.   begin
  41.     FFileStream.Write(aBuffer, aCount);
  42.   end;
  43.  
  44.   Function TEvsFile.Seek(const aOffset: Int64; aOrigin: TSeekOrigin): Int64;
  45.   begin
  46.     FFileStream.Seek(aOffset, aOrigin);
  47.   end;
  48.  
  49.   function Open(const aFilename:TFilename):TEvsFile;
  50.   begin
  51.      Result.Open(aFilename);
  52.   end;
  53.  
  54.   procedure domytheng;
  55.   begin
  56.     with open("MyDataFile.Dat") do
  57.       read(Data, size);
  58.   end;
  59.  
you have your init right there and when it fells off scope you have the destructor called automatically and it is as clean as your example
Keep in mind that I have not worked with object for a long long time so my facts might be upside down but the idea is there and I'm pretty sure can be made to work.
I do like the variable ability. In any case I'm all up for a new compiler but I'm warning you I'm not giving up my compatibility for any reason.
Title: Re: The future of Free Pascal
Post by: mse on July 10, 2017, 07:01:36 am
MSElang has [ini] and [fini] attributes for object methods:
https://gitlab.com/mseide-msegui/mselang/wikis/home/mselang_objects
Maybe there will be [incref] and [decref] too in order to implement universal reference counting (not yet decided).

Title: Re: The future of Free Pascal
Post by: taazz on July 10, 2017, 08:31:44 am
you have your init right there and when it fells off scope you have the destructor called automatically and it is as clean as your example
Keep in mind that I have not worked with object for a long long time so my facts might be upside down but the idea is there and I'm pretty sure can be made to work.
I do like the variable ability. In any case I'm all up for a new compiler but I'm warning you I'm not giving up my compatibility for any reason.

The programmer is responsible for calling the constructor and the destructor explicitly when using objects.

But it does not relate to what I meant. I took simple semantics in Python as an example and demonstrated how it could possibly be implemented in Object Pascal or some static typed lang.
OK. I don't see it then. Keep in mind that the main force that keeps pascal alive this days is compatibility if I'm to forgo compatibility and rewrite my libraries I'll target a more popular toolchain like c++ I have no reason to stay cornered.
Title: Re: The future of Free Pascal
Post by: Ñuño_Martínez on July 10, 2017, 09:22:17 am
I tend to think the task would require writing another compiler without backward compatibility.
Then it will not be Pascal but another language (i.e. Modula, Oberon...).  ::)

Actually the big advantage of FPC (and also Delphi) is its high backward compatibility.  You can compile programs designed for very old compilers (such as Turbo Pascal 1.0 or Delphi 1) with very little changes.
Title: Re: The future of Free Pascal
Post by: Thaddy on July 10, 2017, 10:10:27 am
What's wrong with
Code: Pascal  [Select][+][-]
  1. f:=open("file.txt")
?
Double quotes... :D
Title: Re: The future of Free Pascal
Post by: Thaddy on July 10, 2017, 10:18:10 am
In general, note that within the limitations of a strongly typed language several python like constructs are already possible or will be possible in the near future.
The needed features for e.g. automatic memory management are either already there (use instantiation to interface variables, not class variables) or under active development (arc support, smartpointers).
Title: Re: The future of Free Pascal
Post by: marcov on July 10, 2017, 10:59:52 am
OK. I don't see it then. Keep in mind that the main force that keeps pascal alive this days is compatibility if I'm to forgo compatibility and rewrite my libraries I'll target a more popular toolchain like c++ I have no reason to stay cornered.

I don't see it either. The challenges of programming nowadays are not due to a lack of language syntax micro optimization.  This is syntax navel-gazing, or syntax graffiti; people feel a need to mark a language as their own by adding something. And if you search long enough you'll find always some construct that can be a few chars shorter. But it makes the language as a whole more baroque and thus weaker.
Title: Re: The future of Free Pascal
Post by: AlexK on July 10, 2017, 11:08:00 am
I tend to think the task would require writing another compiler without backward compatibility.
Then it will not be Pascal but another language (i.e. Modula, Oberon...).  ::)

Actually the big advantage of FPC (and also Delphi) is its high backward compatibility.  You can compile programs designed for very old compilers (such as Turbo Pascal 1.0 or Delphi 1) with very little changes.

True. I implied that more likely nobody would implement it in FPC, not that it breaks backward compatibility.
Golang is criticized for minimalism, procedures attached to structures(records), but Oberon is even more minimalist.
Title: Re: The future of Free Pascal
Post by: bylaardt on July 12, 2017, 04:32:44 am
Double quotes... :D
of course... :-[
Title: Re: The future of Free Pascal
Post by: carl_caulkett on July 12, 2017, 07:08:05 am
In case you're wondering, I believe the bugs related to tooltips showing the wrong variable values when the mouse was hovered over the variable names.
Title: Re: The future of Free Pascal
Post by: Thaddy on July 12, 2017, 10:02:36 am
what happened to the danish language?  O:-)
Dansk bacon er supior til Britisk bacon.
Title: Re: The future of Free Pascal
Post by: Thaddy on July 12, 2017, 11:33:37 am
Anyway, we showed examples that do no necessarily do what the programmer wants
Title: Re: The future of Free Pascal
Post by: AlexK on July 14, 2017, 03:59:08 pm
I've worked a little on implementing syntax highlighting for an FPC mode in Emacs.
It turns out that Delphi's idiosyncrasies spoiled the language in some parts.
For example, calling a proc/func without parenthesis: http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg (http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg)

OBJFPC style guidelines fix that, but are not enforced.
It seams to me that such a language may replace C in open source.
Title: Re: The future of Free Pascal
Post by: Thaddy on July 14, 2017, 05:22:44 pm
 Apart from the fact I had to adapt my ad blocker because of some careless image hosting >:( >:( >:( >:(  (http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg)
Those are not Delphi deficiencies but half-baked parser issues on the emacs side....
Delphi has parser issues, but that's not one of them.

(Try to parse Delphi 7 's system.pas or windows.pas in FPC to find some real parser issues...  8-) )
Title: Re: The future of Free Pascal
Post by: AlexK on July 14, 2017, 06:56:58 pm
Those are not Delphi deficiencies but half-baked parser issues on the emacs side....
Delphi has parser issues, but that's not one of them.
(Try to parse Delphi 7 's system.pas or windows.pas in FPC to find some real parser issues...  8-) )

You are ignorant.
In Delphi "there is no difference between a function result and a variable, however there is in FPC":
http://wiki.freepascal.org/Code_Conversion_Guide#When_calling_a_procedure_variable_use_this_syntax:_theprocname.28.29

It's not a "half-baked parser issues on the Emacs side" because I didn't even start to write a parser(Semantic built-in lib in Emacs). Only a quick automatic fontification so far.

I don't know yet what pushed Delphi programmers to make the language more context dependent by omitting parenthesis for function calls without arguments. It seams like a C++ way.
Title: Re: The future of Free Pascal
Post by: avra on July 14, 2017, 07:33:48 pm
It seams to me that such a language may replace C in open source.
I wish. Anyway, it made me smile today. Thank you!  :D
Title: Re: The future of Free Pascal
Post by: marcov on July 14, 2017, 07:36:07 pm
You are ignorant.
In Delphi "there is no difference between a function result and a variable, however there is in FPC":

There is in some parser modes. The opinions about that vary.

Quote
http://wiki.freepascal.org/Code_Conversion_Guide#When_calling_a_procedure_variable_use_this_syntax:_theprocname.28.29

It's not a "half-baked parser issues on the Emacs side" because I didn't even start to write a parser(Semantic built-in lib in Emacs). Only a quick automatic fontification so far.

Halfbaked "Semantic built-in lib in Emacs" then.

Quote
I don't know yet what pushed Delphi programmers to make the language more context dependent by omitting parenthesis for function calls without arguments. It seams like a C++ way.

Delphi's predecessor already had it.   Parenthesis don't make a function call a function call. Pascal is a typed language, the fact that identifier is a function makes it a function call.

The FPC mode forces it to solve some rare ambiguity case. Not for syntax highlighters benefit.
Title: Re: The future of Free Pascal
Post by: Blestan on July 14, 2017, 07:42:06 pm
Quote
You are ignorant
nowi will get some.gin/tonic and wait for thaddy's reaponse and i will enjoy your slow convultions   :D
Title: Re: The future of Free Pascal
Post by: Thaddy on July 14, 2017, 08:57:36 pm
Quote
You are ignorant
nowi will get some.gin/tonic and wait for thaddy's reaponse and i will enjoy your slow convultions   :D
In this case ... I'd stick to the gin-tonic  8-)
Title: Re: The future of Free Pascal
Post by: AlexK on July 14, 2017, 09:20:22 pm
Parenthesis don't make a function call a function call. Pascal is a typed language, the fact that identifier is a function makes it a function call.

That's why in Delphi you have to do @SomeFuncName to get a pointer.

Code: Pascal  [Select][+][-]
  1. type
  2.   TFuncNoArgsString = function(): String; // is it a pointer type?
  3.  
  4. function Hello: String;
  5. begin
  6.   Result := 'Hello There';
  7. end;
  8.  
  9. procedure Take(f: TFuncNoArgsString);
  10. begin
  11.   WriteLn( f() );
  12. end;
  13.  
  14. Take(@Hello); // that is a pointer type! but you have to use operator @ on a name
  15.  

When you think about a function name, it can't be anything else than a POINTER to its code.
But if you want to treat a function's name as a pointer, you have to distinguish between a name as a pointer and a function invocation.
So parenthesis for invocation must be mandatory. In this case you wouldn't need to use @ on a function's name.
Title: Re: The future of Free Pascal
Post by: marcov on July 14, 2017, 09:33:58 pm
That's why in Delphi you have to do @SomeFuncName to get a pointer.

Your code compiles fine without the @. @ and @@ are only used to disambiguate cases (mostly when a function returns  a function type )

Quote
When you think about a function name, it can't be anything else than a POINTER to its code.

Functions are semantically not pointers, even if  they translate to a pointer on asm level. Talking about function pointers is a Cism.

Actually, @ can (in the case of nested functions and functions of objects), even have an implementation of two pointers.

Quote
But if you want to treat a function's name as a pointer, you have to distinguish between a name as a pointer and a function invocation.
So parenthesis for invocation must be mandatory. In this case you wouldn't need to use @ on a function's name.

I think you are confused with a different language. There is no @ requirement in Delphi (or TP for that matter)
Title: Re: The future of Free Pascal
Post by: AlexK on July 14, 2017, 10:03:03 pm
That's why in Delphi you have to do @SomeFuncName to get a pointer.
Your code compiles fine without the @.

No, compiler calls the function "Hello" and passes to "Take" a string returned by "Hello".
Code: Pascal  [Select][+][-]
  1. Take(Hello);

Error: Incompatible type for arg no. 1: Got "AnsiString", expected "<procedure variable type of function:AnsiString;Register>"

It expects "procedure variable type", but in syntax you have to use @, which means a pointer.
A function's name is treated as an invocation, not as a pointer.
Title: Re: The future of Free Pascal
Post by: marcov on July 14, 2017, 10:38:41 pm
That's why in Delphi you have to do @SomeFuncName to get a pointer.
Your code compiles fine without the @.

No, compiler calls the function "Hello" and passes to "Take" a string returned by "Hello".
Code: Pascal  [Select][+][-]
  1. Take(Hello);

Error: Incompatible type for arg no. 1: Got "AnsiString", expected "<procedure variable type of function:AnsiString;Register>"

That sounds like a /fpc/ error. Delphi (XE4) compiles it fine, WITHOUT @.

Title: Re: The future of Free Pascal
Post by: chain_reaction on July 15, 2017, 03:11:47 am
I've worked a little on implementing syntax highlighting for an FPC mode in Emacs.
It turns out that Delphi's idiosyncrasies spoiled the language in some parts.
For example, calling a proc/func without parenthesis: http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg (http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg)

OBJFPC style guidelines fix that, but are not enforced.
It seams to me that such a language may replace C in open source.

Alex, FPC-mode in Emacs? This is really a good one. Have you already upload the FPC-mode package to the melpa repo? I would really like to try it  :).
Title: Re: The future of Free Pascal
Post by: Thaddy on July 15, 2017, 09:57:37 am
Code: Pascal  [Select][+][-]
  1. type
  2.   TFuncNoArgsString = function(): String; // is it a pointer type?
  3.  
  4. function Hello: String;
  5. begin
  6.   Result := 'Hello There';
  7. end;
  8.  
  9. procedure Take(f: TFuncNoArgsString);
  10. begin
  11.   WriteLn( f() );
  12. end;
  13.  

Silly idiots, this compiles in all Delphi's and in FPC:
Code: Pascal  [Select][+][-]
  1. program untitled;
  2. {$ifdef fpc}{$mode delphi}{$apptype console}{$endif}
  3. type
  4.   TFuncNoArgsString = function(): String; // is it a pointer type?
  5.  
  6. function Hello: String;
  7. begin
  8.   Result := 'Hello There';
  9. end;
  10.  
  11. procedure Take(f: TFuncNoArgsString);
  12. begin
  13.   WriteLn( f() );
  14. end;
  15. begin
  16. Take(Hello); // that is a pointer type! but you have to use operator @ on a name (NO silly!)
  17. end.

Versus this does not compile in Delphi at all but will compile in objfpc mode:
Code: Pascal  [Select][+][-]
  1. program untitled;
  2. {$mode objfpc}{$ifdef mswindows}{$apptype console}{$endif}
  3. type
  4.   TFuncNoArgsString = function(): String; // is it a pointer type?
  5.  
  6. function Hello: String;
  7. begin
  8.   Result := 'Hello There';
  9. end;
  10.  
  11. procedure Take(f: TFuncNoArgsString);
  12. begin
  13.   WriteLn( f() );
  14. end;
  15. begin
  16. Take(@Hello); // that is a pointer type! but you have to use operator @ on a name (YES, that is required by objfpc mode)
  17. end.
  18.  


Mixing up modes. No bug in fpc.
Title: Re: The future of Free Pascal
Post by: AlexK on July 15, 2017, 04:47:51 pm
Alex, FPC-mode in Emacs? This is really a good one. Have you already upload the FPC-mode package to the melpa repo? I would really like to try it  :).

Just an experiment.
I still have to make auto-indentation, better Imenu support with Helm. Some main shortcuts for compilation.
All other modes in the past where done for Delphi, then abandoned for understandable reasons.
Not sure yet if I'll be implementing it.
Title: Re: The future of Free Pascal
Post by: marcov on July 18, 2017, 10:34:52 am
I tried to split the Bounded WITH subthread (http://forum.lazarus.freepascal.org/index.php/topic,37594.0.html), but it is my first split, so be patient
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on July 20, 2017, 10:03:03 pm
Well, in favor of Delphi (and because marcov really doesn't like it when I say bad things about it), next to all the bugs, warts and uncertainty, it does have FireMonkey. Which is exactly what every decent IDE nowadays should have.

Because that's the main reason why projects get cancelled in my experience, and that is / would be the main reason to use Lazarus.

If doing a project today, it needs to be multi-platform. And either a web-app, or C# or Java if that's not possible, because that's what the people graduating know. And that's who companies want to hire: young, cheap and like virgin clay.

Then again, if you make a list what IDE scores best on that Time To Market scale, Lazarus is in the top three. And it would solidly be on the first place if it had something like FireMonkey.

Now the only development platform that is truly multi-platform is Unity3D...


So, when I have explained all the pros and cons, management tends to like Unity best, except that it is called a "game engine". If not for that, I wouldn't be able to use Lazarus at all.

The saving grace for Lazarus is (in my experience) that you can turn out tools and Linux servers (mostly http, the MicroService idea) at a fast clip. That they are easy to distribute (no installing). And that they keep on working.


If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.
Title: Re: The future of Free Pascal
Post by: AlexK on July 27, 2017, 06:38:59 am
If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.

OpenGL ES 2 is an ubiquitous standard these days. https://kivy.org in Python uses it for user interfaces, multi touch, different input devices.
But some prefer native look and feel.
Title: Re: The future of Free Pascal
Post by: mse on July 27, 2017, 08:08:01 am
If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.
Free Pascal has at least two owner drawn cross platform toolkits since more than 10 years: fpGUI and MSEgui. For MSEgui there is also MSEide, a handy and very productive design environment.

Title: Re: The future of Free Pascal
Post by: Blestan on July 27, 2017, 08:19:00 am
great then!  so mse gui has his own  coherent look and feel across android and ios? what are the minimal verions supported? if the both platform are 10+ years then atleast ios 6 and android kitkat?  pls send some screenshots on different screen sizes :)
Title: Re: The future of Free Pascal
Post by: mse on July 27, 2017, 08:28:35 am
Personally I think on phones one should use the tools of the platform.
Porting fpGUI and MSEgui to phone-OS could be done if there is enough interest and maybe sponsors, the software architecture is designed for such a task.
Title: Re: The future of Free Pascal
Post by: Blestan on July 27, 2017, 08:33:55 am
so for example unity is only cross platform on desktops and uses another tools on android and ios?
Title: Re: The future of Free Pascal
Post by: Thaddy on July 27, 2017, 10:11:07 am
so for example unity is only cross platform on desktops and uses another tools on android and ios?

Basically. Yes. Unity is nothing more than a widget set. So doesn't matter to OS operation. Unity is a display library, not part of any OS. E.g. It could be implemented on Windows... Like Qt and GTK(x)
Which means it is only cross platform for the platforms it is implemented on.....
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on July 27, 2017, 11:48:44 am
Unity - Game Engine (https://unity3d.com/unity/features/multiplatform)
Title: Re: The future of Free Pascal
Post by: Thaddy on July 27, 2017, 12:29:53 pm
Unity - Game Engine (https://unity3d.com/unity/features/multiplatform)
Unity: user interface: http://unity.ubuntu.com/ A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.
<Grumpy!!  >:D> O:-)
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on July 27, 2017, 12:42:51 pm
Unity: user interface: https://en.wikipedia.org/wiki/Unity_(user_interface) A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.
As I was the one talking about Unity, I wanted to clarify which one I was talking about.
Title: Re: The future of Free Pascal
Post by: Thaddy on July 27, 2017, 12:46:43 pm
Unity: user interface: https://en.wikipedia.org/wiki/Unity_(user_interface) A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.
As I was the one talking about Unity, I wanted to clarify which one I was talking about.
Which was unknown to me (which also means nobody knows it - let alone uses it - on a large scale). Unity as a widget set is rather well known. Unity as game engine is not. Change the name...
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on July 27, 2017, 12:55:31 pm
Change the name...
As you wish.
Title: Re: The future of Free Pascal
Post by: Thaddy on July 27, 2017, 01:02:47 pm
Change the name...
As you wish.
I will check it out, now. What the new name? 8-)
Title: Re: The future of Free Pascal
Post by: SymbolicFrank on July 27, 2017, 01:08:37 pm
I changed it in the original post to Unity3D, but left the others to show what we were discussing.

 ;D
Title: Re: The future of Free Pascal
Post by: AlexK on August 03, 2017, 05:24:36 am
Unity: user interface: http://unity.ubuntu.com/ A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.
<Grumpy!!  >:D> O:-)

It had been discontinued. Ubuntu uses standard Gnome now, like Fedora distro.
Title: Re: The future of Free Pascal
Post by: Akira1364 on August 06, 2017, 03:36:31 am
Which was unknown to me (which also means nobody knows it - let alone uses it - on a large scale). Unity as a widget set is rather well known. Unity as game engine is not. Change the name...

You certainly have this backwards. Unity (the game engine) is effectively tied with the Unreal Engine for "most popular game engine in the world." It's a billion-plus dollar endless cash cow for its developer (Unity Technologies). 99.99999% of anyone who is remotely tech savvy would think of it first if you simply mentioned "Unity". Unity the Ubuntu skin (calling it a "widget set" is something of a stretch) is on the other hand generally only known by people who both use Linux in general (which is not that many in the grand scheme of things to begin with) and on top of that specifically use Ubuntu as their distribution. Its developer, Canonical, is a sub-100-Million dollar company that again, generally only Ubuntu users have ever heard of.
TinyPortal © 2005-2018