Recent

Author Topic: Off Topic - Promises - Re: Would like feedback on my idea for a "fork" or "dist"  (Read 3623 times)

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
I don't know how WordPress makes it happens, static or dynamic linking or whatever. Lots of theme designers and plugin writers are making good money working on WordPress. WordPress can install commercial closed source plugins/themes easily. If Lazarus can be linked or integrated or work together with commercial closed addons/plugins, it will be attractive to some skilled programmers who want to make money.

I don't want to drag this discussion too far afield, but Lazarus and Wordpress can't really be compared like this, as they serve two entirely different target markets.

Wordpress serves a market of people who want to host their own website, using a platform that supports extensions and plugins.  Ignoring its competitors for a moment, this is a vast number of potential people.

Lazarus servers a market of people who want to use Free Pascal with a rapid application development environment.  Even ignoring every other language and IDE, this is a much smaller number of people.    And it's not clear what percentage of those people would be further interested in closed addons/plugins.

Is it a bad idea?  No.   But I have a hard time seeing the following as a statement that can be made definitively:

...it will be attractive to some skilled programmers who want to make money.

Who can attest to the size of the market that would pay for this now?   

At best, we can hope that there would be some attraction. If it was easy to implement either way, I would say, "sure, let's see someone take the time and go for it."    But I doubt it is that simple, and if it didn't come with some pre-built addons and plugins to show the viability, I don't see where the gravitational pull would come from.

I can see niche markets, though, like one that might cater to the OP's needs.   But I would be very careful at any over-exuberance in this regard.

[Edit for readability]
« Last Edit: May 09, 2021, 06:58:28 pm by ASBzone »
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9755
  • Debugger - SynEdit - and more
    • wiki
Afaik there are commercial 3rd party packages on the Market. Which would mean that already exists. (Not sure if that includes IDE extensions, but not impossible either)

Could it be made simpler? Sure everything can always be made simlper :P
(Actually, seriously there are things like dyn link pgk under way. But they take their time. Maybe not enough money to be made from them?)


As for "would attract more"...
If I had a penny for every time I heard that... So many people promised that for whatever they thought would be good to have...
But, then some of those requested things have actually happened, the promised effect on the other side, well that has never yet happened ever...


ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
As for "would attract more"...
If I had a penny for every time I heard that... So many people promised that for whatever they thought would be good to have...
But, then some of those requested things have actually happened, the promised effect on the other side, well that has never yet happened ever...

That's because, as I am sure you well know, ecosystems like this are complex, and there are many factors that play into popularity, market stature, market perception, financial viability, etc.

Too many of these discussions tend to boil everything down to a *single* problem, that if solved, would unilaterally open the floodgates of increased attention and usage.   

That may be possible, but it is certainly not probable.  There are assuredly multiple factors involved in this issue, and that requires multiple approaches and tactics.

Frankly, a sustained marketing effort to deprogram folks from thinking of Pascal as some toy or learning-only language, would likely yield better results than almost any other single change or addition.   But for real effect, there would need to be a coordinated effort across multiple fronts, addressing perception, actual usability, economic opportunities, etc...

(BTW, let's just all agree that making Pascal *popular* by making it more like something else is not actually making Pascal popular, but simply creating a Pascal-flavored-something-else.  And that's not what I would ever want to see.)
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11355
  • FPC developer.
Too many of these discussions tend to boil everything down to a *single* problem, that if solved, would unilaterally open the floodgates of increased attention and usage.   

(in my mind I call this the "build it, and they will come" argument, after a "Married with Children" episode)

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
I don't know how WordPress makes it happens, static or dynamic linking or whatever. Lots of theme designers and plugin writers are making good money working on WordPress. WordPress can install commercial closed source plugins/themes easily. If Lazarus can be linked or integrated or work together with commercial closed addons/plugins, it will be attractive to some skilled programmers who want to make money.

You can install commercial packages in Lazarus without problems. However there are currently two problems:
  • no code completion of binary only units
  • packages need to match the version of the compiler and IDE

The first point is solved once CodeTools gains support for reading information from PPU files.

The second point will stay and it's not something that even dynamic packages will solve (which seems to be something that commercial package vendors don't seem to understand). So a package vendor will need to provide their package for e.g. 2.0.12 with 3.2.0, 2.0.12 with 3.2.2, 2.2 with 3.2.0, 2.2 with 3.2.2 and so on. In theory they could also provide packages for the development versions, but these would be for specific revisions making it rather unfeasible for such vendors and also the users.
We can only guarantee the binary compatibility with the released versions, cause the point of the development versions is that things shift around and change. The vendors don't have this problem with Delphi, because they simply don't have access to the development versions like they do with FPC and Lazarus.

WordPress has it easier here, because it's written in PHP which is source only thus there's no problem with binary compatibility.

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
WordPress has it easier here, because it's written in PHP which is source only thus there's no problem with binary compatibility.

And Wordpress is primarily hosted, which means that a fairly large percentage of the population is running a near current version of the platform, making it easier for vendors to target support.

When you take a product that is installed on premise, and where there is no external pressure to be running the latest version, the compatibility issue becomes more pronounced.

For reference, here are some Wordpress statistics from the past few months, to show what I am talking about:

https://w3techs.com/technologies/details/cm-wordpress
https://wordpress.org/about/stats/

The three most recent versions of Wordpress represent 58% of all Wordpress installations, bearing in mind that the release dates are as follows:
-- v5.7.0 = March 9, 2021
-- v5.6.0 = December 8, 2020
-- v5.5.0 = August 12, 2020

The latest version has 32% of Wordpress install share and was released just over a month ago.

That does not nearly begin to resemble the dynamics of the Lazarus/FPC ecosystem.

So, it's not just enough to make sure your package or plugin works with the latest version (or 3), because you could have a sizable percentage of people running something older, and needing support there.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9755
  • Debugger - SynEdit - and more
    • wiki
WordPress has it easier here, because it's written in PHP which is source only thus there's no problem with binary compatibility.

Well Pascal allows source distribution too. And that would solve most compatibility issues. But for some reason....

lainz

  • Hero Member
  • *****
  • Posts: 4450
    • https://lainz.github.io/
Quote
Well Pascal allows source distribution too. And that would solve most compatibility issues. But for some reason....

Bad marketing?

A tool that does a lot of things, but not a single one, like PHP is related to web only, but pascal isn't?

For example if you enter some language website, they display the main 3 or 4 things you can do with it.

Something like: native command line, webassembly, embedded and compile to javascript. Easy to follow manuals for each target application.

If the language doesn't have that manual, is easier to go and pick another? (In the end you must know more than a single language, why not only these that already solves the manual)

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
WordPress has it easier here, because it's written in PHP which is source only thus there's no problem with binary compatibility.

Well Pascal allows source distribution too. And that would solve most compatibility issues. But for some reason....

Pascal allows it, it doesn't require it. And thus with the mere possibility to keep their source private companies will do so (at least if they aren't inclined to publish their sources as Open Source anyway).

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
We can only guarantee the binary compatibility with the released versions, cause the point of the development versions is that things shift around and change.
As I understand when interfacing with an other language, the version of the compiler shouldn't be important, right? So the binary compatibility could only change for special features? What would that be, classes?

So in practice, it might not be necessary to provide a package for each release?

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
We can only guarantee the binary compatibility with the released versions, cause the point of the development versions is that things shift around and change.
As I understand when interfacing with an other language, the version of the compiler shouldn't be important, right? So the binary compatibility could only change for special features? What would that be, classes?

So in practice, it might not be necessary to provide a package for each release?

It is necessary, because from release to release the interface sections of the core units will likely have changed (new intrinsics here, new Delphi compatible types, classes, variables there, maybe a bugfix here and there that changes some function signature and let's not forget a new virtual method for the one or other class) and thus anything that depends on them needs to be recompiled. And some times even the version number of the PPU files changes, because something new was stored into the PPUs (mainly when a new language feature is added). This again requires a recompilation of all units. And the dynamic package system will check both the interface checksums (that are stored in the PPUs) and the PPU versions to ensure that there aren't any problems due to a differing binary interface.

In theory one could achieve binary compatibility by only changing things in the implementation section (and one can in fact use this with dynamic packages), but from release to release that is a maintenance burden we're not going to support. Not to mention the development versions.

It's not as simple as calling a library, because the with a library you only have a code address, nothing more (and if you import a C function returning int as returning void instead nothing bad will happen), with units, no matter if statically linked or using dynamic packages you have the whole range of mangled names, VMTs, type information, etc. that needs to be kept consistent.

At work we use C++ and our code is split over many libraries and we use abstract classes (aka interfaces) a lot. Since a few years we have a build system that automatically generates a complete build with which you can work, but before we had that it was a nightmare to add new virtual methods to an interface or to refactor things, cause you had to make sure manually that all dependant libraries are recompiled with the correct headers. And we control all the source that's involved there. Now imagine this in a situation where you have binary code from multiple vendors.

No. We're definitely not doing something like that. We'll have new binaries each version and no guaranteed binary compatibility in the development versions. Just like it is today.

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
(BTW, let's just all agree that making Pascal *popular* by making it more like something else is not actually making Pascal popular, but simply creating a Pascal-flavored-something-else.  And that's not what I would ever want to see.)

One of the best examples of this, in my mind, was IBM OS/2 Warp.   

The compatibility of Warp in running Windows applications, did not induce anyone to code native apps for OS/2 Warp, but made it easier to run existing Windows apps on OS/2 Warp.

This led to software developers getting a slightly bigger market to deliver their Windows apps to, and put the burden of support on IBM to ensure that Warp continued to be compatible with Windows.  And the Warp ecosystem did not grow as it could have.

Ultimately, the ability of Warp to run Windows apps, contributed to the relative paucity of native apps for Warp, without actually broadening the appeal of Warp in any significant way. 

Compatibility has value, especially when there are other advantages available, such as cost, performance or market stability.    But compatibility often (but not always) leads to an inability to provide or leverage native strengths.  And this often leads to dead in the mid-to-long-term.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2020
  • Former Delphi 1-7, 10.2 user
Ultimately, the ability of Warp to run Windows apps, contributed to the relative paucity of native apps for Warp, without actually broadening the appeal of Warp in any significant way. 

And as soon as OS/2 could no longer run Windows applications, I reluctantly moved on to Windows NT 3.51.

Of course IBM did not add Windows 3.1 compatibility to widen the appeal of OS/2, it was already part of the doomed IBM-Microsoft operating system joint venture.

 

TinyPortal © 2005-2018