I have been using Lahey's F77/EM32 compiler for some years and I have amassed a considerable amount of code using many of that compiler's F90 extensions (e.g., ALLOCATE, DO WHILE, etc.). I am poised to embark on the creation of a collection of Windows programs using either the CVF6.1 or the LF95 compiler with the GINO-F Bundle (GINO's graphics and windowing capabilities suit my tastes best). Lahey folks tell me that my F77 code with the F90 extensions should not be a problem with their LF95 compiler since F77 is a complete subset. Now some questions:
(1) Will CVF6.1 accept my F77/EM32 (with F90 extensions) code without substantial modifications?
(2) Reading this news group for some time, my impression is that CVF is the prefered compiler. Why is that (compared to LF95)? Or, am I mistaken?
(3) Any one out there with both CVF and Lahey experience using GINO want to offer their opinion(s) and recommendation(s)?
(4) Steve (Lionel), if you are listening, give me a good pitch to switch.
I look forward to any comments and I appreciate your help.
I am using both CVF 6.1 and LF95 5.5 currently and have used the GINO bundle in the past (with LF90). Your best bet it to talk to the Bradley people to see if their implementation is better on one of these two fine compilers than on the other.
> I have been using Lahey's F77/EM32 compiler for some years and I have > amassed a considerable amount of code using many of that compiler's F90 > extensions (e.g., ALLOCATE, DO WHILE, etc.). I am poised to embark on > the creation of a collection of Windows programs using either the CVF6.1 > or the LF95 compiler with the GINO-F Bundle (GINO's graphics and > windowing capabilities suit my tastes best). Lahey folks tell me that > my F77 code with the F90 extensions should not be a problem with their > LF95 compiler since F77 is a complete subset. Now some questions:
> (1) Will CVF6.1 accept my F77/EM32 (with F90 extensions) code without > substantial modifications?
> (2) Reading this news group for some time, my impression is that CVF is > the prefered compiler. Why is that (compared to LF95)? Or, am I > mistaken?
> (3) Any one out there with both CVF and Lahey experience using GINO want > to offer their opinion(s) and recommendation(s)?
> (4) Steve (Lionel), if you are listening, give me a good pitch to > switch.
> I look forward to any comments and I appreciate your help.
If Bradley says there isn't any appeciable GINO implemention difference, CVF is the better compiler and a much better development environment (Visual Studio).
Al
Alan Greynolds <agreyno...@breault.com> wrote in message
> I am using both CVF 6.1 and LF95 5.5 currently and have used the GINO bundle > in the past (with LF90). Your best bet it to talk to the Bradley people to > see if their implementation is better on one of these two fine compilers > than on the other.
> > I have been using Lahey's F77/EM32 compiler for some years and I have > > amassed a considerable amount of code using many of that compiler's F90 > > extensions (e.g., ALLOCATE, DO WHILE, etc.). I am poised to embark on > > the creation of a collection of Windows programs using either the CVF6.1 > > or the LF95 compiler with the GINO-F Bundle (GINO's graphics and > > windowing capabilities suit my tastes best). Lahey folks tell me that > > my F77 code with the F90 extensions should not be a problem with their > > LF95 compiler since F77 is a complete subset. Now some questions:
> > (1) Will CVF6.1 accept my F77/EM32 (with F90 extensions) code without > > substantial modifications?
> > (2) Reading this news group for some time, my impression is that CVF is > > the prefered compiler. Why is that (compared to LF95)? Or, am I > > mistaken?
> > (3) Any one out there with both CVF and Lahey experience using GINO want > > to offer their opinion(s) and recommendation(s)?
> > (4) Steve (Lionel), if you are listening, give me a good pitch to > > switch.
> > I look forward to any comments and I appreciate your help.
"Richard E. Rossi" wrote: > I have been using Lahey's F77/EM32 compiler for some years and I have > amassed a considerable amount of code using many of that compiler's F90 > extensions (e.g., ALLOCATE, DO WHILE, etc.). I am poised to embark on > the creation of a collection of Windows programs using either the CVF6.1 > or the LF95 compiler with the GINO-F Bundle (GINO's graphics and > windowing capabilities suit my tastes best). Lahey folks tell me that > my F77 code with the F90 extensions should not be a problem with their > LF95 compiler since F77 is a complete subset. Now some questions:
> (1) Will CVF6.1 accept my F77/EM32 (with F90 extensions) code without > substantial modifications?
I can't answer this one, but if they were truely F90 extensions and not some approximation, it is highly likely.
> (2) Reading this news group for some time, my impression is that CVF is > the prefered compiler. Why is that (compared to LF95)? Or, am I > mistaken?
This is probably some measure of marketing, but much of it also relates to the development environment and the "integration" with the Windows OS (not intending to discount the high quality of the compilers in both products). It is my impression that Compaq is accomplishing more in this area than competing products, including ActiveX/COM. Digital also has a fairly longstanding good reputation for being "tops" in Fortran support (rightly or wrongly, I've mostly experienced DEC competitor's products). Certainly much better than the inventor company, especially if you consider well thought out language extensions and high levels of OS integration to be good thngs.
> (3) Any one out there with both CVF and Lahey experience using GINO want > to offer their opinion(s) and recommendation(s)?
Well, I can't afford GINO BUNDLE for both compilers (just upgrading my one copy makes me have to go without food for several weeks). It would be unusual for there to be any significant differences or problems with either configuration.
> (4) Steve (Lionel), if you are listening, give me a good pitch to > switch.
> I look forward to any comments and I appreciate your help.
We've tried four different compilers on Windows NT: Absoft, Salford, Compaq and Lahey. The first two we gave up on; they were totally inadequate. I have been attempting to compile my program for THREE years with the Compaq compiler and I have yet to succeed! (I have over thirty years experience programming Fortran, including over three with Fortran 90/95.) We've reported every bug we've found to Compaq, and they and Mr. Lionel have been very responsive, but the simple fact is that it will not compile our code; Lahey's compiler will. The Lahey compiler is SOLID. If it indicates an error, I made a mistake.
I would agree with some of the others that the Compaq is a more consolidated work environment.
Having ported a program from LF77/EM32 into limbo between that and DVF5.0D within the last six months:
"Richard E. Rossi" wrote:
> I have been using Lahey's F77/EM32 compiler for some years and I have > amassed a considerable amount of code using many of that compiler's F90 > extensions (e.g., ALLOCATE, DO WHILE, etc.). I am poised to embark on > the creation of a collection of Windows programs using either the CVF6.1 > or the LF95 compiler with the GINO-F Bundle (GINO's graphics and > windowing capabilities suit my tastes best). Lahey folks tell me that > my F77 code with the F90 extensions should not be a problem with their > LF95 compiler since F77 is a complete subset. Now some questions:
> (1) Will CVF6.1 accept my F77/EM32 (with F90 extensions) code without > substantial modifications?
Yes. If you use graphics from Lahey, you'll need to do something with that; my solution was to write wrappers that were functionally equivalent for Standard Graphics output. If you use command-line argument processing, you'll have to modify that code slightly as well, as DVF/CVF uses a different function name and slightly different usage. Otherwise, the only differences I encountered were differences in function names between some Lahey extensions and F90 intrinsics (specifically, CHARNB vs. TRIM). If you won't have a period where you need to be able to compile your code in both compilers, this is easily handled with a global search and replace.
On Thu, 20 Jan 2000 19:10:44 -0700, "Richard E. Rossi"
<ro...@frii.net> wrote: >(2) Reading this news group for some time, my impression is that CVF is >the prefered compiler. Why is that (compared to LF95)? Or, am I >mistaken?
It's probably because CVF is by far the most widely used of the commercial compilers. Figures I have seen from a number of sources suggest something like a 10:1 sales ratio compared to the next best-selling compiler. This by itself doesn't mean that CVF is necessarily any better than the others, but it does indicate that there are a lot of Fortran users who have chosen to purchase our product. I'd hope that most of them are happy with it.
I had to laugh when I read Gary Scott's mention of "marketing", since we don't do any! At least not the traditional kind - running ads and the like. I think it says a lot for the product that we've become so successful without marketing. While we certainly got a good head start by being "annointed" by Microsoft as the preferred replacement for PowerStation, I don't think we would have gotten where we are today, three years later, without having a fundamentally good product, engineering and support team.
>(4) Steve (Lionel), if you are listening, give me a good pitch to >switch.
It would be inappropriate in this forum for me to give a "pitch" here. What I will do is list what I think some of our strengths are, to give you something to think about.
- Excellent Windows integration, including Win32 interface declarations (with source), simple creation and use of dialog boxes (now including ActiveX controls) - Microsoft Developer Studio IDE - shared with Visual C/C++ if you wish for seamless mixed-language application development and debugging. Integrated source and configuration manager, build dependency manager, editor with syntax coloring and one-click context-sensitive help for Fortran statements, routines and Win32 routines, debugger with features such as conditional breakpoints, show value on hover, examine array slices, and much more, and source browser to find declarations and uses of identifiers - Integrated online documentation for both Visual Fortran and the Microsoft Win32 SDK - QuickWin environment to give traditional Fortran applications an instant "Windows look and feel" - Compaq Extended Math Library - optimized BLAS, LAPACK, FFT and more - Compaq Array Visualizer (Professional Edition only) - "see" your program's data in 3-D views, with interactive rotate and zoom - even from the debugger - Full Fortran 95 with popular extensions from DIGITAL Fortran, Microsoft Fortran and a UNIX "portability" library - Continuous membership and active participation in the Fortran standards committee since the early 1960s. - Excellent generated code quality - CVF shares our own GEM optimizer witrh our performance-leading Alpha products, with constant performance improvements benefiting all platforms - Broad support from third-party software vendors - Free, fast and helpful support from the engineers who built the product - Low total cost of ownership - we don't charge you for upgrades every few months - More than 35 years of experience building respected Fortran compilers for multiple architectures. We have many on our large engineering team who have been doing Fortran for 20 years or more (like me!) Fortran is a passion with us, not a market niche filler.
I think I let this go on more than I wanted, but I hope that it helps you in your decision.
Send Visual Fortran support requests to vf-supp...@compaq.com
Steve Lionel (mailto:Steve.Lio...@compaq.com) Fortran Engineering Compaq Computer Corporation, Nashua NH
> I had to laugh when I read Gary Scott's mention of "marketing", since > we don't do any! At least not the traditional kind - running ads and > the like. I think it says a lot for the product that we've become so > successful without marketing. While we certainly got a good head > start by being "annointed" by Microsoft as the preferred replacement > for PowerStation, I don't think we would have gotten where we are > today, three years later, without having a fundamentally good > product, engineering and support team.--
I shoulda been a commodian...I've lamented several times here in the past over the lack of overt marketing of the Fortran vendors. Even Microsoft included words on the FPS packaging claiming "part of the MS visual development tool set" or something like that, yet Fortran was NEVER mentioned in any advertisement that I saw, including those which listed ALL of the other Visual Studio companion languages together.
The loose use of the term "marketing" in my previous post was attempting to allude to "riding on the coat tails" of Microsoft's marketing for its "visual" tool sets and to calling the product "Visual Fortran". Is that not marketing of some sort?
Marketing is designed to increase sales of a product (I assume a carefully balanced process whereby you don't eat up all your profits on advertisements). So why IS there no overt marketing efforts?
On Fri, 21 Jan 2000 22:23:10 GMT, Gary Scott <sco...@flash.net> wrote: >The loose use of the term "marketing" in my previous post was attempting to >allude to "riding on the coat tails" of Microsoft's marketing for its "visual" >tool sets and to calling the product "Visual Fortran". Is that not marketing of >some sort?
I see your point, but that only gets us so far...
>Marketing is designed to increase sales of a product (I assume a carefully >balanced process whereby you don't eat up all your profits on advertisements). >So why IS there no overt marketing efforts?
What sort of marketing do you think would be effective? We do have a modest budget for marketing, but it's not clear what sort of advertising would lead to an increase in sales. Otherwise, I like to think that my efforts here, good information on our web site, making sure that we look good in public comparisons such as Polyhedron's tables, and delivering a good product with good support is as effective a marketing as we can manage. We also work closely with resellers to make sure they have the information they need.
Once you obtain a critical mass of users, resellers and third-party "companion products", you don't need to do too much to keep your product's name in the customer's mind. I don't think any amount of advertising we do is going to convince, say, C++ users to switch to Fortran.
Send Visual Fortran support requests to vf-supp...@compaq.com
Steve Lionel (mailto:Steve.Lio...@compaq.com) Fortran Engineering Compaq Computer Corporation, Nashua NH
In article <3887C024.7FC75...@frii.net>, Richard E. Rossi <ro...@frii.net> writes
>I have been using Lahey's F77/EM32 compiler for some years and I have >amassed a considerable amount of code using many of that compiler's F90 >extensions (e.g., ALLOCATE, DO WHILE, etc.). I am poised to embark on >the creation of a collection of Windows programs using either the CVF6.1 >or the LF95 compiler with the GINO-F Bundle (GINO's graphics and >windowing capabilities suit my tastes best). Lahey folks tell me that >my F77 code with the F90 extensions should not be a problem with their >LF95 compiler since F77 is a complete subset. Now some questions:
>(1) Will CVF6.1 accept my F77/EM32 (with F90 extensions) code without >substantial modifications?
Maybe. Did you use any Lahey-specific extensions (as opposed to those now in F90), or call any Lahey library functions? If so, CVF won't like them but LF95 probably will. Having said that, I recently had to port some code, originally for an old Lahey compiler, which had declarations liberally scattered through the executable statements. Couldn't find a modern compiler which would accept it, not even Lahey's. [This isn't a complaint as it was truly horrible nonstandard coding style, but a comment that you could have code which nothing else will accept without substantial modifications.]
>(2) Reading this news group for some time, my impression is that CVF is >the prefered compiler. Why is that (compared to LF95)? Or, am I >mistaken?
A possible reason which has nothing to do with the merits of either product is that lots of people used to use Powerstation purely because it was Microsoft. CVF was/is the recommended upgrade path from Powerstation. Or you could argue that Lahey users have no problems so don't need to post on the newsgroup. What I'm trying to say is that volume of newsgroup traffic isn't a very good way to choose a compiler.
>(3) Any one out there with both CVF and Lahey experience using GINO want >to offer their opinion(s) and recommendation(s)?
>(4) Steve (Lionel), if you are listening, give me a good pitch to >switch.
>I look forward to any comments and I appreciate your help.
>Richard E. Rossi, Ph.D.
Both are good compilers - my main suggestion would be to choose the one which suits your situation best rather than the one which you think everyone else is using. I use Salford FTN95 with Winteracter at the moment, not exactly something the newsgroup is buzzing about, or something I'd recommend for every situation. But it works for me.
It's probably because CVF is by far the most widely used of the commercial compilers. Figures I have seen from a number of sources suggest something like a 10:1 sales ratio compared to the next best-selling compiler. This by itself doesn't mean that CVF is necessarily any better than the others, but it does indicate that there are a lot of Fortran users who have chosen to purchase our product. I'd hope that most of them are happy with it.
I had to laugh when I read Gary Scott's mention of "marketing", since we don't do any! At least not the traditional kind - running ads and the like. I think it says a lot for the product that we've become so successful without marketing. While we certainly got a good head start by being "annointed" by Microsoft as the preferred replacement for PowerStation, I don't think we would have gotten where we are today, three years later, without having a fundamentally good product, engineering and support team.
I'm not knocking CVF. The majority of what I know about it is what people in this newsgroup write. However.... I have to disagree with Steve 100% on the marketing statements. Digital marketed the heck out of the product. I received flyer after flyer in the mail. And.. so did other engineers I work with who don't even program anything. The flyers were also, IMHO, aimed in large part at those part time programmers who really aren't active enough at their own computers to know that Microsofts Fortran products were pretty, well... lame. I had people at work tell me that Digital was the only way to fly, "After all,... they are the ugrade path from Microsoft" or something of that nature. These people would not even consider another competitors product. They were wholly convinced that the new Digital product MUST be the best. Keep in mind that several of these people I'm referring to were those responsible for making the final decisions on what software products we would purchase. Guess who's compiler we purchased. :-)
So... to sum things up.... Digital DID market their product. Relative to marketing of other vendors compilers, I'd even go so far as to say that Digital launched a major marketing campaign. I've never gotten unsolicited ads or flyers from anyone elses fortran before.
Don't misunderstand me, I think the way Digital/Compaq marketed their product was quite ingenius. It worked! The big question now is... which compiler out there is truly the best ( if one exist ) for todays fortran programmer?
Norm wrote: > I'm only qualified to answer question 2)
> We've tried four different compilers on Windows NT: Absoft, Salford, > Compaq and Lahey. The first two we gave up on; they were totally inadequate.
Well, it sounds figurally the following. We've tried violin, grand piano, guitar and sax. First two we gave up because of they were totally inadequate.
> I have been attempting to compile my program for THREE years with the Compaq > compiler and I have yet to succeed! (I have over thirty years experience > programming Fortran, including over three with Fortran 90/95.) We've > reported every bug we've found to Compaq, and they and Mr. Lionel have been > very responsive, but the simple fact is that it will not compile our code;
Guitar was also not good because of it did not allow us to perform our songs (written diring 30 years, some in 90, some in 77 or even 66).
> Lahey's compiler will. The Lahey compiler is SOLID. If it indicates an > error, I made a mistake.
...while others have different experience. When they write their songs, the instrument makes 3 errors per noteline.
> I would agree with some of the others that the Compaq is a more > consolidated work environment.
So sax is what I recommend.
---------------
Though nothing a can tell about tastes and preferences, but me with colleague were totally intrigued :
> >Marketing is designed to increase sales of a product (I assume a carefully > >balanced process whereby you don't eat up all your profits on advertisements). > >So why IS there no overt marketing efforts?
> What sort of marketing do you think would be effective? We do have a > modest budget for marketing, but it's not clear what sort of > advertising would lead to an increase in sales. Otherwise, I like to > think that my efforts here, good information on our web site, making > sure that we look good in public comparisons such as Polyhedron's > tables, and delivering a good product with good support is as > effective a marketing as we can manage. We also work closely with > resellers to make sure they have the information they need.
Well, I wish I was a marketing genius. I DO know that at my company there are about 6000 engineers (at my location) and that a sizable percentage of them know and have programmed in Fortran at some point in the past. An extremely large percentage of those are completely unaware that Fortran survives today and that they can get a great "visual" Fortran product for Windows (or UNIX) and that they even have several of them to choose from. I've helped sell a few copies of DVF just by posting the flyers I get on my cubicle wall (I also post Lahey and Absoft flyers). I sometimes get a crowd around my cubicle reading the flyers for compilers and GINO (but those flyers are only going to current users and so aren't helping much to gain new customers). During the DVF product launch, I received demo CDs from Kathy Appleof (sp?) and they flew out of my hands, so I know there is still interest in Fortran that isn't being tapped. There are quite a few engineers out there that stopped programming or went to Excel, EMACs, or some other inadequate tool just because they no longer automatically get a Fortran compiler with the computer system that they typically use.
Another problem, however, is that they want to be able to walk into Fry's or COMP USA and read/feel the package (maybe try it out). If all they see is copies of VC++ and JAVA, they get the feeling that it's unpopular or dying and a waste of time.
I think that what I'd like to see would be cooperation with MS to get CVF included in their adverts for the visual tool suite. I'd also place an occasional ad ($$$) in magazines such as Scientific American, Science (I see Mathematica and Maple and similar products advertised there, why not Visual Fortran?), Popular Science, Discover (maybe Dr Dobbs and similar magazines, but most engineers that might want to use Fortran DO NOT read those), and get copies of the product on store shelves (i.e. the same issues as for OS/2). Are there any marketing firms that deal in "technical" products? Maybe hire one.
> Once you obtain a critical mass of users, resellers and third-party > "companion products", you don't need to do too much to keep your > product's name in the customer's mind. I don't think any amount of > advertising we do is going to convince, say, C++ users to switch to > Fortran.
Engineers (which I know best) are just as fical and subject to fads as the general public (some would say more so). If they see advertisements for VC++ and JAVA everywhere and none for Visual Fortran, then that is what's in their minds. It pushes Fortran out of consideration even when it might be the best tool for the job. Most don't buy development tools from SciTechInt, Programmer's Paradise, etc. They go down to Fry's, Best Buy, or COMP USA and look at what's on the shelves or they ask the computer support team what THEY recommend (which is almost always C-based since they're all CS grads). So I think that the market is actually much bigger than current sales would indicate.
Critical information that needs to be in the ads: complete OS API access, pointers (integer and safe), modules, select case, and similar things that many use to berate Fortran as inadequate, and of course the "visual" IDE.
I sometimes think about taking a marketing job in my company...well on second thought, I better not go there...
> Send Visual Fortran support requests to vf-supp...@compaq.com
>they want to be able to walk into Fry's or COMP USA >and read/feel the package
There are plenty of linux packages there which include g77. Hence, possibly, the remarks about "linux fortran."
>ask >the computer support team what THEY recommend
They will never recommend anything which might increase their work load. No one can expect help from them with C, Java, or Excel, but Fortran could be a different matter. If they thought that anyone would get anywhere with Visual Basic, they'd stop recommending that. "convert all your VAX Fortran yourself to Visual BASIC, then maybe we can help you."
My company did decide that it was more cost effective to upgrade VMS to y2k compliance rather than force such conversions, and we agreed readily to do our share of y2k remediation and testing on that platform, so now our VMS applications are probably more compliant than the NT ones. Maybe they'll force us to take another vacation at the end of February when those leap-year compliance issues come up on NT. Tim Prince tpri...@computer.org
> those part time programmers who really aren't active enough at >their own computers to know that Microsofts Fortran products were pretty, >well... lame.
I have experience with MS Fortran offerings, from IBM Personal Fortran v1.0 through the last 16 bit version (5.1) and FPS1 and FPS4. I have also used Watcom F77 (several versions), Absoft Pro Fortran, a couple of ports of G77, IBM Professional Fortran 1.0 (a Ryan-Macfarland (?sp) relabel), IBM Fortran/2, (another RM relabel), Lahey Personal Fortran, IBM Fortran G and H levels for the IBM 360, CDC's Fortran for the 6000 series and some Fortran for the PDP-11 (running RT-11) don't ask me whose, 'cause it's been too long. On Multics I don't think I had a chance to do Fortran, I enjoyed PL/I a lot, so I didn't miss it. So -- I've seen a fair number of Fortrans on mainframes to micros.
The earliest MS ones had some severe problems -- but I always found I could make the thing do what needed. By version 5.x of the 16 bit line, they had gotten a decent, useable (by my standards at least) product. The FPS compilers were OK too. I still use them. In fact MS Fortran 5.1 is my primary dev. tool for small things. I get reasonable sized EXEs, and I get them FAST (except when running the compiler on an 8088 -- but then there aren't many Fortrans that will both run on and target an 8088. Watcom will, but it's been discontinued also.<sigh>).
Now the only thing I've got against Digital, er Compaq, is the IDE -- I don't particularly like DevStudio -- but I can run the command line compiler drivers and the linker, so no problem -- and DevStudio is another MS creation, not really DEC's fault at all.
Y'all want something to bitch about? -- well I've got two or three copies of IBM Personal Fortran v1.0. I'll lend you a copy and you can program in that for a while ;-)
C'mon, Digital made a strategic decision in taking over MS's Fortran customers and offering a VERY attractive upgrade (Thank you, Digital -- I was extremely gratified to be offered that upgrade when I was just an FPS1 owner and had not "upgraded" to FPS4 at the time.) I think it 1) worked out well 2) provided a strong Fortran player in place of MS 3) was good for the Fortran on x86 community as well as for DEC
I don't like everything MS does -- but is it truly relevant here? MS don't DO Fortran no mo . . . So forget 'em.
I now have DVF 5.0d and CVF6.1 on my main machine -- and I use both regularly. I don't have experience with any Lahey except the LPF compiler -- so I can't compare. But DVF/CVF is a good solid Fortran in my experience. -- Kevin G. Rhoads, Ph.D. (The Cheshire Cat for official Internet mascot.) kgrhoads@NO_SPAM.alum.mit.edu
Tim Prince wrote: > >they want to be able to walk into Fry's or COMP USA > >and read/feel the package
> There are plenty of linux packages there which include g77. Hence, possibly, > the remarks about "linux fortran."
> >ask > >the computer support team what THEY recommend
> They will never recommend anything which might increase their work load.
We have about 5 separate UNIX networks (some fully separate), 3 of which I have to use myself (1 fully separate). All I asked for was for them to install PERL, EXPECT, and FRAMEMAKER in the same directory structure on each of the systems so that I don't have to modify my documentation conversion macros uniquely to operate on each of those separate systems. In fact, they REFUSED to install EXPECT on any additional systems, even though the first system had it and of course we USED it and have critical EXPECT macros that we can't utilize on the other systems. I've asked for them to install REXX also...but they're basically ignoring me. I was told that they'd be more inclined to install a commercial package than a freeware/shareware package, all I have to do is come up with the funds.
>they'd be more inclined to install a commercial package than a >freeware/shareware package,
I used to hear that at my office. We were never allowed to have a fully working diff program on hpux. Interesting, when many of the utilities in the commercial unix versions are obsolete or buggy versions of gnu free software. That complicates the job of the administrator if they aren't willing to replace the vendor's version with a current working version. It's more important to be able to blame the vendor for the system not working than to get it working. You may need to fix up your scripts with a variable which you can use to designate the path to your own tool directory. But you may have to wait until y2k compliance testing has been forgotten.
I'm no great expect user, but I've never seen a native installation of expect which worked, unless you count cygwin expect which magically works on Windows 2000 on this Pentium II, although it has a few problems on a more modern P III system with identical software installed. Didn't think of it as having a connection with fortran, although it's used to run the egcs compiler test suites. Tim Prince tpri...@computer.org
In article <388BC9E1.26F67...@flash.net>, Gary Scott <sco...@flash.net> wrote:
> In fact, they REFUSED to install EXPECT on any additional systems ... > I've asked for them to install REXX also...but they're basically ignoring me.
Ummm, these people work in a _service_ component of your organization.
Through what combination of your failure to report their arrogance, and management's ineptitude, are they still employees of your organization, and you still working for that organization? Anywhere I worked, these folks would have been packed and out the door the same day that answer was received to a request previously cleared with management, or my resume would have been on the net and in 200 recruiters' hands that evening.
I even know that Unix sysadmins are in short supply and highly paid right now, but one of the pleasures of Unix systems is that they run pretty much unassisted until a change is needed, modulo a clerk to mount backup media before leaving for the night, so losing all your uppity sysadmins while looking for others willing to work for a living isn't that huge a crisis.
FWIW (and I've _been_ a Unix sysadmin, repeatedly).
-- Kent Paul Dolan. <xanth...@well.com> <xanth...@aztec.asu.edu> <xanth...@whistle.com>
On 22 Jan 2000 08:33:34 GMT, dant...@aol.com (Dan Tex1) wrote:
>I'm not knocking CVF. The majority of what I know about it is what people in >this newsgroup write. However.... I have to disagree with Steve 100% on the >marketing statements. Digital marketed the heck out of the product. I >received flyer after flyer in the mail. And.. so did other engineers I work >with who don't even program anything. The flyers were also, IMHO, aimed in >large part at those part time programmers who really aren't active enough at >their own computers to know that Microsofts Fortran products were pretty, >well... lame.
The flyer you are referring to was sent to registered users of Microsoft Fortran PowerStation and those who receive the SciTech International catalog. That was two and a half years ago and we haven't a mailing to non-customers since then (as far as I know...)
Anyway, maybe you'll see some more marketing from us in the future...
Send Visual Fortran support requests to vf-supp...@compaq.com
Steve Lionel (mailto:Steve.Lio...@compaq.com) Fortran Engineering Compaq Computer Corporation, Nashua NH
> It's probably because CVF is by far the most widely used of the > commercial compilers. Figures I have seen from a number of sources > suggest something like a 10:1 sales ratio compared to the next > best-selling compiler.
Don't know whether you're right about this one. If your statistics are coming from resellers they might be skewed. CVF is sold, I believe, almost exclusively through resellers. We sell a lot of compilers direct and correspondingly fewer through resellers.
I can't think of a good way to get an reliable sales ratio of one Fortran compiler versus another without getting the figures from the vendors. I can think of a number of ways of getting an unreliable sales ratio!
Kent Paul Dolan wrote: > In article <388BC9E1.26F67...@flash.net>, Gary Scott <sco...@flash.net> wrote:
> > In fact, they REFUSED to install EXPECT on any additional systems ... > > I've asked for them to install REXX also...but they're basically ignoring me.
> Ummm, these people work in a _service_ component of your organization.
Yup! But in all fairness, they didn't say that _I_ couldn't install it (or any other tool). I just feel that these types of tools ought to be installed as "system" tools for EVERYONE to use and in a "standard" way so that it's actually EASY to port macro sets (things that I need to do real work) across systems without having to install the interpreters myself also (am I strange or something? (don't answer...)).
> Through what combination of your failure to report their arrogance, and > management's ineptitude, are they still employees of your organization, > and you still working for that organization?
They're contracted...they CONTROL us...Actually, in the case of EXPECT, I may be the one and only user on one of the systems. I just hate wasting my time installing tools instead of RUNNING them to accomplish real work.
> I even know that Unix sysadmins are in short supply and highly paid > right now, but one of the pleasures of Unix systems is that they run > pretty much unassisted until a change is needed, modulo a clerk to > mount backup media before leaving for the night, so losing all your > uppity sysadmins while looking for others willing to work for a living > isn't that huge a crisis.
They (UNIX systems) do seem more reliable than our NT's but still noticably less so than our mainframes.
> FWIW (and I've _been_ a Unix sysadmin, repeatedly).
> -- > Kent Paul Dolan. > <xanth...@well.com> <xanth...@aztec.asu.edu> <xanth...@whistle.com>
Yall have a great product. You have a great market share. Now maybe the thing to do with marketing is increase size of the chanel not your share of it.
Market to the IS decision makers. The message would be use CVF with Visual Studio to modernize legacy applications. The advantage to the market is they are not having to rewrite existing applications from scratch just because they are changing platforms or are outdated. The benefit is a huge cost savings in initial development and in testing.
> > It's probably because CVF is by far the most widely used of the > > commercial compilers. Figures I have seen from a number of sources > > suggest something like a 10:1 sales ratio compared to the next > > best-selling compiler.
> Don't know whether you're right about this one. If your statistics are > coming from resellers they might be skewed. CVF is sold, I believe, almost > exclusively through resellers. We sell a lot of compilers direct and > correspondingly fewer through resellers.
> I can't think of a good way to get an reliable sales ratio of one Fortran > compiler versus another without getting the figures from the vendors. I can > think of a number of ways of getting an unreliable sales ratio!
> What sort of marketing do you think would be effective? We do have a > modest budget for marketing, but it's not clear what sort of > advertising would lead to an increase in sales...
Why not take a page from the Mathworks marketing strategy!? Here's why: Market base 400,000 plus. At $100 a pop that's $40 mil. Let's say that 10% of them convinces (after graduation) their employer to buy a copy, this time at $1500 a pop, that's the next $60 mil. Can't do much with Matlab alone so each one buys at least one toolbox, on average at $900 a pop, that is next $36 mil... not bad for "canning" Fortran code!
Here's how: Attractive (academic) entry price and raising the awareness of Fortran *free* assets (netlib, gams) should find a particular resonance at a time of growing momentum for the Open Source Phenomenon.
The irony is that Matlab owes its existence to Fortran and is growing the market primarily out of a Fortran pie. It is succeeding even though the source code and compiled speed are being replaced with a slow black box arithmetic. Surely there must be some valuable PR** mileage derived from that.
btw, I haven't seen your Linux/Fortran announcement on the slashdot site whereas Matlab drivel is everywhere even in the most obscure magazines.
** PCAI mag: "Maximize the Power of Matlab", "Put Matlab toolboxes to work for you", "Matlab, Language of Technical Computing" (Matrix Lab graduated!?)
The mistery switch is, Matlab = f2c-ed Fortran code (www.netlib.org) and the ad works for Fortran as well, minus the negatives. If CVF PR starts reeducating the market we may yet see the reversal of fortunes.
> What sort of marketing do you think would be effective? We do have a > modest budget for marketing, but it's not clear what sort of > advertising would lead to an increase in sales...
Why not take a page from the Mathworks marketing strategy!? Here's why: Market base 400,000 plus. At $100 a pop that's $40 mil. Let's say that 10% of them convinces (after graduation) their employer to buy a copy, this time at $1500 a pop, that's the next $60 mil. Can't do much with Matlab alone so each one buys at least one toolbox, on average at $900 a pop, that is next $36 mil... not bad for "canning" Fortran code!
Here's how: Attractive (academic) entry price and raising the awareness of Fortran *free* assets (netlib, gams) should find a particular resonance at a time of growing momentum for the Open Source Phenomenon.
The irony is that Matlab owes its existence to Fortran and is growing the market primarily out of a Fortran pie. It is succeeding even though the source code and compiled speed are being replaced with a slow black box arithmetic. Surely there must be some valuable PR mileage derived from that.
btw, I haven't seen your Linux/Fortran announcement on the slashdot site whereas Matlab junk is everywhere even in the most obscure magazines. e.g.
PCAI mag: "Maximize the Power of Matlab", "Put Matlab toolboxes to work for you", "Matlab, Language of Technical Computing" (Matrix Lab graduated!?)
The mystery eqn is, Matlab = f2c-ed Fortran code (www.netlib.org) and the ad works for Fortran as well, minus the negatives. If CVF starts reeducating the market we may yet see the reversal of fortunes.
> advertising we do is going to convince, say, C++ users to switch to > Fortran.
No, Steve, but after a while what they will have will be Fortran, whether they understand the process or not. Lately, I've been seeing things in the C++ literature recommending that all function arguments be passed by reference, a stunning conceptual breakthrough that comes on the heels of the previous one in which they passed some arguments by value and some by reference, thereby creating all sorts of truly remarkable effects whenever somebody goofed on an ampersand or an asterisk.
Then, what's this I hear about Java having no pointers? At least, not the type that point to just anywhere in memory allowing user tasks to clobber such unimportant things as interrupt vector tables. (That's as opposed to safe, optimizable, Fortran pointers.) That sounds like somebody, somewhere, got fed up with stepping on landmines, doesn't it?
By refusing to learn from history about why Fortran does certain things, they have condemned themselves to reinventing Fortran. They'll just call it something else (how about "Nartrof"?), and it will involve staggering features such as discovering that most lines don't need semicolons. Stand by for many years of media-hyped intellectual brilliance!
Computers never cease to be a source of great amusement. A couple of weeks ago, I was interested to see an article in Business Week on "software hell," in which the magazine noted that software was a heck of a lot more reliable 20 years ago. Well, shucks, that was back in the days when nobody could rely on awesome CPU speeds and gigantic memory capacities to cover up for sloppy coding\\\\\, errr, brilliant ideas. But, if they expect to get their subscriber database program rewritten in Dibol, they're a little late, I'm afraid.
