On Fri, Oct 14, 2016 at 1:50 AM, Michael Schnell via Lazarus <
> On 14.10.2016 00:13, Erwin van den Bosch via Lazarus wrote:
>> I'm not a big fan of the RAD development way any more. (I was years ago).
>> The problem is that you should separate your business logic and the GUI.
> This is absolutely true especially when doing large systems or (embedded)
> systems that don't are tightly bundled with the GUI. But even there using
> RAD for testing/debugging is a way for speed up the development.
> And here the addressees are non-computer engineers who most likely will
> not do large systems on their own, but just should understand what
> programming means to enable them to talk decently with their colleagues who
> will do the programming for appropriate projects.
The above paragraph is not correct very much , because the computer
engineers and the other engineers are different professions . The other
engineers are using computer programming to solve their own problems , the
computer engineers are using computer programming to solve other people's
Mehmet Erol Sanliturk
> So a fast way ("RAD") to do and test a rather simple working project and
> understand the basics
> With Delphi like RAD it's very difficult to do that. (but it is possible)
>> Everything is coded in events and connected to database aware GUI controls.
>> (In the case of a database application)
> I don't think so.
> With a more careful design it's absolutely possible to do "non RAD"
> programs by doing "GUI units" and "business code Units" that interact via
> Objects with functions, properties and events (callback-properties) .
> I believe this is not more effort that using an external GUI designer.
> I did this for embedded projects using the GUI units for debugging and
> testing and then replacing them by dummies without needing to modify the
> business code units and hence being able to start testing again at any
> time, while the "GUI-stripped" executable can used on a "headless" target
> Lazarus mailing list
Lazarus mailing list