4 ms·

You seem to think there's this thing called the "functional denotation" that functional programmers really care about. I've never heard that term before. Goog

• pron 9y ago
  > You seem to think there's this thing called the "functional denotation" that functional programmers really care about. I've never heard that term before. Oh, but that's because FP fans call it "referential transparency"; I'm sure you've come across that term. While the terminology is incorrect (for one, Java is also referentially transparent), when FP fans say "referential transparency", they mean "value semantics", i.e., that the meaning of a function application is its normal form, or, in other words, they simply mean "functional denotation". This is exactly what enables the equational reasoning FP fans like to talk about. > I see no reason the sorts of analysis you give in your Java examples couldn't equally be applied to functional programs They could (I know it's possible to write assertions in Haskell), but then they no longer operate on the denotation of the language. You can also use unsafePerformIO in Haskell, but if you do that, you may break the mental model the language aims to create. > not least because functional programs can be trivially rewritten as imperative ones (see CBPV). Again, they could, but not in a way that preserves the benefits for which the formalism was designed for. Similarly, pure functional programs could be written in Java, but that's not the idiomatic way. To take us back to where we started, we are talking about language design, and while many languages can imitate the style of others, they are optimized for certain pragmatic and aesthetic concerns. That is my whole point.
  • tome 9y ago
    > To take us back to where we started, we are talking about language design, and while many languages can imitate the style of others, they are optimized for certain pragmatic and aesthetic concerns. That is my whole point. If that were your whole point we could have avoided this thread. No one disputes that. In fact your point seems to be that Java/imperative languages are better than Haskell/functional languages, for a reason that you have tried to elaborate and that I have failed to understand.
    • pron 9y ago
      > In fact your point seems to be that Java/imperative languages are better than Haskell/functional languages, for a reason that you have tried to elaborate and that I have failed to understand. Not at all. My point is that the reason for preferring a formalism is largely aesthetic and pragmatic, and almost never mathematical or universal. Indeed, one pragmatic reason to prefer classical imperative programming is that in many cases, it makes formal reasoning easier, something that comes as a surprise to those familiar with the math of FP but not of imperative (you don't have to take my word for it; here are Xavier Leroy and Simon Peyton Jones saying that: http://homepages.inf.ed.ac.uk/stg/Milner2012/Monday_Panel-html5-mp4.html http://homepages.inf.ed.ac.uk/stg/Milner2012/Monday_Panel-ht...). But if you knew me you'd know that I don't care much for programming languages at all, partly because personally I don't feel much of a difference and partly because the empirical evidence so far show that there is little if any practical difference between them (at least modern ones). So I resist any attempt (by lmm this time) to claim that functional languages are "better designed" because of one or other of their properties. They are not, but they may be languages that lmm or you find aesthetically appealing, and more productive because they match how you like to think about programs. I'm skeptical of all languages, but I am at least hopeful of languages that haven't yet had the chance of proving themselves, which is why I'm curious about Eve, the most theoretically-advanced language that I know of, and one whose semantics I personally find appealing (actually, some of the ideas behind Eve have proven themselves quite spectacularly in realtime, which is why I'm even more hopeful).