Forem: Pan Seba

Stop abusing .map()!

Pan Seba — Sun, 26 Sep 2021 19:41:41 +0000

Every once in a while when I do code review or visit StackOverflow I stumble upon code snippets that look like this:

const fruitIds = ['apple', 'oragne', 'banana'];
fruitIds.map((id) => {
   document.getElementById(`fruit-${id}`).classList.add('active');
});

So as you can see it's just a simple iteration where for every element in the fruitIds array we add active class to a certain HTML element in a DOM.

Many programmers (especially new) wouldn't notice anything wrong with the code above. However, there is a one major issue here - the usage of .map(). Let me explain.

What is wrong with `.map()`?

Well, there is completely nothing wrong with this particular array method. In fact, I think it is very handy and beautifully wraps one of the iteration patterns - mapping.

In simple words, mapping is an operation which applies a function to every element of a collection and returns a new collection with elements changed by the mentioned function. For example, if we have an array of numbers const nums = [1, 2, 3, 4]; and would like to receive a new array of doubled numbers, we could map the original array to a new one like this (in JavaScript):

const biggerNums = nums.map((n) => n * 2);
// >> [2, 4, 6, 8];

The biggerNums array would consist of numbers from the original nums array multiplied by 2.

Notice how .map() is used - we assigned the result of this method to a new variable called biggerNums. I have also mentioned earlier that mapping is an operation that returns a new collection of elements. And this is the very reason the code snippet showed at the beginning of this article is wrong. The .map() returns a new array - always - and if we don't need that array, we shouldn't use .map() in the first place. In this particular case (simple iteration) a different array method should be used - .forEach() - which is specifically designed for such cases. It doesn't return a new collection, it simply walks through an array and invokes a callback function for every element allowing you to do something for each of them.

So the correct version of the mentioned snippet should look like this:

// good way
const fruitIds = ['apple', 'oragne', 'banana'];
fruitIds.forEach((id) => {
   document.getElementById(`fruit-${id}`).classList.add('active');
});

We don't need a new array so we simply iterate over the fruitIds array and add the active class to an HTML element for each of the array items.

Okay, but why should I care? .map() is shorter and easier to write than .forEach(). What could possibly go wrong?

Consequences of abusing `.map()`

One of the worst consequences of abusing .map() is the fact that it returns a new redundant array. To be more specific - it returns a new array of the same size as the one this method was called on. It means that if we have an array of 1000 elements, .map() will return a new array of 1000 elements - every time.

In JavaScript, all functions return a value. Even if we don't use the return keyword, the function will return undefined implicitly. That's how the language has been designed. This rule also applies to callbacks - they are functions too.

Having said that, let's get back to the original example:

// wrong way
const fruitIds = ['apple', 'oragne', 'banana'];
fruitIds.map((id) => {
   document.getElementById(`fruit-${id}`).classList.add('active');
});

What happens here? An array of fruit IDs is created and then it's mapped to another array of the same size. Even though the array returned by .map() is not used, it does take place in memory. This new (unused) array looks like this:

[undefined, undefined, undefined]

It's because the callback passed to the .map() method does not have the return keyword and as we know, if there is no return, undefined is returned implicitly.

How bad is it? Very bad. In this particular example it won't bring any serious consequences - there are only three items in the array so creating another three-element array won't cause any problems. However, the problem arises when we deal with big arrays of complex data. If we want to iterate over an array of five thousand objects and we abuse .map(), we create another array of five thousand elements - undefineds. So we end up storing 10 000 elements in memory from which a whole half is redundant. It is a very non-optimal practice and in some scenarios it may even lead to the application overload. This is why we should pick right methods to the right tasks.

Summary

There are many practices that are essentialy bad, but the negative consequences will start to be visible only when dealing with bigger datasets. One of such practices is abuse of .map(). When operating on small arrays, it won't cause any hurt. But when we make this mistake with a bigger array it will start overloading our application and it may be quite hard to debug.

This is why we should never let it pass by and whenever we see this abuse, we should take care of it. I hope now you understand why.

Do you remember Bosque from Microsoft? I wrote a book about it

Pan Seba — Thu, 16 Sep 2021 19:28:47 +0000

Let's start with a quick explanation what is Bosque, because I believe it's not so well-known topic.

Bosque is a programming language created by Microsoft in 2019. Initially, it was an experiment that was supposed to show what would happen if we removed the sources of accidental complexity from the language. Currently, Bosque is on its road to the first stable version. This project's mission is to start a new paradigm called Regularized Programming.

At this point you may be wondering why on Earth would I write a book about a language which is hardly recognizable? Let me explain how it happend.

How did I become an author?

It was a bit unexpected. Back in 2019, when Bosque had been initially released to the public, I was curious what this new language looks like and what it can be used for. At the time, I was also very interested in the internal design of various programming languages and was simply curious how to implement a new one from scratch. So, I downloaded the Bosque codebase and started reading it and playing with the language itself. There was a ton of bugs really. But I couldn’t leave that as-is and started fixing them. After my first PR got merged, I was motivated to open more. I was really enjoying it – I was both helping to develop Bosque and learning about how programming languages are designed and implemented. I was thinking that regardless of whether Bosque will be a success or not, it’s still worth doing it – you never know what the future brings, right? And then, a year later, I got an email in my inbox with a proposition to author a book about Bosque. I couldn’t say no and without hesitation agreed. That’s how I become an author and this is the cover of my first ever technical book:

Let's get back to Bosque itself. I think it's a good idea to make a little introduction to the language since I decided to write a book about it, right? In the next few sections I describe in more detail what is Bosque and regularized programming as well as cite a few fragments from my book. Let's jump in!

What is regularized programming?

Let's make a step back to the term "sources of accidental complexity". It covers things like loops, mutable state, unexpected behavior or invariants. All of that lead to the whole variety of problems, often quite easy to solve but hard to find. You can imagine a built-in method called .sort(). As a programmer you need to think whether the sorting is stable or not. Similarly iterating over a map - you can't be sure about keys order since there's no such concept as "order" in maps. Depending on a language the solutions will differ. Languages following regularized programming paradigm are supposed to work in very clear and predictable way.

Another example refers to the mentioned invariants. Let's say you create a game of chess. These are your invariants:

a piece (or a pawn) can take only one square
a piece (or a pawn) disappears from the board when it gets taken

These are the rules that cannot be broken. So we need to create a data structure representing a chessboard. When one of the players make a move we need to do two things: take a piece from one square (1) and put it on another (2). For a very short moment one of our invariants is broken. If we take the piece from a square first and then put it on another one, we break the second invariant because for a brief moment a piece that hasn't been taken is not on the board. If we put the piece on another square first and then take it from its current square, we break the first invariant because for a moment a piece stands on two different squares. A "regulation" here is a mechanism that allows you to update class fields in atomic way so that there's no moment in time when your invariants are broken.

This is what regularized programming has been initiated for. It's a paradigm that gives us tools that take a ton of problems from us. There are more examples really and it's hard to show them all. Using Bosque built-in tools you can create quite complex programs although the language is still under quite a heavy development.

Let's see a few examples from my book to better understand advantages of this language.

Typed Strings

It's a feature that allows you to create text values of a specific type. Have a look at the fragment from Chapter 3, Bosque Key Features:

[...] On the other hand, there are lots of less complex data types that are still schematic, and some checks are required to confirm their validity. Some examples include phone number, ZIP code, email address, credit card number, or even simple types such as mass or distance. All these data types can be described with a finite number of rules that define their structure. The problem is that we usually do not create a class for things such as a mass unit and even if we do, we feel like it's overkill because the implementation hides the true intent of a programmer, which is to simply know what type of data we are dealing with. A solution we usually go for is strings.

If we want to store a phone number or a distance unit, we simply store it as a string. This is convenient, but at the same time, it brings terrible consequences. If we operate on strings, then how sure can we be that a given string is actually a phone number? What stops us from – accidentally – passing a string representing a mass unit to a function that expects a ZIP code string? The answer is that we can't be sure at all unless we perform a manual check; nothing stops us unless we perform a manual check. It would be much easier for us if there was a way to tell the compiler to treat some strings as if they were representing some data type – typed strings. This is where Bosque shines.

So we can define a type of value that is stored in a string. Thanks to that it's impossible to accidentaly pass the wrong value to your variable/parameter. For example if you want to store a phone number you can create a typed string and use it in your code so that there's no doubt what you are looking at:

let number = PhoneNumber'123-456-789';

There are more interesting ideas from Bosque creators.

There are no loops in Bosque

No, really, not a single loop construct. But don't worry, you can still perform iteration - just use built-in methods for that. No need to create a "manual" for or while. Have a quick read:

The truth is that Bosque did not remove the iteration completely. What the creators did is they removed structures like the ones we mentioned previously: while, for, do...while, and so on. Instead, every iterable data structure (such that we can perform an iteration on it) that is available in Bosque is equipped with a ton of methods that are performing iterative processing internally. The only thing we have to do is to pick the ones that will satisfy our needs and make use of them. This may seem like an impediment because we simply got used to structured loops. But in reality, for the price of some level of flexibility, we are better able to understand the code we write.

Using the built-in methods we can create programs that utilize iteration without having to write any loops. I prove that in the next section.

Artificial Intelligence in Bosque? You can do that

Although Bosque is on the early stage of development you can create quite interesting projects. One of such projects is an AI classifier. Here are a few citations:

[...] Our end result should consist of two programs. The first one should be used to train and test our intelligent model and return trained values (we'll talk about these in the next section). The second one should accept those learned values as parameters plus two coordinates – X and Y – and return a string that will indicate which quadrant the point with these coordinates belongs to.
[...]
Neural networks are mathematical structures that are designed to perform calculations by using a collection of nodes called neurons. An artificial neuron is an elementary unit of a neural network. Basically, it's a mathematical function that receives input and produces output. The artificial neuron usually has multiple input values (input vectors) that are weighted (weight vectors).
[...]
Alright, after this very quick introduction to neural networks, we are ready to put the theory into practice. Our task is a simple classification problem. We want to assign every
point to one of four classes (quadrants). As mentioned earlier, in order to recognize four classes, we need two perceptrons. Each of these two perceptrons will produce only one of
the two possible outputs – 1 or 0, which maps to a certain class. If the output is 1, we can say that the given perceptron has activated.
[...]
In order to train the perceptron, we need to perform certain operations iteratively until our training set is fully processed. At each step of iteration, we have to take the training
sample, create an input vector from it, and multiply this and the current weights vector. Then, we need to pass the result to the activation function and use the output to update
the weights. These steps must be repeated for all of the training samples.
[...]
The best practice is to always wrap the constantly repeating
code in a function so that it will be easier to maintain. So, let's go ahead and wrap the
repeating piece of code in a classify function. This is what it can look like:

function classify(x: Float64, y: Float64, perceptron: Perceptron): Float64 {
    let sum = multiplyVectors(List<Float64>@{ x, y }, perceptron.weights);
    return activation(sum);
}

Summary

It's hard to show all examples here. The whole idea standing behind Bosque, its syntax and approach is a topic for a whole series of articles or... a book :) Anyway, I encourage you to have a look at the language. People at Microsoft have proven that they know how to create good programming lanugages - C# and TypeScript are the best examples. Who knows, maybe one day it will turn out to be a great success?

Can I use MySQL with Node.js?

Pan Seba — Mon, 10 May 2021 20:34:59 +0000

For far too many times have I heard that question and far too many times have I heard someone saying that it’s not a popular combination or questioning this choice. It’s time to finally release my frustration and dispel any doubts on this topic.

Here’s what we are going to cover in this article:

Why MySQL may look unnatural for Node?
What database should you choose when working with Node?
Can I use MySQL with Node?

The aim of this article is to explain the common misconception about using MySQL with Node.js and to assure you that there is completely nothing wrong with using this database together with Node.js. Let’s get started.

Why MySQL may look unnatural for Node?

I think the whole uncertainty of choosing MySQL for Node.js projects comes from the conviction that when you are using Node and want to store your data in a database then you should pick MongoDB. Why is that? Well, I think we need to get back in time to 2013 when the acronym MEAN was coined.

What is MEAN and what does it stand for? It is a well-known JavaScript software stack for building full-stack web applications. It stands for:

MongoDB
Express.js
Angular
Nodejs

All of these components are technologies supporting programs written in JavaScript. MongoDB is a non-relational database for storing document-oriented data. Express.js is a web framework designed for Node.js. And Angular is a frontend framework created for building dynamic web applications. All of them support JS and therefore when choosing this stack you can build the whole system using a single programming language. It’s the essence of the „JavaScript everywhere” paradigm.

Because knowing just a single programming language enabled developers to build the whole web apps the MEAN stack became very popular. As new JavaScript frameworks was created, new versions of this stack evolved. Today we have the three most popular JS frameworks and because of that we have three variations of the MEAN stack:

MEAN – the original stack with Angular as the main frontend technology
MERN – a variation using React as the frontend technology
MEVN – a variation using Vue as the frontend technology

Today, the MERN stack became even more popular than the original variation because React's popularity is skyrocketing.

There are dozens of free tutorials, courses and videos showing how to get started with these stacks. By googling any of these we can learn that using them you can build any web application with only one language – JavaScript.

All of this caused that today these stacks seem to be a natural combination for Node. This belief becomes stronger as new developers learn that it’s the only right way of building JS apps and share it further. MongoDB became a default choice for Node apps – especially for junior developers or people who are completely new to programming. Of course, this is wrong.

So what is the best option for Node? What should be your default choice when choosing a database for Node? Let’s find out.

What database should you choose when working with Node?

Let’s start with the fact that there is no such thing as a default database for any technology. That’s not how it works. You never should pick a database based on the technology that you use in your application. The reason is that similarly to the choice of backend and frontend technology it all depends on requirements. The project requirements should be your main deciding factor for database technology. On top of that, when your architecture is well-designed the kind of your database becomes a technical detail that does not have anything in common with programming languages used to create a backend.

Every database available on the market has its own advantages and will be the best choice for projects that it has been created for. Taking only the two databases that we are discussing here – MySQL and MongoDB – each of them should (and should not) be used in certain scenarios. If in your project you must deal with a large amount of data (like really large) or the data is unstructured or it has a potential for rapid growth then probably the better choice is to use MongoDB. On the other hand, if you have structured data or your priority is data security or you just need a relational database then MySQL is a lot better choice.

So let me repeat that again: there is no default database for any backend technology. It all depends on project requirements and what do you expect from the database. You should never be guided by the technology that you chose to create your backend.

Having said that, let’s finally answer the main question of this article.

Can I use MySQL with Node?

Yes! There is completely nothing wrong with that. I hope you realize this by now. The common misconception comes from the huge popularity of the ME[ARV]N stacks and the fact that MongoDB feels very compatible with JavaScript because of its JSON-like document-oriented structure and the query language that looks like JavaScript. However this is only the illusion – yes, in many cases MongoDB is the best option for Node.js but not always. In equally many scenarios the best option will be MySQL or any other database available in the market.

At the end of the day, we do have ORMs like TypeORM or Sequelize (or a dozen of others) that support MySQL drivers and they are very popular – it also means something.

To sum up, the most important thing to realize is that there is no such thing as a default database for Node.js (or any technology) and that you never should pick MongoDB just because you use Node. In fact, Node.js does not care about data storage really – just like Java or Python, Node.js is a backend technology used to implement server-side business logic. You should always choose the database that meets your particular project needs regardless of the chosen programming language.

With that in mind, go ahead and create a new Node.js project without worrying if MySQL will be a good choice.

Forem: Pan Seba

Stop abusing .map()!

What is wrong with .map()?

Consequences of abusing .map()

Summary

Do you remember Bosque from Microsoft? I wrote a book about it

How did I become an author?

What is regularized programming?

Typed Strings

There are no loops in Bosque

Artificial Intelligence in Bosque? You can do that

Summary

Can I use MySQL with Node.js?

Why MySQL may look unnatural for Node?

What database should you choose when working with Node?

Can I use MySQL with Node?

What is wrong with `.map()`?

Consequences of abusing `.map()`