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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|
| Yeah I know this sounds like a hybrid Pascal/python but I believe thats
| the way to go - marry Delphi's speed and component framework with less
| verbose python style syntax and you will have the best RAD language ever
| written.
|

You are asking to reinvent python. If I were you, I'd just look into finding a 
python
compiler. Everything you say points to the fact that you like the way python is 
laid
out. That's fine, there's nothing wrong with different taste.


Lars


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

Reply via email to