is functional programming at least most of what it's cracked up to be? nothing is everything it's cracked up to be, so is FP at least most of what it claims to be?
i know whats-his-face says you should learn LISP because it turns on god-mode for programming and LISP has a bunch of functional...paradigms, i guess, but functional programming seems like a lot of super-academic handjobbing and hobnobbery.
Name:
102010-06-23 12:34
Functional programming is not required for static typing and type inference.
Where did I claim that? A language supporting the functional paradigm does to require dynamic or static typing.
Taking Haskell and changing the syntax will not accomplish anything; the syntax is not what is wrong with Haskell.
Did I claim that there's something wrong with Haskell? The reason I said to make a Lisp-like syntax is to allow for easier macros, as removing the syntactic soup and just using S-Expressions allows you to do that. I'm actually not entirely sure it's such a good idea, without actually defining a macro system (will it be a macro system allowing the full power of the language? can one integrate it with haskell's purely functional style? will it be a pattern-based macro system which enforces hygiene? and such questions).
It seems to me that Lisp would be great as a high-performance language for stuff like game development if it offered static typing
You desire that types be infered and declarations be made unnecessary? This is possible to some degree, and some compilers can do it (SBCL is pretty good at this, I've had it detect typing errors in my code quite a few times, and it does assume the types it infers, providing proper optimization settings are used), but the problem is less in the compiler and more in the language. CL itself was designed to be highly dynamic, and a lot of the functions allow a wide range of arguments (for example, generic sequence types, or having all arithmetic operations work on a wide variety of numeric types (fixnum, bignum, ratio, complex, float(s), real, ... ). The language's library was designed in ways not unlike CL's generic functions to allow polymorphism.
To make static typing truly work in Lisp, you'll need to define a new language or make a subset of a current one which lends itself to static typing and type inference. I'd be interested to see further work in this domain.
However, I don't think the performance of current CL implementations is bad. I believe some of them would be quite usable for games, maybe with a bit of gc tuning. I've used CL for some complex and intensive data processing tasks, and it has performed rather well (in modern implementations). Most of the time, the real reason the code is slow isn't because it's not written in C, but it's because of poor algorithmic choices - making changes to fix such problems is usually rather easy in Lisp and can be done with little effort. Porting the code to C could give you some 1.5-3+ times the speedup, at the cost of a lot of time spent porting and debugging, the question is if the gain is really worth doing the rewriting.