One of my favourite videos on YouTube is the talk Stop Writing Classes by Jack Diederich. He shows a clear example where they go from a full library down to a single function that still does everything the library did.

I am very much a fan of the building upwards method of constructing programs where you start with just the code that you then lift into procedures and then into classes or modules if the need arises. Sometimes the best solution is a class, but it's really hard to know that from the outset and if you start out by writing the classes you think you'll need you will end up with classes like the first one Jack shows in that video (Greeter) that are what he calls obfuscated function calls.

This is why I think multi-paradigm programming languages are the bees-knees and any language that strictly forces a certain paradigm on you are not that fun to use. This goes both for OOP languages like C# or Java and functional languages like Haskell. Their strictness lead to hairy corner-cases where you can't write the best possible code because the language forbids it. Sometimes a global function (Python's len() comes to mind) is the ultimate solution, but if your language can't do it you do something like a Singleton which really is just a hidden global variable in most cases.

Tell someone you're using global variables and they'll jump down your throat telling you you're a shitty coder. Tell them you're using Singletons and they'll applaud you for being a diligent practitioner of the Patterns as proscribed by the holy Gang of Four...

I always try to use the simplest abstraction that solves the problem. Oftentimes that's just a function.

Functions are also way more reusable than classes. Classes by design tie state to methods, oftentimes grouped with state I don't care about or have. If instead they used functions I could just reuse the functions I care about with the state I have.

That is the nice thing about multiparadigm languages like e.g. Python. You could start with a simple function. If you realize that there is need for another function, you group this functions together in a module. If you realize, this module contains data and functions which could go well together, you could start writing a class.

I find it unfortunate that some languages, ahem Java and C#, don't even offer global functions.

This isn't completely accurate. C# has static classes and static functions that can achieve the same results.

You could even create a static class called Global and then call functions like:

Global.MyFunction()

This would act the same as a global function, it would just be prefixed with a namespace or type.

Allowing global functions seems like you're just asking for namespace pollution. I'm not a fan of the idea.

Here’s a mixture of facts and opinions :p

Let’s take simplicity of expression and implementation as our goal. Consider that functions are considerably simpler than the proposed alternatives, which add layers upon the primitive idea of a function. It is clearly true that a function is the better choice when it provides equivalent functionality to the more complex structure. The more complex solution adds useless information and therefore obfuscates the purpose of the software.

Another question is whether to use the mathematical definition of a function or consider them to be equivalent to procedures. I prefer the mathematical definition because it is easy to reason about, easy to test, and therefore harder to get wrong.

The idea of elegance can be misleading, suggesting intricacy as a virtue. Elegance really comes from simplicity and compactness, which actually minimize the level of intricacy. The effect of beauty comes from the stucture of the design clearly expressing the problem that it solves.

I think the industry, having over-worshipped the object-oriented paradigm, is now veering in the opposite direction.

I have also the same feeling. And I feel it is because of the type of problems that the industry is facing nowadays.

I strongly support the OOP paradigm not only because it aligns to the way the complexity is organized in the real world, also because it provides solid mechanisms for extensibility.

I did program games 20 years ago with old programming languages that didn't support OOP. It was very hard to make abstractions. Since I found the OOP paradigm it was easier to build the behaviour of the game components and reuse it in others. Many enemies shared the way to move, or shoot, etc.

Of course there were problems that, by its nature, didn't need such mechanisms. But at the end they also feed into a class method.

So what can I do in a function that can not be done in a class method ?

I don't see the OOP as a replacement of the old procedural paradigm. I see it as an extension, the same way that the theory of relativity is an extension to the theory of mechanics.