I'm very interested in dataflow and concurrency focused languages. I've read up on the subject and repeatedly I see SIGNAL, Esterel, and Lustre mentioned; so I take it they're prominent players in those fields. However, many of their links in the resources I found are dead and they don't seem very accessible. I managed to find a couple compilers I can compile from source (Polychrony Toolset for SIGNAL and the Columbia Compiler for Esterel) but they've both had issues when trying to compile with cmake. Even textbooks teaching these languages have been tough to come by.
With the background of the way, my actual questions are: is anyone really familiar with this field of programming? Are these languages still big deals, or have they "died out" by now? Could it be they're just available to big companies with a hefty price tag, so the average programmer wouldn't really be able to pick those languages up?
I ran into a couple other dataflow/concurrent paradigm languages, such as Oz or E, but they seemed to be mostly for education and not suitable for real world projects. Not to say they aren't impressive languages, but their implementation was limited and it would be unlikely to see them in production contexts. Does anyone know of other languages in this field they can recommend that are actually accessible (have good documentation, tutorials, and an installable compiler to actually code in)? Or can anyone clarify a language such as Oz or E and hopefully show that they indeed are good enough for large real world projects?
All the languages you mentioned are not widespread. This means their compilers and runtime have bugs, the community is narrow and can give little help, and linking with general purpose libraries can be problematic.
I recommend to use an actively supported general purpose language such as Java, Scala, Kotlin or C++. They all have libraries to support asynchronous computations, and dataflow is no more than support of asynchronous procedure call. You even can develop your own dataflow library. This is not that hard: I wrote a dataflow library for Java which is only 40 kilobytes of source code.
Have you tried Céu? It is a recent variant of Esterel, and compiles to C. It is simple to understand, and provides a reactive and concurrent structuring of control flow. Native C calls can be made by just prefixing them with an underscore ("_printf").
http://ceu-lang.org
Also, see the paper "Structured Synchronous Reactive Programming with Céu" for a nice overview.
http://www.ceu-lang.org/chico/ceu_mod15_pre.pdf
These academics languages mostly disappeared as such and are used in industrial tools
Esterel-Lustre are the basis of in Ansys' SCADE
Signal is used in 3DS' ControlBuild
Esterel was used in Synopsys' ConcentricStudio.
Researchers use also Heptagon for synchronous language studies for code generation, formal methods, new concepts.
Related
I am currently considering writing a small game. It is essentially a map where you can zoom out and in, and in certain places click on info boxes where, at some point, I hope to integrate minigames. Granted, game might be overstating it. Think of it as an interactive map. The theme is how mathematics can be applied in peoples every day life to raise awareness on the usefullness of mathematics.
The question is how I as fast as possible can make a reasonable prototype. If I recieve enough positive response on this I might try to code "the real thing" and use the prototype to obtain funding.
However, I am at a crossroad. I want something to work rather fast and have some C++ experience coding optimization problems, mainly in c-style. I am not convienced, though, that coding it in C++ is the fast way to obtain a prototype. Though I have some experience coding in C++, but have no experience in coding any sort of GUI.
As I see it there is a number of possibilites:
C++, possibly using some library, such as boost or ???.
Start out purely webbased, using e.g. HTML 5 and java.
Python
C#/.NET
Others, such as?
I have to admit I have little experience with anything besides C++ and the STL.
So my question to this wonderful forum is basically, is there a language that provides a significant advantage? Also, any additional insight or comments is more than welcome!
Python is a simpler language than C++, and for prototyping it will help you focus on the task at hand. You can use Pygame, a game library built on the excellent cross-platform SDL library. It provides 2D graphics, input, and audio mixing features. SDL is mainly a C library (and thus compatible with C++), and there are a number of very useful libraries that integrate with it:
SDL_image for loading images in various formats
SDL_ttf for rendering text using TrueType fonts
SDL_mixer for audio mixing
SDL_net for networking
SDL_gfx for graphics drawing primitives
So if you prototype in Python using Pygame, there is a reasonable chance you’ll be able to port what you make over to C++ with minimal hassle, if and when you choose to do so.
Possible options:
Go with what you know the best. Anything else will require a learning curve, which may be weeks to months long. If you're willing to take that road in order to make your prototype, then there are some really great tools available.
BlitzBasic is a good way to go, and is basically designed to be for games
I've done little games in Java using Slick2D - but you'll need good grounding in object-oriented coding to work effectively in Java. If you've got that from C++, then you can see a tech demo I built in Slick2D called Pedestrians. It's open source, and has demo videos here.
You might also ask your question on https://gamedev.stackexchange.com/ - a Q/A site dedicated to game programming
I tried googling and read some snippets online. Why is Ada a "safety critical" language? Some things I notice are
No pointers
Specify a range (this type is an integer but can only be 1-12)
Explicitly state if a function parameter is out or in/out
Range-based loops (To avoid bound errors or bound checking)
The rest of the syntax I either didn't understand or didn't see how it helps it to be 'safety critical'. These are some points but I don't see the big picture. Does it have design-by-contract that I am not seeing? Does it have rules that make it harder for code to compile (and if so what are some?) Why is it a 'safety critical' language?
Well, this is pretty simple. The reason there's a lot of Ada sytax that doesn't seem to have much of anything to do with making the language "safety-critical" (whatever that means for a language) is that this was not Ada's design goal. It was designed to be a general-purpose compiled system's programming language, sufficently capable that the U.S. Department of Defense could get rid of all its little one-use languages it had to support all over the place.
The fact that the end result is a language that is rather useful for safety-critical applications was just a happy side-effect of the fact that the language was very well-designed with military applications (where lives are often staked on the software's reliability) in mind.
Surprisingly few other modern languages had support for building reliable software as a design goal. Most seem to be cooked up by a lone "genius" hacker, with the chief goal being the ability to facilitate cranking out lots of code quickly, perhaps in some new way that hacker favors.
All of those are good for safety-critical application; but consider also the ability to assign a layout (down to the bits) and the ability to [optionally] specify that such a record can ONLY be at a certain location (useful for things like video-memory mappings).
Consider that a lot of safety-critical applications are also without standard (in the senses both of "wide-spread" and of forward-comparability) interfaces; example: nuclear reactors, rocket engines (the engineering itself differs from generation to generation*), models-of-aircraft.
The upcoming Ada 2012 standard DOES have actual contracts, in the form of pre- and post-conditions; example (taken from http://www2.adacore.com/wp-content/uploads/2006/03/Ada2012_Rational_Introducion.pdf):
generic
type Item is private;
package Stacks is
type Stack is private;
function Is_Empty(S: Stack) return Boolean;
function Is_Full(S: Stack) return Boolean;
procedure Push(S: in out Stack; X: in Item)
with
Pre => not Is_Full(S),
Post => not Is_Empty(S);
procedure Pop(S: in out Stack; X: out Item)
with
Pre => not Is_Empty(S),
Post => not Is_Full(S);
Stack_Error: exception;
private
-- Private portion.
end Stacks;
Also, another thing that gets glossed over, is the ability to exclude Null from your Access/pointer types; this is useful in that you can a) specify that exclusion in your subprogram parameters, and b) to streamline your algorithm [since you don't have to check for null at every instance-of-use], and c) letting your exception handler handle the (I assume) exceptional circumstance of a Null.
* The Arianne 5 disaster occurred precisely because the management disregarded this fact and had the programmers use the incorrect specifications: that of the Arianne 4.
AdaCore has a nice presentation of various safety features of Ada 2005 here:
http://www.adacore.com/knowledge/technical-papers/safe-secure/
The US Government and industry also ran studies on program reliability a long time ago that compared languages. I couldn't find one very quickly as the sites are all old (!) but here's a quote from DDCI's website you: " In studies conducted during the eighties Ada consistently outperformed established programming languages like Pascal, Fortran, and C. In the nineties, Ada continues to surpass C++ in performance evaluations measuring capability, efficiency, maintenance, risk, and lifecycle cost."
Lists reasons they used it on Commanche project in link below. I'll add that the platform implementations have been around for a LONG time and stayed stable. Like a source in article said, maintenance is where majority of costs come in. We've seen the modern contenders .NET and Java change like crazy. Long-term stability of Ada is better for safety-critical apps which are often fielded for long periods (sometimes decades).
http://www.ddci.com/displayNews.php?fn=programs_rah66.php
Another benefit is Ada was designed for cross-language development. I keep seeing in the news people talking about how .NET and JVM are innovative b/c they let you mix the "right tools for the job" into one system. Ada's had that ability for a long time. It's common for apps to be a mix of Ada, C, C++, assembler, etc. (MULTOS CA comes to mind.) And they still function well.
It hasn't been static either. They keep updating the language, most recently in 2012. Its portability allowed it to run on both JVM and .NET too for people that want the libraries or have plenty existing code on those. There's also Ada development tools and robust runtimes for many OS's and RTOS's from IBM, Aonix, AdaCore, and Green Hills.
Last benefit: if it will compile, it will work. Usually.
I know this is late, but it's an example I recently encountered. I wrote the following C++ function that worked fine in -O0:
size_t get_index(const Monomial & t, const Monomial & u) {
get_index(t, u.log()); // forgot to type "return" first...
}
This actually compiles, and while it might emit a warning if you're lucky to have a decent compiler, you're not likely to see it when it's one of a lot of programs being compiled. Miraculously, it ran just fine when I compiled it with -O0. But when I compiled it in -O3 it crashed every time, and for the life of me I couldn't figure out why, because I didn't see the warning (if it even appeared). Imagine debugging that when you think you imagine a return there simply because you know your intent.
Likewise, back when I was learning C I frequently made this mistake:
int a;
scanf("%d", a); /* left out & before the a */
Using int's for pointers and vice versa is considered normal programming practice in C, so much so that compilers 25 years ago didn't even bother to emit a warning. Heck, that was a feature of C, not a bug. (See, for instance, Brian Kernaghan's "Why Pascal is not my favorite Language.") And of course back then home computer OS's didn't have memory protection; if you were lucky the computer wasn't writing to hard disk when it reset.
These kinds of mistakes won't even compile in Ada. Functions have to return a value, and you cannot accidentally use an Integer in place of an access Integer (i.e., pointer to integer).
And that's just the start!
Ada has superior support for real-time http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-1-3-4.html . This allows the programmer to implement a greater degree of determinism rather than worry about the technical details of the programming language itself. While many of the run-time features supported by Ada can be achieved in C with some deep understanding of things, Ada achieves most real-time features very well since it's standardized. Ada even has a Ravenscar profile http://en.wikipedia.org/wiki/Ravenscar_profile and SPARK a computer language where "highly reliable operation is essential" is based on a subset of Ada 83 and 95 http://en.wikipedia.org/wiki/SPARK_%28programming_language%29. My guess is that SPARK does not have a version for later Ada versions b/c it is too early to tell how safe the newer versions really are. It's also mentioned in the latter article that Ada can be optimized for speeds rivaling C which would be important for real-time applications that relied on precise control during rapidly changing events. There are many built in standard features for real-time control which are obviously important for a 'safety critical' language.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am new to programming. I have some Knowledge Of C++ and have learned Python.
Now i want to develop a Qt Gui Application. Which language should i use for Qt development C++ or Python with PyQt. I found Python to be easy language.
There is no definite answer to this question. With that said...
Pros and cons you often hear
Python is easy, C++ is hard (in
comparison to Python)
C++ is fast, Python is slow (so to
speak) performance wise.
In reality...
Both arguments can be true or false, you can make slow C++ program, but you can also make fast Python program, you could also say C++ is not that hard if you know it really good etc.
Qt is written in C++ so the documentation examples are in C++. This is not really a problem since it is easy to port this to Python. Although I've found that for example animations with state machine cause segmentation faults with PyQt and PySide is not all that stable yet.
So which one to pick?
Depends on your skill and assignment. If it is work you are doing go with what you know best and asses how much speed you actually need, not every app has a need for lower level code.
If you know Python, you could start building your prototype in Python, then port to C++ parts that you deemed slow and bind them back to the Python (using SIP for example) or even port the whole application to C++. This approach also makes good exercise.
But even if you wrote your whole app in Python I doubt you and your clients would ever notice the "slowness" or "fastness" if you go with C++. These things usually depend on skill of a programmer.
Conclusion
It's entirely up to you to choose what are you are most comfortable with and to understand what your app really needs, but both languages will do the job in most cases.
My subjective advice would be to go with Python and port to C++ if you really need to. Sole reason for this advice is that you do not need to type as much in Python as you do in C++ but this can also be seen as a silly reason.
I just finished a reasonably large project with PyQT... I think your choice should depend on three factors:
How big is your audience (less
than 100 installations? More?)
How much functionality do you need?
(Databases + graphics + plotting +
signal analysis + network access +
blah blah blah)?
How rapidly do
you need to develop, both now and in
the future?
C++/QT is great for 1) Big audience, 2) Low to medium functionality, and 3) Slow to medium development speed. Of course, you can do anything with C++ given enough time and money.
Python/PyQt is great for 1) Small Audience, 2) Any level (including high) functionality, and 3) Medium to fast development speed.
The benefits of Python/PyQt are that:
you needn't worry too much about datatypes, header files, and numerous other headaches that slow development, and you get to work in a world-class interpreted environment known for its ability to foster fast and robust development.
you can pull in massive 3rd party libraries like matplotlib, scipy, sqlalchemy, and configobj that can make complex tasks stupidly easy.
The downsides of Python/PyQt, IMHO, are that:
it may have slower performance in some applications (who cares? How often does that really matter?)
it may be substantially harder to deploy. Py2exe requires quite a bit of tweaking to get 3rd party libraries to work, and then you still need to build an installer and get that working. Then, every time someone installs your app you might have 10 to 100MB of unnecessary dependencies built into the thing.
Personally, I work in an engineering R&D environment where fast turnaround and extensive data analysis/visualization is key, and deployment is often to only a few dozen (tech-savvy) people. Python/Pyqt is the clear choice. But, if I were to be developing a simple, widely-deployed application like a bittorrent client or something, I'd go C++ all the way.
Other notes:
PySide (a free LGPL alternative to PyQt) is rapidly progressing and seems sure to blow PyQt out of the water; I'm planning to switch within the next few months but as of now some 3rd party libraries still aren't set up for it.
The documentation for Pyside is much better than for PyQt; if you need help on, say, "QListView", just search google for "Pyside QListView".
I'd recommend only using PyQt where you need to. E.g., don't mess with QtSQL (debugging is a nightmare) when you could just use SqlAlchemy, and don't screw with Qt's configuration system when you can use the awesome library ConfigObj.
The clear way to install Python/Pyqt/etc is using the distribution Python(x,y) ... it includes, among other things: Python, PyQt, Qt, Eclipse, PyDev, QtDesigner, Spyder, iPython, and many dozens of useful scientific and computing libraries. Compiling and installing this stuff on your own is not fun.
In addition to the arguments given by rebus, I would add that the development and maintenance time in Python is considered to be about 2-10 times faster than in C++ (in papers by Prechelt and Ousterhout). This is another significant advantage of Python, that you might want to consider.
My main reasons for choosing Python and PyQt4 are:
Readability: I can't think in C++. I truthfully cannot. Python, on the other hand, is pretty close to English, so I find it easier to skim and debug.
Speed: I find that Qt4 works almost identically in both C++ and Python when you're using it for simple applications that do little work on the inside. I coded a book binding application with Python, and since it is basically a frontend to bunch of CLI tools, there is no noticeable performance lag.
Rapid Development: If you can write it in words, you can probably write it in Python. When I had to implement a new feature in my program, I just opened up the source folder (which consists of only a few files. Compare that to C++'s header mayhem), and added it in. Sure I had to tweak it to work faster later on, but my main point is that because the language is readable, it is easy to code in, and hence increases productivity.
But just to weigh both sides equally, here's what I don't like about Python and Qt4:
Example Code: Good luck trying to find some sample PyQt4 applications. The community is pretty small compared to the C++ Qt community, so don't expect tons and tons of examples.
IDE: I code with Gedit, so this was not a big issue for me, but it did take some hacking while I was designing the GUI. You have to trick Qt Designer into promoting your widgets in Python-compatible ways (like proving fake header file names so that the modules import properly), and other things like that. Nothing to serious. My regret was the inability to use Qt Creator IDE. It's basically a GUI designer on steroids, but it looks nice and is like Visual Studio for Qt.
Speed: If your application does some serious heavy lifting, I'd stick with C++. Python is good for algorithmic things, but for raw number-crunching power, C++ is the winner.
Deployment: To compile Python applications into binaries, you need to do some magical stuff with PyInstaller, Py2exe, and Py2App. It's a pretty painful process (for me at least), but it's the price you pay for an interpreted language. C++ just compiles and is ready to go.
I hope this helps in your decision. Good luck!
Learn C++. C++ executes faster than Python, and the fact that Qt is not native to Python will also slow things down slightly. Also, there is at this point far more 3rd party software in C/C++ than in Python. You might not need it now but down the road you might want to link to some of this.
EDIT: Looking a little harder I see that EOL is right, there is a lot of Python support for major libraries, though not for everything as lunayorn points out. Nonetheless in all these cases the Python user is reliant on bindings, which by their nature may lag the library developments and add extra possibility for bugs.
And since I don't yet have the cred to respond to others' posts, let me say here that rebus' claim that it's all programmer relative and C++ or Python can be just as fast is completely (and dangerously, where speed is important!) wrong. Python's ease of use comes at an unavoidable performance cost, see the wikipedia entries on interpreted vs. directly executed languages. I know from direct experience that Matlab, which is interpreted in the way Python is, executes line for line 2 full orders of magnitude more slowly than C++. Python and Matlab are best considered as (and in the case of Matlab at least, originally intended as) interfaces to libraries coded in languages like C or Fortran. For serious, large programs where performance matters use C++.
I have been doing object-oriented programming for a few years now, and I have not done much functional programming. I have an interest in flight simulators, and am curious about the functional programming aspect of Lisp. Flight simulators or any other real world simulator makes sense to me in an object-oriented paradigm.
Here are my questions:
Is object oriented the best way to represent a real world simulation domain?
I know that Common Lisp has CLOS (OO for lisp), but my question is really about writing a flight simulator in a functional language. So if you were going to write it in Lisp, would you choose to use CLOS or write it in a functional manner?
Does anyone have any thoughts on coding a flight simulator in lisp or any functional language?
UPDATE 11/8/12 - A similar SO question for those interested -> How does functional programming apply to simulations?
It's a common mistake to think of "Lisp" as a functional language. Really it is best thought of as a family of languages, probably, but these days when people say Lisp they usually mean Common Lisp.
Common Lisp allows functional programming, but it isn't a functional language per se. Rather it is a general purpose language. Scheme is a much smaller variant, that is more functional in orientation, and of course there are others.
As for your question is it a good choice? That really depends on your plans. Common Lisp particularly has some real strengths for this sort of thing. It's both interactive and introspective at a level you usually see in so-called scripting languages, making it very quick to develop in. At the same time its compiled and has efficient compilers, so you can expect performance in the same ballpark as other efficient compilers (with a factor of two of c is typical ime). While a large language, it has a much more consistent design than things like c++, and the metaprogramming capabilities can make very clean, easy to understand code for your particular application. If you only look at these aspects
common lisp looks amazing.
However, there are downsides. The community is small, you won't find many people to help if that's what you're looking for. While the built in library is large, you won't find as many 3rd party libraries, so you may end up writing more of it from scratch. Finally, while it's by no means a walled garden, CL doesn't have the kind of smooth integration with foreign libraries that say python does. Which doesn't mean you can't call c code, there are nice tools for this.
By they way, CLOS is about the most powerful OO system I can think of, but it is quite a different approach if you're coming from a mainstream c++/java/c#/etc. OO background (yes, they differ, but beyond single vs. multiple inh. not that much) you may find it a bit strange at first, almost turned inside out.
If you go this route, you are going to have to watch for some issues with performance of the actual rendering pipeline, if you write that yourself with CLOS. The class system has incredible runtime flexibility (i.e. updating class definitions at runtime not via monkey patching etc. but via actually changing the class and updating instances) however you pay some dispatch cost on this.
For what it's worth, I've used CL in the past for research code requiring numerical efficiency, i.e. simulations of a different sort. It works well for me. In that case I wasn't worried about using existing code -- it didn't exist, so I was writing pretty much everything from scratch anyway.
In summary, it could be a fine choice of language for this project, but not the only one. If you don't use a language with both high-level aspects and good performance (like CL has, as does OCaml, and a few others) I would definitely look at the possibility of a two level approach with a language like lua or perhaps python (lots of libs) on top of some c or c++ code doing the heavy lifting.
If you look at the game or simulator industry you find a lot of C++ plus maybe some added scripting component. There can also be tools written in other languages for scenery design or related tasks. But there is only very little Lisp used in that domain. You need to be a good hacker to get the necessary performance out of Lisp and to be able to access or write the low-level code. How do you get this knowhow? Try, fail, learn, try, fail less, learn, ... There is nothing but writing code and experimenting with it. Lisp is really useful for good software engineers or those that have the potential to be a good software engineer.
One of the main obstacles is the garbage collector. Either you have a very simple one (then you have a performance problem with random pauses) or you have a sophisticated one (then you have a problem getting it working right). Only few garbage collectors exist that would be suitable - most Lisp implementations have good GC implementations, but still those are not tuned for real-time or near real-time use. Exceptions do exist. With C++ you can forget the GC, because there usually is none.
The other alternative to automatic memory management with a garbage collector is to use no GC and manage memory 'manually'. This is used by some (even commercial) Lisp applications that need to support some real-time response (for example process control expert systems).
The nearest thing that was developed in that area was the Crash Bandicoot (and also later games) game for the Playstation I (later games were for the Playstation II) from Naughty Dog. Since they have been bought by Sony, they switched to C++ for the Playstation III. Their development environment was written in Allegro Common Lisp and it included a compiler for a Scheme (a Lisp dialect) variant. On the development system the code gets compiled and then downloaded to the Playstation during development. They had their own 3d engine (very impressive, always got excellent reviews from game magazines), incremental level loading, complex behaviour control for lots of different actors, etc. So the Playstation was really executing the Scheme code, but memory management was not done via GC (afaik). They had to develop all the technology on their own - nobody was offering Lisp-based tools - but they could, because their were excellent software developers. Since then I haven't heard of a similar project. Note that this was not just Lisp for scripting - it was Lisp all the way down.
One the Scheme side there is also a new interesting implementation called Ypsilon Scheme. It is developed for a pinball game - this could be the base for other games, too.
On the Common Lisp side, there have been Lisp applications talking to flight simulators and controlling aspects of them. There are some game libraries that are based on SDL. There are interfaces to OpenGL. There is also something like the 'Open Agent Engine'. There are also some 3d graphics applications written in Common Lisp - even some complex ones. But in the area of flight simulation there is very little prior art.
On the topic of CLOS vs. Functional Programming. Probably one would use neither. If you need to squeeze all possible performance out of a system, then CLOS already has some overheads that one might want to avoid.
Take a look at Functional Reactive Programming. There are a number of frameworks for this in Haskell (don't know about other languages), most of which are based around arrows. The basic idea is to represent relationships between time-varying values and events. So for example you would write (in Haskell arrow notation using no particular library):
velocity <- {some expression of airspeed, heading, gravity etc.}
position <- integrate <- velocity
The second line declares the relationship between position and velocity. The <- arrow operators are syntactic sugar for a bunch of library calls that tie everything together.
Then later on you might say something like:
groundLevel <- getGroundLevel <- position
altitude <- getAltitude <- position
crashed <- liftA2 (<) altitude groundLevel
to declare that if your altitude is less than the ground level at your position then you have crashed. Just as with the other variables here, "crashed" is not just a single value, its a time-varying stream of values. That is why the "liftA2" function is used to "lift" the comparison operator from simple values to streams.
IO is not a problem in this paradigm. Inputs are time varying values such as joystick X and Y, while the image on the screen is simply another time varying value. At the very top level your entire simulator is an arrow from the inputs to the outputs. Then you call a "run" function that converts the arrow into an IO action that runs the game.
If you write this in Lisp you will probably find yourself creating a bunch of macros that basically re-invent arrows, so it might be worth just finding out about arrows to start with.
I don't know anything about flight sims, and you haven't listed anything in particular they consist of, so this is mostly a guess about writing a FS in Lisp.
Why not:
Lisp excels at exploratory programming. I think that since FSs been around so long, and there are free and open-source examples, that it would not benefit as much from this type of programming.
Flight sims are mostly (I'm guessing) written in static, natively compiled languages. If you're looking for pure runtime performance, in Lisp this tends to mean type declarations and other not-so-Lispy constructs. If you don't get the performance you want with naive approaches, your optimized-Lisp might end up looking a lot like C, and Lisp isn't as good at C at writing C.
A lot of a FS, I'm guessing, is interfacing to a graphics library like OpenGL, which is written in C. Depending on how your FFI / OpenGL bindings are, this might, again, make your code look like C-in-Lisp. You might not have the big win that Lisp does in, say, a web app (which consists of generating a tree structure of plain text, which Lisp is great at).
Why:
I took a glance at the FlightGear source code, and I see a lot of structural boilerplate -- even a straight port might end up being half the size.
They use strings for keys all over the place (C++ doesn't have symbols). They use XML for semi-human-readable config files (C++ doesn't have a runtime reader). Simply switching to native Lisp constructs here could be big win for minimal effort.
Nothing looks at all complex, even the "AI". It's simply a matter of keeping everything organized, and Lisp will be great at this because it'll be a lot shorter.
But the neat thing about Lisp is that it's multi-paradigm. You can use OO for organizing the "objects", and FP for computation within each object. I say just start writing and see where it takes you.
I would first think of the nature of the simulation.
Some simulations require interaction like a flight simulator. I don't think functional programming may be a good choice for an interactive (read: CPU intensive/response-critical) applicaiton. Of course, if you have access to 8 PS3's wired together with Linux, you'll not care too much about performance.
For simulations like evolutionary/genetic programming where you set it up and let 'er rip, a functioonal lauguage may help model the problem domain better than an OO language. Not that I'm an expert in functional programming but the ease of coding recursion and the idea of lazy evaluation common in functional languages seems to me a good fit for the 'let her rip' sort of sims.
I wouldn't say functional programming lends itself particularly well to flight simulation. In general, functional languages can be very useful for writing scientific simulations, though this is a slightly specialised case. Really, you'd probably be better off with a standard imperative (preferably OOP) language like C++/C#/Java, as they would tend to have the better physics libraries as well as graphics APIs, both of which you would need to use very heavily. Also, the OOP approach might make it easier to represent your environment. Another point to consider is that (as far as I know) the popular flight simulators on the market today are written pretty much entirely in C++.
Essentially, my philosophy is that if there's no particularly good reason that you should need to use functional paradigms, then don't use a functional language (though there's nothing to stop you using functional constructs in OOP/mixed languages). I suspect you're going to have a lot less painful of a development process using the well-tested APIs for C++ and languages more commonly associated with game development (which has many commonalities with flight sim). Now, if you want to add some complex AI to the simulator, Lisp might seem like a rather more obvious choice, though even then I wouldn't at all jump for it. And finally, if you're really keen on using a functional language, I would recommend you go with one of the more general purpose ones like Python or even F# (both mixed imperative-functional languages really), as opposed to Lisp, which could end up getting rather ugly for such a project.
There are a few problems with functional languages, and that is they don't mesh well with state, but they do go well with process. So in a way it could be said they are action oriented. This means you'll be wasting your time simulating a plane, what you want to do is simulate the actions of flying a plane. Once you grim that you can probably get it to work.
Now as side point, haskell wouldn't be good IMHO, because it's too abstract for a "game", this sort of app is all about Input/Output, but Haskell is about avoiding IO, so it'll become a monad nightmare, and you'll be working against the language. Lisp is a better choice, or Lua or Javascript, they are also functional, but not purely functional, so for your case try Lisp. Anyways in any of these languages your graphics will be C or C++.
A serious issue however is there is very little documentation, and less tutorials about Functional languages and "games", of course scientific simulations is academically documented but those papers are quite dense, if you succeed maybe you could write you experiences, for others as it's a rather empty field right now
After reading this question I just wondered whether it would be a good idea to use Haskell (or other functional programming languages) in mission critical industries.
Apart from Erlang, most languages followed imperative/design-by-contract paradigms (Ada, Eiffel, C++).
But what about the functional ones?
The resulting code would be easily maintainable, stable and lots of potential bugs could be eliminated by their strict type systems at compile-time.
Or is lazy evaluation more dangerous than helpful? Are there other security drawbacks?
I think you could. The language seems well suited for such situations, assuming you trust the compiler enough to use it in mission critical situation.
Remember that in mission critical situations it is not only your code that is under scrutiny, but all other components too. That includes compiler (Haskell compiler is not among the easiest ones to code review), appropriate certified hardware that runs the software, appropriate hardware that compiles your code, hardware that bootstraps the compilation of the compiler that will compile your code, hell - even wires that connect that all to the power grid and frequency of voltage change in the socket.
If you are interested in looking at mission critical software quality, I suggest looking at NASA software quality procedures. They are very strict and formal, but well these guys throw millions of dollars in space in hope it will survive pretty rough conditions and will make it to Mars or wherever and then autonomously operate and send some nice photos of Martians back to earth.
So, there you go: Haskell is good for mission critical situations, but it'd be an expensive process to bootstrap its usage there.