Live data from Hacker News

“Mostly functional” programming does not work

queue.acm.org

201–205 of 205 posts

Re: “Mostly functional” programming does not work

#201

Earlier quoted context omitted.

You asked some questions, I answered them in an attempt to be helpful. Any conclusions you draw about my personal beliefs are spurious and roughly as well founded as your conclusions generally. For what it's worth, I write a bunch of C and I like C very much. I also like Haskell and have to say you really don't know what you're talking about here. I'm not interested in dealing further with these kinds of ramblings, a…

> my personal beliefs Your and the haskell community's puritan behavior . > you really don't know what you're talking about here. Can't Parsec English ? I define the word hypocrisy, from a dictionary no less.

This is nothing but trolling. I wasn't disputing your definition; but you weren't including it as merely an informative point on a random English word. By the pragmatics of English conversation, it was clearly meant as an accusation in this context. Your retreat to defense of the definition, as opposed to any notion of the applicability of the definition or of anything else you've said, is disingenuous. In any event, at this point I am done responding in this thread, whatever else is posted.

Re: “Mostly functional” programming does not work

#202

Earlier quoted context omitted.

He isn't confusing the terms, he's just using the correct one. Functional programming is about programming with functions - "Purely functional" is redundant. It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects. Languages which don't use functions are not functional - they would be best desc…

I disagree that '"Purely functional" is redundant'. You can have a functional language that still uses mutable state. Lisps are a good example. Pure functional implies no mutable state. Pure functional is the only way to safely achieve laziness. Which seems to be the author's thesis.

Well, from the parent poster's position, Lisps would not be "functional" - they'd be "pseudo" or "mostly" functional or something. Obviously this disagrees with common usage, but the expressed motivation "mutation disagrees with 'function' in mathematics" isn't crazy. I do think it's insufficient, however, in the face of common usage given that we've collectively chosen that "purely functional" should mean that.

Re: “Mostly functional” programming does not work

#203
post #163
post #50

Earlier quoted context omitted.

And it's important to note with Scala, a big part of its complexity comes from the practical philosophy of its creators: purity is sacrificed in order to actually make it work on the JVM the way we want it to . I used to work with Java on the server-side, but I'm programming almost entirely in Scala now (I'm at a small shop where I was lucky enough to convince the boss to let me give it a go on a project last year) a…

How do you manage nesting from callbacks and matches and such? Inlining short functions like _ + _ is fine, but how do you organize more advanced operations? (I'm just constantly looking for ways to make my scala code more accessible.)

I am indeed referring to for-comprehensions. Any time you have nested flatMap/maps you can replace it with a for, since that's all a for-comprehension really is...

  computation1.flatMap { result1 =>
    computation2.flatMap { result2 =>
      computation3.map { result3 =>
        result2 + result3
      }
    }
  }
Becomes...

  val foobar = for {
    result1 
Or, since I'm using the async Postgres module which returns Futures, to make them run in parallel you need to create the futures beforehand. I often have something like this...

  val fProject = Project.findById(projectId)
  val fTask = Task.findById(taskId)

  for {
    projectOption  Student.findByProject(projectId)
      case None => Future.successful(IndexedSeq[Student]())
    }

    result  { 
        /* do something with project, task and students */ 
      }
      case (None, _) => Future.successful(NotFound(s"Project $projectId not found"))
      case (_, None) => Future.successful(NotFound(s"Task $taskId not found"))
    }
  }
  yield result
By creating the futures first, they both run in parallel and their results are 'collected' by the for comprehension. In the first example, the computations necessarily run in sequence.

I'm using Play framework, for me, these for comprehensions are usually found in my controllers and the final result is an HTTP result.

Passing along failure can still be tricky but I find this much more organized than nesting callbacks.

Re: “Mostly functional” programming does not work

#204

Earlier quoted context omitted.

If code is structured or not is not really a property of a language, every function call is effectively a "goto" although with more convenient syntax. If your functions are partitioned in a strange way, you can just as easily produce spaghetti code. Same with nested if statements. You can write well structured code in Fortran 77 for example, even though most standard control structures involve a goto. Absence of a go…

There is an entire class of compiler optimizations that can only be done on structured languages. If you include a "goto" command in a language you must either do a huge amount of statical analysis to map your language into a structured one, or live without such optimizations. The fact that some code do not use a feature of the language does not help the computer generating a faster program. Also, no, function calls…

Compiler IL reduces all branches to the equivalent of "goto", so adding a few more is just no problem at all.

More important obstacles to optimization include use of exceptions (now that makes control flow complicated), memory aliasing (any write to a char * is a scheduling barrier), overly-defined int math (can't prove loop iteration count), and the fact that your compiler has no idea what the hell is going on inside an x86 chip anyway.

Re: “Mostly functional” programming does not work

#205
post #127

Earlier quoted context omitted.

I agree. Part of the reason Clojure sees production use and Haskell does not leave its academic closet very often is that the former makes interaction with the non-functional parts of a system painless.

I don't regularly use either one, but I was under the impression that the situation is rather the reverse: Clojure is quite popular among hobbyists but doesn't get a lot of serious industry usage (perhaps excepting some stuff in the web space, which I don't really follow), while Haskell has a bunch of industry users. I see ads for Haskell jobs pretty often, anyway, while I'm not sure I've ever seen a Clojure job ad o…

This shows Clojure outpacing Haskell since 2012:

http://www.indeed.com/jobtrends?q=clojure%2C+haskell&l=&rela...

Post reply on HN