What are we missing?

[engkin]

I don't understand one thing, when you could do similar or better Application in Lazarus why is Python popular?

I am sure you received better answers for this question (did not read the whole thread), but see the following.

Debugger experience is not perfect, true.

Some (All?) functions could be added to GDP using Python, if GDB compiled with Python extension support. I believe the copy of GDB that comes with Lazarus does not have that extension. The guy behind OllyDbg had already released a Windows version of GDB with Python extension. And there is a series of tutorials by the person who added that extension to GDB.

Questions regarding FPC debug information does not get answered here in the forum nor on the mailing list.

[MountainQ]

In the above comments I am still missing a point:
Pyhton is used in data analysis. As far as I know there is no equivalent to the powerful numpy/scipy packages in fpc.
In addition, python is very flexible (e.g. being not a strongly typed language). This can lead to quick-and-not-so-dirty code and is immensely helpful when one still has to try different approaches.
Personally, I use them both (and like them both a lot) yet so far it has always been obvious which language to use.
Best to all.

[Thaddy]

Half of it is in math... (maybe more than half) The other half is in the packages....

I use both Pascal and Python  too, but do not confuse people. It is simply there...

[tatamata]

In the above comments I am still missing a point:
Pyhton is used in data analysis. As far as I know there is no equivalent to the powerful numpy/scipy packages in fpc.
In addition, python is very flexible (e.g. being not a strongly typed language). This can lead to quick-and-not-so-dirty code and is immensely helpful when one still has to try different approaches.
Personally, I use them both (and like them both a lot) yet so far it has always been obvious which language to use.
Best to all.

Exactly! The sexiest thing today is Data Science and Python is THE programming language of data science. What python is missing is RAD tools like Lazarus.
So, let me dream about Lazarus being front-end to python...hm

[snorkel]

when you could do similar or better Application in Lazarus why is Python popular? When you can do more and better in Lazarus?

I use both python & Pascal and though py IDEs often have fewer features or are annoying like KDevelop I encounter too much breakage in Pascal to be content with it. I mean I accept a lil setup work and all, but I dont like unpredictability.

Delphi had a proper dashboard where all paths and binaries could be monitored while Laz lets you goof around with control-files yourself. I mean where is a GUI when you need it?

Huh, what dashboard did Delphi have(are you talking about the debugger)?  And what do you mean goof around with control-files?  Sorry but I don't think I have ever goofed around with control-files when using lazarus to make GUI or console applications.

Also exactly what breakage are you talking about? 

[snorkel]

Python is great for business automation, you can make really decent SSH SFPT/FTP/FTPS servers and client scripts, any kind of text processing etc.
It's not good for GUI development at all though, not sure why anyone would write a GUI in Python that requires Python itself, some GUI framwork like Wxwindows or whatever it's called now or QT, when you can make super kick ass GUI apps with Lazarus with zero dependencies on Windows and minor ones on Linux (QT or GTK).

One thing Python has is a really good SSH library called Paramiko, Lazarus and even Delphi have no good open source SSH/SFTP client and server library.
The best one is from Devart (securebridge) it's not super expensive, but when you need to automate some SFTP upload it's super easy with Python and paramiko.

I like the name Lazarus, but it might be holding things back for adoption in corporate environments, maybe it's time for a new catchy name as it's already been raised from the dead :-)

There used to be lots of great Delphi Developers and I don't really see many of the old names here on the forums, one I do see a lot  is Remy Lebeau.

Maybe we should look at getting more of those great Delphi people involved in the project and all the Delphi component developers to take a look, and speaking of that one thing that would be great is the ability to have packages like Delphi has, i.e. the bpl concept was pretty good.

[piGrimm]

it was/is pretty easy for Delphi to make packages and libraries because Delphi was/is targeting only one kind of processor/OS.
In a multiplatforms world, it is quite impossible, except if some genius people invent a superlinker able to manage multiple assembler objects in many different formats, targeting different CPUs and OSes inside the packages/libraries.
I'm sure that explains why FPC was and is unable to achieve its own "package concept".
packages and libraries are supposed to be distributed as sort of overlays and extensions to main programs and language (plugins). In a multiplatform way, such packages/libraries to be distributed, should contain code and data structures for each supported platform... the main programs, able to read inside such libs/packs, only the desired parts specialy assigned and designed for their CPUs/Oses.
technically it is feasible..., however :
- compiler will lost its speed advantage, compiling sources for each target (lost in comp. passes)
- people already complaining about huge sizes of pascal compiled programs are going to cry to hell with de megasize of the packages/libraries to distribute.
- the only happy people would be those who have the habit to share half/opensourced codes, as they are used to share interfaces to their libraries alongside them, already pre-compiled.

that is why FPC was/is never able to manage packs/libs like Delphi does in it's restricting "windows targeting" world

[piGrimm]

there is another way to achieve crossplatform packages, with Pcode and a sort of Pascal Virtual Machine, like java does BUT half/compiled Pcode is slow compared to native code, needs to implement a "half-recompiler/interpreter" in each main program. So, forget about that LOL... It is not "turbo" concept at all 

[Mr.Madguy]

it was/is pretty easy for Delphi to make packages and libraries because Delphi was/is targeting only one kind of processor/OS.
In a multiplatforms world, it is quite impossible, except if some genius people invent a superlinker able to manage multiple assembler objects in many different formats, targeting different CPUs and OSes inside the packages/libraries.
I'm sure that explains why FPC was and is unable to achieve its own "package concept".
packages and libraries are supposed to be distributed as sort of overlays and extensions to main programs and language (plugins). In a multiplatform way, such packages/libraries to be distributed, should contain code and data structures for each supported platform... the main programs, able to read inside such libs/packs, only the desired parts specialy assigned and designed for their CPUs/Oses.
technically it is feasible..., however :
- compiler will lost its speed advantage, compiling sources for each target (lost in comp. passes)
- people already complaining about huge sizes of pascal compiled programs are going to cry to hell with de megasize of the packages/libraries to distribute.
- the only happy people would be those who have the habit to share half/opensourced codes, as they are used to share interfaces to their libraries alongside them, already pre-compiled.

that is why FPC was/is never able to manage packs/libs like Delphi does in it's restricting "windows targeting" world

Packages are intended to be used to achieve 2 different goals:
1) To distribute components
2) To share the same code between applications/modules to minimize their size

We don't need #1, but we need #2.

[piGrimm]

Packages are intended to be used to achieve 2 different goals:
1) To distribute components
2) To share the same code between applications/modules to minimize their size

We don't need #1, but we need #2.

No need to repeat, Sir!
That's EXACTLY what i did mention about 1), PLUS the major Reason making it feasible BUT quite IMPOSSIBLE without larger compiled files + special linker/reader (new crossplatform executable libs format specific to fpc) + loss of speed advantage =>> crossplatform shared libraries accessing main programS systemS.
about 2) it is already in yer hands for years and years LOL

[Mr.Madguy]

No need to repeat, Sir!
That's EXACTLY what i did mention about 1), PLUS the major Reason making it feasible BUT quite IMPOSSIBLE without larger compiled files + special linker/reader (new crossplatform executable libs format specific to fpc) + loss of speed advantage =>> crossplatform shared libraries accessing main programS systemS.
about 2) it is already in yer hands for years and years LOL

In first case you need pre-compiled packages => all problems, you've mentioned. But in second case packages can simply be compiled on target platform at the same time, your application is compiled. All, that is needed - platform should support some sort of dynamic libraries (such as DLLs and SOs). Native dynamic libraries usually don't support OOP. I.e. if you would want to separate implementation of class to DLL - you wouldn't be able to inherit another class from this one. But that's, what actually needed for VCL/LCL - we need to inherit classes from such VCL/LCL classes, as TComponent, TForm, etc. Therefore such feature should be supported at compiler level. For example, as I understand, Delphi simply separates code to DLLs, that export mangled field/properly/method names from it, such as @TForm@Create$q<something>. That's it. It's not that hard.

Yeah, this solution is universal, but isn't optimal though. Just because sizes of import/export tables themselves are large enough to eliminate any benefits of using packages for small 200-500Kb plug-ins, cuz some mangled method names are extremely long. It would be much better to separate name dictionary to some design-time only file and import/export methods by some IDs or GUIDs instead.

[Thaddy]

One thing Python has is a really good SSH library called Paramiko, Lazarus and even Delphi have no good open source SSH/SFTP client and server library.

Huh? Is that Donald tweeting?

[piGrimm]

@Mr.Madguy
what is the color of a white hat that is white?
just asking LOL, no offense but it seems you enjoy trolling. I don't

[Mr.Madguy]

@Mr.Madguy
what is the color of a white hat that is white?
just asking LOL, no offense but it seems you enjoy trolling. I don't

I guess, you misunderstand, what I mean. Runtime package support - is what I need. They can decrease size of application from 1.5Mb to 340Kb. And neither "super linkers", nor "special library formats" are needed to achieve this goal. It's very simple. We have Unit1, that exports @TMyClass@MyMethod$qi and Unit2 that imports it. Now this two units are simply linked together into single MyApplication.exe. If MyModule.dll also needs Unit1 - it also being linked into it, so we have two copies of the same code. What happens with runtime packages: Unit1 is liked into MyPackage.bpl, that is dll, that exports @TMyClass@MyMethod$qi and both MyApplication.exe and MyModule.dll import this routine dynamically, so Unit1 is shared between them. In case of small Unit1 benefit isn't so big, but in case of whole VCL/LCL it would be very big - 80% size decrease.

[taazz]

@Mr.Madguy
what is the color of a white hat that is white?
just asking LOL, no offense but it seems you enjoy trolling. I don't

I guess, you misunderstand, what I mean. Runtime package support - is what I need. They can decrease size of application from 1.5Mb to 340Kb. And neither "super linkers", nor "special library formats" are needed to achieve this goal. It's very simple. We have Unit1, that exports @TMyClass@MyMethod$qi and Unit2 that imports it. Now this two units are simply linked together into single MyApplication.exe. If MyModule.dll also needs Unit1 - it also being linked into it, so we have two copies of the same code. What happens with runtime packages: Unit1 is liked into MyPackage.bpl, that is dll, that exports @TMyClass@MyMethod$qi and both MyApplication.exe and MyModule.dll import this routine dynamically, so Unit1 is shared between them. In case of small Unit1 benefit isn't so big, but in case of whole VCL/LCL it would be very big - 80% size decrease.

no it will not, the linker will only link in the parts you are using in case of dynamic packages you are forced to share the complete code weather you are using it or not. There might be a decrease in shared size if and only if your application uses all  of the lcl and rtl, otherwise the size you share will go up with dynamic packages not down.