Write Some ****ing Code

[regexcellent]

I have no idea WTF you're talking about for the most part, but IIRC "Monad" is the Neoplatonist/Gnostic name for God. Is the point supposed to be that "monad" is some sort of programming term for something that causes abstruse philosophical wanking about ultimately unprovable points?

In functional programming, you strive to eliminate "side effects" from your algorithms. I'm not going to go into the theoretical computer science stuff behind this because this bores even most programmers to tears (the ones not obsessed with functional programming, specifically). The trouble with functional programming is that all input and output is a side effect, and therefore all actually useful programs have side effects, usually a lot of them. So you have to have some method of having them in your programming language for it to be useful. In "pure" functional programming languages, this is done with something called a monad.

Thus, you have to learn how to use monads to get around the fact that your programming language is specifically designed to be clunky when it comes to programs real people actually write, and it's a major hurdle you have to leap in order to get into writing applications in these languages.

[Hauldren Collider]

Functional programming actually adds a whole class of features beyond what Regexcellent is describing, many of which have actually been adopted by more traditional languages like C# and Java, such as anonymous functions (lambdas) as values. Other neat ideas include algebraic datatypes, and pattern matching on said datatypes.

If all of this is gobbledegook don't worry about it. The point is this: FP has a lot of neat and genuinely valuable ideas. The problem is that the main peddlers of such ideas are ivory tower academic *******s who understand the real world almost as well as you probably understand the CS words in the preceding paragraph.

[regexcellent]

The seminal article on this particular phenomenon:

http://sdtimes.com/code-watch-functi...gness-problem/

I ****ing love this:

Functional programmers have applied modern advances in type theory to yesterday’s Smug LISP Weenie to generate today’s Insufferable Haskell Prick.

[loinburger]

I almost got in trouble recently ("almost" meaning that I got in trouble with the functional programming contingent at work, but my boss is not a full member so who cares) because of the deferred execution stuff I did with the custom transaction stuff I was working on. The problem: inside of our transactions we were doing things that didn't know that they were in a transaction - the most common example is that we would start a transaction, create an object, index the object in ElasticSearch, hit an error, roll back the object creation, and wind up with an object that doesn't exist being indexed in ElasticSearch (because ElasticSearch had no idea that we were in a transaction). The solution was to have two classes of operations: the kind that knows that it's in a transaction, and the kind that doesn't. If an operation knows that it's in a transaction then go ahead and execute it since it'll get rolled back as expected if we encounter an error, otherwise defer execution until the transaction has successfully completed. The functional programming idiots wanted me to use some awful monad to store all of these deferred operations; in my defense I made a half-assed attempt at this, and then I wisely ditched the functional programming crap in favor of a ConcurrentLinkedQueue of deferred operations (upon successful execution of the transaction, use a while((blah = queue.poll) != null) {blah.execute} loop to execute everything in the deferred execution queue). Every couple weeks one of the Functional Programming Douchebags will lodge a complaint about this queue, but they never program a functional alternative because deep inside they realize that it would be awful.

[pchang]

agreed that functional programming attracts weirdos

Thank goodness, their chance of breeding is exceptionally low.

[Hauldren Collider]

I almost got in trouble recently ("almost" meaning that I got in trouble with the functional programming contingent at work, but my boss is not a full member so who cares) because of the deferred execution stuff I did with the custom transaction stuff I was working on. The problem: inside of our transactions we were doing things that didn't know that they were in a transaction - the most common example is that we would start a transaction, create an object, index the object in ElasticSearch, hit an error, roll back the object creation, and wind up with an object that doesn't exist being indexed in ElasticSearch (because ElasticSearch had no idea that we were in a transaction). The solution was to have two classes of operations: the kind that knows that it's in a transaction, and the kind that doesn't. If an operation knows that it's in a transaction then go ahead and execute it since it'll get rolled back as expected if we encounter an error, otherwise defer execution until the transaction has successfully completed. The functional programming idiots wanted me to use some awful monad to store all of these deferred operations; in my defense I made a half-assed attempt at this, and then I wisely ditched the functional programming crap in favor of a ConcurrentLinkedQueue of deferred operations (upon successful execution of the transaction, use a while((blah = queue.poll) != null) {blah.execute} loop to execute everything in the deferred execution queue). Every couple weeks one of the Functional Programming Douchebags will lodge a complaint about this queue, but they never program a functional alternative because deep inside they realize that it would be awful.

What I don't understand is what exactly do they think the benefit of a hypothetical functional alternative would be? Ideological purity? If the code is more confusing and isn't faster, who gives a ****?

[regexcellent]

I see functional programming as a useful tool for expressing certain things that are awkward in OOP, like the strategy pattern. Not as something to design your entire application around.

[loinburger]

Currently writing a program to move a bunch of records from MySql to MongoDB. The first time you run the program it retrieves all of the records from MySql (in batches of 1000 records - we're moving about 5,000,000 records in the QA database and 10,000,000 records in the Prod database) and puts them in MongoDB; successes are stored in successes.log, failures are stored in failures.log. Every subsequent time you run the program you only reprocess the records in failures.log - new successes are appended to successes.log, whereas the old data in failures.log is wiped out.

I use a mutable reference to the logger so that we can ask it for a status report (number of successes and number of failures) since we're expecting the program to run for at least a few hours, and I use a mutable AtomicBoolean to ensure that the program won't be invoked more than once at the same time (which would create duplicate records and screw up the logger). Obviously one of the functional programming douchebags objected to this. The awesome thing about this is that their alternative implementation relied on operating system locks on files, which is imperative as hell - but since the impure locking code is in the operating system the functional programmer is allowed to use it and still claim that his code is pure.

[regexcellent]

edit: I'm dumb, reading comprehension is fundamental!

I would love to see code that manages to allocate resources in a non-stateful manner.

[Ben Kenobi]

The awesome thing about this is that their alternative implementation relied on operating system locks on files, which is imperative as hell - but since the impure locking code is in the operating system the functional programmer is allowed to use it and still claim that his code is pure.

So if I understand it correctly, the program relies on external rather than internal constraints? Oboy. I can't see that working out poorly. Why didn't your boss veto it? Seems like a terrible way to program.

[loinburger]

Functional programmers want to allocate everything all at once because then you can get a nice pure immutable data structure, but that's not going to fly with ten million database records.

[loinburger]

So if I understand it correctly, the program relies on external rather than internal constraints? Oboy. I can't see that working out poorly. Why didn't your boss veto it? Seems like a terrible way to program.

I vetoed it

[Ben Kenobi]

Functional programmers want to allocate everything all at once because then you can get a nice pure immutable data structure, but that's not going to fly with ten million database records.

I don't understand their opposition to your iterative process. Yours scales up really well and it'll get to the same place. If I've understood what you're doing it'll work for pretty much any size, eventually. It should also work better with bad/crappy inputs.

[Hauldren Collider]

The awesome thing about this is that their alternative implementation relied on operating system locks on files, which is imperative as hell - but since the impure locking code is in the operating system the functional programmer is allowed to use it and still claim that his code is pure.

[Hauldren Collider]

I'm currently writing a compiler in OCaml for a class. Algebraic datatypes are nice, but sometimes you just have to use state. I use a mutable variable to keep count while I parse identifiers, for instance.

I discovered that OCaml, despite its vaunted ML-granted easy referential transparency, can't be multithreaded because of a Python-style global garbage collector mutex. So to do parallel code, OCaml programmers use ****ing MPI.