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.
“Mostly functional” programming does not work
201–205 of 205 posts
Re: “Mostly functional” programming does not work
#202Earlier 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.
Re: “Mostly functional” programming does not work
#203Earlier 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.)
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
#204Earlier 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…
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
#205Earlier 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…
http://www.indeed.com/jobtrends?q=clojure%2C+haskell&l=&rela...