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…


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> }, Promise { <pending> }, Promise…

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


Further thoughts and experience on using a Parsing Expression Grammar to evaluate expressions in JavaScript

Photo by Joshua Sortino on Unsplash

Some time ago, as described in my PEG away at evaluating expressions in JavaScript article, we used a Parsing Expression Grammar (PEG) to validate and evaluate math formulas that involved numbers, variables, and functions.

After putting the code in practice, some ideas for enhancements popped up, and also (gasp!) a couple of bugs! We even discovered that Excel’s rules sometimes differ from normal arithmetic rules, so we had to add some changes to get the wrong (but in Excel’s “eyes”, right) results.

In this article…


A short curious algorithm reveals details about how JavaScript (and computers in general) represent numbers internally.

Photo by Andrew Buchanan on Unsplash

When you start programming, sooner or later you come to realize that mathematical properties are not always satisfied by computer math, and some unexpected results pop up. For example, you’d think that adding two positive numbers should produce a greater positive number, wouldn’t you? However, that’s not always the case…

In this article we’ll examine a rather simple (and totally valid) algorithm, which includes four seemingly wildly illogical statements, and that will lead us to better understand some aspects of internal number representation for…

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