Hi,
Just wandering if any of you are interested in modernising Pascal which
is looking quite dated when compared to modern languages like Python. I
note free pascal supports a variety of pascal dialects but none of them
are particular modern.
My main gripes with Delphi/pascal is its additional
peter green wrote:
1. Memory management. Delphi is quite incosistent here by allowing
component classes to be auto managed (via their owner) whilst
non-component class have to be manually managed. The best solution I can
think for this is to reference count non-component classes. This should
be
Marco van de Voort wrote:
The best solution I can
think for this is to reference count non-component classes. This should
be safe for TObjects but obviously not for Tcomponent descendants (cf
circular reference problem) so a protected variable could be added to
TObject to specify whether to
Marco van de Voort wrote:
2. For Each. Its in Delphi 2005 and every modern language implements it.
Yeah, and I still wonder why. There is nothing to gain with it.
one less variable to manually declare
Implement something in lazarus that auto-adds the variable to the local var
section. No need
DrDiettrich wrote:
My main gripes with Delphi/pascal is its additional verbosity and
somewhat tedious coding practices which seem superfluous in some cases.
Now I dont mind typing a bit extra to make code cleaner and more legible
but I have a few ideas which would reduce needless typing and
I do need an IDE anyhow for container based GTK2/Gnome2/Glade apps so
maybe I ought to start writing one that implements this.
Why don't you see if you can get this implemented as an add-on in
Lazarus ? You get the rest of the IDE for free.
In the short term yes (although I use delphi 5 under
Jonas Maebe wrote:
On 24 feb 2005, at 13:51, Jamie McCracken wrote:
IMO the best solution for (almost) all of your problems were garbage
collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
well.
GC is very inefficient with memory and current implementations tend to
cost a lot
Sebastian Kaliszewski wrote:
On Thursday 24 February 2005 14:57, Jamie McCracken wrote:
It's *much* faster than reference counting everything. Reference
counting is more or less the slowest garbage collection technique there
is (except if only very few objects have to garbage collected). It also
Sebastian Kaliszewski wrote:
On Thursday 24 February 2005 13:51, Jamie McCracken wrote:
IMO the best solution for (almost) all of your problems were garbage
collection. GC is part of Oberon, and it would fit into .NET/DotGNU as
well.
GC is very inefficient with memory and current implementations
Florian Klaempfl wrote:
Jamie McCracken wrote:
I did wrote GC in C++ itself. So it binds rather well...
not a compacting one then -
Ref. counting isn't compacting either?
Not an issue cause memory allocation is conventional when ref counting.
GCs allocate memory from a managed heap which
DrDiettrich wrote:
Jamie McCracken wrote:
GC is very inefficient with memory and current implementations tend to
cost a lot performance wise too.
I don't see how GC is inefficient with memory?
Reference counting and (mark/sweep) garbage collection have a different
runtime behaviour: Reference
Marco van de Voort wrote:
circular refs should also be done if applicable)
6) Whenever an exception is thrown, wait until its either handled or
fully propagated and then perform some garbage collection. (traverse the
single linked list of all managed objects and for each object check
whether
Marco van de Voort wrote:
a valid/invalid reference without accessing memory that is invalid in the mean
time.
How does a GC do this? It would have the same problem?
A GC manages all memory, local variable allocation inclusive. IOW, the
way a GC does it, is not possible in a mixed environment.
Uberto Barbini wrote:
I also thought immediately what Uberto already said: how do you recognize
a valid/invalid reference without accessing memory that is invalid in the
mean time.
How does a GC do this? It would have the same problem?
A GC dont' try to recognize a valid/invalid reference, it is
Jonas Maebe wrote:
On 28 feb 2005, at 12:26, Jamie McCracken wrote:
FPC uses an platform independent method. The C++ ABI isn't used.
But it could be used on platforms that have a fairly stable and
standardised C++ ABI (windows and Linux mainly). Other platforms can
use the current FPC generic
Some things that will affect executable size include:
1) Over zealous use of inlining (I dont see a command option to
control how much inlining is done)
There is almost none in the rtl.
Doesn't the compiler attempt to inline small functions/methods
automatically as part of its
well thats soemthing you should add to your to do list. Automatic
inlining can deliver a signifcant performance improvement especially
as delphi uses a lot of one line procedures to set property values. A
fucntion call adds quite a bit of overhead (around 10+ clock cycles at
a guess)
But
Hans-Peter Diettrich wrote:
well thats soemthing you should add to your to do list. Automatic
inlining can deliver a signifcant performance improvement especially as
delphi uses a lot of one line procedures to set property values. A
fucntion call adds quite a bit of overhead (around 10+ clock
Jonas Maebe wrote:
On 30 May 2005, at 18:29, Jamie McCracken wrote:
What would be nice is to have a compiler switch which takes say an
8bit value to indicate how many bytes a function must contain in
order to be inlined automatically. That way it is scaleable and so
wont exacerbate
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:04, Jamie McCracken wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#.
In terms of _written_ or in terms of _working_ lines of code? :-
Dont kid yourself - a lot of my
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
MyObject.Create is impossible with classes on the heap. You need to
assign MyObject a pointer but you can't do that from within
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet with any
python programmer that I create any application faster than him :)
You must be a damn fast typer then :)
Ironically python is perhaps the
most popular language on Linux and most of its
Michael Van Canneyt wrote:
However, in general Pascal has poor developer productivity when
compared to modern languages like python and C#. Ironically python is
perhaps the most popular language on Linux and most of its syntax is
derived from object pascal whereas pascal on linux is
Micha Nelissen wrote:
On Thu, 02 Jun 2005 14:22:55 +0100
Jamie McCracken [EMAIL PROTECTED] wrote:
In terms of _written_ or in terms of _working_ lines of code? :-
Dont kid yourself - a lot of my fellow Delphi programmers have dumped it
for C# already so it is really worrying for me
Florian Klaempfl wrote:
If that were the case then yeah it would sux (however pythons
performance is due to bien a bytecode interpreter and dynamic typing
neither of which we need in pascal).
Ref. counting etc. eats time because you need good garbage collection to detect
cycles and other
Vinzent Hoefler wrote:
On Thursday 02 June 2005 13:38, Jamie McCracken wrote:
Florian Klaempfl wrote:
I'am a poor delphi programmer, didn't use it for years, but I bet
with any python programmer that I create any application faster
than him :)
You must be a damn fast typer
Michael Van Canneyt wrote:
I don't consider Ojbect Pascal to be verbose at all, so it's not an
issue for
me...
Well I will typically spend about 25% of my development time with
forward declarations, doing loads of try finaly blocks to free memory
and other things instead of implementing
Micha Nelissen wrote:
I don't understand, why are these forward declarations so evil ?
More code bloat, more typing and they get in the way. They dont give me
anything useful in return.
Garbage collection is largely no issue when using the Owner concept in
TComponent, using
Vinzent Hoefler wrote:
On Thursday 02 June 2005 14:01, Jamie McCracken wrote:
Vinzent Hoefler wrote:
What matters is designing und understanding the code, not writing
it. I spend less than 10% of my time at work in actually _writing_
code, so even if someone can type in his/her code twice
Micha Nelissen wrote:
On Thu, 02 Jun 2005 15:31:51 +0100
Jamie McCracken [EMAIL PROTECTED] wrote:
Micha Nelissen wrote:
I don't understand, why are these forward declarations so evil ?
More code bloat, more typing and they get in the way. They dont give me
anything useful in return
Michael Van Canneyt wrote:
But the compiler needs to check many things:
1. Initialize the S with Nil.
2. Check that S is assigned only once during the lifetime of the
procedure.
This is actually a bigger restriction than you might think,
unless you want to introduce reference
Vinzent Hoefler wrote:
On Thursday 02 June 2005 15:16, Uberto Barbini wrote:
If the goal is this, I'd prefear a way to declare objects
autocreated:
varauto:
strlist: TStringList;
begin
//some stuff
end;
[...]
It could be a problem to pass parameters to the constructor.
Yes,
L505 wrote:
| Yeah I know this sounds like a hybrid Pascal/python but I believe thats
| the way to go - marry Delphi's speed and component framework with less
| verbose python style syntax and you will have the best RAD language ever
| written.
|
You are asking to reinvent python. If I were
Daniël Mantione wrote:
Op Thu, 2 Jun 2005, schreef Jamie McCracken:
Daniël Mantione wrote:
Ok! We'll be happy to assist anyone doing interresting developments with
Free Pascal. Keep in mind though that implementing ideas can take a lot
more time that thinking out ideas.
The Free Pascal
Marc Weustink wrote:
Jamie McCracken wrote:
[snip]
would become under Rad Pascal:
uses
Classes, SysUtils;
TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
inherited Create(AnOwner);
inc (count
Vincent Snijders wrote:
Jamie McCracken wrote:
At the end of the day, if you dont like my new dialect then dont use
it - stick to {$mode objfpc} in your code. I want to offer you a new
dialect that should hopefully make your life easier but if it does not
then fair enough.
Thanks
Hans-Peter Diettrich wrote:
You obviously missed that a compiler does not only consist of scanner
and parser, but that optimizers and code generators also have to be
implemented. For multiple target platforms and CPU's...
The new dialect simply makes the syntax less annoying and verbose - it
Danny Milosavljevic wrote:
you *might* have less overhead using ref count on a tstringlist then
making it a component (if you are creating more than one reference to it
or passing it as a parameter to a function then yes a component would be
more efficient). You also have the problem of what
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
if
...
lol - thats not what I meant. If you want
Michael Van Canneyt wrote:
On Sun, 5 Jun 2005, Jamie McCracken wrote:
Hans-Peter Diettrich wrote:
Not at all; I certainly don't indent them, and I'm a fanatical
indenter.
Agreed. I really can't understand why some people indent like this:
if ...
then
begin
...
end
else
if
...
lol
Daniël Mantione wrote:
Op Sun, 5 Jun 2005, schreef Jamie McCracken:
yes but isn't it fair to say that such developers that require such
structures would be knowledgable enough to make it safe by using weak refs?
What is a weak ref?
Allows you to make a reference without increasing
Michael Van Canneyt wrote:
I suggest you create an external preprocessor, and limit yourself to that.
I don't consider your construct to be Pascal, so I will fight inclusion of it
in the compiler, not even under some {$Mode} construct.
Well all I ask is you wait til I have written it then
42 matches
Mail list logo
