On Thursday, May 14, 2020 at 7:36:52 AM UTC+2, JJ wrote:
> On Wed, 13 May 2020 22:09:07 -0700 (PDT), [email protected] wrote:
> > Implementing a python like language onto of Delphi could be interesting.
>
> Python like? Why only go halfway? Might as well have a Python to Delphi code
> transpiler.
Have to start somewhere.
First test to see if it truely helps, and to see if it becomes popular and well used.
It's also to keep things somewhat simple.
Python has scary complex data structures and such... which might be buggy and maybe lead to bad code design or structures, or maybe I am talking out of my ass, but recently some bad python bugs were found.
It might also takes the fun out of thinking about data structures yourself and implementing them yourself which might even be a better fit.
It is about maintaining delphi as a truely generic purpose language and not transforming it into python-limited-minds-data-structure-ways of doing things.
I like inventing my own data structures in Delphi even though some of them cannot match the power of python then some over take pythons strengths perhaps... but at least it gets the job done the way it should and very reliably.
Do you truely "trust" the python library implementations ?! Also were are they ?
Ofcourse Delphi also has implementations like Tlist or Tlist<generic> or something...
Though usually I develop my own... or maybe learn from some delphi examples or what not...
Usually the delphi provided RTL objects/collections fall short of what I truely needed but they do give a good insight/starting point how something better might be developed.
For me it's purely about the compiler/language itself and not so much the objects/collections/data structures that come with it.
However math functions and other things that are hard like GUI/VCL is appreciated and used.
I don't use fire monkey for now though, does anybody ? Hmm maybe in future... maybe it should be opengl based instead of direct2d or what not. Not sure which one is more stable, opengl does seem somewhat more stable, though I have also seen one app crash situation so far... none are very statisfieing but ok.
Implementing a full blown python to delphi compiler could be a waste of time if python's data structures/RTL is unused by delphi programmers.
I do see PascalCoin using TList<T> and such... it's nice for some quick/lazy code maybe... comes at an expense though but ok.
One benefit of full blown python to delphi compiler could also be using python code in Delphi.
However this is not my requirement.
My requirement is simply developing faster in Delphi. And the long syntax is kinda boring, obstructing and slighty frustrating and taking up a lot of time for things that should be a bit simpler.
Also the viewing could be improved.
So for now for me at least. A small improvement to this is desired and would go a long way to giving delphi a modern look, without losing it's past.
It's fully backwards compatible and if people don't like it they can turn it off and so forth.
So switching back and forth could be very nice... especially when robustness is require for for example heavy-cut&paste operations especially when indentations are different/off then the begin/end method is superior and more robust.
After heavy cut&pasting/editing is done it could be converted back for "easy viewing" mode.
So then one has best of both worlds.
There should be a clear demand for python to delphi full blown compiler.
As long as people don't demand it, it's a waste of time.
I do demand a shorter syntax to save time. I am willing to try it out especially if it can be switch back and forth and saved in original Delphi form... that would be very cool.
This keeps Delphi, Delphi but with a twist: "fast editting mode" and "fast/clear viewing mode".
This would probably turn some heads in the python community too... as WOW look at fancy pancy Delphi all of sudden looking very cool and MODERN and FAST again and at the same time MAINTAIN it's robustness ! =D
Bye,
Skybuck ;) =DDDD
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.