<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 12:05 PM, Lars via Lazarus <span dir="ltr"><<a href="mailto:lazarus@lists.lazarus-ide.org" target="_blank">lazarus@lists.lazarus-ide.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 14/10/16 08:30, Michael Schnell via Lazarus wrote:<br>
><br>
><br>
> Of course there are decent drawbacks regarding relying too much on RAD<br>
> and about not really understanding the fundamentals behind it. But in the<br>
> end the addressees are non-computer engineers.<br>
<br>
The big issue with teaching using a RAD tool, is welding the program logic<br>
into the onclick events, instead of decoupling the logic in separate<br>
procedures that can be reused elsewhere.  RAD tools are superior at<br>
prototyping... I can't believe how awesome they are at that. They are<br>
inferior, however, when it comes to bad habits being brought on.  With<br>
this warning, RAD tools can still be very useful for writing solid<br>
programs, as long as one knows this warning ahead of time.<br>
<br>
When I first learned delphi I made the mistake of putting code in the<br>
onClick events and similar, and then when you expand your app later you<br>
realize all that code is welded in place and cannot be reused outside of<br>
the events.<br>
<br>
Of course decoupling the logic from the GUI leads to more layers of code.<br>
<br></blockquote><div><br>-------------<br><br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How I got rid of my bad habits when I first learned delphi: I started<br>
writing console apps with no object oriented programming, no events, and<br>
learned that not everything is a click event in computer programming.<br>
<br></blockquote><div><br><br>-------------<br><br><br></div><div>My opinion is that the above ideas are really very good to be applied during teaching :<br></div><div>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 .<br></div><div><br></div><div>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 ) .<br></div><div><br>-------------<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
People late in the game (learned programming when GUI's were available)<br>
and have no experience with console mode apps will earn some bad habits<br>
because of the GUI oriented programming. Those with experience in other<br>
areas of programming such as old Dos programs, web programs (basically<br>
like a dos or unix console program) will learn different ways of<br>
organizing code without everything being tied to a GUI event driven code.<br>
<br>
I suppose even doing a plain Win32 API app with no delphi code (pure win<br>
api) would help someone learn how to organize code from a second opinion<br>
view, without being forced to use the event driven system you were given<br>
by the RAD tool.<br>
<br></blockquote><div><br><br>-------------<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Of course, also learning other programming languages helps (although, IMO<br>
learning too many brain dead languages and hip cool ones will not help, as<br>
much as others claim... Basic programmers from the 80's or 70's still<br>
think in GOTO's and line numbers)<br>
<span class="gmail-HOEnZb"><font color="#888888">--</font></span><br></blockquote></div><br><br>-------------<br><br><br><br></div><div class="gmail_extra">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 ) ,<br><br></div><div class="gmail_extra">people ( mostly ) uses a "primary" language for her/his profession and a "secondary" language for some her/his works as an additional tool .<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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 .<br><br></div><div class="gmail_extra">A similar approach should also be used for a "secondary" language .<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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 .<br><br><br><br></div><div class="gmail_extra">Mehmet Erol Sanliturk<br></div><div class="gmail_extra"> <br></div><div class="gmail_extra"><br></div></div>