date:20050602

On Thursday 02 June 2005 15:23, Jamie McCracken wrote:
> Vinzent Hoefler wrote:
> >>manual memory management of tobjects is redundant as you can get
> >> good performance with ref counting tobjects.
> >
> > That can be a point, yes. But it is somehow not related to any
> > syntax.
>
> It means not having to bother with my pet hate the try..finally..free

Well, try/finally is mainly for handling exceptions, not for handling 
memory. ;-)

> > Typing is only a very small part of the development cycle.
> > Performance measures indicate that rhe average programmer delivers
> > about 2 to 20 lines per code per day (measured over the whole
> > development cycles, this of course includes testing, too).
> >
> > Compare these with the lines of code you *could* write in eight
> > hours if you would just write them and you see how much you could
> > optimize away there if you'd actually manage to double the
> > performance.
>
> You are referring to an industrial strength development process

Basically I'm just talking about being professionell.

> taht
> is not used by a lot of developers (at least not that I know of
> considering Delphi is a RAD tool and is primarily used as such).

_Anything_ is used as RAD tool these days. The problem is, it's not so 
rapid after all.


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] Re: [fpc-l] type discussion

> P.S.:
> BTW: Never heard of anybody doing serious programming in GNU Pascal (and I
> know many a programmer doing serious programming in FPC and even VP)

As far as I can see (from their maillists), most serious GPC users are
academics working with large numeric-related legacy ISO codebases. 

VP had some serious apps in the BBS time, but nothing serious in the
half-decade, except maintenance of those apps.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpc-svn177-units-Mysql broken

2005-06-02 Thread Alexandrov Alexandru

there is an inconsistency:

  TDateTimeRec = record
case TFieldType of
  ftDate: (Date: Longint);
  ftTime: (Time: Longint);
  ftDateTime: (DateTime: TDateTimeAlias);
  end;

   TTimeStamp = record
  Time: integer;   { Number of milliseconds since midnight }
  Date: integer;   { One plus number of days since 1/1/0001 }
   end ;

TTimeStamp,Date is integer, and TDateTimeRec.ftDate is longint. 

on AMD 64 integer<>longint?

Alex


On 6/3/05, Jan Ruzicka <[EMAIL PROTECTED]> wrote:
> Hi
> 
> the latest version (177) of fpc in svn does not compile on Mac OS X
> 10.3.9.
> 
> The make all ends with following:
> 
> /Users/j/fpc/fpc-svn/compiler/ppcppc -Xs -O1 -n -S2
> -Fu/Users/j/fpc/fpc-svn/rtl/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/ibase/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/postgres/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/mysql/units/powerpc-darwin
> -Fu/Users/j/fpc/fpc-svn/packages/base/sqlite/units/powerpc-darwin -FE.
> -FU/Users/j/fpc/fpc-svn/fcl/units/powerpc-darwin -dpowerpc -dRELEASE
> db.pp
> dataset.inc(468,54) Error: Incompatible type for arg no. 1: Got
> "TDateTimeAlias", expected "Int64"
> db.pp(2025) Fatal: There were 1 errors compiling module, stopping
> db.pp(2025) Error: Compilation aborted
> make[3]: *** [db.ppu] Error 1
> make[2]: *** [db_all] Error 2
> make[1]: *** [fcl_all] Error 2
> make: *** [build-stamp.powerpc-darwin] Error 2
> 
>  >>
> 
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: [fpc-l] type discussion



Forward declarations are redundant - they exist purely for the benefit 
of the compiler.


I agree.  I hate prototyping.  That's why you use top-down design.  
What's wrong with that?


Begin..End is redundant - you have to indent them to make em readable 
anyways.


Not at all; I certainly don't indent them, and I'm a fanatical 
indenter.  I don't think you're going to convince anyone to change THIS 
part of Pascal--it's essential.  You change begin and end, and you just 
don't have Pascal anymore.  Plus the only reason I love FPC is because 
it is faithful to older code.  If it breaks my code, I'll likely go back 
to a previous version and I bet there are enough people who feel this 
way that there will be the beginning of another project based on the 
older FPC code.


manual memory management of tobjects is redundant as you can get good 
performance with ref counting tobjects.


Oh yes, this old argument.  I remember reading this on the list before.  
I guess it's still on your mind ;)  I really don't know about the pros 
and cons for ref counting, so maybe someone can explain it.



___
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

[fpc-devel] Re: [fpc-l] type discussion



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 as fast, the 
maximum (s)he would gain would be five percent in overall performance.



you are missing the point!

Whather you can implement something faster in another language is not 
the issue. I am arguing for less verbose syntax without decreasing 
the clarity of the code in delphi/pascal and that is logically gonna 
improve productivity without taking anything away.



This is only 'logical' if the hypothesis

"productivity is inversely related to the syntax verbosity"

is correct.

I question the correctness of the hypothesis, and I assume, so does
Florian...



I think the point of this is being lost on me.  We're talking about 
changing things like philosophy (top-down design), and syntax.  So are 
we talking about just creating another new language?  I mean that's what 
it sounds like.  Why not take Python or C# and add Pascal syntax or 
philsophies to it instead of adding these to Pascal?


Maybe some people just really don't like Pascal that much.

___
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

[fpc-devel] Extend the libraries people!




What makes python interesting are the many classes it offers by default
to perform standard tasks, especially in the text treatment department;
regular expression stuff etc.

The same goes for most languages; Mostly it's not the language syntax
that determines the productivity factor; it's the number of standard
available routines.



Exactly!  Thanks for brining this up.  If you just want more people to 
use Pascal, just


1) Make it simple
2) Have lots of nice tools
3) And most of all, have lots of units to do different thing

It's the libraries, functions, objects, etc. that really attract 
people.  Why do you think Java got so popular?  It certainly wasn't 
because it was lightning fast or easy to write.  It was because the 
"standard" libraries that come with Java (despite Sun's insistance to 
try to talk about the two synonomously) were so extensive.  Ever since C 
and its concept of including libraries, it's been obvious that this is 
the main attraction for people.




___
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




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] Range check error in cthreads (make debug)

2005-06-02 Thread Tomas Hajny

Date sent:  Thu, 2 Jun 2005 10:30:25 +0200
From:   [EMAIL PROTECTED]
To: fpc-devel@lists.freepascal.org
Subject:[fpc-devel] Range check error in cthreads (make debug)
Send reply to:  FPC developers' list 




> If i compile rtl with debug info (make debug), then i get at start of
> my multithreaded app:
> 
> An unhandled exception occurred at $08062B3C :
> ERangeError : Range check error
>   $08062B3C  CGETCURRENTTHREADID,  line 310 of ../unix/cthreads.pp
>   $0805ADAD  GETCURRENTTHREADID,  line 136 of
>   /mnt/progs/devel/fpc/rtl/inc/thread.inc $08140367  COMMONINIT,  line
>   1519 of /mnt/progs/devel/fpc/rtl/objpas/classes/classes.inc

Thank you, should be fixed now.

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] fpc-svn177-units-Mysql broken

2005-06-02 Thread Jan Ruzicka


Hi

the latest version (177) of fpc in svn does not compile on Mac OS X 
10.3.9.


The make all ends with following:

/Users/j/fpc/fpc-svn/compiler/ppcppc -Xs -O1 -n -S2 
-Fu/Users/j/fpc/fpc-svn/rtl/units/powerpc-darwin 
-Fu/Users/j/fpc/fpc-svn/packages/base/ibase/units/powerpc-darwin 
-Fu/Users/j/fpc/fpc-svn/packages/base/postgres/units/powerpc-darwin 
-Fu/Users/j/fpc/fpc-svn/packages/base/mysql/units/powerpc-darwin 
-Fu/Users/j/fpc/fpc-svn/packages/base/sqlite/units/powerpc-darwin -FE. 
-FU/Users/j/fpc/fpc-svn/fcl/units/powerpc-darwin -dpowerpc -dRELEASE 
db.pp
dataset.inc(468,54) Error: Incompatible type for arg no. 1: Got 
"TDateTimeAlias", expected "Int64"

db.pp(2025) Fatal: There were 1 errors compiling module, stopping
db.pp(2025) Error: Compilation aborted
make[3]: *** [db.ppu] Error 1
make[2]: *** [db_all] Error 2
make[1]: *** [fcl_all] Error 2
make: *** [build-stamp.powerpc-darwin] Error 2

>>


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Jose Manuel


>
> 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 my application.
>
> jamie.

Well, you are quite a machine. If you say so, sure it's so, but that's not
the problem. Anyhow there are tools, editors, etc. that can easy that fact
if you feel confortable with then.
I usually spend under 5% typing my code, I spend a lot longer thinking what
I have to type, and I DO spend quite longer debugging and improving my code.
And herebye I challenge any C Coder to maintain a program faster and neater
than in Pascal (I say C, 'cause your comments about Python and other script
language I assume it's a joke).

Anyway as Michael would say, a can of worms has been opened and we are not
going anywhere. If you want to stick to Python, stick to it, but Pascal is
another thing.

JMR

P.S.:
BTW: Never heard of anybody doing serious programming in GNU Pascal (and I
know many a programmer doing serious programming in FPC and even VP)



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion





Yes. Too bad it is not possible. One of the problems you can expect is
with cyclic units. Normally the interfaces of the units form a tree, which
define how they get called. So the compiler can compile the interfaces in
the depth first order, then it can do the implementations in any order it
wants, cyclic uses in implementations are no longer a problem, as the
compiler known how to call the procedures in those units.


yes I will need to think about that. Perhaps have two different use 
clauses...




From the good taste department, it breaks the interface/implementation
principle. The unit principle guarantees that libraries are being written
so that one only needs to look at the interface, not the implementation to
know how a library works. It saves a few keystrokes, but makes it a lot
harder for the user of the library to understand it.


Well thats how c# does it and whilst you have a point its not really a 
problem in the modern world were introspection or indexing is used by an 
IDE to get the interface.


jamie.



Daniël


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread DaniÃ«l Mantione

Op Thu, 2 Jun 2005, schreef Jamie McCracken:

> 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 parser is indeed manual craftmanship. Some experimenting
> > was done using yacc in the past but a handwritten parser turned out to be
> > the best choice. The parser units start with the letter p, for example
> > pexpr.pas is the expression parser.
>
> You've done it the hard way - no wonder developer's are reluctant to
> implement syntax changes!

Depends on your definition of "hard way". The parser is fast and
flexible. Ask Carl Eric Codere what the exact problems with Yacc were. But
it's "been there, done that, didn't work".

> > Yes... Because Java often turns out to be the wrong tool and its memory
> > management is one of the reasons. We need to be carefull to prevent Pascal
> > becoming a wrong tool. However, automated memory management does have some
> > advantages. Nobody can deny that.
>
> Ref counting does not use more memory! (well okay 32 bits extra to store
> the ref count for each object).

Yes, but it has its own problems. Think of an object having a reference to
itself (think of a ringbuffer with 1 object in the ring or so). Welcome in
the real world.

Perhaps (likely) there is a solution, perhaps (likely) there are more
problems. No expert here.

> would become under Rad Pascal:
>
> uses
>Classes, SysUtils;
>
>   TMyObject = class (Tobject)
>  private
>  count : integer;
>  public
>  constructor create; override;
>   inherited Create(AnOwner);
>   inc (count);
>
>  destructor destroy; override;
>   inherited Destroy;
>
>
> Notice its at least 50% less code to write.

Yes. Too bad it is not possible. One of the problems you can expect is
with cyclic units. Normally the interfaces of the units form a tree, which
define how they get called. So the compiler can compile the interfaces in
the depth first order, then it can do the implementations in any order it
wants, cyclic uses in implementations are no longer a problem, as the
compiler known how to call the procedures in those units.

From the good taste department, it breaks the interface/implementation
principle. The unit principle guarantees that libraries are being written
so that one only needs to look at the interface, not the implementation to
know how a library works. It saves a few keystrokes, but makes it a lot
harder for the user of the library to understand it.

Daniël

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


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 parser is indeed manual craftmanship. Some experimenting
was done using yacc in the past but a handwritten parser turned out to be
the best choice. The parser units start with the letter p, for example
pexpr.pas is the expression parser.


You've done it the hard way - no wonder developer's are reluctant to 
implement syntax changes!




Yes... Because Java often turns out to be the wrong tool and its memory
management is one of the reasons. We need to be carefull to prevent Pascal
becoming a wrong tool. However, automated memory management does have some
advantages. Nobody can deny that.


Ref counting does not use more memory! (well okay 32 bits extra to store 
the ref count for each object).



except were the source is bloated by forward declarations :)



Just order your procedures like you should order them, go go!! :)

[EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep ';forward;' *.pas
browlog.pas:procedure writesymtable(p:Tsymtable);forward;
pexpr.pas:function sub_expr(pred_level:Toperator_precedence;accept_equal : 
boolean):tnode;forward;
pstatmnt.pas:function statement : tnode;forward;
[EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep '; forward;' *.pas
browcol.pas:  function GetDefinitionStr(def: tdef): string; forward;
scanner.pas:function read_expr : string; forward;
[EMAIL PROTECTED]:~/fpc2/fpc/compiler>

Wow! 5 forward declarations in the entire compiler source. Yeah, bloat
indeed :)




its a bit more than that. Forward declarations include the class 
interfaces too in the type section. EG under delphi :



uses
  Classes, SysUtils;

type

  TMyObject = class (Tobject)
  private
  count : integer;  
  public
  constructor create; override;
  destructor destroy; override; 
  end;

implementation

constructor TConfigureBuildLazarusDlg.Create(AnOwner: TComponent);
begin
  inherited Create(AnOwner);
  inc (count);  
end;

destructor TConfigureBuildLazarusDlg.Destroy;
begin
  inherited Destroy;
end;

end.



would become under Rad Pascal:

uses
  Classes, SysUtils;

 TMyObject = class (Tobject)
private
count : integer;
public
constructor create; override;
inherited Create(AnOwner);
inc (count);

destructor destroy; override;   
inherited Destroy;


Notice its at least 50% less code to write.


jamie.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Daniël Mantione

Op Thu, 2 Jun 2005, schreef Jamie McCracken:

> Daniël Mantione wrote:
>
> >
> > Granting all those wishes would turn the language in an enourmous
> > monster. That doesn't look like a good idea. We've also a limit amount of
> > developers whos time needs to be spent well, or we'll get behind.
> >
> > So, we're very convervative. Good ideas though, that will really benefit
> > people, will be read with great interrest.
> >
>
>
> okay but my idea was to have a new dialect (i'll call it RAD-Pascal) as
> FPC supports multiple dialects it can slip in without affecting existing
> code so if people dont like it they dont have to use it. Im quite happy
> to write it myself but I will need help on where to look and what to
> modify in the compiler as im not familliar with the compiler source (I
> cant even find the grammar for the language so I take it you dont use a
> table driven or auto generated parser like yacc)

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 parser is indeed manual craftmanship. Some experimenting
was done using yacc in the past but a handwritten parser turned out to be
the best choice. The parser units start with the letter p, for example
pexpr.pas is the expression parser.

As for forward declarations, forget it for the short term, adding a pass
is way too complicated for a beginner.

Lastly, a good language tries to maximize power while limiting language
constructions. Keep that in mind.

> > Users like software written in Pascal. They dislike software requiring
> > JDK's and .NET runtimes.
> >
> > So, lets turn the disadvantage in an advantage. Pascal is no replacement
> > for Java and C#. It is a replacement for C and C++.
>
> It is a replacement for java and c# for *desktop* apps. I have rewritten
> several java apps into delphi in my previous jobs.

Yes... Because Java often turns out to be the wrong tool and its memory
management is one of the reasons. We need to be carefull to prevent Pascal
becoming a wrong tool. However, automated memory management does have some
advantages. Nobody can deny that.

> > Now, the majority of software is written in C and C++. Isn't that a great
> > potential "market"?
> >
> >
> >>All in all the changes would mean you spend more of your time
> >>implementing your application rather than typing loads of redundant
> >>code. Maintenance is easier as their is less redundancy.
> >
> >
> > As has already been said, typing is not the problem, maintenance is.
> > Pascal does a good job here, saving people a lot of time.
>
> except were the source is bloated by forward declarations :)

Just order your procedures like you should order them, go go!! :)

[EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep ';forward;' *.pas
browlog.pas:procedure writesymtable(p:Tsymtable);forward;
pexpr.pas:function sub_expr(pred_level:Toperator_precedence;accept_equal : 
boolean):tnode;forward;
pstatmnt.pas:function statement : tnode;forward;
[EMAIL PROTECTED]:~/fpc2/fpc/compiler> grep '; forward;' *.pas
browcol.pas:  function GetDefinitionStr(def: tdef): string; forward;
scanner.pas:function read_expr : string; forward;
[EMAIL PROTECTED]:~/fpc2/fpc/compiler>

Wow! 5 forward declarations in the entire compiler source. Yeah, bloat
indeed :)

> None of my proposed changes should be detrimental to pascal's
> maintainability or clarity as I too value that feature.

If you want to expiriment, go ahead and we'll be helpfull. That'll be more
productive than this discussion. However, your time is propably as
valuable as ours, try to make features that'll really help people.

Daniël

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] type discussion

2005-06-02 Thread Christian Iversen

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] Re: [fpc-l] type discussion


Daniël Mantione wrote:



Granting all those wishes would turn the language in an enourmous
monster. That doesn't look like a good idea. We've also a limit amount of
developers whos time needs to be spent well, or we'll get behind.

So, we're very convervative. Good ideas though, that will really benefit
people, will be read with great interrest.




okay but my idea was to have a new dialect (i'll call it RAD-Pascal) as 
FPC supports multiple dialects it can slip in without affecting existing 
code so if people dont like it they dont have to use it. Im quite happy 
to write it myself but I will need help on where to look and what to 
modify in the compiler as im not familliar with the compiler source (I 
cant even find the grammar for the language so I take it you dont use a 
table driven or auto generated parser like yacc)





Forward declarations are redundant - they exist purely for the benefit
of the compiler.



Here I disagree. I like that I only need to look upward to search a
procedure. Even when I program C I order the procedures like I to in
Pascal, since it'll save time in the long term.


I understand that but its enforced for the convienience of the compiler. 
A developer should have a choice for how he arranges things especially 
if hes in a hurry to develop something quick. Such constraints reduce 
the RAD factor.







Begin..End is redundant - you have to indent them to make em readable
anyways.



Here I agree, however, Pascal was designed this way. If I would design the
language I would have likely chosen something shorter. On the other hand,
I only need to type alt+B and I have a begin/end combo. Even without it,
the begin/end doesn't irritate me.



manual memory management of tobjects is redundant as you can get good
performance with ref counting tobjects.



I agree that automatic memory management eases the programming job.
However, Pascal is a manual memory management language. That has
advantages, software written in Pascal is fast, perceived fast by people,
and uses very little memory.


same is true for Delphi but it uses ref counting and parent/child owner 
for managing memory for most things. However they forgot to do something 
about tobjects - its just inconsistent to manage some things and not others.


With C++ exception handling the try..finally construct has negligible 
overhead so simple ref counting is fast. In the majority use case where 
objects are kept local the overhead will be negligible too. I really 
doubt you will see any significant performance hit this way and memory 
use is of course hardly affected at all by ref counting (unlike GCs). I 
do hope the FPC developers will look at this once we have C++ exceptions 
 and see just exactly what is the overhead and if its worth ref 
counting some more stuff.




Users like software written in Pascal. They dislike software requiring
JDK's and .NET runtimes.

So, lets turn the disadvantage in an advantage. Pascal is no replacement
for Java and C#. It is a replacement for C and C++.


It is a replacement for java and c# for *desktop* apps. I have rewritten 
several java apps into delphi in my previous jobs.




Now, the majority of software is written in C and C++. Isn't that a great
potential "market"?



All in all the changes would mean you spend more of your time
implementing your application rather than typing loads of redundant
code. Maintenance is easier as their is less redundancy.



As has already been said, typing is not the problem, maintenance is.
Pascal does a good job here, saving people a lot of time.


except were the source is bloated by forward declarations :)

None of my proposed changes should be detrimental to pascal's 
maintainability or clarity as I too value that feature.


jamie.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to manually control debug information

2005-06-02 Thread Peter Vreman


At 19:36 2-6-2005, you wrote:

Hello,

I'm writting a custom preprocessor and I would like that the line number
information maps to the original file. An example (not real, only an
example):

  ...original.pas...
  21 procedure AddFive(var a, b: Integer);
  22 begin
  23   a := ++b;
  24 end;

After preprocessor:

  ...processed.pas...
  25 procedure AddFive(var a, b: Integer);
  26 begin
  27   Inc(b);
  28   a := b;
  29 end;

I would like that stepping in the debugger through AddFive showed 
original.pas

in lines 21 to 24, not processed.pas in lines 25 to 29.

How could I do that?


That is not possible with fpc


Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread DaniÃ«l Mantione



Op Thu, 2 Jun 2005, schreef Jamie McCracken:

> So am I. My point is not changing the language so that it incurs
> additional maintenance or is harder to read or harder to fix bugs or
> make bugs more likely. In fact its the complete opposite.
>
> My point is to to reduce or remove *redundant* syntax that serves no
> useful or productive purpose (to the programmer).

No, adding syntactic sugar usually does more harm than it is an
enrichment. It promotes people to write code that only works on 1 compiler
and increases the learning curve for people trying to learn the language.

Syntactic sugar can be added *if* it really does have an advantage.
However, changing the way constructors are done saves only a few
keystrokes, but keeps people away from understanding class references,
which, if understood well, can be a very powerfull tool (virtual
constructors, calling class methods of class references etc.)

So, I very much doubt if this proposal will help.

Don't take us wrong, we are very much in favour of modernizing the
language. However, we are getting *lots* of proposals like this, only
*for* *no* *other* *reason* than to save a few keystrokes.

Granting all those wishes would turn the language in an enourmous
monster. That doesn't look like a good idea. We've also a limit amount of
developers whos time needs to be spent well, or we'll get behind.

So, we're very convervative. Good ideas though, that will really benefit
people, will be read with great interrest.

> Forward declarations are redundant - they exist purely for the benefit
> of the compiler.

Here I disagree. I like that I only need to look upward to search a
procedure. Even when I program C I order the procedures like I to in
Pascal, since it'll save time in the long term.

> Begin..End is redundant - you have to indent them to make em readable
> anyways.

Here I agree, however, Pascal was designed this way. If I would design the
language I would have likely chosen something shorter. On the other hand,
I only need to type alt+B and I have a begin/end combo. Even without it,
the begin/end doesn't irritate me.

>
> manual memory management of tobjects is redundant as you can get good
> performance with ref counting tobjects.

I agree that automatic memory management eases the programming job.
However, Pascal is a manual memory management language. That has
advantages, software written in Pascal is fast, perceived fast by people,
and uses very little memory.

Users like software written in Pascal. They dislike software requiring
JDK's and .NET runtimes.

So, lets turn the disadvantage in an advantage. Pascal is no replacement
for Java and C#. It is a replacement for C and C++.

Now, the majority of software is written in C and C++. Isn't that a great
potential "market"?

> All in all the changes would mean you spend more of your time
> implementing your application rather than typing loads of redundant
> code. Maintenance is easier as their is less redundancy.

As has already been said, typing is not the problem, maintenance is.
Pascal does a good job here, saving people a lot of time.

Daniël


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] modernizing pascal discussions

2005-06-02 Thread listmember

If you want to modernize the language you can take the current fpc code 
and extend it yourself. If the extension is clear and we agree on it it 
can eventually be put in the main fpc release.


Discussions are useful.

Before one starts coding away, a consensus would be nice to have.

I would not want to spend days on something only to be thrown
out simply because the idea or the principle got on the wrong
sides of others.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: strlist.create [was: type discussion]

2005-06-02 Thread listmember


First, with

 strlist.create;

It is not clear whether strlist is already initialized or not;
there is no way it can now this.


Why not, what stops you from checking 'strlist <> Nil'.. ?


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.


> Create MUST be a constructor, since you are initializing
> the variable.

Which could be solved by making 'Create' a reserved word for the
constructor only. It has already become a de facto reserved word
anyhow.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread listmember


-- Class Contracts
I like the 'require/ensure' aproach.

It makes the code more robust and more debuggable, IMHO


I think the checks you can do there are to limited. I also wonder what
will happen if a require isn't met. Personally I don't want exeption in my
released app.


No, these are assertions not as exceptions.


-- Generics
I am not sure if Generics could be done in FPC.


There were some discussions about it here and AFAIK some are trying to
implement.


Any links?


-- Virtual Properties and Events

The examples given there are not very different of what is possible now.
Make SetWith virtual and you have almost the same.

What however would be nice is if you could override the getter or setter.
Something like
property Width write MySetWidth


I think you missed a few things here.

type
  TMyClass = class
...
property Width: integer read write; virtual; abstract;
  end;

As you can see, getters and setters are not in the picture
at all. Which means, you have all the freedom you want in
the derived class.

Plus, I like the idea that I could have a base class
with read-only property that can not be overriden to be
read-write later.

property Width: integer read; virtual; abstract;

OK, while I like the idea, I can not think of how I would
use it though :-) Can someone help me out here 


-- Enhanced Multicast Events



This is not really new. You can implement it yourself like

property OnChange: TNotifyList;

and then OnChange.Add(Notifyproc) or OnChange.Remove(Notifyproc)


OK. Nice to be able to do that. Do I have to write my
TNotifyList every time I need it?


Inline variable initializers, such as:


[snip]



var
 Integer1: Integer = 15;
 Boolean1: Boolean = False;
 String1: String = 'SOME TEXT';


Hmm.. sometimes usefull. You can put it as first lines 

> in your constructor/codeblock, but keep it thogheter in
> say large classes can be handy.

Yes, and it improved the readability, IMHO. Plus, there is
no reason for you to alter that in constructor/codeblock too.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


|
| > Begin..End is redundant - you have to indent them to make em readable
| > anyways.
|
| No. This makes the code more readable like normal english text. It
| states much more clearly what it intents, at least much more than just
| indenting or putting curly braces around it.

And when you have a high resolution monitor, or you are reading the code in 
small
print, that { could be a (.
It's not always clear.
On very short code blocks in PHP, I found myself always going

{
 code
}

Anyways! for clairty. So the whole so called "advantage" of going {code} was 
defeated.
Because I figured it could have been (code) too, on a blurry day when I just 
woke up.


___
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] Re: [fpc-l] type discussion


| Begin..End is redundant - you have to indent them to make em readable
| anyways.

Typing "type" is reduntand to, so is "integer"

You could use "i" instead of integer, you could use "T" instead of type. Draw 
the
line. Draw the line. I feel you do not like any part of the Pascal language, so 
I
wonder as to your intention or goal here. It seems python or C# is the perfect 
fit for
what you are describing.

By the way, remember that you will always convert "{" to "beginning of the code
block".
At least you don't have to type out "beginning of the code block" but rather 
"begin".

Draw the line.


___
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] Re: [fpc-l] type discussion

Jamie McCracken wrote:

> > For me I prefere clarity above less typing (besides if you want to write
> > realy short code, you sould use APL)
> >
> 
> I totally agree with you in this case - we dont want or need cryptic c
> stlye syntax in any version of Pascal.

ACK.

> 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 virtually non-existant. Of
> course Python is piss poor in both performance and memory usage but it
> does point the way to a revitalised pascal. Adopting less verbose but
> still clean and clear syntax ala python is IMHO the way to make Pascal
> great again.

IMO Python is preferred for its portability. Consider the efforts
required to distribute a C project, with autobloat, configure and all
that crap. Python in contrast is the modern BASIC, that made programming
easy, at the cost of execution speed. And, like BASIC, Python IMO is not
such a general (unlimited) programming language as are C or Pascals.

> Consider the developer unfirendly nature of pascal/Delphi atm:
> 
> 1) Forward declarations - they sux! Why should the developers have the
> burden of making the code totally sequential declaration wise. All other
> modern compilers dont need this. Sure your code might take a bit longer
> to compile but thats peanuts compare to the time saved in extra typing
> and reordering your code

I agree that forward declarations and circular unit references suck. If
it's only compilation time, according improvements are welcome. But I
suspect that the introdution into the compiler would exceed the current
manpower :-(

> 3) loads of small and pointless additional syntax like EG for creating
> an object you should just be able to say:
> 
> myobject.create;
> 
> and not
> 
> myobject := Tobject.create;

That conflicts with e.g. someproc(someclass.create);
It also is useless with polymorphism, where the type of the variable can
differ from the type of the created object.

> also Begin..End blocks should IMO be replaced with python's indenting.

No, please :-(

A single run through an inappropriate editor could irrecoverably damage
the indentation!

I for my part would prefer a cleaner syntax, closer to Modula or Oberon,
with statement_list vs. statement_sequence. The "end"s etc. can be
inserted by an appropriate editor, if somebody wants less typing...

> 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.

I like RAD, but only when paired with the reliability and (type...)
safety of Pascal. RAD never should mean: type fast, debug forever - or -
press run and cross your fingers :-(

Or, as Vinzent pointed out:
>> 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? :->

The careful design of a programming language is not a simple task. What
looks nice to the user, may look very different to the compiler writer.
It also should be noted that the amount of *helpful* compiler error
messages heavily depends on the language design.

Unfortunately there exist multiple Pascal compilers, each with different
extensions to the original language, reducing the portability of source
code. With regards to Python you only can hope that there will never
come a
second Python system, and that the development of the language and
libraries will be continued, once the current implementors leave the
project.

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

listmember wrote:

> Inline variable initializers, such as:
...
> function Something(...): Boolean = False;
> var
>Integer1: Integer = 15;
>Boolean1: Boolean = False;
>String1: String = 'SOME TEXT';
> begin
> end;

Such constructs are subject to frequent misinterpretation :-(

I assume that you want to have C semantics, where the variables are
initialized at every invocation of the subroutine. Other people think
that the variables are "static", retaining their values across calls
(like writeable constants).

In general I prefer an implementation of features that exist in other
Pascal compilers, over an implementation of new and incompatible
features, whose impact on the overall language (stability, type
safety...) are unpredictable.

Sometimes I dream of an compiler for both Pascal and C syntax, with
simple switching between both languages. But I would not dare to suggest
how those C parts should work, i.e. what features and bugs of which C
compiler should be implemented, and how the C code should fit together
with the Pascal code, with regards to type and operation safety.

DoDi

___
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] Re: [fpc-l] type discussion


| >
| >>
| >> 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 :)


Sometimes it's which keys are near the home key. I don't care if "{" is shorter 
than
begin, because "{" requires the shift key and finger strain. Plus, I always 
convert
"{" into "begin of code block" in my mind anyway.

I rarely find that fast typing helps my coding. It sure helps when writing 
emails.. or
when doing bulk operations on big amounts of code. But when creating code, 
usually you
have to stop and think.. and fast typing is useless. It helps when you are 
typing
comments for the code. Pressing things like "End" and the arrow keys takes my 
hand off
the home keys, and this cramps up my coding thought. But it's never the typing 
speed
that helps my productivity when writing code. Just comments and bulk operations 
on
code that was already written, that is now being changed.

What I find that takes more time then the typing, is running to the manual 
trying to
figure out what this cryptic thing does, or what parameter goes where. For 
example, if
you set(red,edit) how do you know it isn't set(edit,red)? So in php when I was 
using a
text editor.. I didn't have code completion and I always had to look things up. 
Or,
even with code completion, you still have to look up more detailed descriptions 
of
what the parameters are. But it's not the typing that costs me time.

What also takes more time than the typing of code is writing comments for the 
code.
Any language requires comments for the code, so there would be no advantage for 
any
language there. Comments are comments.

Lars


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] type discussion

2005-06-02 Thread Uberto Barbini

> > 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] Re: [fpc-l] type discussion


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 you, I'd just look into finding a 
python
compiler. Everything you say points to the fact that you like the way python is 
laid
out. That's fine, there's nothing wrong with different taste.


No not at all. I dont want python but I would like to borrow some of its 
more concise syntax to make delphi less verbose thats all. Python is way 
too flawed with its grossly inefficient dynamic typing to ever be good 
for building general purpose applications.


I'll see if I can create a modern dialect and integrate it into FPC... 
Any documents/info on how the compiler is laid out would be most 
appreciated.


jamie.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


| However, in general Pascal has poor developer productivity when compared
| to modern languages like python and C#. Ironically python is perhaps the

I disagree strongly, this is one of the reasons I chose Pascal. The fact that it
creates compiled programs in a productive language versus python and C# who are 
not
generally compiled right there and then, was another reason.

| most popular language on Linux and most of its syntax is derived from
| object Pascal whereas Pascal on linux is virtually non-existant. Of
| course Python is piss poor in both performance and memory usage but it

Yes, it is. All the linux programs I tried on KDE are extremely slow compared to
Windows 2000. A lot of linux apps are made relying on python or perl. i.e. 
kpackage
relies on python, and the KDE CPU monitor program. It's so slow, I found. There 
was
also a "visual php" program of some sort made in python which was about a 450MB
download and wouldn't even load up on my pc in ample time. I deleted it before 
loading
it.

| does point the way to a revitalised Pascal. Adopting less verbose but
| still clean and clear syntax ala python is IMHO the way to make Pascal
| great again.

You just can't have it both. Perl is shortform. But it's not easy to create a
regex for the long term, for other programmers to read.. or even yourself. No 
matter
how clear the regex seems to be for a split second when you first create it 
initially.

|
| Consider the developer unfirendly nature of Pascal/Delphi atm:
|
| 1) Forward declarations - they sux! Why should the developers have the
| burden of making the code totally sequential declaration wise. All other
| modern compilers dont need this. Sure your code might take a bit longer
| to compile but thats peanuts compare to the time saved in extra typing
| and reordering your code

They don't suck, you just need a proper editor which let's you see your
declarations without taking you away from your code editing. A proper
IDE should have this. Virtual views of the text file, showing declarations
in a little side window or side panel editor, which you can edit at any
time. Not just dual view or dual opening of the file, an actual dedicated
portion for declarations open at all times in some virtual window. So the
editor needs to be improved, IMO.

Also, how in the world are you going to find all your declarations scattered 
across
the file? incremental search? or are you going to make notes at the top of the 
file
about where things are? Index it? bookmark them?

|
| 2) I have touched on manual memory managaement of tobjects before so I
| wont rehash it here (in summary ref count tobjects and they should have
| good performance with c++ style exception handling).
|

I don't mind freeing a stringlist, something bigger and something I should feel
responsible about.  But I do mind freeing a string or an array. So I have no 
problems.
I won't ask you if you've seen a fast and productive language used today with 
GC.

| 3) loads of small and pointless additional syntax like EG for creating
| an object you should just be able to say:
|
| myobject.create;
|
| and not
|
| myobject := Tobject.create;

This is not a big deal. I found as a beginners it was a big deal. I find its'  
more
clear this way.. You're creating a Tobject after all, not a object.

|
| also Begin..End blocks should IMO be replaced with python's indenting.

You need to use python and forget about Pascal. What you are asking for here is
Python! It's obvious.

|
| 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 you, I'd just look into finding a 
python
compiler. Everything you say points to the fact that you like the way python is 
laid
out. That's fine, there's nothing wrong with different taste.


Lars


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] How to manually control debug information

2005-06-02 Thread Nico Aragón

Hello,

I'm writting a custom preprocessor and I would like that the line number 
information maps to the original file. An example (not real, only an 
example):

  ...original.pas...
  21 procedure AddFive(var a, b: Integer);
  22 begin 
  23   a := ++b;
  24 end;

After preprocessor:

  ...processed.pas...
  25 procedure AddFive(var a, b: Integer);
  26 begin
  27   Inc(b);
  28   a := b;
  29 end;

I would like that stepping in the debugger through AddFive showed original.pas 
in lines 21 to 24, not processed.pas in lines 25 to 29. 

How could I do that?

-- 
saludos,

Nico Aragón

___
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

> 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] Re: [fpc-l] type discussion

> Michael Van Canneyt wrote:
> 
> > 
> > This is not so easy, and reference counting is always a mess...
> 
> Well you already have the code for ref counting for com objects so its 
> not like its a ton of work and therefore we dont need to worry about 
> your four points. Adding C++ style exception handling should make it 
> fast enough too (ok that is some work).

No it won't. The ref counting is expensive. Test e.g. speeds with Decal
vs an own implementation on Delphi. 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

> Michael Van Canneyt wrote:
> > This is only 'logical' if the hypothesis
> > 
> > "productivity is inversely related to the syntax verbosity"
> > 
> > is correct.
> 
> And it's not.
> 
> What is correct is "productivity is directly related to the number of 
> separate language constructs developer has to put in program to acomplish 
> the task"

True. But the problem is that the "task" is not a constant. _If_ you really
try to exploit this feature, and increase your programming speed (by not
having to track object age and owner), you will have to deal with
irregularties in deallocation (GC storms), null pointer exceptions etc.

> Or lack of standard libary supplied container 
> apropriate for a task requires programmer to develop his/her own or to adapt 
> something less usable.

Partially true yes. However the only reasonable solution for that is
generics I think.
> So here is some little idea which seems to me Pascalish enough to be 
> considered:
> 
> how about new keyword: local
> Class variable declared local will be automatically freed upon every exit 
> from the scope (i.e. something along the lines of implicit try/finally for 
> some builtin types).

No. Inconsequent. 

I think you are totally on the wrong track if you want to try to solve this
with language.

There are only two solutions :
1) go fully automated
2) have only the minimum on base automated types (e.g. strings, I don't count
variants, since they are for a specific purpose)

Any patchy solutions will only go against this. Most allocations aren't
limited to a simple scope anyway. Since not everything is an object, there
is a lot less object creation going on.

Even dynamic arrays were somewhat doubtfull, but finally mostly added
because of Delphi compat.

___
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



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] Re: [fpc-l] type discussion

> 
> > Begin..End is redundant - you have to indent them to make em readable
> > anyways.
> 
> No. This makes the code more readable like normal english text. It 
> states much more clearly what it intents, at least much more than just 
> indenting or putting curly braces around it.

Not every syntax is about minimizing code or readability. Some are also
to simply simplify parsing (and that is about compiler developer, but to make
the language more internally consistent) and avoid long lookaheads. These things
combined also improve quality of error messages a lot.

> > manual memory management of tobjects is redundant as you can get good
> > performance with ref counting tobjects.

For trivial programs: yes. However FPC is not designed for short scripting
programs.
 
> > Maintenance is easier as their is less redundancy.
> 
> It simply depends on the kind of redundancy.
> 
> For instance, "type" and "var" keywords are just redundant, the compiler 
> could figure it out by itself, still they serve a useful purpose.

See above.

___
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] Re: [fpc-l] type discussion

2005-06-02 Thread Ales Katona


Marco van de Voort wrote:


Also, I simply don't see the use of it. Borland Pascal's have the forward
directive for those really few cases where it is annoying.
 


Also, forward declarations mostly mean shitty code / design.
Atleast in my case it does.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

> 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 then :)
> 
> No, that's a common misunderstanding (especially amongst C-programmers).
> 
> 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 as fast, the maximum 
> (s)he would gain would be five percent in overall performance.

I doubt you would get that high.

A educated typist can get over >120 keys/min (and that is already lowered
because of many shifts, with real text it). I don't think the avg line of code
is longer than 20 chars. That is 360 lines/hr. SLOC, not code with whitespace,
and not counting generated code with codetools.

Most of the time of entry is spent in navigating and searching, not code
adding. And then data entry is only a small part overall.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] modernizing pascal discussions

2005-06-02 Thread Peter Vreman

I think we should put these kind of threads to an end. We get several 
different request which conflict or need a lot of time:


- Packages
- Better optimizer
- Better smartlinking (internal linker) to reduce executable size
- Easier cross platform (internal linker/assemblers)
- Faster (C++ like) exception handling
- More Delphi compatible

I guess the above all gives us enough work for the next 10 years.

If you want to modernize the language you can take the current fpc code and 
extend it yourself. If the extension is clear and we agree on it it can 
eventually be put in the main fpc release.


So please stop useless requests and debating and start coding.

Peter


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] type discussion

2005-06-02 Thread Ales Katona





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] Re: [fpc-l] type discussion

> >> 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 create.
> 
> sorry myobject is the pointer so a better example would be :
> 
> var strlist : Tstringlist;
> strlist.create;
> 
> This should be easy as you know the pointer type.

Syntactic sugar. Read the faq ;)
 
> > 
> > Forward declarations are IMHO required because otherwise the compiler 
> > would have to make additional passes(it does 3 AFAIK).
> 
> They are not required in a multipass compiler. 

They can be. A multipass compiler doesn't necessarily spend multiple passes
in the parser.

> If you cant resolve a 
> symbol on a single pass you can do so on a subsequent one.

This limits the amount of stuff you can do in the subsequent pass, since
nothing is required to be resolved yet. And passes are expensive,
compiletime wise.

Also, I simply don't see the use of it. Borland Pascal's have the forward
directive for those really few cases where it is annoying.

> > Besides, they are seldom enough to be a problem.
> 
> Pain in the arse they are. Its annoying and makes use of the code 
> explorer a neccsity when dealing with large classes. Its a total waste 
> of my time.

Then improve the code explorer.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

> > I totally agree with you in this case - we dont want or need cryptic c
> > stlye syntax in any version of Pascal.
> > 
> > However, in general Pascal has poor developer productivity when compared
> > to modern languages like python and C#. 
> 
> 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 :)

The opinion that Python is so fast is mainly based on tinkerers. So it is
simply true. Trial and error programming is for small programs always faster,
and Pascal doesn't help with that.

However IMHO is that a problem of Python/C#, not Pascal. Or actually it is 
a big problem for IT managers ;-)

And then people wonder why the avg IT project doesn't make the deadline.
 
> > object pascal whereas pascal 
> 
> Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice,
> Mozilla etc. use ;), definitively not python ... Python is a usuable scripting
> language but nothing more.

If I see what python is used for on my system than that is application
scripting and distribution-related tools (pkg management etc). Not one really
usable app.

Python is not a brick in the wall of development, but more like hole filler.
 
> > on linux is virtually non-existant. 
> 
> The problem with pascal on linux was/is that there was no good compiler in
> the 90s for linux so a lot developers got lost.

The educational stigma also hurt pretty bad, even though untrue. This was
indeed not helped by the relative late arrival of 32-bit Borland compilers.

> > 2) I have touched on manual memory managaement of tobjects before so I
> > wont rehash it here (in summary ref count tobjects and they should have
> > good performance with c++ style exception handling).

This is impossible:-)
 
> Good performance like python ;)?

That is doable  :-)

___
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] Re: [fpc-l] type discussion

2005-06-02 Thread Joost van der Sluis


> Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice,
> Mozilla etc. use ;), definitively not python ... Python is a usuable scripting
> language but nothing more.

Well.. you should think so. But parts of Gnome are written in Python.
And a lot of the configuration-tools of Fedora are python-based.

I thought about it to rewrite some of them in fpc. That would make them
a lot faster, and less memory-intensive.

But first you need fpc in Fedora-Core offcourse...

Joost.


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] Re: [fpc-l] type discussion

> Marco van de Voort wrote:
> > Some of these target functionality (specially in the linking section) might 
> > require restructures
> > related to
> > * introduction of an internal linker for some core platforms (no more 
> > LD)
> > * Rewrite of module (unit) handling
> 
> Yes, these would be great, IMHO.

> > For the rest, improve RTL/FCL compability and extend them in general, and 
> > of course fixbugs.
> > 
> >>Beside of compatibility towards Delphi or MacPascal or others FPC should be
> >>open to other modifications/extensions (maybe Delphi one day copies FC a bt
> >>:-), and not always the other way round)
> 
> Maybe a few things should be borrowed from RemObjects Chrome, such as
> 
> -- Class Contracts
> http://www.remobjects.com/page.asp?id={DFA00D71-D5A4-40A3-9FD0-251899EB30D8}

> I like the 'require/ensure' aproach.

Glorified asserts. This is inventing syntax for marketing reasons.

> It makes the code more robust and more debuggable, IMHO

Nope. It just is a limited form of assert with special syntax. Definitely
does not mark the trival syntax test.

> -- Generics
> http://www.remobjects.com/articles/?id={A1D08EE3-0D9E-4828-AFB3-B2C1E772186E}

> I am not sure if Generics could be done in FPC.

Probably yes, however it will not be easy. IMHO Generics/templates are
definitely on the list, but don't expect it anywhere soon, unless there is
massive help.

> -- Virtual Properties and Events
> http://www.remobjects.com/page.asp?id={10E153AD-E05F-48CE-9CED-BCED5C9CDE99}

Understandable. However lots of performance issues. One could mitigate some
of these by e.g. requiring virtual properties to only use static methods and
adding optimizations.

RemObject/.NET probably either don't care about speed, and/or have some 
global optimalisations that makes adding this kind of stuff not to hurtful.

Probably a bit of both.

IMHO not a definite no, it would be either unoptimal, or a lot of work.

> -- Enhanced Multicast Events
> http://www.remobjects.com/page.asp?id={CC9C4828-9E49-4C41-AFD9-0BFFA4E9C3D3}

> Inline variable initializers, such as:
> 
> type
>TSomethingElse = class(TSomething)
>private
>  FInteger: Integer = 15;
>  FBoolean: Boolean = False;
>  FString: String = 'SOME TEXT';
>  {etc}
>protected
>public
>published
>end;

Can be done otherwise (simply init it). -> Syntactic sugar.

> Similarly, for
> 
> function Something(...): Boolean = False;
> var
>Integer1: Integer = 15;
>Boolean1: Boolean = False;
>String1: String = 'SOME TEXT';
> begin
> end;

Useless IMHO. Equal to above (initialising in syntax what can be inited 
normally)

> Procedure Something(Out AInteger: Integer = 12; );
> var
>Integer1: Integer = 15;
>Boolean1: Boolean = False;
>String1: String = 'SOME TEXT';
> begin
> end;

Same. Don't even add to productivy

> >>a way to write integer constants in any base, not only
> >>binary/octal/hexadecimal (not so important, but easy to implement)
> > 
> > Rarely used. Specially since more than base 36 becomes a notational 
>  > problem. However it has been brought up before.
> 
> If someone contributes the code, why not. 
> It does not hurt, IMHO.

Because the more features, the more involved maintainance of the compiler
becomes. So keep that work for features that are worth it.

I don't like this one, but it might already exist (in mac mode), since ISO
Paslla has this.

___
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] Re: [fpc-l] type discussion


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 counting.
3. Put a try/finally block and generate a call to S.Destroy at the end.
   It must also catch any errors that may occur when s.destroy is
   called. For classes, this danger is very real; For ansistrings it is
   not (well, very small)
4. It cannot assign S to anything, since that could mean that the
   lifetime of S could be prolonged. The alternative is again again ref. 
counting.


This is not so easy, and reference counting is always a mess...


Well you already have the code for ref counting for com objects so its 
not like its a ton of work and therefore we dont need to worry about 
your four points. Adding C++ style exception handling should make it 
fast enough too (ok that is some work).


jamie.






Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 15:13, Sebastian Kaliszewski wrote:

> So here is some little idea which seems to me Pascalish enough to be
> considered:
>
> how about new keyword: local
> Class variable declared local will be automatically freed upon every
> exit from the scope (i.e. something along the lines of implicit
> try/finally for some builtin types).

Oh. You mean a thing I know as "controlled type".


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 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

2005-06-02 Thread Christian Iversen

> >>>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] Re: [fpc-l] type discussion




On Thu, 2 Jun 2005, Sebastian Kaliszewski wrote:


Michael Van Canneyt wrote:

This is only 'logical' if the hypothesis

"productivity is inversely related to the syntax verbosity"

is correct.


And it's not.

What is correct is "productivity is directly related to the number of 
separate language constructs developer has to put in program to acomplish the 
task"


Inversely related, I assume you want to say :-)

So, for example, need to put separate finally block to free memory means 
additional few constructs. Or lack of standard libary supplied container 
apropriate for a task requires programmer to develop his/her own or to adapt 
something less usable.


Geeintg rid of end in begin / end wont help much (as they can;t be separated, 
they count as single construct).



So here is some little idea which seems to me Pascalish enough to be 
considered:


how about new keyword: local
Class variable declared local will be automatically freed upon every exit 
from the scope (i.e. something along the lines of implicit try/finally for 
some builtin types).


While I can see the use, there are all kinds of problems associated with it.

So instead of

Var
   S : TStringList;

ManagedVar  // or whatever. All that goes here is freed again by the compiler.
   S : TStringList;

begin
  S:=TStringList.Create;
  // code here
end;   // Compiler frees S here.

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 counting.
3. Put a try/finally block and generate a call to S.Destroy at the end.
   It must also catch any errors that may occur when s.destroy is
   called. For classes, this danger is very real; For ansistrings it is
   not (well, very small)
4. It cannot assign S to anything, since that could mean that the
   lifetime of S could be prolonged. The alternative is again again ref. 
counting.

This is not so easy, and reference counting is always a mess...


Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


Vinzent Hoefler wrote:
 >

manual memory management of tobjects is redundant as you can get good
performance with ref counting tobjects.



That can be a point, yes. But it is somehow not related to any syntax.


It means not having to bother with my pet hate the try..finally..free





All in all the changes would mean you spend more of your time
implementing your application rather than typing loads of redundant
code.



Typing is only a very small part of the development cycle. Performance 
measures indicate that rhe average programmer delivers about 2 to 20 
lines per code per day (measured over the whole development cycles, 
this of course includes testing, too).


Compare these with the lines of code you *could* write in eight hours if 
you would just write them and you see how much you could optimize away 
there if you'd actually manage to double the performance.


You are referring to an industrial strength development process taht is 
not used by a lot of developers (at least not that I know of considering 
Delphi is a RAD tool and is primarily used as such).






Maintenance is easier as their is less redundancy.



It simply depends on the kind of redundancy.

For instance, "type" and "var" keywords are just redundant, the compiler 
could figure it out by itself, still they serve a useful purpose.


but that harms legibility. I wanna balance that trims the fat but not 
the legibility.


jamie.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] type discussion

2005-06-02 Thread Uberto Barbini

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] Re: [fpc-l] type discussion


Michael Van Canneyt wrote:

This is only 'logical' if the hypothesis

"productivity is inversely related to the syntax verbosity"

is correct.


And it's not.

What is correct is "productivity is directly related to the number of 
separate language constructs developer has to put in program to acomplish 
the task"



So, for example, need to put separate finally block to free memory means 
additional few constructs. Or lack of standard libary supplied container 
apropriate for a task requires programmer to develop his/her own or to adapt 
something less usable.


Geeintg rid of end in begin / end wont help much (as they can;t be 
separated, they count as single construct).



So here is some little idea which seems to me Pascalish enough to be considered:

how about new keyword: local
Class variable declared local will be automatically freed upon every exit 
from the scope (i.e. something along the lines of implicit try/finally for 
some builtin types).



And there are possibly few variants of the thing:

1a.

var
  mySth: local TSomething;

begin
  mySth := TSomething.create();
  ...

end;


1b.

var
  mySth: TSomething local;

begin
  mySth := TSomething.create();
  ...

end;


2.

local
  mySth: TSomethin;

begin
  mySth := TSomething.create();
  ...

end;



So in 1. local is just a type modifier (in case of 1a it might make sense to 
allow it also in type declaration, hence allowing allways local classes -- 
but I'm not convinced it's desirable, and it definiately requires more work 
on compiler side). 1b. is like some other storage modifiers like absolute 
(and might be prefered). 2. is substituting local instead of var for local 
objects -- so such local object declarations stand out more int the code, 
but it's also further away from standard Pascal.



Is it worth something?


rgds
--
Sebastian Kaliszewski

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] type discussion

2005-06-02 Thread Marc Weustink

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 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] Re: [fpc-l] type discussion

On Thursday 02 June 2005 14:44, Jamie McCracken wrote:

> My point is to to reduce or remove *redundant* syntax that serves no
> useful or productive purpose (to the programmer).

Well applied redundancy is a good thing.

> Forward declarations are redundant - they exist purely for the
> benefit of the compiler.

IBTD.

> Begin..End is redundant - you have to indent them to make em readable
> anyways.

No. This makes the code more readable like normal english text. It 
states much more clearly what it intents, at least much more than just 
indenting or putting curly braces around it.

> manual memory management of tobjects is redundant as you can get good
> performance with ref counting tobjects.

That can be a point, yes. But it is somehow not related to any syntax.

> All in all the changes would mean you spend more of your time
> implementing your application rather than typing loads of redundant
> code.

Typing is only a very small part of the development cycle. Performance 
measures indicate that rhe average programmer delivers about 2 to 20 
lines per code per day (measured over the whole development cycles, 
this of course includes testing, too).

Compare these with the lines of code you *could* write in eight hours if 
you would just write them and you see how much you could optimize away 
there if you'd actually manage to double the performance.

> Maintenance is easier as their is less redundancy.

It simply depends on the kind of redundancy.

For instance, "type" and "var" keywords are just redundant, the compiler 
could figure it out by itself, still they serve a useful purpose.

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 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

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



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] Re: [fpc-l] type discussion


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 as fast,
the maximum (s)he would gain would be five percent in overall
performance.


you are missing the point!



No, I don't. I'm damn sure what I am talking about.


So am I. My point is not changing the language so that it incurs 
additional maintenance or is harder to read or harder to fix bugs or 
make bugs more likely. In fact its the complete opposite.


My point is to to reduce or remove *redundant* syntax that serves no 
useful or productive purpose (to the programmer).


Forward declarations are redundant - they exist purely for the benefit 
of the compiler.


Begin..End is redundant - you have to indent them to make em readable 
anyways.


manual memory management of tobjects is redundant as you can get good 
performance with ref counting tobjects.


All in all the changes would mean you spend more of your time 
implementing your application rather than typing loads of redundant 
code. Maintenance is easier as their is less redundancy.


jamie.






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

On Thursday 02 June 2005 14:24, Jamie McCracken wrote:

> 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 my application.

I typically spend 80% of my development time in *thinking* about what I 
should do, 10% in writing the code, 5% in showing that it works and 5% 
in drinking coffee to enhance the productivity of the first 80%.

Well, of course, this is a slight exaggeration.

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:

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] Re: [fpc-l] type discussion

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 as fast,
> > the maximum (s)he would gain would be five percent in overall
> > performance.
>
> you are missing the point!

No, I don't. I'm damn sure what I am talking about.

> Whather you can implement something faster in another language is not
> the issue.

Right. The issue is if you can make it work, i.e. how long you have to 
test and debug it and how long someone needs to understand it when he 
comes to that code later (that's called maintenance, I think).

> I am arguing for less verbose syntax without decreasing
> the clarity of the code in delphi/pascal

Which is an almost impossible task. Sure you can tweak it here and 
there, but it would _at best_ simplify the task of writing the code in 
the first place. You are just missing the remaining 98% of the 
development cycle of a typical medium to large software project.

You won't gain anything there, even if and /only if/ you could manage to 
simplify some syntax without having *any* impact on understanding the 
code later.

(BTW, Ada is even more verbose than Pascal and for the things I'm doing 
it is still /more/ productive. I'm talking about error rates and such 
stuff, not how much time spending in front of the monitor typing 
something that *may* work, if you just debug it long enough).

> and that is logically gonna
> improve productivity without taking anything away.

It would, if you could actually manage to accomplish that task. But as I 
tried to point out, those 5% don't matter. You can lose *much* more and 
much easily on a bad design. 90% of software development costs is 
testing. And then it is much better to actually be able to _read_ and 
_understand_ the code instead of writing it.

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] Re: [fpc-l] type discussion


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 my application.


jamie.



Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion




On Thu, 2 Jun 2005, Jamie McCracken wrote:


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 then :)



No, that's a common misunderstanding (especially amongst C-programmers).

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 as fast, the maximum (s)he would 
gain would be five percent in overall performance.


you are missing the point!

Whather you can implement something faster in another language is not the 
issue. I am arguing for less verbose syntax without decreasing the clarity of 
the code in delphi/pascal and that is logically gonna improve productivity 
without taking anything away.


This is only 'logical' if the hypothesis

"productivity is inversely related to the syntax verbosity"

is correct.

I question the correctness of the hypothesis, and I assume, so does
Florian...

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 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] Re: [fpc-l] type discussion




On Thu, 2 Jun 2005, Jamie McCracken wrote:


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 virtually non-existant. Of course 
Python is piss poor in both performance and memory usage but it does point 
the way to a revitalised pascal. Adopting less verbose but still clean and 
clear syntax ala python is IMHO the way to make Pascal great again.



I beg to differ.

Recently I rewrote a python program (on linux). The pascal version was
shorter and much clearer to understand. The python syntax is a horror
as far as I'm concerned.


Im not saying make pascal behave like python so if you were doing some weird 
dynamic stuff with python thats fair enough.


The python program wasn't mine.
There were errors in it; it was easier to rewrite it in pascal than to try and 
fix it.

ALl im sayting is theres no harm 
in replacing some of the verbose syntax with less verbose ones provided they 
dont harm the clarity of the code.


I love delphi but find its verbosity a pain in  some circumstances.


I don't consider Ojbect Pascal to be verbose at all, so it's not an issue for
me...

Michael.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


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 then :)



No, that's a common misunderstanding (especially amongst C-programmers).

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 as fast, the maximum 
(s)he would gain would be five percent in overall performance.


you are missing the point!

Whather you can implement something faster in another language is not 
the issue. I am arguing for less verbose syntax without decreasing the 
clarity of the code in delphi/pascal and that is logically gonna improve 
productivity without taking anything away.



jamie.





Vinzent.




___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


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 ugly stuff.


There should be no cycles on TObjects so we dont need performance 
sapping code to detect them. TCOmponents are likely to have cycles as 
they tend to link to each other but then they would not be ref counted 
as they are parent/child owner managed anyway


jamie.





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel





___
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] Re: [fpc-l] type discussion

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 then :)

No, that's a common misunderstanding (especially amongst C-programmers).

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 as fast, the maximum 
(s)he would gain would be five percent in overall performance.

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? :->



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] Re: [fpc-l] type discussion

2005-06-02 Thread Florian Klaempfl

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 then :)

I teached myself typing with 10 fingers, but typing is not the issue with auto
completion etc. Show me a python ide which can do the same tricks as lazarus or
delphi.

>> The problem with pascal on linux was/is that there was no good
>> compiler in the
>> 90s for linux so a lot developers got lost.
> 
> 
> Gnu pascal?

We were talking about good :)

> 
> 
>>> 1) Forward declarations - they sux! Why should the developers have the
>>> burden of making the code totally sequential declaration wise. All other
>>> modern compilers dont need this. 
>>
>>
>>
>> C++ is still the number one language and it requires it.
> 
> 
> yes but that aint modern! C# and python do not.

Modern doesn't mean necessarily good ...

>> Good performance like python ;)?
> 
> 
> 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 ugly stuff.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


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 virtually 
non-existant. Of course Python is piss poor in both performance and 
memory usage but it does point the way to a revitalised pascal. 
Adopting less verbose but still clean and clear syntax ala python is 
IMHO the way to make Pascal great again.



I beg to differ.

Recently I rewrote a python program (on linux). The pascal version was
shorter and much clearer to understand. The python syntax is a horror
as far as I'm concerned.


Im not saying make pascal behave like python so if you were doing some 
weird dynamic stuff with python thats fair enough. ALl im sayting is 
theres no harm in replacing some of the verbose syntax with less verbose 
ones provided they dont harm the clarity of the code.


I love delphi but find its verbosity a pain in  some circumstances.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion


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 syntax is derived from
object pascal whereas pascal 



Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice,
Mozilla etc. use ;), definitively not python ... Python is a usuable scripting
language but nothing more.


I agree but nevertheless it has become popular for desktop applications. 
Ubuntu and Fedora now uses it exclusively for filling in the blanks in 
their gnome desktops.





on linux is virtually non-existant. 



The problem with pascal on linux was/is that there was no good compiler in the
90s for linux so a lot developers got lost.


Gnu pascal?



1) Forward declarations - they sux! Why should the developers have the
burden of making the code totally sequential declaration wise. All other
modern compilers dont need this. 



C++ is still the number one language and it requires it.


yes but that aint modern! C# and python do not.





Sure your code might take a bit longer
to compile but thats peanuts compare to the time saved in extra typing
and reordering your code



Did you ever work in a team? Then you know why ordering declarations is a good
practice because reading non sequential declarations is hard.


Yes i have worked in small teams and that was never an issue. Of course 
crazy ordering is harmful but any reasonable ordering is readable.






2) I have touched on manual memory managaement of tobjects before so I
wont rehash it here (in summary ref count tobjects and they should have
good performance with c++ style exception handling).



Good performance like python ;)?


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).


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: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] Re: [fpc-l] type discussion




On Thu, 2 Jun 2005, Jamie McCracken wrote:


Marc Weustink wrote:




What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to "decode" a  "a := b
:= c := d := 0"  line. There might be a ; inbeween which results in a
complete different assignment. With such lines I've to read them over and
over to see what is going on.
Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me.
This also counts for the proposed c-isms.

For me I prefere clarity above less typing (besides if you want to write
realy short code, you sould use APL)



I totally agree with you in this case - we dont want or need cryptic c stlye 
syntax in any version of Pascal.


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 virtually non-existant. Of course Python is 
piss poor in both performance and memory usage but it does point the way to a 
revitalised pascal. Adopting less verbose but still clean and clear syntax 
ala python is IMHO the way to make Pascal great again.


I beg to differ.

Recently I rewrote a python program (on linux). The pascal version was
shorter and much clearer to understand. The python syntax is a horror
as far as I'm concerned.

What makes python interesting are the many classes it offers by default
to perform standard tasks, especially in the text treatment department;
regular expression stuff etc.

The same goes for most languages; Mostly it's not the language syntax
that determines the productivity factor; it's the number of standard
available routines.

Quabbling about being able to type
  a:=b:=c:=d;
is beside the question. If your productivity depends on that, you're
either in the wrong business, or you are using the wrong kind of editor.
A good IDE/Editor has tools to make typing less cumbersome.

In the company where I work, 4 languages are in use: Delphi, VB, C++
and PHP. In order of descreasing productivity they are rated as follows:
- Delphi
- PHP
- VB
- C++
The order of VB/PHP was the most surprising for me; but that can maybe
be explained by the kind of app the language is used for.

Pascal is a language that allows you to develop in many styles, with as
much or as little optimization as you want, and all along it keeps your
code readable, which is very important when you work in team and you
need to read other people's code frequently. To see what I mean, try
reading this little 'gem':

int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

(better yet, run it)

Michael.

___
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

2005-06-02 Thread Jonas Maebe



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] Re: [fpc-l] type discussion

Gerhard Scholz wrote:

> Useful extensions I would see:
> 
> bigger sets: set of -10..10 (e.g.)

Ordinals are positive numbers, and only ordinals can become set
elements.
In rare cases I missed bigger sets myself, in detail in parser
generators and other automatons with many states.

> a way to write integer constants in any base, not only
> binary/octal/hexadecimal (not so important, but easy to implement)

More important: Unicode literals. But I know that this would require a
very big change to the scanner, and to all code editors and other tools.
Perhaps somebody has another idea how to solve this problem?

> more operators which can be overloaded (should follow the ALGOL68 rules)

No, please, don't open a can of worms :-(

> 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.

DoDi

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion






___
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 create.


sorry myobject is the pointer so a better example would be :

var strlist : Tstringlist;

strlist.create;


This should be easy as you know the pointer type.



Forward declarations are IMHO required because otherwise the compiler 
would have to make additional passes(it does 3 AFAIK).


They are not required in a multipass compiler. If you cant resolve a 
symbol on a single pass you can do so on a subsequent one.



Besides, they are seldom enough to be a problem.


Pain in the arse they are. Its annoying and makes use of the code 
explorer a neccsity when dealing with large classes. Its a total waste 
of my time.




How does python handle modularity btw?


WHat do you mean?

Im a Delphi programmer not a python one (though Ive done bits and pieces 
in python) but I do envy its less verbose syntax as its just as clean 
and clear.


jamie.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-l] type discussion

2005-06-02 Thread Florian Klaempfl

Jamie McCracken wrote:

> Marc Weustink wrote:
> 
>>
>>
>> What is easier to read is a matter of taste.
>> Being a pascal devel for years now, it takes time to "decode" a  "a := b
>> := c := d := 0"  line. There might be a ; inbeween which results in a
>> complete different assignment. With such lines I've to read them over and
>> over to see what is going on.
>> Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me.
>> This also counts for the proposed c-isms.
>>
>> For me I prefere clarity above less typing (besides if you want to write
>> realy short code, you sould use APL)
>>
> 
> I totally agree with you in this case - we dont want or need cryptic c
> stlye syntax in any version of Pascal.
> 
> However, in general Pascal has poor developer productivity when compared
> to modern languages like python and C#. 

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 :)

> Ironically python is perhaps the
> most popular language on Linux and most of its syntax is derived from
> object pascal whereas pascal 

Well, I wonder which languages the kernel, X windows, GNOME, KDE, OpenOffice,
Mozilla etc. use ;), definitively not python ... Python is a usuable scripting
language but nothing more.

> on linux is virtually non-existant. 

The problem with pascal on linux was/is that there was no good compiler in the
90s for linux so a lot developers got lost.

> Of
> course Python is piss poor in both performance and memory usage but it
> does point the way to a revitalised pascal. Adopting less verbose but
> still clean and clear syntax ala python is IMHO the way to make Pascal
> great again.

I wonder if Python couldn't revive Fortran with it's strange formatting rules.

> 
> Consider the developer unfirendly nature of pascal/Delphi atm:
> 
> 1) Forward declarations - they sux! Why should the developers have the
> burden of making the code totally sequential declaration wise. All other
> modern compilers dont need this. 

C++ is still the number one language and it requires it.

> Sure your code might take a bit longer
> to compile but thats peanuts compare to the time saved in extra typing
> and reordering your code

Did you ever work in a team? Then you know why ordering declarations is a good
practice because reading non sequential declarations is hard.

> 
> 2) I have touched on manual memory managaement of tobjects before so I
> wont rehash it here (in summary ref count tobjects and they should have
> good performance with c++ style exception handling).

Good performance like python ;)?



___
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] Re: [fpc-l] type discussion

2005-06-02 Thread Ales Katona


Jamie McCracken wrote:


Marc Weustink wrote:




What is easier to read is a matter of taste.
Being a pascal devel for years now, it takes time to "decode" a  "a := b
:= c := d := 0"  line. There might be a ; inbeween which results in a
complete different assignment. With such lines I've to read them over 
and

over to see what is going on.
Where a line like "a := 0; b := 0; c := 0; d := 0;" is clear to me.
This also counts for the proposed c-isms.

For me I prefere clarity above less typing (besides if you want to write
realy short code, you sould use APL)



I totally agree with you in this case - we dont want or need cryptic c 
stlye syntax in any version of Pascal.


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 virtually 
non-existant. Of course Python is piss poor in both performance and 
memory usage but it does point the way to a revitalised pascal. 
Adopting less verbose but still clean and clear syntax ala python is 
IMHO the way to make Pascal great again.


Consider the developer unfirendly nature of pascal/Delphi atm:

1) Forward declarations - they sux! Why should the developers have the 
burden of making the code totally sequential declaration wise. All 
other modern compilers dont need this. Sure your code might take a bit 
longer to compile but thats peanuts compare to the time saved in extra 
typing and reordering your code


2) I have touched on manual memory managaement of tobjects before so I 
wont rehash it here (in summary ref count tobjects and they should 
have good performance with c++ style exception handling).


3) loads of small and pointless additional syntax like EG for creating 
an object you should just be able to say:


myobject.create;

and not

myobject := Tobject.create;

also Begin..End blocks should IMO be replaced with python's indenting.

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.


jamie.


___
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 create.


Forward declarations are IMHO required because otherwise the compiler 
would have to make additional passes(it does 3 AFAIK).

Besides, they are seldom enough to be a problem.

How does python handle modularity btw?

___
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: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] Re: [fpc-l] type discussion