You're looking at Less Wrong's discussion board. This includes all posts, including those that haven't been promoted to the front page yet. For more information, see About Less Wrong.

fiddlemath comments on Course recommendations for Friendliness researchers - Less Wrong Discussion

62 Post author: Louie 09 January 2013 02:33PM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Comments (113)

You are viewing a single comment's thread. Show more comments above.

Comment author: fiddlemath 09 January 2013 07:13:45PM 8 points [-]

How is the distinction between functional and imperative programming languages "not a real one"?

"Not a real one" is sort of glib. Still, I think Jim's point stands.

The two words "functional" and "imperative" do mean different things. The problem is that, if you want to give a clean definition of either, you wind up talking about the "cultures" and "mindsets" of the programmers that use and design them, rather than actual features of the language. Which starts making sense, really, when you note "functional vs. imperative" is a perennial holy war, and that these terms have become the labels for sides in that war, rather than precise technical positions.

I mean, I am somewhat partisan in that war, and rather agree that, e.g., we should point new programmers to Scheme rather than Python or Java. But presenting "functional" vs. "imperative" as the major division in thinking about programming languages is epistemically dirty, when there's so many distinctions between languages that matter just as much, and describe things more precisely.

(Jim: fair rephrasing?)

Comment author: loup-vaillant 14 January 2013 12:01:29PM *  2 points [-]

I've wrote about the difference between imperative programs and functional ones (here, trying to explain why an imperative programmer might find functional programming difficult).

The main differences (do vs be, reversed order of reading, and heavy use of first class functions), make a quite sharp divide. Way sharper than other divides, such as "Object Oriented" versus the rest (though Alan Kay's original vision is probably more distinguishable than the current C++/Java vision).

Now when talking about programming an FAI, the most probable course of action will be to translate the math of FAI into a program. One thing I noticed about math formalism outside the specific field of computer programming, is that most formulations are either stateless, or explicit about state. When at some point we say X = some long expression, we know it won't change until the end of the assignment. The math I know tend to be functional by default.