kalininalex

Have this book, and couldn't agree more.

Harry Bernstein began writing his first novel at 93. He published it and gained fame at 96. He published two more before he turned 101. His fourth book will be published this year (posthumously, unfortunately).

Is 50 too late to start a new career? Only if we decide so in our minds.

That's true, functions can work quite well for smaller apps, and/or apps specifically suited for that style.

But there are many apps that have complex internal states. Subroutines and functions don't say anything about how to deal with it. This state ends up being global variables, which is a big issue.

I once worked on a complex desktop app written with functions and global data. It was nearly impossible to modify it, or understand what it does. A click on a button could execute 1,000 lines of code modifying dozens of variables, resulting in effects throughout the application. Debugging a seemingly simple issue could take an inordinate amount of time. We had to re-factor the entire app into OOP and model-view design to stabilize it and move forward.

The app had about 30,000 lines of code. So, based on this experience, I'd say it's too large for the functional style. When I start a new project I often don't know how large it'll get, so the safest approach is to default to OOP. If the functional approach will prove more appropriate down the road, it should be relatively easy to integrate functional design in those parts of the app where it's required.

Ah, sorry, poor wording :) I meant to apply "all being lost" to encapsulation in general, not OOP specifically.

I think we only need to count entities we need to keep in mind _simultaneously_. For example, a hypothetical File object can have dozens of methods, but to open it I only need one: File.open("..."). Internally, File may contain a dozen of variables, all of which may be updated by this call. But I don't need to know about any of them due to encapsulation. If I did, I'd be unable to write this code.

OOP (when done properly) enables us to focus at any time on a sub-part of the system containing five entities or less, so that we can understand that particular slice of the system. The slice can be very low-level (a private helper function of the smallest class), or very high-level (invoking a large subsystem through a facade interface, http://en.wikipedia.org/wiki/Facade_pattern). A typical REST API would be a good example of the latter.

I like benefits of the functional programming too, but I think functional and OOP work together rather than being in contradiction to each other.

Good point. Connections make the situation even worse (for aliens). Interestingly, it's about the same for humans: 3-4 entities produce 3-6 connections. Both are in the same neighbourhood. The limitation is biological though (http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_...).

The answer actually IS objective. The limit of complexity is defined by the fact that our short-term memory can simultaneously hold only five entities, plus or minus two. So, if the code requires one to hold more than seven elements in mind simultaneously - no one will be comprehend it, even the programmer who wrote it.

I once inherited a module written by a more junior developer. He indiscriminately used several dozen global variables that were used and modified in various parts of the program without much of a system. I spent about two months trying to understand how the module worked without much success. Ultimately, I had to completely re-write it (with great difficulty) to get rid of global states, and bring the number of entities affected by each function to under five-to-sever.

This biological limitation affects our development tools. That's why we have object-oriented programming. The goal is to keep the number of items we have to deal with at any moment under that magical limit of five to seven. Incapsulation is a key component of OOP used for this purpose. Without it all will be lost.

Sometimes I think of an alien race capable of keeping track of 100 items simultaneously, and try to imagine what their programming languages look like.. :)

Great observation. It's very easy to forget after a year or so of good times that bad times ever happened. Yet, this too shall pass. The key component of my philosophy is to always provide more value than paid for, be it 10 days of vacation, or 30. This will create consistent demand for one's services negating the impact of economic cycles.