From psmith@mozart.convex.com Thu Mar 19 00:55:05 1992 Received: from convex.convex.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA26569; Thu, 19 Mar 92 00:55:05 +0100 Received: from mozart.convex.com by convex.convex.com (5.64/1.35) id AA20528; Wed, 18 Mar 92 17:54:31 -0600 Received: by mozart.convex.com (5.64/1.28) id AA11022; Wed, 18 Mar 92 17:54:28 -0600 Date: Wed, 18 Mar 92 17:54:28 -0600 From: psmith@mozart.convex.com (Presley Smith) Message-Id: <9203182354.AA11022@mozart.convex.com> To: SC22WG5@dkuug.dk, walt@netcom.com Subject: Re: (SC22WG5.72) Market surveys Cc: psmith@mozart.convex.com X-Charset: ASCII X-Char-Esc: 29 > We need to get back to our roots and analyze the Fortran market needs. >Let me also try to make this as complicated as possible and maybe help >convince some people that this is doomed to failure. >Compiler vendors can try to estimate their customers, the Fortran >programmers, and, as we have seen, this is pretty difficult. But >these folks have their own "customers", the users of the programs, >from purchasers of a mathematical library from IMSL or NAG or Magus >to the purchaser of an airline ticket who gets his plane designed >by a Fortran program (or whose medical equipment is controlled by >a Fortran program when the plane designer encounters a bug). I would >bet that most of these folks would come down hard on the side of >reliability and maintainability over performance, but I doubt that >any "market survey" anybody on X3J3 devises will take these people >into account. It seems to me like there's something wrong in this logic. I, as a USER of UNIX, don't care that UNIX was written in C. What I care about is how fast my prompt comes back or my awk or grep gets executed and whether it gets the right answer or not... It seems to me that the programmer who is writing code in Fortran is the target audience of the Fortran standard. And that programmers have similar concerns no matter what application program they are developing or maintaining... And in some cases, they have common concerns no matter what language standard they are using. For example, a common concern is does the compiler run fast enough, does it find my errors, does it ... Even with COBOL, that's a concern. In the case of the specific language, it would seem that the concerns would be with functionality of the language being right, it should be fit the problem that the programmer is trying to solve (let's redo UNIX and write it in Fortran???), it should... So, I think the target audience for the Fortran standard is the Fortran programmer in whatever field that person is using Fortran. And that we should limit our "market" to programmers who program in Fortran. That immediately eliminates much of the computing world. I don't believe the target market is the programmers who write general ledgers or paycheck programs. I don't believe the traget market is the OS deverlopers or the compiler developers, I don't believe the target market is the PC hacker at home who wants to write a program to balance his checkbook... etc. The COBOL group knows what their traget market is. It's Business Application development... that's why they talk about packed decimal and ISAM files... The DOD defined what the target market was for the first release of Ada was... embeded software. So, what is the target market for the Fortran standard? Last time I looked it was the programmer developing scientific and engineering applications... and only a subset of those because some have already moved to C, Pascal, Ada or some other language... So, I think we can define the traget market. Now, there's lots of different activities in that target market, but I'd bet we could get information on about how much of each activity there is in that target market... If you can't define the target market for this standard, and what that target market requires vs what they might just want...then you'll never produce a standard that will satisfy the demands of the market and will not be successful in the long run. A standard that is all things to all people will always fail. >This is one more way to say that X3J3 is not a "representative democracy" >in the sense of each person/dollar/line-of-code having the same amount >of representation (Andrew, Loren, Keith, and I have less of a vote in >the US Senate than people from any other state, but I sill would call >it a representative democracy), but in the sense that the members of >the committee must try to represent some class (not all the same as >Richard points out) and do their best to understand the needs of >the rest. It is unfortunate that representatives of vendors are >some times put in the position of representing only the economic >well being of their own company, however much that will harm others. >And, of course, representatives of users could be put in the same >position. I certainly have not said anything about this. What I'm saying is that for X3J3 to be successful in the next round of Fortran standardization, we must 1. Obtain consensus on what the requirements are for the market that the Fortran standard to be produced will serve... 2. And THEN work on the features to best serve that market... The problem with the last committee and with Fortran 90 is that there was never a consensus in the committee of what the main target market was. There were those who's prime interest was in: - Adding things so it could be taught - Adding things for software engineering - Adding things for performance - Adding things for ... You know what I heard most from Fortran programmers that I talked to... They wanted existing features in vendor X Fortran language standardized so they'd have more portability of code between vendors... That was the #1 thing I heard from what I believe to be the target market for Fortran 90. Yep, I also heard that they'd like things for performance and software engineering and ... They wanted INCLUDE, CRAY Pointers, VAX Structures, REAL*, etc. etc. What are they saying today?? Are we listening? Do we know what our target is for Fortran xx?? Now's the time to be answering those questions. Not after we've gone and added a bunch more stuff to Fortran 90... If X3J3 would spend the next year coming to consensus on what the target market wants, getting the syntax and semantics down and agreed on will be simple. And the committee will know when they are done... And the reviewers will be not be hostile... And X3 will view this all in a different light... ------------------------------------------ You know, I'm told more all the time, that to design good software you must spend more time up front... get the design right. Test the design. Prototype the design. DON'T start coding!!! Design it and verify it and spend most of the time on the project doing that... Don't you think a standards committee should do the same? FYI. Presley