Re: Yahoo - Informix Revitalizes 4GL Application Development Too
Posted in 1998
Nils Myklebust wrote: > > On Tue, 12 May 1998 18:01:50 +0100, Peter Lancashire > <Peter.Lancashire.PL1@bayer.co.uk> wrote: > > >Nils Myklebust wrote: > >> > >> What we do now for reports, invoice creations and other batch type > >> processes, is to create a GUI front end in Java. Then we strip off the > >> small front end (if any) in these 4GL programs and start them from > >> Java using RMI. This is just greate. It works nice and gives you a > >> true GUI. > >> As we have time for it we recreate programs fully in Java, but still > >> use RMI to execute the heavy part on the server. > >> > ><big snip> > >Java may be great but it's a 3.5 generation language. I4GL is maybe a > >3.9 GL. We just want something with a future that reduces the number of > >lines of code required. It's that simple (and that complicated) :-). Oh, > >and spare me from keyhole programming of mini components through a GUI. > > This is true only to some extent. It isn't all that hard to make Java > into a 4.x or whatever generation language by either buying or > creating class libraries or possibly better Java Beans. Remember Java > Beans are in no way GUI only components. They can just as well be non > visual components and easily used on the server side as well. There is > even the Enterprise Java Beans standard comming allong that gives you > some more server side functionality. > > I am not sure what you mean by "keyhole programming of mini components > through a GUI". Although Java Beans can be mini components they can be > large and sofisticated as well. They can also be used and controlled > via straight code you write, not only through a GUI development > system. An extra nice thing is they are also written in Java so if you > have the source (bought or developed by you) you can change them with > the same tool you use for regular development. We couldn't develop > many components using C/C++, but in Java it's fairly easy to create > our own Java Beans from our classes. > > To some extent the development environements that are available can > also reduce the number of lines of code you actually have to write. > They generate some code for you. Of course sometimes you may not be > too happy with generated code. On the other hand, what is it 4GL realy > does for you? > > As to "with a future" which is extremely important to us, it's hard to > think you would go wrong with Java if you look at all the effort going > in to that language and environement. > > The thing here is I can't see any better language or tools currently > available or on the horizon for the spesific purpose of creating > bussiness type database applications - the same types of applications > 4GL are so well suited for. If your requirements are for other types > of applications there are many other issues to evaluate and the > conclusion may be very different. > > Nils Myklebust > NM Data AS > Norway > E-mail: Nils.Myklebust@nmdata.com > FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html > (Now with ODBC info under "Third party products".) Nils, I agree with you about Java's flexibility and probably about it's future. The stability of its specification is perhaps less clear. The problem is that to get the extra productivity you need more than Java: you need tools and beans and such. It seems to me that these are not stable at all in the sense that they are changing all the time. If you develop with a tool that disppears you still have the Java source code it leaves you but then I4GL leaves you with C :-). Maybe the problem is that 4GL solutions seem to have a much shorter life than 3GLs. They die like flies: look at Galaxy. But writing in 3GLs is drudge. Still, there's an awful lot of COBOL around :-). -- Peter Lancashire Information Systems Specialist, Bayer plc Eastern Way, Bury St Edmunds, Suffolk, IP32 7AH, UK Tel: +44-1635-562258, Fax: +44-1635-562281 Mail: Peter.Lancashire.PL1@bayer.co.uk --- My Internet plumbing does not allow me to mail and post news together. Sorry. All opinions are my own and not those of Bayer plc. --- Join Infuse, the UK Informix User Group at http://www.infuse.org.uk/