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…


Pointfree style will help you write better code, by letting you and future maintainers focus on functions, rather than on minor details.

Do you wish to write more readable and easier to understand JavaScript code? Pointfree style will help you write better code, by letting you and future maintainers focus on functions and their meanings, rather than on minor details.

In this article, we’ll focus on this style of programming, and its advantages — as well as its possible disadvantages! Thus, this article stays in the trend of applying functional programming techniques to enhance your code, as in our previous work on chaining and fluent interfaces.

What is Pointfree Style?

Pointfree style has to do with not needing to specify the arguments for each function application…


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. …


Chaining calls is a way to design fluent interfaces, which in turn allow for clearer, more understandable code.

Photo by JJ Ying on Unsplash

How do you design a clear API? More specifically, how can you make your API easier to use? The concept of a “fluent interface”, based on “chaining”, lets you provide a more streamlined development experience to developers. While in the two previous articles in this series (here and here) we looked at improving performance, now we’ll focus on improving clarity and usability.

What is Chaining?

Composing and pipelining are common patterns to apply a sequence of transformations when you work functionally . However, when you…


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…

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