I followed this discussion if that construction (see below) should be allowed or not (I think it should be allowed, but it's possible to live without it; I can imagine situations where it could make easier to read), and I'm missing a bit a discussion forum about the future of FPC. It should contain what is planned to be implemented, it should contain about ideas of what could be implemented.

I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail).

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)

Useful extensions I would see:

bigger sets: set of -100000..100000 (e.g.)

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

writing of enums to text file;

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

the C-style operators += etc. should better be written as  +:= since C has =
as assignment, Pascal has := as assignment symbol

automatic assignment operators:

operator * ( a : type1 ; b : type2 ) : type1

should automatically permit constructions like:

           var
             x : type1,  y : type2 ;
           x *:= y ;

multiple assignments:

     a := b := c := d := 0 ;

etc.

That are just some ideas. Maybe there are more?

Greetings

Gerhard

I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail).

Main plans short term to my knowledge are:

* create/improve the COM/OLE support. This has multiple facets: o COM compat interfaces/vmt
o Variants (needed for OLE)
o implements style delegation
* linking/debug/fileformats related
* improve smartlinking (get rid of .a files, less mem use)
* improved "packages" and dynamic libraries (PIC!) support in general.
* crosslinking (2.0 is actually quite crosslink capable already)
* stabs->dwarf crossover.
* Some form of Kylix compat resources.(still under discussion)
* Support for 64-bit (sized) native filetypes.

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

For the rest, improve RTL/FCL compability and extend them in general, and of course fixbugs.

I'd like that too.

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.

writing of enums to text file;

This should be supported, however needs some tricks. (RTTI is available for enums!)

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

IMHO this is asking for a mess, and the use is limited.

Why to save two characters? The C operators were afaik mostly added to ease porting critical C code. However IMHO one shouldn't use them in new code, and there is no need to start adding variations on the C syntax.

Same point. Totally useless.

That are just some ideas. Maybe there are more?

To judge extensions, it might be smart to check this faq item:

http://www.freepascal.org/faq.html#extensionselecthttp://www.freepascal.org/faq.html#extensionselect

which is more or less a rough view on how we (or actually more I, since I wrote it) see extensions to the language.

Except larger sets and more control about set packing is the only really interesting thing IMHO generics/templates, since it really makes heaps of new behaviour possible, and is not purely syntax that saves typing.

The wiki also contains some roadmap info:

http://www.freepascal.org/wiki/index.php/Detailed_2.1.0_branch_todo

See below

Don't expect anything. Like assigning values to enumarations we had it already before Delphi did. And also with inlining they added other rules.

You can write your own routine for that.

writing of enums to text file;

Enums are like constant numbers. You can already write them to a file
using a typecast: writeln(longint(enum));

This will break existing code. And IMHO it looks very strange with the colon in the middle.

This was in the compiler in the past and caused a lot of trouble and hacks in the parser.

That are just some ideas. Maybe there are more?

But are they usefull? Do they add something or only save you typing? THat is why there is no discussion about future on the webpages. Discussion shall take place at the mailing lists.

Marco van de Voort wrote

Main plans short term to my knowledge are: ... * improved "packages" and dynamic libraries (PIC!) support in general.

Sorry if I've been confused by "improved". Is PIC already supported?

----- Original Message -----

in my humble opinion(IMHO):

:= is based on the fact that A: is written normaly in math etc. where it means " this is a fact about A "
So when someone writes A:=5; it means "it's a fact that A equals 5" Writing A*:= is stupid. If nothing else do it like this: A:*=
But IMHO it's useless in ANY case. Even C people tend to not use it when they want readible code(especialy * which is so ambiguos)

As to the ASM:

in C if you do a+=b; and a is int b is longint it does this actualy:
a = a + (int)b;

which is stupid and unsafe.

Just my 0.05 euros

my marks start with ####:

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.

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.

It makes the code more robust and more debuggable, IMHO

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

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

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

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

Similarly, for

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

Me too.

If someone contributes the code, why not. It does not hurt, IMHO.

>writing of enums to text file; This should be supported, however needs some tricks. (RTTI is available for enums!)

Yes. Ditto.

>more operators which can be overloaded (should follow the ALGOL68 rules) IMHO this is asking for a mess, and the use is limited.

Again, agreed.

Not really useful. More like confusing, to me, that is.

In modern compilers all these shorthands from the past only create extra complexity without different results.

I checked it with the FPC (nice that there are assembler files as output); the GNU C compiler translates "arr[ii] += 1" better than FPC.

GCC will translate "arr[ii] = arr[ii] + 1" to exactly the same code. This has nothing to do with whether or not you support some syntactic sugar, but with how good the optimizer is. GCC's optimizer(s) is (are) definitely more advanced than FPC's.

Jonas

From: Gerhard Scholz
Sent: woensdag 1 juni 2005 18:35

[big snip]

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)

Marc

From:
Behalf Of listmember

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

D8}

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.

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

86E}

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.

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

99}

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

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

D3}

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

property OnChange: TNotifyList;

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

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.

Marc

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.

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.

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?

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.

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

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 ;)?

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.

Gerhard Scholz wrote

Useful extensions I would see: bigger sets: set of -100000..100000 (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

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.

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.

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

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.

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

Gnu pascal?

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

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.

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.

> 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

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.

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.

We were talking about good :)

Modern doesn't mean necessarily good ...

Ref. counting etc. eats time because you need good garbage collection to detect cycles and other ugly stuff.

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.

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.

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

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.

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.

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.

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

Michael.

listmember wrote

Inline variable initializers, such as:

...

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

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

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 ?

Sorry, the only language that does what ?

Micha

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.

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.

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.

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.

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.

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.

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.

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.

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.

ACK.

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.

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

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

Please show me a piece of code where they are "in the way". Code bloat? They don't cost anything in the executable.

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.

In C++:

TStringList strlist;
strlist = new TStringList;

How is that shorter ?

Micha

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.

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.

thats not what I meant! I mean its source code bloat to me especially when trying to follow code with large classes in it.

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!

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.

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.

A correlation of things that are independent ? Then there is no correlation ?

Micha

From:
Behalf Of Jamie
McCracken
Sent: donderdag 2 juni 2005 16:32

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

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

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

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

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

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

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

jamie.

Because the pointer might not be. Polymorphism, you know? :-)

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

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.

[...]

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.

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

Vinzent.

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.

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.

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.

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.

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

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

Same. Don't even add to productivy

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.

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

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.

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.

There was a bunch of popular languages (don't remember them all), C like were C++, Java & Perl. Others certainly were not.

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

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.

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

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.

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

Syntactic sugar. Read the faq ;)

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.

Then improve the code explorer.

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.

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.

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.

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

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.

See above.

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.

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.

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.

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

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.

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

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.

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

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

| 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

No, these are assertions not as exceptions.

Any links?

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

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

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

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

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

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

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

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

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

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

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

Op Thu, 2 Jun 2005, schreef Jamie McCracken:

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

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)

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.

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.

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

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.

(and you can, in several script languages)

Op Thu, 2 Jun 2005, schreef Jamie McCracken:

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.

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.

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

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;

grep '; forward;' *.pas

browcol.pas:  function GetDefinitionStr(def: tdef): string; forward;
scanner.pas:        function read_expr : string; forward;

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

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

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.

Op Thu, 2 Jun 2005, schreef Jamie McCracken:

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

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

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

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.

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)

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.

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

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.

Jamie McCracken wrote

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

You obviously missed that a compiler does not only consist of scanner and parser, but that optimizers and code generators also have to be implemented. For multiple target platforms and CPU's...

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)

You'll find an (incomplete) grammar, with railroad diagrams, in the syntax description. In the last version the code resides in the compiler directory, you may have to download the compiler and library sources separately. Another (simpler) parser can be found in fcl\passrc\pparser.pp, but it is not so close to the current FPC parser.

And yes, the parser is a handcrafted top-down (recursive descent) parser, easier to maintain, extend, and debug, than bottom-up parsers. Of course you can use CoCo/R for your parser, if you want an parser generator, or lex/yacc if you like, for which also ports with Pascal output are available (dyacclex, tply).

BTW, for code completion and other RAD features, a top-down parser is almost the only choice, because it allows to parse specific parts of the code (statements...). In a bottom-up parser you have little chances to find equivalent initial and final states for the parser automaton.

The safe approach is to write an preprocessor, that can translate your dialect into any implemented language, so that the compiler code must not be touched. Then you'll find out that your dialect needs code completion and other features, that have to be implemented as well, apart from the compiler. These are fine exercises before you start bothering with the compiler code.

Hmm, why don't you start with the Lazarus sources? There you'll find everything related to entering and editing source code, code explorer and other RAD features...

If you found the source code, please open another thread for further discussion. Perhaps there exists another mailing list for Lazarus?

DoDi

It's not much worse than C++ in typical projects (which has, I admit, much to do with the people using it).

You know that about 90% of all installed computer(chip)s are actually embedded systems? So I'd consider this "mainstream software" a niche. :-)

The study was measuring error rate in some typical and rather simple prgramming task coded in varius languages by varius programmers. Correlation found was clear -- number of bugs per 1kloc were constatant

What figures did they give? I'm curious.

and independent of the language. The difference was that the same task could be coded in some languages using significantly lesser number of lines.

Which is quite irrelevant once you've got to maintain it.

Two things: 1. They'd better claim they got significant gains or someone should be fired for wasting money. IOW I take all such corporation made studies not with a grain but with a shuffle of salt.

Even the salt doesn't taste away the fact that they were on-time, on-budget and testing the software more or less deviated to simply showing that it works. And considering that most money is spend in the testing phase (well, of course, especially in that particular domain), the 80% aren't that surprising after all.

2. You're talking about complex life-critical realtime system, not mainstream software.

Yes, true. Funny thing is, that those companies are now almost able to deliver software cheaper than the mainstream. If they would cut the testing completely, they definitely could and the software wouldn't even be as worse. (BTW, that's my own observation, not some study.)

In such system the cost of bugs is many orders of magnitude higher than in mainstream. Cost structure of such projectes differs stronly from mainstream programming.

Yes. The main costs goes into testing. Which, in main stream software, is done by the customer and he even pays for the bugfix called upgrade. So, of course, testing is a bad thing. You can earn less money with it and it even costs you.

Is that what you're trying to tell me?

I'd guess, in that test, languages like Pascal or Ada would get an even worse rating than C. Because these are languages that focus on design and doing it right instead of focusing on doing it fast. Which, in practice, means you get compilabe code much later, but in the end this code is more likely to be correct. So it all depends on what you measure.

Did they take maintenance into account? (I just ask, because that's what I am being paid for for the last 5 years and I guess, I am not the only one out there who gets paid for this kind of development).

Not necessarily.

Besides lack of convincing argumentation about compiler correctness,

Realtime doesn't necessarily mean correctness. A while ago I talked to one of the developers working for a electronic company who wrote the code for a television. He told me, that in the final system, there would be about 140 running threads. That's definitely not small scale and judging on how often I had to reboot my Nokia phone by removing the batteries, it doesn't mean correctness either.

you need real time guarantees wrt allocations and other library stuff (which FPC does not provide).

No. Simple rule: Don't allocate at runtime.

And for how many years they had to maintain that code?

I do that too, if it's necessary (and on a 8 MHz 286 with 128K RAM it is). No big deal. You know, I even make less mistakes then than I usually make in C.

Yeah, right.

And with a "class NoHeapRealtimeThread" you even circumvent garbage collection completely.

Of course, stuff like Lisp is perfect. Problem is, nobody wants to use it, either.

So what? The only proof I see is that the optimizer can be done better.

Ocaml code is significantly shorter too (they can be coded in significanly lesser amount of lines).

Hmm. Funny thing is, if you compare Ada95 and Free Pascal, the test claims that Ada95 uses much less lines of code either. And considering that

|function Foo (const I : Integer) : Integer;
|begin
|   ...
|end;

in Ada looks

|function Foo (I : in Integer) return Integer is
|begin
| ...
|end Foo;

which is the same amount if you count in LOC (and even more verbose), either the Pascal code is unnecessarily complex or something else was wrong. It just doesn't correlate with the praxis.

Vinzent.

Jamie McCracken wrote:

[snip]

Hmm.... less to write... and maintain ?

Go for example to the lazarus project and try to write the controls.pp unit this way. Do you still think it is a good idea ? When all code is put in the class header itself, can you still tell what methods a class has ?

Besides, when we are at Lazarus (or Delphi), when you have typed

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

and press ctrl+shift+c it will generate the whole body. Which is already less typing :)

You have to type even less if you start with

classf

and then press ctrl+j

So what is the point to make the language less clear, while there tools exist which do most of the annoying typing for you ?

Marc

OK, what to do if an invalid input is met ? Continue ? Skip ? Abort ? IMO you still need some code which takes proper action

http://www.freepascal.org/wiki/index.php/Generics

Which is allmost the same as a virtual abstract Getter and Setter (almost, read/write from a field isn't covered)

That makes some sense (but it would be incompatible with existing code)

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

:-)

Not if you have generics ;)

Not too. It is still edited at one place.

Marc

not a problem for an IDE - it can extract the methods and in fact visual studio does that for c#. And likewise with the code explorer in lazarus.

It makes it more clear IMO not less. having all that interface code and having to jump between it and the implementation does not aid legibility. Having it all nicely tied up in my proposed Rad Pascal, C# and python does.

Those lazarus tools are great but they require advance knowledge of those tools that new users wont have (at least somebody using lazarus for the first time is not going to know all the keyboard shortcuts). Not having to rely on hacks around the coding inefficiency of a language with keyboard shortcuts is always a plus in my book too.

At the end of the day, if you dont like my new dialect then dont use it
- stick to {$mode objfpc} in your code. I want to offer you a new dialect that should hopefully make your life easier but if it does not then fair enough.

jamie.

Jamie McCracken wrote

It makes it more clear IMO not less. having all that interface code and having to jump between it and the implementation does not aid legibility.

It encourages reading code instead of interface specifications. Often there is a big discrepancy between what the code is supposed to do and what it really does. If a fellow programmer relies on the latter this is known to break sooner or later.

Of course, this implies that there *is* a specification.

Vinzent.

Thanks for the offer, where can I download the patch? I would like to try this too.

Vincent.

The latter it should.

Well, it is still named "begin", "end", not "x0x0x0" "0x0x0x", is it? ;-)

And for the compiler: it wouldn't make a difference if you'd parse "begin end" or "curly braces" tokens, would it?

Yes, it might make the compiler writer's job easier. But typically you don't design a language around a compiler. And I strongly doubt that Wirth did.

Vinzent.

Patience! Its vapour ware at the moment.

Im just familiarising myself with the compiler source at the moment so give me a few months to implement it. Once I have something I will post a patch here.

Glad to see some of you are interested in it :)

jamie.

----- Original Message -----

You have a point here. That, I suppose could be handled through runtime options. But, a construct something like

require
[...]
otherwise
[...]
end;

ensure
[...]
otherwise
[...]
end;

would be needed.

Thanks.

Why would it. Existing code does not have virtual properties.

Of course C is much worse than contemporary C++ (C++ + std::).

Count separate apps not separate instalations.

I don't remember. I read the paper over a year ago.

Smaller programs are easier to maitain.

This could also be that they simply properly planed for the unknown. You can do most of apps withing time & bugget even in pure machine code if you'll assume huge enough budget and long enough time.

[snip]

The same functionality?

No. Simply preventing some failure is economically viable if cost_of_failure
* probality_of_filure > const_of_prevention.

In systems you're talking about const of failure is enormous, so you can spend on prevention till probablity of failure is really, really small.

Nope. There was enough time to develop the app in all but some ackward joke languages. Problem was simple & well understood.

Because these are languages that focus on design and doing it right instead of focusing on doing it fast.

All languages require design.

Which, in practice, means you get compilabe code much later, but in the end this code is more likely to be correct. So it all depends on what you measure.

They measured the number of actual bugs in code declared by the author as ready to deploy.

[snip]

You were talking about flight control system...

And this is example of what? For me it's just sloppy programming. Lot of that Nokia stuff isn't realtime either (it maybe should, but it's not).

If you have fixed amount of data the fine. But if not then it's rather hard.

[snip]

That's the reality. Just look at properly designed languages, not Java.

Java is so but because it uses bloated objects for virtually everything. Want to store few int numbers into a list? You must encapsulate every int into Integer class object. You want to write some values out into a file -- you have to create a cascade of objects to do that.

It's as true as nobody wants to use Ada... IOW both are used in niches, but both *are* used.

See comparison with C. They're more or less equal performance wise.

But what is that '...' is what matters.

In C you'll also get

int Foo(int i)
{
...
}

which is the same amount if you count in LOC (and even more verbose), either the Pascal code is unnecessarily complex or something else was wrong. It just doesn't correlate with the praxis.

Probably Pascal examples are poor (it was already signaled on this list). But don't forget that Ada is more verbose but is also somewhat more expressive (compare the typesystems for example). More expressive languages allow for more concise programs.

rgds

Only in theory. Look at typical projects in the industry.

Doesn't change the count much, I think. Every f*cking microwave oven has its own control program these days.

I'm just asking because somebody from a car company claimed that one bug per 1000 SLOC would be "the normal expected amount" and I got a study here that claims a bug rate of less then a tenth (0.096 defects/KSLOC [and even for their C-Code, they had 0.676 defects/KSLOC]) for "just a compiler and related tools", not for potentially life-critical systems as you'd expect in the 70 or more microprocessors a modern car has built in.

Which seems quite surprising considering that the bug rate should be practically independent of the language (ok, this statement is not valid for C99, of course, it's the only exception there). Sarcasm included.

Yes, but small programs are not the typical project. Even small projects break through the 100 KSLOC barrier very quick.

Of course they did, they are not bloody id10ts and it was not their first project of this size. It was just the first that was much cheaper than ever expected.

You can do most of apps withing time & bugget even in pure machine code if you'll assume huge enough budget and long enough time.

Considering that it wasn't government money they had to waste, instead they took the risk of the whole development theirselves, this certainly wasn't the case here.

Yes. MULTOS/CA had 0.04 defects per KSLOC with an average "productivity" of 28 lines of code per developer per day, if I remember the figures correctly.

Yes. But Cost_Of_Failure sometimes seems to be a negative amount while Cost_Of_Prevention never is.

Yeah. The latter may be the problem. Most real world problems are neither simple nor they are well understood just until after you solved them. :-)

> Because these are languages that focus on design > and doing it right instead of focusing on doing it fast. All languages require design.

But they encourage it in different scales.

We were mainly talking about FPC. I'm crazy, but I'm damn sure not crazy enough to recommend FPC for such kind of system.

The example of a typical commercial, industrial (embedded) project?

For me it's just sloppy programming.

Exactly. The point is: some languages just make it harder to do so and some languages make it even harder *not* to do so.

Lot of that Nokia stuff isn't realtime either (it maybe should, but it's not).

Lot's of the code in a realtime environment is not real time. The 80/20 rule probably applies to almost everything. ;-)

Yes, it is. OTOH I know the memory map out of my head. :)

I'm looking at the stuff that gets used most often, because it must be superior then, otherwise nobody would use it. But i.e. Python's automatic memory system didn't convince me any bit more, although it seems more effective to me.

Yes, as Pascal is. Used by me, for instance. In a commercial industrial application. And I *do* have less bugs than my fellow programmer who does Python (although I'd like to see it differently, because of the dynamic typing) and although the amount of code I maintain is about five times as big.

The productivity gain he gets from Python is that he can fix the bugs faster because he doesn't need to compile anything. Just change the source.

What?

http://shootout.alioth.debian.org/
benchmark.php?test=all&lang=icc&lang2=ocaml&sort=fullcpu

doesn't look much *equal* to me. Maybe, my feeling for numbers is screwed up.

Yes, of course. But we were talking about verbosity in general and not on the amount of standard libraries.

Probably Pascal examples are poor (it was already signaled on this list). But don't forget that Ada is more verbose but is also somewhat more expressive (compare the typesystems for example).

Especially the type system accounts for a lot of writing work if you want to do it "the right way".

For an example, take a look at

http://www.t-domaingrabbing.ch/tmp/
elan520-sdram_controller_registers.ads

It's really nasty when you just consider the writing work. :)

More expressive languages allow for more concise programs.

To be honest: I wouldn't expect much difference between Ada and (Free)Pascal programs in terms of lines of code there. But I'd expect a difference in terms of declaration lines and in FreePascal a much lesser amount of needed code because of the relatively large amount of libraries you can use (which usually don't account for SLOC).

Vinzent.

I think we're mostly offtopic now, maybe we should EOT or move to private

Vinzent Hoefler wrote

>Of course C is much worse than contemporary C++ (C++ + std::). Only in theory. Look at typical projects in the industry.

I have close look at the projects in my company. And the difference is snignificant.

>Count separate apps not separate instalations. Doesn't change the count much, I think. Every f*cking microwave oven has its own control program these days.

I suspecct that owens from the same manufacturer have the same program or their programs differ only minmally. Then how complex those programs are?

Now look how many different general computing apps are out there? The count goes in millions, i think.

Depends how the bugs were counted. In the study I talk, AFAIR there was quite a variation between solutins, but no correlation of defects/kLoC to programming language was found.

>Smaller programs are easier to maitain. Yes, but small programs are not the typical project. Even small projects break through the 100 KSLOC barrier very quick.

Smaller small. But it's generally easier to mainatin 100 kSLoC vs 200 kSLoC system.

Lokheed-Martin not wasting goverment money!?! That's something new ;)

But kSLoC kSLoC. What amount of functionality was there is also important.

That's true only in some special cases, and mostly if you're monopoly. But even MicroSoft had to improve their soft. Sales lost due to customet dissatisfaction are also cost of failure.

Well, I'd say that most of the software is doing the well understood stuff only slightly differing from things already done.

You're joking, right?

But i.e. Python's automatic memory system didn't convince me any bit more, although it seems more effective to me.

Pyhton is not very concerned with performance. Besides there are dynamically typed languages much faster than it (Dylan for example).

The difference is not big. It's allmost the same as with C++ vs C.

Hmmm... Verbosity is not important. Expresiveness is. You can have language with verbose or not verbose constructs, but wether those constructs are expressive or not is an orthogonal matter.

C constructs are typilcally non-expressive and not verbose. Standard Pascal construct are verbose but not too expressive. Object Pascal (i.e. FPC) is more expressive. Ada, C++ with std:: or OCaml are even more expressive.

Well, quite a lot of SLoc is consumed by simple stuff not requiring large standard library. Personally I don't like languages with bloated standard library (case example: Java). At some point you'll lose more time looking for library feature to solve your problem that actually solving it yourself.

Not to mention that such large bloated libraries are quite often full of bugs. Your app will be no better than library it uses.

So often relatively simple things are what make or break expreiveness. C vs Pascal example: set -- try acheiving the same in C. But there is more of that stuff like maps/dictionaries, dynamic arrays, autmatic destructoe calling at the end of scope, etc. Or even automatic memory management.

In one lang you'd have to write:

for i:=1 to len(arr) do begin
   if arr[i] = 0 then
     break
end;

And in anther:

i := find(arr, 0);

And in yet another:

i := arr.Find(0);

Verbosity of the particular constructs is the same (all are Pascal variants), but 2 later have better expresiveness of their basic datastructures.

rgds

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.

Then you may have a bad exception handling model. Try-Finally is required only when there are chances that an exception will abort the current subroutine. Can't you find a less expensive method for steering the regular control flow, besides by throwing exceptions? Do there really exist so many situations, where an action frequently is aborted due to some error, so that such occurences can be considered as "normal operation"?

DoDi

What do you mean with "Tobjects"? Isn't TObject the ancestor of all classes?

If you mean a dedicated root class for reference counted objects, you can use interface instead of class variables (at least in Delphi, not sure about FPC).

As was already pointed out, GC doesn't work well without assistance in actual code. There's no big difference between setting a reference to Nil, and calling the destructor or FreeAndNil, for the same purpose.

Auto-destroyed local objects, or local interface references, require hidden try-finally blocks; from similar discussions I know that many people don't like such invisible magics, for performance and othX-Mozilla-Status: 0009

Editors with macro capabilities are not hacks, and the shortcuts for macro invocations are not built into the editors. You'll need equivalent macros for maintaining an indentation structure, and, even worse, you're almost lost without such macros, due to the lack of redundancy!

DoDi

Hans-Peter Diettrich wrote

You obviously missed that a compiler does not only consist of scanner and parser, but that optimizers and code generators also have to be implemented. For multiple target platforms and CPU's...

The new dialect simply makes the syntax less annoying and verbose - it wont alter functionality as such so altering those shouldn't be on the agenda (I hope!).

The new dialect simply requires a multi pass parser. It shouldn't be too hard to adapt the existing one for this purpose. Of course the compiler will only use this if the source file tells it to use Rad Pascal dialect so it wont affect or harm compiler performance of other dialects.

I can also totally eliminate circular refs in the multi pass phase (it will require three passes if there are circular refs, otherwise one or two passes will be sufficient). The advantage for the developer here is that only one uses clause ever needs to be used.

Looking at the tokens.pas file in the compiler, every token in the parser is specified against which dialect implements it (via the mode switch) so it shouldn't be too difficult to remove any redundant syntax where its not needed. (I emphasize removing not adding syntax here!)

I had thought of that but thats problematic for debugging. IE the compiler returns line numbers for errors and they will not match if I use an external preprocessor.

For replacing Begin..End blocks with indents in my new dialect I planned to use the compiler's internal preprocessor in the compiler to put back the begin/end blocks without affecting the line numbers. I can do likewise for syntactic sugar.

If you or anybody else has advise on how best to implement it then
please let me know - I apreciate anything that will help me here.

Thanks

jamie.

Jamie McCracken wrote

I had thought of that but thats problematic for debugging. IE the compiler returns line numbers for errors and they will not match if I use an external preprocessor.

See the recent thread "How to manually control debug information" in this list. I asked the very same thing.

I've been playing with the same concept for years, so I think I do have some advice :-) The preprocessor is the right step to start. I have a working scanner and the next tasks (conditional "compilation" and expressions) planned in detail. If you're interested, we could share the work.

I admit I hadn't read it before but I already knew an external preprocessor was more a last resort cause of the hacky nature of correlating virtual line numbers to physical line numers.

Which the compiler's internal preprocessor or your external preprocessor?

I prefer the internal one cause it means no external dependencies but then again if its too dificult to use...

. I have a working

scanner and the next tasks (conditional "compilation" and expressions) planned in detail. If you're interested, we could share the work.

If I get bogged down with the compiler internals then yes I'll be happy to collaborate then. As I said IMO the external stuff is a last resort to me not a first but thanks anyway for the offer - I will be in touch if I need an external one.

jamie.

Internal, if all you want is to create a new dialect to integrate inside FPC as {$MODE RADPASCAL} and you are sure your patches will be accepted by core developers.

External otherwise. I want something more than this kind of arrangement, so I chose external. YMMV.

Hi,

I'd suggest creating tlist, tstringlist, tfilestream-like things with an optional owner (TComponent-like). I've been programming delphi for years, and trust me, I know how annoying keeping track of tlist memory is (and I mean _annoying like hell_ :)). Of course having to cast around list content is even more annoying. But 'm trying to fix that now, in fpc.

TInterfacedObject works in fpc too. works fine. Using it all the time :)

As was already pointed out, GC doesn't work well without assistance in actual code. There's no big difference between setting a reference to Nil, and calling the destructor or FreeAndNil, for the same purpose.

Setting a reference to nil works automagically (user doesnt need to do it).
Only remaining serious problem are reference cycles. And thats a BIG problem (see old java versions and swing, and you will see... its the horror).
But it still 'only' means you have to set 'some' references to nil manually. Which is ugly. Either all or none would be cleaner :)

To offset that danger, I've been trying to get weakref on interfaces to work, but its actually non-trivial to get that to work cleanly without using your own tinterfacedobject everywhere (which is a 'cant do'-like thing when using other people's com objects) ... too bad. What I mean is:

type
  TXyz = class(TInterfacedObject)
    parent: IWeakref;
    constructor Create(const parent: IInterface);
    procedure someCallbackSoIKnowParentIsGone(whereitwas: Pointer);
  end;
  constructor TXyz.Create(const parent: IInterface);
  begin
    parent := TWeakref.Create(parent);
    parent.OnDestroy.Add(someCallbackSoIKnowParentIsGone);
  end;

ideas ?

It always depends on what you are trying to do. If you are building huge systems, you wont care about some hidden try-finally blocks you would have needed at the same places and of the same count regardless. And choice is good, so as long as you can use the old way, who cares. But wait, you already can use both ways (reference counted and non-reference counted). So what's this talk about anyways ? There need to be reference counted list/map/... units ? I know, working on it :)

cheers,
Danny

you *might* have less overhead using ref count on a tstringlist then making it a component (if you are creating more than one reference to it or passing it as a parameter to a function then yes a component would be more efficient). You also have the problem of what you are going to set the owner to in the case where its only a temp variable.

ref cycles are not a big deal - show me one bit of the FCL that has cycles using Tobjects only (IE not with Tcomponents)!

Its obvious that you wont have cycles in things like TstringList, TFileStream objects etc.

In fact only in Tlist are you likely to have cycles and in the add method you could check to make sure no self references are added and throw an exception if they are. A knowledgable developer can of course set any object to nil if he knows that there are or likely to be cycles but again this will only happen in a very small minoirty of cases.

I would implement ref count on TObjects with a protected boolean variable to turn it off for TComponent descendants as we dont need to ref count components and components by their nature are far more likely to have cycles then plain objects.

Its also obvious that pascal by its nature is far better suited to efficient ref counting than others like java because java strings are objects and ref counting a whole load of short term objects can adversely affect performance. (imagine deleting a stringlist where all the strings are objects - you would have to call dec_ref on all the strings and thats why ref counting is considered slow especially with java)

I am asserting that ref counting in pascal would probably have a much lower effect on overall performance as a result. Ref counting objects with long life spans is actually far more cpu efficient than any GC scheme (and thats why the best performing GCs are hybrid GCs which actually ref count globals and all objects that survive multiple generations). In fact unless you are creating loads of temporary short lived objects in your code, the overhead of ref counting should be acceptable in most cases and of course you can optimise your code for ref counting by using more global vars instead of temps/passing them as parameters to functions etc.

But we cant test out any of this until we have c++ style exception handling so its performance or lack of performance is just speculation at the moment.

jamie.

Hi,

owner nil, and free later

I dont know the fcl enough for that.

But generally speaking, most (nice) trees have that problem actually.

TXMLNode
Parent: TXMLNode

  Children: list(TXMLNode);

ref cycle:

a: TXMLNode;
b: TXMLNode;
a := TXMLNode.Create;
b := TXMLNode.Create;
a.Children.Add(b);
b.Parent := a;

not freeing anything:

a := nil;

not freeing anything:

b := nil;

not freeing anything:

a := nil;
b := nil;

For gui stuff, it like happens all the time... for tree stuff, it like happens all the time ... hmm

and pascal strings are ?

what is that ?

jamie.

cheers,
Danny

yeah and now you are back at manual management.

Good point but are trees like that the exception or the rule? I mean Delphi's TTreeview's TTreeNode is not cyclic AFAIK.

however they are better implemented using Tcomponent where the parent objects can automatically free the children. In any case we would need weak refs to overcome problems like these in tobjects.

so in your code we would have something like:

b.Parent := weak (a);

where weak() prevents the ref count from incrementing. Or a quick hack would be to manually dec the ref count (assuming we provide a public Tobject method for this) after that assignment. What we shouldn't do is rely on the developer who is using the class to nil it at the end cause that defeats the whole purpose.

I admit its not perfect but exceptions like these should hopefully be few and far between.

Absolutely, which is why components will not be ref counted

for tree stuff, it like

happens all the time ... hmm

dunno - its hard to say how common occurances like your example are as all the trees I have recalled using have not been cyclic like that.

records or pointers to records. If you use shortstrings then it will be fast cause they are not ref counted. Java strings by comparison are classes so they will always suck in this regard.

jamie.

I've implemented such classes years ago, and according list and tree view controls for easy display. The classes are derived from TStrings, widely compatible with the remainder of the VCL. I also use bidirectional member/owner links, so that a destroyed member can inform it's owner appropriately, and the display and navigation in trees requires no further stacks or treeview structures. In fact it's sufficient to pass a reference to some existing TStrings structure to my controls, then that structure is displayed automagically, without the need for hidden copies or other crap, as occurs with the traditional controls.

DoDi

Consider the communication between the parser and the code generator. I'm not sure about FPC, but usually a parse tree is generated first, then the remaining code works with that parse tree. Herefore your parser will have to create a tree structure that is compatible with what the compiler expects.

The new dialect simply requires a multi pass parser. It shouldn't be too hard to adapt the existing one for this purpose. Of course the compiler will only use this if the source file tells it to use Rad Pascal dialect so it wont affect or harm compiler performance of other dialects.

Hmm, I wonder how a multi pass parser fits together with RAD ;-)

OTOH, are you sure that more passes really are required? Many languages require that the parser must know about the declaration (or type) of every identifier. This is not a requirement for Pascal!

The requirement for forward declarations can be replaced by an appropriate symbol table implementation, which allows to add the declaration to every identifier later. The implementation only must assure that *subsequent* declarations or definitions are added to the correct *previously* entered identifier.

AFAIR a solution was already posted?

If you or anybody else has advise on how best to implement it then please let me know - I apreciate anything that will help me here.

See my above suggestions ;-)

DoDi