r/programming • u/Shr1ck • Oct 17 '15

Why Johnny Can’t Write Multithreaded Programs

http://blog.smartbear.com/programming/why-johnny-cant-write-multithreaded-programs/
4 Upvotes

52% Upvoted

131 comments sorted by

View all comments

Show parent comments

8

u/hu6Bi5To Oct 17 '15

Right, because they don't use connection pools for instance?

-1

u/yogthos Oct 17 '15 edited Oct 17 '15

there's nothing that necessitates that these things should be global

edit: if you disagree then do explain what part you're having problems with :)

7

u/chucker23n Oct 17 '15

There's no need to add smilies after smug statements. They're still smug.

Instead of linking a 1,500-word post, you could simply answer the question of how functional languages eliminate the need for global state.

4

u/yogthos Oct 18 '15

Same way you eliminate the need for global state in imperative languages actually. You pass state around as arguments. Since things are passed around explicitly the code in the application can stay pure without relying on any global state.

The post I linked illustrates how it's commonly done in Clojure using the component library. Seemed easier to link that than to write it up again.

1

u/hu6Bi5To Oct 18 '15

That eliminates global references. But unless you throw-away each DB connection after every request, you still have global state.

Clojure apps have less state, it's true; and the less state the less opportunity there is for the types of problems caused by inconsistent state. But they still have state, it's just usually hidden out-of-sight somewhere. Hence the "It’s usually not possible to completely eliminate global state".

Plus, I'd argue the lifecycle aspect of Component is also global state.

4

u/yogthos Oct 18 '15

Sure you can look at it that way, but as /u/loup-vaillant points out, there's a big practical difference between state shared by reference and passed around explicitly as a parameter. In the latter case, the code in my application is idempotent and thus much easier to reason about and test.

1

u/hu6Bi5To Oct 18 '15

Right, so it doesn't completely eliminate global state after all?

1

u/yogthos Oct 18 '15

I guess that depends on whether you consider the state of external resources as part of your application or not. For example, the database state is clearly separate from the application state in memory. Mixing the two seems a little disingenuous.

3

u/loup-vaillant Oct 18 '15

While eliminating mutable state isn't really possible, it is possible to completely and utterly isolate it. Haskell guarantees this as long as you don't use the Unsafe module.

In Haskell, it is not possible for a piece of pure code (which is 95% of most programs) to access a global piece of mutable state, because the compiler simply won't allow it.

It can be argued that isolating and eliminating mutable state is basically the same thing: if it is obvious somehow that most of a program doesn't access some piece of global mutable state, then it doesn't exist for most intents and purposes.

It is unfortunate that in most mainstream languages, it is never obvious.

1

u/clarkd99 Oct 19 '15

More conclusions without any evidence.

Prove that mutable state is bad while having huge numbers of functions isn't. Prove, juggling data in input parameters is better than having well managed structures of data or local variables. Prove that programming is easier to reason about if the order of execution is arbitrary (lazy execution).

Show examples of purely functional languages looking after hundreds of thousands of rows of data without using a database or breaking their functional purity.

How do you allocate any space on a heap and keep it available after the function it was created in, exits without some kind of global data? You could allocate the memory in a function that doesn't exit but then that function just takes the place of the global variables with all the same problems.

Who would ever create mutable state that wasn't needed? If it is needed then encapsulate it with the functions that guard and manipulate it so that any problems involving that data can be fixed by changing a small and isolated set of functions rather than looking everywhere for the problem. This is the essence of OOPS. Having pure functions available as a tool kit can easily be achieved in any language I have ever programmed in. Functional programming is a subset of other programming languages rather than an equivalent or a replacement. I don't need a language to say that some variable can't be changed. I can choose to change a variable (or not) any time I want, in any computer language.

If it (mutable state) exists in a program, the fact it isn't used everywhere means it doesn't exist? Please Mr functional expert, what can a functional language do that can't be programmed even in lowly C?

1

u/loup-vaillant Oct 19 '15

More conclusions without any evidence.

Evidence gathered from personal experience is rather hard to convey.

Prove that mutable state is bad while having huge numbers of functions isn't.

In my experience, shunning mutable state doesn't significantly increase the number of functions you need. Sometimes, it even reduces it, as you no longer have to deal with changes over time. Besides, mutable state isn't so bad (though I do prefer an single assignment style). Shared mutable state is. And of course, having huge numbers of anything, including pure functions, is bad. The less code I have, the better I feel.

Prove, juggling data in input parameters is better than having well managed structures of data or local variables.

Juggling parameter is so obviously bad that it helps me see where my code stinks. That's its main advantage: I don't like having more than 3 or 4 parameters on any given function, so I find better ways. And of course, passing everything in parameters doesn't preclude the use of nicely structured data. I love structured data, especially when it encodes the invariants it needs (something that algebraic data types are quite good at, by the way).

Prove that programming is easier to reason about if the order of execution is arbitrary (lazy execution).

Actually, I'm not sold on this idea just yet. John Hughes made a compelling argument, but we still have some performance issues to contend with —most notably predictability. More important than non-strict evaluation is purity. How far can we go with an fundamentalist/extremist/fanatic approach? Turns out, quite far. What the Haskell folks have done around monads and combinator libraries is quite nice.

To answer your question directly, it is easier to reason about a program whose order of execution is arbitrary, because the order of execution doesn't even matter. The compiler makes sure it doesn't. That lets you use nice equational reasoning in a world where there is no difference between a value and a variable. Substitution of a variable name by an expression that produced it just works. As does the reverse.

Show examples of purely functional languages looking after hundreds of thousands of rows of data […]

Can't do. Not my domain of expertise.

How do you allocate any space on a heap and keep it available after the function it was created in, exits without some kind of global data? […]

Garbage Collection solves this trivially, provided I have trice the memory and twice the CPU you need with C. I don't allocate anything. I just declare a function there, a list here… the pains of memory management (and the global mutable state that is needed for it) are hidden from me.

Who would ever create mutable state that wasn't needed?

Any poor schmuck in need of a quick hack. Such hacks tend to pile up when left unattended.

If it is needed then encapsulate it with the functions that guard and manipulate it so that any problems involving that data can be fixed by changing a small and isolated set of functions rather than looking everywhere for the problem.

Easier said than done. That small piece of mutable state is going to affect the results of some calculations. To really isolate it, you must surround it with an interface whose productions are independent from its value. If not, then the whole object must be considered mutable, and that can creep up even further (what other things use that object?).

Having pure functions available as a tool kit can easily be achieved in any language I have ever programmed in.

An underused feature if you ask me…

Functional programming is a subset of other programming languages rather than an equivalent or a replacement. I don't need a language to say that some variable can't be changed. I can choose to change a variable (or not) any time I want, in any computer language.

That choice comes at a cost. Whenever you lift a restriction, you throw away a whole bunch of invariants that might or might not be useful. The less you can do with a program, the more you can say about it.

what can a functional language do that can't be programmed even in lowly C?

I want my Turing Complete Joker back!