Thread:Sinthorion/@comment-25330335-20170525042041/@comment-25101690-20170525144111

I don't get it. What do you mean? <!-- First of all, I think there is no ultimatively best way of programming. Everything has its pros and cons. Strictly following a guideline costs both time and freedom, but helps with other things. Often things are still done dirty because it has to be done quick. Especially in the professional sector, it's sometimes hard to explain to customers why they have to pay 1000€ to add a simple button at the right place, when the problems with it are just guidelines that prevent you from going the simple way. On the other side it is even worse if it takes 1000€ only because you were lazy in the past and didn't consider future adjustments.

Choosing the right guideline also depends a lot on the type of application. For a critical system, such as pacemakers, autopilots, or bank applications, you need very strict standards, while for web applications, you would prefer loose standards because the web itself is changing and evolving all the time and you want your website to work in all past and future browsers as good as possible.

If you think about it, everything is basically global: There are always some objects in global scope, that contain other objects in their own scope etc. The difference of the inner to the global objects is just encapsulation. By preventing that other parts of your program can alter a state, you can rely on your changes to the state.
 * 1) How to write good functional code

Another problem with the global namespace is that you might override something accidentally because your own object has the same name.

A third problem is unit testing. In good development, you want to have unit tests that isolate a single part of your software (a single class, usually), and make sure it works as intended. If the class depends on global state, you can't isolate it.

Pure functions have no side effects and depends on nothing but the parameters it gets. That means you can't build an entire application out of pure functions; at some point you have to wait for user input, for a network connection, a PRNG, or file operations. But it's good to stay pure as much as possible and do IO on a reasonably high level.
 * 1) Functions

Take a look at [Haskell's IO](https://wiki.haskell.org/IO_inside), that has done a great job of keeping IO as pure as possible. Generally, take a look at Haskell if you value purity. But generally, purity is too inconvenient to be more popular.

In Fortran you can tell the compiler the intent and possible side effects of your function or subroutine so that the compiler can do more optimisations. Fortran is probably the language with the absolutely best performance and it's especially good with doing repetitive calculations (such as a few thousand pure function calls on a large matrix) on multi-core processors.

I really like first class functions. Javascript would be nothing without its callbacks, that can be passed around like any variable. Python has "function modifiers" that take a function object and return an enhanced version of the function.

Many programming languages don't have structs. They are really just a subset of classes so there's no need to add them as a separate feature to the language. It's common to use classes for struct types, which only have getter and setter methods. But I don't see the point in that. If you can't do anything with an object other than getting and storing data in it, then why is it even an object and not just plain data? A map should be used for that instead.
 * 1) Structs

With access modifiers we can control WHO can access our data. That sounds useful because we can rely on data if we know that nobody else tampered with it, but what would be infinitely more useful would be a way to control HOW the data can be accessed.
 * 1) Encapsulation

For example you have a ratio as float, that must be between 0 and 1 for your program to function. You could check it for correctness before each use, you could make it private to prevent any unauthorised access, or you could check the value in the setter method and do nothing (or throw an exception) if the value is wrong. Writing a setter is a bit of efford though, requires change of all parts that previously used the value, and performs worse than direct value access. Ruby is the only language that I know to solve this well, with its [attr_accessor and bracketless function call](https://stackoverflow.com/questions/4370960/what-is-attr-accessor-in-ruby#4371458).

I could talk about this for so much longer without getting tired. I had to delete whole sections I wrote when I noticed I was going too far. I'm also not quite content with some things I wrote here, but I ran out of hours to spend thinking about it. -->