Tag Info

Hot answers tagged

43

Writing your functions/methods without side effects - so they're pure functions - makes it easier to reason about the correctness of your program. It also makes it easy to compose those functions to create new behaviour. It also makes certain optimisations possible, where the compiler can for instance memoise the results of functions, or use Common ...


20

Views #1 and #2 are incorrect in general. Any data-type of kind * -> * can work as a label, monads are much more than that. (With the exception of the IO monad) computations within a monad are not impure. They simply represent computations that we perceive as having side effects, but they're pure. Both these misunderstandings come from focusing on the ...


19

I don't know of any formal studies of the effects of programming language usage on native language competency, but I can share anecdotal evidence and pet theories. First off, even speaking more than one natural language has interesting side effects. If, for instance, I were to travel to France, speak only French for several years, and return to the United ...


19

There is one semi-conditional side effect I can think of that is okay: while(iter.MoveNext()) That said, I think this falls mostly into the "never is a really big qualifier" category. I can think of a few rare cases where I've seen it be acceptable, but in general this is vile and to be avoided. I also cannot think of a scenario where that particular ...


15

a and b are Numbers, whereas currentDateTime.seconds returns an IO<Number>. Those types are incompatible, you cannot add them together, therefore your function is not well-typed and simply won't compile. At least that's how it's done in pure languages with a static type system, like Haskell. In impure languages like ML, Scala or F#, it is up to the ...


13

From an article about Functional programming: In practice, applications need to have some side effects. Simon Peyton-Jones, a major contributor to the functional programming language Haskell, said the following: "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that ...


13

Referential Transparency means that you can replace an expression with the result of evaluating that expression everywhere in the program without changing the result of the program. So, take the following program: a = foo(1, 2) + foo(1, 2) b = a + global_variable Referential Transparency says that I can replace every occurrence of foo(1, 2) with the ...


11

(I don't know Erlang, and I can't write Haskell, but I think I can answer nevertheless) Well, in that interview the example of a random number generation library is given. Here is a possible stateful interface: # create a new RNG var rng = RNG(seed) # every time we call the next(ceil) method, we get a new random number print rng.next(10) print ...


10

First, your example is wrong (unless x refers to a field, and X is not used). foo(int x) { return x = x % x; } is actually a pure method, i.e. it doesn't have side effects. What would have side effects is a method like: private int x; public void ComputeValue() { this.x = this.x * 2 + 1; // Modifies a state of this.x } As for the second point, the ...


10

Let's begin with a definition for referential transparency: An expression is said to be referentially transparent if it can be replaced with its value without changing the behavior of a program (in other words, yielding a program that has the same effects and output on the same input). What that means is that (for example) you can replace 2 + 5 ...


9

You've got it wrong, functional programming promotes limiting side effects to make programs easy to understand and optimize. Even Haskell allows you to write to files. Essentially what I am saying is that functional programmers don't think side effects are evil, they simply think limiting the use of side effects is good. I know it may seem like such a ...


7

I will try to illustrate Haskell's approach (I am not sure my intuition is 100% correct since I am not a Haskell expert, corrections are welcome). Your code can be written in Haskell as follows: import System.CPUTime f :: Integer -> Integer -> IO Integer f a b = do t <- getCPUTime return (a + b + (div t 1000000000000)) So, ...


7

A few notes: Functions without side effects can trivialy be executed in parallel, while functions with side effects typically require some sort of synchronisation. Functions without side effects allow for a more aggressive optimization (e.g. by transparentely using an result cache), because as long as we get the right result, it doesn't even matter whether ...


6

Few to no languages make it impossible to cause side-effects. Languages that were completely side-effect free would be prohibitively difficult (near to impossible) to use, except in a very limited capacity. Why side-effects are considered evil? Because they make it much more difficult to reason about exactly what a program does, and to prove that it ...


6

All of your logic is sound, except that I think your understanding of functional programming is a bit too extreme. In the real world functional programming, just like object-oriented, or imperative programming is about mindset and how you approach the problem. You can still write programs in the spirit of functional programming while modifying application ...


6

Isn't it the same as asking "does long term programming affect your ability to do Calculus" or "does long term Calculus affect writing in a native spoken language". We get good at things the more we practice those things. And conversely, if we stop doing something, over time our skills worsen at doing that task. You probably used to write a lot more papers ...


6

Look into using Hypersonic, or another in-memory DB for unit testing. Not only will the tests execute faster, but side-effects aren't relevant. (Rolling back the transactions after each test also makes it possible to run many tests on the same instance) This will also force you to create data mockups, which is a good thing IMO, as it means something that ...


6

What I would do in this case would be to introduce my own RobotControl interface with methods corresponding to the ones in the real lib. After having done this, I would make a RobotControlImpl class which implements this interface against the real robot lib. The commands that I consequently would write would not extend the base class, but instead ...


5

If I understand your point correctly, you seem to be mis-using or abusing every and some but it's a little unavoidable if you want to change the elements of your arrays directly. Correct me if I'm wrong, but what you're trying to do is find out if some or every element in your sequence exhibits a certain condition then modify those elements. Also, your ...


5

In my world, a read from memory may be considered a side effect (e.g. memory mapped IO). Now, consider the following: while( ( *memory_mapped_device_status_register & READY_FLAG) == 0) { // Wait } And compare to: status = *memory_mapped_device_status_register; while( ( status & READY_FLAG) == 0) { // Wait ...


4

This is a fascinating question. The most interesting take on it is, in my view, the approach adopted in Clojure and explained in this video: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey Basically the "solution" proposed is as follows: You write most of your code as classic "pure" functions with immutable data structures and no side ...


4

View 1: Monad as a label "Consequently, this Int value has been marked as value that came from a process with IO therefore this value is "dirty"." "IO Int" is not in general a Int value (although it may be in some cases such as "return 3"). It is a procedure which outputs some Int value. Different executions of this "procedure" may yield different Int ...


4

I find that programming has had an overall positive effect on my writing, even though while studying in the USA I took a 9 year break from writing in my native language. I have developed the patience to edit and re-edit my writings, (when I have the time to do so,) until they come out perfect. Just like I tend to refactor my code until it comes out perfect. ...


3

The usual approach is to allow the compiler to track whether or not a function is pure through the entire call graph, and reject code that declares functions as pure that do impure things (where "calling an impure function" is also an impure thing). Haskell does this by making everything pure in the language itself; anything impure runs in the runtime, not ...


3

This question made me laugh, because as soon as I saw it, I thought of myself. I have developed (as in written code) several times weekly for about three years now. My world generally consists of diagrams, code structures, project plans, and sentence-long emails. Hopefully, studies will be done on this subject, but I can definitely say that my writing has ...


3

This is the eternal problem that everyone faces while writing integration tests. The ideal solution, particularly if you're testing on production, is opening a transaction in setup and rolling it back in teardown. I think this should suit your needs. Where that isn't possible, for example where you're testing the app from the client layer, another solution ...


2

Well, IMHO, this is quite hypocritical. Nobody likes side effects, but everybody needs them. What is so dangerous about side effects is that if you call a function, then this possibly has an effect not only on the way the function behaves when it is called next time, but possibly it has this effect on other functions. Thus side effects introduce ...


2

One note: a functional language is pure, but its runtime is not. For example, the Haskell runtimes involve queues, thread multiplexing, garbage collection, etc... all of which is not pure. A good example is laziness. Haskell supports lazy evaluation (that is the default, actually). You create a lazy value by preparing an operation, you can then create ...


2

I'm confused as to how this "no side-effects" philsophy works with asynchronous programming. By asynchronous programming I mean ... That would be the point, then. A sound, no side-effect style is incompatible with frameworks that depend on state. Find a new framework. Python's WSGI standard, for example, allows us to build no side-effect ...


2

On scalability I've had this problem some times before, that the integration tests were taking too long to run and were not practical for a single developer to continuously run in a tight feedback loop of changes. Some strategies to cope with this are: Write fewer integration tests - if you have good coverage with unit tests in the system, the integration ...



Only top voted, non community-wiki answers of a minimum length are eligible