Episode One

Hello there, and welcome to Episode One of ProScala podcasts. This is the first tech episode released on the 22nd of February, 2021,  that follows a series of prequel episodes. After a short introduction, we will detail some tech topics targeting both newbies, senior and business audiences. I’m Csaba Kincses; we’ll start in a moment.

For you, who are new to this podcast, we talked about non-tech topics like what this show will be about in general, what are its concepts, and the purpose of the membership model that will be built around it. As given these non-tech episodes, you have the opportunity to go into detail about these topics listening to a specific record; I would like to highlight the 3 main community goals stated in these chapters as these have some specific importance.

The spreading knowledge of some aspects of programming, and launching processes make it better, and let a financially sustainable business to be built around the show.

Aligned with the philosophy of making programming better, how the podcast approaches tech is focused on an advanced concept: functional programming and, more specifically, Scala, the scalable programming language.

I have to introduce you to some details of how the outline of a tech based episode works for we did not have such one yet. So, as mentioned earlier, the show is focused on three audience segments, newbies, seniors and business, this may need further explanation. As for aspects of programming, the focus is scalability and agility and the tool is Scala programming, therefore besides juniors, I refer to curious Java or other programmers willing to learn more as newbies and mostly Scala seniors as seniors. Business meant to be the people who are in the position of choosing Scala for example as an implementation technology or do a hiring or strategic decision to go in that way.

I’d like to bring these three groups in one community to open up a wide discussion between them and I’m convinced by previously made research on this topic that this serves the aforementioned three community goals as well.

It’s not an easy task to create something entertaining for all the mentioned three groups. Still, I believe in revealing the big picture for all of them in the podcast, for then supporting spoken content with hackable technological details either on Github or a community site can be the working formula.

Episodes shall be released on a long paced schedule, in most cases two months due to the work intensity of creating an episode and the background community-building activity both needed resources.

Please be noted that this is a proof concept episode for testing ways of making all the three audience segments - newbies, seniors, and business - happy, highly relying on making comparisons, for example, between Java and Scala solutions, presenting these in an educative way interesting for all, so I would like to ask everybody to be patient listening to the content addressed for various audiences.

You may ask the question being in a specific segment of the audience that why would you necessarily need to listen to the content originally intended for other kinds of people? I have a value proposition for all of you on why to listen to the whole show. Newbie content can be interesting for all sides as it is good for repetition, and the business side could actually get an idea of what programming is without needing to go too deep into the details. Senior content can help everyone get a clue on the big picture, and the business side can get an idea of the crucial tech decisions they may also find it vital for understanding. Business content can be of great support in thinking about how to reason decision-makers in regard to a specific development-related idea.

There are two more introductory topics you should be aware of, firstly as it was stated in the very first Episode Zero non-tech episode, I have an unfinished pet project trading robot and found it a good one for demonstrative purposes for that dealing with such a project’s technological details, we can learn a lot together about scalable software design and Scala itself.

Mind that I’m keen on creating demonstrative projects, so we won’t go right away to check out final architectures but look into many ways an implementation can be approached.

One more important thing is that the content is built on top of the previous one, so it is highly recommended to listen to the chapters in the order they were released.

The main topic of this episode is why functional programming should be taught in schools instead of imperative?

Firstly, I’d like to check out the big picture and the most common reasons for the current state by checking out some highlights targeting all my audiences.

In the overwhelming majority of cases, an imperative programming language is taught in schools, I mean elementary or high schools with which both my tech and non-tech audiences are affected. How do these programming paradigms differ and what could be the reason why imperative is taught in the first place? Not to talk about the technical details, why these differences can be important from a business perspective?

Let me clarify that in the end I want to give you an aha moment, that functional programming or more likely a better way of thinking in programming would highly benefit both the technical and business side, and the current mainstream educational system mostly poisons minds with something harmfully oversimplified.

I will go deep into the details to make things clear.

There are no exact answers for what could have led to the advantage of imperative, so I had to do some research. I realized that there might be multiple reasons, of which it would be instructive to go through.

Firstly, I need to introduce the terms low-level and high-level programming, which basically describes the distance from the computer's actual hardware logic. Low-level means the programming language looks much like something that is aimed to show you what happens on the computer level, whilst high-level is much like something that is designed to be closer to human understanding.

One might think that introducing the very basics that a computer has memory: there we introduce variables, wrongfully, and that a computer can do processing and by that we introduce procedures and commands also without giving any real context to these elements could be the only way to start teaching programming, and this results in making the learning curve of functional languages and problem-solving even steeper.

But why would we favor Functional versus imperative, and what does this have to do with low-level and high-level? In a nutshell, functional programming focuses on the “what” instead of the “how”, so basically, when you read a well-written functional program, you should have a better idea of what the program actually does, contrary to the concept of an imperative program, that is more likely to be focused on the “how.” How does the machine do those operations in terms of introducing a series of instructions and tweaking memory?

Taking these into account, it’s easy to figure out that a functional program is obviously more high-level than an imperative one.

Second point: historical reasons. Naturally imperative, low-level languages are more established by considering the historical evolution of computers and software development. It has been a quite short time when the focus shifted from fitting in a small capacity device to focus on the human as a precious resource. Of course, if computers would have been some rapid discovery giving us something of high capacity from the very first days, it would be a rational decision to start with creating human-friendly languages, but remember the huge dimensions of the first machines like ENIAC or the poor technical capacities of the PC’s of the 80s compared to even a recent smartphone.

Historically, the programming scene has come into existence in the 40s to start a long trajectory towards today’s modern programming has only come up with some commonly used functional programming languages like Haskell or Scala in the 90s and after the Millenium. However, some earlier ones already existed that did not really get traction.

Simply put, for the aforementioned reasons, imperative languages are more well-established, even considering that it would be a no-brainer to design something human friendly in an age of cheap computing capacity and expensive human resources. And being more well-established means more teachers understand it compared to functional languages.

And to handle a possible objection from the business side, functional programming is not something experimental, and it is widely used in production environments. Still, it takes a long time for the educational system to react.

Let’s revisit some common points from both the business and technical sides as surely all of us are affected. We’ve tried to answer why functional programming should be taught in schools instead of imperative by looking at the status quo and the main reasons behind it.

By doing this and learning about some related topics, we’ve already encountered some bits of what meant to be the problem with the current state.

I guess that my business listeners who are likely to be involved in something highly digital-related may have an idea from a gut feeling that there’s an oversimplification issue here; there’s much more to programming than writing a statement executing something, and setting a variable.

I still owe you an answer to the original question; I will do this by mentioning the main problem a functional language can solve, considering educating it, and making a minor glance at what’s on the contrary. We will need to go through the main advantages given by such a language, both taking into account the technical and business side and to reach a bottom line. Once we are done with these, we can introduce a side topic going even deeper into detail.

The main problem with not teaching functional programming in the first place is an oversimplification issue from my perspective, as there’s much more to today's programming and its economic surroundings than merely treating a computer as some mechanical slave for historical reasons that can do some calculations and that’s all.

The point is, if you treat it that simply, you skip over the fact that useful knowledge around programming acknowledges that the whole process of software development and even how we treat a wider range of tech centric organizations should be done in an agile way, and given the possibility of having a clue from the roots of teaching this, why wouldn’t we do that?

A shorter explanation of the main problem you can now understand given the aforementioned clues is that I think education in most cases does not reflect the digitalized nature of the current state of the economy.

On the contrary about teaching for example functional programming to tackle these issues, some may say that there comes a  learning curve with this and why would someone learn about broader issues of software development and digitalized culture who does not want to become a software developer? I could address this objection by asking another question: will it be useful to learn an imperative language for someone who does not want to deal with it professionally? Probably in most cases not.

Ok, now we have lots of general information on why it would be beneficial to learn something different in the first place to give an adequate answer for today’s challenges. However, you may still have many questions why would that be good concretely?

Let’s focus on the advantages of an educational shift towards functional programming, such being the case, what would Scala give to programming and business thinking?

Peeking back to what was said on the digitized nature of these days, we can say that we may expect some ingenuity in education bringing in something useful that is by its nature agile, killing two birds with one stone this way, using this very first encounter of a person with programming.

Previously computers were some niche thing, now all advanced work culture is built around it, with that being said it won’t be an exaggeration to tell everyone about examples how this thing as a whole can work efficiently.

Before enumerating them, my business audience may need a better understanding of the nature of technologically agile advantages; in a modern organization these are closer to the business side than you might think. So the point is even if you practice agile roles whether written or not, you need to know that the whole process is to provide advantages by bringing the business and technical side closer to each other.

This can be treated as agile has some messages for the participants. The first message could be the involvement of the business side in a technological creative process brings in high value business assets, which are more flexible, a result that is much closer to requirements and as the parties learn to speak each other’s language, blame culture is removed.

Agile enforces the business side to think more like their developer colleagues and vice versa. I still don’t say that someone on the business side should become a professional programmer but at least knowing about some basics to be able to understand principles which lead to better group performance results is vital.

In today’s digitalized business and culture, it is inevitable to build a skill to become involved in technological decisions. Firstly, if you like higher control, you can realise how many business decisions which previously seemed somewhat technological decisions, could have been done for you by your developers. Also, you can better avoid common failure patterns like the sunk cost fallacy that can easily be realised by your software developer colleagues, and their requests may seem some postponable technical detail development, but they are actually willing to push through a business innovation with a good return. Can you recall a case when your software developers asked to completely rewrite a whole system but management insisted on the old technology because of vast previous investment that was made into it?

As I hope all my audiences realize how having a common understanding of some basic tech can help both sides be better in agile, I shall go through the previously mentioned advantages of using and educating a functional programming language, in this case, Scala.

So, the advantages are the previously mentioned “what instead of how” nature of functional languages. You get patterns as language features, and Scala is for these characteristics can be treated as something that enforces clean code usage.

Let’s inspect the “what instead of how” feature from an educational and a business aspect! As was spoken, breaking down the facts about low and high-level languages, this feature makes, in this case, Scala more human-friendly, easy to debug and maintain, and this should be obvious on both sides that it's not just a convenience feature. If less debugging is needed, this puts money on the table. Another advantage, considering the educational aspect, is a functional language's learning curve could be less steep   as a first impression, because newcomers will treat the way it is organized, as a natural thing.

Checking out the patterns as language feature traits, I should tell non-tech, patterns if not built-in, are something to be learned, and are on an advanced level, so not all of the programmer colleagues will know about them, and if not built-in, that’s always a possible error source. Seeing things from the educational side, it is always a good take to have a tool to make someone learn something easily compared to other ways, and this feature of Scala is a huge help.

The last one, but the most important, is that with its first two characteristics and functional principles in general, Scala enforces clean and compact coding with less boilerplate, which is again, aside from being a convenience feature, a great business advantage as well, because it makes the code maintainable and extendable.

Concluding, we have great answers for the original question, whether Functional, for example Scala should be taught in schools instead of imperative languages, namely with Scala we have a tool to introduce everyone to agile focused development.

Finally, we‘ve arrived at our side topic, diving deeper into how Scala enforces clean code, which is a huge benefit on the programming side and a lucrative business asset considering that you can make long lasting software with your team.

Though, this part of the show is more technical, still, I believe it can be a useful part of a learning journey for both Java or other imperative language programmers to learn new, and business decision-makers to get their mindset closer to a technologically agile way of thinking to improve communication with their tech colleagues.

So even though this part of the chapter is highly technical, I do think it would be gratifying to listen to it by all my audiences cause having a tool enforcing quality code, even considering junior developers who might not have that much experience with design patterns because we have many such features for granted. The language, by its nature, enforces techniques toward intuitively well-written code, is a great asset.

Considering the subject of clean code and reflecting the low-level versus high-level debate of the previous topic, it is recommendable to pin that it’s better to write programs that humans understand, though easier to write something a machine understands. At the same place, one still needs to understand a lot about the low-level operation of a computer in order to keep the working parts of a high-level program together.

It’s widespread with Scala that developers use patterns provided intuitively, without even knowing. Of course, migrating as a senior developer from a language like Java knowing some patterns will give you a clue about which built-in Scala language feature is the equivalent.

We have the chance to approach the question of how Scala enforces clean code by looking into some root features by examining the way design pattern implementations work in Scala.

We’ll start with briefly going through the root features, reflecting how a functional language differs.

The first root feature we should have a look at is the heavy use of constants, meaning though there is a fallback option present of not using these, the functional way is to implement everything with final immutable values.

This results in easy to follow code once you’ve got used to it, and this removes the possibility of bringing in hard to debug issues changing a value at a place where it won’t have been logical. Though you are not restricted to this, something similar applies for methods, as in a Scala-ish implementation, they should not have side effects like setting some state in a variable outside their scope. And if the general pattern of using constants is followed, most likely you will end up using such methods being referentially transparent, they do their thing, and with the same input, they should return the same result.

You can easily see that the aforementioned characteristics apply, we have some  learning curve, especially if migrating from an imperative background, but that results in something easier to maintain.

The second root feature is that in Scala, everything is an object. There are no special exceptions, like primitive values in Java, and functions are also first-class objects natively. I know that some functional features started to appear in originally imperative languages like Java. Still, Scala is built from the ground up, having its syntax created for these so that you can concisely use these features.

Let’s focus on functions being objects, hence comes the functional paradigm. Because of this feature, functions can be easily passed as arguments, used as return values, or assigned to values. And why is this a paradigm maker? The reason is the widespread usage of passing callbacks to modify specific value containers' contents, resulting in a new value. Basically, solving problems in such a way is the functional way of thinking. F or example, this is something can be unfamiliar for somebody who is used to imperative solutions.

And why is this a game-changer in terms of productivity? For instance, this is when the aforementioned “what instead of how” focus of functional languages most clearly manifests. With this feature, you may see a chain of callbacks modifying a value to transform it to another value, all the “how” focus is abstracted away. You get human-readable code in clear and easy to follow blocks doing their thing with data.

The third noteworthy feature is that in Scala, every block returns a value. You don’t need a statement to force this, as this is the default behavior. This is handy in enforcing the “what instead of how” principle, as you can put a code block in an assignment, it can be seen right away what kind of logic was implemented.

The bottom line with these features is they can bring some centralization to the code as the whole thing is focused on seeing the “what” logical steps in one place and boilerplate code deep beneath, but clearly, that’s the point. Why would you on any side, even business or tech be happier, if the project is messed up with many layers acting at one place as boilerplate being in a situation when you have no clear entry points?

On the business side, you may say that the hierarchization of code parts can open the way to let one have overly high responsibility with a modification. Still, you do have both senior and junior developers, most likely. So such a coding method would reflect the actual hierarchy of an existing tech organization.

We’re diving deeper into tech to give further details for developer audiences about some more advanced related topics; this is where checking out design pattern implementations in Scala comes in. The topic is about how Scala enforces clean code, it is important to highlight that we get design patterns as language features out of the box. In many other programming languages, a design pattern is made up of lower-level components of a language. In Scala, you get specific syntaxes that implement common design patterns out of the box in a compact way.

We will focus on the design patterns that are equivalent to similar patterns in other languages, but we get them for granted in Scala.

The pattern set that we get as a language feature out of the box encompasses at least 7 built-in patterns as language features. Though in an audio format, we do not have the chance to check out code examples line by line, we still have the ability to highlight how compact the resulting code can get.

The great advantage: using patterns with Scala, is not rocket science anymore, junior Scala developers can also easily use the built-in patterns intuitively without pattern specific training as in most cases, if one has a basic understanding of the functional style Scala provides, then come built-in patterns into use simply, because they are handy and easy to derive from the general logic of this language.

So the next thing we can do here is go through what we have been provided, get some clue how compact these are compared to, for instance, a Java solution, and once we get to have a community site launched around this show, you will have the chance to get your hands dirty with code having some community mentoring.

Let’s start with a Scala feature that is highly demonstrative regarding how Scala gets us rid of boilerplate code. I’ll introduce the feature case classes, a truly functional feature related to more than one pattern.

Explaining what these are, I would refer to the value object pattern being pre-implemented for us, so we only need to write a one-liner. Unlike Java, we don’t need any boilerplate code with custom equals implementations; we get a value comparable entity out of the box.

This feature can flexibly be overridden. By default, it's immutable, but you can even treat it as a POJO. As an extra, we get implementations in the background making this thing helpful in pattern matching, which is really common in Scala. To make it even more concise, no “new” keyword is needed for instantiation.

Noting how useful and compact this is, you can solve a 5 to 10 lines problem with a single line, so this is a true productivity feature.

I’ll continue with Scala’s built-in singleton solution, which is also a one-liner, so no need for private constructors and instance getters. You get these out of the box with one simple “object” keyword. This feature has an added trait: an object for a class with the same name will act as a companion object. There will be a special relationship between the two regarding members' visibility.

Though not so many lines can be spared, Scala makes it easy to create a seamless implementation of the adapter pattern with a built-in feature to make an otherwise incompatible interface compatible with another. This is called implicit class, and it is also widely used to give some extended functionality to something in the background.

Scala also has a convenience feature called stackable traits to replace a decorator pattern solution. The advantage of this is that it's easy to see through what happens as you can instantiate a class with a chosen trait added just using a few built-in keywords. It’s important to see that Scala is designed to be expressive again to let you focus on the what instead of the how.

Once someone gets familiar with the use of functions as values, it is easy to intuitively come to using a strategy pattern, as it is basically returning a function from a set of functions conditionally, what Scala offers here compared to a pure imperative solution is that you can pass around callbacks.

Broader topics but outwith the scope of this episode are pure functional patterns and monadic behavior. Compared to recent check out on common imperative pattern replacement, that would be the part where a learning curve begins. As was mentioned earlier when I broke down the “what” nature of Scala and the heavy usage of constants, there will be a lot to learn about chaining, and this is where more functional like patterns will come in.

This chapter is about to end, I’ll be back with a new one on the 19th of April, 2021. This will be about a minor case study of the pet project of the show and Scala's suitability to implement it.

I hope now you at both sides have a deeper understanding about how Scala and Functional can save time and money for you, looking to give you a better outlook after scratching the surface with the previous countable benefits going further to take a look at the project planning level characteristics of Functional.

I was Csaba Kincses, be back to you at the next episode; thanks for listening!