[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: small integers
- To: firstname.lastname@example.org, email@example.com
- Subject: Re: small integers
- From: firstname.lastname@example.org (Scot Dyer)
- Date: Mon, 19 Oct 92 09:21:52 PDT
- Cc: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU, email@example.com, firstname.lastname@example.org
/// The already working codes had to be developed at least once though. And
/// most large numeric programs are constatntly being twiddled. Take some
/// of the large "Hydrodynamics" codes run at the national laboratories.
/// They are constantly being upgraded to agree with the latestest
/// experimental data. The codes are then tested regressively against all
/// previous data for agreement. This is a very time consuming process.
/// A modern, efficent development environment would help considerably.
Dynamic development may not be the best modern development environment for such
projects, then. [a gasp escapes the studio audience] The regression testing
would have to be heavily compiled and optimized (read: static-ized) in order
for such heavy-duty number crunching testing to be viable.
Dylan may be, despite it's name [DYnamic LANguage], a suitable language for
expressing such algorithms at some time in the future, but only if enough
attention is paid to float optimization when writing the compiler.
/// Also, think of all the image processing and full motion video code that
/// will be developed in the coming years. Most of that code is intensely
/// numerical. It will be important for that code to execute quickly. We
/// we be forced to write that code in C or Fortran? I hope not.
Hopefully, Dylan will come equipped with a foreign function interface that
would allow the development of methods on these objects in a static language.
I agree that this is not the best long-term direction, but languages that try
to be everything for everyone end up like PL/I.
Not that PL/I wasn't a great language. I just don't need compiler-support for
eight different numeric representations, and more constructs than I can count.
PL/I represents committee language designe, and much like Ada, a complete
compiler was never produced [Ada fans, I may be wrong about the later] because
of the bulk of requirements laid down for it.
Even worse, people who paid [through the nose] for what PL/I compilers
there were seemed to resent having to pay for what everyone else wanted
when they bought them... Numerics are important, but I think we need a
good implementation of the base language before we can really dig into
more detailed issues...