|
Are you saying that: (1) A good RPG programmer can do in 15 lines of RPG what an AS/SET programmer does in 100 lines of AS/SET code? i.e., even ignoring the performance considerations, are you saying that developing applications with AS/SET takes about 6 to 7 times more work than coding the same functionality in RPG. Or, are you saying that (2) A good RPG programmer can do in 15 lines of RPG, what a program written with AS/SET would generate 100 lines of RPG for. If this is the case, how many lines of AS/SET would the programmer need to write to get the same functionality as the 15 lines of RPG. i.e., is there ignoring the performance of the RPG code generated by AS/SET, is there a productivity benefit in development and maintenance using AS/SET compared to RPG. If so how big of a benefit, and in what areas are AS/SET's strengths and weaknesses? "L. S. Russell" wrote: > > Whoa! > > A poorly written RPG program will run just as fast as one developed with > AS/SET. But a well written RPG program can run circles around anything > generated by a case tool. Anyone who writes RPG will become ill at the > site of RPG generated by AS/SET. > > AS/SET does things repeatedly for no earthly reason; loops calling > SUBR's which contain no more code than BEGSR and ENDSR, endlessly > initializing arrays whose values are never changed, ... the list goes on > and on. > > AS/SET code is bloated and ugly, a good RPG programmer can do in 15 > lines what a good AS/SET program takes 100 or so lines to do. > > P. S. I have never seen an AS/SET generated subfile program. > > "Lacelle, Marc" wrote: > > > > Hi Ho. > > > > I for one use ASSET/ADK as a development tool and find it quite > > useful. I am not an RPG or RPG-ILE programmer and never intend on being one. > > ASSET/ADK offers is a simple alternative to RPG. You almost can do > > everything with this tool. Yes, RPG is more powerful but, a program written > > using ASSET will take the same amount of time to run as a program written in > > RPG. The code generated from a program using Asset will be much smaller than > > a program written using RPG, it will take me a few days to come up with a > > complex ASSET/ADK program where it may take a week or more using RPG. > > > > If the execution time for a program is the same and the length in > > time to write the code using ASSET is lesser than RPG. Why knock the > > product. > > > > You are correct in the saying that the source provided by SSA for > > BPCS is pretty bad. We call it spaghetti language over here, but lets not > > forget SSA are in the business of making money. If they had two line source > > for every program they had, we would not need them. > > > > PS: It think the people who dislike ASSET are RPG programmers. > > > > Marc Lacelle > > Royal Canadian Mint > > > > > > > > > ---------- > > > From: Chick Doe[SMTP:Cdoe@barton-instruments.com] > > > Reply To: BPCS-L@midrange.com > > > Sent: Saturday, September 16, 2000 3:32 PM > > > To: BPCS-L@midrange.com > > > Subject: the ASSET issue again > > > > > > there's been a lot said in the last couple of days about SSA and AS/SET. > > > while i am not a fan of it, i can understand the logic of writing code in > > > AS/SET that could then be compiled and run on multiple environments. yes > > > you will sacrifice performance, but if the intent was to provide improved > > > functionality at less cost, then i can understand the logic. whether this > > > was ever delivered or not is another question. > > > > > > but what drives me absolutely insane is SSA's practice of commenting out > > > lines in both the AS/SET source and in the resulting RPG source. much o > > > the complexity in trying to read these damn programs is just trying to > > > decipher which lines are still executable statements and which are now > > > comments. my guess is that well over half of all statements in their > > > programs are old lines of code that are now comments. TAKE THEM OUT AND > > > GIVE US SOURCE PROGRAMS THAT CAN BE READ! > > > > > > chick doe > > > barton instrument systems > > > > > > +--- > > > | This is the BPCS Users Mailing List! > > > | To submit a new message, send your mail to BPCS-L@midrange.com. > > > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > > > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > > > | Questions should be directed to the list owner: dasmussen@aol.com > > > +--- > > > > > +--- > > | This is the BPCS Users Mailing List! > > | To submit a new message, send your mail to BPCS-L@midrange.com. > > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner: dasmussen@aol.com > > +--- > +--- > | This is the BPCS Users Mailing List! > | To submit a new message, send your mail to BPCS-L@midrange.com. > | To subscribe to this list send email to BPCS-L-SUB@midrange.com. > | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. > | Questions should be directed to the list owner: dasmussen@aol.com > +--- +--- | This is the BPCS Users Mailing List! | To submit a new message, send your mail to BPCS-L@midrange.com. | To subscribe to this list send email to BPCS-L-SUB@midrange.com. | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com. | Questions should be directed to the list owner: dasmussen@aol.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.