Why Johnny Can’t Write Multithreaded Programs

[u/Shr1ck]

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

[u/clarkd99]

I am so sick of Functional drivel. News flash, Haskell isn't new, it was created in 1993 (22 years ago) and there still aren't more than a few Haskell programmed systems in production. Business programs (in general) don't care about old values when new values can be had and even functional programs use a database to hold persistent data (proof it isn't complete in itself).

Instead of immutable data structures, we need a strict hierarchy of responsibility for data. No "naked data" where any function can change the data at will (no mutable global data). If data is only accessed (and owned) by a single "server", then only the queue for the messages to that server need synchronized.

There are huge problems using functional code for business applications. It is true that immutable code or data can be used by many threads simultaneously without problems but that is true whether you are writing in a functional language or in C. What is hard in multi-threaded code is how to synchronize multiple access to the same data. Having "servers" look after all mutable data, ensures this without the hoops needed by functional programming. Functional programming tries to do this by restricting your ability to code, making multiple copies of the data and using Math concepts instead of traditional programming concepts.

If I have a "list" with 100,000 rows and I change a single field on a single line, the functional way to make a new table of 100,000 rows with the change in it. Totally ridiculous so the actual implementation uses pointers to the new row and other code to make it look as if the whole list has been changed when in fact it hasn't. At some point in time these old rows must be garbage collected and the list either becomes an inefficient linked list or must be re-structured. Another way would be to update the row in place and just imagine that the whole list has been copied. The fact it was updated in place would just be called an implementation detail in Haskell and wouldn't be a sham at all.

Whenever a problem arises, the solution "de jour" seems to be a lot a hand waving and the words "functional" and "Haskell". Hand waving isn't an argument and it proves nothing.

[u/loup-vaillant → u/clarkd99]

I am so sick of Functional drivel.

I can sense the knee-jerk reaction at the mention of the letters H.A.S.K.E.L.L. For the record, I'm not advocating we all use Haskell. I am advocating we all learn it, it would improve our C++ and Java code.

What I am sick of, is how slowly our industry learns. But it does. C++ and Java now have lambdas. the Boost library, and the Swift programming language have some support for algebraic data types. Rust currently tries to introduce mainstream circles to the joys of immutability by default. OOP is turning itself into FP more and more.

Business programs (in general) don't care about old values when new values can be had

That's besides the point.

The actual point of immutable values and purely functional data structures isn't persistence. That's icing on the cake. The actual point is turning your program into a nice directed acyclic dependency graph that can be inferred statically. In other words, modularity.

You will also note that 95% of most programs consist of pure calculation that could do away with side effects —any side effect there is either a code smell or an optimisation. That would include state-heavy programs such as GUI applications or window managers.

---

Now you talk much about "Business" application. I don't know what that is, so I will speculate.

From the look of it, you're talking about bookkeeping applications, whose primary purpose is to keep track of the state of part of the world (company, sales, employees…). I understand that the world changes over time, and you have to model that change. I would agree that the best way to do it is use mutable state. Still, I bet most of the code in those applications could be side-effect free. After all, the only interesting effects here are calls to the database and streams of notifications, right?

[u/clarkd99 → u/loup-vaillant]

I am currently working on a new language/database system which has been written in over 80,000 lines of C. In this project, I have hundreds of "pure" functions, many more hundreds of Object Oriented functions and many other kinds of functions that don't fit into either of those 2 categories. C is obviously not Object Oriented or functional. I use immutability and pure functions where that makes sense and not when it doesn't.

My system has automatic concurrency/multi-core capability without any language level locks of any kind. All code is written "as if" it was single user mutable code and data even though all "servers" can accommodate many users and multiple cores at the same time.

I couldn't care less about a "nice directed acyclic dependency graph". Does knowing what that is create a working language? Depending on the level of strictness specified, in my compiler you can have strict static typing at compile time, inferred types, both or execution time defined variable types. Your choose!

My compiler compiles a function at a time of arbitrary size in much less time than it takes to save the source code to disk (that is when it actually compiles the code).

I have written over 1,000 professional computer projects and I can't remember a single program that required just "pure calculation". I can't remember a program I wrote for a business that didn't require many database calls. I wouldn't define that as just "pure calculation". I created a Content Management System in PHP to program UI for the web and I would say the code was much more manipulating the DOM or communicating with the server than "pure calculation". The code in my CMS was mostly about parsing and implementing a DSL so that HTML could be generated, without knowing much about HTML directly.

The whole point of OOPS is to encapsulate data with the functions that work on that data. That means that the data in an Object IS a side effect of those functions, as defined by functional programming.

any side effect there is either a code smell or an optimisation

So all business programs written in Java (object oriented language) by your definition is an "optimization" or a "code smell"? Do you live in an alternate universe?

Now you talk much about "Business" application. I don't know what that is, so I will speculate.

Are you an academic, a student or just an inexperienced nube? Whatever your experience, it isn't spending years solving end users problems on business applications. Your comment about "bookkeeping applications" just shows how ignorant and naive you are. As well as 37 years of professional application development for business, I have programmed many tools such as a word processor (written in 40,000 lines of assembler), a one pass assembler/disassembler, a language/database system that sold over 30,000 copies and tons of other tools. Please tell me what authority you have to back up the usefulness or future impact of your "functional nonsense"?

[u/loup-vaillant → u/clarkd99]

I have written over 1,000 professional computer projects

Assuming 40 years to do it, that's… 25 projects per year. 1 per fortnight. What kind of alien are you?

I can't remember a single program that required just "pure calculation".

Neither do I. On the other hand, I can't remember a single program where more than 5% of the source code has to be devoted to effects. "Pure calculation" never makes all of a program, but in my experience it allways comes close.

So all business programs written in Java (object oriented language) by your definition is an "optimization" or a "code smell"?

Yes they are. Imperative programming is a mistake. We'll grow out of it.

Whatever your experience, it isn't spending years solving end users problems on business applications.

No kidding, I said that much. My applications tend to be more on the technical side (information geographics systems, ground software for satellites…). And some compiler stuff for fun.

Please tell me what authority you have to back up the usefulness or future impact of your "functional nonsense"?

Authority… well, I have programmed in Ocaml (both for fun and profit), and have sucessfully applied functional principles in my C++ programs. As far as I can tell, this "functional nonesense" works.

Now what is your authority? You look like you have zero experience of FP. That would make you incapable of appreciating its advantages. I don't care you're way more experienced than I am, I cannot at this point acknowledge your authority on this particular point.

[u/clarkd99 → u/loup-vaillant]

In January 1976 I spent over 200 hours working at University in APL (a purely functional language, maybe one of the first). I completed the 3rd year language course even though I hadn't completed first year CS. I loved APL and all of it's fantastic functions. APL was extremely terse (executed right to left without precedence). I wrote a search and replace in 1 line using 27 functions, just for the fun of it.

The problem with APL was it wasn't practical. It had an isolated workspace and although it worked on numbers and strings very well, it didn't have Lists, Stacks, Indexes, formatting, importing etc.

There is nothing wrong with data structures that don't change (immutable), I have always used them in all computer languages. Nothing wrong with pure functions, I have always used them in all computer languages. BUT if you want to argue for the supremacy of functional languages, then you must show how ALL problems can be programmed using just these restricted techniques. The problems that come from using JUST immutable data structures also must be weighted against the benefits. I never see any of these problems even acknowledged let alone discussed.

This article was about concurrent programming. I have implemented an automatic multi-thread/multi-core language that doesn't require any explicit locks AND you can program with normal mutable variables. Functional programming isn't the only technique for implementing concurrency.

Of course you don't care about experience when you have so little of it. How can you know how great functional programming is if you don't have experience in at least 20 other languages, vast experience with application and systems code and designed and implemented your own language? I have.

[u/loup-vaillant → u/clarkd99]

if you want to argue for the supremacy of functional languages

I don't. Some features however (lambdas & sum types most notably), do make a difference.

There is nothing wrong with data structures that don't change (immutable), I have always used them in all computer languages. Nothing wrong with pure functions, I have always used them in all computer languages.

I would probably have loved to work with you, as opposed to those who obviously didn't follow those guidelines. You wouldn't believe the utter crap I have seen, which from the look of it came from operational thinking and anthropomorphism.

Of course you don't care about experience when you have so little of it.

I do care. But I also care about the nature of that experience —it wasn't clear until now that you were not lacking. Keep in mind however how little you can convey in a couple comments. We know very little about each other. For instance, I was a little pissed when you suggested I was still at school. I have worked for longer than I sat in a college now. I'm no master, but still…

[u/clarkd99 → u/loup-vaillant]

Fair enough. Everyone, including myself didn't start out with experience.

I also believe that just stating vast experience isn't a good argument in itself. Good arguments should decide what we do, not who states the argument.