[fpc-pascal] Pascal is alive!!??

[Vinzent Hoefler]

On Monday 26 February 2007 12:07, Matt Emson wrote:
> > Well, let's do the standard:
> >
> > Pascal:
> >
> >    program
> >       Hello_World;
> >
> >    begin
> >       WriteLn ('Hello world.');
> >    end.
>
> Class: What does program mean?

"That this unit is supposed to be a program. (Still, you can leave it 
out in most dialects.)"

> Does the name matter?

"It should matter for you. Naming your program "grzbmpfl" does not help 
memorizing what it was done for."

> Does it have to be the same as the executable?

"To be more precise, it should be the same as your sourcefile."

> Why is there a colon at the end of the
> line - isn't the begin end at the bottom part of it -

"Because this tells the compiler that this is the end of the source. 
Just like the colons in your textbook indicates "end of sentence", 
although a few spaces and commas would do, too."

> What does begin and end mean?

"Precisely what they say. 'begin' some code and 'end' it. It's called 
block."

> Where does "writeln" come from?

"From the 'System' unit."

> Why is the System unit hidden?

"It's compiler automatism to aid you getting some useful stuff without 
telling the compiler. Unlike C, Pascal compiler's are intelligent and 
know you want to get something done."

> > Ada:
> >
> >    with Ada.Text_IO;
> >
> >    procedure Hello_World is
> >    begin
> >       Ada.Text_IO.Put_Line ("Hello World.");
> >    end Hello_World;
>
> Wow.. I forgot how horrible ADA was ;-)
>
> Class: "is" what?

"The procedure *is* the following code block. In the next lessons you 
see how you can put variables and types declaration local to such 
subroutines."

> Why do I need to repeat the name of the procedure?

"You don't have to, but it is strongly advised to do so, because once 
programs get larger it is fairly easy to lose track of where a 
subroutine 'begin's and 'end's."

> If I use "with" why do I need to put the whole line in again?

"Because there's a strong difference between telling the compiler to 
look for something and telling your fellow readers where you have it 
from.
For the advanced: If you really want to pollute your whole namespace you 
can put a 'use Ada.Text_IO;' right after the 'with' and you don't need 
to repeat yourself."

> Why can't I leave out "with" but can leave out "uses"?

"Because 'with' is for the reader. 'Use' is for the writer. In Ada the 
emphasis is on easily readable code. So only one writer has to work 
more hard to simplify the job of 1000 readers used trying to figure out 
what

'while (****str() != -1) a = lngcmpw();'

meant to be and if it was correct."

> Where does the "put" put it?

"Look up the specification of the 'Ada.Text_IO' package. Now you know 
where the routine comes from you can easily look at the spec what it 
does."

> > Java:
> >
> >    public class HelloWorld {
> >       public static void main(string[] args) {
> >          System.out.println ("Hello World.");
> >       }
> >    }
>
> Thins that are simpler to explain:
>
> 1) "void" - the procedure and function paradimn often confuses
> students. With Java/C./C++/C# the syntax is completely consistent.

In Ada the paradigm has gotten further. Functions are not allowed to 
alter their arguments (only in parameters allowed), so the notion of 
"do_something" and "calculate_something" is perfectly reasonable.

> 2) "public" - try explaining unit syntax to a beginner.

Hmm. Never had a problem with that. Maybe people who try writing code 
before thinking about a spec do.

> The difference between "interface" and "implementation" and the
> argument for "public" and "private" are already on a par.

So what does "protected" mean? And why there's no "package" visibility 
keyword?

> 3) "static", easily glossed over as a "feature you will find useful
> later on". No more complex than explaining the entry point in a
> pascal "program" or how on earth ADA works out what the entry point
> is in the firtst place.

"Entry point" (last time I heard that I still used TASM3.2)? Who needs 
an entry point? You compile something and either it is executable from 
the context or it isn't. Why the hell should someone need a function 
called "main" each time? On the contrary, what's against different 
entry points depending on the context?

> 4) "System.out" how is this any more complex than the Ada example. In
> fact, if you imported "System.out" it would actually be *simpler*
> than the ADA example.

Well, I don't import. I DON'T pollute namespace. And I'd teach any 
beginner not to try. Especially in Java, where you can import 
wildcards.

> 5) The string[] array of arguments.. again, it's a fairly simple
> "you'll find this useful in the future", but it's simply and array of
> the parameters passen on the command line.

What command line? Tell me where the command line in a web application 
is? Tell me where on a bare metal system which doesn't even have an OS?

Do I need to tell you that Java was targeted to such systems?

> The way Pascal handles
> this is far, far more complicated to explain that the, quite frankly
> up front, way Java does. ParamStr(), ParamCount and all that
> business... is not intuitive at all.

True.

> > Java in that respect is definitely harder to grasp. You learn a lot
> > of keywords in one lesson, though.
>
> Not really. The syntax is different,

Yes. I said "in that respect".

> it's not that you learn anything more or less.

Right, you even learn it wrong, because Java is supposed to be an 
OOP-only language according to its inventors and in the "Hello world." 
example is not a single bit of OOP.

> > So, it isn't? A full bunch of keywords wrapped inside a class to
> > make it OOP and it's not even close to *any* OOP is *easy*?
>
> No, you can write seriously non OOP code in Java if you treat a class
> as a "unit". You could even write inline classes if you so wished.

I know that. Sun doesn't. They call Java an OO-language. Well, Smalltalk 
was. Java is a bunch of crap badly designed from people who just failed 
their C++ classes.

> > Well, at that point programming ends and software engineering
> > starts to emerge. The latter Java already lacks by mixing interface
> > and implementation into one holy mess.
>
> Java does nothing of the sort. It mixes nothing..

Right. Sorry, I forgot. In Java there's no spec at all. It's only 
implementation.

> it actually forces
> the programmer to think about the scope of a routine rather than
> leaving it up to the luck of the draw,

Considering that local subroutines are something completely unknown to 
Java and that the package system has nothing to with scope but merely 
with funny names, I stringly recommend, you rethink what you've just 
said here.

Actually there is no scope.

> > > Pointers - no, no, no. Java passes by reference. This is not
> > > anything to do with "pointers"
> >
> > That's why it's called "NullPointerException" instead of
> > "NoneReferenceException", I'd suppose?
>
> Historical.

Ohoh, even back in the 90ies they didn't know how to call it yet? 
Although the concept was known and implemented for at least 20 years 
already? Are you kidding me?

> > Well, it's a minor technicality, if you call it pointer or
> > reference.
>
> A reference contains much more information.

Just like an access type in Ada, still in Ada it's technically a 
pointer.

> > > different to Java? If you wish to pass integral types by
> > > reference, box them. It's not exactly rocket science ;-)
> >
> > It's damn hard rocket science, because even if you do that it's
> > still not clear, what sort of parameter mode it is supposed to
> > have. :P
>
> Not really... Objects are passed by reference. That's the only rule
> you need to remember ;-)

And that String and Array are objects, although they appear as intrinsic 
types at the first glance.

> double is a simple type, Double is a class.
>
> double dd = 3.142;
> Double dD = new Double(d); //boxed..

Yes. And now it suddenly become immutable, meaning I can't just get 
information into it which makes the whole point of boxing useless in 
the context of parameter modes. It'll always be in, but this time by 
reference.


Vinzent.