Hvorfor snakker vi om produkter og digital produktutvikling? Og hva er alternativet? Hvorfor snakker vi ikke om prosjekter eller tjenester?

Hvorfor snakker vi om produkter?

Hey there! In this calendar, we will share CSS tips and tricks! First however, a short recap.

In the beginning, there was HTML. As the language grew and more browsers were created, styling quickly became a problem. Browsers had their own unique "built-in" styling. This made it hard to make a website appear the same across different browsers. The idea of separating structure from the presentation was proposed; to link styling to a document and make it possible to have a different presentation of the same content for different mediums, such as screen and print.

There were several proposals to solve how to style markup, among them the first draft of CSS made by Håkon Wium Lie. Together with Bert Bos, Lie developed his proposal into CSS 1. CSS 1 was published in December 1996, and Internet Explorer - which was released the same year - partially implemented this standard. Internet Explorer 5 was the first browser to support more than 99% of the CSS 1 specification in the year 2000. Other browsers followed, and even implemented parts of CSS 2 in addition.

This became the start of a chaotic period where different browsers supported different features of CSS. The browsers had different quirks - and often had incorrect implementations of the features. This was a difficult period for developers, seeing as creating websites - that looked consistent across different browsers - was almost impossible. Developers were forced to create websites that worked through the premise of not following the standard, but instead the quirks of the browsers of choice. When later versions of browsers corrected their implementation of CSS, they had to add backward compatibility.

Instead of having the new browser defaulting to the better CSS implementation, developers had to specify that the website intended to use the newer version of the CSS implementation. Many developers suffered without need as they were not aware of this new CSS implementation that they could turn to, and make their days better.

Fast forward, today most browsers support CSS2 in a consistent way - making the development experience a lot better. But CSS is still developing, providing new features that let us get even more out of our markup. But this also creates much frustration seeing as developers are often living on the bleeding edge - knowing that some browsers support features they want to use - but knowing some browsers still don't support them.

There still seems to remain some frustrations when styling websites. Some libraries try to make the development experience better, but they often bloat the markup. It seems that because HTML and CSS seem so simple, it is simple to accidentally skip getting to know of certain basic principles one should know of, so as to take full advantage of the languages.

To improve on this situation, and frankly, because we think CSS is awesome, we are sharing articles with tips and tricks throughout each day throughout the rest of this Christmas calendar!

And then there was CSS

Every year, Santa Claus and his helping elves create a special list for every child in the world: the Naughty or Nice list. React has something quite similar – Strict Mode.

What is Strict Mode and why should I use it?

Strict Mode is a feature already introduced to React 16.3 in March 2018. Still, chances are you've never used it before. Strict Mode does not render anything visual (similar to Fragment), but detects potential problems in your code and gives you helpful warnings. Strict Mode runs in development mode only and doesn't affect your production build. With the introduction of Hooks earlier this year and Concurrent Mode just around the corner, Strict Mode is becoming an increasingly important tool for locating bad practices (Concurrent mode probably won't work until you have fixed the warnings thrown in Strict Mode).

Deprecated code and legacy APIs

Like everything else that is made of code, React changes over time and what was once considered state of the art eventually becomes deprecated and replaced. Such as findDOMNode which is deprecated in Strict Mode and possibly will be removed in a future version of React. Other examples are the use of string refs and the legacy context API, both of which cause some issues.

Unsafe lifecycle methods

Since release 16.9, React throws a warning when using any of the lifecycle methods componentWillMount, componentWillReceiveProps and componentWillUpdate. You've hopefully converted these methods into safer alternatives by now (if not, you should at least add an "UNSAFE_" prefix). Strict Mode can help you identify unsafe lifecycle methods in your own code and third-party libraries, and also suggests alternative methods.

Unexpected side effects

In Concurrent Mode, React may trigger the render method multiple times before actually committing the changes (e.g. changing the DOM). Therefore, it is important that this method doesn't contain side effects which can lead to memory leaks and invalid state. Strict Mode can't detect these side effects automatically, but uses a simple yet clever trick to make them easier to spot – the methods constructor, render, setState and getDerivedStateFromProps all get double invoked. If this leads to any weird behaviour in your app, you know what to look for.

How to use Strict Mode?

Fortunately, using Strict Mode is amazingly easy – all you have to do is to wrap whatever you want to use Strict Mode on inside <React.StrictMode />. This can be your entire <App />:

Or just a single component:

This way, you can gradually apply Strict Mode to your app without having to correct everything at once.

If you want to see Strict Mode in action, you should check out this CodeSandbox created by Kent C. Dodds' (warnings can be found in the console output):

How to avoid React's "Naughty List"

Have you ever deployed a static site, but found yourself in need of an API endpoint? Perhaps you needed somewhere to post form data, but the thought of setting up your own server, manage the endpoint and write the logic seemed like too much work. Not anymore

I recently created a static webpage and needed an API endpoint. The page was a simple landing page, with a contact form where potential clients could reach out.The choice of hosting for the site fell on Netlify, and they just happen to have a super simple way of utilizing AWS Lambda Functions.

In this post, I will show you how to setup an API endpoint for whatever your heart desires in three simple steps.

Prerequisites

For the three steps, there are some prerequisites that needs to be met:

Sign up to Netlify.

Install netlify-cli with npm install -g netlify-cli.

Create a repository on Github, or connect an existing repository to your site. The repository cannot be empty when connecting to Netlify.

Create a new site in Netlify with the following command: netlify init and follow the prompt in the terminal.

When prompted if you want the cli to create a netlify.toml-file, select Y (Yes).

1. Create the function

With netlify-cli installed, go ahead and make a new function with the following command

netlify functions:create <name_of_your_function>

This will trigger a prompt with a few different function templates provided by Netlify. For this demonstration I chose hello-world.

2. Write the logic

Open your function in your editor of choice. You may use the template and just skip ahead to step 3 if you want to, or you can switch out the template content with your own logic. I will add the following code which fetches a random quote by Donald Trump on every request. Pay attention to the fact that if you use the Donald Trump example you will have to run npm init and install axios with npm install axios --save to have a working example.

Using the netlify command, you can easily test your function locally. Just run netlify dev and follow the instructions in your terminal.

3. Deploy your function

The last step we should do is make our endpoint available on the internet. This is as simple as running git push with your committed changes. Netlify will deploy your site and after a few seconds you will have an available API endpoint. To get to the admin panel of your site, run netlify open in your terminal. Your endpoint will be available at https://<yoursitename>.netlify.com/.netlify/function/<your_function_name>.

Summary

In this short post, we have seen how easy it is to get started with Netlify functions. With just a few commands using the netlify-cli we have created an api endpoint where you can implement your own logic easily.

Now go ahead and make something awesome!

Take your functions to the cloud with 3 simple steps

Did you know that JavaScript is the world's NO. 1 most popular language? At least according to Github and Stack Overflow it is. As a developer, that is a huge reason to get to know it better, wouldn't you say?

The story

In the great year of 1995, the rumours has it that the American computer scientist Brendan Eich wrote a brand new language. Just through 10 days of work! At this time back in Norway, we were still riding the wave of (finally) hosting the winter olympics in Lillehammer the year before. Sometimes I'm thinking we still are.

At this time, Eich was working for Netscape, one of the coolest tech companies in that decade. He called his brand new programming language "Mocha", but it was later on renamed to LiveScript (when shipped with Netscape Navigator) and later on JavaScript.

Just like the Norwegians, Netscape also wanted to ride the wave, the wave of the super-popular language Java.

Introduced as "the scripting language" for the web, Netscape shipped JavaScript in its newest browser update. What they did not know was that this was going to become the most used programming language in the world just 25 years later.

JavaScript today

Today, many websites are completely and utterly reliant on JavaScript to even work. It is safe to say that the days where websites are only containing HTML and CSS, are gone. Long gone.

Take my life as an example; without Brendan Eich's JavaScript, I wouldn't even get into my local banking services. I wouldn't be able to buy tickets for the tram, I wouldn't be able to chat with all my friends.

The committee and "Not breaking the web"

Thankfully, there are a lot of highly competent people making sure that all the websites we rely on so heavily do not break. The most powerful tech firms of the 21st century is cooperating on improving the technical standard of JavaScript (EcmaScript) through its very own committee, called TC39. The committee is behind all the great improvements to the language, especially in ES6/ES2015 when we got additions to the language such as arrow functions, rest/spread etc.

But did you know that anyone can contribute by composing their own proposals to develop the language further? You can read more about this process here, or just peak at all the cool, already processed proposals over at github.com/tc39/proposals.

And. If you have the time, take a stroll down memory lane and read Eirik's article from last year's calendar on the committee work and the standard itself.

Or, if you're lucky, perhaps one of the coming calendar hatches will be written by one of the maintainers of EcmaScript? Who knows😏.

Follow the calendar!

Keep on reading for technical quirks, explanations, funny ingredients in the JavaScript language and many more, throughout the rest of the days in this Christmas calendar, and pick up a thing or two about the world's most popular language!

Not breaking the web

Welcome to the Bekk 2019 Kotlin advent calendar! In the days leading up to Christmas, we will present you with 24 articles, one for each day, about different topics regarding Kotlin. To start of, we'll give a short presentation of the language and show you how to get started with Kotlin in your existing Java project.

What is Kotlin?

Kotlin is an open source, cross-platform, statically typed, general-purpose programming language with type inference that is fully interoperable with Java. It was started by Jetbrains, and is now supported by them and Google through the Kotlin Foundation.

The name Kotlin comes from the Russian island of Kotlin (or Kotlin island), located west of St. Petersburg. The lead language designer of Kotlin (Andrey Breslav) has reportedly said that the team decided to name it after an island just like Java was named after the Indonesian island of Java. Though, according to Wikipedia, it might as well have been named after the coffee.

Kotlin is really a programing language on the rise, with Google declaring it the official language for android app development on May 7, 2019. The 2019 Stackoverflow developer survey shows that Kotlin is one of the four most loved languages. So, sit back and relax as we take you on a tour of its features.

First up, set up Kotlin in an existing project

We'll go through how to set up Kotlin in both an existing Gradle and Maven project.

Setup in Maven

If your existing project uses Maven, the following dependencies and plugins must be added to the pom.xml-file.

Fist off, the Kotlin standard library:

This library contains all the standard features of Kotlin, like classes, functions and common types like String and Int, to name a few. Then we need the kotlin-maven-plugin, which builds and compiles your code:

The parts to notice here is the sourceDirs which shows the plugin where your main and test source files are located. For a more in depth explanation of the kotlin-maven-plugin see Using Maven.

Setup in Gradle

Setting up Kotlin in Gradle requires quite a bit less code than the Maven setup. Since we are setting up Kotlin, we'll assume that your gradle config is not written in Kotlin and will therefore only show the Groovy-way of doing it.

Depending on what your project targets, the config may vary, but in this project we target the JVM:

Kotlin source files can be put in the same folders as your existing Java sources. But the default convention is to use different folders like this:

If you are not using the default convention, you have to update the sourceSets property in build.gradle like this:

For a more in depth explanation of how to set up Kotlin with Gradle, have a look here: Using Gradle.

And that's all!

You're now all set to write whatever you want in Kotlin, and to tackle the rest of our advent calendar. To get you started with actually writing some code, have a look at the links below, which are all great resources for beginners:

Starting a project from scratch.

Kotlin Koans is one of the most popular and most effective ways to get into Kotlin for people who already know Java.

And of course, the Kotlin documentation.

Get started with Kotlin!

Welcome!

Welcome to our Christmas calendar for machine learning and data science, one of 12 (!) calendars prepared by Bekk this year.

The year is now 2019 and it seems like everyone is talking about AI, machine learning or data science these days. Not so shocking as it has already been several years since even Gartner and Harvard Business Review said that the question was not if you should be using machine learning, but rather how quickly you should do it. Despite the initial hype, people seem to have sobered up, and last year Gartner rather said that one should focus on Narrow AI. That is AI focused on solving one specific problem instead of trying to tackle all problems at once. Come to think of it, that might make us all feel safer as well 😊

I’m getting off track. Despite everyone talking about these topics as if they are self-explanatory there are likely many out there who are wondering how these different concepts fit together and why or how you should use machine learning. It might seem scary to ask someone but have no fear – we’ve got you covered.

Each day until Christmas we will give you a brief introduction into a topic related to the exciting field of machine learning and data science. Although there will be some deep dives into statistics and mathematics everyone should be able to understand the content of the calendar. We will start off by explaining machine learning and the most common techniques. As we get further into December stuff will become a bit more advanced and we will get to see some rather interesting and fun applications of machine learning. In between theory we will make time for some practical cases, business value and pure fun. You might even get some help for your Christmas preparations!

Whether you are an experienced data scientist, an aspiring novice or just curious about data science – this is the Christmas calendar for you.

Stay tuned for tomorrows article where we will start our data science journey towards Christmas.

Finally December!

What is multi-threading?

Java is a multi-threaded language. This means that you can run your Java application, or specific parts of it, in parallel as separate threads. If the computer running the Java program has multiple CPUs, as most modern computers do, then performing tasks concurrently may improve performance and utilize the available resources more efficiently. This sounds great, you may think, let's do this! However, there are a few pitfalls. A Java program is running as a process, and a thread started by your program will have access to all shared data of all other threads that is started by the same process. For instance, if you have a Java application that is responsible for creating and sending the monthly utility bill to all customers of a power company, you really want the bill to contain the right amount for each particular household, and that no bills are being sent with a random combination of customer and amount.

Design your code to be thread safe

If a piece of code can be run by more than one thread without harmful side effects it is said to be thread safe. There are many ways to ensure thread safe code, and we will mention a few in this post.

Immutable objects

Always make your objects immutable. All fields should be private and final, and they should be assigned when the object is created. One of the challenges with multi-threading is that one thread may overwrite fields of an object that is used in another thread. Using immutable objects will make sure that the object cannot be modified after creation by another thread.

Avoid state

Write stateless code as far as possible. If there is no state, then there is no state that can be shared between multiple threads. Stateless code is methods or functions that are independent of anything but the input parameters, and given the same input it will produce the same output every time. Another advantage of stateless code is that you can easily write automatic tests for it as well!

Java functionality for concurrency

Java provides several ways to control what is shared between threads. A common way to make sure that only one thread at a time can access a particular piece of code is by using the synchronized keyword. You can also use a lock to achieve this.

Sometimes you have the opposite problem - you have a field that is being updated, and you want all threads to see the new value. By declaring the field volatile you are forcing the JVM to keep this value in the main memory, and all threads must read the value from there.

And one final gotcha: Many commonly used libraries and even quite basic Java APIs are not thread safe. This includes most collections from the java.util package, almost all OutputStreams, SimpleDateFormat and JAXB Marshaller and Unmarshaller, to mention a few.

Multi-threading is scary, I'll rather not use it!

Yes, multi-threading requires a little more thought, and yes, in many cases you probably don't need to deal with it. But, whenever you create a REST API and deploy it on Jetty or Tomcat or some other application server, then you are in fact running your code on multiple threads. All application servers, even the really light ones, will have a threadpool, and each new request to the API will start a new thread, as long as there are available threads in the threadpool. This is what makes your API able to handle more than one request at a time.

Thread safety in Java

We think Open Source is such an important part of a developer’s life that we’ve devoted an entire advent calendar to the subject! For a lot of developers, the thought of putting your code or ideas out there for the whole community to see, can be daunting. Once you get the hang of it and get more comfortable though, it has a tendency to drag you in.

Let's start by going through your first steps towards your first contribution together.

Getting started

Using Git and GitHub

GitHub is a platform for hosting and collaborating on Git-repositories. You should have a basic understanding of Git in order to contribute.

Create an account on GitHub

In order to contribute to repositories you'll need a GitHub account. Create an account if you don't have one already.

Look for a good first issue

A great way to get started is to look for issues by using www.firsttimersonly.com or searching GitHub for issues marked as good-first-issue.

Here's a few ideas on what typically are low-hanging fruits:

fix errors in the repository's documentation

write missing documentation

fix spelling in code or in documentation

help out on troubleshooting other people's issues

give feedback on pull requests

Before you start working

Look for the README or the CONTRIBUTING file first, you'll usually find those at the repository's root folder.

The maintainers might have a set of requirements that you should fulfill before you start working. Maybe its signing a Contributor License Agreement like the .NET Foundation has or following steps for testing your changes before you create the pull request.

Work on your issue

Once you've found an issue you're comfortable working on, fork the repository to your account and clone your fork to your local machine.

Choose a Git-workflow that suits your preferred way of working on Git and start your work!

When picking an issue and committing time to work on it, it's good practice to write a comment on the issue stating that you're keen on helping out. This lets the repository maintainers know that someone's working on it, they might even assign you to the issue 😀

Tip: refer your pull request and issue by using #<issue/pull request id>. This generates a link to the issue/pull request.

Create a pull request

Once your work is done and you've pushed your changes on your branch to your fork on GitHub, you are ready to create a pull request. This tells the maintainers that your work is ready to be reviewed and your code merged from your branch to the master branch.

Pay attention to the pull request and any build steps it might trigger. If the pull request build fails, you'll need to fix your code so that the build succeeds before continuing.

Check up on your GitHub notifications as you might get comments and need to adjust your work, based on the feedback you'll receive from the maintainers.

Issue fixed and closed

Once the maintainers have completed your pull request, your work is done! On the issue's page you'll see that your pull request has been merged and marked as complete.

Congratulations on your first Open Source contribution! Well done! 🎉👏

How to contribute to Open source

Tada. With this post, I declare UX.christmas hereby launched. Welcome to the world’s first UX advent calendar from Bekk – 24 articles from 24 Bekkers and a rant about roles and tunnel vision.

But first, some context.

What can one expect from a UX advent calendar from Bekk? UX.christmas is a collaborative project where 24 writers have written as many articles, full of industry-relevant tidbits. The “windows” of this advent calendar cover a variety of topics like creativity, storytelling, and product development. Everything from variable fonts and dark patterns (on Friday the 13th of course 👻) to hypothesis testing and digital accessibility.

Some articles are written in English, and some in Norwegian. They are just short enough (2-3 minute read) to squeeze in on the way to work or while you wait for the gingerbread to bake in the oven. But if that isn’t enough to scratch your itch this advent, you can always try out a window on one of the 11 (!) other calendars Bekk is publishing this holiday season. Check out bekk.christmas to see them all.

Here are a couple of sneak previews of what you can come to expect from UX.christmas:\ \ December 4th: Designer Sonja Porter has a wake-up call when it comes to Maslow’s Hierarchy of Needs...

“Way back in 1943 Abraham Maslow published his “Hierarchy of needs” – a pyramid describing the forces that motivate us, and the order in which we strive to meet them. For many designers, this 76-year-old model still informs the design decisions we make every day. But did you know that Maslow moved on to an updated model only a few years later? Or that psychologists stopped using Maslow’s pyramid years ago?“

\ December 6th: Copywriter Erik Mathisen tells us a little story on storytelling (in Norwegian) …

“Historier sender ungene våre til drømmeland. Historier bygger solide merkevarer og får tårer til å trille på kino. Historier skaper helter. Skurker. Presidenter. Mytologier. Konspirasjoner. Legender.



Historier er sentrale i vår fortløpende konstruksjon av virkeligheten.



De er limet som skaper et fornuftig narrativ vi kan forholde oss til i dag, i morgen og til dagen historiene våre er alt som er igjen.



Velkommen til en liten historietime. Om historier.“

Roles and tunnel vision

This year, a couple of us in Bekk’s Interactive department decided to make our own UX advent calendar to compliment the slurry of development calendars produced by the Technology department. Only a breath or two later, a discussion arose about what it would be called and what type of articles we should include. Is “UX” the right term? Does it cover all of the specialities we have in our discipline?

In our industry, there are a ton of titles and role-descriptions for what we do. In Bekk we have Graphic Designers, Interaction Designers, Service Designers, UX Designers, Product Designers, Product Developers, Front-end Developers, Full-stack Developers, and Project Managers to name a few.

These titles make it easy to distinguish between practice areas and foster expertise within our own discipline. They make it easy to identify individuals, assign responsibility within a team, and assure cross-disciplinary collaboration. My experience is that the titles can also create silos and disclaimers within the team.

Interaction Designers facilitate user testing and create user-flows. Visual or Graphic Designers focus on combining visuals and other elements to create clear communication, and developers make sure that the technology delivers. It’s natural for us to want to keep to our own camp and focus on problems that can be solved with our own discipline. But this tunnel vision can severely limit our creative thinking and force us to fall back on obvious solutions.

Being true to your discipline does not always have to be the golden standard. That super-important insight workshop and user test you’ve been planning maybe isn’t the best for your agile team and could hinder other important priorities. Even if you are the design expert in the room, that doesn’t necessarily mean that you have the correct answer when it comes to users, or that you know what is important to prioritise right now.

Who is actually responsible for user experience?

What if the whole team, no matter their background, was more curious about each other's work? Expand your horizons – co-design with a product owner. Practice style and tone of voice with a developer. Take over the customer service lines for a day, or try your hand at in-browser coding. Look past titles and figure out what your teammates are doing. At the end of the day, we are all working together to achieve the same thing (hopefully). By erasing our roles, the whole team can work towards a common goal: the best product for our users. Let the whole team take responsibility and feel ownership of the user experience – not just their own discipline.

A true story:

Everyone is a UXer.

Titles can so easily put us in a box. But why can’t a developer think about tone of voice, while a Visual Designer considers technical architecture and implementation. Just to be clear, I'm not saying that designers should take over and code. By putting titles to the side, a team can collaborate and focus on what they want to achieve. We should be open, challenge one another, not micromanage eachother or cling on to the methods we learned in school. Do we really need these titles, as long as we are delivering value?

Happy December 1st! Thanks for opening the first window of our advent calendar. Remember to follow along for a new design tidbit every day until Christmas Eve.

Helen Le\ – Innovator of Interaction Interpretation & UX.christmas-pusher

The world premiere of UX.christmas

Welcome to the annual Security Christmas Calendar. After weeks of research and writing we are super excited to finally be able to present this year's calendar.

Security is a hot topic, both in various projects we work on and in the mainstream news, both national and internationally. What just a few years ago was an obscure topic discussed only by those in the know, is now on everyone's lips. We hear people talking about ransomware on the bus, and the news regularly reports on international cyber-attacks and crimes.

One of the most profiled incidents in Norway this year was a ransomware attack. As the days were getting longer in March, industry giant Hydro was under siege, probably by the Lockergoga ransomware. The assumed attack vector is email. It is likely that the network was infected by one or more people clicking a link in an email or something to that effect. This snowballed into a major breach which caused Hydro to shut down many of its networks and cost them hundreds of millions NOK. During the outage many industrial plants had to be run manually or some even shut down. Sadly, this is just one example where lack of security causes millions in loss.

Even our personal devices are under attack. We keep our most personal information, which we would like to decide who can access and not, on our smart phones. Even if there is great work being done on the operating system of these devices, there seems to be an endless storm of security updates after each major upgrade. Most users feel safe by using the recommended app stores for their devices. But an increasing number of applications for mobile operating systems have been proven to contain malware, also in the official app stores. There are numerous reports of this, both on Google’s Android and Apples’ IOS.

We hope you will enjoy this years security.christmas as much as we had fun creating it. Please spread the word and please help use make the last weeks of the year a safe one. Remember to visit our other calendars.

The annual Security Christmas calendar

Hi there, and welcome to this advent calendar! While you wait for Christmas, we'll provide you with an article related to Functional Programming (FP) each day until December 24 🎅

We will try to tackle a wide range of topics. We will cover a few "classic" FP-concepts, both basic and more advanced. We also aim to have some articles with a more practical focus. Some posts will be intended for beginners and some will have a more experienced audience in mind. So if a particular article isn't for you, hopefully the next one will be!

To get the show on the road, lets start out by answering the following question:

So, what is FP anyway?

Functional Programming is, like Object Oriented Programming (OOP), a programming paradigm. There isn't a formal agreed-upon definition of what FP entails, but there are two core concepts most people would agree are central to the paradigm:

Avoiding mutating state and side-effects

Using functions as the central building block of programs

Lets discuss each of these in turn.

Immutability

In functional programming, we strive to avoid mutating state. In fact, in many functional languages modifying a "variable" is simply impossible. We also have a concept of pure functions, meaning functions which cannot have any side effects besides returning a value.

Now, if you're new to FP this might sound very strange, but it's actually really nice when you get used to it. Because, in return for giving up the possibility to mutate state in our programs, we get some really nice benefits.

One of the main benefits, at least to me, is that code written in a functional style is much easier to understand. If I want to know what a given piece of code does, I know that I will only have to look at that particular code, and not worry about how state in other parts of the program might affect it.

The computer can also benefit greatly from code being written in a functional style, opening the possibility of some nice optimizations. For example, two pure expressions which does not depend on each other can easily be computed in parallel, and a pure function can be memoized automatically since it will always give same result when called with a given set of inputs.

Don't tell anyone, but we will return to this topic and explore it further in a later article 🤫

Functions as building blocks

In OOP the basic building blocks are classes and objects. In FP, in contrast, you build your programs using functions. In most functional languages your entire program will simply be a function. And this function will in turn be built out of other functions. To use a cliché, it's functions all the way down…

To make this viable, it is important that functions are first class values of the language. You should be able to assign your function to a variable or store it in a data structure, like any other type of value in your program.

Functions must also accept other functions as arguments, and can even have functions as their return value. This is often referred to as higher order functions. It is common to create new functions by composing two other functions together, or by calling a function with only some of its arguments to create a new function.

These are also concepts we will be returning to in later articles.

What is a functional language?

A programming language isn't either functional or not functional. It is more like a spectrum, where languages are more or less on the functional side, depending on which features they support. So, a language that's considered functional is simply one which makes it easy, or even mandatory, to program in a functional style.

But it's also perfectly possible to use FP in many languages not traditionally considered functional. Often this will just require more discipline on the part of the programmer to stay away from mutating variables, for instance. Most such languages also have useful libraries for those inclined to a more functional style of programming. And by the time Christmas comes around, that will hopefully include you!

1-Dec

Today's posts