Re: [fpc-devel] type discussion
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? :-> Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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 fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland being virtually bankrupt. Delphi as it is faces a bleak future so its looking increasingly like its time to modernise or die. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On 2 jun 2005, at 15:22, Jamie McCracken wrote: Dont kid yourself - a lot of my fellow Delphi programmers have dumped it for C# already so it is really worrying for me espcially with borland being virtually bankrupt. Delphi as it is faces a bleak future so its looking increasingly like its time to modernise or die. And do you think they dumped Delphi because Borland is virtually bankrupt and is basically only trying to become yet another .Net platform, or because they think they are so much more productive with the C# *syntax* ? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 13:22, Jamie McCracken wrote: > 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 fellow Delphi programmers have dumped > it for C# already so it is really worrying for me espcially with > borland being virtually bankrupt. Delphi as it is faces a bleak > future so its looking increasingly like its time to modernise or die. Yeah. Flies. Shit. They keep telling me the same about Ada. Still, I am much more productive than any of my fellow programmers who are doing things in C, Java, or Python. While they are still debugging and chasing NullPointerExceptions and such stuff, I already implemented the next needed feature. I can't even remember when was the last time I actually needed a debugger. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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 espcially with borland C# is very much like delphi, not at all like Python. What were their reasons to switch ? Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call "TStringList.Create" on the object pointed to by the mystrings variable. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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? :-> Both in fact as they are directly correlated. The studies show that in high level languages (C nothwithstanding) there is very evident but simple correlation -- number of programmer errors per language construct (typically in not obfuscated code it's very close to the number of not empty & non comment source lines) is independent of the language. But languages do differ significantly wrt. how many constructs are required to solve particular programming problems. C++ (pre stl) was worst there, Python, Perl & likes were the best, Java was not that bad but still about 30% worse thatn Python (C++ was 100% i.e 2x worse). The biggest boost to effectivanes was bring by introducing automated memory management (i.e. getting rid of explicit memory freeing). So even languages with ugly C-ish syntax like "Perl the awful" can beat otherwise elegant & clean languages. Hence probably the greaytest impact on Objective Pascal productioveness would come from allowing programmers to declare classes like self managing (self freeing, not needeing explicit destructions). rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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 espcially with borland C# is very much like delphi, not at all like Python. What were their reasons to switch ? Because its so close to Delphi and they have switched because they found it more productive. No forward declarations, garbage collection and a richer framework has made them switch to the dark side. We need to fight back! Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). not true because of the indenting (use bigger indents!). Im not saying python is great I just envy *some* of its shorter syntax and it would be so cool if Delphi/pascal did likewise - we could blow all these inferior languages away. I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call "TStringList.Create" on the object pointed to by the mystrings variable. Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 02 Jun 2005 14:52:13 +0100 Jamie McCracken <[EMAIL PROTECTED]> wrote: > > C# is very much like delphi, not at all like Python. What were their > > reasons to switch ? > > Because its so close to Delphi and they have switched because they > found it more productive. No forward declarations, garbage collection I don't understand, why are these forward declarations so evil ? Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. > and a richer framework has made them switch to the dark side. We need > to fight back! Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). > > Python is hard to read, especially if multiple blocks are closed at > > once, then it's hard to see what block a line belongs to (because of > > missing 'end' or '}'). > > not true because of the indenting (use bigger indents!). Im not saying Bigger indents cause the text to go too wide. More functions also help, I agree. > python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? > > I also don't like the magic. For example the 'mystrings.create;' > > example you mentioned, it's *totally* not consistent with regular > > syntax: mystrings.create means call "TStringList.Create" on the > > object pointed to by the mystrings variable. > > Well pascal in the only mainstream langugae that does that - I dont > see the pont and it aint magic. Sorry, the only language that does what ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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 TObjectList, etc. True and thats why I suggested ref counting Tobjects only so that no manual memory management is required. I tend to make heavy use of TList, Tstringlist and TFilestream objects so I cant do everything with tcomponents alas. and a richer framework has made them switch to the dark side. We need to fight back! Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). Python is hard to read, especially if multiple blocks are closed at once, then it's hard to see what block a line belongs to (because of missing 'end' or '}'). not true because of the indenting (use bigger indents!). Im not saying Bigger indents cause the text to go too wide. More functions also help, I agree. python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? Well typing begin..end all over the place isn't a lot of fun :( Especially as Im gonna have to indent them as well just to make em readable. So yeah it seems they are more pointless syntax bloat. I also don't like the magic. For example the 'mystrings.create;' example you mentioned, it's *totally* not consistent with regular syntax: mystrings.create means call "TStringList.Create" on the object pointed to by the mystrings variable. Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? For 2 reasons: First, with strlist.create; It is not clear whether strlist is already initialized or not; there is no way it can now this. strlist := Tstringlist.create; makes this explicitly clear. Second, with strlist.create; It is not clear from reading whether create is a constructor or not. Create() is just a convention, which you can decide to ignore. Here again, with strlist := TStringlist.create; Create MUST be a constructor, since you are initializing the variable. Look at other languages: VB, PHP, Perl, Python. They all require the use of the 'new' (or a variant thereof) keyword when the constructor must be called: strlist = new tstringlist; Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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. Please show me a piece of code where they are "in the way". Code bloat? They don't cost anything in the executable. > >>python is great I just envy *some* of its shorter syntax and it would > > > > Ok, some, but not this one ? > > Well typing begin..end all over the place isn't a lot of fun :( Have you done maintenance yet of other people's code ? > Especially as Im gonna have to indent them as well just to make em > readable. So yeah it seems they are more pointless syntax bloat. They are not pointless to me: they indicate clear structure, but we may simply differ in opinion here. > > Sorry, the only language that does what ? > > var strlist : TStringlist; > strlist := Tstringlist.create; > > I know strlist is a Tstringlist, the compiler knows it too as I have > declared it so why do I have to spell it out in the creation process? In C++: TStringList strlist; strlist = new TStringList; How is that shorter ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: > 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? :-> > > Both in fact as they are directly correlated. No, they aren't (or let me put it this way: It depends on what you measure). For instance, studies indicate that there are ten times more errors code in C code then in Ada code once you've delivered the software. > The studies show that in high level languages (C nothwithstanding) > there is very evident but simple correlation -- number of programmer > errors per language construct (typically in not obfuscated code it's > very close to the number of not empty & non comment source lines) is > independent of the language. You must have read different studies. :) A while ago Lockheed Martin switched to SPARK code (which is a statically proven version of Ada) and they claimed this saved them about 80% of development cost compared with former projects of the same size (and we're talking about a flight control system of five million lines of code here). > C++ (pre stl) was worst there, Python, Perl & likes were the best, > Java was not that bad but still about 30% worse thatn Python (C++ was > 100% i.e 2x worse). What did they actually measure? Which languages did they compare. The list above is all (except Python) more or less C-ish or even worse syntax. > The biggest boost to effectivanes was bring by > introducing automated memory management (i.e. getting rid of explicit > memory freeing). Which is something you definitely don't want in large scale realtime systems. > So even languages with ugly C-ish syntax like "Perl > the awful" can beat otherwise elegant & clean languages. Of course they can under certain circumstances. Just as a bubble sort can beat a quick sort algorithm if you feed the "right" input. > Hence > probably the greaytest impact on Objective Pascal productioveness > would come from allowing programmers to declare classes like self > managing (self freeing, not needeing explicit destructions). Maybe, yes. But I'm old school. I like to handle memory myself. And I still need less than 2 MB while a Java VM is still loading its 100 MB foot print into memory. ;-> Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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. Please show me a piece of code where they are "in the way". Code bloat? They don't cost anything in the executable. thats not what I meant! I mean its source code bloat to me especially when trying to follow code with large classes in it. python is great I just envy *some* of its shorter syntax and it would Ok, some, but not this one ? Well typing begin..end all over the place isn't a lot of fun :( Have you done maintenance yet of other people's code ? Especially as Im gonna have to indent them as well just to make em readable. So yeah it seems they are more pointless syntax bloat. They are not pointless to me: they indicate clear structure, but we may simply differ in opinion here. But its the indenting that gives the structure. If i used begin end blocks without indenting there would be no clear structure - it would be a mess! Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? In C++: TStringList strlist; strlist = new TStringList; How is that shorter ? okay but its still redundant. Why does the compiler need to have it spelt out twice? Why cant the compiler deduce that as the pointer is declared as TStringlist therefore it creates a TStringList? jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 02 Jun 2005 15:54:54 +0200 Sebastian Kaliszewski <[EMAIL PROTECTED]> wrote: > The studies show that in high level languages (C nothwithstanding) there is > very evident but simple correlation -- number of programmer errors per > language construct (typically in not obfuscated code it's very close to the > number of not empty & non comment source lines) is independent of the > language. But languages do differ significantly wrt. how many constructs are > required to solve particular programming problems. A correlation of things that are independent ? Then there is no correlation ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] type discussion
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jamie McCracken Sent: donderdag 2 juni 2005 16:32 >var strlist : TStringlist; >strlist := Tstringlist.create; > >I know strlist is a Tstringlist, the compiler knows it too as I have >declared it so why do I have to spell it out in the creation process? What to do with virtual constructors or variables of a lower class ? ie. var strlist: TStrings; strlist := Tstringlist.create; or var strlist: TStrings; listclass: TStringsClass; listclass := TStringlist; strlist := listclass.create; Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 17:07, Marc Weustink wrote: > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jamie > McCracken > Sent: donderdag 2 juni 2005 16:32 > > >var strlist : TStringlist; > >strlist := Tstringlist.create; If the goal is this, I'd prefear a way to declare objects autocreated: varauto: strlist: TStringList; begin //some stuff end; which wil be auto-magically compiled as var: strlist: TStringList; begin strlist := TStringList.Create; try //some stuff finally strlist.Free; end; end; It could be a problem to pass parameters to the constructor. Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
> >>>Sorry, the only language that does what ? > >> > >>var strlist : TStringlist; > >>strlist := Tstringlist.create; > >> > >>I know strlist is a Tstringlist, the compiler knows it too as I have > >>declared it so why do I have to spell it out in the creation process? > > > > In C++: > > > > TStringList strlist; > > > > strlist = new TStringList; > > > > How is that shorter ? > > okay but its still redundant. Why does the compiler need to have it > spelt out twice? Why cant the compiler deduce that as the pointer is > declared as TStringlist therefore it creates a TStringList? Because the pointer might not be. Polymorphism, you know? :-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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, exactly. So why bother the extra complexity? You still need the "real thing", so for consistency it's better to stay with it only. Something like this you can see in Java: In the constructor of a derived class you always need to call the constructor of the base class in the first place. So, to "simplify" the task, the compiler does the magic for you, if there is a "default" constructor that has no parameters. Great. But the virtually same code just does not compile when there is no such thing as a parameterless constructor and you keep asking you why it does not f***ing compile. Until you read the 500 pages of the JLS and then *know* that the compiler does stupidly magic tricks for you. It can even become much more confusing if you have more than a single constructor. I don't think, this makes anything easier, less error-prone, whatever. It just confuses people. Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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, exactly. So why bother the extra complexity? You still need the "real thing", so for consistency it's better to stay with it only. Thats why I proposed a month back in my modernising pascal thread to implement things like a stringlist as a base type container (like pyhton does with lists, dicts etc). This would then be dynamically allocated and ref counted. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Vinzent Hoefler wrote: On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: No, they aren't (or let me put it this way: It depends on what you measure). For instance, studies indicate that there are ten times more errors code in C code then in Ada code once you've delivered the software. If you didn't notice I wrote "C nothwithstanding". C is far away from modern high level languages (and also many older than it but hight level languages). The studies show that in high level languages (C nothwithstanding) there is very evident but simple correlation -- number of programmer errors per language construct (typically in not obfuscated code it's very close to the number of not empty & non comment source lines) is independent of the language. You must have read different studies. :) Certainly. Those I read were about mainsteream software development not niche life critical realitime systems. The study was measuring error rate in some typical and rather simple prgramming task coded in varius languages by varius programmers. Correlation found was clear -- number of bugs per 1kloc were constatant and independent of the language. The difference was that the same task could be coded in some languages using significantly lesser number of lines. A while ago Lockheed Martin switched to SPARK code (which is a statically proven version of Ada) and they claimed this saved them about 80% of development cost compared with former projects of the same size (and we're talking about a flight control system of five million lines of code here). Two things: 1. They'd better claim they got significant gains or someone should be fired for wasting money. IOW I take all such corporation made studies not with a grain but with a shuffle of salt. 2. You're talking about complex life-critical realtime system, not mainstream software. In such system the cost of bugs is many orders of magnitude higher than in mainstream. Cost structure of such projectes differs stronly from mainstream programming. C++ (pre stl) was worst there, Python, Perl & likes were the best, Java was not that bad but still about 30% worse thatn Python (C++ was 100% i.e 2x worse). What did they actually measure? Which languages did they compare. The list above is all (except Python) more or less C-ish or even worse syntax. There was a bunch of popular languages (don't remember them all), C like were C++, Java & Perl. Others certainly were not. The biggest boost to effectivanes was bring by introducing automated memory management (i.e. getting rid of explicit memory freeing). Which is something you definitely don't want in large scale realtime systems. But FPC is useless in such systems as well. Besides lack of convincing argumentation about compiler correctness, you need real time guarantees wrt allocations and other library stuff (which FPC does not provide). So even languages with ugly C-ish syntax like "Perl the awful" can beat otherwise elegant & clean languages. Of course they can under certain circumstances. Just as a bubble sort can beat a quick sort algorithm if you feed the "right" input. If you'd use not the "naive" version of Qsort, but something more elaborate then you'd have to caerefully craft contrived input to cause it to work badly. But naive Qsort will work terribly on really common input. Those examples were real code not some contrived stuff. Hence probably the greaytest impact on Objective Pascal productioveness would come from allowing programmers to declare classes like self managing (self freeing, not needeing explicit destructions). Maybe, yes. But I'm old school. I like to handle memory myself. Well, I met some people who needed 'full controll' so they wnated to code in assembly. And I still need less than 2 MB while a Java VM is still loading its 100 MB foot print into memory. ;-> Java is a different story, but GC overhead is not that bad in some better languages (2-3x). And performance seems to be unaffected: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=fpascal&lang2=ocaml&sort=fullcpu Here comes Pascal (FPC) vs Ocaml (hybrid functional/imperative language with OO). Ocaml is significantly faster although it havily uses GC. Ocaml code is significantly shorter too (they can be coded in significanly lesser amount of lines). rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=fpascal&lang2=ocaml&sort=fullcpu Here comes Pascal (FPC) vs Ocaml (hybrid functional/imperative language with OO). Ocaml is significantly faster although it havily uses GC. Ocaml code is significantly shorter too (they can be coded in significanly lesser amount of lines). rgds Those tests are flawed. I just submitted some improvements to the pascal code. Look at objects for example. The author of that benchmark forgot to .free those classes. C++ for example uses static classes and inlines. So that's for the "comparison". Don't trust those benchmarks, most are just a load of bullshit. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
> On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: > > probably the greaytest impact on Objective Pascal productioveness > > would come from allowing programmers to declare classes like self > > managing (self freeing, not needeing explicit destructions). > > Maybe, yes. But I'm old school. I like to handle memory myself. And I > still need less than 2 MB while a Java VM is still loading its 100 MB > foot print into memory. ;-> I think the time spent doing the manual compilation is overestimated, and the time problem solving in automatic allocation is underestimated. How many Java programmers routine set references to NIL ? Really a lot... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thu, 2 Jun 2005, Ales Katona wrote: > > > > > http://shootout.alioth.debian.org/benchmark.php?test=all&lang=fpascal&lang2=ocaml&sort=fullcpu > > > > > > > > Here comes Pascal (FPC) vs Ocaml (hybrid functional/imperative language > > with OO). Ocaml is significantly faster although it havily uses GC. Ocaml > > code is significantly shorter too (they can be coded in significanly > > lesser amount of lines). > > > > rgds > > Those tests are flawed. I just submitted some improvements to the pascal code. > Look at objects for example. The author of that benchmark forgot to .free > those classes. C++ for example uses static classes and inlines. So that's for > the "comparison". > > Don't trust those benchmarks, most are just a load of bullshit. Indeed. The code submitted for pascal made my hair grey on the spot !! Obviously we're not going to score high with flawed code in the benchmarks... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Marco van de Voort wrote: I think the time spent doing the manual compilation is overestimated, and the time problem solving in automatic allocation is underestimated. How many Java programmers routine set references to NIL ? Really a lot... This only shows the implementation (and std library design) is bad (and that's true at least to java 1.4) rgds -- Sebastian Kaliszewski ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
> The difference was that the same task could be coded in some languages > using significantly lesser number of lines. But that doesn't necessarily equal to less overall time. Also specially the size of the testing code pieces. The troubles typically only start when the program grows larger. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
> Marco van de Voort wrote: > > I think the time spent doing the manual compilation is overestimated, and > > the time problem solving in automatic allocation is underestimated. > > > > How many Java programmers routine set references to NIL ? Really a lot... > > This only shows the implementation (and std library design) is bad (and > that's true at least to java 1.4) I hear this from nearly any language with automated allocation (C#, Python, Perl, Java). The concept is simple and attractive, the practice seems to be different. At least if you go about it the trial-and-error way. With careful design and consideration can be brought down. However then also go most of the time advantages. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
> > This only shows the implementation (and std library design) is bad (and > > that's true at least to java 1.4) > > I hear this from nearly any language with automated allocation (C#, Python, > Perl, Java). The concept is simple and attractive, the practice seems to > be different. I'm not a grear fan of them, but managed objects are indeed very useful for modelling business applications. But they don't make sense for "system" classes, so all in all I'm against them. Some OPF like InstantObjects offer a kinda of them, and I think this is a good compromize. Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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? :-> Can't stop refraining that fact ;-) > Dont kid yourself - a lot of my fellow Delphi programmers have dumped it > for C# already so it is really worrying for me espcially with borland > being virtually bankrupt. Delphi as it is faces a bleak future so its > looking increasingly like its time to modernise or die. The attractivity of C# is a hype, and the current lack of able programmers. The more complicated and error prone a language is, the more programmers are required to make little bits work. This is why I moved from Atari ST to MS-DOS and Windows, because there I could earn more money with less efforts. The .NET thing and the # languages may vanish in a few years, condemned to live forever as zombies in the underground, like COBOL does :-( The problem with perfect products is, that they cannot be improved any more. Even if Delphi is far from being perfect, it cannot overcome some bad inheritance from earlier language versions, and the elimination of the remaining bugs costs more than the users are willing to pay for. In so far it has reached a dead end, as a Windows specific development system. But it still has a chance, when the next Delphi.NET version will break backwards compatibility, and restarts with a better language design, combining the goodies of Pascal, Modula, Oberon etc. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
| More code bloat, more typing and they get in the way. They dont give me | anything useful in return. Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | | > Garbage collection is largely no issue when using the Owner concept in TComponent, using TObjectList, etc. | | True and thats why I suggested ref counting Tobjects only so that no | manual memory management is required. I tend to make heavy use of TList, | Tstringlist and TFilestream objects so I cant do everything with | tcomponents alas. | | > | >>and a richer framework has made them switch to the dark side. We need | >>to fight back! | > | > | > Ok, but richer framework simply needs people adding packages and useful units to freepascal :-). | > | > | >>>Python is hard to read, especially if multiple blocks are closed at | >>>once, then it's hard to see what block a line belongs to (because of | >>>missing 'end' or '}'). | >> | >>not true because of the indenting (use bigger indents!). Im not saying | > | > | > Bigger indents cause the text to go too wide. More functions also help, I agree. | > | > | >>python is great I just envy *some* of its shorter syntax and it would | > | > | > Ok, some, but not this one ? | | Well typing begin..end all over the place isn't a lot of fun :( Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | Especially as Im gonna have to indent them as well just to make em | readable. So yeah it seems they are more pointless syntax bloat. | Why do you even bother using Pascal, it seems you obviously do not like one bit about it. | | >>>I also don't like the magic. For example the 'mystrings.create;' | >>>example you mentioned, it's *totally* not consistent with regular | >>>syntax: mystrings.create means call "TStringList.Create" on the | >>>object pointed to by the mystrings variable. | >> | >>Well Pascal in the only mainstream langugae that does that - I dont | >>see the pont and it aint magic. | > | > | > Sorry, the only language that does what ? | | var strlist : TStringlist; | strlist := Tstringlist.create; | | I know strlist is a Tstringlist, the compiler knows it too as I have | declared it so why do I have to spell it out in the creation process? Why do you even bother using Pascal, it seems you obviously do not like one bit about it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
| > In C++: | > | > TStringList strlist; | > | > strlist = new TStringList; | > | > How is that shorter ? | | okay but its still redundant. Why does the compiler need to have it | spelt out twice? Why cant the compiler deduce that as the pointer is | declared as TStringlist therefore it creates a TStringList? | | Why can't I just go strlist = new Draw the line. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 21:28, L505 wrote: > | > In C++: > | > > | > TStringList strlist; > | > > | > strlist = new TStringList; > | > > | > How is that shorter ? > | > | okay but its still redundant. Why does the compiler need to have it > | spelt out twice? Why cant the compiler deduce that as the pointer is > | declared as TStringlist therefore it creates a TStringList? > > Why can't I just go > > strlist = new > > Draw the line. (and you can, in several script languages) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol := means "assign to", += means "add to" etc., I cannot find any inconsistency here. Also, += and such were created to make it easier to convert C code. If you change this to +:= you do essentially two things: 1) Break existing code 2) Destroy any of the original purpose and usefulness of the thing in question. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
And do you think they dumped Delphi because Borland is virtually bankrupt and is basically only trying to become yet another .Net platform, or because they think they are so much more productive with the C# *syntax* ? No, of course they're using it because Microsoft said so ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Jamie McCracken 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. > > > > > > Please show me a piece of code where they are "in the way". Code bloat? > > They don't cost anything in the executable. > > thats not what I meant! I mean its source code bloat to me especially > when trying to follow code with large classes in it. I typically follow code by jumping to the definition of variables or subroutines, and back again. I rarely read source code sequentially, because the static arrangement of code pieces is different from their logical relationship. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Well pascal in the only mainstream langugae that does that - I dont see the pont and it aint magic. Jamie, now I KNOW I don't understand where you're coming from Pascal? Mainstream? ;) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
On Thursday 02 June 2005 15:53, Sebastian Kaliszewski wrote: > Vinzent Hoefler wrote: > > On Thursday 02 June 2005 13:54, Sebastian Kaliszewski wrote: > > > > No, they aren't (or let me put it this way: It depends on what you > > measure). For instance, studies indicate that there are ten times > > more errors code in C code then in Ada code once you've delivered > > the software. > > If you didn't notice I wrote "C nothwithstanding". C is far away from > modern high level languages (and also many older than it but hight > level languages). It's not much worse than C++ in typical projects (which has, I admit, much to do with the people using it). > >>The studies show that in high level languages (C nothwithstanding) > >>there is very evident but simple correlation -- number of > >> programmer errors per language construct (typically in not > >> obfuscated code it's very close to the number of not empty & non > >> comment source lines) is independent of the language. > > > > You must have read different studies. :) > > Certainly. Those I read were about mainsteream software development > not niche life critical realitime systems. You know that about 90% of all installed computer(chip)s are actually embedded systems? So I'd consider this "mainstream software" a niche. :-) > The study was measuring > error rate in some typical and rather simple prgramming task coded in > varius languages by varius programmers. Correlation found was clear > -- number of bugs per 1kloc were constatant What figures did they give? I'm curious. > and independent of the > language. The difference was that the same task could be coded in > some languages using significantly lesser number of lines. Which is quite irrelevant once you've got to maintain it. > Two things: > 1. They'd better claim they got significant gains or someone should > be fired for wasting money. IOW I take all such corporation made > studies not with a grain but with a shuffle of salt. Even the salt doesn't taste away the fact that they were on-time, on-budget and testing the software more or less deviated to simply showing that it works. And considering that most money is spend in the testing phase (well, of course, especially in that particular domain), the 80% aren't that surprising after all. > 2. You're talking about complex life-critical realtime system, not > mainstream software. Yes, true. Funny thing is, that those companies are now almost able to deliver software cheaper than the mainstream. If they would cut the testing completely, they definitely could and the software wouldn't even be as worse. (BTW, that's my own observation, not some study.) > In such system the cost of bugs is many orders > of magnitude higher than in mainstream. Cost structure of such > projectes differs stronly from mainstream programming. Yes. The main costs goes into testing. Which, in main stream software, is done by the customer and he even pays for the bugfix called upgrade. So, of course, testing is a bad thing. You can earn less money with it and it even costs you. Is that what you're trying to tell me? > >>C++ (pre stl) was worst there, Python, Perl & likes were the best, > >>Java was not that bad but still about 30% worse thatn Python (C++ > >> was 100% i.e 2x worse). > > > > What did they actually measure? I'd guess, in that test, languages like Pascal or Ada would get an even worse rating than C. Because these are languages that focus on design and doing it right instead of focusing on doing it fast. Which, in practice, means you get compilabe code much later, but in the end this code is more likely to be correct. So it all depends on what you measure. > > Which languages did they compare. > > The list above is all (except Python) more or less C-ish or even > > worse syntax. > > There was a bunch of popular languages (don't remember them all), C > like were C++, Java & Perl. Others certainly were not. Did they take maintenance into account? (I just ask, because that's what I am being paid for for the last 5 years and I guess, I am not the only one out there who gets paid for this kind of development). > >>The biggest boost to effectivanes was bring by > >>introducing automated memory management (i.e. getting rid of > >> explicit memory freeing). > > > > Which is something you definitely don't want in large scale > > realtime systems. > > But FPC is useless in such systems as well. Not necessarily. > Besides lack of > convincing argumentation about compiler correctness, Realtime doesn't necessarily mean correctness. A while ago I talked to one of the developers working for a electronic company who wrote the code for a television. He told me, that in the final system, there would be about 140 running threads. That's definitely not small scale and judging on how often I had to reboot my Nokia phone by removing the batteries, it doesn't mean correctness either. > you need real > time guarantees wrt allocations and other lib
Re: [fpc-devel] type discussion
Vinzent Hoefler wrote: If you didn't notice I wrote "C nothwithstanding". C is far away from modern high level languages (and also many older than it but hight level languages). It's not much worse than C++ in typical projects (which has, I admit, much to do with the people using it). Of course C is much worse than contemporary C++ (C++ + std::). You must have read different studies. :) Certainly. Those I read were about mainsteream software development not niche life critical realitime systems. You know that about 90% of all installed computer(chip)s are actually embedded systems? So I'd consider this "mainstream software" a niche. :-) Count separate apps not separate instalations. The study was measuring error rate in some typical and rather simple prgramming task coded in varius languages by varius programmers. Correlation found was clear -- number of bugs per 1kloc were constatant What figures did they give? I'm curious. I don't remember. I read the paper over a year ago. and independent of the language. The difference was that the same task could be coded in some languages using significantly lesser number of lines. Which is quite irrelevant once you've got to maintain it. Smaller programs are easier to maitain. Two things: 1. They'd better claim they got significant gains or someone should be fired for wasting money. IOW I take all such corporation made studies not with a grain but with a shuffle of salt. Even the salt doesn't taste away the fact that they were on-time, on-budget This could also be that they simply properly planed for the unknown. You can do most of apps withing time & bugget even in pure machine code if you'll assume huge enough budget and long enough time. [snip] 2. You're talking about complex life-critical realtime system, not mainstream software. Yes, true. Funny thing is, that those companies are now almost able to deliver software cheaper than the mainstream. If they would cut the testing completely, they definitely could and the software wouldn't even be as worse. (BTW, that's my own observation, not some study.) The same functionality? In such system the cost of bugs is many orders of magnitude higher than in mainstream. Cost structure of such projectes differs stronly from mainstream programming. Yes. The main costs goes into testing. Which, in main stream software, is done by the customer and he even pays for the bugfix called upgrade. So, of course, testing is a bad thing. You can earn less money with it and it even costs you. Is that what you're trying to tell me? No. Simply preventing some failure is economically viable if cost_of_failure * probality_of_filure > const_of_prevention. In systems you're talking about const of failure is enormous, so you can spend on prevention till probablity of failure is really, really small. C++ (pre stl) was worst there, Python, Perl & likes were the best, Java was not that bad but still about 30% worse thatn Python (C++ was 100% i.e 2x worse). What did they actually measure? I'd guess, in that test, languages like Pascal or Ada would get an even worse rating than C. Nope. There was enough time to develop the app in all but some ackward joke languages. Problem was simple & well understood. Because these are languages that focus on design and doing it right instead of focusing on doing it fast. All languages require design. Which, in practice, means you get compilabe code much later, but in the end this code is more likely to be correct. So it all depends on what you measure. They measured the number of actual bugs in code declared by the author as ready to deploy. [snip] Besides lack of convincing argumentation about compiler correctness, Realtime doesn't necessarily mean correctness. You were talking about flight control system... A while ago I talked to one of the developers working for a electronic company who wrote the code for a television. He told me, that in the final system, there would be about 140 running threads. That's definitely not small scale and judging on how often I had to reboot my Nokia phone by removing the batteries, it doesn't mean correctness either. And this is example of what? For me it's just sloppy programming. Lot of that Nokia stuff isn't realtime either (it maybe should, but it's not). you need real time guarantees wrt allocations and other library stuff (which FPC does not provide). No. Simple rule: Don't allocate at runtime. If you have fixed amount of data the fine. But if not then it's rather hard. [snip] Java is a different story, but GC overhead is not that bad in some better languages (2-3x). Yeah, right. That's the reality. Just look at properly designed languages, not Java. Java is so but because it uses bloated objects for virtually everything. Want to store few int numbers into a list? You must encapsulate every int into Integer class object. You want to writ
Re: [fpc-devel] type discussion
On Friday 03 June 2005 14:52, Sebastian Kaliszewski wrote: > Vinzent Hoefler wrote: > >>If you didn't notice I wrote "C nothwithstanding". C is far away > >> from modern high level languages (and also many older than it but > >> hight level languages). > > > > It's not much worse than C++ in typical projects (which has, I > > admit, much to do with the people using it). > > Of course C is much worse than contemporary C++ (C++ + std::). Only in theory. Look at typical projects in the industry. > >>>You must have read different studies. :) > >> > >>Certainly. Those I read were about mainsteream software development > >>not niche life critical realitime systems. > > > > You know that about 90% of all installed computer(chip)s are > > actually embedded systems? So I'd consider this "mainstream > > software" a niche. :-) > > Count separate apps not separate instalations. Doesn't change the count much, I think. Every f*cking microwave oven has its own control program these days. > >>The study was measuring > >>error rate in some typical and rather simple prgramming task coded > >> in varius languages by varius programmers. Correlation found was > >> clear -- number of bugs per 1kloc were constatant > > > > What figures did they give? I'm curious. > > I don't remember. I read the paper over a year ago. I'm just asking because somebody from a car company claimed that one bug per 1000 SLOC would be "the normal expected amount" and I got a study here that claims a bug rate of less then a tenth (0.096 defects/KSLOC [and even for their C-Code, they had 0.676 defects/KSLOC]) for "just a compiler and related tools", not for potentially life-critical systems as you'd expect in the 70 or more microprocessors a modern car has built in. Which seems quite surprising considering that the bug rate should be practically independent of the language (ok, this statement is not valid for C99, of course, it's the only exception there). Sarcasm included. > >>and independent of the > >>language. The difference was that the same task could be coded in > >>some languages using significantly lesser number of lines. > > > > Which is quite irrelevant once you've got to maintain it. > > Smaller programs are easier to maitain. Yes, but small programs are not the typical project. Even small projects break through the 100 KSLOC barrier very quick. > >>Two things: > >>1. They'd better claim they got significant gains or someone should > >>be fired for wasting money. IOW I take all such corporation made > >>studies not with a grain but with a shuffle of salt. > > > > Even the salt doesn't taste away the fact that they were on-time, > > on-budget > > This could also be that they simply properly planed for the unknown. Of course they did, they are not bloody id10ts and it was not their first project of this size. It was just the first that was much cheaper than ever expected. > You can do most of apps withing time & bugget even in pure machine > code if you'll assume huge enough budget and long enough time. Considering that it wasn't government money they had to waste, instead they took the risk of the whole development theirselves, this certainly wasn't the case here. > [snip] > > >>2. You're talking about complex life-critical realtime system, not > >>mainstream software. > > > > Yes, true. Funny thing is, that those companies are now almost able > > to deliver software cheaper than the mainstream. If they would cut > > the testing completely, they definitely could and the software > > wouldn't even be as worse. (BTW, that's my own observation, not > > some study.) > > The same functionality? Yes. MULTOS/CA had 0.04 defects per KSLOC with an average "productivity" of 28 lines of code per developer per day, if I remember the figures correctly. > >>In such system the cost of bugs is many orders > >>of magnitude higher than in mainstream. Cost structure of such > >>projectes differs stronly from mainstream programming. > > > > Yes. The main costs goes into testing. Which, in main stream > > software, is done by the customer and he even pays for the bugfix > > called upgrade. So, of course, testing is a bad thing. You can earn > > less money with it and it even costs you. > > > > Is that what you're trying to tell me? > > No. Simply preventing some failure is economically viable if > cost_of_failure * probality_of_filure > const_of_prevention. Yes. But Cost_Of_Failure sometimes seems to be a negative amount while Cost_Of_Prevention never is. > C++ (pre stl) was worst there, Python, Perl & likes were the > best, Java was not that bad but still about 30% worse thatn > Python (C++ was 100% i.e 2x worse). > >>> > >>>What did they actually measure? > > > > I'd guess, in that test, languages like Pascal or Ada would get an > > even worse rating than C. > > Nope. There was enough time to develop the app in all but some > ackward joke languages. Problem was simple & well understood. Yeah. The latter may be
Re: [fpc-devel] type discussion
Jamie McCracken wrote: > > Garbage collection is largely no issue when using the Owner concept in > > TComponent, using TObjectList, etc. > > True and thats why I suggested ref counting Tobjects only so that no > manual memory management is required. I tend to make heavy use of TList, > Tstringlist and TFilestream objects so I cant do everything with > tcomponents alas. What do you mean with "Tobjects"? Isn't TObject the ancestor of all classes? If you mean a dedicated root class for reference counted objects, you can use interface instead of class variables (at least in Delphi, not sure about FPC). As was already pointed out, GC doesn't work well without assistance in actual code. There's no big difference between setting a reference to Nil, and calling the destructor or FreeAndNil, for the same purpose. Auto-destroyed local objects, or local interface references, require hidden try-finally blocks; from similar discussions I know that many people don't like such invisible magics, for performance and othX-Mozilla-Status: 0009 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Hi, Am Samstag, den 04.06.2005, 08:53 +0200 schrieb Hans-Peter Diettrich: > Jamie McCracken wrote: > > > > Garbage collection is largely no issue when using the Owner concept in > > > TComponent, using TObjectList, etc. > > > > True and thats why I suggested ref counting Tobjects only so that no > > manual memory management is required. I tend to make heavy use of TList, > > Tstringlist and TFilestream objects so I cant do everything with > > tcomponents alas. I'd suggest creating tlist, tstringlist, tfilestream-like things with an optional owner (TComponent-like). I've been programming delphi for years, and trust me, I know how annoying keeping track of tlist memory is (and I mean _annoying like [EMAIL PROTECTED] hell_ :)). Of course having to cast around list content is even more annoying. But 'm trying to fix that now, in fpc. > > What do you mean with "Tobjects"? Isn't TObject the ancestor of all > classes? > > If you mean a dedicated root class for reference counted objects, you > can use interface instead of class variables (at least in Delphi, not > sure about FPC). TInterfacedObject works in fpc too. works fine. Using it all the time :) > > As was already pointed out, GC doesn't work well without assistance in > actual code. There's no big difference between setting a reference to > Nil, and calling the destructor or FreeAndNil, for the same purpose. Setting a reference to nil works automagically (user doesnt need to do it). Only remaining serious problem are reference cycles. And thats a BIG problem (see old java versions and swing, and you will see... its the horror). But it still 'only' means you have to set 'some' references to nil manually. Which is ugly. Either all or none would be cleaner :) To offset that danger, I've been trying to get weakref on interfaces to work, but its actually non-trivial to get that to work cleanly without using your own tinterfacedobject everywhere (which is a 'cant do'-like thing when using other people's com objects) ... too bad. What I mean is: type TXyz = class(TInterfacedObject) parent: IWeakref; constructor Create(const parent: IInterface); procedure someCallbackSoIKnowParentIsGone(whereitwas: Pointer); end; constructor TXyz.Create(const parent: IInterface); begin parent := TWeakref.Create(parent); parent.OnDestroy.Add(someCallbackSoIKnowParentIsGone); end; ideas ? > > Auto-destroyed local objects, or local interface references, require > hidden try-finally blocks; from similar discussions I know that many > people don't like such invisible magics, for performance and > oth It always depends on what you are trying to do. If you are building huge systems, you wont care about some hidden try-finally blocks you would have needed at the same places and of the same count regardless. And choice is good, so as long as you can use the old way, who cares. But wait, you already can use both ways (reference counted and non-reference counted). So what's this talk about anyways ? There need to be reference counted list/map/... units ? I know, working on it :) cheers, Danny -- www.keyserver.net key id A334AEA6 signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Danny Milosavljevic wrote: I'd suggest creating tlist, tstringlist, tfilestream-like things with an optional owner (TComponent-like). I've been programming delphi for years, and trust me, I know how annoying keeping track of tlist memory is (and I mean _annoying like [EMAIL PROTECTED] hell_ :)). Of course having to cast around list content is even more annoying. But 'm trying to fix that now, in fpc. 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 you are going to set the owner to in the case where its only a temp variable. Setting a reference to nil works automagically (user doesnt need to do it). Only remaining serious problem are reference cycles. And thats a BIG problem (see old java versions and swing, and you will see... its the horror). But it still 'only' means you have to set 'some' references to nil manually. Which is ugly. Either all or none would be cleaner :) ref cycles are not a big deal - show me one bit of the FCL that has cycles using Tobjects only (IE not with Tcomponents)! Its obvious that you wont have cycles in things like TstringList, TFileStream objects etc. In fact only in Tlist are you likely to have cycles and in the add method you could check to make sure no self references are added and throw an exception if they are. A knowledgable developer can of course set any object to nil if he knows that there are or likely to be cycles but again this will only happen in a very small minoirty of cases. I would implement ref count on TObjects with a protected boolean variable to turn it off for TComponent descendants as we dont need to ref count components and components by their nature are far more likely to have cycles then plain objects. Its also obvious that pascal by its nature is far better suited to efficient ref counting than others like java because java strings are objects and ref counting a whole load of short term objects can adversely affect performance. (imagine deleting a stringlist where all the strings are objects - you would have to call dec_ref on all the strings and thats why ref counting is considered slow especially with java) I am asserting that ref counting in pascal would probably have a much lower effect on overall performance as a result. Ref counting objects with long life spans is actually far more cpu efficient than any GC scheme (and thats why the best performing GCs are hybrid GCs which actually ref count globals and all objects that survive multiple generations). In fact unless you are creating loads of temporary short lived objects in your code, the overhead of ref counting should be acceptable in most cases and of course you can optimise your code for ref counting by using more global vars instead of temps/passing them as parameters to functions etc. But we cant test out any of this until we have c++ style exception handling so its performance or lack of performance is just speculation at the moment. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Hi, Am Samstag, den 04.06.2005, 16:02 +0100 schrieb Jamie McCracken: > Danny Milosavljevic wrote: > > > > I'd suggest creating tlist, tstringlist, tfilestream-like things with an > > optional owner (TComponent-like). I've been programming delphi for > > years, and trust me, I know how annoying keeping track of tlist memory > > is (and I mean _annoying like [EMAIL PROTECTED] hell_ :)). Of course having > > to cast > > around list content is even more annoying. But 'm trying to fix that > > now, in fpc. > > 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 you are going to set > the owner to in the case where its only a temp variable. owner nil, and free later > > > > Setting a reference to nil works automagically (user doesnt need to do > > it). > > Only remaining serious problem are reference cycles. And thats a BIG > > problem (see old java versions and swing, and you will see... its the > > horror). > > But it still 'only' means you have to set 'some' references to nil > > manually. Which is ugly. Either all or none would be cleaner :) > > > ref cycles are not a big deal - show me one bit of the FCL that has > cycles using Tobjects only (IE not with Tcomponents)! I dont know the fcl enough for that. But generally speaking, most (nice) trees have that problem actually. TXMLNode Parent: TXMLNode Children: list(TXMLNode); ref cycle: a: TXMLNode; b: TXMLNode; a := TXMLNode.Create; b := TXMLNode.Create; a.Children.Add(b); b.Parent := a; not freeing anything: a := nil; not freeing anything: b := nil; not freeing anything: a := nil; b := nil; > > Its obvious that you wont have cycles in things like TstringList, > TFileStream objects etc. > > In fact only in Tlist are you likely to have cycles and in the add > method you could check to make sure no self references are added and > throw an exception if they are. A knowledgable developer can of course > set any object to nil if he knows that there are or likely to be cycles > but again this will only happen in a very small minoirty of cases. For gui stuff, it like happens all the time... for tree stuff, it like happens all the time ... hmm > > I would implement ref count on TObjects with a protected boolean > variable to turn it off for TComponent descendants as we dont need to > ref count components and components by their nature are far more likely > to have cycles then plain objects. > > Its also obvious that pascal by its nature is far better suited to > efficient ref counting than others like java because java strings are > objects and ref counting a whole load of short term objects can > adversely affect performance. (imagine deleting a stringlist where all and pascal strings are ? > the strings are objects - you would have to call dec_ref on all the > strings and thats why ref counting is considered slow especially with java) > > I am asserting that ref counting in pascal would probably have a much > lower effect on overall performance as a result. Ref counting objects > with long life spans is actually far more cpu efficient than any GC > scheme (and thats why the best performing GCs are hybrid GCs which > actually ref count globals and all objects that survive multiple > generations). In fact unless you are creating loads of temporary short > lived objects in your code, the overhead of ref counting should be > acceptable in most cases and of course you can optimise your code for > ref counting by using more global vars instead of temps/passing them as > parameters to functions etc. > > But we cant test out any of this until we have c++ style exception > handling so its performance or lack of performance is just speculation > at the moment. what is that ? > > jamie. cheers, Danny -- www.keyserver.net key id A334AEA6 signature.asc Description: This is a digitally signed message part ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
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 you are going to set the owner to in the case where its only a temp variable. owner nil, and free later yeah and now you are back at manual management. ref cycles are not a big deal - show me one bit of the FCL that has cycles using Tobjects only (IE not with Tcomponents)! I dont know the fcl enough for that. But generally speaking, most (nice) trees have that problem actually. Good point but are trees like that the exception or the rule? I mean Delphi's TTreeview's TTreeNode is not cyclic AFAIK. however they are better implemented using Tcomponent where the parent objects can automatically free the children. In any case we would need weak refs to overcome problems like these in tobjects. so in your code we would have something like: b.Parent := weak (a); where weak() prevents the ref count from incrementing. Or a quick hack would be to manually dec the ref count (assuming we provide a public Tobject method for this) after that assignment. What we shouldn't do is rely on the developer who is using the class to nil it at the end cause that defeats the whole purpose. I admit its not perfect but exceptions like these should hopefully be few and far between. Its obvious that you wont have cycles in things like TstringList, TFileStream objects etc. In fact only in Tlist are you likely to have cycles and in the add method you could check to make sure no self references are added and throw an exception if they are. A knowledgable developer can of course set any object to nil if he knows that there are or likely to be cycles but again this will only happen in a very small minoirty of cases. For gui stuff, it like happens all the time... Absolutely, which is why components will not be ref counted for tree stuff, it like happens all the time ... hmm dunno - its hard to say how common occurances like your example are as all the trees I have recalled using have not been cyclic like that. I would implement ref count on TObjects with a protected boolean variable to turn it off for TComponent descendants as we dont need to ref count components and components by their nature are far more likely to have cycles then plain objects. Its also obvious that pascal by its nature is far better suited to efficient ref counting than others like java because java strings are objects and ref counting a whole load of short term objects can adversely affect performance. (imagine deleting a stringlist where all and pascal strings are ? records or pointers to records. If you use shortstrings then it will be fast cause they are not ref counted. Java strings by comparison are classes so they will always suck in this regard. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Danny Milosavljevic wrote: > > > > Garbage collection is largely no issue when using the Owner concept in > > > > TComponent, using TObjectList, etc. > > > > > > True and thats why I suggested ref counting Tobjects only so that no > > > manual memory management is required. I tend to make heavy use of TList, > > > Tstringlist and TFilestream objects so I cant do everything with > > > tcomponents alas. > > I'd suggest creating tlist, tstringlist, tfilestream-like things with an > optional owner (TComponent-like). I've been programming delphi for > years, and trust me, I know how annoying keeping track of tlist memory > is (and I mean _annoying like [EMAIL PROTECTED] hell_ :)). Of course having > to cast > around list content is even more annoying. But 'm trying to fix that > now, in fpc. I've implemented such classes years ago, and according list and tree view controls for easy display. The classes are derived from TStrings, widely compatible with the remainder of the VCL. I also use bidirectional member/owner links, so that a destroyed member can inform it's owner appropriately, and the display and navigation in trees requires no further stacks or treeview structures. In fact it's sufficient to pass a reference to some existing TStrings structure to my controls, then that structure is displayed automagically, without the need for hidden copies or other crap, as occurs with the traditional controls. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
