Evan Laforge wrote:
Java's just wordy like that. In python you'd say max(foos, key=lambda x: x.update_time).
While this is true, I was also thinking of the typical audience SPJ specified: senior technical people and managers. Most of these people have heard of Python and Ruby, but see them as "scripting" languages that are not suitable for Real Work. Most of the ones I have met seem to regard a static type system and compilation to native code as prerequisites for "real" programming languages (although Java has greatly weakened the second prejudice). More importantly, these people have not read "Beating the Averages". They see the programming language market as a Keynsian Beauty Contest, in which the judges get rewarded for voting for the most popular candidate. Therefore the trick to winning the contest is not persuading the judges that you are the most beautiful, but that you are the one that most of the other judges are going to vote for. Paradoxically this is best done by emphasising your similarity with what they already know. The message is "I'm just like her, only better". In the case of Haskell ways to do this would include: * Outline (single Powerpoint slide) a mapping between UML class diagrams and Haskell data and class types. Mention that Haskell classes and data types correspond roughly to Java interface and implementation classes respectively. * Emphasise that Haskell *is* statically type checked, its just that type inference means you don't have to declare the type of every single thing. Repeat this point three or four times during the talk to make sure it sticks. * Mention the covariance type hole in Java and say that Haskell doesn't have it. In Haskell "static type system" means what it says. * Hackage does what Doxygen and Javadoc do. The ones who know about automatic documentation will get a warm fuzzy feeling. The ones who don't will find it interesting. Also mention Hunit. Mention QuickCheck in passing, but don't dwell on it because its not what they know. * Mention that there is an Eclipse plug-in for Haskell. * Talk at length about the Haskell library and package mechanisms. Large projects often have multi-version configuration management issues, so talk about how library versions can be selected at compile time by a configuration file. * Talk about the FFI interface. Most of these people have big important monoliths of legacy code that they don't like to talk about in public. * Trying to dereference "null" is a significant source of bugs, so explain that null references are impossible in Haskell. If you have "x :: Foo" then "x" can never be null; it *has* to refer to a Foo object. If we want a possible null value then we say "Maybe Foo" to signal this, and type safety means you have to account for possible "Nothing" values. * Say "computers are cheap but programmers are expensive" whenever explaining a correctness or productivity feature. The best way to demonstrate the innate productivity improvement in Haskell is using numbers. Haskell projects to re-implement existing code routinely report 4-fold or better code reduction. The 1993 paper on Ada vs Awk vs C++ vs Haskell... is still good ammunition, as are the GetOpts implementations in C and Haskell. A lot of this is to demonstrate that the normal development infrastructure is actually available. This is another thing that these people expect to see in a "real" language. Its not that this is important for productivity, its just stuff you have to have to be considered a "real" language. Maybe I should write a "Real Programming Languages Eat Lots of Quiche" piece. Paul.