51–60 of 205 posts
I disagree, because the entire article rests on the premise that imperative programs are bad because they rely on shared mutable state. Here's the thing, though: every complex-enough program relies on shared mutable state; even Haskell programs[1]. Pure functional code just might outsource shared mutable state to an external database. The solution, then, is not doing away with shared mutable state, as that's downrigh…
The average programmer would [...] because that's the way the program was written, as evidenced by the semicolon between the two statements. Seriously? I don't even know C# and the "var q0" was enough to suggest the type of whatever Where returns is not an array of int (as opposed to the two functions above, with int and bool types), so why would I expect it to have filtered the array and returned it? Ditto for the 2…
Going to any extreme makes some things horribly difficult and going to another does the same for other things. So, optimally, multiple paradigms coexist in the single codebase, applied where they're most useful.
Functional programming with as many immutable bits as possible is definitely a good start. I generally do that for whatever problem I'm solving: I have a model for the data and then I write (if at all possible) pure functions to transform the inputs into meaningful outputs. But then you need know where to drop the ball and move over to some other paradigm that does something else right and merely drives the functional parts from the top level.
For example, such a data analysis library can be written with minimal state and using only pure functions but if -- and when -- you need some sort of an user interface so that the program can actually be used, an imperative/procedural approach is generally the most native approach because UIs are basically I/O. If you're adding a graphical user interface, you might use object oriented approach to build the UI tree which is probably the world's most idiomatic, canonical use for OO anyway. But even those are generally driven with an innately imperative event loop.
Also, note that the different approaches or paradigms aren't language specific either.
In the first stage, languages are tools that shape your thinking into accepting new programming paradigms but at some point you have a number of different ways of thinking in your head, and you can just forget about the languages they came from.
But in the second stage, you can just think directly in paradigms: you can consider different ways to build different parts of your program but you might actually use only one language to implement everything. You can write functional, imperative, object-oriented, and whatever code in C. Or you can use several languages with strengths in each paradigm, depending on what trade-offs produce the best engineering in each case.
I disagree, because the entire article rests on the premise that imperative programs are bad because they rely on shared mutable state. Here's the thing, though: every complex-enough program relies on shared mutable state; even Haskell programs[1]. Pure functional code just might outsource shared mutable state to an external database. The solution, then, is not doing away with shared mutable state, as that's downrigh…
Is there any reference for transactional semantics?
What do I mean by isolation of mutation? As stated above, all applications end up needing global shared mutable state (usually it lives in databases, but doesn't have to). So Rich Hickey created mechanisms to do such things safely and concisely.
The software engineering world is in danger of repeating the mistake it made with objects two decades ago. Back then there were legacy "structured" languages like C and Ada, and new exciting "object oriented" languages like Smalltalk and Eiffel. C++ was promoted as a "middle way" that let you "choose the best tool for the job". This made the pure OO languages look extremist. So, it was argued, if you had a problem be…
And just what makes you think making a purely functional language 'lambdacious' will not a few years later result in a book 'Industrial strength lambdacious'? You're falling for the trap of thinking that pursuing a theoretically pure discipline will result in a language with less flaws; in reality, even theoretically pure concepts have issues and can be superior and inferior to other theoretical concepts/constructs […
Yes, people use languages with solid theoretical foundations less because they perceive them to be extreme. That was my point.
Quote: "I can't imagine [... any measure that] makes these 'purity-oriented' languages appear to "work better in practice".
How about SLOC required to implement a task? Take a look at this: http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf Its an old paper, but the findings are still perfectly valid.
Quote: "each process is like an object, holding onto state".
This is the actor model. Erlang is an uncompromisingly pure implementation of the actor model, which is why it is so effective. Again, I think you are making my case for me.
Your use of the term "sacrificing flexibility" sets up a false dichotomy between purity and flexibility, as though there were programs that are difficult to write in Haskell.
Earlier quoted context omitted.
How about Clojure, which is a Lisp-like language with objects? Explicitly, you have protocols and multimethods; implicitly, almost everything under the hood is done with Java interfaces (and you can make new first-class datatypes by implementing the interfaces, though this is mildly discouraged). I cannot recall anyone complaining about the OO clashing with the functional patterns. There's also O'Haskell, and in regu…
I'm an experienced Clojure user with work done on the job and in open source. If you're a Clojure user, it's very likely you've used a library I've worked on or made. Don't bother. Go straight to Haskell and just Haskell. No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time. Hybridized approaches are l…
Earlier quoted context omitted.
Is there any reference for transactional semantics?
I would strongly look at Clojure's implementation of Atoms, Agents and Refs. IMO that is the best isolation of mutation I've seen in any language. What do I mean by isolation of mutation? As stated above, all applications end up needing global shared mutable state (usually it lives in databases, but doesn't have to). So Rich Hickey created mechanisms to do such things safely and concisely.
I absolutely agree that if you buy into Lazy programming, you have to buy into entirely Pure Functional as well.
However, many languages and frameworks have demonstrated a high degree of success mixing in functional paradigms (mostly centered around collections)
I would like to refer people to the concept of Collection Oriented Programming. In this paradigm, application specify most of there operations as mapping and reducing functions across different collections (trees, vectors, lists, etc). Not only does it promote safety, but it works in such high level constructs, it allows the compiler/interpreter to optimize the operation in many ways, such as optimizing out the lambda calls, and even parallelizing the operations.
To name a few Language+Libraries for which this is hugely successful: Ruby, Clojure, C++11 w/ std::algorithm, Scala, and Haskell, of course.
I disagree, because the entire article rests on the premise that imperative programs are bad because they rely on shared mutable state. Here's the thing, though: every complex-enough program relies on shared mutable state; even Haskell programs[1]. Pure functional code just might outsource shared mutable state to an external database. The solution, then, is not doing away with shared mutable state, as that's downrigh…
There's an important distinction between essential side-effects and inessential side-effects.
Some data you have to store in a database is an essential side effect.
Modifying iterator or flag (e.g. bool isOpen) etc. is a non-essential side effect.
Transactional semantics are probably part of the story for the former, but the author was talking about the latter.