Less Wrong is a community blog devoted to refining the art of human rationality. Please visit our About page for more information.

Comment author: loup-vaillant 15 January 2013 11:35:49AM 0 points [-]

Functional programming isn't an idiomatic approach to container manipulation, it's a paradigm that avoids mutable state and data.

I'm not sure you and jimrandomh actually disagree on that point. I mean, avoiding mutable state is bound to change your approach to container manipulation. You described the root cause, he described the surface differences.

Also,

And sure you can write functional code in C++, for example (which by the way has map, filter, fold, and so on), but you can also write OO code in C. But few people do, and for a reason: […]

jimrandomh knows that:

(The main exceptions are non-garbage-collected languages, which can't use the functional style because it interacts badly with object ownership, and Java, which lacks lambda expressions as a symptom of much bigger problems).

I personally tried functional style in C++, and did feel the pain (<algorithm> is unusable before C++11). There are ways however to limit the damage. And languages such as Python and Javascript do not discourage the functional style so much. Their libraries do.

Now sure, languages do favour a style over the other, like Ocaml vs Lua. It does let us classify them meaningfully. On the other hand, it is quite easy to go against the default. I'm pretty sure both you and jimrandomh agree with that as well.

From the look of it, you just talked past each other, while there was no real disagreement to begin with…

Comment author: siodine 15 January 2013 04:03:00PM *  2 points [-]

In light of the following comment by jim, I think we do disagree:

Please be careful about exposing programmers to ideology; it frequently turns into politics kills their minds. This piece in particular is a well-known mindkiller, and I have personally witnessed great minds acting very stupid because of it. The functional/imperative distinction is not a real one, and even if it were, it's less important to provability than languages' complexity, the quality of their type systems and the amount of stupid lurking in their dark corners.

And while I would normally interpret jim's nearest comment in this thread charitably (i.e., mostly in agreement with me), it's more reasonable to interpret in light of quoted comment.

I think he probably doesn't or didn't understand the functional paradigm. If he did, I think he would know about its usefulness in concurrent or parallel programming, and consequently know that it is not just a mind-killing ideology like US political parties, but a paradigm with real advantages and real disadvantages over other paradigms. I don't think he would have written his first comment if he really knew that. I think he's probably confusing the functional idiomatic approach/style/dialect/whatever with the functional paradigm. I mean he says "The majority of the difference between functional style and imperative style is in how you deal with collections." And remember this thread was created in reference to a comment about a textbook on functional programming (not functional "style" -- maybe he's backpedaling or charitably he means fp).

(also c++ is a non-garbage-collected language. And more importantly I don't mean to shit on jim. I'm more worried about how many people thought it was a comment worth being at the top of the comment section in a thread about course recommendations for FAI researchers. I would have been fine ignoring it otherwise)

Comment author: loup-vaillant 14 January 2013 12:11:22PM *  0 points [-]

Where did that come from? I didn't spot anything wrong in his comment, and I'm pretty knowledgeable myself (I'm no authority, but I believe my grasp of FP is quite comprehensive).

(Edit: Retracted: I now see it did came from somewhere: several comments, including the top one)

Comment author: siodine 15 January 2013 03:59:27AM 2 points [-]

Functional programming isn't an idiomatic approach to container manipulation, it's a paradigm that avoids mutable state and data. Write a GUI in Haskell using pure functions to see how different the functional approach is and what it is at its core. Or just compare a typical textbook on imperative algorithms with one on functional algorithms. Container manipulation with functions is just an idiom.

And sure you can write functional code in C++, for example (which by the way has map, filter, fold, and so on), but you can also write OO code in C. But few people do, and for a reason: the language makes it near impossible or, at the very least, undesirable for humans. That's close enough for the distinction being located in the language.

Comment author: Eliezer_Yudkowsky 12 January 2013 03:44:45PM 54 points [-]

It looks like Aaron Swartz may have willed all his money to Givewell. This... makes it even sadder, somehow, in ways I don't know how to describe.

His last Reddit comment was on /r/HPMOR.

Comment author: siodine 13 January 2013 03:48:37AM *  0 points [-]

-

Comment author: siodine 13 January 2013 03:47:37AM *  0 points [-]

-

Comment author: IlyaShpitser 11 January 2013 08:59:48AM *  3 points [-]

The causality in a functional language is far from obvious. Consider Haskell, a language that is both purely functional and lazy, and is considered somewhat of a beautiful poster child of the functional approach. Say you write a program and it has a bug -- it's not doing what it's supposed to. How would you debug it? Some alternatives:

(a) Use a debugger to step through a program until it does something it's not supposed to (this entails dealing with a causal order of evaluation of statements -- something Haskell as a lazy and functional language is explicitly hiding from you until you start a debugger).

(b) Use good ol' print statements. These will appear in a very strange order because of lazy evaluation. Again, Haskell hides the true order -- the true order has nothing to do with the way the code appears on the page. This makes it difficult to build a causal model of what's going on in your program. A causal model is what you need if you want to use print statements to debug.

(c) Intervene in a program by changing some intermediate runtime value to see what would happen to the output. As a functional language, Haskell does not allow you to change state (ignoring monads which are a very complicated beast, and at any rate would not support a straightforward value change while debugging anyways).


My claim is that causality is so central to how human beings think about complex computer programs that it is not possible to write and debug large programs written in functional style without either building a causal model of your program (something most functional language will fight with you about to the extent that they are functional), or mostly sticking to an imperative "causal" style, and only use simple functional idioms that you know work and that do not require further thinking (like map and reduce, and simple closure use). Note that even Haskell, a language committed to "wearing the hair shirt" (http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/haskellretrospective.pdf) of functional programming, has given concessions to the imperative/causal writing style by providing the "do" shorthand.

Personally, I love functional idioms, and I think functional code with heavy recursion use is often quite beautiful. But I don't think the functional approach is well suited to writing complex code precisely because it is violating a principal rule of computer science -- make things easy for the human at the expense of the machine.

Comment author: siodine 11 January 2013 04:31:13PM *  1 point [-]

Laziness can muddy the waters, but it's also optional in functional programming. People using haskell in a practical setting usually avoid it and are coming up with new language extensions to make strict evaluation the default (like in records for example).

What you're really saying is the causal link between assembly and the language is less obvious, which is certainly true as it is a very high level language. However, if we're talking about the causality of the language itself, then functional languages enforce a more transparent causal structure of the code itself.

You can be certain that a function that isn't tainted by IO in haskell, for example, isn't going to involve dozens of different causal structures. An imperative function like AnimalFactory.create("dog") could involve dozens of different dependencies (e.g. through singletons or dependency injection) making the dependency graph (and causal structure) obfuscated. This lack of transparent guarantees about state and dependencies in imperative languages makes concurrent/parallelprogramming (and even plain code) very difficult to reason about and test.

Moreover, the concessions that haskell has given way to are probably temporary. Haskell is a research language and functional solutions to problems like IO and event driven programs have been put forward but are not yet widely accepted. And even ignoring these solutions, you still have a basic paradigm where you have top level imperative style code with everything else being functional.

And while it can be more difficult to debug functional programs, they're easier to test, and they're less prone to runtime bugs. And really, the debugging problem is one of laziness and difficult to use debuggers. Debugging F# with visual studio's debugger isn't that difficult.

(Note: that when I talk about functional programming, I'm talking about a paradigm that avoids mutable state and data rather than idiomatic approaches to container manipulation)

Comment author: mapnoterritory 10 January 2013 11:33:15PM 4 points [-]

Would love to read a gwern-essay on your archiving system. I use evernote, org-mode, diigo and pocket and just can't get them streamlined into a nice workflow. If evernote adopted diigo-like highlighting and let me seamlessly edit with Emacs/org-mode that would be perfect... but alas until then I'm stuck with this mess of a kludge. Teach us master, please!

Comment author: siodine 10 January 2013 11:45:45PM *  1 point [-]

Why do you use diigo and pocket? They do the same thing. Also, with evernote's clearly you can highlight articles.

You weren't asking me, but I use diigo to manage links to online textbooks and tutorials, shopping items, book recommendations (through amazon), and my less important online article to read list. Evernote for saving all of my important read content (and I tag everything). Amazon's send to kindle extension to read longer articles (every once and a while I'll save all my clippings from my kindle to evernote). And then I maintain a personal wiki and collection of writings using markdown with evernote's import folder function in the pc software (I could also do this with a cloud service like gdrive).

Comment author: IlyaShpitser 10 January 2013 07:03:06PM *  0 points [-]

There is a functional/imperative distinction, but I don't think it's located in the language

It can be -- Haskell is purely functional, I would say early FORTRAN is purely imperative.

and Java, which lacks lambda expressions as a symptom of much bigger problems

Java has true closures (anonymous inner classes). But you don't want to use them. Or Java for that matter :).


I used to like functional programming much more when younger, before I realized the entire point of functional programming is to hide the causality of the program from the human, and the human needs the causality of the program to reason about the program and to debug. Sure, functional programs are easier for computers to handle, but human time is more precious.

Debugging non-trivial functional program projects requires the reinvention of imperative (causal) style (if you are very smart, this happens on the fly in your head, and the program still looks functional).


That this article wrote about the functional/imperative distinction in the way it did is a reminder that lesswrong is an attractor for holy war prone young people :). Keep religion out of science please!

Comment author: siodine 10 January 2013 10:03:25PM *  0 points [-]

the entire point of functional programming is to hide the causality of the program from the human

Why? I would say it's the opposite (and really the causality being clear and obvious is just a corollary of referential transparency). The difficulty of reasoning about concurrent/parallel code in an imperative language, for example, is one of the largest selling points of functional programming languages like erlang and haskell.

Comment author: jimrandomh 09 January 2013 07:02:06PM 1 point [-]

How is the distinction between functional and imperative programming languages "not a real one"? I suppose you mean that there's a continuum of language designs between purely functional and purely imperative.

Not exactly. There is a functional/imperative distinction, but I don't think it's located in the language; it's more a matter of style and dialect. The majority of the difference between functional style and imperative style is in how you deal with collections. In functional style, you use map, filter, fold and the like, mostly treat them as immutable and create new ones, and use a lot of lambda expressions to support this. In imperative style, you emulate the collection operators using control flow constructs. Most major programming languages today support both syles, and the two styles act as dialects. (The main exceptions are non-garbage-collected languages, which can't use the functional style because it interacts badly with object ownership, and Java, which lacks lambda expressions as a symptom of much bigger problems).

These styles are less different than they appear. A lot of use of mutation is illusory; it matches to a palette of a dozen or so recognizable patterns which could just as easily be written in functional form. In fact, ReSharper can automatically translate a lot of C# between these two styles, in a provably-correct fashion; and if you want to prove complicated things about programs, the infrastructure to make that sort of thing easy is part of the price of admission.

But there's a catch. Programmers who start in a functional language and avoid the imperative style don't learn the palette of limited mutations, and to them, imperative-style code is more inscrutable than to programmers who learned both styles. And while I'm much less certain of this, I think there may be an order-dependence, where programmers who learn imperative style first and then functional do better than those who learn them in reverse order. And I don't think it's possible to get to the higher skill levels without a thorough grasp of both.

Comment author: siodine 10 January 2013 09:42:04PM 3 points [-]

I don't think you understand functional programming. What background are you coming from?

Comment author: RobbBB 30 November 2012 01:24:42AM 2 points [-]

What's your objection to the violinist thought experiment? If you're a utilitarian, perhaps you don't think the waters here are very deep. It's certainly a useful way of deflating and short-circuiting certain other intuitions that block scientific and medicinal progress in much of the developed world, though.

Comment author: siodine 30 November 2012 04:07:12PM *  3 points [-]

From SEP:

Judith Thomson provided one of the most striking and effective thought experiments in the moral realm (see Thomson, 1971). Her example is aimed at a popular anti-abortion argument that goes something like this: The foetus is an innocent person with a right to life. Abortion results in the death of a foetus. Therefore, abortion is morally wrong. In her thought experiment we are asked to imagine a famous violinist falling into a coma. The society of music lovers determines from medical records that you and you alone can save the violinist's life by being hooked up to him for nine months. The music lovers break into your home while you are asleep and hook the unconscious (and unknowing, hence innocent) violinist to you. You may want to unhook him, but you are then faced with this argument put forward by the music lovers: The violinist is an innocent person with a right to life. Unhooking him will result in his death. Therefore, unhooking him is morally wrong.

However, the argument, even though it has the same structure as the anti-abortion argument, does not seem convincing in this case. You would be very generous to remain attached and in bed for nine months, but you are not morally obliged to do so.

The thought experiment depends on your intuitions or your definition of moral obligations and wrongness, but the experiment doesn't make these distinctions. It just pretends that everyone has same intuition and as such the experiment should remain analogous regardless (probably because Judith didn't think anyone else could have different intuitions), and so then you have all these other philosophers and people arguing about this minutia and adding on further qualifications and modifications to the point where that they may as well be talking about actual abortion.

Comment author: RobbBB 30 November 2012 01:49:35AM *  0 points [-]

Abstractly, bee hives produce honey. Concretely, this bee hive in front of me is producing honey. Abstractly, science is the product of professions, institutions, ect. Concretely, science is the product of people on our planet doing stuff.

It sounds like you're conflating abstract/concrete with general/particular. But a universal generalization might just be the conjunction of a lot of particulars. I prefer to think of 'abstract' as 'not spatially extended or localized.' Societies are generally considered more abstract than mental states because mental states are intuitively treated as more localized. But 'lots of mental states' is not more abstract than 'just one mental state,' in the same way that thousands of bees (or 'all the bees,' in your example) can be just as concrete as a single bee.

But when you say science is a bunch of abstractions (like I think your definitions are)

We're back at square one. I still don't see why reasoning is more abstract than professions, institutions, etc. We agree that it all reduces to human behaviors on some level. But the 'abstract vs. concrete' discussion is a complete tangent. What's relevant is whether it's useful to have separate concepts of 'the practice of science' vs. 'professional science,' the former being something even laypeople can participate in by adopting certain methodological standards. I think both concepts are useful. You seem to think that only 'professional science' is a useful concept, at least in most cases. Is that a fair summary?

This is exactly why I want to avoid defining science with abstractions. It literally does not make sense if you think of science as it is. "Scientific" imports essentialism.

Counterfactuals don't make sense if you think of things as they are? I don't think that's true in any nontrivial sense....

'Scientific' is not any more guilty of essentializing than are any of our other fuzzy, ordinary-language terms. There are salient properties associated with being a scientist; I'm suggesting that many of those clustered properties, in particular many of the ones we most care about when we promote and praise things like 'science' and 'naturalism,' can occur in isolated individuals. If you don't like calling what I'm talking about 'scientific,' then coin a different word for it; but we need some word. We need to be able to denote our exemplary decision procedures, just to win the war of ideas.

'Professional science' is not an exemplary decision procedure, any more than 'the buildings and faculty at MIT' is an exemplary decision procedure. It's just an especially effective instantiation thereof.

I can't think of any abstraction more important in making progress with something.

Maybe we're just not approaching the problem at the same levels. When I ask about what the optimal way is to define our concepts, I'm trying to define them in a way that allows us to consistently and usefully explain them (in any number of paraphrased forms) to 8th-graders, to congressmen, to literary theorists, such that we can promote the best techniques we associate with scientists, philosophers, and mathematicians. I'm imagining how we would design a scientific+philosophical+mathematical+etc. literacy pamphlet that would teach people how to win at life. It sounds like you're instead trying to think of a single sentence that summarizes what winning at life is, at its most abstract. 'Adopt a self-improving feedback cycle linking you to reality' is just a fancy way of saying 'Behave in a way that predictably makes you better and better at doing good stuff.' Which is great, but not especially contentful as yet. I only care about people understanding how winning works insofar as this understanding helps them actually win.

Comment author: siodine 30 November 2012 03:52:15PM *  0 points [-]

I prefer to think of 'abstract' as 'not spatially extended or localized.'

I prefer to think of it as anything existing at least partly in mind, and then we can say we have an abstraction of an abstraction or that something something is more abstract (something from category theory being a pure abstraction, while something like the category "dog" being less abstract because it connects with a pattern of atoms in reality). By their nature, abstractions are also universals, but things that actually exist like the bee hive in front of me aren't particulars at the concrete level. The specific bee hive in my mind that I'm imagining is a particular, or the "bee hive" that I'm seeing and interpreting into a bee hive in front of me is also a particular, but the bee hive is just a "pattern" of atoms.

Is that a fair summary?

I think that you're stuck in noun-land while I'm in verb-land, but I don't think noun-land is concrete (it's an abstraction).

What's relevant is whether it's useful to have separate concepts of 'the practice of science' vs. 'professional science,' the former being something even laypeople can participate in by adopting certain methodological standards. I think both concepts are useful. You seem to think that only 'professional science' is a useful concept, at least in most cases. Is that a fair summary?

Framing those concepts in terms of usefulness isn't helpful, I think. I'd simply say the laypeople are doing something different unless they're contributing to our body of knowledge. In which case, science as it is requires that those laypeople interact with science as it is (journals and such).

Counterfactuals don't make sense if you think of things as they are?

No, I mean thinking of someone as being scientific doesn't make sense if you think of science as it is because e.g. the sixth grader at the science fair that we all "scientific" isn't interacting with science as it is. We're taking some essential properties we pattern match in science as it is, and then we abstract them, and then we apply them by pattern matching.

I'm suggesting that many of those clustered properties, in particular many of the ones we most care about when we promote and praise things like 'science' and 'naturalism,' can occur in isolated individuals.

We can imagine an immortal human being on another planet replicating everything science has done on Earth thus far. So, yes I think it can occur in isolated individuals, but that's only because the individual has taken on everything that science is and not some like "carefully collecting empirical data, and carefully reasoning about its predictive and transparently ontological significance."

If I'm going to apply an abstraction to what I praise in science to individuals, it's not "being scientific" or "doing science", it's "working with feedback." It's what programmers do, it's what engineers do, it's what mathematicians, it's what scientists do, it's what people that effectively lose weight do, and so on. It's the kernel of thought most conducive to progress in any area.

Maybe we're just not approaching the problem at the same levels. When I ask about what the optimal way is to define our concepts, I'm trying to define them in a way that allows us to consistently ..

I think we are approaching the problem at the same level. I think I have optimally defined the concepts, and I think "behave in a way that predictably makes you better and better at doing good stuff" is what needs to be communicated and not "science: carefully collecting empirical data, and carefully reasoning about its predictive and transparently ontological significance." If we're going to add more content, then we should talk about how to effectively measure self-improvement, how to get solid feedback and so on. With that knowledge, I think a bunch of kids working together could rebuild science from the ground up.

If, in some cataclysm, all of scientific knowledge were to be destroyed, and only one sentence passed on to the next generation of creatures, what statement would contain the most information in the fewest words? I believe it is the atomic hypothesis that all things are made of atoms — little particles that move around in perpetual motion, attracting each other when they are a little distance... -- Feynman

I'd pass on how important "behave in a way that predictably makes you better and better at doing good stuff" is.

View more: Next