// μ = m // dayvan cowboy // music is math

The debate about adding closures to Java has spawned a curious debate about the role of explicit loops, recursion and higher-order list combinators. I wonder why no one has stepped up in defense of GOTO yet.

Misguided Java snob Elliot Harold harangues fist and teeth against progress in computer languages:

I don’t know what it is some people have against for loops that they’re so eager to get rid of them. This isn’t the first or even the second time CS theorists have revolted against for loops (or equivalent).

This isn’t even the most proeminent below-the-belt jab at new expressive techniques. Take blog blog journal spot.com/2007/02/whats-wrong-with-for-loop.html”>oh, but wait, the traditional Bird-Merteens/Standard Prelude functions are kinda expressive too, you know. Which is fine and quite useful for bystanders trying to evaluate this debate on merit alone. I myself should repackage the section in this blog blog journal spot.com/2007/02/whats-wrong-with-for-loop.html”>oh, but wait, the traditional Bird-Merteens/Standard Prelude functions are kinda expressive too, you know. Which is fine and quite useful for bystanders trying to evaluate this debate on merit alone. I myself should repackage the section in this Reddit, which is where I get my daily dose of blog journal — functional programming is frankly on the rise. Part of it probably is due to OOP’s failure to materalize its promise of easy-to-maintain, flexible, reusable code. Part of it is also the rise of FP-centered languages around relatively recent developments in theoretical computer science — like the MLs and Haskell, a little further away from academia, Erlang. There’s finally the visible hand of Moore’s Law making high-level languages ever more practical.

Also judging from the blog blog journal s there’s a distinct zeitgeist of rejecting “static” languages in favor of “dynamic” ones. This is partly an artifact of fast computers finally making serious work in dynamic languages feasible, but also a rejection of the Big Architecture discipline of the C ++/Java weltanschauung.

Being as easy as it is to make noise with a blog blog journal , this has led to a lot of uninformed ranting. Even Steve Yegge, who’s supposed to be a smart programmer with a track record that shames mine, has done his share of pointless rambling on how “static” languages compile to ‘hardware’, to ‘Pinocchio’-like wooden boys that aren’t “real”, while dynamic languages yield “living” software somehow.

This, of course, makes absolutely no sense.

The Either/Or approach to classifying computer languages

First of all, this dichotomy mixes up type-checking strategies with evaluation models. Dynamically-typed languages check types at runtime, while statically-typed languages do some form of type-checking that ensures no type error will arise once a program manages to compile. On the other hand, statically-compiled languages yield an executable that does what it needs to do, while dynamic languages are either interpreted — that is, require a separate runtime environment that parses source in text form — or allow some form of pseudocompiling that mangles source into some form of object code and bundle a runtime environment.

Abstract for Haskellers:

This is a long, involved defense of purity, both in terms of what it affords us in terms of power and in how it enforces “good” programming practices.

Haskell is often defined in terms of what it cannot do: variables can’t be changed once declared, the results of IO computations can’t directly be used in functions, execution flow can’t be controlled, etc. While this characterization is strictly correct, it paints a rather ascetic, when not outright negative, outlook of the language that practitioners not only know to be misleading, but also to be the key to the great power latent in functional programming.

We discuss how and why certain “restrictive” features have become succesful in computer programming while others haven’t, and procceed to explain referential transparency and what it affords us. Finally, we conclude that adopting this particular set of “restrictive” features is useful and positive, even in contrast with the experience of non-useful “restrictions” that seem to have common characteristics.

Abstract for non-Haskellers:

This essay explains why Haskell is cool.

<

p>

{1 word, estimated 0 secs reading time}