\documentclass[a4paper]{article}
\pagestyle{empty}
\usepackage{url}
\usepackage{multicol}
\usepackage[left=1.8cm,top=4cm,bottom=2cm,right=1.8cm,nohead,nofoot]{geometry}
\usepackage{sectsty}
\usepackage{relsize}
\allsectionsfont{\sffamily\raggedright}
\begin{document}
\begin{figure}[t]
\hspace{0.2cm}
\begin{minipage}[t]{.55\textwidth}
\flushleft
\Huge\textbf{Haskell Weekly News}
\end{minipage}
\hfill
\raisebox{0.4cm}{
\begin{minipage}[t]{.40\textwidth}
\flushright
Issue 69, February 10, 2008\\
\url{http://sequence.complete.org/}
\end{minipage}
}
\hspace{0.5cm}
\hrule
\vspace{0.5cm}
\end{figure}
\setlength{\columnsep}{0.5cm}
\setlength{\multicolsep}{1cm}
\begin{multicols}{2}
\setcounter{unbalance}{3}
\raggedcolumns
\bigskip
\hrule
\section*{Quotes}
\begin{itemize}
\item \emph{Peter} I hardly know Haskell, but I can already write some code much faster and easier than I could do in C/C++ (and I've been programming 2 decades in that language)
\item \emph{Miguel Mitrofanov} Since NaN /= NaN, I think, we should decipher 'NaN' as 'Not a NaN'
\item \emph{Achim Schneider} The essence of non-strictness, though, is another kind of story. Like a golem plowing half of the country until you remember that you placed him a bit absent-mindedly into your backyard and said 'plow', that still won't plow mountains.  The essence of strictness is easy, though: get stuck on a stone, fall over and continue moving until you break.
\item \emph{monochrom} OCaml tells you 'map f xs is bad because it takes O(n) space'. Haskell tells you 'map f xs' is good because it takes O(1) space
\item \emph{ddarius} It says *right on the box* that it it's intended for *both* research and applications.
\item \emph{Clifford Beshers} Why Haskell? Medical researchers announced today that MRI studies reveal that the structure of the human brain is significantly different in adolescence than adulthood.
\item \emph{Larry O'Brien} I really had a hard time refactoring my Ruby into a packrat parser. This was due, in no small part, because of the difficulty in understanding the types being built-up in the data structure. The paper, in explicitly-typed Haskell: clear as a bell. My code's behavior on unit tests: virtually indistinguishable from random.
\item \emph{SuperGrade} Haskell kind of herds you into functional programming. There are advantages to this manner of coding, and I'm getting to thinking you should attempt code this way almost all of the time, regardless of language.
\item \emph{Berlin Brown} Haskell is readable, fast, and expressive. I like it.
\item \emph{Yaakov Nemoy} Changing the type of a function in Python will lead to strange runtime errors that take some work to debug, whereas, when I tinker with a program in Haskell, I already know it will work once it compiles.
\item \emph{Michael Reid}  Learning Haskell has completely reversed my feeling that static typing is an old outdated idea. The power of Haskell's type system makes it feel like you are programming in a dynamic language to some degree, yet all of it is type-checked, and that is just *really* cool.
\item \emph{weavejester} I've come across many parser generators that are a dream to work with in comparison to lex and yacc. The best one I've found so far is Haskell's Parsec.
\item \emph{David Roundy} What's the good of having a haskell-programming computational linguist on board if we can't get static compile-time guarantees of grammatical correctness?
\item \emph{Bulat Ziganshin} When FP just pass all the functions and data required for specialization of generic algorithm, OOP provides interfaces, virtual functions, anonymous classes, delegates and lots of other interesting ways to hide the fact of lack of first-class functions :)
\item \emph{[Douglas] Adams} was interested in computing --- I think his reaction to being told about functional programming was to wonder what non-functional programming might be.
\item \emph{ezekiel} I find Haskell to be like Lisp and APL and Python all put together in a way that leads me quickly to a solid result. Other languages work, but the road to the result is bumpier.
\item \emph{AlanYx} I've found that Haskell's uber-strong, static type system does help me be productive, because it increases the class of bugs that can be found at compile time, forces thinking at a higher level, and can help avoid edits to existing code breaking things elsewhere in the code
\item \emph{anonymous} Closures in today's world are a 'language geek' feature. Unless done extremely carefully and in a way that supports the various skill levels of developers, they end up being unusable and unsupportable by anything less than computer language savants. In their inherent obscurity and complexity, 'language geek' style closures are about as anti-Java as you can get.
\item \emph{anonymous} I work in a Smalltalk shop, where we extend and maintain an application that has been around over a decade. During the maintenance part of our job, it would be really nice to have type declarations on variables. For maintenance, the more dependable information we have, the better! The fewer things that can escape as runtime exceptions, the better!  
\item \emph{consultant barbie} Languages are hard. Let's write web frameworks and go shopping!
\end{itemize}
\end{multicols}
\vspace*{\fill}
\hrule
\hspace{0.5cm}
\flushleft
\begin{minipage}[t]{\textwidth}
\flushleft
\textbf{Choose higher order, polymorphic and purely functional. Choose Haskell.} \\
\url{http://haskell.org/} \\
\end{minipage}
\end{document}