One who advocates FunctionalProgrammingLanguages above their imperative cousins. Unlike the weenies of LispLanguage and SmalltalkLanguage, the FunctionalWeenie doesn't get the label "smug", as they are advocating a technology still being actively researched, rather than one which elegantly solved all the world's problems twenty years ago and is slowly being integrated into mainstream technologies (which are arguably still of lesser quality) ex post facto. In other words, the FunctionalWeenie is not in a position to say "I told you so!"
At least not yet.
Note that FunctionalWeenies are not a superset of SmugLispWeenies (though the two overlap), as many of the latter gloss over (or ignore) the purely-functional aspects of LispLanguage. Most Lispers happily indulge in unclean things such as side effects, for instance. Also, FunctionalWeenies often go agog over TypeInference and the like--an issue sidestepped completely in a dynamically-typed language like Lisp.
Attributes of the FunctionalWeenie:
- Think that constructing the natural numbers (and other algebraic sets) is a useful exercise for practicing programmers working on deadlines.
- Have spent man-years researching (and advocating) mind-warping contortions such as monads, just to avoid typing an assignment statement. When that fails, would prefer to make a copy of the world rather than mutating it in some fashion. (After all, the GarbageCollector can always throw away the old world when you're done with it...)
- Are proud of languages which feature complicated TypeInference schemes--but have different operators for integer and floating-point arithmetic. (Like PythonLanguage, for example? :) (Dude, this is an obvious reference to OCAML, where + is for ints, and +. is for floats)
- Can't write a paragraph without use of the word "lambda" at least once.
- Will go through loops to avoid writing loops.
- Have come together as a community to specify a language whose syntax makes Perl look like pseudocode. And that language would be... HaskellLanguage. YourMileageMayVary, of course
- Know what the BottomType is. Extra points if you've ever written a function that returns Bot (often spelled _|_ just to confuse the imperative unwashed)--despite the fact that according to type theory the BottomType is empty (no instances of it exist).
- Is that really so confusing? I mean, there's an easy mnemonic: just think of it in parentheses. (Anyone who doesn't get this one is invited to open up a text file and try it out now.)
- Don't think of Indian food when someone says "curry".
- Don't think of religion when someone says "church". <-- This is false, the ideas of Alonzo Church are the religion of any true functional weenie ;)
- Consider multi-argument functions to be an abomination. Nope, just a special case of a function that takes a tuple as the argument. :). Nah. A true FunctionalWeenie uses CurryingSchonfinkelling, rather than CartesianProduct, to handle multiple argument function. Addition is really a HigherOrderFunction, after all... Of course, but "true" multi-argument functions are a special case of functions that take tuples as argument. Curried functions are better (more powerful) in a number of cases...
- Routinely put down other functional languages for being impure or unsafe, preferring whichever language is the most unsuitable for actual programming.
- Insist that any program which passes the type-checker is correct. If an incorrect program does pass through the type-checker, then the type system isn't good enough.
- This despite the fact that demonstrating the absence of many bugs, such as DivisionByZero?, is impossible
- Not so fast! It wouldn't be at all impossible to make a type that can carry any number -except- zero, then define division as taking a number and a 'not-zero-number' to produce another number. Allow this to percolate through the code... it will enforce checks to avoid zero prior to division where it cannot be proven. The fact that current type-systems don't allow you to prevent division-by-zero is proof that they aren't good enough... (heh heh)
I'd like to hear more about this one argument thing, anybody have some good links?
Fast search on google gave this: http://www.cs.hmc.edu/courses/2002/fall/cs80/sml/lecture03.html (scroll down to the "more than one parameter" part).
Usually, Haskell / Ocaml programmers tend to prefer curried style, SML programmers tuple style. Both are isomorphisms of true multiple argument functions; isomorphisms such that they only need one-argument functions for their semantics; OccamsRazor in practice. To confuse things more, let's note that under category theory the isomorphism between tuple and curried functions is equivalent to the logical claim,
(a and b => c) <=> (a => (b => c))
And you're really a
FunctionalWeenie if you have ever:
See GreatLispWar
CategoryWhimsy CategoryFunctionalProgramming CategoryWeenie
Functional Weenie