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 ...


26

If the memory you access can change, then it is indeed a side effect. For example, in Haskell, the function to access a mutable array (IOArray) has type Ix i => IOArray i e -> i -> IO e (slightly simplified for our purposes). While accessing an immutable array has type Ix i => Array i e -> i -> e The first version returns something ...


21

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 ...


16

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 ...


10

I think you've reinvented monads! Let's look at what we have here, we can "dirty" a pure computation implicitly and use it in an impure one, and we can call impure function from another impure one. That sounds a lot like monads, we can dirty a pure value with return, to call another function from an impure function, we can just use >>= apply :: (a ...


10

In computer science, a function or expression is said to have a side effect if, in addition to returning a value, it also modifies some state or has an observable interaction with calling functions or the outside world. Reading from a file is an observable interaction with the outside world. It meets the definition of side effect. Reading the 42nd element ...


10

Simplest possible example: printing "Hello, world!" changes the state of the system, because the console now displays "Hello, world!", and earlier it didn't. Not only have you changed the state, it's actually impossible to change it back, since you can't un-get characters from a terminal! That's about the most serious side effect possible.


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 ...


9

You have described an effect system. It’s true that there are other effect systems than monads, but in practice monads give you a lot of expressive power that you would need to reinvent in any practical effect system you might devise. For example: I start by tagging my I/O procedures with an io effect. My pure functions can still throw exceptions, but ...


9

The Haskell optimizer is allowed to freely manipulate calls to pure functions as long as the result remains the same. For example, if it can see that you are calling sqrt on the same number 100 times, it can cache the returned value and only call it once. If it can see that you never actually use the result of that function, it can choose to not call it at ...


8

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 ...


7

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 ...


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, ...


6

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 ...


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

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 ...


6

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 ...



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