Functional programming and the new black
Functional Programming have been all over the media (well at least the part that addresses programmers) the last year or so. Although I have not programmed in any functional language (as of yet), I still have an opinion about it (and why Dawn is not functional based).
As far as I know (and feel free to correct me), functional style programming can be done in most dynamic languages by observing a few key principles, but dynamic cannot be done in a functional language. In my book that means that dynamic languages is more general than functional languages; that functional practices are a limitation of the expressiveness (sounds like a bad thing formulated like this - but Im not saying that its a bad thing); that functional is in fact a convention or a DSL if you like. And as far as conventions goes I try to keep them out of Dawn, but welcome them as a specialization of its use.
My design purpose is to be general, general and general. That’s why the only general error handling I have discovered is timeout, that’s why generics, templates and concepts are replaced by the identifier override functionality; that’s why functions are objects with a single output - because all the other things are specializations and I want more generalizations.
I’m on the hopeless quest of the single programming language for all purposes, doomed to fail, but hoping to get a better result because of reaching for the stars (just hoping that I’m no Ikaros).
"Everybody's talkin' 'bout the new sound. Funny, but it's still rock and roll to me"
Billy Joel
As far as I know (and feel free to correct me), functional style programming can be done in most dynamic languages by observing a few key principles, but dynamic cannot be done in a functional language. In my book that means that dynamic languages is more general than functional languages; that functional practices are a limitation of the expressiveness (sounds like a bad thing formulated like this - but Im not saying that its a bad thing); that functional is in fact a convention or a DSL if you like. And as far as conventions goes I try to keep them out of Dawn, but welcome them as a specialization of its use.
My design purpose is to be general, general and general. That’s why the only general error handling I have discovered is timeout, that’s why generics, templates and concepts are replaced by the identifier override functionality; that’s why functions are objects with a single output - because all the other things are specializations and I want more generalizations.
I’m on the hopeless quest of the single programming language for all purposes, doomed to fail, but hoping to get a better result because of reaching for the stars (just hoping that I’m no Ikaros).
"Everybody's talkin' 'bout the new sound. Funny, but it's still rock and roll to me"
Billy Joel
posted by phook at
5:54 AM
3 Comments:
This post's discussion of "functional-vs-dynamic" puzzles me a bit. I am used to seeing "dynamic" contrasted with "static", contrasting run-time (or no) typing with compile-time typing. Similarly, "functional" is often contrasted with "imperative" to emphasize the difference between composing functions and dependence on mutable state.
If by "dynamic" you mean "dynamically typed languages that support an imperative programming style" and by "functional" you mean "languages that support a pure functional programming style", then neither is more general than the other.
Let's use Perl as an example of a "dynamic" language, and Haskell as an example of a functional language (in the sense above). Pugs (http://en.wikipedia.org/wiki/Pugs) is a compiler and interpreter for Perl 6 written in Haskell, which demonstrates that it is possible to support a dynamically-typed, imperative language with a strongly, statically-typed functional language.
This post has been removed by the author.
You are right, of course, I am talking about something I know not-so-much about, namely functional programming. I was under the impression tha functional languages by default were type strong, but have no basis for that assumption.
But using the compiler/interpreter argument I dont buy, since Turing completeness, which they all are, allows for cross implementations.
My argument is weak, yes, but let me try to reiterate, dynamically typed imperative algorithms will be "hard" to implement in statically typed languages, whereas the functional algorithms is comparatively easier to implement reversely, well, that is my impression at least. Again I will say that i'm not saying "better" or "worse" - Im talking about "general", but I still may be blatantly wrong.
Post a Comment
<< Home