Recent

Author Topic: The future of Free Pascal  (Read 228524 times)

Edson

  • Hero Member
  • *****
  • Posts: 1301
Re: The future of Free Pascal
« Reply #105 on: April 14, 2016, 09:49:48 pm »
So, I'm curious: what would Modula 2 / Oberon do better?

The syntax. No need to use too many begin-end. It simplifies typing in most of the cases.
Lazarus 2.2.6 - FPC 3.2.2 - x86_64-win64 on Windows 10

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: The future of Free Pascal
« Reply #106 on: April 14, 2016, 10:31:17 pm »
So, I'm curious: what would Modula 2 / Oberon do better?
Oberon also has OO style that inspires other mainstream languages, Java and Go being the most prominent. I mostly like the amalgamation of interface and implementation section, by using markers for access modifier. Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP). And oh, the grammar is damn simple, much simpler than OP although providing less language integrated features, but proven to be sufficient to even write an operating system.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2770
    • havefunsoft.com
Re: The future of Free Pascal
« Reply #107 on: April 15, 2016, 03:11:20 am »
Even Microsoft supports Pascal (both Delphi and FPC)  these days.
 :D

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: The future of Free Pascal
« Reply #108 on: April 15, 2016, 11:28:41 am »
So, I'm curious: what would Modula 2 / Oberon do better?
The syntax. No need to use too many begin-end. It simplifies typing in most of the cases.
I also prefer such syntax. I have it in AvrCo Multitasking Pascal for AVR microcontrollers and it's really nice. The only thing I miss more is try..except..finally..end block written in one shot. These 2 things would make code even more readable.

Code: Pascal  [Select][+][-]
  1. try
  2.   if TestCondition then
  3.     DoThing1;
  4.     DoThing2;
  5.   else
  6.     DoThing3;
  7.     DoThing4;
  8.     DoThing5;
  9.   end;
  10. except
  11.   HandleException;
  12. finally
  13.   FreeAnythingCreated;
  14. end;
« Last Edit: April 15, 2016, 11:30:40 am by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

Windsurfer

  • Sr. Member
  • ****
  • Posts: 368
    • Windsurfer
Re: The future of Free Pascal
« Reply #109 on: April 15, 2016, 05:11:11 pm »
I agree with the convenience of a try..except..finally..end written in one shot. I frequently use a try...try...except...end..finally... end block.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: The future of Free Pascal
« Reply #110 on: April 18, 2016, 03:51:51 pm »
I agree, that would both be nice.

serbod

  • Full Member
  • ***
  • Posts: 142
Re: The future of Free Pascal
« Reply #111 on: April 18, 2016, 04:05:45 pm »
Yes, 'begin' and 'try try' is annoying.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: The future of Free Pascal
« Reply #112 on: April 18, 2016, 04:47:06 pm »
Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP).

The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.

If you have two threads, that both access the same variable, you are encouraged to use a mutex to lock and unlock that variable. This is how it is done.

And that's totally the wrong way to do it.

Every time you lock the variable, you serialize the application. And not only that, but it incurs a large overhead and makes context switching take ten times as long:

- The shadow registers need to be cleared.
- The pipeline needs to be flushed.
- The cache memory needs to be partially flushed.
- the page tables need to be refreshed.

In the time that takes, the CPU could have done more work than a 8086 could do in a whole second.

Ergo, working like that makes your application slower instead of faster.

That's why the amount of CPU cores on Intel x86 processors first climbed up to 16, and is now back down to max four. Simply because few people have figured out how to use them effectively.

Essentially, you need to give each thread its own (thread-safe) message queue, which triggers execution on post. And use that for both events as well as data passing. That increases the latency, but the throughput as well.

There should be no shared memory. If you want to pass a block of data, allocate it on the heap, post the pointer and nil your own copy of the pointer.
« Last Edit: April 18, 2016, 04:52:29 pm by SymbolicFrank »

Graeme

  • Hero Member
  • *****
  • Posts: 1428
    • Graeme on the web
Re: The future of Free Pascal
« Reply #113 on: April 18, 2016, 05:14:58 pm »
Code: Pascal  [Select][+][-]
  1. try
  2.   if TestCondition then
  3.     DoThing1;
  4.     DoThing2;
  5.   else
  6.     DoThing3;
  7.     DoThing4;
  8.     DoThing5;
  9.   end;
  10. except
  11.   HandleException;
  12. finally
  13.   FreeAnythingCreated;
  14. end;
  15.  
I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making. What if your code block has an if..else statement in it as well. The compiler might interpret it one way, each developer might interpret it another.

Code: Pascal  [Select][+][-]
  1. try
  2.   if TestCondition then  //  (1)
  3.     DoThing1;
  4.     if DoThing2 then   //  (2)
  5.       DoThing21;
  6.   else                //  (3)
  7.     DoThing3;
  8.     DoThing4;
  9.     DoThing5;
  10.   end;
  11. except
  12.   HandleException;
  13. finally
  14.   FreeAnythingCreated;
  15. end;
  16.  

Is (3) the else part of (2) or (1)?  You might figure it out eventually, but others might not. It doesn't make the code easy to read. Thus not very Pascal-like. No thanks - I'll prefer the begin..end block syntax. It adheres to the Pascal-style, making code easy to read, write and understand.

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: The future of Free Pascal
« Reply #114 on: April 18, 2016, 05:19:57 pm »
You're missing an "end". It won't compile like that.

BeniBela

  • Hero Member
  • *****
  • Posts: 905
    • homepage
Re: The future of Free Pascal
« Reply #115 on: April 18, 2016, 06:10:38 pm »
try .. except is also annoying if you have to catch multiple exceptions.

Like

Code: [Select]
try
...
except
  on e: E1 do ...
  on e: E2 do ...
  on e: E3 do ...
end

instead a simple on e: E1 | E2 | E3 do




The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.


Perl's variables are thread local at default.

Smalltalk has message passing

Qt has a similar signal/slot mechanism

Go has its channels

In functional languages variables are immutable, you do not need locking

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: The future of Free Pascal
« Reply #116 on: April 18, 2016, 06:54:13 pm »
The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.

If you have two threads, that both access the same variable, you are encouraged to use a mutex to lock and unlock that variable. This is how it is done.

And that's totally the wrong way to do it.

Every time you lock the variable, you serialize the application. And not only that, but it incurs a large overhead and makes context switching take ten times as long:

- The shadow registers need to be cleared.
- The pipeline needs to be flushed.
- The cache memory needs to be partially flushed.
- the page tables need to be refreshed.

In the time that takes, the CPU could have done more work than a 8086 could do in a whole second.

Ergo, working like that makes your application slower instead of faster.

That's why the amount of CPU cores on Intel x86 processors first climbed up to 16, and is now back down to max four. Simply because few people have figured out how to use them effectively.

Essentially, you need to give each thread its own (thread-safe) message queue, which triggers execution on post. And use that for both events as well as data passing. That increases the latency, but the throughput as well.

There should be no shared memory. If you want to pass a block of data, allocate it on the heap, post the pointer and nil your own copy of the pointer.
And that's why concurrent programming is considered a different paradigm ;)
When coded properly, concurrent programming DOES make your app runs faster. Try my UPX wrapper, compress tens or hundreds of exes/dlls/whatever file type UPX can handle. Compare the total time taken with thread count = 1 and = number of cores in your CPU.
No problem with concurrency if one pays attention to the limiting factors. In my company, I create a concurrent message queue processor. If different kind of message are in sequence, they are processed in parallel without waiting. This increases the processing speed, A LOT, especially in case of heavy traffic situation because the request processing is less likely to timeout.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: The future of Free Pascal
« Reply #117 on: April 18, 2016, 06:58:21 pm »

Bad example. If you do this, end becomes mandatory, and every block is terminated by end eventually. (since if then else end is considered one statement it only has one end)

So

Code: Pascal  [Select][+][-]
  1.   if TestCondition then  //  (1)
  2.     DoThing1;
  3.   end; // <- HERE
  4.     if DoThing2 then   //  (2)
  5.       DoThing21;
  6.   else                //  (3)
  7.     DoThing3;
  8.     DoThing4;
  9.     DoThing5;
  10.   end;
  11.  

The rest is perfectly valid in M2, and actually a better blocksyntax than Pascal (no dangling else)

guest58172

  • Guest
Re: The future of Free Pascal
« Reply #118 on: April 18, 2016, 07:03:43 pm »
Perl's variables are thread local at default.

Smalltalk has message passing

Qt has a similar signal/slot mechanism

Go has its channels

In functional languages variables are immutable, you do not need locking

D also has all its variables on the thread local storage (TLS), unless they are annotated with "__gshared" or "shared", and two multi thread paradigms: "MessageBoxes" that allow to easily send receive between threads and "Tasks". Even with mutable data you don't need to lock all the time, but only when you access non-TLS data. I think all modern compilers do something like that nowadays.

Actually I'd surprised if someone tells me that FPC doesn't put the variables declared in a class or a struct on the TLS.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: The future of Free Pascal
« Reply #119 on: April 18, 2016, 09:58:04 pm »
And that's why concurrent programming is considered a different paradigm ;)
When coded properly, concurrent programming DOES make your app runs faster. Try my UPX wrapper, compress tens or hundreds of exes/dlls/whatever file type UPX can handle. Compare the total time taken with thread count = 1 and = number of cores in your CPU.
No problem with concurrency if one pays attention to the limiting factors. In my company, I create a concurrent message queue processor. If different kind of message are in sequence, they are processed in parallel without waiting. This increases the processing speed, A LOT, especially in case of heavy traffic situation because the request processing is less likely to timeout.
Well, of course. I agree.

There will always be some overhead, but it can be minimized. Although the best way to do it would require a specialized OS (to swap the page tables).

If you do it right, your application will scale greatly.

 

TinyPortal © 2005-2018