[fpc-pascal] Lazarus and FPC integration

Agustin Barto abarto at gmail.com
Sun Oct 30 22:25:15 CET 2005

On 10/30/05, Felipe Monteiro de Carvalho
<felipemonteiro.carvalho at gmail.com> wrote:
> Witch unicode? UTF-8 obviously works on Lazarus as the editor produces
> and reads files in this format. I have also worked with lazarus and
> XML files, witch are normally in UTF-8.

I can't type any international characters (like accented vowels) in
the editor. FYI, mi FC4 uses UTF-8.

> > c) My capstone project did some pretty intensive numerical computing.
> > On Delphi it behaved reasonably good. The binaries compiled with fpc
> > where OpenOffice.org 2.0 slow! even with aggressive non-portable
> > optimizations (obviously this isn't lazarus problem).
> My app performed very well doing Fourier Analisys on very big waves on
> a 233Mhz machine running Damn Small Linux ... I got pretty impressed.

It was a very complex statistical analysis. Many many huge matrices.
On Delphi it took almost a day to complete a process, on fpc (running
on Windows) I had to stop it after 50 hours. Maybe I was being unfare
with fpc. It has to work reasonably well on any of the supported
architectures, while Delphi only has to deal with one.

> How does pascal imposes architectural limitations? FPC even works on ARM...

I was talking about design. One example? Polymorphism with primitive
data types can get really messy really fast with ObjectPascal. It's
not easy, for instance, to have a generic data structure that can
store *any* primitive data in a type-safe way. I have to admit that
this kind of problem can be solved, but my point was, that in other
languages this isn't an issue.

> What bad designs does it impose the programmer?? I have a big interest
> to know because I like to make a as reusable as possible code. Are you
> talking about the form designer??

Software that's designed starting from the user interface to the
behavioral parts of the program leads to some pretty nasty design
bias. We usually call this the "visual basic syndrome" :)

> I deploy over the internet to a very wide public that may use
> extremely slow computers, so I simply *cannot* in anyway force them to
> install something that cannot fit a floppy or something that requires
> a big library. And it also needs to perform very well with a easy to
> use GUI.

Good point. We usually deal with resource shortage on the client side
using a three-tiered architecture or virtual machines. If I absolutely
*have* to delegate some work on the client (maybe due to the lack of
adequate network connection), fpc/lazarus seems like good solution in
terms of portability and resource economy.

More information about the fpc-pascal mailing list