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 (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!
Isaac Asimov once wrote  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…
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?
In this article we’ll…
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.
Pointfree style has to do with not needing to specify the arguments for each function application…
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. …
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.
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.
In the previous articles in this series (Part 1, Part 2, and Part 3) we looked at problems with functions such as
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:
findIndex() that also need a workaround.
Why do these methods fail? The reason is the same as for
every(), which we studied in Part 3 of this series. …
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
When looking at
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…
Computer Systems Engineer, MSc in Education, Subject Matter Expert at Globant