Recent

Author Topic: RAD IDE  (Read 2790 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 10478
Re: RAD IDE
« Reply #15 on: July 10, 2020, 03:18:18 pm »
Well the only logical conclusion of course is that C++ programmers are lazy :-)
Not quite... But they are wasting time because of the language... They have to work harder in fact...
When you ask a question that is actually answered in the documentation, you are either lazy or a moron.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8731
  • FPC developer.
Re: RAD IDE
« Reply #16 on: July 10, 2020, 03:26:16 pm »
Well the only logical conclusion of course is that C++ programmers are lazy :-)
Not quite... But they are wasting time because of the language... They have to work harder in fact...

But something would be visible by now. And as said, even MFC can't touch VCL/LCL.

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: RAD IDE
« Reply #17 on: July 10, 2020, 03:30:38 pm »
Not quite... But they are wasting time because of the language... They have to work harder in fact...
Depends on what you are doing, I often had the point where, while developing with pascal, I wished I was doing this bit in C++ because it would be so much easier. A simple example: HashMaps, std::unordered_map<key, value> works on a binary level for every type out of the box, as well as having specialized implementations for all standard library types like strings. You can also easiely define custom hash functions for your type at your type while you can also have custom hash functions used only for this one map and everywhere else the standard hash is used.

This is something you can't even build in Pascal because FPC generics are much weaker than C++ templates

Paul_

  • Full Member
  • ***
  • Posts: 136
Re: RAD IDE
« Reply #18 on: July 10, 2020, 03:59:26 pm »
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.

Aren't those GUI frameworks like Qt programmed in C++? There is difference between using scripting language for easier work in GUI designer, for styles or whatever while you're still coding in C++ in relatively monolithic structure (but yes, it's already falling apart in contrast of FPC/Lazarus) vs using C# which means second language with different concept. I completely do not understand what has prevented large companies at least from keeping one way.

One of the main things about C++ is, it isn't and never will be a Microsoft language.

Microsoft directly develops C#, they have full control there. It's better? Let's make UI in eeee.. Net.. uhm.... stand.. ee.. .Net Framework? Or newly and partly in .Net Core (which is different from Framework)? Or maybe Mono, UWP, WPF, WTF, Xamarin, Silverlight, ASP.NET/Core/CoreMVC/.. webforms, Entity Framework.. or wait until november there will be new .Net 5.0 which "takes best from all this" except half of the concepts will be forgotten and or implemented again in semi-finished phase at least until new direction. There can be no question that the user just simply starts Visual Studio and just makes an GUI application.

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: RAD IDE
« Reply #19 on: July 10, 2020, 04:39:19 pm »
Aren't those GUI frameworks like Qt programmed in C++? There is difference between using scripting language for easier work in GUI designer, for styles or whatever while you're still coding in C++ in relatively monolithic structure (but yes, it's already falling apart in contrast of FPC/Lazarus) vs using C# which means second language with different concept. I completely do not understand what has prevented large companies at least from keeping one way.
Of the big cross plattform frameworks, QT is written in C++, mainly for C++ (and therefore requires C++ to C wrappers for using in other languages), and GTK as the name (gimp toolkit) was written for gimp, which is a C program, so GTK is written in C.
These have especially been established because you can use them with any other language (for example you can even use GTK with C#). Then there are the platform dependend Frameworks like .Not with .Not Windows Forms and WPF, Java with JavaFx and Apple with Cocoa (Android sure has it's own thing, but I don't know the name about that).

But what these libraries are written in doesn't matter much regarding whats their best usage. .Not is surely internally written in C++, but still C++ is pretty much the worst language to use it. That said, there is QT with the QT creator for C++, which comes pretty close to the type of RAD development we know from Lazarus. You have QTCreator as your IDE, with a pretty WYSIWYG editor, the event system is pretty weird (basically the event function is defined by name, so button1 will always call button1_on_click or something like that, which is really weird), but there are these tools. But as I said, this is not the C++ main niche. And without any demand there is not much development.

One of the main things about C++ is, it isn't and never will be a Microsoft language.

Microsoft directly develops C#, they have full control there. It's better? Let's make UI in eeee.. Net.. uhm.... stand.. ee.. .Net Framework? Or newly and partly in .Net Core (which is different from Framework)? Or maybe Mono, UWP, WPF, WTF, Xamarin, Silverlight, ASP.NET/Core/CoreMVC/.. webforms, Entity Framework.. or wait until november there will be new .Net 5.0 which "takes best from all this" except half of the concepts will be forgotten and or implemented again in semi-finished phase at least until new direction. There can be no question that the user just simply starts Visual Studio and just makes an GUI application.
.Not is basically pretty simple, it started out as the idea: "Lets make Java but better", then the demand for cross platform availability increased (which was first met by mono, which is an open source clone of .Not and had at first nothing to do with MS) they decided to also support this, but as many of .Not features where directly representative of WinAPI features, they couldn't just port .Not, and rather than that put out .Not Core.
WPF was developed in an effort to make "pretty" application development easy by basically having DirectX rendered forms (similar to firemonkey for delphi, even though the reasoning behind it is different) which allows for much more complex graphics. Xamarin is an IDE containing a cross plattform gui framework they bought (before that it was a totally separate project, so not the idea of MS) which now basically is the Mobile version of .Not, ASP.Net is a language, MVC is the micrsoft LibC and entity framework is a framework for Databases. And Silverlight was a mistake.

I mean sure they did a lot of stuff, but Microsoft is a large company, and most of it (except for Silverlight) was a success. I mean if you want to use C# you simply download visual Studio and can start of. You want to have more graphical opportunities (which makes it also more complicated), Simply use WPF. If you want to make an (cross plattform) application that does not requires system API specifics (like GUIs), use .Not Core, if you need a web application, use ASP.Net. You want all of .Not but cross plattform and maybe not by MS, use Mono. You want to create a mobile app, use Xamarin.

Btw, I really don't like .Not, and haven't been following it since 2014 or so, but still I know and understand their Concepts and products

I mean they made it such that a formerly Windows only Java Clone, is now one of the most important Programming languages around. Meanwhile VC++ is still only considered "just another C++ compiler"
« Last Edit: July 10, 2020, 04:41:34 pm by Warfley »

PascalDragon

  • Hero Member
  • *****
  • Posts: 2138
  • Compiler Developer
Re: RAD IDE
« Reply #20 on: July 10, 2020, 04:54:27 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).

Microsoft has a member in the ISO C++ Comittee. Thus they can at least influence decisions even if there are many others who would block approaches that aren't cross platform.

If you want to use the WinAPI in the most convinient way possible, you should use .Not.

Are you calling .Net ".Not" on purpose?

This is something you can't even build in Pascal because FPC generics are much weaker than C++ templates

FPC's generics simply have different design goals than C++'s templates.

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: RAD IDE
« Reply #21 on: July 10, 2020, 05:09:41 pm »
Microsoft has a member in the ISO C++ Comittee. Thus they can at least influence decisions even if there are many others who would block approaches that aren't cross platform.

Sure, and as one of the biggest companies using C++ (I would say the Windows, DirectX, .Not, etc. code base isnt so small), as well as compiler developers I think they can contribute a lot to it, but this was more about their "single handed" approaches where they tried to implement their vision into VisualC++, which never really found tracktion because it is not compatible

Are you calling .Net ".Not" on purpose?
Kinda, I don't even know anymore how and why I started doing it (it was somewhen during the time I was using it extensively) now it just became a habit of mine. But there once where a purpose to it

FPC's generics simply have different design goals than C++'s templates.
Yes, this is pretty much I am saying, different language design allow for different constructs and make different things easier and other things harder. C++ templates are for example turing complete and allows for having complicated logic solved out at compile time which allows for some pretty neat things, but in turn give you horrendous error messages. Different tools fit different jobs.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8731
  • FPC developer.
Re: RAD IDE
« Reply #22 on: July 10, 2020, 06:09:19 pm »
Microsoft has a member in the ISO C++ Comittee. Thus they can at least influence decisions even if there are many others who would block approaches that aren't cross platform.

Sure, and as one of the biggest companies using C++ (I would say the Windows, DirectX, .Not, etc. code base isnt so small), as well as compiler developers I think they can contribute a lot to it, but this was more about their "single handed" approaches where they tried to implement their vision into VisualC++, which never really found tracktion because it is not compatible

I think it simply got no traction because no majority player pushed it. MS was all about VB, and then the focus went to .NET. Apple had various languages (C,Pascal) for Classic MacOS and then went to Objective C and then Swift.

Possibly because they didn't want to deal with the Standards committee for every little thing, or risk being branded Standardsbreakers if they jumped the gun.

So that leaves QT and KDE, and the classic candidate KDevelop.

One could argue QT Creator tried to jump into that gap, the lack of native focus for Desktop apps.
« Last Edit: July 10, 2020, 06:37:13 pm by marcov »

Paul_

  • Full Member
  • ***
  • Posts: 136
Re: RAD IDE
« Reply #23 on: July 10, 2020, 07:10:52 pm »
I mean if you want to use C# you simply download visual Studio and can start of.

Yes, I made .Net Framework library, application and also Windows Forms application, all default templates which are preferably offered. Then I found Core fits better for my purposes. I changed library project for supporting both (interesting) and application into Core. After few months there was on blog post from MS dev: "Hey, whats up, look at newly released Core forms build somehow over XY, which is based on YZ and it "works"!". That was clear choice, I couldn't resist. Of course forms were not compatible.

I wonder if .Net 5.0 is the light at the end of the tunnel where developers leave Framework, Mono and other things and will work on a single C# platform, although the universal cross platform GUI is still not happening. If C++ needs C# for forms, then C# needs what?

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: RAD IDE
« Reply #24 on: July 10, 2020, 08:13:45 pm »
Cross plattform GUI applications are not trivial.

If you want to do it native, like Lazarus tries to do, you need to support many different APIs that might not be that compatible (just look at the Cocoa LCL implementation). Also this effectively means that you (considering you want to support GTK, QT, WinAPI and Cocoa) need to support 4 different projects. I mean look at Lazarus as an example, it handles it really great, but still GTK2 is fully supported, but the framework is pretty much dead (I think even XFCE is switching from GTK 2 to 3), but GTK3 is still a WIP while GTK 4 release is already on the horizon. QT 4 and QT 5 and Windows forms are fully supported, and while I haven't used lazarus on OSX for a while, back then Cocoa was nearly not usable, and from what I have seen so far, it still has some quirks that inhibit full LCL compatibility. And support for Mobile Plattforms is AFAIK nearly not existent (using LCL forms)

The other option is to draw it yourself like Firemonkey or Java, which works, but does not feel native (you can nearly always tell if something is a java application).

But the question is, why bother if such things already exist? I mean you can use GTK# the GTK wrapper for .Not (and Core). And basically let the GTK team figure out how to make this cross plattform available (which they seem to do pretty well). AFAIK the Xamarin.Forms designer can also work with them, giving you all the RAD tools you know and love for cross plattform GUI developmen.

Quote
If C++ needs C# for forms, then C# needs what?
C++ does not need C# for Forms, it needs a Framework, this could either be .Not, QT, WxWidgets, GTK, whatever. There are a lot of such tools available, but, as I said, they don't have so much traction because C++ is simply not used for RAD GUI development.
Similarly, if you take a python programmer, he probably never wrote a single GUI in Python, on the other hand, a Swift programmer probably only writes GUI applications.
I mean not everyone needs to write GUIs, and tools are chosen to fit the problem, there is no tool that fits every problem. I for example haven't written a GUI application in the past 2 years, similarly my usage of Pascal and Lazarus has declined in the past 2 years, because other tools simply fitted better (for example I use a lot of python for small computational scripts like statistics). If I had to write a GUI application, C++ would be one of the last languages I would use, while when writing for my avr, it's pretty much my goto language.

fcu

  • Jr. Member
  • **
  • Posts: 64
Re: RAD IDE
« Reply #25 on: July 10, 2020, 10:57:46 pm »
i've been using wxwidgets for a while , it has many nice features (its docking feature is much better than lazarus ),
of course you would write more code than lazarus but this is not a problem .
about database there is many frameworks (e.g SOCI) which could be integrated with wxwidgets , but alot of code is required ;)     

Thaddy

  • Hero Member
  • *****
  • Posts: 10478
Re: RAD IDE
« Reply #26 on: July 10, 2020, 11:07:14 pm »
This is something you can't even build in Pascal because FPC generics are much weaker than C++ templates
Weaker? Do you work in teams? It is a headache working with C++ templates, just because there is too much freedom. This is just a slight remark  from someone who knows both languages inside out.
Yes, ++ is a template, probably... :D ;D >:(
« Last Edit: July 10, 2020, 11:13:31 pm by Thaddy »
When you ask a question that is actually answered in the documentation, you are either lazy or a moron.

Warfley

  • Sr. Member
  • ****
  • Posts: 303
Re: RAD IDE
« Reply #27 on: July 11, 2020, 03:44:20 am »
Weaker? Do you work in teams? It is a headache working with C++ templates, just because there is too much freedom. This is just a slight remark  from someone who knows both languages inside out.
Yes, ++ is a template, probably... :D ;D >:(
Yes weaker, in the language theorethical sense pascal generics have much weaker expressive capabilities.

This is not ment to judge them, its just a fact that c++ templates are much more expressive

But if would judge them, I must confess that fpc generics drive me absolutely mad, they have a tone of weird limitations, and even if you circumvent all of them you will simply recieve fpc internal error xxx or "fpc raised an internal exception", which of you are lucky is gone when making a clean build and if zou are unluck completely stop you from implementing your idea (and of course thin only happens in complicated code so you cant create a minimal working example with less than 4k lines of code)...
This gets a little off topic, but ive founs that generics for anything other then simple things sucg as containers or calling static functions, are basically completely unusable. If you have something more complex (so at around 10-15 generic classes being interconnected) you will either run into fpcs limitations (the design) or into a bug in fpc, whicg you cant report because your minimal working example is a whole project of several thousands od lines, where removing obly one function makes the bug disappear
« Last Edit: July 11, 2020, 04:22:34 am by Warfley »

PascalDragon

  • Hero Member
  • *****
  • Posts: 2138
  • Compiler Developer
Re: RAD IDE
« Reply #28 on: July 11, 2020, 11:16:45 am »
Are you calling .Net ".Not" on purpose?
Kinda, I don't even know anymore how and why I started doing it (it was somewhen during the time I was using it extensively) now it just became a habit of mine. But there once where a purpose to it

May I please ask you to refrain from doing that at least on this forum? In my opinion that is just as childish as calling Microsoft "M$" or (in German) people calling "Windows" "Windoof" ("doof" = "stupid").

But if would judge them, I must confess that fpc generics drive me absolutely mad, they have a tone of weird limitations, and even if you circumvent all of them you will simply recieve fpc internal error xxx or "fpc raised an internal exception", which of you are lucky is gone when making a clean build and if zou are unluck completely stop you from implementing your idea (and of course thin only happens in complicated code so you cant create a minimal working example with less than 4k lines of code)...
This gets a little off topic, but ive founs that generics for anything other then simple things sucg as containers or calling static functions, are basically completely unusable. If you have something more complex (so at around 10-15 generic classes being interconnected) you will either run into fpcs limitations (the design) or into a bug in fpc, whicg you cant report because your minimal working example is a whole project of several thousands od lines, where removing obly one function makes the bug disappear

Generics are both a rather complex feature and a work in progress feature. There's bound to be problems. I try to solve them as good as I can, but there's only so much I can do (and then there's also Delphi compatibility I need to pay attention to). Right now for example I'm trying to solve one problem and it turns out that I need to solve a bunch of others at the same time to keep everything working...  %)

 

TinyPortal © 2005-2018