Mac Scientific Software Petition
MattSPete
The petition is in response to the recent demise of many major scientific
software packages for the Macintosh (MatLab, SPSS, SysStat, & Statistica).
Without these applications, there will be little incentive for many
universities to continue to purchase Macintoshes. The goal of the petition to
convince Apple that the fate of the MacOS in higher education hinges on the
availability of these products. Apple needs to convince these software
publishers to reenter the market, and should support their efforts as much as
possible.
The petition is available at:
Feel free to distribute news of the petition to other mailing lists,
newsgroups, colleagues, or potentially interested parties. After all, we need
all the support we can get!!!
Fight back for the Mac!
-Matt
----------------------------------------------------------------
Matt Peterson, Ph.D. Ph: (217) 244-4467
Beckman Institute
Univerisity of Illinois email: mpet...@faroe.vp.uiuc.edu
405 North Mathews Avenue
Urbana, IL 61801
www.beckman.uiuc.edu
----------------------------------------------------------------
Dirk Froehling
(MattSPete) wrote:
>Without these applications, there will be little incentive for many
>universities to continue to purchase Macintoshes. The goal of the petition to
>convince Apple that the fate of the MacOS in higher education hinges on the
>availability of these products. Apple needs to convince these software
>publishers to reenter the market, and should support their efforts as much as
>possible.
This is a very good initiative! These are exactly my thoughts.
Dr.-Ing. Dirk Froehling
--
| Dirk Froehling - Germany, Uni Dortmund, FB Maschinenbau, LS Mechanik |
| d...@mech.mb.uni-dortmund.de |
John Christie
> The petition is in response to the recent demise of many major scientific
> software packages for the Macintosh (MatLab, SPSS, SysStat, & Statistica).
> Without these applications, there will be little incentive for many
> universities to continue to purchase Macintoshes. The goal of the petition to
Seeing it displyed this way reminds me that this is probably exactly
what Statistica. MatLab, SPSS, etc. want. They don't want schools buying
Macintosh computers.
I wonder if convincing them to port is better than convincing others
not to use their product. Rather than pushing to get packages for which
there is a rough equivalent supported on out favorite platform maybe we
should just support the rough equivalent. And, we should carry that
support through to promotion in our scientific community of the truly
cross platform products.
Maybe we should tell institutions that have 80 PCs, 10 Unix, and 10
Macs to get a different cross platform software package (like Mathematica
and SAS). We should promote not just our favorite computer but also the
software organizations that promote that computer. Maybe SPSS did the
math and said that they don't care if they lose the Mac market. OK. But,
perhaps they didn't factor in that they would also lose the PC market and
Unix market as well as a result of that. If we can show them that is true
we will be much better off in the long run. We won't have to scramble for
support anymore, we can just point out that dropping the Mac will hurt you
in other markets. Is there anyone out there who can report stories of
institutions abandoning non cross patform software instead of the Mac?
I'm also reminded that any company that does their best to cause others
to standardize on Windows deserved to have Microsoft crush them. Don't
they realize that they are promoting a company whose mission statement is
to eventually wipe them out? That all software should be Microsoft
software.
--
You aren't free if you CAN choose - only if you DO choose.
All you are is the decisions you make.
Remove "*" and ohnny (i.e. jc@) to make nice, polite
academic related replies via email.
AES
petition to
Further bad news is that there seems to be little or no science or
engineering-relevant content to the program for the Mac Expo
coming up in San Francisco in Jan '99.
Matt Jones
Froehling, d...@mech.mb.uni-dortmund.de writes:
>>Without these applications, there will be little incentive for many
>>availability of these products. Apple needs to convince these software
>>publishers to reenter the market, and should support their efforts as much as
>>possible.
>
>This is a very good initiative! These are exactly my thoughts.
>
>Dr.-Ing. Dirk Froehling
>
Sorry, my newsreader doesn't show me the full text of the original post,
but I would certainly be interested in adding my name to such a petition.
Can anyone provide more information please?
Matt Jones
Thomas L. Ferrell
been able to find better applications than some of those mentioned. For
example, IDL is a fantastic package and Mathematica is top flight all
the way. In electronics design and simulation, Capilano, Douglas,
BeigeBag, and others have products, but I dearly wish someone would port
the freeware (from Berkeley) program Magic to the Mac. The source code
is available for download. I run it inder Tenon's BSD unix along with
other stuff and programs like PowerView and Epoch are very, very fast on
an 8600/300. But a PPC native version would be a killer app. Jim Klein
has written an excellent freeware optics design program for Windows, and
a port of it would be another worthy cause for the Mac programming
community. With the G4 on the horizon giving us the capabilities of a
Cray of just a few years back, we'll have an enormous speed advantage
but need the sw in order to go anywhere in our speed demons.
Thomas L. Ferrell, PhD
Health Sciences Research Division
Oak Ridge National Laboratory
Jeff at MacTech
>... but I dearly wish someone would port
>the freeware (from Berkeley) program Magic to the Mac. The source code
>is available for download. I run it inder Tenon's BSD unix along with
>other stuff and programs like PowerView and Epoch are very, very fast on
>an 8600/300. But a PPC native version would be a killer app. Jim Klein
>has written an excellent freeware optics design program for Windows, and
>a port of it would be another worthy cause for the Mac programming
>community. With the G4 on the horizon giving us the capabilities of a
>Cray of just a few years back, we'll have an enormous speed advantage
>but need the sw in order to go anywhere in our speed demons.
OS X Server and then OS X will have a BSD variant under the hood, so such
porting efforts should be much easier and, therefore, much more common. I
don't know if Apple is going to do any of the porting itself (I believe
that Apache works "out of the box", so to speak), but it could be an
interesting use of some of their resources. Something like GIMP (the image
processing app) would be an excellent showpiece, but I don't know if this
will happen. (Apple has said that they don't plan to ship an X Window
Server, althought third-party solutions will surely appear. I don't know
if there will be a more elegant way to put a GUI on Unix apps under OS X.)
--
__________________________________________________________________________
Jeff Clites Online Editor http://www.MacTech.com/
onl...@MacTech.com MacTech Magazine
__________________________________________________________________________
Francis Courtois
> I am writing in regards to a petition for scientific software on the
MacOS.
> The petition is in response to the recent demise of many major scientific
> software packages for the Macintosh (MatLab, SPSS, SysStat, & Statistica).
> Without these applications, there will be little incentive for many
> universities to continue to purchase Macintoshes. The goal of the petition to
> convince Apple that the fate of the MacOS in higher education hinges on the
> availability of these products. Apple needs to convince these software
> publishers to reenter the market, and should support their efforts as much as
> possible.
>
>
> The petition is available at:
>
>
> members.aol.com/mattspete
>
>
> Feel free to distribute news of the petition to other mailing lists,
> newsgroups, colleagues, or potentially interested parties. After all, we need
> all the support we can get!!!
>
>
> Fight back for the Mac!
Good Idea... but let me tell you that I think mac is already almost dead.
Apple has made too much mistakes. They have had the best OS but it is not
so obvious now. I use now win95, macOS and Linux and I can tell you that
Mac is dead. And MkLinux is nothing to compare to Linux/PC. I'm sorry but
they are late.
The best deal now is a cheap Pentium II at $1300 with both win98 and
linux... you have almost everything in it. The best of unix and the best
of PC with cheaper accs and soft. Of course there are still some softs
that exists only on Mac... but not that much.
In my univ. in France, we buy more and more PC instead of mac and sun.
Here in UCDavis, it looks the same.
Best platform for office... win/PC !
Best platform for maths/programming... Linux/PC !
Best price... PC !
For those who are computer skilled, switch to PC/Linux and you'll see.
I really regret how bad Apple manages their brand. Anyway, now it is
obviously to late to reverse the steam.
--
Francis
--
Visiting professor at the University of California at Davis.
F. Courtois, Bio. & Agr. Eng. dept., One Shields Avenue, Davis, CA 95616, USA
Phone:(530)752-1020, Fax:(530)752-2640
mailto:cour...@ensia.inra.fr or mailto:fcou...@ucdavis.edu
Home phone:(530)792-1273.
John W Robbins
> With the G4 on the horizon giving us the capabilities of a
> Cray of just a few years back, we'll have an enormous speed advantage
> but need the sw in order to go anywhere in our speed demons.
>
This is very true. Mac users as well as Apple need to keep scientific
developers aware of these coming hardware developments. The G4 chip with
AltiVec technology promises to blow the socks off of what is currently
available. If scientific software developers are bailing out of the Mac
market right now, they themselves are really blowing what could be a
tremendously large desktop/laptop market among colleges, universities and
research institutes. With the introduction of G4 based Macs and AltiVec
processing, a revolution in desktop processing is imminent - what a way to
start a new millennium! This could be a good time for start-up companies to
begin to prepare to fill those scientific and engineering niches and needs.
--
John Robbins
Gary L. Gray
wrote:
> Sorry, my newsreader doesn't show me the full text of the original post,
> but I would certainly be interested in adding my name to such a petition.
> Can anyone provide more information please?
From the original post:
The petition is available at:
--
Gary L. Gray Engineering Science & Mechanics
Assistant Professor Penn State University
mailto:gr...@engr.psu.edu (814) 863-1778
http://www.esm.psu.edu/HTMLs/Faculty/GGray.html
Dirk
>In article <df-021198...@muffin.maschinenbau.uni-dortmund.de> Dirk
>Froehling, d...@mech.mb.uni-dortmund.de writes:
>>This is a very good initiative! These are exactly my thoughts.
>Sorry, my newsreader doesn't show me the full text of the original post,
>but I would certainly be interested in adding my name to such a petition.
>Can anyone provide more information please?
>
>Matt Jones
Please look at http://members.aol.com/mattspete/ for the petition.
Dirk
Matthew Vaughn
WORLD benchmark tests show, the CURRENT G3 (not even G4) is faster or as
fast (except in FPU where it lags by like 5 %) as a PII and definitely
uses less power/etc so it can run in a laptop. Then there's the price.
Top-end G3 systems, esp those configured to do science (lots of RAM,
didn't spend 500 dollars on video-editing capabilities, fast UW-SCSI HD,
100Mbit Enet) are CHEAP in comparison to a PII of similar configuration
(and the PII will still lag behind in most tests!)
--
<DARWIN><
' '
Jon Naude
Oh come on, you still believe the Apple hype? The G3 was supposed to be
the fastest thing on the planet and what happened? The Pentium crowd
upped their performance and there was no longer a big deal.
Jon
Garry Jolley-Rogers
no use without software that uses its capabilities. That is - its only
as good as it is allowed to be. Unless vendors take the time to recompile
and optimize then the best design is still a dog. As I understand it, the
G3 can easily beat a pentium when the software is compiled and optimized.
Sadly, this is often not the case. Thus the need to encourage native
software. I think this petition is a very good idea.
Garry
In article <1di0ddf.nfv...@mailbox212.univie.ac.at>,
Stefan Krey
> In my univ. in France, we buy more and more PC instead of mac and sun.
> Here in UCDavis, it looks the same.
And in our group we buy more and more Macs. Since the days of the
early classic Macs, we do data acquisition, data manipulation,
number crunching and all publications on Macs. All machines are
working reliable over years, whereas the few PC´s are mostly
out of work.
The only maintenance on our Macs, as I remember, was exchanging
2 fans and a few Lithium batteries of some older models. Most of them
run around the clock. Even the oldest models are fast enough
to do the data acquisition in most experiments. The newer and faster
models are used for more expensive calculations and for the publishing.
Stefan
--
Stefan Krey
email: stefa...@hamburg.netsurf.de (private site)
kr...@physnet.uni-hamburg.de (office)
www: http://www.physnet.uni-hamburg.de/home/vms/krey/
John Christie
stefa...@hamburg.netsurf.de (Stefan Krey) wrote:
> And in our group we buy more and more Macs. Since the days of the
> early classic Macs, we do data acquisition, data manipulation,
> number crunching and all publications on Macs. All machines are
> working reliable over years, whereas the few PCæ„€ are mostly
> out of work.
Similar here, we still have a IIx collecting data for experiments. It
is 9 years old. The only service our Macs ever needed was due to people
blocking the cooling vents on old Plus's. In 10 years we replaced one HD
due to failure (some others due to expansion). On our floor we have the
largest lab and it has the highest productivity, and it is 90% Apple. The
size and productivity is something we have acquired over that time. All
other labs in our section are mosly PC. I hear horror stories of multiple
replacements of HD's and walk by labs full of PCs that are never used
while the members of those labs try to get time on our equipment. We just
had an eqiupment failure; it was an HP printer; we will try to replace it
with a used Apple one.
> The only maintenance on our Macs, as I remember, was exchanging
> 2 fans and a few Lithium batteries of some older models.
We have yet to have a lithium battery failure in a non laptop. Even
our IIx is still going strong without a single repair (it has lasted
longer than our PDP's and has been much more reliable).
Bernie Wieser
This is a bit of a long ramble, sapientia is appreciated.
First, my shameless plug. OMDI produces math and imaging add-ins
for Excel. (http://www.octavian.com/excel.html).
Personally, I think it would not be so bad if certain players left the MacOS
market, because
there are numerous "small" players that then have an opportunity to
grow into the empty space (some even have better products, but
unfortunately most have little if any exposure. I'll leave comments
about Apple's failure to promote these markets for a different
rant.) Unfortunately, lack-of-tools from perceived "big" players is often
a convenient, and somewhat incorrect, rationalization for companies
to not get into or not support a platform. What can you do about it?
(Answer later.)
Previously, I worked for a company involved in simulation.
Most of my income comes from consulting to sci-tech companies. I've had
contact with a lot of engineering and sci-tech companies. You must
understand the reasons for "big" players leaving the market. I'm
going to rank these from most important to least important.
1) political and or religious bias in upper management
It does not matter if it is Mac or any Unix flavor. Many individuals with
control over purse strings and with the power to make irrational
sweeping decisions have not, and do not use any platform other
than Windows. The historical reasons on this topic are too big
to get into. What matters is that these individuals feel good
being on the bandwagon - and like the Pope is a little bit
closer to [the christian] God - by blindly supporting the "Microsoft
platform" these individuals are a bit closer to Bill. You have no
better chance of converting them than you do of the deeply
religious, as the strongest ties to their decisions are not supported
by physical, factual rationale.
In three companies now, I have been witness to the following
directive: "You can pick from any Microsoft platform or technology
to implement a solution."
2) political and or religious bias in IS and IT
Although the reality is we live in a multi-vendor, multi-platform world,
there is a common misconception that costs can be reduced by
picking the homogeneous platform. Many of us know that the
best, most innovative, most elegant solutions never get the
exposure they deserve. Its all about promotion and mind-share.
Its also about fear of the unknown. Many IS/IT departments
push what they know. They don't know MacOS. And, as
one IS fellow that works with my wife pointed out -
"If we supported MacOS, there wouldn't be anything for me
to do, so I'd be out of a job."
So for IS, it is more than religious, it is a motivation based
on some fear, that lets them actively work against the
multi-platform solution, and 1) many IS/IT departments
make the purchasing, 2) many IS/IT report directly to
upper management.
3) market share
Most companies try target the audience based on market share.
It makes sense. If you know that 70% of your market uses
Windows (in one form or another), 25% uses a Unix flavor,
and 5% uses "other", then your priorities are pretty clear.
4) availability of resources
My above numbers are more typical to engineering than
the consumer space. But most resources for development
can be thought of as fitting the consumer space.
Good resources are hard to find - especially with platform
expertise - more so with multi-platform expertise.
In general, you'll find development managers fitting into
the clique of "no clue" re multi-platform development,
with the same biases as others.
5) distribution of resources and work process
Many companies that develop sci-tech software are
not founded on solid software engineering principals.
So you have the usual glut of "pile people on the problem."
Of course, the problem is prioritized for the target audience.
This means many companies have 40 people working on
the Windows version, and maybe 2 or 3 working on "ports".
Ports are always behind - you just can't match productivity
on this scale... and unrealistic work process will mean that
40 people might be making platform-specific short-cuts
to get the product out on time. They will use platform-specific
tools and frameworks. The real issue of multi-platform
support can often be solved in process - not technology -
but try selling "software engineer" or applied software
management to companies that have no knowledge
of what is involved. You always get buy-in for process improvement -
with the next day question "Have you started coding yet?"
Anyway - you cannot fight this battle by petitioning. The decision
makers "feel negative" because you are trying to enforce what
really is a contradictory belief - no matter what the rationalization.
And, these people are surrounded by individuals that share the
belief and support the decisions.
Speaking with dollars is also hard. Sales figures are often
not compared to relative market size. I know of several products
that would/were profitable on MacOS but the decision
was made "to focus on the primary market." Go for the
80% cash cow.
The only real way to promote sci-tech software in the MacOS
market is to support companies that have MacOS offerings
and publically stated "open" strategy. You might not be able
to get the "best" tool, or the "defacto/du jour" tool, but you
will promote the vendors to grow in these directions by
supporting them. You can probably get the 90% of the
function you need through multiple vendors. Think of it this
way - you probably only use 30% of the functionality in
any large, monolithic, do-it-all type package.
And as the smaller vendors are usually cash strapped
and cannot market themselves effectively (seriously,
my advertising dollars are very limited, and I have
a mostly vertical product that I could advertise in
nearly 100 technical journals, where EACH one would
only hit the tiniest portion of my potiential market -
at $2K per ad with potential revenue of $.2K, it
just doesn't make sense to market through traditional
channels). Spread the word. Get the site license. Publish
a paper. Link to their web pages.
You should also politely, non-intrusively educate your
employer. "I want to use the best tools that I am
most familiar with to get my max productivity without
artificial constraints." Show them. And if they tell you
what brand hammer to use to fasten that screw -
find a more enlightened employer. (Easier said
than done right?)
Bernie Wieser, OMDI
p.s. previous rants include
- why I can't get capital to do Mac projects
- why Apple shot itself in the sci-tech market
- why making everything part of the "OS" is great
for open systems, and why open systems are
terrible for business (the freeware principle)
MattSPete wrote in message <19981101232314...@ng69.aol.com>...
> I am writing in regards to a petition for scientific software on the
MacOS.
>The petition is in response to the recent demise of many major scientific
>software packages for the Macintosh (MatLab, SPSS, SysStat, & Statistica).
>Without these applications, there will be little incentive for many
>universities to continue to purchase Macintoshes. The goal of the petition
to
>convince Apple that the fate of the MacOS in higher education hinges on the
>availability of these products. Apple needs to convince these software
>publishers to reenter the market, and should support their efforts as much
as
>possible.
>
>
>The petition is available at:
>
>
> members.aol.com/mattspete
>
>
> Feel free to distribute news of the petition to other mailing lists,
>newsgroups, colleagues, or potentially interested parties. After all, we
need
>all the support we can get!!!
>
>
>Fight back for the Mac!
Roberto Celi
assessment of the situation. However, I still believe that Matt
Peterson's petition drive is an excellent idea. For example, it could
send Apple three messages that I think are important:
1 -- If a piece of scientific software is no longer supported, take
*extra* care in making sure that MacOS updates are compatible with it.
Take Matlab, for example. The last version for the Mac, 5.2.1, luckily
seems to be compatible with 8.5. Make sure that it stays that way with
8.6, 9.0, and OS X. In my opinion, Matlab is going the way Word and
PowerPoint have gone, that is, toward "bloatware". This would mean that
the current version may be sufficient for most needs for many years to
come, if we don't get unpleasant surprises with future MacOS updates.
2 -- Leverage the UNIX core of OS X to increase the availability of
scientific software. Staying with the Matlab example, ideally Apple
should make it possible to read and load on a Mac a Matlab version for
UNIX. Not trivial, I suppose, but not impossibly difficult for Apple (I
don't think we should count on any third party developers for this).
3 -- Appoint an evangelist for scientific and technical software, and
make his or her e-mail address widely available to the Mac scientific
community.
Roberto
Bernie Wieser
Apple has historically had trouble staffing the position of
"engineering" evangelist - and when they have - the mandate
has pretty much been "support those already in the market,
or those with killer apps". The problem is in the sci-tech-eng
space, core tools are not considered killer apps.
Another problem with former evangelism is the repeated
ability to wear blinders, gather around only positive reinforcement,
and general clique creation. This doesn't go very far if
the object is growing an embryonic market (bad word? I would say
there is no real sci-tech-eng Mac market today).
Anyone that went to the engineering sessions at previous years
WWDC knows what I mean.
Apple cannot help. Its not really their job. (Flames on?)
Roberto Celi wrote in message <364A21...@eng.umd.edu>...
AES
* "engineering" evangelist - and when they have - the mandate
* has pretty much been "support those already in the market,
* or those with killer apps". The problem is in the sci-tech-eng
* space, core tools are not considered killer apps.
*
* Another problem with former evangelism is the repeated
* ability to wear blinders, gather around only positive reinforcement,
* and general clique creation. This doesn't go very far if
* the object is growing an embryonic market (bad word? I would say
* there is no real sci-tech-eng Mac market today).
*
* Anyone that went to the engineering sessions at previous years
* WWDC knows what I mean.
Received a bulk mail catalog today: "SciTech Academic: Your Technical
Computing Tools Catalog" -- 56 pages of fine print, allegedly 1850
products. Tons of cool stuff -- a few Mac things buried here and there,
a few cross platform items, but probably 95% of it Windows only, to the
extent that many of the ads don't even both saying that their product is
for Windows, it's just assumed. Pretty discouraging.
Thomas L. Ferrell
Bernie Wieser wrote:
> snip...
>
> I would say
> there is no real sci-tech-eng Mac market today
>
> Anyone that went to the engineering sessions at previous years
> WWDC knows what I mean.
> snip...
I disagree--witness this newsgroup, the National Laboratories that are Mac
centric, and the widespread use of Macs in scientific education as well as
in many other areas of science. Certainly Apple experienced some bad years,
but both the market and the capabilities are increasing rapidly. In fact,
the turn-around has been astonishing. A salient fact is that the computer
world changes extremely rapidly and it is very difficult to predict. This
means that the best safeguard for a company is diversity---just as in the
investment world. Those software companies who do not offer platform
diversity will assuredly die. Even Microsoft has 200 Mac programmers and
long-term success should always outweigh the short-sighted paradigm of doing
away with all but the most profitable products. For Apple itself it means
they must diversify their markets as a long-term strategy. They have begun a
"one step at a time" plan and the scientific market is too enormous to
ignore as the plan moves forward. Certainly other market proponents have
the ear of Steve Jobs just now, but we need to make some noise. I spend
thousands each year on Mac software and would love to buy more. This
platform saves me money and loads of time vis a vis our PCs. It is no small
coincidence that the Nobel prize last year was won by a Mac user---it's
certainly the platform of choice for those whose time is valuable---unless
perhaps they've not experienced an environment demanding large numbers of
personal computers (not really an excuse). Apple is fully cognizant of their
advantages and I hope they will continue to advertise them. Users have to
struggle with network administrators who are aware that their empire is
ensured if it uses PCs--they get vastly more help calls. We need to become a
squeaky wheel and the petition is just one way of doing so.
Christopher Wright
<ber...@octavian.com> wrote:
>Apple cannot help. Its not really their job. (Flames on?)
Fact is that Apple sells hardware, not software. It really isn't realistic
to expect that they'll be interested in expanding into the software biz,
especially a vertical market like engineering or technology. This is
reallya job for people who know the science/engineering market intimately.
And instead of thumping on Apple, we thump on software people. And if
existing developers aren't responsive, do it ourselves. I use COSMOS/M on
a PTP 250 It's a pretty good combination which could become a killer
combination with a little attention paid to the stuff that makes Apple
great, like making COSMOS fully scriptable instead of using a somewhat
lame macro language or using Quickdraw 3D for graphic output. Given that
SRAC has promised no further development of the Mac version of COSMOS,
I've pondered whether they'd release the Mac version of the code to a
third party who'd develop it further. The current state of things isn't
too bad, but it could be better. What would it take to gradually replace
existing pieces of code (solver, mesher, graphic postprocessor for
example) with code optimized for the MacOS and PPC? Or is this just a bad
idea?
--
Christopher Wright P.E. |"They couldn't hit an elephant from
chr...@skypoint.com | this distance" (last words of Gen.
___________________________| John Sedgwick, Spotsylvania 1864)
http://www.skypoint.com/~chrisw
John Christie
chr...@skypoint.com (Christopher Wright) wrote:
> And instead of thumping on Apple, we thump on software people. And if
> existing developers aren't responsive, do it ourselves. I use COSMOS/M on
Which reminds me. Does anyone else think that our science programs
should be open source? We hear occasional reports that this piece of
software is more or less accurate than that in many scientific
enterprises. Statistics, for example, seems to me a piece of software
that is a prime candidate for having the source code open and available to
scrutiny. If it isn't verification has to be somewhat roundabout and
incomplete. Testing every eventuality is much less efficient than
designing something correctly in the first place. Does anyone know of a
current free source code Stats program we could start with? I know of
ViSta and MacANOVA. What do we think the best language would be? What
other science programs should be Open Source? Perhaps a more concerted
effort to bring MuPad into competition with the commercial packages should
be made within out universities instead of leaving everything up to the
Germans.
Roberto Celi
>
> In article <chrisw-1211...@tc0137.skypoint.net>,
> chr...@skypoint.com (Christopher Wright) wrote:
>
> > And instead of thumping on Apple, we thump on software people. And if
> > existing developers aren't responsive, do it ourselves. I use COSMOS/M on
>
> Which reminds me. Does anyone else think that our science programs
> should be open source? We hear occasional reports that this piece of
I think this is a very good point. I don't know if this is what John
meant but: I think that there are two potential groups of developers for
Mac sci-tech software, those who do the "kernels" and those who do the
GUIs. I would belong to the first category. To generate my research
results I write software that is quite sophisticated and
state-of-the-art for my field; portions of it may be of some interest
outside my field too. But the GUI is miserable to nonexistent (these
are mostly Fortran programs with text files for I/O), and although I
know the very basics of Mac GUI programming, I wouldn't have the time to
do anywhere near a professional job. I suppose that the opposite
argument may hold for many people who can do good Mac programming: the
GUIs would be professionally done, the kernels may not.
I think that the job of an Apple sci-tech evangelist (and yes, I have
read and thought about the postings of this thread about this specific
topic) should be that of bringing the two communities together. The
Windows and Unix worlds have the resources for companies that can hire
from both groups of people, and make them work under the same roof. The
Mac world often does not, and perhaps some alternative, grass roots type
of effort should be devised with the help of the Mother Ship at 1
Infinite Loop.
Roberto
-----------------------------------------------------------------------
Dr. Roberto Celi phone: (301)
405-1132
Department of Aerospace Engineering FAX: (301)
314-9001
University of Maryland, College Park, MD 20742
http://aerospace.umd.edu/Sections/Faculty/celi.html
-----------------------------------------------------------------------
Marcus H. Mendenhall
John Christie wrote:
> Which reminds me. Does anyone else think that our science programs
> should be open source? We hear occasional reports that this piece of
> software is more or less accurate than that in many scientific
> enterprises. Statistics, for example, seems to me a piece of software
> that is a prime candidate for having the source code open and available to
> scrutiny. If it isn't verification has to be somewhat roundabout and
> incomplete. Testing every eventuality is much less efficient than
> designing something correctly in the first place. Does anyone know of a
> current free source code Stats program we could start with? I know of
> ViSta and MacANOVA. What do we think the best language would be? What
> other science programs should be Open Source? Perhaps a more concerted
> effort to bring MuPad into competition with the commercial packages should
> be made within out universities instead of leaving everything up to the
> Germans.
I have recently been spinning up on ROOT, which is a data
analysis/graphics/everything else program from CERN. I am using the
LinuxPPC version, which is superb. It has been partly ported to MacOS
(the core is ported, the screen graphics are not). It is based on the
CINT system (a C++ intperpreter acting as a scripting language) and a
vast library of graphics and analysis
components. If someone had the time to port a graphics library for
this, it would be an amazingly useful tool under MacOS. Of course, when
OS-X is available, the port will be trivial, I suspect.
Marcus Mendenhall
Bernie Wieser
AES wrote in message ...
>Received a bulk mail catalog today: "SciTech Academic: Your Technical
>Computing Tools Catalog" -- 56 pages of fine print, allegedly 1850
>products. Tons of cool stuff -- a few Mac things buried here and there,
>a few cross platform items, but probably 95% of it Windows only, to the
>extent that many of the ads don't even both saying that their product is
>for Windows, it's just assumed. Pretty discouraging.
Grab your favorite CEP directory, Sigma catalog, or go to the online ASME
database. The story is the same all over.
One interesting irony - AiCHE does most of its publishing on MacOS.
B.
Bernie Wieser
Christopher Wright wrote in message ...
>In article <364af...@198.161.96.27>, "Bernie Wieser"
><ber...@octavian.com> wrote:
>
>>Apple cannot help. Its not really their job. (Flames on?)
>
>combination with a little attention paid to the stuff that makes Apple
>great, like making COSMOS fully scriptable instead of using a somewhat
Ouch. As I was responsible for a port of a big chemical process simulator
many moons ago - we had numerous flames and bad press because
the tool was NOT Mac-like. There is a pervasive belief that MacOS
users are very picky and refuse to buy ports. Very odd in a vertical
market where function is the most important feature, and interface
is usually secondary.
>existing pieces of code (solver, mesher, graphic postprocessor for
>example) with code optimized for the MacOS and PPC? Or is this just a bad
>idea?
Any math tools would be pretty simple as they're usually pure C/C++/Fortran
(etc.)
Any interface tools (graphics for display or print) get tough - especially
if they
have moved to proprietary formats, du jour formats (D3D), or defacto ones
(OpenGL).
Most vector packages can be ported in a short time (from experience, maybe
one month). The trouble is how to deal with support for different aspect
ratio.
However, many of these companies consider their products to be the crown
jewels and will rigorously protect (read covet?) them. My experience about
going to third parties to port is about as successful as going to VenCap
with a Mac product... "No."
Ports aren't the best solution - always in keep-up, diff, merge. Always
behind. Core code strategies are much better, but assume a good
development process and methodology for controlling cross platform
code. Very few companies have the experience to do this effectively,
and any stress (read slight time increase) to accomplish it is goal
is taken very poorly.
Just my humble opinion.
B.
Joshua Margolin
Joshua Margolin
AES wrote:
> * Without these applications, there will be little incentive for many
> * universities to continue to purchase Macintoshes. The goal of the
> petition to
>
> Further bad news is that there seems to be little or no science or
> engineering-relevant content to the program for the Mac Expo
> coming up in San Francisco in Jan '99.
--
Argus Interware, Inc.
350 5th Ave., Suite 2819
New York, N.Y. 10118
Phone: (212) 563-8600
Fax: (212) 594-0800
http://www.argusint.com
email: sup...@argusint.com
Developing and Marketing the Argus ONE - An Integrated Numerical Pre- and
Post-Processor for all the models you're using and developing.
Joshua Margolin
will port many engineering/scientific products to the Mac. This way this
company can still be in business because the volume of many packages will
compensate for the small volume of Mac users in engineeing.
Run this by Steve Jobs
Joshua
Christopher Wright wrote:
> In article <364af...@198.161.96.27>, "Bernie Wieser"
> <ber...@octavian.com> wrote:
>
> >Apple cannot help. Its not really their job. (Flames on?)
>
> Fact is that Apple sells hardware, not software. It really isn't realistic
> to expect that they'll be interested in expanding into the software biz,
> especially a vertical market like engineering or technology. This is
> reallya job for people who know the science/engineering market intimately.
> And instead of thumping on Apple, we thump on software people. And if
> existing developers aren't responsive, do it ourselves. I use COSMOS/M on
> a PTP 250 It's a pretty good combination which could become a killer
> combination with a little attention paid to the stuff that makes Apple
> great, like making COSMOS fully scriptable instead of using a somewhat
> lame macro language or using Quickdraw 3D for graphic output. Given that
> SRAC has promised no further development of the Mac version of COSMOS,
> I've pondered whether they'd release the Mac version of the code to a
> third party who'd develop it further. The current state of things isn't
> too bad, but it could be better. What would it take to gradually replace
> existing pieces of code (solver, mesher, graphic postprocessor for
> example) with code optimized for the MacOS and PPC? Or is this just a bad
> idea?
>
> --
> Christopher Wright P.E. |"They couldn't hit an elephant from
> chr...@skypoint.com | this distance" (last words of Gen.
> ___________________________| John Sedgwick, Spotsylvania 1864)
> http://www.skypoint.com/~chrisw
--
AES
<marg...@argusint.com> wrote:
* And when was there enginnering content at Mac Expos? NEVER
*
* Joshua Margolin
Sorry -- what I was remembering was the First Annual Conference on
Scientific and Engineering Applications of the Macintosh (SEAM '92), held
in San Francisco in January 1992. I thought I remembered that meeting as
being coincident with a Mac Expo in SF that same January, but I don't at
this point remember . . .
--- and from consulting the MacSciTech home page, I guess the LAST Annual
SEAM (real, not virtual) was 1995 . . . ?
Vladimir Avdonin
<ber...@octavian.com> wrote:
> Ouch. As I was responsible for a port of a big chemical process simulator
> many moons ago - we had numerous flames and bad press because
> the tool was NOT Mac-like. There is a pervasive belief that MacOS
> users are very picky and refuse to buy ports. Very odd in a vertical
> market where function is the most important feature, and interface
> is usually secondary.
Not at all in mac case. It is an interface that save time and efforts. I
am developing an electrophysiology program which is along the lines of
wide spread commercial program, the ported one. Currently my program is
inferior functionally in most case, but more consistent mac approach have
higher value both for me and for number of other people using it.
In general I believe it is better to loose 1 hr once a month to work
around missing function then loose 5 min every hour to strugle with clunky
interface. Also bad interface is a source of regular confusions that not
only waist the time but may cause data damage.
oops, looks like i am off subject, sorry
Vladimir Avdonin
Jeff Greenberg
petition: to get Steve Jobs interested in strategic scientific software for
the Mac. Matlab is the application I care most about (since the lack of
Matlab cross-platform compatibility will force me to give up my mac). It is
also a product that plays a strategic role in science, engineering and
engineering education. This last market may be of some importance to Apple.
I agree that grass-roots support and marketing arguments will make no
difference to managers at the Mathworks. But a call from Steve Jobs, Apple
assisstance in providing Mac support and possible cost sharing might do the
trick. For Apple it's a relatively low cost way to keep macs in the hands of
thousands of engineering students.
No matter what, it won't hurt the situation.
--------------------------------------------------------------------
Jeff Greenberg Ford Research Laboratory Dearborn,MI
jgre...@ford.com PROFS:JGREENB2 Phone: (313) 323 8273
----------
In article <3649d...@198.161.96.27>, "Bernie Wieser" <ber...@octavian.com>
wrote:
Scott Gustafson
> Maybe it is a good idea to call on Apple to form (or initiate) a company that
> will port many engineering/scientific products to the Mac. This way this
> company can still be in business because the volume of many packages will
> compensate for the small volume of Mac users in engineeing.
This is an interesting idea. I own a company, Garlic Software, and this
sounds like a good idea to me. If anyone has a program they would like
developed, ported, or modified for Macintosh, send me an email. I also
write software for the Palm Pilot. So if there is some data collection
task that you need a portable solution to, let me know. I'm currently
working on solutions for Applied Materials and SGI.
And for any of those government people, I've had Secret clearance through
NASA-Ames and the US Army.
Later,
scott
--
The opinions expressed here are not the opinions of Seiko EPSON or
any other EPSON affiliate.
Bernie Wieser
Scott Gustafson wrote in message ...
>In article <364F0A4B...@argusint.com>, Joshua Margolin
<marg...@argusint.com> wrote:
>> Maybe it is a good idea to call on Apple to form (or initiate) a company
that
>> will port many engineering/scientific products to the Mac. This way this
>> company can still be in business because the volume of many packages will
>> compensate for the small volume of Mac users in engineeing.
>
>This is an interesting idea. I own a company, Garlic Software, and this
This is a bad idea. And you have historical precidence re Apple's interest.
Once upon
a time, they had an enterprise solutions group. This group was responsible
for
finding Macintosh solutions in enterprise in various vertical markets. For
the most part,
they ended up doing custom solutions. Apple killed the group, even though
they
were pretty much responsible for getting Apple a toe-hold in many an
enterprise.
"It's not our business," was the primary justification. "Focus on our
primary business
- making integrated hardware/software for the consumer space."
So... I don't think it is more than a wild guess that Apple would have no
interest in
funding such a start up. The '96 WWDC where Guy brought in those successful
Mac vencapists - none of which said they'd support a Mac start-up then - was
a good show of why. As was Guy's failed garage.com... To do any successful
engineering app, even a port, you are looking at pretty significant
investment.
You will need to have people in the problem domain (experts) from both a
technical
and supporting side. The brutal reality about any venture is <1M, nobody
will
take you seriously (there aren't many angels). 1M+, considering Apple's
revenue, Apple would be nuts considering the hundreds of projects they
could fund, none of which would advance their business significantly.
Real vencaps would want to see returns - and so called money-managers have
real biases towards the largest market segment because they have the best
chance of success.
Any, there have been articles in various trade mags about why Garage failed
(from the mouth of Guy himself - nobody would give him any money.)
I'll take an optimistic view now... if there were a Mac fund I could invest
in with
the sole purpose of support Mac start-ups - I'd throw in a few bucks. But
there are already a bunch of capital starved Mac friendly or Mac only
companies...
picking and choosing [a winner] would be a tough job.
B.
Scott Gustafson
>Scott Gustafson wrote in message ...
>>In article <364F0A4B...@argusint.com>, Joshua Margolin
><marg...@argusint.com> wrote:
>>> Maybe it is a good idea to call on Apple to form (or initiate) a company
>that
>>> will port many engineering/scientific products to the Mac. This way this
>>> company can still be in business because the volume of many packages will
>>> compensate for the small volume of Mac users in engineeing.
>>
>>This is an interesting idea. I own a company, Garlic Software, and this
>
>This is a bad idea. And you have historical precidence re Apple's interest.
I agree that I wouldn't want Apple to do anything about it, but I certainly
can. I don't think Apple has the time or money to worry about any vertical
market, they should be more concerned about getting their lost customers
back and building up their new customer base. So, what I was saying was that
my company can get into any vertical market I want, and this sounds like
a good one. Since there are many Macs out in the engineering and science
field, and I have a science background, sounds like I can have some fun doing
what I like, writting software. And if this just happens to be in a field
that I know a little about, then all the better.
So, I will renew my statement that if anyone needs a software product
developed or updated to modern MacOS, please send me an email.
Later,
scott
--
Scott Gustafson (sco...@garlic.com) http://www.garlic.com/~scottg
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook
PGP key available upon request.
Key fingerprint = D0 83 1E AF AC 5E E3 C9 D2 96 08 A0 F1 90 BF 86
Joshua Margolin
Bernie Wieser wrote:
> Scott Gustafson wrote in message ...
> >In article <364F0A4B...@argusint.com>, Joshua Margolin
> <marg...@argusint.com> wrote:
> >> Maybe it is a good idea to call on Apple to form (or initiate) a company
> that
> >> will port many engineering/scientific products to the Mac. This way this
> >> company can still be in business because the volume of many packages will
> >> compensate for the small volume of Mac users in engineeing.
> >
> >This is an interesting idea. I own a company, Garlic Software, and this
>
> This is a bad idea. And you have historical precidence re Apple's interest.
> Once upon
> a time, they had an enterprise solutions group. This group was responsible
> for
> finding Macintosh solutions in enterprise in various vertical markets. For
> the most part,
> they ended up doing custom solutions. Apple killed the group, even though
> they
> were pretty much responsible for getting Apple a toe-hold in many an
> enterprise.
> "It's not our business," was the primary justification. "Focus on our
> primary business
> - making integrated hardware/software for the consumer space."
Bernie:
Apple is known for its talent to have the best product in the market and fail.
Much of Microsoft's success is attributed to its ability to work with industry
and gov. all around the world to provide them with custom solutions. That is
how they get their products used by large customers, make a lot of money, and
take the and re-integrated into their horizontal products.
Joshua
Thomas L. Ferrell
working with software firms. Venture capital, as discussed by Bernie, is
not the only way. For example, I know several companies who have
benefited from the Small Business Innovative Research (SBIR) program.
This has allowed Mac sw development for a number of scientific projects
and has produced niche products that created a nice revenue stream for
them. Once the facts of the bottom line and growth curve are known, it
is possible to attract venture capital for any projected expansion.
Another case I know about involved the development of cross-platform,
scientific training sw for large concerns. This instance has been
dramatically successful. The key is to get something off the ground with
an SBIR, STTR, or other grant, including foundation grants and then to
move into the marketplace. The best results I've seen had a targeted
market and expanded from there.
Regards,
Bernie Wieser
Scott Gustafson wrote in message ...
>developed or updated to modern MacOS, please send me an email.
How many CTO's of science or engineering tools
do you think follow this group? I wonder hoow many 1MLOC+ projects
are ported in this way? Please let us know if you get any bites.
B.
Bernie Wieser
Thomas L. Ferrell wrote in message <365DD495...@tds.net>...
My pessimism comes from negative experience. I think the only way
to get vencap for these kinds of business is to start a group specific
to this end. But... such groups in the past have failed and all money
managers I know look for big returns (justifies 10 failures and one stunning
success.)
I should apologize (in particular to Gustafson) for my sarcasm -
if anyone offers him work - kudos to him - but the several "porting"
companies I know work very, very hard to get contracts, and
fight the uphill battle (in particular against bandwagon and faith
mentalities). Hard to prove the business case. And I also know
of two companies that specifically ported that failed (basically,
it has to be something for nothing and business doesn't work
that way.)
So... it would be nice to get a grant - but no agency in my
country would fund such work - let alone assist any software
start-up - I know 'cause I've tried. "We only give loans/credits
to companies that have a ripple effect on the economy, and
software is not tangible [If you fail, we have nothing to
recover.] Thanks - good luck."
I guess there needs to be a pessimist [realist?] in every group
Thomas L. Ferrell
Bernie Wieser wrote:
Bernie,
We don't mind the pessimist! But actually, at least 3 different agencies have
funded scitech apps for the Mac very recently. DARPA, NIH (where you can find
the magnificent freeware app NIH Image), and DOE are the cases I know of
personally.
Dr. Ian R. Ollmann
On 16 Nov 1998, Vladimir Avdonin wrote:
> Not at all in mac case. It is an interface that save time and efforts. I
> am developing an electrophysiology program which is along the lines of
> wide spread commercial program, the ported one. Currently my program is
> inferior functionally in most case, but more consistent mac approach have
> higher value both for me and for number of other people using it.
>
> In general I believe it is better to loose 1 hr once a month to work
> around missing function then loose 5 min every hour to strugle with clunky
> interface. Also bad interface is a source of regular confusions that not
> only waist the time but may cause data damage.
>
> oops, looks like i am off subject, sorry
Ahh, but it is a good subject! I ran into the same problem. I found that
most of the plotting/graphing programs such as Kaleidagraph or
CricketGraph had very cumbersome interfaces, that in most cases increased
the amount of effort to do common tasks by many fold. (Let us not talk
about Excel!) So, I started writing my own program for which I've worked
hard to keep the interface out of the way. At this point, in many cases,
the feature set of my own program actually exceeds those of CricketGraph
and the fitting capabilities are better than and faster than those of
Kaleidagraph. I'm planning on looking for people here for beta testing
soon, after I finish with the core feature set and work out the bugs that
I know about. (The big missing elements at the moment are the ability to
save your work and an undo/redo function. These two concepts share a lot
of code.) The beta test may occur in the Spring some time. It is looking
like the program will require PowerPC and MacOS 7.5 or higher, but these
are just guesses.
Ian Ollmann
Dr. Ian R. Ollmann
On Fri, 13 Nov 1998, Roberto Celi wrote:
> I think this is a very good point. I don't know if this is what John
> meant but: I think that there are two potential groups of developers for
> Mac sci-tech software, those who do the "kernels" and those who do the
> GUIs. I would belong to the first category. To generate my research
> results I write software that is quite sophisticated and
> state-of-the-art for my field; portions of it may be of some interest
> outside my field too. But the GUI is miserable to nonexistent (these
> are mostly Fortran programs with text files for I/O), and although I
> know the very basics of Mac GUI programming, I wouldn't have the time to
> do anywhere near a professional job. I suppose that the opposite
> argument may hold for many people who can do good Mac programming: the
> GUIs would be professionally done, the kernels may not.
It's more than a culture barrier or mindset barrier. There is also a
language barrier. Most MacOS GUI programming is done in C/C++ these days,
and it seems that (apparently for reasons of readibility ;-) scientific
kernel code is written in Fortran. I've been staring at some really lovely
minimization/optimization code from the Math Sci world for weeks now
(NL2SN1 & NL2SOL are two examples). The code is in FORTRAN. I really think
that even though such routines are robust and decades ahead of stuff like
that in Numerical Recipes in C, routines like those from the latter source
are going to be what end up in most scientific apps with a advanced GUI's.
The reason is that Fortran code is extremely difficult to decipher
compared to (well written) C and doesn't link well with C under current
predominant MacOS programming environments. I find it amazing that many
many research labs are doing top notch work, but doing it in a language
which no one uses any more. It's like having mass in Latin -- the people
who can benefit most from your ideas, in general, dont have a clue how to
speak the arcane language in which you chose to communicate them.
Of course, there are some solutions like MacF2C, but they dont always work
and they do always involve the inclusion of some rather large software
libraries into your code.
Ian Ollmann
FRID...@psfc.mit.edu
<snip>
->I agree that I wouldn't want Apple to do anything about it, but I certainly
->can. I don't think Apple has the time or money to worry about any vertical
->market, they should be more concerned about getting their lost customers
->back and building up their new customer base. So, what I was saying was that
->my company can get into any vertical market I want, and this sounds like
->a good one. Since there are many Macs out in the engineering and science
->field, and I have a science background, sounds like I can have some fun doing
->what I like, writting software. And if this just happens to be in a field
->that I know a little about, then all the better.
->
->So, I will renew my statement that if anyone needs a software product
->developed or updated to modern MacOS, please send me an email.
->
->Later,
->scott
->--
Just an observation - I had ported some of Berkeley EE software to Mac, as
well as written my own original EE software. I don't know how many people
actually using it, but I know that I did not get a SINGLE piece of e-mail
about any of it. No questions, no sugestions, no bug reports. Nada. Zero.
Either nobody interested in it, or nobody have any questions about it, which
is very unlikely. I had more e-mail about my port of x-tide, for god
sake! BTW, everything was free with a source code enclosed. Maybe some other
disciplines, but electronic engineering on Mac is dead (IMHO). Anyway, I ain't
spending my time end effort on something that nobody gives a damn about.
I wish you luck, but unless Apple really do something about it, I don't believe
it'll get you anywhere.
Just my 0.02
Mike.
Roberto Celi
>
> On Fri, 13 Nov 1998, Roberto Celi wrote:
>
> > I think this is a very good point. I don't know if this is what John
> > meant but: I think that there are two potential groups of developers for
> > Mac sci-tech software, those who do the "kernels" and those who do the
> > GUIs. I would belong to the first category. To generate my research
> > results I write software that is quite sophisticated and
> > state-of-the-art for my field; portions of it may be of some interest
> > outside my field too. But the GUI is miserable to nonexistent (these
> > are mostly Fortran programs with text files for I/O), and although I
> > know the very basics of Mac GUI programming, I wouldn't have the time to
> > do anywhere near a professional job. I suppose that the opposite
> > argument may hold for many people who can do good Mac programming: the
> > GUIs would be professionally done, the kernels may not.
>
> It's more than a culture barrier or mindset barrier. There is also a
> language barrier. Most MacOS GUI programming is done in C/C++ these days,
> and it seems that (apparently for reasons of readibility ;-) scientific
> kernel code is written in Fortran. I've been staring at some really lovely
> minimization/optimization code from the Math Sci world for weeks now
> (NL2SN1 & NL2SOL are two examples). The code is in FORTRAN. I really think
> that even though such routines are robust and decades ahead of stuff like
> that in Numerical Recipes in C, routines like those from the latter source
> are going to be what end up in most scientific apps with a advanced GUI's.
Still, the issue of bringing the two communities together remains,
regardless of whether it's culture, mindset, or language. It may very
well be that the professional sci-tech market is too small for Apple to
care and for developers to make sufficient money from (although I am not
too sure--I know of too many Mac "pockets" of happy and productive
scientists and engineers). But I look at things from the perspective of
higher education, and that *is* a strategic market for Apple. The right
VP is probably not Developer Relations but Education (hopefully I'll let
you know soon), and the place to put the sci-tech evangelist that I have
been advocating as the person to coordinate the two communities is
Education too. Perhaps a copy of the petition should also go to the
higher ed people at Apple.
> The reason is that Fortran code is extremely difficult to decipher
> compared to (well written) C and doesn't link well with C under current
> predominant MacOS programming environments. I find it amazing that many
> many research labs are doing top notch work, but doing it in a language
> which no one uses any more. It's like having mass in Latin -- the people
> who can benefit most from your ideas, in general, dont have a clue how to
> speak the arcane language in which you chose to communicate them.
>
At the risk of starting the usual religious war, I strongly disagree
with you. First on the decipherability of Fortran vs. C and (worse)
C++. Either can be extremely readable or extremely unreadable. My
colleagues and I deal with students who often are at their first big
programming project. We can always make some sense of Fortran code
(F77, for F90 I may not be so sure). On the other hand, a few years ago
we had to throw away a big (alas, working) C code because the student
threw a fit and disappeared, and nobody could make sense of what he
did. And yesterday a student in a course I'm teaching came to me all
excited because (can you really do that?!) he had redefined the "+" as a
new class in C++ with different meaning from the regular "+". It sounds
like something from a Clinton testimony: it depends on what you mean by
"+"!
I also disagree on the fact that no one uses Fortran any more. We
certainly do very extensively in our department (Aerospace Engineering)
for non-GUI coding, and it's an integral part of our instructional
curriculum. And the people who can benefit most from our ideas (and,
BTW, who pay our bills through research grants) use it too, are
perfectly happy to receive Fortran code, and haven't asked that we move
to any other language.
> Of course, there are some solutions like MacF2C, but they dont always work
> and they do always involve the inclusion of some rather large software
> libraries into your code.
>
> Ian Ollmann
Roberto
Wood Lotz
>
> It's more than a culture barrier or mindset barrier. There is also a
> language barrier. Most MacOS GUI programming is done in C/C++ these days,
> and it seems that (apparently for reasons of readibility ;-) scientific
> kernel code is written in Fortran. I've been staring at some really lovely
> minimization/optimization code from the Math Sci world for weeks now
> (NL2SN1 & NL2SOL are two examples). The code is in FORTRAN. I really think
> that even though such routines are robust and decades ahead of stuff like
> that in Numerical Recipes in C, routines like those from the latter source
> are going to be what end up in most scientific apps with a advanced GUI's.
> compared to (well written) C and doesn't link well with C under current
> predominant MacOS programming environments.
I disagree, Fortran code is not necessarily difficult to decipher and
Fortran does link well with C under current predominant MacOS
programming environments: CodeWarrior where Absoft Fortran is link and
debug compatible; and MPW C, where Absoft Fortran is link and debug
compatible. Absoft also provides a C/C++ compiler as a component of Pro
Fortran which is link and debug compatible with Absoft Fortran
compilers. Further, many users use CW to build GUIs to run their Absoft
Fortran programs.
> I find it amazing that many
> many research labs are doing top notch work, but doing it in a language
> which no one uses any more.
I disagree again. Commercial developers may be predominately C users,
but labs and many Fortune 2000 are actively doing Fortran work - both
porting legacy code to the desktop and new development. Typically these
are special purpose in-house apps.
--
Wood Lotz
Absoft Corporation
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Complete F90/F77/C/C++ toolsets for Windows95/98/NT, Mac and Linux
Absoft Corporation, 2781 Bond Street, Rochester Hills, MI 48309 USA
Voice (248) 853 0050 EST - Fax (248) 853 0108 - http://www.absoft.com
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
David Blanchard,,,
Dr. Ian R. Ollmann <ia...@cco.caltech.edu> wrote:
>I find it amazing that many many research labs are doing top notch work,
>but doing it in a language which no one uses any more.
Interesting contradiction! "Many, many research labs" but "no one uses" it
all in the same sentence. It may not be the dominant language in todays
market, but Fortran has a strong presence. Some of the first people to use
computers were scientists and engineers and Fortran was the language of
choice because it is designed for that type of problem (i.e., FORTRAN =
"FORmula TRANslation"). There are millions (billions?) of lines of code in
the science/engineering community and it makes tremendous ecomomic sense to
maintain that code in the language in which it was written. One can always
argue that any newly developed code should use another language (C/C++,
Objective-C), but if the core of the program is simply number crunching,
Fortran is still the best choice.
Fortran is not a cutting edge language. It requires stability and
compatibility so that upgrades in features and compilers do not break
existing code. On the other hand, updates to Fortran (from F77 to F90 and
even the objective Fortran I hear about) will take features which work
well in the modern languages and integrate it into Fortran. F90 has
dynamic memory allocation, pointers, and other features borrowed from C.
Fortran is not a dead language; it is evolving but it does not attempt to
be cutting edge.
-db-
[Fortran is to Macintosh in the same way C/C++ is to Windows; just because
most people are using it doesn't mean its the right choice for everyone.]
--
+----------------------------------------------------------------------+
| David Blanchard NOAA/NSSL & OU/CIMMS Boulder, Colorado |
| bla...@ucar.edu http://mrd3.nssl.ucar.edu/~dob/www/ |
+----------------------------------------------------------------------+
Dr. Ian R. Ollmann
On Mon, 30 Nov 1998, Roberto Celi wrote:
> On Fri, 13 Nov 1998, Roberto Celi wrote:
> At the risk of starting the usual religious war, I strongly disagree
> with you. First on the decipherability of Fortran vs. C and (worse)
> C++. Either can be extremely readable or extremely unreadable. My
> colleagues and I deal with students who often are at their first big
> programming project. We can always make some sense of Fortran code
> (F77, for F90 I may not be so sure). On the other hand, a few years ago
> we had to throw away a big (alas, working) C code because the student
> threw a fit and disappeared, and nobody could make sense of what he
> did. And yesterday a student in a course I'm teaching came to me all
> excited because (can you really do that?!) he had redefined the "+" as a
> new class in C++ with different meaning from the regular "+". It sounds
> like something from a Clinton testimony: it depends on what you mean by
> "+"!
OK, so as to avoid the religious crusades, I will concede that if
"properly written" Fortran can be decipherable. I might contend that any
use of the goto statement pushes the code hard in the "improperly written"
direction, but Fortran can be decipherable. In addition, any language if
improperly written can be indecipherable. I probably spoke too hastily. I
was really complaining about improperly written software. Almost all of
the Fortran that I read (invariably someone else's) seems "improperly
written" compared to the majority of the C/C++ code that I read (my own).
:-) So there may indeed be plenty of real world examples of properly
written Fortran, and improperly written C. I would submit the entire
contents of "Numerical Recipes in C" as examples of hard to decipher or
improperly written C, something that I had previously felt was due to
their Fortran heritage. However, for the sake of reaching some sort of
agreement, I will concede that the original language itself may not have
been the problem.
#define NEW_CRUSADE Long_Variable_Names
What I really want to see is long variable names and long function names,
names which make sense in English. I had previously perceived that it was
part of the Fortran tradition, if not the language per se, to use highly
abbreviated subroutine names and single or double character variables. I
find it astounding that highly visible source code such as the book
mentioned above, its Fortran equivalent and the various public code
repositories on the net, seem littered with variables called "uu", "vv",
and "xx". If they really are temporary two dimensional matrices with only
function local scope, then why not call them d_temp_2D_matrix1 and
f_temp_2D_matrix2. (You can leave out the 2D if it is obvious from context
that that is what it is.) At least then we would know that they are, and
not have to wonder what precisely uu is without constant referral to the
declarations area or searching the comments hidden somewhere else. However
if they are something important like a covariance matrix, then call them
that! Ok, so you don't like typing. However, if you plan to publish in a
public place, supposedly to elevate mankind another notch with a useful
software tool then I find it very difficult to understand why you dont use
a Find/Replace tool to go back and convert the "uu"'s into
"a_long_and_descriptive_variable_name". It is not like longer names slow
down execution times and very few people still work on CRT's with 40
characters per line.
As for your criticism of operator overloading, I would suggest that your
student did not write proper C++. The function of an overloaded operator
should *always* be analogous to that of the normal operator. So if a + b
does not return a third object which is the logical sum of a and b, then
that is very much like writing code like this in any language:
void ShowErrorMessage( const char *errorMessage )
{
EraseHardDrive();
}
Based on the name ShowErrorMessage, people will be tempted to call it when
an error condition happens. Wont they be surprised when the hard drive is
erased as a result! In C++ you can write new data types and in many ways
write the language itself as you go. It is very powerful. However, as
always, with power comes responsibility. If you start redefining the
language in strange and inconsistent ways, then you get what you would
expect - Obfuscated code. I hope for his or her sake you drilled that
lesson into the student's head after he did it.
Ian Ollmann
Peter Kelm
I am doing mechanical engineering software development for about six years
now. In this time I have heard of very few company that were doing active
FORTRAN development. Our own companys large-scale client-server analysis
programs have been transferred to C++. Every university lab I have seen has
switched (at least) to C instead FORTRAN. I have started programming using
FORTRAN around a decade ago myself. But I would not like to miss all the
"modern" features of programming languages like C++.
IMHO it is true that there still is a wealth of FORTRAN code. But new code is
definately done in C/C++. Recent C++ compilers do not suffer from runtime
speed drawbacks (according to my own experiences or Dr. Dobbs Journal, ...)
compared to FORTRAN. We still have to use some dated FORTRAN parts in our
in-house programs but these get replaced by C++ versions one after another.
Linking these against C/C++ code is no problem at all. From my point of view
there is only limited future in FORTRAN code.
And if you think of GUI code (which is an issue even for hard-core number
crunchers)
I cannot imagine that one would go the FORTRAN way (instead of Tcl/Tk UIs,
MacApp,
PowerPlant, MFC, ViewKit, ...).
> [Fortran is to Macintosh in the same way C/C++ is to Windows; just because
> most people are using it doesn't mean its the right choice for everyone.]
I strongly disagree. I would be very concerned if this would prove to be true.
I agree to making the programming language choice dependent on other factors
(maintainability, exception handling, peoples skills, just to name a few) than
"C/C++ is better than FORTRAN. Period.". But every new code that I write would
be C/C++ rather than FORTRAN (sorry to ABSOFT, Fortner).
Peter
----------------------------------------------------------------------
--- beam me up scotty, this planet sucks ---
Plan B
Peter Kelm
Lukas Latz
> now. In this time I have heard of very few company that were doing active
> FORTRAN development. Our own companys large-scale client-server analysis
> programs have been transferred to C++. Every university lab I have seen has
> switched (at least) to C instead FORTRAN. I have started programming using
> FORTRAN around a decade ago myself. But I would not like to miss all the
> "modern" features of programming languages like C++.
>
> IMHO it is true that there still is a wealth of FORTRAN code. But new code is
> definately done in C/C++. Recent C++ compilers do not suffer from runtime
> speed drawbacks (according to my own experiences or Dr. Dobbs Journal, ...)
> compared to FORTRAN. We still have to use some dated FORTRAN parts in our
> in-house programs but these get replaced by C++ versions one after another.
> Linking these against C/C++ code is no problem at all. From my point of view
> there is only limited future in FORTRAN code.
>
i hear fortran is still very strong in aerospace (cfd..). would mean that new
codes be written in fortran still..
anyone know if this is still true and/or changing?
lukas
Roberto Celi
>
> > I am doing mechanical engineering software development for about six years
> > now. In this time I have heard of very few company that were doing active
> > FORTRAN development. Our own companys large-scale client-server analysis
> > programs have been transferred to C++. Every university lab I have seen has
> > switched (at least) to C instead FORTRAN. I have started programming using
> > FORTRAN around a decade ago myself. But I would not like to miss all the
> > "modern" features of programming languages like C++.
> >
>
> i hear fortran is still very strong in aerospace (cfd..). would mean that new
> codes be written in fortran still..
> anyone know if this is still true and/or changing?
> lukas
As I mentioned in a previous posting in this thread, Fortran is still
very widely used in the subset of aerospace engineering that I deal
with, and is still very much the language of choice for number crunching
applications.
I would like to add that I (and most of my colleagues here) am not
married to Fortran, and I am ready to switch to any programming language
or package that will reduce the development time for the codes that my
students and I develop. So far however we haven't seen any reason to
move away from Fortran.
Tracking my own programming errors in F77 I have noticed that most come
from setting work areas, splitting them up through pointers, and passing
them to subroutines. The next biggest source is very similar: the
configuration data for the systems I work with are contained in tens of
fairly short vectors, that I pack into bigger ones with pointers, send
downstream to the subroutines that need them, and unpack them just
before they need to be used. So I needed dynamic dimensioning for the
work areas and structures for the input data. LS Fortran had
structures, but implemented as extensions to the language, so I didn't
want to use them. Now however I am going to switch to Absoft F90 and
get both dynamic dimensioning and structures.
The bottom line is that I am not going to change programming language
just to make my codes buzzword-compliant, or to be able to claim that I
use the sexy language "du jour". On the other hand, if there is a
so-called "modern" feature that I can't effectively reproduce in Fortran
and that will demonstrably save me time and effort in the long run I'll
switch in a second.
Roberto
-----------------------------------------------------------------------
Dr. Roberto Celi phone: (301)
405-1132
Department of Aerospace Engineering FAX: (301)
314-9001
University of Maryland, College Park, MD 20742
http://aerospace.umd.edu/Sections/Faculty/celi.html
-----------------------------------------------------------------------
Richard Ciervo
Just out of curiosity, what progs did you port, and where are they? I am an
EE who uses a Mac (one of a really teeny group), mostly at home, and I'm
always looking for Mac engineering SW for my "arsenal"...
-Rick
----------
In article <30NOV98....@radio.psfc.mit.edu>, FRID...@PSFC.MIT.EDU
wrote:
Peter Kelm
> i hear fortran is still very strong in aerospace (cfd..). would mean that new
> codes be written in fortran still..
> anyone know if this is still true and/or changing?
> lukas
Yup, AFAIK this is true.
Having a talk with our CFD specialist some days ago he mentioned
that even in this area times are changing. He told me that CFX for example
(the CFD software we use in our company) is working on a C++ solver
that should replace the current FORTRAN one within a few years.
But until now there are some features missing in the new solver that hinders
us from switching to the new one. What especially are you interested in?
Anthony Wilson
I would also like to know what programs you ported and wrote yourself, I
would like to check them out. In checking the web, I have not found much
for scientific freeware for EEs. Therefore, i decided to contribute some of
my time to developing some software for the Macintosh.
My only successful compile job( so far) has been updating MacSpice3f4 -->
http://home.earthlink.net/~wilsona/macspice.html. This was a port of
Berkeley's Spice 3f4 originally done by Reto Tishhauser. I just finished
adding the most recent BSIM3(from Berkeley) and HFET(heterostructure FET)
models to the port and released it with Reto's blessing. I'll continue to
update with new models as i find them and bug reports as i get them.
I have also started on continuing the port Scilab for the Macintosh. This
was orginally done by Francis Courtois. He finished the port of Scilab 2.1,
but had to stop the development b/c of other projects. So I have decided to
continue that work by porting Scilab 2.4.
In searching the web, I also had the fortune of coming across Electric -->
http://www.electriceditor.com . It is a layout/schematic capture tool that
is in platform independent source code. I got it to compile using CW Pro 3.
It was the missing link in doing some circuit design work on my Mac.
Although not used for my final designs, it is a good way to do schematics,
produce netlist automatically, performing layout, and doing stuff at home.
BTW, I do give a damn. I think there is potential for the macintosh as a
scientific machine. Even using the free stuff ported to the Macintosh such
as gnuplot(http://www.ee.gatech.edu/users/schooley/gnuplot.html),
MacSpice3f4, Mupad( http://www.mupad.de), and MacScilab.
Therefore, i do plan to continue my software development, even for my own
use. anyone that is willing to help with the software development, feel
free to contact me directly.
-anthony
http://home.earthlink.net/~wilsona
Please use the following for email
wil...@earthlink.net
In article <747g56$9ge$3...@holly.prod.itd.earthlink.net> , "Richard Ciervo"
<rickc...@earthlink.net> wrote:
>Hi Mike,
>
>Just out of curiosity, what progs did you port, and where are they? I am an
>EE who uses a Mac (one of a really teeny group), mostly at home, and I'm
>always looking for Mac engineering SW for my "arsenal"...
>
>-Rick
>----------
>In article <30NOV98....@radio.psfc.mit.edu>, FRID...@PSFC.MIT.EDU
>wrote:
>
>
>
flavioh...@gmail.com
> Okay, as a cross platform software developer, I need to throw in my .02.
> This is a bit of a long ramble, sapientia is appreciated.
>
> First, my shameless plug. OMDI produces math and imaging add-ins
> for Excel. (http://www.octavian.com/excel.html).
>
> Personally, I think it would not be so bad if certain players left the MacOS
> market, because
> there are numerous "small" players that then have an opportunity to
> grow into the empty space (some even have better products, but
> unfortunately most have little if any exposure. I'll leave comments
> about Apple's failure to promote these markets for a different
> rant.) Unfortunately, lack-of-tools from perceived "big" players is often
> a convenient, and somewhat incorrect, rationalization for companies
> to not get into or not support a platform. What can you do about it?
> (Answer later.)
>
> Previously, I worked for a company involved in simulation.
> Most of my income comes from consulting to sci-tech companies. I've had
> contact with a lot of engineering and sci-tech companies. You must
> understand the reasons for "big" players leaving the market. I'm
> going to rank these from most important to least important.
>
> 1) political and or religious bias in upper management
> It does not matter if it is Mac or any Unix flavor. Many individuals with
> control over purse strings and with the power to make irrational
> sweeping decisions have not, and do not use any platform other
> than Windows. The historical reasons on this topic are too big
> to get into. What matters is that these individuals feel good
> being on the bandwagon - and like the Pope is a little bit
> closer to [the christian] God - by blindly supporting the "Microsoft
> platform" these individuals are a bit closer to Bill. You have no
> better chance of converting them than you do of the deeply
> religious, as the strongest ties to their decisions are not supported
> by physical, factual rationale.
>
> In three companies now, I have been witness to the following
> directive: "You can pick from any Microsoft platform or technology
> to implement a solution."
>
> 2) political and or religious bias in IS and IT
> Although the reality is we live in a multi-vendor, multi-platform world,
> there is a common misconception that costs can be reduced by
> picking the homogeneous platform. Many of us know that the
> best, most innovative, most elegant solutions never get the
> exposure they deserve. Its all about promotion and mind-share.
> Its also about fear of the unknown. Many IS/IT departments
> push what they know. They don't know MacOS. And, as
> one IS fellow that works with my wife pointed out -
> "If we supported MacOS, there wouldn't be anything for me
> to do, so I'd be out of a job."
>
> So for IS, it is more than religious, it is a motivation based
> on some fear, that lets them actively work against the
> multi-platform solution, and 1) many IS/IT departments
> make the purchasing, 2) many IS/IT report directly to
> upper management.
>
> 3) market share
> Most companies try target the audience based on market share.
> It makes sense. If you know that 70% of your market uses
> Windows (in one form or another), 25% uses a Unix flavor,
> and 5% uses "other", then your priorities are pretty clear.
>
> 4) availability of resources
> My above numbers are more typical to engineering than
> the consumer space. But most resources for development
> can be thought of as fitting the consumer space.
> Good resources are hard to find - especially with platform
> expertise - more so with multi-platform expertise.
> In general, you'll find development managers fitting into
> the clique of "no clue" re multi-platform development,
> with the same biases as others.
>
> 5) distribution of resources and work process
> Many companies that develop sci-tech software are
> not founded on solid software engineering principals.
> So you have the usual glut of "pile people on the problem."
> Of course, the problem is prioritized for the target audience.
> This means many companies have 40 people working on
> the Windows version, and maybe 2 or 3 working on "ports".
> Ports are always behind - you just can't match productivity
> on this scale... and unrealistic work process will mean that
> 40 people might be making platform-specific short-cuts
> to get the product out on time. They will use platform-specific
> tools and frameworks. The real issue of multi-platform
> support can often be solved in process - not technology -
> but try selling "software engineer" or applied software
> management to companies that have no knowledge
> of what is involved. You always get buy-in for process improvement -
> with the next day question "Have you started coding yet?"
>
> Anyway - you cannot fight this battle by petitioning. The decision
> makers "feel negative" because you are trying to enforce what
> really is a contradictory belief - no matter what the rationalization.
> And, these people are surrounded by individuals that share the
> belief and support the decisions.
>
> Speaking with dollars is also hard. Sales figures are often
> not compared to relative market size. I know of several products
> that would/were profitable on MacOS but the decision
> was made "to focus on the primary market." Go for the
> 80% cash cow.
>
> market is to support companies that have MacOS offerings
> and publically stated "open" strategy. You might not be able
> to get the "best" tool, or the "defacto/du jour" tool, but you
> will promote the vendors to grow in these directions by
> supporting them. You can probably get the 90% of the
> function you need through multiple vendors. Think of it this
> way - you probably only use 30% of the functionality in
> any large, monolithic, do-it-all type package.
>
> And as the smaller vendors are usually cash strapped
> and cannot market themselves effectively (seriously,
> my advertising dollars are very limited, and I have
> a mostly vertical product that I could advertise in
> nearly 100 technical journals, where EACH one would
> only hit the tiniest portion of my potiential market -
> at $2K per ad with potential revenue of $.2K, it
> just doesn't make sense to market through traditional
> channels). Spread the word. Get the site license. Publish
> a paper. Link to their web pages.
>
> You should also politely, non-intrusively educate your
> employer. "I want to use the best tools that I am
> most familiar with to get my max productivity without
> artificial constraints." Show them. And if they tell you
> what brand hammer to use to fasten that screw -
> find a more enlightened employer. (Easier said
> than done right?)
>
> Bernie Wieser, OMDI
>
> p.s. previous rants include
> - why I can't get capital to do Mac projects
> - why Apple shot itself in the sci-tech market
> - why making everything part of the "OS" is great
> for open systems, and why open systems are
> terrible for business (the freeware principle)
>
>
> MattSPete wrote in message <19981101232314...@ng69.aol.com>...
> > I am writing in regards to a petition for scientific software on the
> MacOS.
> >The petition is in response to the recent demise of many major scientific
> >software packages for the Macintosh (MatLab, SPSS, SysStat, & Statistica).
> >Without these applications, there will be little incentive for many
> >universities to continue to purchase Macintoshes. The goal of the petition
> to
> >convince Apple that the fate of the MacOS in higher education hinges on the
> >availability of these products. Apple needs to convince these software
> >publishers to reenter the market, and should support their efforts as much
> as
> >possible.
> >
> >
> >The petition is available at:
> >
> >
> > members.aol.com/mattspete
> >
> >
> > Feel free to distribute news of the petition to other mailing lists,
> >newsgroups, colleagues, or potentially interested parties. After all, we
> need
> >all the support we can get!!!
> >
> >
> >Fight back for the Mac!
> >-Matt
> >
> >----------------------------------------------------------------
> >Matt Peterson, Ph.D. Ph: (217) 244-4467
> >Beckman Institute
> >Univerisity of Illinois email: mpet...@faroe.vp.uiuc.edu
> >405 North Mathews Avenue
> >Urbana, IL 61801
> >
> >www.beckman.uiuc.edu
> >----------------------------------------------------------------
> >
Hi, Please a copy of omdi Image addin for Excel Microsoft