Re: interpretive vs. compiled
- From: pjb@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon)
- Date: Tue, 20 Jan 2009 14:09:34 +0100
Jason <jason.lillywhite@xxxxxxxxx> writes:
Thank you everyone for those great explanations! It makes sense that
dynamic languages can be used for developing complex software. My
background is in using simulation models for civil engineering,
usually built in FORTRAN. These apps are designed to run as follows:
1. develop an input file, 2. hit run, 3. wait until all the
calculations are done, 4. view results. Example apps are EPANET,
Modflow, HEC-2, and many more. We also develop our own smaller tools
for specific needs in FORTRAN.
Well, think about it. Aren't these application designed this way
because of the limitations that existed (once upon a time) in systems
programmed in Fortran? That is, if engineers had interactive access
to computers, perhaps they wouldn't have used this linear workflow.
Programmers have more imagination with respect to computers and
program (naturally, it's their job). So it's natural that the
inventor of Lisp also invented time sharing, to let programmers have
interactive work sessions with the computers.
Nowadays, workstations are also available to engineers, and there's no
reason why they should continue with linear workflows. Also, today
computers being much faster, the simulations required by the engineers
can be computed almost in real time in most cases, so they could
easily be embedded in an interactive environment.
Under this paradigm of input file/run, it seems you would want to
compile and not use a dynamic language. We often see these FORTRAN
models take more than an hour to run through all the computations - so
execution time can be important - about 25% of the time.
Instead, the engineer could spend more time in developing the "input
file", interactively, with frequent feedback from the computer.
Instead of running one big simulation per hours, he could be running
simulations every few seconds, and modifying the data or program
interactively.
But I need to say, after looking at FORTRAN code all these years,
looking at something like Ruby or Python sure is nice! Garbage
collection, dynamic documentation, exceptions, and many other OOP
aspects in general sure seem nice. I would rather build a simulation
model in Ruby than in FORTRAN because of this - just concerned that it
would create much longer computation times than we want.
I find it interesting that many of our engineering apps are still
built in FORTRAN. I think it is because the engineers graduating 25+
years ago had to use FORTRAN and the engineers graduating today use
Excel/VBA and much less exposure to programming. Professors in our
colleges are wondering what language to use in classes. We are
defaulting on Visual Basic, which I feel is unfortunate. So here I am
with nobody else in my entire industry who use the newer dynamic
languages.
The newer generation of engineers should have the same exposure to
programming as the older generation. We should be building our own
apps in something other than Visual Basic. If you had control over
civil engineering curriculum in our schools, what would you suggest to
our professors? Just use any language? Use FORTRAN because that is
what we are used to? Continue with VBA because it is well documented?
Use some new language?
When I discovered Ruby, I thought, "this is a great language for us.
It is powerful and easy to read." Definitely a step up from VB. This
is the reason I keep bringing up Ruby. It is a breath of fresh air
after dealing with FORTRAN and Visual Basic. I'm happy to hear any
thoughts on this subject. Thank you.
Notice that Common Lisp cover all the domain:
- it is a dynamic programming language with an interactive REPL (read
eval print loop), leading to easy and fast development,
- it has compilers that produce native code even better than gcc,
- it excels in meta-programming, there are translators from Fortran to
Common Lisp (eg f2cl for Fortran-77 code), which can be used to
convert Fortran library sources into Common Lisp code.
- of course, you can call "foreign" code, use libraries written in
other programming languages from Common Lisp, so you can use CL for
exploratory programming, while you call up to existing debugged and
optimized libraries that may be implemented in other programming
languages.
You could do almost the same in Ruby, but it is less well advanced.
There is much more experience in the Lisp familly of programming
languages to produce good compilers and good programming environments.
You have various professionnal and free implementations of CL.
http://maxima.sourceforge.net/
http://matlisp.sourceforge.net/
http://www.sbcl.org/
http://www.gigamonkeys.com/book/
http://www.franz.com/success/
http://www.franz.com/success/customer_apps/modeling_simulation/
--
__Pascal Bourguignon__
.
- Follow-Ups:
- Re: interpretive vs. compiled
- From: Jon Harrop
- Re: interpretive vs. compiled
- References:
- interpretive vs. compiled
- From: Jason
- Re: interpretive vs. compiled
- From: Phlip
- Re: interpretive vs. compiled
- From: Jason
- interpretive vs. compiled
- Prev by Date: Re: solving an equation different ways
- Next by Date: Re: interpretive vs. compiled
- Previous by thread: Re: interpretive vs. compiled
- Next by thread: Re: interpretive vs. compiled
- Index(es):
Relevant Pages
|
