Recent

Author Topic: RAD IDE  (Read 6883 times)

lawman

  • New Member
  • *
  • Posts: 43
RAD IDE
« on: January 22, 2020, 09:35:15 pm »
I'm just wondering why...

C++ has soooo much userbase...

but I can't find any free decent RAD IDE for C++ like Lazarus that has GUI and Database components built in??

I've found CodeBlocks C++ which has gui components with wxwidgets, but Lazarus has so much more to make it RAD.

Just find it weird as Lazarus / FPC userbase is a small fraction of C++ userbase.

I've searched everywhere and checked out Ultimate++, Codelite, Codeblocks and a range of others... but Lazarus still seems so much easier to use, like Visual Basic RAD IDE was in the old days.

Am I missing something?

Please advise.   

Thanks

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: RAD IDE
« Reply #1 on: January 22, 2020, 09:43:16 pm »
Am I missing something?
...a few deep pocket corporates and a several decades of active development tool promotion. (specifically the language).

IF Lazarus is too support other languages, specifically on the level of code tools - meaning intelligent understanding of the code, then it could grow the popularity by itself. (not necessary the pascal language)

Most of Lazarus IDE users are Pascal developers, and either don't need to develop a language plugin for the IDE or are using different IDE's for other languages.
« Last Edit: January 22, 2020, 09:45:15 pm by skalogryz »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: RAD IDE
« Reply #2 on: January 22, 2020, 09:59:31 pm »
I'm just wondering why...

C++ has soooo much userbase...

but I can't find any free decent RAD IDE for C++ like Lazarus that has GUI and Database components built in??

Well the only logical conclusion of course is that C++ programmers are lazy :-)

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: RAD IDE
« Reply #3 on: January 22, 2020, 10:05:25 pm »
Well the only logical conclusion of course is that C++ programmers are lazy :-)

Or the other way around: Pascal programmers have become so lazy that we require full-fledged, advanced IDEs like Lazarus and Delphi ;D :D

Of course, at some point that becomes a "chicken and egg" problem :D :D :D
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: RAD IDE
« Reply #4 on: January 22, 2020, 10:20:53 pm »
Well the only logical conclusion of course is that C++ programmers are lazy :-)

Or the other way around: Pascal programmers have become so lazy that we require full-fledged, advanced IDEs like Lazarus and Delphi ;D :D

Of course, at some point that becomes a "chicken and egg" problem :D :D :D

If that so, C++ users would stodgily refuse to use VIM because it is too advanced and gotten to bloated and stick to ED. That's not the case. Many C++ IDEs exist, but the integration beyond code editing, navigation is usually poor, and design is even less, staying fancy editors and not much else.

I don't really know why there is not something equivalent.

Some problems are inherently C++, like the need for complex project management since you need more than " CC mainfile" to compile a C++ project. Some are that the free C/C++ compilers are tied to Unix, and thus are often tied to Unixy environments like cygwin and mingw on majority target Windows.

And Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)

And to succeed you really need to keep all the noses pointed in the same direction. People always rant on this forum about delphi compatibility, but I think having an example that large groups of people looked up to  was a really major, major factor (and TP compatibility before it)

And of course ONE whole Pascal RAD in 25 years might just be a statistical anomaly
« Last Edit: January 22, 2020, 10:29:08 pm by marcov »

Bart

  • Hero Member
  • *****
  • Posts: 5275
    • Bart en Mariska's Webstek
Re: RAD IDE
« Reply #5 on: January 22, 2020, 10:35:49 pm »
And of course ONE whole Pascal RAD in 25 years might just be a statistical anomaly

 :) :) :)

Bart

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: RAD IDE
« Reply #6 on: January 24, 2020, 12:53:30 am »
I've searched everywhere and checked out Ultimate++, Codelite, Codeblocks and a range of others... but Lazarus still seems so much easier to use, like Visual Basic RAD IDE was in the old days.

Am I missing something?

Tools made by the community, for the community.  There's something to be said for this.

Having deep pockets is great for getting something out there, and commanding mindshare, but if there isn't a corresponding vision by people who strongly desire to use the resulting end product, then it doesn't necessarily lead to a better product.  A more popular one, perhaps, but not necessarily better.

The other advantage is that when Delphi was released, it was lightyears better than other products and rapid design and rapid prototyping.   I don't think that this edge has really been lost for ObjectPascal since that time.    Other tools have focused on other strengths...

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

Paul_

  • Full Member
  • ***
  • Posts: 143
Re: RAD IDE
« Reply #7 on: July 09, 2020, 07:40:50 pm »
And Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)

Actually in Visual Studio isn't possible to create GUI/form with native C++ whereas forms are somewhat like C#.
You can make C++ CLI application and add form, but it's managed dialect where you can't use pointers, std.. some unnecessary interface must be created. In addition C++ CLI is abandoned by MS in favor of C# forms. Then another option is using C# application and C++ DLL. All this is overcomplicated and really confusing nonsense, if somebody is using C++ so he want surprisingly code in C++.. also want performance, clarity or other benefits of that language.

Not to mention that forms implementation and form designer looks like an experimental feature moreover with stability similar to Chernobyl reactor than the fixed component of the Visual Studio (which, on the contrary, I quite like).

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: RAD IDE
« Reply #8 on: July 09, 2020, 08:37:21 pm »
Simple, C++ is not used for RAD development, thats why there is no real RAD IDE for it. Same is also true for example for Python. Pascal as a language was steered into the RAD direction by borland, it also heavily inspired .Not and Java which is why there are RAD tools available for these languages too.

C is a language developed for one reason, kernel development, which is the pure opposite of RAD, looking at C++, there is QT with the QT-Creator, which tends more into the RAD direction, but as with C, the main niche C++ occupies is not rad development, which is somewhat understandable, because the language design of C++, it's strength and weaknesses, are not so well suited for RAD as for example C# or Pascal. For example, there is no concept of Method pointers in C++, there are only function pointers to this call functions.

The design of a language has profound implications on what it's strength and weaknesses are. C++ has by design some base complexity, so the rapid in RAD is already off the table.

Also C and C++ have a "difficult" relationship with IDEs in general, because of the very different tooling available. With using an IDE you are binding yourself to what this IDE can understand. Now let's say you have a C++ project for Windows, Linux and macOS. For windows you use MSVC++ compiler and the corresponding debugger. On Linux you might use GCC and GDB and for Apple you will use the Apple version of Clang with LLDB.
To handle this clusterfuck of a buildsystem you started of with makefiles but soon realized that this is not enough so you either write a configure script using Bash, generate one using Autoconf, or if you are a little less old fashioned use CMake.
So if you wanted to use an IDE, this IDE needs to be capable of parsing this buildsystem and somehow find out how you configured your project (search paths, defines, etc.) and also make smart changes to this when you configure your project. But as your buildsystem is a literally a turing complete scripting language, this is simply computationally impossible, so long story short, such an IDE can not exist.

So if you have an "IDE" it can't really integrate the most important part of your "Development Environment", i.e. the buildsystem and project configuration. So whats the point of having an IDE. So all you are left with is an editor that is configurable to your C++ project (like using clang-completion and stuff), and this already exists, Emacs, Vim, VSCode, there is nothing an IDE could do better than a good editor for such projects.


That said, there are C++ IDEs, but if you use them everyone in your team needs to use them (because a general buildsystem is of the table) which of course has other implications. License restrictions, personal preferences, and simply cross plattform availability. Visual Studio or XCode are great, but only work on a single machine. CLion is good but is proprietary software.

For Java this is solved by having widespread support for simple and unified buildsystems like maven which are well thought through. And languages like Javascript or Rust have their own management tools like npm or cargo which are shipped with the language environment. Similarly this is for Pascal, there are basically two relevant pascal compilers (Delphi and FPC) with each having one IDE that is the defacto standard for them (Delphi and Lazarus). If you don't have much choice, there is no need for such a clusterfuck like C++ has


When I started using C++ and C, I was using a mac, so what I did was I've imported the project into XCode, and configured the XCOde project as the CMake file configures the project for building on Linux (I actually compiled it on a Linux buildserver). The XCode files where added to the gitignore and everything worked fine, I could use all of XCodes functions. But I've always had to sync up XCode with CMake if any changes where done, and the initial effort is huge. So with the next project I simply decided to only use Vim, now I am using emacs with Spacemacs, and I never regretted that decision to switch from IDEs to simple editors. They are great for C++, and there is no feature that IDEs have that is worth the effort I've had before.

Also there is something to the fact that I can simply download a C++ project, fire up vim or emacs (evan via ssh on a totally different pc) and build it with one simple make (or cmake build).
If I want to contribute to a Java project that doesn't use maven, I first need to get the correct IDE for this, which resulted in at one time, me having 3 Java IDEs installed at once on my machine.
« Last Edit: July 09, 2020, 09:31:46 pm by Warfley »

dparnaby

  • New Member
  • *
  • Posts: 11
Re: RAD IDE
« Reply #9 on: July 09, 2020, 08:51:11 pm »
Lazarus and  FPC  have come so far over the years
Bloating in other similar IDE's have made them difficult to use.
Pascal should reign and any move to bring in a broader user base would,  in my opinion, be better spent in expanding the Node.js capability in the IDE.
A fit all approach leads to bloating and reduced productivilty

« Last Edit: July 10, 2020, 04:38:38 am by dparnaby »

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: RAD IDE
« Reply #10 on: July 10, 2020, 09:26:24 am »
And Windows centric C++ users simply use free VS that allows you to deploy free GUI applications (contrary to Delphi that costs several thousands and the free version of which has license restrictions and is sometimes complex to get)

Actually in Visual Studio isn't possible to create GUI/form with native C++ whereas forms are somewhat like C#.

Ever used MFC? I mean, it's not RAD in the Delphi/Lazarus sense, but it allows you to visually design your GUI and it's relatively easy to add event handlers.
 
For example, there is no concept of Method pointers in C++, there are only function pointers to this call functions.

Of course C++ does have method pointers. At work I've even used them a few occasions. :) They are however clumsy to use and nowhere as nice and flexible as method pointers in Object Pascal.

Also C and C++ have a "difficult" relationship with IDEs in general, because of the very different tooling available. With using an IDE you are binding yourself to what this IDE can understand. Now let's say you have a C++ project for Windows, Linux and macOS. For windows you use MSVC++ compiler and the corresponding debugger. On Linux you might use GCC and GDB and for Apple you will use the Apple version of Clang with LLDB.
To handle this clusterfuck of a buildsystem you started of with makefiles but soon realized that this is not enough so you either write a configure script using Bash, generate one using Autoconf, or if you are a little less old fashioned use CMake.
So if you wanted to use an IDE, this IDE needs to be capable of parsing this buildsystem and somehow find out how you configured your project (search paths, defines, etc.) and also make smart changes to this when you configure your project. But as your buildsystem is a literally a turing complete scripting language, this is simply computationally impossible, so long story short, such an IDE can not exist.

MSBuild is an additional alternative to CMake that nowadays is even cross platform.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: RAD IDE
« Reply #11 on: July 10, 2020, 09:48:52 am »
Of course C++ does have method pointers. At work I've even used them a few occasions. :) They are however clumsy to use and nowhere as nice and flexible as method pointers in Object Pascal.

The answer to the second question (needing also the object) could be considered to prove it doesn't ;-)


Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: RAD IDE
« Reply #12 on: July 10, 2020, 01:44:33 pm »
Of course C++ does have method pointers. At work I've even used them a few occasions. :) They are however clumsy to use and nowhere as nice and flexible as method pointers in Object Pascal.

I don't consider that method pointers, but rather a workaround using classical function pointers to make up for this :)

Paul_

  • Full Member
  • ***
  • Posts: 143
Re: RAD IDE
« Reply #13 on: July 10, 2020, 01:47:46 pm »
Ever used MFC? I mean, it's not RAD in the Delphi/Lazarus sense, but it allows you to visually design your GUI and it's relatively easy to add event handlers.

You're right. It's still in VS 2019 and updated. Although it looks like you need a lot of books on winapi, coding could be much easier with modern C++ features.

It's interesting how many concepts MS has tried without clear result.
« Last Edit: July 10, 2020, 02:15:03 pm by Paul_ »

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: RAD IDE
« Reply #14 on: July 10, 2020, 02:35:49 pm »
It's interesting how many concepts MS has tried without clear result.

One of the main things about C++ is, it isn't and never will be a Microsoft language. Most of the things MS does with C++ will never become "mainstream" because a huge chunk of C++ developers (I would even go so far and say most C++ developers) don't target windows (or better, don't explicitly target windows). C++ is very much used in server software, which is predominantly *nix based. A lot of applications are nowadays also build using the LLVM infrastructure, which by design is cross platform, so MS never really got a foot in the door with C++.

If you want to use the WinAPI in the most convinient way possible, you should use .Not. If you want to write interactive GUI applications for Windows, C# is the language for you. Even the C++ CLI interface which allows you to use .Not is not really used by C++ community, because using C++ to write a .Not GUI application is so much more effort than using C# and you don't gain anything from it.
C++ has it's niche in the "bare metal" programming area, servers, game engines, embedded systems, simulations, etc. Everything where you need a good performance and you have to work with complex datastructures.
For most GUI applications performance is not relevant (because the reaction time of the user is orders of magnitude higher than the reaction time of the computer), and even if you need high performance computations, it is usually easier to only write these algorithms in C++ and do all the GUI stuff with another language.

 

TinyPortal © 2005-2018