I originally missed this as back then I was in the midst of managing trouble in my parental family, unaware I was already having rectum cancer. Then things went fast, not even including the Covid-19 years, so I was glad last year I got reminded of this mid-2019 article:
In his rare 1994 book “Object-Oriented Programming In C” Axel Tobias Schreiner explains how to do inheritance, class methods, class hierarchies, and even how to raise exceptions using nothing else than pure, simple, pointer arithmetic-filled, ANSI C.
then arguing basically most of not all modern languages share the majority of programming paradigms and all these paradigms are repeats of the past:
But none of this is new. Smalltalk, arguably the precursor of object orientation, had collect and select methods which were the grandparents of our more common map and filter functional friends.
What sets modern languages apart is that they the majority covers all the paradigms you might need, just differing in how well they support the paradigm-du-jour.
It means programming language wars should have been a thing of the past for about two decades now.
Many articles have been published on the Google Leaks earlier this year including a Twitter Thread by Henk van Ess. I will mention his and the original starting article which should give anyone hand and feet to dig deeper and assess for themselves how fast Google might be able to change this and get a feeling on much of it is still relevant over time.
A few days ago I tweeted a C# code snippet, showing a FizzBuzz implementation using some of the new features in C# 8.0. The tweet “went viral”, as the kids say, with several people admiring the terse
Great introduction into functional programming by a step by step: “Why Functional Programming Matters”, by Ted Neward on Devoxx Poland 2016.
It uses Java, but translates very well into C#, C++, Delphi and many other programming languages because the underlying support structures are very easy (a ~50 line Lists class, a few Function# prototypes, etc).
Two great observations here:
most variables don’t vary
collections are the gateway drug to becoming functional programmers
Summary
Coding Tech
In the latter half of the 2000s, a new kind of programming language seemed poised to take the steam out of the dominancen of object-oriented programming languages and their hold over “mainstream” development. But these new languages, collectively referred to as “functional” languages, were nothing new. In fact, they’ve been a part of the language landscape since the late 80s, and arguably even longer than that. What makes a functional language, and what makes a functional language interesting? Most importantly, why do we care now, thirty years after their introduction?
“Functional programmer: (noun) One who names variables ‘x’, names functions ‘f’, and names code patterns ‘zygohistomorphic prepromorphism.'” — James Iry
4:07 “Functional Programming: What? When? Why?” or “The Failure of State”
5:10 Rich Hickey is the author of Clojure. Listen to his talks. 5:40 What is state? Variables.
11:15 Structure and Interpretation of Computer Programs. This is a fascinating book. For the first 250 pages, the book uses no assignment statements.
14:15 Here’s how SICP’s model of computing worked before they introduced an assignment statement. Simply replace a function call with its implementation.
15:58 Once you introduce assignment. You can no longer replace a function call with its implementation. Why? Because the state of the system may have changed. An assignment statement introduces the concept of time.
18:04 Side effect: an assignment statement. If there’s no assignment, there’s no side effect.
20:22 What “hack” have we done to protect us from memory leaks? Garbage collection.
31:46 Functional programming was invented in 1957 before OO and structured. But memory was too expensive to make it practical. But memory is cheap now.
32:53 Should we change how we program? We should because: 1) Functional programs are simpler – which makes them easier to write and maintain 2) There’s no temporal coupling – no worrying if some function was called before another function. 3) Fewer concurrency issues. In a purely functional program, there’s no concurrency because there is no state. 4) No asking, “What’s the state?”
38:38 We’re using multicore CPU’s now because we can’t increase clock rate anymore. And hardware makers are doing bizarre tradeoffs. They’re making individual processors slower but putting more processors in. So individual cores slow down but the chip throughput goes up if you can take advantage of all the cores.
42:00 How are you going to work with an abundance of cores? Maybe we need to walk away from the assignment statement.
49:49 OO = procedure + state. OO is exposed procedure but hidden state (encapsulation). It’s possible to write functional programs using an OO style. All of the objects become immutable.
The Wiert Corner - irregular stream of stuff 