[fpc-devel] Re: [fpc-l] type discussion
jamie-junk at blueyonder.co.uk
Thu Jun 2 22:08:03 CEST 2005
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
> 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.
More information about the fpc-devel