[Lazarus] Teaching Pascal at College

[Mehmet Erol Sanliturk]

On Mon, Oct 17, 2016 at 12:05 PM, Lars via Lazarus <
lazarus at lists.lazarus-ide.org> wrote:

> > On 14/10/16 08:30, Michael Schnell via Lazarus wrote:
> >
> >
> > Of course there are decent drawbacks regarding relying too much on RAD
> > and about not really understanding the fundamentals behind it. But in the
> > end the addressees are non-computer engineers.
>
> The big issue with teaching using a RAD tool, is welding the program logic
> into the onclick events, instead of decoupling the logic in separate
> procedures that can be reused elsewhere.  RAD tools are superior at
> prototyping... I can't believe how awesome they are at that. They are
> inferior, however, when it comes to bad habits being brought on.  With
> this warning, RAD tools can still be very useful for writing solid
> programs, as long as one knows this warning ahead of time.
>
> When I first learned delphi I made the mistake of putting code in the
> onClick events and similar, and then when you expand your app later you
> realize all that code is welded in place and cannot be reused outside of
> the events.
>
> Of course decoupling the logic from the GUI leads to more layers of code.
>
>
-------------




> How I got rid of my bad habits when I first learned delphi: I started
> writing console apps with no object oriented programming, no events, and
> learned that not everything is a click event in computer programming.
>
>

-------------


My opinion is that the above ideas are really very good to be applied
during teaching :
First , teach language on , let's say , "atomic" problems . Then , use
these "atomic" concepts in further problems either embedded in a GUI or
console program .

One obvious point is that an "event" driven programming knowledge is a must
to become a competent programmer . The problem is how this can be learned .
Without knowing how to program an algorithm when a related event is
occurred , will bring any one to nothing means ( not to a success ) .

-------------



> People late in the game (learned programming when GUI's were available)
> and have no experience with console mode apps will earn some bad habits
> because of the GUI oriented programming. Those with experience in other
> areas of programming such as old Dos programs, web programs (basically
> like a dos or unix console program) will learn different ways of
> organizing code without everything being tied to a GUI event driven code.
>
> I suppose even doing a plain Win32 API app with no delphi code (pure win
> api) would help someone learn how to organize code from a second opinion
> view, without being forced to use the event driven system you were given
> by the RAD tool.
>
>

-------------



> Of course, also learning other programming languages helps (although, IMO
> learning too many brain dead languages and hip cool ones will not help, as
> much as others claim... Basic programmers from the 80's or 70's still
> think in GOTO's and line numbers)
> --
>


-------------



With respect to researches ( I am not able to supply links now because this
view is based on old times readings , but I am sure that such research
findings can be found ) ,

people ( mostly ) uses a "primary" language for her/his profession and a
"secondary" language for some her/his works as an additional tool .

This shows that during teaching , this feature should be taken into
consideration : Guide the students to discover which language she/he will
prefer to use in much of her/his works , and attempt to teach that language
in a "best" way to be used by the students in their profession .

A similar approach should also be used for a "secondary" language .

If a language is taught just for fun or whatever else other than being a
possible candidate for "primary" or "secondary" is likely that , if it not
a necessity for the learner , is only a waste of everything is involved .



Mehmet Erol Sanliturk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20161017/8dad4350/attachment.html>