|
| -----Original Message----- | [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Jon Paris | >> Why don't my typos get flagged and auto corrected, given the | context of | the files referenced and fields defined?? | | jt - To some extent this is present in the auto-complete | functions in WDSc - | but will not happen in SEU and in fact (given that SEU works in | block mode) | would be next to impossible to implement and I wouldn't want it even if it | did because it would be so nasty. I'm glad WDSc has this feature, and hope it provides it and still has subsecond response time. I agree with your comment on SEU, to an extent. Unless and until a LOT more 400s are single-user systems... But what COULD be implemented in a block-mode editor (fairly easily, I would think) is a pop-up window if an invalid field was entered, with some suggestions. And this window could also provide a D-spec. The D-spec could be inserted in one of (at least) three places: At end of D-specs, in alphabetical order, or at a user-specified point (via something-like-a IDx (insert D after/before)). All this would be a NET NEGATIVE, unless the feature(s) could be turned on or off by the programmer, btw. | | You are also (by accident or design) ignoring Both. When making an analogy, the trick is to be very clearly aware of the similarities and differences. If the similarities are over-emphasized, you get an analogy that appears to fit a situation but doesn't. If the differences are over-emphasized, you get an analogy that appears to not fit, but which actually does. So I intentionally ignore some things, but mistakes happen by accident. (I think systems analysis is largely the process of making proper analogies, between an existing system and a user's dreams.) | a couple of major | differences | between writing programs and writing letters etc. Auto complete works in | Word because the language (i.e. words) that can be used are known i.e. the | English language. In a program you constantly "make up" words. | Often these | "words" are invented as you write the calcs and you define them later. I find this analogous to user-defined dictionaries. Secretaries can add their own words, on the fly. | Auto-complete doesn't help here because the names will often reflect the | names of the "root" fields with which the new ones are associated | and would | therefore be auto-miscorrected as often as not. I dunno, you could be right... And if they're auto-miscorrected anywhere NEAR as often as they're corrected, it'd be pretty horrible. But I'm not looking for the computer to do all my thinking for me, and was thinking along the lines of Intellisense, and having the editor IDENTIFY all known errors. | | >> I would suggest that this could be implemented a LOT easier than | implementing syntax-checking of /FREE | | I doubt it - besides the resources are from different "pots" - things like | the syntax checker are part of RPG development - the kind of functionality | you are asking for is very much part of the editor. Well 2 1/2 years ago I asked Hans this very question, and he stated "the Code developer is sitting right next to me". Obviously that's changed with WDSc. | Compiler writers and | tool developers are not interchangeable. On the contrary. That's been one-a the points I've been making... First of all, the compiler *is the primary tool* a programmer uses, and the compiler-writer IS a tool-developer. I have some understanding of the different natures of compiler-development and UI designer. I think this is analogous to the debate over whether a single person can be both a good coder and a good analysis, and they CAN be in "many" cases. These are not mutually exclusive talents, although it's difficult to do both well. | Certainly compiler writers can | often turn their hand to tool building, but it is a rare tool builder that | makes a successful transition to compiler waiting - different mind-set. Well, having said the above, you could be right or your experience may be different than mine... I dunno. It's hard to tell if Joe Pluta, for example, is an exceedingly rare exception to the general rule, or not. (I don't view a translator, which is what PSC does when it converts server-side code, as much different than a compiler.) There are VERY few in Joe's class, of course, but I am of the opinion that many people have the capabilities to do a pretty good job developing both compilers and tools, and see that a lot outside the 400 arena. | | Re Polls: | | Since I was the first to initiate these within RPG development to the best | of my knowledge, I think I can comment to some extent on their usefulness | etc. | | First of all they are not distributed _only_ to this list but to | many lists, | and at least in my day to attendees at User Group meetings, | COMMON, IBM Tech | Conference and other such gatherings of the clans. I've studied communities in some detail, and there are both pros and cons to the "clannish" aspects of ANY community. | In my experience the | vast majority of RPG programmers who do not attend/participate in such | lists/conferences are for the most part still coding RPG400 and | using mostly | only the RPG II features so even if one could reach them (how | exactly would | one do that?) their opinions would not be of much value since they have | little or no awareness of what RPG IV offers in the first place. This is a false meme. I look at code created by these "plebisites" (sp?) every day. I've worked in shops from huge to one-man, from Fortune-30 to $10M. You've talked to hundreds, if not thousands of coders Jon, but they are all of this same basic mind-set. If you don't participate in these kinds of lists and go to COMMON, then you're coding in RPGII and have no awareness of what RPG IV offers. This is false. | Secondly the list is built from a wide range of sources. For example, | comments on lists like this that indicate people are having to | jump through | hoops to achieve what should be simple, ideas that arise when discussing | requirements with customers, formal requests from the field/customers for | enhancements, ideas that the compiler team think would be useful, | etc. etc. This is true to an extent. There sure IS a wide range of resources on this list. But it isn't nearly as all-encompassing as you would like to believe. | Third. While the compiler team often have very strong ideas on what | should/should not be done, they have proven over and over again that they | will change designs if people don't like the proposals (/Free being a good | example) and have frequently changed the priority of items based on user | feedback. I have under-emphasized my appreciation of this fact. | Fourth. Polling data is used to _help_ establish priorities. We all have | to do that when we have a fixed budget. By assigning dollar figures to | the shopping list the compiler team get an idea of where their development | efforts would be most appreciated. I have heard of quite a few people who | have taken the approach the compiler team use and applied it very | successfully with their user community. Interestingly it has helped some | get more $ in their budgets! I have no question of the efficacy, and like it a lot. | By the way, notice the emphasis on | "help" - it | is not the be all and end all. Well, my point is that it is over-emphasized. | The compiler team ultimately make the | decision True. | but the data is very valuable when you can only afford to do one | thing and are uncertain which would be of most use to an RPG programmer. As I said, the compiler team is exceptionally open... However, the "data" is being collected from those who are most VOCAL, on the assumption that "anyone who cares" would be participating in this kind-a list. That skews the "data". | JT - Since you are big on meeting and talking to other programmers No... Most-a the meeting and talking I do with other programmers is on-the-job. I do little here.. don't have the time (but wish I did). | - I | routinely talk to hundreds of RPG programmers in every conceivable type of | RPG shop. As I noted above. | I conduct on-going discussion by e-mail with programmers around | the world including many who are "stuck" in RPG III. I'm gonna hafta cut this relatively "short". (Oooops, too late!...;-) "Short" being a matter of taste. | I have | found the votes | surprising at times - but mostly to be a good reflection of what | I am seeing | in the field. But what you are seeing in the field is "the vast majority of RPG programmers who do not attend/participate in such lists/conferences are for the most part still coding RPG400 and using mostly only the RPG II features so even if one could reach them (how exactly would one do that?) their opinions would not be of much value since they have little or no awareness of what RPG IV offers in the first place." This is false. And it ignores those who read these lists, but aren't VOCAL. And it ignores those who DO care about RPG, and take personal pride in their work.. and that's regardless of even whether they HAVE any specific suggestions on how they'd like the tools they use be improved. It ignores almost all of those in one-man shops, and most in small shops (who have a wider range of duties and less spare time). But many if not most of these, who don't participate in the lists and may only occasionally go to COMMON (if at all) DO have opinions on the subject. Mebbe if you "went slumming", your experience would more closely match mine, or maybe not.. I dunno for sure. But I sure DO know that I don't know of a SINGLE coder who hasn't become (at least fairly) comfortable with D-specs, which is not RPGIII. I'm sure there is an exception, but I've never ran across anyone m'self... D-specs are intuitive, much like DDS. Not all have bought into the theory that ALL C-specs should be EVALs. Maybe they have a good REASON, even if they don't go to COMMON. The view that there is, at least some, value to a combination of fixed-form and free-form C-specs is simply not tolerated in this list. It's not open for discussion, let alone debate... I dunno why, when the efficacy of the design of F-specs, D-specs, O-specs and DDS is fairly well-accepted. (Leaving aside the debate of O-specs and *PRTF, of which I, personally, use both.) As far as how to reach the vast majority of people (at varying degrees of being "behind the curve") who don't participate in COMMON or this list: I would say it would be easier if you treated their opinions as having at least SOME value. Granted, you won't learn a WHOLE lot from most, but a minority have MANY years of both practical and theoritical experience. I would also remind anyone (who has gotten this far...;-) who cares to listen. It is these people who are "behind the curve" who are footing the bill. So, if for no OTHER reason, they deserve to be listened to. Mebbe that's a matter of opinion?
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.