On Tue, Oct 18, 2016 at 12:48 AM, Travis Ayres <tray...@gmail.com> wrote:
> I'm all for this effort, and hope it leads to new and modern tutorials, > books or notes that would be useful for others that use FreePascal/Lazarus > to convey graphical system interactions. If there's any need to proofread > such materials, I'll gladly help out! > > To test a large program , I want to use Petri Nets to drive the testing steps in an information processing , let's say network , to simulate a business environment : https://en.wikipedia.org/wiki/Petri_net ( Petri net ) https://en.wikipedia.org/wiki/Category:Petri_nets Category:Petri nets ( My work on this is "Perhaps" now ... ) One unfortunate situation is that there is not much Pascal software for Petri Nets processing , except the following ( which its license is very ambiguous means not usable ) and may be considered very old with respect to new Pascal language level : http://staff.um.edu.mt/jskl1/petrisim/ PetriSim - Discrete Simulation Environment There are others , perhaps , but again , not usable very well . Petri Nets are a vast subject now . There are some Petri Nets processing software but their licenses being copy left are not friendly for commercial environment . For event driven systems , Petri Nets are very important . My opinion is that a "good" , "permissively" licensed , as much as general purpose Petri Nets simulation software may be a very useful tool for the students to simulate their event driven system definition , and , then write its special purpose Pascal program by using Lazarus easily . Actually , it is not compulsory to use Pascal , but Pascal will supply the Pascal programming language learners a very good example , its license will permit them to use some of its parts whatever they want to do without any hostile restriction in any environment . In such a tool , only it is necessary to describe the nodes , information flow between nodes , etc. . ( Please see above link about PetriSim . ) Mehmet Erol Sanliturk > On Oct 17, 2016 6:32 PM, "Mehmet Erol Sanliturk via Lazarus" < > lazarus@lists.lazarus-ide.org> wrote: > > > > On Mon, Oct 17, 2016 at 12:05 PM, Lars via Lazarus < > lazarus@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 > > > > -- > _______________________________________________ > Lazarus mailing list > Lazarus@lists.lazarus-ide.org > http://lists.lazarus-ide.org/listinfo/lazarus > > >
-- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus