What's bad about OO (and FP)?

[josvazg]

I am writing a tiny book for non-techies about the digital world. 

In the first part of the book I explain digital data and in the second I take the reader into an overview trip from transistors and logic gates up to software programming.

At the end of the second part I talk a bit about traditional languages (C, Pascal, Basic, Cobol, etc), then I talk about OO before introducing more recent languages (C++, Java, Python, Ruby, Javascript, etc). Finally I wanted to talk about current trends with 2 base examples, Scala and, of course, Go(lang).

Currently I was looking for the "cons" (as in pros and cons) that the programming community has learn about on pure OO programming (as for instance class hierarchy management overhead). But when I search about the topic I end up in Functional Programming silos where they attack both OO and imperative prog. and this is not the approach I wanted in my text, besides I guess pure FP is also an easy target for criticism and, initially, I did not plan to go deep down to cover FP vs imperative on an overview for "non-techies" (or future "techies").

Where can I read about Rob Pike or other Go co-authors opinion on OO's problems (even from a imperative-centric stand point)?

In preparation for the last part it would be also useful to read about the "contras" of FP as a pure paradigm. Any URLs on these?

I have the impression that Go does the right thing doing away of a lot of OO "counterproductive" luggage and letting you do FP "as far as you want to go" at the same time without forbidding your imperative code at all. But I would like to read more on the subject to be able to explain it properly.

[Matt Kane's Brain]

On Wed, Apr 18, 2012 at 11:53, josvazg <jos...@gmail.com> wrote:
> Where can I read about Rob Pike or other Go co-authors opinion on OO's
> problems (even from a imperative-centric stand point)?

Have you seen this? http://harmful.cat-v.org/software/OO_programming/

--
matt kane's brain
http://hydrogenproject.com

[Benny Siegert]

On Wed, Apr 18, 2012 at 17:53, josvazg <jos...@gmail.com> wrote:
> Where can I read about Rob Pike or other Go co-authors opinion on OO's
> problems (even from a imperative-centric stand point)?

Look at some of the talks given about the motivation behind Go. In
particular, there is one titled "public static void" by Rob Pike,
which seems to be pertinent to your question. Most of the talks
(though not the one I just cited) are linked at
http://code.google.com/p/go-wiki/wiki/GoTalks .

--Benny.

--
The first essential in chemistry is that you should perform practical
work and conduct experiments, for he who performs not practical work
nor makes experiments will never attain the least degree of mastery.
        -- Abu Musa Jabir ibn Hayyan (721-815)

[josvazg]

Thanks this is a good one.

[josvazg]

I watched that talk, I will do it again but with more focus on what he says on OO and FP. 

(Although I recall it was more about dynamic vs statically typed)

Jose

[Michael Jones]

One caution is that rarely do languages enable or disable programming
approaches. They do facilitate them, or the opposite, they may make
expressing concepts implicit, explicit, or so complicated as to be
obfuscatory, but it is a feature of Turing completeness that you can
do most anything in any environment.

Language X was not naturally recursive, yet many algorithms were
written recursively with explicit stack management. (X = Fortran, ...)

Language X lacks "OO" as a check item, but programmers can readily
code in an OO way in any language, and of course CFRONT showed that C
could have feature-rich "OO."

Feature Y (bounds checking, list-structure, SNOBOL/Icon inbuilt
pattern matching, dynamic allocation, GC, ...) can be built in or
added on.

Concept Z ('bounds checking") can be implement noisily with "a[i] ==>
{t = iExpression; if t is in bounds r = a[t] else r = ...}" as a macro
or a preprocessor or a well-implemented habit.

Design approaches can also be manufactured. I want to program with
generators or continuations. I write my function with all state as a
struct element, I allocate such a state for a new function call,
process, and return result and pointer to state, ...)

I don't need Go for asynchronism -- not only do pthreads work but the
whole of Go's asynchronism can be built for C using a library.

So the real question is about paradigms of program, data, or process
organization--what are their benefits in various cases and what are
the weaknesses. The secondary question is about what languages make
these paradigms more or less easy or clear to express, debug, or
maintain across various scales of problems in terms of data size,
performance, or developer community.

For example, it is surprisingly easy to build an automatic
differentiator or anti-differentiator for numerical functions
expressed in a functional means--I mean tools that transform the
program source to compute the desired function. Iverson was able to
differentiate a rich set of APL functions using an 8 or 10 line APL
function. That is a stunning thing and if you wanted to do that on the
fly then that advocates for expressing your code in a FP manner. (Tiny
example of a huge field byt still, a valid one.)

I'd like to see an analysis of approaches first and then a discussion
of implementations secondarily. To be clear, Go's interfaces are
certainly OO to me, even though they lack most every expression of
OO-ness from every OO-themed language. The ability for a common set of
actions to be understood by a class of programmatic objects (they can
all print themselves, they can serialize, they can ...) is a greatly
simplifying design approach. It is a good thing to do. However, what
to do and how to do it are orthogonal. One way is to say that anything
C and D have in common is inherited from their ancestor A. This can
make D's ability to also do what B can do an awkwardness. In Go, with
zero "you are who your parents made you" we have "you are what you say
you can do", an individual meritocracy. If fact, you "are" every class
that you match so you might even match interfaces not yet written.
This is subtle and deeply important, yet, must we say that Go is
against OO and all the flaws of OO languages?

Saying this (in a book) means talking about shared traits as a concept
and parent-child bestowing of traits as a different concept then
showing how some languages links of these two concepts to implement
"objects", some keep them apart, some, like Go, don't have the notion
of parent at all but they do have the notion of DNA borrowing by
embedding as well as arbitrary DNA equivalence by subsetted interface
signature matching.

Just a thought, but you might want to be clear about this.

--
Michael T. Jones | Chief Technology Advocate  | m...@google.com |  +1
650-335-5765

[josvazg]

Well, as for the book I wasn't planning to enter in so many details. The goal of the (tiny) book is to be brief and friendly to non-techies on a rush or techies-to-be. Not that I want to confuse the readers, I just don't want to overload them with too much alien-stuff for them. I guess the trick is to find the right set of few words to sum this up.

But yes, most of the languages are NOT "a pure thing", they usually just bet more on "this" or "that" and, as you say, this leads to using certain paradigm A on one language L1 is easier that in language L2 which is better for paradigm B that is possible on L1, but very awkward. I have written a few lines of OO inspired code in straight C myself ;-).

I just wanted to point out a few of the "problems" that have been detected in OO and also FP once they have been used (and abused for quite a while) and what are the basic lessons learned up to now, pragmatically speaking, taking into account, for instance maintenance, time-to-design, time-to-code, verbosity in lines of code, result performance and those kind of things .

Jose

> I watched that talk, I will do it again but with more focus on what he says

[josvazg]

Ok, I think now I have enough sources to search for OO objections.

What about pure "Functional Programming"?

Is it perfect?

I guess not, so, Where are the objections to FP?

(Go lang has selected a more imperative than functional path, so there must be a reason for this)

[Andy Balholm]

Well, here's my take on the problem with pure functional programming:

Imagine a diagram that shows all possible ways of thinking, with more similar mindsets closer together. (I'm using "thinking" in a broad sense that includes computation, not in the strict sense that is restricted to consciousness and real intelligence.) One point (or a small area) on the diagram would represent how computer hardware works. Another, larger area would represent how people naturally think (larger because people are more varied than computers).

Most programming languages fall somewhere near the line connecting how computers work to how people think. Low-level languages are very close to how the hardware works. Higher-level languages are farther from the hardware and closer to the people. You have a fairly straightforward tradeoff: making a language more natural for people makes it less natural for the hardware, and vice versa.

But functional languages go off in a whole different direction. They are high-level in that they are not close to the hardware, but not in the sense of being close to how people think. (Some people may think that way, but probably only after extensive graduate studies in mathematics.) 

[Glenn Brown]

What about pure "Functional Programming"?

Is it perfect?

In my eyes, the fundamental problem with pure FP is that some tasks which are O(1) time in imperative languages are O(ln(N)) time in pure functional systems.  This is a deal-breaker in my domain: dynamic routing and chip/network simulation, where mutable shared hash tables and RAM simulation are essential, are O(1) in imperative languages, and are O(ln(N)) in functional languages.

Also, I find the "FP makes parallelization trivial" attitude to be grossly misleading, because it ignores the overhead of computing on remote processors.  On real-world architectures, efficient parallel and concurrent computation requires intelligent choices about how to subdivide problems, so subdivision needs to be explicit in programs.  For example, "go function()" in Go explicitly invokes concurrency and the associated overhead; you don't want to use it for trivial functions.

[Ian Lance Taylor]

josvazg <jos...@gmail.com> writes:

There is nothing particularly wrong with functional programming.
Obviously many of the ideas from functional programming have been
adopted into other languages, including Go.

However, pure functional languages have been around for many years and
none have been widely adopted. Personally I think this is because pure
functional languages are a poor fit for the way that programmers
actually think about solving problems. We live in a world in which
things change, and we are accustomed to that; pure functional languages
live in a world in which nothing changes. Also, pure functional
languages are a poor fit for the problem domains that most programmers
have to work in, e.g., user facing applications. Interacting with the
user is difficult in a pure functional language, and generally requires
breaking the purity. We wind up with approaches like Haskell's monads,
which are notoriously difficult for most programmers to understand.

Go is not a pure functional language because the initial conception of
Go was to use it to write system level programs like web servers and
databases. These sorts of tools are not written in pure functional
languages. It would not be impossible to do so, but it would be
difficult and awkward. In particular it would be hard to make the
result highly efficient; one of the advantages of Go over some other
languages is close control over memory layout and usage, a feature that
is very difficult to provide in a pure functional language.

Of course there are examples of non-pure functional languages that are
entirely suitable for systems programs, such as Erlang or, arguably,
Scala.

Ian

[josvazg]

Thanks for the replies!

I am just  introducing myself to FP thinking. I believe that it can be quite good for certain problems, and on some others it can be mixed with imperative and OO just as you see fit... if you are using Go (or a similar language that includes FP support, but having Go... what else do you need?)

It seems to me that FP is more mathematical which is good in many calculus, map-reduce, etc, but programming most of the time is not pure maths, it's more moving data form one place to another, storing data and retrieving it, talking to other programs remotely, etc. Sometimes functions help, other FP constraints are just "getting in the middle".

Just one more question.. I thought that Scala was kind of an hybrid language (OO, imperative +FP) , just like Go but with more features towards, for instance, enforce inmutable data somehow as pure FP dictates. Is that right?

(When I read about Scala I either see features that are also similar to Go, or feel a bit of a bloat; cool at first sight, but a bad idea in the long run, like "operator overloading" is for code maintenance)

Jose

[Ian Lance Taylor]

josvazg <jos...@gmail.com> writes:

> Just one more question.. I thought that Scala was kind of an hybrid
> language (OO, imperative +FP) , just like Go but with more features
> towards, for instance, enforce inmutable data somehow as pure FP dictates.
> Is that right?

I believe that is correct, although I can't claim to fully know Scala.

Ian

[Michael Jones]

I recommend reading Backus' Turing Award paper on FP and his later,
second-generation FL:

FP: http://www.stanford.edu/class/cs242/readings/backus.pdf
FL: http://theory.stanford.edu/~aiken/publications/trs/FLProject.pdf

You might want to read Dijkstra's review of FP. Harsh in his way but cogent:
http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html

One of my favorite languages is J, the intellectual heir of all that
is/was APL. J has a strong sense of FP in it, especially when you get
into Tacit expressions. This "essay" discusses them but does so in the
manner of English Cricket, which only makes sense to those to whom it
previously made sense:
http://www.jsoftware.com/jwiki/Essays/Tacit%20Expressions

If you're intrigued, then read the beautiful guide by my friend, the
great Henry Rich. It is in section 36 of his book J for C Programmers
(included with J and linked from here in Word and PDF form:
http://www.jsoftware.com/jwiki/Books)

There is another language within J, a microcode for J as it were.
Like Moliere's M. Jourdain, who was astonished to find he had been
speaking prose for forty years without knowing it, you have been using
a small subset of this language unwittingly throughout our
investigations. The hidden language describes a way of coding called
tacit programming, and it is time for you to learn it in full. J's
tacit language is the irreducible essence of a programming language.
It describes your algorithm using only the ordering of the J
primitives you have already learned. It has a grammar without words,
which you use to write programs without visible operands; yet its
renouncing these seemingly essential components is self-denial rather
than self-mutilation, for it retains the vigor to express any
algorithm. It is as evanescent as the breeze and as powerful as the
hurricane. It is a sublime creation.

It is very educational to learn J and from that you will see what
Backus wash talking about.

--

[JLarky]

It's valid point. Because ideal program in functional language will do no side effects: won't take input and won't print output :)

Nevertheless anyone can see now, that having immutable data and no hidden state are essential parts of writing good scalable applications. 

But again, there's no use of app that don't change it's state. Why will you need web server that won't change state of tcp connection from listen to open to close? :)

So I think if you want to have programming language usable by general public you have to do it multi paradigm. For me best example is Erlang. Language structured on basis of pure functional core language used to write stateful servers. i.e. you can't do i=i+1, but can do put(i, get(i)+1); you can't set global variables, but can register global names for processes (more sophisticated goroutines). That approach when all non-pure functional behavior done by authors of language and is well tested; and programmers encouraged to write simple pure functional handlers for servers or fsms (gen_server and gen_fsm).

What I described above is essential to be able to do things like hot code swap, when you can upgrade all of your application code without even stopping it. Utilities of language that will cover that very non-functional move having in mind that your handlers are pure functions so they will need only state (which is just one Erlang variable) and message. So you can wait until server replies to message, take state of server and now next message can be handled by new version of code, and it's will be done by OTP framework semi-automatically.

On Thursday, April 19, 2012 11:57:28 PM UTC+4, Ian Lance Taylor wrote:

josvazg writes:

[Joubin Houshyar]

This was a very interesting post, as usual, Michael. Have been meaning
to get back to you (and OP) regarding this subject matter, but frankly
a hesitation not to unintentionally offend prompted discretion. That
said, a review of the referenced page making light of the /
substantial/ contributions of Dr. Alan Kay and the regrettable
collective ad-hom/"critique" of EWD indicated that apparently such
discretion is uncalled for in this field.

The development and promotion of software paradigms and languages is a
matter of collective concern as it clearly is a drain on humanity's
resources, in terms of time, materials, effort, and (most critically)
brains. I would think it fair to assert, for example, that the
original authors of C language never expected that their language
would remain viable and in pervasive use in the 21st century, nor did
their utilitarian conception of the interface between the UNIX
operating system and system languages e.g. void *malloc(size_t) turn
out to be the conceptual bottle-neck between the modern hardware (of
the same un-seen century) and systems and languages that have to
struggle with that narrow semantic interface between purposive user
land software and the poorly informed OS mechanisms grasping at
heuristic straws in the temporal wind.

Given that now it is abundantly clear that civilization and society
will in short order be /entirely/ dependent for continued success and
viability on software, and that our very intellectual heritage will be
kept in ransom by software systems, it absolutely behooves the thought
leaders in this field to put aside un-helpful chauvinism for their pet
theories and paradigms and get on with 'the collective program', that
is 'progress'.

We need software that can be readily devised, implemented, and
maintained, subject to a rigorous industrial regiment, given that the
demand on the mind product of practitioners in the field -- from
"lowly" IT cube farm workers on up to the exalted realms -- is
industrial in scale and scope, and, our very lives will soon come to
fully depend on the correctness and robustness of software systems
that are the product of these practioners.

Every single applied intellectual field of mankind is minimally
properly categorizable as 'engineering' (without blushing), and some
even are (gasp!) scientific. That is all except one, namely
software. In every other practical field of inquiry, mankind has
managed to out grow the supremacy of 'belief systems', but alas,
software's thought leaders remain insistent on promoting group thought
and petty chauvinism.

After all, what can possibly explain ill considered statements such as
"Object-oriented programming is an exceptionally bad idea which could
only have originated in California" from otherwise clearly intelligent
people?

http://harmful.cat-v.org/software/OO_programming/

Even a superficial survey of the developmental history of various
domains of thought underlines the fact that such attitudes are
indicative of a lack of a rational basis for conceptualization. It is
perfectly reasonable for artists and perhaps even architects to argue
over 'the one true way', but such an attitude is not only un-seemly
for engineers and scientists (theoretical physicists notwithstanding),
but it clearly also counter productive.

Here is "Dr." Dijkstra's careless dismissal of a fellow computer
"scientist" that is well worth quoting at length as a specimen of the
narrow mindedness that is the inevitable fate of a mind (however
powerful) in thrall of belief systems:

. He presents the proving of the correctness of programs
. as an activity reserved for geniuses: "The complexity
. of this axiomatic game of proving facts about von Neumann
. programs makes the successes of its practitioners all
. the more admirable. Their success rests on two factors
. in addition to their ingenuity". And then comes his
. fundamental complaint "In any case, proofs about programs
. use the language of logic, not the language of programs.
. Proofs talk about programs but cannot involve them directly [? EWD]
. since the axioms of von Neumann languages are so unusable."
. and he presents as an advantage --without questioning-- that
. in his system "Algebraic transformations and proofs use the
. language of the programs themselves, rather than the language
. of logic, which talks about programs." I am not quite sure
. what is meant by talking proofs and talking logic. But
. whereas machines must be able to execute programs (without
. understanding them), people must be able to understand them
. (without executing them). These two activities are so utterly
. disconnected --the one can take place without the other-- that
. I fail to see the claimed advantage of being so "monolingual".
. (It may appear perhaps as an advantage to someone who has not
. grasped yet the postulational [sic] method for defining programming
. language semantics and still tries to understand programs in
. terms of an underlying computational model. Backus's section
. "Classification of Models" could be a further indication that
. he still belongs to that category. If that indication is correct,
. his objection is less against von Neumann programs than against
. his own clumsy way of trying to understand them.)"

http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html

If the man wasn't so ornery, and still present, one would clarify the
matter that is apparently so opaque to him.

Let's put aside for the moment that it is no longer even /practically/
correct to assert that "machines must be able to execute programs
(without understanding them)". Even fully accepting that conceptual
disconnect, the following is not subject to reasonable debate:

LP verifies 'the intent'; FP verifies 'the artifact'.

One can 'logically prove' that some algorithm indeed sorts numbers in
given order, with such and such time and space characteristics. But
logical proof has absolutely nothing to say about whether the same
algorithm rendered in (say) C on the a "von Neumann" machine having n
cores and virtual memory and tasked with sorting gigabytes of numbers
will in fact perform as expected ("proven"), to say nothing of the
fact that the program in question may contain unintentional errors by
the programmer.

Thus "Proofs talk about programs but cannot involve them directly".

If the field did not suffer from the malaise of belief systems that
prevents the various factions from constructively engaging one
another, we may had already found ourselves in possession of the
'perfect programming paradigm' that provided the entirely rational
workflow of `logician -> LP -> machine-as-programmer -> FP ->
hardware` that would bridge the "disconnect" and forever guarantee
'perfect' programs that would be effectively manufactured. And in
such a world, a handful of "geniuses" would devise 'logical programs"
and EDW may have been celebrated for being a rock star hacker instead
of a theoretician. And if software driven systems suffered
catastrophic failures, we could righteously point the finger at the
hardware engineers and say "talk to them". And the rest of us would
likely had found ourselves satisfying our intellectual curiosity in
service of other pressing matters instead of the present case where we
find some of the best and brightest educated in diverse fields
bunkered in cube farms or start ups writing what basically amounts to
glorified book keeping. It is such a sad state of affairs. And we're
certainly going to pay for this brain drain.

So to conclude, and address the OP, these are the facts: Thought
leaders of the various 'schools' and their acolytes are each and
everyone highly capable thinkers and programmers. So it is perfectly
natural for them to in fact believe that their way is the 'one true
way'. It is so easy for them and they get things done. The very same
people would of course excel applying the other ridiculed paradigm
with equal success and ease. But because we're stuck in what most
generously can be termed as pre-industrial 'arts and crafts' mindset,
they do not do so, and actively encourage others to follow in their
foot steps. Please do not tell "non-technical" people that X is good
and Y is bad. It is hardly constructive to spread superstition. Tell
them we programmers are still struggling to figure out a common ground
of Reason and have yet to rid ourselves of priests and acolytes and
contentious dogmas.

/end-rant

On Apr 19, 5:46 pm, Michael Jones <m...@google.com> wrote:
> I recommend reading Backus' Turing Award paper on FP and his later,
> second-generation FL:
>
> FP:  http://www.stanford.edu/class/cs242/readings/backus.pdf
> FL:  http://theory.stanford.edu/~aiken/publications/trs/FLProject.pdf
>
> You might want to read Dijkstra's review of FP. Harsh in his way but cogent:http://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD692.html
>
> One of my favorite languages is J, the intellectual heir of all that
> is/was APL. J has a strong sense of FP in it, especially when you get
> into Tacit expressions. This "essay" discusses them but does so in the
> manner of English Cricket, which only makes sense to those to whom it
> previously made sense:http://www.jsoftware.com/jwiki/Essays/Tacit%20Expressions
>
> If you're intrigued, then read the beautiful guide by my friend, the
> great Henry Rich. It is in section 36 of his book J for C Programmers
> (included with J and linked from here in Word and PDF form:http://www.jsoftware.com/jwiki/Books)

(Thank you for this ref, btw.)

>
> There is another language within J, a microcode for J as it were.
> Like Moliere's M. Jourdain, who was astonished to find he had been
> speaking prose for forty years without knowing it, you have been using
> a small subset of this language unwittingly throughout our
> investigations.  The hidden language describes a way of coding called
> tacit programming, and it is time for you to learn it in full.  J's
> tacit language is the irreducible essence of a programming language.
> It describes your algorithm using only the ordering of the J
> primitives you have already learned.  It has a grammar without words,
> which you use to write programs without visible operands; yet its
> renouncing these seemingly essential components is self-denial rather
> than self-mutilation, for it retains the vigor to express any
> algorithm.  It is as evanescent as the breeze and as powerful as the
> hurricane.  It is a sublime creation.
>
> It is very educational to learn J and from that you will see what
> Backus wash talking about.
>

> On Thu, Apr 19, 2012 at 5:13 PM, Ian Lance Taylor <i...@google.com> wrote:

[josvazg]

I quite agree.

Software engineering is quite a young field, nearly every other field in science and engineering is centuries older than Software, some of them, like architecture or civil engineering are even tens of centuries older. This field is still to find its solid scientific roots.

I started this thread in order to learn about _pragmatic_ reasons for when using OO and FP AND ALSO WHEN NOT to use them.

What I learned so far is:

- Pure paradigms suck sooner or later, it happens to OO, imperative programming, FP, and you name it. At some point you will be facing a problem which solution is better done in another paradigm or by mixing paradigm concepts and THAT will NOT always be obvious, cause the problems may be delayed to the maintenance phase, when trying to refactor, when extending or reuse the software, when debugging corner cases, etc

- Pure FP doesn't make sense, cause in real life "state happens" (just as "shit happens") and you have to deal with it, not try to avoid it. It is good to know about FP and its benefits and USE IT as much as you can in solving certain problem areas on the system you are designing or developing, in some cases you might be able to avoid state completely so you could go FP all the way down, but most of the time FP will be relegated to some areas when the rest of the program will have to deal with state and traditional imperative coding.

- Pure OO is quite dangerous. It seems to be very good for conceptualizing and going from problem statement to design and then to coding. But some of the luggage that comes with OO, mostly inheritance and its implications, imposes hidden costs to the software that appear at the maintenance, extension and reuse phases. OO also tends to make simple things more complex than they should be, specially in small systems, so it is better to avoid thinking always in object terms and thus it is preferably to have a language that does NOT force you to make a class for anything and everything. 

It may be still unclear which OO concepts do more good than bad in which situations and which ones are better to avoid in some or any case, but I think Go is a good step in that direction. I also think that the basic FP support in Go AND the fact that it doesn't force you to pure FP is a good thing (maybe it would be good to have a helper tool to analyse your code to tell you when are you complying to strict FP rules in a package or set of go sources, when you are aiming at it)

Jose

[Jim Whitehead II]

On Thu, Apr 26, 2012 at 8:53 AM, josvazg <jos...@gmail.com> wrote:
> I quite agree.
>
> Software engineering is quite a young field, nearly every other field in
> science and engineering is centuries older than Software, some of them, like
> architecture or civil engineering are even tens of centuries older. This
> field is still to find its solid scientific roots.
>
> I started this thread in order to learn about _pragmatic_ reasons for when
> using OO and FP AND ALSO WHEN NOT to use them.
>
> What I learned so far is:
>
> - Pure paradigms suck sooner or later, it happens to OO, imperative
> programming, FP, and you name it. At some point you will be facing a problem
> which solution is better done in another paradigm or by mixing paradigm
> concepts and THAT will NOT always be obvious, cause the problems may be
> delayed to the maintenance phase, when trying to refactor, when extending or
> reuse the software, when debugging corner cases, etc

As long as you understand that this is not a case for avoiding a
programming language that is (as you say) a pure paradigm language. As
engineers, it is incredibly important that we make use of the best
tools for the given job at hand. Sometimes that's a language like
python or Go which can be nudged in whichever direction we need it,
and in other cases it is indeed a pure paradigm programming language.

Programming paradigms are just mental models that map to the features
present in a programming language.

> - Pure FP doesn't make sense, cause in real life "state happens" (just as
> "shit happens") and you have to deal with it, not try to avoid it. It is
> good to know about FP and its benefits and USE IT as much as you can in
> solving certain problem areas on the system you are designing or developing,
> in some cases you might be able to avoid state completely so you could go FP
> all the way down, but most of the time FP will be relegated to some areas
> when the rest of the program will have to deal with state and traditional
> imperative coding.

Purely functional programming languages can quite happily handle state
and in many cases its not even terribly difficult to use. Expressing
the concepts of state change can be more difficult in purely
functional programming languages, but that doesn't mean they can't be
expressed. Again, it's about choosing the right tool. Sometimes, it
might make sense to (as you say) mix FP with some other part of your
program which is inherently stateful, keeping the functional part
pure. Other times, it will make way more sense to work with the state
monad, or use the concurrency mechanisms provided in a purely
functional programming language.

> - Pure OO is quite dangerous. It seems to be very good for conceptualizing
> and going from problem statement to design and then to coding. But some of
> the luggage that comes with OO, mostly inheritance and its implications,
> imposes hidden costs to the software that appear at the maintenance,
> extension and reuse phases. OO also tends to make simple things more complex
> than they should be, specially in small systems, so it is better to avoid
> thinking always in object terms and thus it is preferably to have a language
> that does NOT force you to make a class for anything and everything.

I think danger is a massive overstatement here. The major problem that
I personally have with object oriented programming are the constructs
that are disallowed in the languages. I shouldn't have to jump through
hoops and create a new class just to create a simple closure, and I
get upset with languages that force me to do this. Callables in Java
are nice and consistent, but they're just not nice to work with. I
agree with the rest of your statements here, but I think saying that
there is an inherent danger to OO is a bit silly.

> It may be still unclear which OO concepts do more good than bad in which
> situations and which ones are better to avoid in some or any case, but I
> think Go is a good step in that direction. I also think that the basic FP
> support in Go AND the fact that it doesn't force you to pure FP is a good
> thing (maybe it would be good to have a helper tool to analyse your code to
> tell you when are you complying to strict FP rules in a package or set of go
> sources, when you are aiming at it)

Just be careful when presenting any of this. Go is great at some
things, but it has its own particular set of mixed dogma that comes
with the language. If you want to think in terms of classes an
inheritance, than Go isn't for you (and that is a quite reasonable
model to think about building systems in). If you want pattern
matching, then Go won't work for you. If you want a language that
allows you to control your own memory allocation and deallocation
explicitly (alongside the GC if desired), then again Go won't work for
you.

I find any sort of pontificating about programming *paradigms* to be a
bit hypocritical. Each language is going to choose a subset of the
available mental models for programming along with some syntax that
makes it easy to express those ideas. Like any other purchase or
choice in your life or profession, you should consider that you
consider important to your work, and investigate the solution that
best fits.

Just some thoughts,

- Jim

[Paul Borman]

"Atlas Shrugged" by Ayn Rand

[Joubin Houshyar]

"Discourse on Inequality" by Jean-Jacques Rousseau