[fpc-pascal] Re: What is the most widely used Pascal on Linux and other Unix variants?

[Noah Silva]

Hi,

2012/2/28 Lars <noreply at z505.com>

> Frank Church wrote:
> > 5. This requires an increase in the uptake of Pascal. I mean if a
> language
> > like D can get so much attention and have libraries being created for it
> > why can't Pascal which has been longer established.
> >
>
> Another language to check out is TutorialD by Date and Darwen, a pascal
> like relational database language. Another interesting one which there is
> almost no information about is "Pascal/R" which was a relational pascal
> that died quickly, but I don't know why.
>
> Certainly there are a lot of interesting languages.  I also find Oberon
and Modula fascinating - the problem is that when you get into "research
languages", actually getting them to interact with the rest of the system
gets to be a burden.  For example, FPC now has ObjectiveC compatibility on
Mac OS X, and FPC/Delphi can use C headers with trivial translations on all
systems.  Making obscure API calls can be nearly impossible in some
languages, or involve a large amount of work - the situation with having to
translate header files is bad enough.  Add to that the availability (or
lack of) native libraries to do routine tasks - This is something that
languages like C and Java excel at, and basically doesn't exist for more
research-oriented languages.  FPC is somewhere in the middle.

>
> > 6.  I guess one major shortcoming of Pascal is it is not immediately
> > identified with objects, like C. Can Free Pascal simply change its name
> to
> > Object Pascal
>
> Not all of freepascal is object oriented, a lot of it is simple procedural
> and you have the option to use objects if you want. Java and Ruby make the
> grand mistake of making everything an object and forcing you to code in
> objects when you shouldn't have to.


I agree here.  The idea that objects are automatically better for
*everything* is a bit much.  If an object is a noun, a procedure is a verb.
 Objects are useful when you need to encapsulate and track state, and are
extremely useful in some areas (i.e. GUI operations, tracking handles,
etc.), but of little value in certain other areas.


> C# the ugly java rip off language also
> forces you into objects and classes.


To be share, C# is better than Java in some ways, despite being a rip-off.
 It has the advantage of hindsight, so they could do some things
differently than Java and Delphi.  (We the main designer of C#, right?)


> If IntToStr was welded in to some
> object and I had to create an "IntToStr object" before calling IntToStr,
> that would suck major.
>
> Agreed.  I would assume that should be a class method, at least.  The way
it works in Java, iirc, is that the "toStr" method would be a method of the
Integer class.  Obviously, making even the lowest level types into Objects
will exact a performance penalty.


> What would be nice is some actual innovation in programming languages
> instead of reinventing C++ over and over again.  I think what
> languages... ....

a database table that you can create easily in your language instead of

resorting to embedding SQL strings into your program.
>
> I am an ABAP programmer by day, and I have to say that although I find
ABAP primitive in some respects (f.e., no WITH ... DO functionality,
annoying spacing rules, etc.), the data type, library, and most notably,
database functionality is a dream.  It's too bad that the language is
heavily tied to SAP.  In ABAP, you can declare variables to be of the type
of certain table fields, and the compiler will automatically match that.
 You can declare new types in the data dictionary, and then use them in
your programs.  In addition, you can use SQL as part of the language
itself, rather than as a string literal - which means tables, etc., can be
checked at compile time.  I could go on, but the point is that although the
language is lacking some bullet-point type features that all the cool kids
have, it is very practical for developing business applications in.  On the
down side, you basically can't use ABAP without a huge database and BASIS
runtime installation - it wouldn't be good for desktop apps unless you have
gigabytes to devote.

I have tinkered with adding some of this basic functionality to FPC in the
past, but it would require significant compiler changes.  I do have an ABAP
utility language for FPC though which handles a lot of ABAP functions in
FPC (translate(), etc.) to make porting easier, as I often prototype in FPC
offline and then convert to ABAP.

As for using database tables, I think FPC could stand to have more included
data types for handing such things without a database.  We have dynamic
arrays, which can't even handle a deletion of an item in the middle, and
then we have StringList.  As soon as people want something like
DualStringList, they resort to using the Object field of StringList and all
kinds of Typecasting hacks.  Generics solves this problem to a degree, but
is still a relatively new feature, and perhaps not the solution for
everything.

> Honestly I think the name is probably the biggest problem if in an era of
> > objects everything it is not associated with Pascal due to its age and
> > past.
>
> Well ObjectPascal has been around since the early 90s at least, and from
an end-user point of view, pascal became primarily Object Oriented with
TurboVision and later Delphi in the mid 90s - so anyone who doesn't know
about that is severely misinformed.  I am not sure that changing the name
will make up for that.

FPC still keeps compatibility with real mode and non-OOP programming - and
there is no way to change that any time soon even if we wanted to, so I am
not sure what you are suggesting.  For example, most of the system/sysutils
units is not OOPs.  In order to make things work, we have to call OS level
features and kernel ABIs, which are almost never OOP.  (Except on Mac OS
for some things).

I think that if we suddenly had a huge budget in terms of money or
developer time, there would be other areas we would be better off investing
in - like making threads easier and more reliable to use.  I have to admit
to being jealous when I see stuff like this in other languages:

Run_in_background (save_file(), update_gui());

Probably before that, I would push for proper UTF8String support, so that
functions like Copy() return the correct characters instead of still
thinking in byte mode.

In the end, everyone here I expect loves Pascal, or we wouldn't be on this
list, but expecting it to suddenly become super popular tomorrow is
probably not realistic - on the other hand, think of it as your secret
weapon.  While everyone else is struggling with doing simple string
operations and pointer issues in C++, include file issues in C, OCX
registration issues in classic VB, the common runtime version mismatch
issues in Java, and the 12 versions of .NET that seem to have to be present
on any system in order for .NET programs to function - you can have a
single set of source code that compiled to Windows, Linux, and Mac OS -
even in GUI programs.  You can also have the low level power of C when you
need it, and the ease of higher level programming languages and OOP when
it's useful.

With newer versions of Delphi and FPC, they have both been catching up in
terms of compiler level features:  Anonymous methods, generics, safer
object references, helper classes, etc.  The only thing that doesn't really
fit neatly into the ObjectPascal model is garbage collection, and that's
largely a non-issue with things like Try..Finally and TComponent.
(Delphi.NET I suppose merges OP with garbage collection somehow or another).

If you want to convince people to use FPC and are having issues, you should
ask them what features, exactly, they are looking for.  Chances are that
FPC has them.  (If they want a functional language, though, then you're out
of luck).

Objects everything.. yuck.. I still like simple procedural code for
> teaching people and for doing quick prototypes, I think one of the biggest
> mistakes of the industry is obsession with objects and not enough
> education about relational techniques (http://www.dbdebunk.com)
>

Procedural models, OOP models, and relational models all serve different
needs.  Certainly it would be convenient if FPC had native DB integration.
(i.e. compiler level instead of library level).

Thank you,
    Noah Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20120228/2351f48d/attachment.html>