121–130 of 181 posts
A small note: composition is not better than monolithism. The article makes it feel like it is but it is not. They are two perfectly valid approaches when it comes to solving problems. Often a mix of both is used. Monoliths tend to be better at solving common real life problems efficiently while composition is better suited for unexpected abstract problems. We need both. For example GNU binutils are not very "unixy",…
I did find it ironic that composition was called UNIX philosophy, when most UNIX tools are complicated functions with many options much more akin to the lisp function examples. (Of course it's the "UNIX pipes" part of the philosophy that's being alluded to, but it's still a funny twist)
I am less experienced than OP, but I got the impression the philosophical difference is that with Lisp, you are trying to abstract things with a simple language and AST code generation (macros) whereas in GHC Haskell you are trying to abstract things with a very in depth language, heavily based on mathematical ideas (see all those language extensions!).
Many of the language extensions are sugar over a simpler (implied) core of the language. Some are purely syntactic, like NumericUnderscores. Some others like GADTs are semantic, but still mostly explained in terms of mapping to this simpler language.
I think it should be stressed that most languages (except maybe bash I guess) can’t provide the kind of compositionality that Haskell does. This is because Haskell’s lazy evaluation allows these compositions to do an asymptotically appropriate amount of work. Consider this Haskell: xs = [1..20] p n = if n If a strict language were being used then the processing would be as follows: 1. drop 3 ys is [4..20] 2. When com…
This seems to imply that extensive use of composition in Haskell is a notable stylistic decision rather than an entailed effect of the fundamental design choices (first-class functions, lazy evaluation, type classes) that explicitly encourage such composition and a terse, mathematical syntax that makes the composition operation obvious. Heavy use of Composition is idiomatic in lisps, too. It’s just the syntax doesn’t…
That's just a chain of function applications.
Function composition puts the emphasis on the fact that functions are values in their own right and can be manipulated (eg with a composition operator) as objects without regard to any values they might act on.
If you want to see one Haskell equivalent of loop, https://hackage.haskell.org/package/monad-loops-0.4.3/docs/C... has got you covered.
There is a strange... kind of poetry with Haskell. It is like math on wheels, math applied to procedures, math with... time. Its appeal to me is like the appeal of math to me, not like real analysis math but abstract algebra math. The beauty, the purity of mathematics of younger days that once became lost after encountering the sad complexities of the world. Understanding every little aspect and being able to prove e…
There is a strange... kind of poetry with Haskell. It is like math on wheels, math applied to procedures, math with... time. Its appeal to me is like the appeal of math to me, not like real analysis math but abstract algebra math. The beauty, the purity of mathematics of younger days that once became lost after encountering the sad complexities of the world. Understanding every little aspect and being able to prove e…
Earlier quoted context omitted.
GHC does have special support for fusion and rewriting. See e.g. [1]. The laziness comes with the language, but turning it efficient requires a series of these rewrite rules expressed as GHC-specific metadata. [1] https://markkarpov.com/tutorial/ghc-optimization-and-fusion....
GHC is the most complicated compiler of any language (or very near to it), except perhaps Mathematica which is similar: It's an optimizer for a graph-reduction engine. It doesn't mean much to call out "special support" for any one bit of style of programming, since the language itself has nearly no concept of performance -- you just write functional code and the compiler will find the fastest runtime computation of t…
While GHC is glorious, it's still very limited in what it can do, performance wise.
You are right that languages themselves seldom have a direct concept of performance. But language features and restrictions have a big impact on achievable performance. Eg Haskell's purity-by-default means that the compiler has quite a bit of freedom when choosing how to translate something like eg the 'map' or 'filter' functions.
The equivalent in C++ gives the compiler less flexibility, because the helper function handed over at runtime might have side-effects.
Similarly, Haskell functions are still allowed one important side effect: non-determination. In a more restricted language like Agda that's not allowed. Thus giving the compiler more degrees of freedom to work with.
Or in a different direction: the query optimizers for SQL can do very impressive work, because SQL is so limited.
There's a more fundamental philisophical difference: Common Lisp promotes the use of doclines and apropos tools in order to discover and understand behaviour, with symbol names that tend to describe the function of what they represent. Haskell leans on type signatures and symbolic operators. IMHO, a pseudo-random sequence of non-word symbols tied to a type signature is of very little use. IE, something fabricated: (-…
let's try to assign some meaning to this. From the get go, you know that it's a function that turns an A into a B, and it only has the information that is derivable from `M c`.
So, yes this is gibberish. But if there's a slight modification to this:
(-*/) :: A -> M c -> c