computer languages
MURPHY KEVIN
Canada (particularly ontario). This is an extremely general question, but i
am very curious. At school we mostly play with fortran 77.
murf...
geo...@csc.canterbury.ac.nz
are in related areas so I look in here once in a while), I worked for
a few years as a computer programmer/analyst. And for the last seven
years, I have NOT taught any programming in my courses. Since most
data sets are amenable to analysis using the many existing programmes
out there, it is a skill best left to computer programmers. I suspect
that most applications in civ eng are covered by programmes that are
available commercially.
Just my POV.
MURPHY KEVIN
>From: geo...@csc.canterbury.ac.nz
>Subject: Re: computer languages
>Date: Tue, 23 Nov 1993 03:02:22 GMT
MURPHY KEVIN
Mark S Wright-1
My experience is that this isn't necessarily true. Organizations
often have need for programs specific to their needs, which either aren't
met by existing programs, are awkwardly met by existing programs or are
only met by using macro-like programs (which, contrary to the opinions of
most REAL programmers, are really programming). Maybe it's
because I work for a very large organization (the MN Dept of Trans), but
my skills are certainly in great demand around here.
The question of who should be programming is an interesting one.
Should you take an existing Civ Engineer and give him/her some programming
training, or take a programmer and try to explain to him what you want.
Around here, the first option gets you unstable programs with such ugly
code that they are impossible to maintain - but they do what people want,
the way they want it done. The
second gets you nice, pretty programs that never quite do what you want.
What sort of experience have others had?
To answer the original question, learn fortran 77 - because thats
probably what most of the existing code will be in. But NEVER do any
additional development in it. Find a nice structured programming language
like Pascal or C to do future programming in - it will encourage you to
avoid the sort of bad code the F77 tends to bring out in people. Just my
two cents.
--
Mark Wright wrig...@gold.tc.umn.edu
--------------------------------------
I don't want to achieve immortality through my work, I want to achieve
immortality through not dying. - Woody Allen
Roger Hadgraft, Civil staff, ext 4983
> To answer the original question, learn fortran 77 - because thats
>probably what most of the existing code will be in. But NEVER do any
>additional development in it. Find a nice structured programming language
>like Pascal or C to do future programming in - it will encourage you to
>avoid the sort of bad code the F77 tends to bring out in people. Just my
>two cents.
I think this is a little out of date. Have a look at Fortran 90. It has all
the nice structuring facilities (both code and data) of Pascal and C. It isn't
OO yet, but that's coming.
What about mixed tool programming? For example, converting existing Fortran
programs to Windows (eg) can be done by compiling the old code as dynamic link
libraries and building the user interface with something like Visual Basic
(or Toolbook or KnowledgePro etc).
Roger
--
Roger Hadgraft, Senior Lecturer in Civil Engineering
Monash University, Clayton, Victoria, AUSTRALIA, 3168.
phone: 03 565 4983 fax: 03 565 4944 or 3409 intnl: +61 3 565 ....
e-mail: roger.h...@eng.monash.edu.au
M21...@mwvm.mitre.org
help wanted ads, the majority of science/engineering software in use is
FORTRAN. My guess would be 70-80% of all existing software and a higher
percentage of mature software (where mature means does useful things,
documentation matches calculations, and doesn't crash often). The figure
for software currently under development from scratch would probably favor
C/C++, but speaking as a software developer for 10 years, most of these
development efforts will die a deserved death as hobby shop software
(he says, donning his flame resistant suit). To be fair, many development
efforts in any language have met a similar fate.
You may want to post this question to one of the computer science newsgroup
and compare the answers from academia and industry.
Dwight Shank
dsh...@mitre.org
Michael Feist
>
> I think this is a little out of date. Have a look at Fortran 90. It has all
> the nice structuring facilities (both code and data) of Pascal and C. It isn't
> OO yet, but that's coming.
But look in the history. Fortran 90 needed 13 years to come up.
If I think, 1990 + 13 = 2003. Thats too late for coming up with OO.
C++ is running away in the meanwhile..
--
\\|// \\|// -------------------------------
(o^o) (o^o) | |
------ooO-(_)-Ooo-----ooO-(_)-Oo------------ Michael Feist |
| Universitaet Hannover |
|Institut fuer Stroemungsmechanik und Elektronisches Rechnen im Bauwesen |
| fe...@erib.uni-hannover.d400.de |
--------------------------------------------------------------------------
Wilfrid Austin Nixon
of a semester teaching a course called Computers in Civil Engineering.
The course attempts to expose students to the programs and skills they
will need as practicing engineers, and give them the insights needed to
live and work with computers.
This was my first semester teaching the course, and I gave it my own flavors
and biases. We began with Microsoft Word, covering things like outlining,
style sheets, equations, tables and the like. The aim here was to ensure
that students had good communication skills available - if you can't
communicate your ideas (especially to some dumb MBA who might be your boss
and is techno-phobic) it doesn't matter how good they are!
From Word, we moved on to Excel (we weren't using Microsoft products deliberately
- they are just what we have on our network here). I think that engineers
will be doing most of their "quick and dirty" programming in Excel, not
Fortran, C, Pascal or any "traditional" computer language. After Excel,
we have taken side trips through Mathcad, Fortran (because, whether we like
it or not, it is the language used by most civil engineering programs), and
Matlab.
To string the course together, we have looked at a paradigm problem - analysing
some of my datasets from the lab using a three paraemter Weibull analysis. This
requires the solution of three very non linear simultaeneous equations - an
excellent test of programming. The students have had to be very creative, and
have come up with some good solutions. They have also had to face some
interesting dillemas - If method A gives this solution, and Method B gives that
one - which is correct? A great challenge for students raised on book problems
with one correct solution.
All in all I've had great fun with this course. But to return to the thread, I
don't think we should teach students any one language in particular. Yes, they
probably need exposure to Fortran, but they will probably do most of their own
analysis using spreadsheets or programs like Mathcad. The times they have a
changed already, and if we insist on cramming too much programming down their
throats, well we just missed them as they changed!
By the way, the biggest challenge I have had with this course is to convince the
students that before they analyse anything with a computer, they should have a
rough idea of what the solution is - otherwise, how will they know if they coded
the problem correctly? If anyone has any solutions to that problem, I'd love to
know.
Wilf Nixon
Associate Professor
Dept. of Civil and Environmental Engineering
University of Iowa
John Lu
As a engineering application programmer, understanding FORTRAN is a must,
since the past engineering application codes are written predominantly in FORTRAN.
C is used a lot for system programming. C++ is gaining firm ground in
software industry.
Simply learning the syntax of a language is trivil. To understand
the essence of programming languages, one should familirize himself to
different programming paradigms (imperative, functional, logic, OO, ...)
It is extremely helpful to write a _nontrivial_ program using a lanaguages
typfying each paradigm. You will be amazed how fast you can adapt to and
_master_ a different lanague if you know the fundmental concepts/constructs
of programming lanaguages in general.
A software developer/programmer is not an application end user. I rarely consider
Word/Excel/Mathcad/Autocad users as a software developer. A person knows nothing
but FORTRAN is not a good programmer.
To really answer your question well is difficult.
I rarely jump into this kind of discussions, because
it is often quite fruitless and may well trigger a religious war.
I suggest that you talk to a professor/friend in CS programming lanaguage area
and ask for their opinions.
Flames > /dev/null.
--
-- John Lu
l...@ecn.purdue.edu
geo...@csc.canterbury.ac.nz
programmer/analyst. Because of my science background, I could talk to the
scientists and engineers and get them what they wanted, and the programmes
I wrote were structured and heavily internally documented (in Fortran 77
BTW). However, in many areas, there are systems that allow for the easier
development of applications - that may well be programming but it's a damn
sight easier and more transparent than the stuff I used to do. Hell, an
FFT call in MATLAB is one line! But I take your point - I may not call it
"programming", but it could still, strictly speaking, be called that.
Oh, and BTW, almost everyone I know in geophysics and groundwater work
who are writing programmes are using something like QuickBASIC or some
C variant, and many systems, like MATLAB etc., allow for the integration
of C routines with the built-in functions. But the development tools
available now make it unlike any of the programming I used to do :-)
Regards,
David Nobes
Department of Geology, University of Canterbury, Christchurch, NZ
geo...@csc.canterbury.ac.nz
(Wilfrid Austin Nixon) writes:
>
> By the way, the biggest challenge I have had with this course is to convince
> have a rough idea of what the solution is - otherwise, how will they know if
> they coded the problem correctly? If anyone has any solutions to that
> problem, I'd love to know.
>
> Wilf Nixon
> Associate Professor
> Dept. of Civil and Environmental Engineering
> University of Iowa
It's a toughy alright! In geophysics, it's even harder - we don't
usually "know" the right answer ahead of time. Instead we have to look for
"robust" methods and use multiple methods. But there is also no subsitute for
plotting the RAW data. Time and again I hammer this home, but there will
always be someone who blithely goes through a problem set doing an analysis
and at the end their interpretation is off because they didn't plot the
raw data which clearly showed the structure we were trying to isolate.
(In real life, that's not necessarily the case. :-)
Once the data are plotted, then they can go ahead with the
processing, with some apprectiation (we hope) of the weaknesses in the
data set. (Well, we can try ... :-)
Regards,
David Nobes
Dept. of Geology, University of Canterbury, Christchurch, NZ
Roger Moortgat
engineer. I think of a program as an instrument, just like an
osciloscope or a balance are instruments. You don't have to know
how to make an osciloscope to work with one.
However you have to be absolutely sure the instrument is doing
what you want it to do with the things you put in it. So I feel
uneasy with most commercial software. You know what you put in and
you see what's coming out but you don't know what's going on in
between.
It is a real danger that most young engineers have an almost
mystic believe in the results of a computer calculation. I'm doing
structural engineering for almost 25 years, and yes, it is true
that a calculation is just to confirm what you already know. So
please don't give a young engineer a computer right away, let him
do lots of calculations by hand to give him a feeling of what he
is doing.
I admit however that some programming has to be done. Twenty years
ago I programmed HP calculators, later I used HP basic and now I
indeed, I prefer Mathcad or a spreadsheet.
I know it's not bon ton to talk about BASIC, however over here
it's frequently used to do as you call it, quick dirty jobs.
Pete Roth
[...]
>But look in the history. Fortran 90 needed 13 years to come up.
>If I think, 1990 + 13 = 2003. Thats too late for coming up with OO.
>C++ is running away in the meanwhile..
OO has been around for more than 10 years already, it is only that
engineers are discovering it now. Which has always puzzled me: here in
the USofA, the Computer "science" departments hardly ever talk to any of
the "real" science departments like civil, mech, etc. :) So how are those
of us writing programs to do real work supposed to find out about these
tools like OO ? (A mystery to me).
Michael - Could you amplify your statement about C++ "running away"?
C++ allows one to use the OO paradigm, so are you saying that OO is
here, or not?
###
Grace & peace
ro...@oasys.dt.navy.mil alias: Peter N Roth
"On the Internet, nobody knows you're a dog." - P Steiner.
Pete Roth
>I am reading this thread with interest, as I am just coming to the end
>of a semester teaching a course called Computers in Civil Engineering.
>The course attempts to expose students to the programs and skills they
>will need as practicing engineers, and give them the insights needed to
>live and work with computers.
{... description of Word & Excel deleted }
Great curriculum! One addition you might make would be a CAD program.
Wilfrid Austin Nixon
I agree wholeheartedly about the CAD stuff. We are trying to get
AutoCAD up on our computing system, but it is a little pricey even
with academic discount (I have been quoted about $1,500 per node).
I don't think it is worth while going with something other than
the industry standard (which as far as I can gather, is AutoCAD).
Any thoughts on this? And suggestions would be welcomed!
Wilf Nixon
Associate Professor
Craig Hinners
>
>I agree wholeheartedly about the CAD stuff. We are trying to get
>AutoCAD up on our computing system, but it is a little pricey even
>with academic discount (I have been quoted about $1,500 per node).
>I don't think it is worth while going with something other than
>the industry standard (which as far as I can gather, is AutoCAD).
>
>Any thoughts on this? And suggestions would be welcomed!
>
>Wilf Nixon
>Associate Professor
>Civil and Environmental Engineering
>University of Iowa
Take a look at CADKEY. We use it for our introductory CAD class.
The text, which includes the CADKEY Student Version, runs $90-100.
Not bad for a great cad program, which will run on 286's and other
lower-end computers which seem to proliferate among students. CADKEY
Pro Version 3.5(?) and other versions are installed in the public
engineering labs.
CADKEY is excellent at teaching CAD basics. Do you really want
something complex as AutoCAD if it's only going to be used for
a few weeks out of the semester?
Craig Hinners
CE Sophomore, Northwestern
c...@nwu.edu
Cameron Howie
>In article <664708.9.753732787@*>, 664...@csi.uottawa.ca (MURPHY KEVIN) writes:
>|> What is the most "popular" language that is used in industry today in
>|> Canada (particularly ontario). This is an extremely general question, but i
>|> am very curious. At school we mostly play with fortran 77.
>|>
>|> murf...
>As a engineering application programmer, understanding FORTRAN is a must,
>since the past engineering application codes are written predominantly in FORTRAN.
>C is used a lot for system programming. C++ is gaining firm ground in
>software industry.
>Simply learning the syntax of a language is trivil. To understand
>the essence of programming languages, one should familirize himself to
>different programming paradigms (imperative, functional, logic, OO, ...)
Precisely. Fortran and C are both imperative . If you've written code in F
or C, moving to the other language should take only a few hours studying the
new syntax.
As both an engineer and a comp scientist, I'd favour C++ anyday, whether
writing engineering or CS software because of its more powerful semantics.
If I was only interested in program execution time I'd write the core
routines in Fortran because of the better compiler technology available,
but software engineering is much more than execution time. Development
and maintenance are much faster and less painful in C++ than F (I'm
referring here to F77 since that's the std I'm familiar with).
You might find that the CASE tools at your disposal make the decision for
you. Your colleagues (you shouldn't be in this alone :) might also favour
a particular language platform over another. Existing code (esp libraries)
cannot be forgotten either, though a parochial dedication to 'backwards
compatibility' will only inhibit advances in application design.
>It is extremely helpful to write a _nontrivial_ program using a lanaguages
>typfying each paradigm. You will be amazed how fast you can adapt to and
>_master_ a different lanague if you know the fundmental concepts/constructs
>of programming lanaguages in general.
I've spent so long in an imperative/OO frame of mind that I would find
functional and logical paradigms irritating for writing most applications.
In addition, engineers seem more comfortable with an imperative approach - I
cant see them enjoying Lisp and Prolog ;-). There's also better support
for imperative programming, and the code developed is generally more
efficient.
>A software developer/programmer is not an application end user. I rarely consider
>Word/Excel/Mathcad/Autocad users as a software developer. A person knows nothing
>but FORTRAN is not a good programmer.
I take it you mean (s)he is not suited to programming a wide variety of
applications which might call on experience with other paradigms. Someone with
20 yrs experience at implementing software with Fortran will have a lot of
experience at designing imperative algorithms and would probably be an
excellent programmer in the right environment. Someone might be a polyglot
w.r.t computer languages but have little experience - it's no good being
familiar with 20 different programming languages if you dont know when,
why and how to use any one of them in a practical manner.
Cameron
Mark S Wright-1
Cameron Howie <cam...@cs.uct.ac.za> wrote:
>In <CH6Jt...@noose.ecn.purdue.edu> l...@ecn.purdue.edu (John Lu) writes:
>
>>In article <664708.9.753732787@*>, 664...@csi.uottawa.ca (MURPHY KEVIN) writes:
>
>>Simply learning the syntax of a language is trivil. To understand
>>the essence of programming languages, one should familirize himself to
>>different programming paradigms (imperative, functional, logic, OO, ...)
>
>
>I've spent so long in an imperative/OO frame of mind that I would find
>functional and logical paradigms irritating for writing most applications.
>In addition, engineers seem more comfortable with an imperative approach - I
>cant see them enjoying Lisp and Prolog ;-). There's also better support
>for imperative programming, and the code developed is generally more
>efficient.
Actually, I'll bet there are quite a few engineers out there writing
in lisp - AutoLisp, that is. And isn't SQL considered a Logical Programming
language (you tell it what to do, not how to do it). I've had to use all the
different paradigms except Functional (we use MicroStation), while developing
for surveyors.
Michael J. Saletnik
Take a look at CADKEY. We use it for our introductory CAD class.
CADKEY is excellent at teaching CAD basics. Do you really want
something complex as AutoCAD if it's only going to be used for
a few weeks out of the semester?
Yes - AutoCAD is the only thing used in industry ... I found a CADKEY
knowledge pretty useless when I started my first job out of grad
school. It's one thing to know concepts of projecting views, but
another to have actual, practical experience.
Michael
--
Michael J. Saletnik, Tufts University Civil Engineering E'91 G'93
Structural Engineer, Bryant Associates, Inc., Boston
mic...@binkley.ext.tufts.edu
d.g....@durham.ac.uk
>I really don't think you have to know how to programm to be a good
>engineer. I think of a program as an instrument, just like an
>osciloscope or a balance are instruments. You don't have to know
>how to make an osciloscope to work with one.
>
I don't think it is that it matters which programming language you teach. Our
undergraduate students are taught C (we switched from FORTRAN four years ago.
However, I have asked my students to work with old programs in BASIC, FORTRAN
and they have easily adapted. If you understand programming you can soon learn
a new syntax. I currently have a student who is programming in AutoLISP for his
project and he is managing - of course after an initial learning period.
Learning programming is still a good way of understanding what goes on inside
packages, and I think that is still good for an engineer to understand. That
might mean that they will never program again, but at least they have that
grasp. Isn't that waht education is all about?
David Toll
School of Engineering and Computer Science
University of Durham
Darrell O'Donnell
>From: fe...@hp1.erib.uni-hannover.de (Michael Feist)
>Subject: Re: computer languages
>Date: Fri, 26 Nov 1993 12:23:11 GMT
>In article <hadgraft.4...@ENG3.eng.monash.edu.au>, hadg...@ENG3.eng.monash.edu.au (Roger Hadgraft, Civil staff, ext 4983) writes:
>>
>> I think this is a little out of date. Have a look at Fortran 90. It has all
>> the nice structuring facilities (both code and data) of Pascal and C. It isn't
>> OO yet, but that's coming.
>But look in the history. Fortran 90 needed 13 years to come up.
>If I think, 1990 + 13 = 2003. Thats too late for coming up with OO.
>C++ is running away in the meanwhile..
The X3J3 commitee (responsible for Fortran 90) plans on revisions in 1995
and 2000-2001. They plan on a 5 year revision cycle.
cheers,
Darrell O'Donnell
------------------------------------------------------------------------------
Darrell O'Donnell (Civil Engineering undergrad student)
deod...@undergrad.math.uwaterloo.ca
or: deodo...@twinkle1.watstar.uwaterloo.ca
"Assembled in Canada from Irish components."
Bhupinder Singh
I would also suggest looking at Microstation from Bentley Systems and
Intergraph, IMHO a far superior CAD package to anything else in the market.
I also think they have an educational discount program
As far as programming languages go, I think Fortran is dead. In fact at MIT
you cannot even take a Fortran course since none is offered.
Sure legacy software exists and people are trying to make it a better
language, but its flogging a dead horse, it cannot compete with C/C++
which should be promoted much more than it is in schools. Being in the
Civil Engineering software development environment for that last 7 years,
there are very few graduates one can find who have the qualifications
to do any serious civil application programming. I think that as a field
we tend to lag behind in implementing available technological solutions.
Maybe because the industry as a whole is too conservative or its just
too old a field , and cannot adapt to new computer developments. Whatever
be the reasons I think the applications of CAD and other tools such as
relational databases can be much more than it is in the industry today...
--
Bhupinder Singh Montgomery Watson Engineers
Internet - bsi...@cerf.net
MaBellnet - (818) 568-6107
Bhupinder Singh
>engineer. I think of a program as an instrument, just like an
>osciloscope or a balance are instruments. You don't have to know
>how to make an osciloscope to work with one.
>
>mystic believe in the results of a computer calculation. I'm doing
>structural engineering for almost 25 years, and yes, it is true
>that a calculation is just to confirm what you already know. So
>please don't give a young engineer a computer right away, let him
>do lots of calculations by hand to give him a feeling of what he
>is doing.
>
and experience you get an intuitive feel for an area and there is no
substitute for it. But I can see the same kind of argument made when the
calculator was developed. People should be made to compute simple mathematical
computations by hand before they are allowed to use the calculator.
You can argue that most folks today have a hard time adding up simple
numbers in their head, but the bottom line is using the best and fastest and
most accurate tools available today to get the job done. This is of course
assuming that there is an educated engineer using it.
fsp...@aurora.alaska.edu
> As far as programming languages go, I think Fortran is dead.
Please, let it be true!
My professor in Advanced Structural Anlysis keeps handing out
antiquated subroutines written in FORTRAN. I have never seen so many uppercase
letters all crammed together in my life. It's like trying to read binary.
This university still teaches FORTRAN to all of its students but I hope
we follow the example of MIT (switching to C). We have, however, turned our
Descriptive Geometry class into a semester long AutoCAD course. Unfortunately,
we are still using version 10. Even more unfortunate, I took the class when it
was still compasses, protractors (sp?), and dividers.
+--------------------------------+---------+----------------------------------+
| ___ | It pays | Matrix |
| /\ /\ /\ | |\ | \/ | to be | fsp...@acad3.alaska.edu |
| / || \ /--\ | |/ | | | more | (907) 474-4590 |
| | \/ | | | | |\ | /\ | than | Senior in Civil Engineering |
| | human | University of Alaska, Fairbanks |
+--------------------------------+---------+----------------------------------+
Mark S Wright-1
Bhupinder Singh <bsi...@nic.cerf.net> wrote:
>
>I would also suggest looking at Microstation from Bentley Systems and
>Intergraph, IMHO a far superior CAD package to anything else in the market.
>I also think they have an educational discount program
>
to be a pretty amazing educational discount to make it practical for the
poster to install it in his computer lab. Although AutoCAD may be the
industry standard, Microstation is the Gov't standard (I'm not sure if
that's something to be proud of :-) ). So depending on where you see
yourself employed in the future, it may be something to keep in mind.
>As far as programming languages go, I think Fortran is dead. In fact at MIT
MIT doesn't teach a class in Fortran because MIT is a computer _science_
school, not a trade school, and Fortran is a lousy way to teach to teach
computer science. For that matter, C isn't a particularly good way to
teach computer science either (and I'm about as fanatical a C fan as
you'll find (especially Microstation's MDL), and trying to teach computer
science using an ugly hack like C++ would be an exercise in frustration.
MIT uses scheme for teaching purposes, not because it's industry's
favorite (has anyone ever used scheme outside of college?), but because
it's a good way to teach good programming techniques. This is why I
advised the original poster against fortran - because it would be his first
language, and it wouldn't encourage him to program well.
But, it is possible to write good code in fortran. And fortran is
certainly not dead. It has a huge installed base and it's better for most
numerical work, because of existing numerical libraries and because array
operations can be better optimized under fortran than under C (and C++ can't
even compare for numerical work). The key is to use the tool which best
fits your needs.
>
>
>
>
>--
>Bhupinder Singh Montgomery Watson Engineers
>Internet - bsi...@cerf.net
>MaBellnet - (818) 568-6107
SAOUMA VICTOR E
>
>I would also suggest looking at Microstation from Bentley Systems and
>Intergraph, IMHO a far superior CAD package to anything else in the market.
>I also think they have an educational discount program
Yes indeed, not only is it far superior than anything else, but Universities
can get it for $150 !!
>
>As far as programming languages go, I think Fortran is dead. In fact at MIT
>you cannot even take a Fortran course since none is offered.
ince when has MIT been a model Engineering School? They have their own
way of doing things, and they have the resources (human (faculty/students))
who can exploit their unique position.
>Sure legacy software exists and people are trying to make it a better
>language, but its flogging a dead horse, it cannot compete with C/C++
>which should be promoted much more than it is in schools. Being in the
>Civil Engineering software development environment for that last 7 years,
>there are very few graduates one can find who have the qualifications
>to do any serious civil application programming. I think that as a field
>we tend to lag behind in implementing available technological solutions.
>Maybe because the industry as a whole is too conservative or its just
>too old a field , and cannot adapt to new computer developments. Whatever
>be the reasons I think the applications of CAD and other tools such as
>relational databases can be much more than it is in the industry today...
>
I have yet to see a commercial FE code written in c or c++
>
>
>
>--
>Bhupinder Singh Montgomery Watson Engineers
>Internet - bsi...@cerf.net
>MaBellnet - (818) 568-6107
--
----------------------------------------------------------------------------
Victor E. Saouma | sao...@bechtel.colorado.edu
Dept. of Civil Engineering | Voice (303) 492-1622 Office
University of Colorado, Boulder CO 80309-0428 | Fax (303) 492-7317 "
BONACCI John
Bhupinder Singh <bsi...@nic.cerf.net> wrote:
>In article <4...@tabone.win.net> rog...@tabone.win.net (Roger Moortgat) writes:
>>It is a real danger that most young engineers have an almost
>>mystic believe in the results of a computer calculation. I'm doing
>>structural engineering for almost 25 years, and yes, it is true
>>that a calculation is just to confirm what you already know. So
>>please don't give a young engineer a computer right away, let him
>>do lots of calculations by hand to give him a feeling of what he
>>is doing.
>I feel that calculations by hand are not realistic. Yes, with time
>and experience you get an intuitive feel for an area and there is no
>substitute for it. But I can see the same kind of argument made when the
>calculator was developed. People should be made to compute simple mathematical
>computations by hand before they are allowed to use the calculator.
Whoa! This is a bogus analogy. The calculator relieves you of tasks you
learned in 5th grade. The computer program can relieve you from tasks
you may never learn (if you follow the path of least resistance) or would
only learn late in an undergraduate program otherwise.
I believe you missed Mr. Moortgat's point altogether. If analysis was
was boiled down to learning how to use input menus and writing datafiles,
you would be throwing out concepts behind an understanding of behavior...not
simply avoiding drudgery. I can make an engineering judgment without
remembering how to do square roots longhand, but maybe I could not if I was
never made to ponder the implications of redundancy.
>You can argue that most folks today have a hard time adding up simple
>numbers in their head, but the bottom line is using the best and fastest and
>most accurate tools available today to get the job done. This is of course
>assuming that there is an educated engineer using it.
Bingo! What, pray tell, is your definition of "an educated engineer",
and how does it differ from a data entry technician?
Before you flame me, go back and reread the post you responded to.
JB
Roy E. Unny
>From: wan...@icaen.uiowa.edu (Wilfrid Austin Nixon)
>Subject: Re: computer languages
>Date: Tue, 30 Nov 1993 14:11:17 GMT
>In article <74...@oasys.dt.navy.mil>, ro...@oasys.dt.navy.mil (Pete Roth) writes:
>|> In sci.engr.civil, wan...@icaen.uiowa.edu (Wilfrid Austin Nixon) writes:
>|> >I am reading this thread with interest, as I am just coming to the end
>|> >of a semester teaching a course called Computers in Civil Engineering.
>|> >The course attempts to expose students to the programs and skills they
>|> >will need as practicing engineers, and give them the insights needed to
>|> >live and work with computers.
>|>
>|> {... description of Word & Excel deleted }
>|>
Why are your undergraduate students being taught how to use WORD, EXCEL, etc
in one of their courses ? Should they not know how to use those tools
already or be able to learn on their own......
------------------------------------------------------------------------------
Roy E. Unny
Masters Program, U. of Waterloo
Systems Design Engineering
Home: (519) 699-5313
Richard Stessel (CE)
(i. e., a "light" version) for about $500 retail. I called the number
and asked for upgrade information (I have Autosketch for Windows), but
have yet to receive anything. This might be of interest if you are using
PCs. Dunno if there'll be an academic price, either.
FWIW
Rich
--
* Richard Ian Stessel, Ph. D., P. E. * Everything =======
* Associate Professor * eventually |Solid|
* Dep't of Civil Eng'g & Mechanics * becomes |Waste|
* ste...@sunburn.ec.usf.edu * |_____|
Roth
[...]
>Why are your undergraduate students being taught how to use WORD, EXCEL, etc
>in one of their courses ? Should they not know how to use those tools
>already or be able to learn on their own......
I would guess it's like many other subjects: remedial. E.g., why do
engineering schools teach english? Shouldn't the students be able to
speak (or at least read) the language? Yet, when graduates reach the
workplace, they usually must be taught how to write. Hmmm. Maybe
for MORE the English for courses better for would be benefit!
Also, folks are in transition between the "old" paradigm (paper + pen)
and the new (whatever it is). Some have made the transition in grade
school, some of us are culturally deprived & must learn it _somewhere_
Roth
[...]
>
>I have yet to see a commercial FE code written in c or c++
>
Supposedly, ALGOR is a C code. Their adverts certainly lead one to
believe that it is commercial... And the new program "INERTIA" is
written in some form of C (although the use of the phrase "object
oriented" in their literature is merely a buzzword compliance,
rather than actual development using the OO paradigm).
If by "commerical" you mean "for sale", then commercial FE in C++
_will__happen_... I'm working on one now, expected release 94Q2.
Whether it's a commercial _success_ will remain to be seen... :)
Default Trumpet User
>From: RU...@SYSTEMS.watstar.uwaterloo.ca (Roy E. Unny)
>Subject: Re: computer languages
...
>Why are your undergraduate students being taught how to use WORD, EXCEL, etc
>in one of their courses ? Should they not know how to use those tools
>already or be able to learn on their own......
>------------------------------------------------------------------------------
>Roy E. Unny
>Masters Program, U. of Waterloo
>Systems Design Engineering
>Home: (519) 699-5313
month or so, I've often asked the same question. I've finally concluded
that if we are to expect students to:
A: Recognize the value of certain tools.
B: Use them in appropriate and productive ways.
C: Avoid printing reams of nearly blank pages or formatting away five
hours of work.
we have to teach at least some of the ways of using the tools. I'm hoping
to open their minds to the possibilities within just a few of the routine
tools and show them that spreadsheets are usefull for more than balancing a
cheque book or recording last month's sales for five different salesmen.
If I can just reduce the numbers coming down the hall with:
"I hear you know something about... how do you....?"
One of our other problems is the range of experiences our students have from
various parts of a so called "have not" province. Some students in my
upcoming class have a far better knowledge of the subject than I while
others will be almost afraid to type in their ID when it comes to connecting
to our Novell Network.
88PS: Anyone know why a cheap keyboard will throw up 88's instead of up
arrow movements and various other ill behavours in only particular programs?
6 (ie. 6 for a right arrow and 4 for the left) The problem happens
regardless of NUM LOCK and often includes a locked shift on the numeric row.
..6644 Thank goodness for a mouse or I'd never get around in this editor!
Eldo H.
Civil Engineering
University of New Brunswick
Balaji V. Ramanathan
|> bsi...@nic.cerf.net (Bhupinder Singh) writes:
|>
|> > As far as programming languages go, I think Fortran is dead.
|>
|> Please, let it be true!
Not so fast! Most of the existing software in Civil Engineering
(at least in Transportation) is exclusively in Fortran.
|> My professor in Advanced Structural Anlysis keeps handing out
|> antiquated subroutines written in FORTRAN. I have never seen so many uppercase
|> letters all crammed together in my life.
That is one of the reasons most civil engineers have to be
conversant with Fortran. anytime you want to know the insides of a Civil
engineering program or want to make modifications, you can know all the
C/C++ you want, but it is not going to help you any.
I am not a big fan of Fortran either, but it is better to be
realistic. Personally, I feel that most civil engineering software
can be written quite well without the use of pointers, objects etc.
And with the introduction of Fortran 90, it is as easy to write structured
programs in Fortran as it is in any other language.
BTW, Fortran does not distinguish between upper case and lower case.
If a string of upper case letters bothers you, get your editor to convert
the case to lower case. Also, IMHO, Fortran is far easier to read than
C/C++.
|>
|> +--------------------------------+---------+----------------------------------+
|> | ___ | It pays | Matrix |
|> | /\ /\ /\ | |\ | \/ | to be | fsp...@acad3.alaska.edu |
|> | / || \ /--\ | |/ | | | more | (907) 474-4590 |
|> | | \/ | | | | |\ | /\ | than | Senior in Civil Engineering |
|> | | human | University of Alaska, Fairbanks |
|> +--------------------------------+---------+----------------------------------+
--
----------------->8 Cut here for Signature! 8<---------------------
Balaji Ramanathan, |
Institute of Transportation Studies, | I don't believe in luck!
University of California, Irvine. | I RELY on it!!
Wilfrid Austin Nixon
It all depends on what you mean by "use"? Yes, they can all fire up Word and
Excel, but that doesn't mean they can use them effectively. Excel in particular
has capabilities which are very useful to Engineers, but which we perhaps tend,
as a group, to overlook, because we think of Excel as a "spreadsheet program"
designed for business types to create pretty pie charts. One of the aims of the
course was to expose students to the vast array of possibilities available to
them in existing software to solve problems. Some of these solutions are in
traditional engineering type programs (e.g. Matlab) but some are not. Excel is,
I think, a non-traditional program for engineers to use, although that is
changing. If I want students to learn how to use Excel effectively as engineers,
I cannot just tell them "Here it is, go and use it." Students require more
guidance than that. By pointing out the highlights of a program, and going over
some of the harder things (e.g. writing Macros and using the Excel Solver) I can
make the program much more accessible to them and thus they will use it more.
It also allows me to stress the limitations (yes, that's right, limitations) of
computers. I say to them repeatedly and I'll inflict my saying on the net, that
if you don't know (approximately) what the answer is, you have no business using
a computer to find it for you (in an engineering situation!). My justification
is that without a knowledge of what the answer should be in general terms, you
cannot tell whether your computer answer is correct or the result of poor input
or poor programming. Perhaps this, more than any language or program, is the
most important lesson to teach students about computers.
Yusin Lee
|> (lines deleted)
|> Also, IMHO, Fortran is far easier to read than
|> C/C++.
Well, easiness to read depends more on the programmer than on the language itself.
Yusin Lee
|> I feel that calculations by hand are not realistic. Yes, with time
|> and experience you get an intuitive feel for an area and there is no
|> substitute for it. But I can see the same kind of argument made when the
|> calculator was developed. People should be made to compute simple mathematical
|> computations by hand before they are allowed to use the calculator.
|> You can argue that most folks today have a hard time adding up simple
|> numbers in their head, but the bottom line is using the best and fastest and
|> most accurate tools available today to get the job done. This is of course
|> assuming that there is an educated engineer using it.
I don't agree. In a similar logic one might argue why people should learn
calculus while numerical integration/differentiation can do most of the work.
The answer is we learn calculus not only because we want to know the area under
the curve, but also want to use it as a tool when we go beyond area under the
curve into the more advanced world of mathematics. Similarly the purpose of
learning how to add 34 with 75 is not just to know how to get 109. The real
purpose is to learn a methodology which could be useful when you go beyond adding
numbers together.
Patrick G Kinnicutt
n article <2CFFB9...@news.service.uci.edu>, ra...@ganymede.its.uci.edu (Balaji V. Ramanathan) writes:
|> (lines deleted)
|> Also, IMHO, Fortran is far easier to read than
|> C/C++.
Fortran, if not used properly, can be a pain to read, as well as C and
C++. It depends greatly on the programmers' programming styles, naming
conventions, use of comments, etc. Also, it is possible and fairly
common to link Fortran numerical libraries to C or C++ applications.
Pat
-----------
Patrick Kinnicutt (617) 492-8367(h)
chess@.mit.edu (617) 253-3883(o)
Department of Civil and Environmental Engineering (617) 253-6044(FAX)
Massachusetts Institute of Technology
Mailing Address: /* Any ideas are entirely my own unless otherwise */
---------------- /* stated. */
Patrick Kinnicutt
MIT Branch P.O. Box 233
Cambridge, MA 02139
AM. Vann
[....]
> But, it is possible to write good code in fortran. And fortran is
> certainly not dead. It has a huge installed base and it's better for most
> numerical work, because of existing numerical libraries and because array
> operations can be better optimized under fortran than under C (and C++ can't
> even compare for numerical work).
Is this true? Why can array operations be better optimised under Fortran? Is
that because there hasn't been demand for these kind of optimisations in the
current C and C++ compilers, or because of something fundamental in the
language structure? I have to admit that once you start creating C++ objects
to represent data (and adding methods to them) the amount of space used shoots
up. However, there are certainly compensations in the ease of programming. I
also would have thought that C was at least no worse than Fortran in terms of
arrays, although I'm much more familiar with C than Fortran. I have to admit
a long-standing prejudice against Fortran, but this is mainly due to the
appalling interfaces on Fortran programs ported from mainframes to PCs. I'm
trying to overcome it!
--
-----------------------------------------------------------------
Andy Vann JANET: A.M....@uk.ac.bristol
Dept of Civil Engineering INTERNET: A.M....@bristol.ac.uk
University of Bristol Tel (+44) 272 303288
UK Fax (+44) 272 303889
-----------------------------------------------------------------
Jeff Dragovich
>Newsgroups: sci.engr.civil
>Path: vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!uknet!warwick!bsmail!irix!ceamv
>From: ce...@irix.bris.ac.uk (AM. Vann)
>Subject: Re: computer languages
>Message-ID: <CHpMI...@info.bris.ac.uk>
>Sender: use...@info.bris.ac.uk (Usenet news owner)
>Nntp-Posting-Host: irix.bris.ac.uk
>Reply-To: A.M....@bristol.ac.uk
>Organization: University of Bristol, England
>X-Newsreader: TIN [version 1.2 PL1]
>References: <664708.9.753732787@*> <2dfqlo$7...@news.acns.nwu.edu> <MSALETNI.93...@jade.tufts.edu> <2djh52$i...@news.cerf.net> <CHF5p...@news2.cis.umn.edu>
>Date: Wed, 8 Dec 1993 09:32:52 GMT
>Lines: 29
>Mark S Wright-1 (wrig...@gold.tc.umn.edu) wrote:
>
>[....]
>
>> But, it is possible to write good code in fortran. And fortran is
>> certainly not dead. It has a huge installed base and it's better for most
>> numerical work, because of existing numerical libraries and because array
>> operations can be better optimized under fortran than under C (and C++ can't
>> even compare for numerical work).
>
>Is this true? Why can array operations be better optimised under Fortran? Is
>that because there hasn't been demand for these kind of optimisations in the
>current C and C++ compilers, or because of something fundamental in the
>language structure?
Some operations can be better optimized in FORTRAN because of object
aliasing in C. An alias for an object is an alternative way to access the
object.
"If an object has no aliases, there is no way to modify the given object
other than through explicitly assigned pointers to the object itself. The
translator may properly copy it into a register of any other portion of
fast memory and read only the copy without checking whether the original
object has changed."
From ANSI C, A Lexical Guide. Mark Williams Company.
Bhupinder Singh
>
>Bingo! What, pray tell, is your definition of "an educated engineer",
>and how does it differ from a data entry technician?
>
>Before you flame me, go back and reread the post you responded to.
>
>JB
No flames necessary. The main point I am trying to stress here ( no pun
intended :) is that, of all the engineering disciplines I have been involved
with over the years Civil Engineering seems to be the one that is least
exploiting computer technology. Whether you make CE's compute 5,10 or 20
moment distribution calcs by hand and then put them on a system, (if
that gives you a warm fuzzy feeling about them now being educated fine)
or whatever. The use of CAD, databases and suchlike tools is fairly
limited, even in colleges. Forget that, as someone else here mentioned
Excel being a good tool, how many entry level CE's are comfortable with a PC ?
Yong Wang
IMHO, I think the reasons that Fortran is still being taught are
1) Fortran is sufficient enough for numerical computing,
2) Most of programming tasks engineering students will cope with
are nothing but numerical computing.
Until all engineering disciplines are fully computerized where engineering
students have to know more about computer rather than just some numerical
programming, Fortran (whatever version, believe few people would really
care about the new features) is here to stay.
A good piece of software is not just how efficiently it runs, there are
many other qualities need to be considered. The current trend in the engineering
software industries is C and C++ are replacing Fortran, that makes me
even wonder if they will rewrite the biggest FEM software I know,
NASTRAN, entirely in C. As a general programming language, C and C++
have more superior qualities over Fortran than disadvantages, such
as dynamic allocation, readibility, resuablity, portability, modularity,
GUI interfacing, etc. There is always a tradeoff between memory
usage and program overhead.
Suggestion for engineering students who are selecting programming
language to learn : learn C! It may seem tough at first, but the
result will be rewarding.
---Yong
-------------------------------------------------------------------------
Yong Wang
Civil Engineering Dept. | *---------* Civil
Auburn University, AL36849 | / \~\~\~\~\~\ Engineering
inet : yong...@eng.auburn.edu | = ============ __
YW...@ducvax.auburn.edu | l T T T T o_\|
| _^ _^__^__^__^_ _^_\|_
-------------------------------------------------------------------------
Cameron Howie
I don't see why aliases should hamper C compilers. Array aliases across
procedure boundaries are going to occur in Fortran as well as C...
C code:
void function_one ()
{
int x[10];
function_two(x);
}
void function_two (int *x)
{
int i;
for(i=0;i<10;i++)
x[i] = i+1;
}
FORTRAN code:
I dont want to embarass myself here as I only read F77, I dont use it. I think
it would be something like:
FUNC1 ()
INTEGER X(10)
FUNC2 (X,10)
END
FUNC2 (X,N)
INTEGER X(N)
DO 10,I=1,10
X(I) = I
10 CONTINUE
END
Now in C, function_one passes the address of the 'x' array to function
two. In F77 this is automatic because you dont want to pass entire
arrays. So, both C and F77 code will pass an address (pointer) and hence
function_two/FUNC2 has access to the array data. Though this is a simple
example, I fail to see how an F77 compiler can outdo the code generated
by a C compiler since the semantics are the same in both cases. In
sequential code, the above example is meaningless as the function
arguments are stacked, and function_two/FUNC2 can fiddle with the array and
when control returns to function_one/FUNC1 there is no problem with
corrupt data. However, in a parallel programming environment, aliases
through passing arguments apply. Here's an example of an alias
'weakness' in C...
C code:
void function()
{
int x;
int *y;
x = 123;
y = &x;
...
}
Because F77 doesnt have pointers :( you cant get into this sort of
situation. A C compiler has to recognise that changing the contents of 'y'
is actually the same as changing the contents of 'x'. Therefore a data
dependance analysis of a block of code involving 'x' and 'y' is more
complicated. However, prior to a DD analysis, the compiler can convert
all '*y' references to 'x', example:
BLOCK 1
x = 123;
*y = 456;
if ( x == 123 )
printf("Condition true\n");
BLOCK 2 (remove aliases)
x = 123;
x = 456;
if ( x == 123 )
printf("Condition true\n");
As far as I can recall, most C compilers offer a 'remove aliases' (or
some equivalent wording) as an optimization option. Even so, it'd be a pretty
daft C programmer who chooses to use aliases as above. He has no need to
create an alias through 'y = &x', since 'x' will generate the same result.
However, C does offer this possibility, so a compiler must be written to
handle it.
CONCLUSION
While C exposes a lot through pointers, I cant see where F77 provides the
compiler advantage mentioned by previous posters if applied to array
processing. The semantics of F77 can be expressed in C exactly. A C compiler
can convert variable aliases within a block of code if the programmer
has used aliases. Across function/procedure boundaries, both languages
will use aliases for efficiency.
Have I missed anything here?
Cameron
P.S. F77 MIGHT provide easier compiler optimization IN GENERAL over C because
it has less semantic power and because there is a restriction on code layout -
you cant use function prototyping like in C (for example). Therefore, when the
parser is at some point P in the source code, it will have more
information available to it for optimization purposes. However, this can
be overcome in C by structuring code in F77-like order.
In the end, I'd say F77 compiler ability to produce better target code is
because of
- many more years of experience in the writing of Fortran compilers
- simpler semantics in Fortran (no pointers, no user-defined data
types, no 'switch' statements etc).
So, array optimization falls within this overall advantage for generating
superior code over a C compiler parsing the same semantics.