Three steps to bring guarded statements to JavaScript for safer, better code, and forego common usage of “else” statements.

Photo by Roméo A. on Unsplash

Edsger W. Dijkstra, a Turing Award winner and ACM Fellow, the inventor of the “structured programming” phrase, and one of the first drivers of Computer Programming becoming a scientific discipline, made many contributions to the theory of programming. In this article we’ll be going back to a very old idea of his— from 1975! — to discuss how you should stop using else statements (at least in some forms) and instead apply guarded statements for safer, clearer programming. …


Revisiting the Babylonian method for square roots: why and how does it work?

In my A totally new, very old method for finding square roots article, I described how I discovered an algorithm that actually happened to be very old and well known: the “Babylonian method.” (See References, at the bottom for more on that topic.) Let’s try to work out how and why this old method works, but “from first principles”, just using basic algebra and without resorting to advanced calculus.

The old method

The (Babylonian, Greek, or Indian; take your pick!) method itself is very simple: if you want to calculate…


A new iterative method to approximate square roots — actually shown to be centuries old!

Photo by Sharon McCutcheon on Unsplash

Isaac Asimov once wrote [1] that all his discoveries in Math were either “completely correct findings that are quite old [or] completely new findings that are quite wrong.” I just had exactly the same experience, developing a totally new, greatly enhanced, surely unequaled method for finding square roots iteratively… to just end up finding, after lots of work, that I had only rediscovered a well known method!

I will show here where I started from, what ideas I developed, and the final sad conclusion about…


Safely evaluate expressions in JavaScript in a simple yet powerful way, by using a Parsing Expression Grammar

Recently, in a front-end project I was working on, the client needed to be able to define calculations by entering formulas using numbers, variables, and functions. The problem: how can you validate and (safely) evaluate such expressions?

If you wanted users to write pure JavaScript code (not a very friendly solution unless users were developers…) you could go with theeval()function, but that could allow users to enter any JavaScript code —potentially breaking the application, or creating a security hole!

In this article we’ll…


Go further with memoization to provide a better, slicker end-user experience.

In a complex web application, with several components needing data, odds are that redundant API calls will be made. You may imagine even a simple e-commerce page: the user could want to see an article, then a second one, and then go back to the first. In such a case it’s a sure bet that the app would redo its previous API calls, to essentially get the very same information it already had. Caching by the browser may help, for sure, but that also depends on the remote server providing the appropriate headers, and that may not always happen. …


Learn what it truly means to memoize a function and why popular front-end frameworks aren’t really doing it

Hi! Welcome to this “ Forever Functional “ series of articles, in which we’ll be looking at how to using several Functional Programming patterns and solutions to simplify your JavaScript programming or, as in this particular case, enhance the performance of your code.

In this first article in the series, we’ll consider a performance problem: dealing with slow, long-running functions, and improving them by using memoization, an interesting technique to avoid unnecessary work. …


A couple more problems with async calls and loops; how to handle searching.

Photo by Ronald Smeets on Unsplash

In the previous articles in this series (Part 1, Part 2, and Part 3) we looked at problems with functions such as forEach(), map() or every() when used with async functions or promises, and developed some alternative versions that suited our purposes. Let’s finish now by considering a pair of tightly related methods: find() and findIndex() that also need a workaround.

Why do these methods fail? The reason is the same as for some() and every(), which we studied in Part 3 of this series. …


Yet more problems with async calls and loops in JavaScript: how to handle testing for some and every.

Photo by Virginia Johnson on Unsplash

As we saw in the previous articles in this series (Part 1, Part 2) JavaScript’s standard higher order functions such as map() or forEach() do not work well if async functions are passed to them. In this article we’ll continue our study of possible fixes, by finding alternative implementations for some() and every().

When looking at some() and every() I thought they would probably fail (because many other functions also did fail!) just because they weren’t promise-ready, but the reason here was simpler: if we pass an async function to them, a promise is returned every time — and since…


More problems with async calls and loops in JavaScript; how to handle mapping and filtering.

Photo by Tine Ivanič on Unsplash

In the first article in this series, “Async loops, and why they fail! — Part 1”, we saw that using common higher order functions like forEach() or reduce() wouldn’t work as expected with async functions. Similar problems apply to map() and filter() so let’s continue our work by dealing with them.

Mapping — a manual solution

If you try to directly use .map() with async functions, the result won’t be what you’d probably expect.

The output would be as follows.

19:58:20.008 START -- using map(...) 
19:58:20.009 END
Result of map: [
Promise { <pending> },
Promise { <pending>…

Mixing loops with async calls in JavaScript produces unexpected results; how to handle looping and reducing.

Higher order functions such as forEach(), reduce(), map(), and filter() are commonly used in JavaScript programming, but if you mix them up with async calls or promises, results probably won’t be what you would expect. The problem occurs, as we’ll see, only with these functions; “common” code won’t be affected.

In this article we’ll study and produce alternative correct implementations for forEach() and reduce(), which are quite similar in some aspects. …

Federico Kereki

Computer Systems Engineer, MSc in Education, Subject Matter Expert at Globant

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store