(moved from part 3 action thread that discourages replies)
munair wrote:
looking at the FreePascal project, I wonder if that compiler would be as actively maintained and developed without the Lazarus RAD environment. So there's definitely an advantage in having a project like that. I'm surpirsed to see it hasn't happened yet in the last 13 years with FreeBASIC.
It all stands or falls with active developers, and a bit long term focus. Lazarus is partially entangled with the FPC project. Having a constantly multi-person development team also keeps it generic, and doesn't cause one persons preferences to show through in everything. Having Delphi as model of course helped enormously to keep the noses (mostly) in the same direction.
Another thing is regular release accessible to the user. Experience shows that most potential devels first have their own projects before they get active, and if they can't easily test, they won't. That aspect is ok in FB I guess.
For the more outer parts of the system potential more serious power users and devels should also be able to compile the project from SVN/CVS/GIT. It doesn't need to be a blind button push so that everybody can do it, but serious people should be able to master it fairly quickly. Having low build dependencies helps immensely here. I don't know how FB does here.
Lazarus
The boost is not just starting on an IDE but compiler, RTS and "outer" libraries too. All parts were advanced at the same time with one common goal, to a have a delphi like RAD. Compiler got RTTI, RTS got libraries to access it and hundreds of other things to make the object model viable for such big endeavour. (the component streaming was rewritten at least three times)
Specially those non visual libraries that the visual components of Lazarus base (streaming, XML, imaging and DB and headers for the libraries, if any) are the ones where most common work are done. In recent years also unicode. Lazarus had a simple unicode system, but that is slowly fading now that there is language encoding support in FPC with FPC3.
FPC development already got a major boost when during the 2.x beta series (late 2003-mid 20050 the number of own libraries started expanding ( most notably simple XML, image, sockets (mostly abstracted simple sockets, not something like Indy) and DB units with low dependencies. These were done thoroughly, and modelled after Delphi, which made it a good fit for Lazarus. (db components and image components e.g.) Compatibility is not just good for users, but also while building it. The interfaces are fixed by it.
That should be as much as a focus as the IDE itself. Don't cut corners, do it right. But for that you need a multiperson effort.
To do this, basically FPC put the old dos legacy in supported but maintenance only mode, and increasingly focused on Delphi after 1997 accelerating in 2000 with the FPC 1 stable release which did a lot for the other libraries, and with a usable FPC 2 beta in early 2004 it really started to go faster. This partially also because Delphi code came in reach.
(the FPC1 release was very compatible with TP, comparable with FB's QB compat, but even with a complete textmode IDE clone, and actually that compatibility still exists today and has been improved, albeit very slowly).