coder . cl

Haskell is a fabulous language, there is no looping instruction like for or while, everything is stated using recursions, like any other functional language does, preventing states across the execution, as it was defined on the computational model of most functional languages, which is known as λ-Calculus. There is no state, only purely functional state-less execution paths. The Problem 255 on the Project Euler, is related to rounded squares and the Heron’s method to calculate it, so I have implemented a Haskell program with that algorithm, which is obviously a recursive algorithm.

The Collatz problem is Math problem related to a pair of operations which applied recursively will make a number reach 1 always. «The Collatz conjecture is a conjecture in mathematics named after Lothar Collatz, who first proposed it in 1937. The conjecture is also known as the 3n + 1 conjecture, the Ulam conjecture (after Stanisław Ulam), Kakutani’s problem (after Shizuo Kakutani), the Thwaites conjecture (after Sir Bryan Thwaites), Hasse’s algorithm (after Helmut Hasse), or the Syracuse problem; the sequence of numbers involved is referred to as the hailstone sequence or hailstone numbers, or as wondrous numbers.»

Take any natural number n. If n is even, divide it by 2 to get n / 2. If n is odd, multiply it by 3 and add 1 to obtain 3n + 1. Repeat the process (which has been called “Half Or Triple Plus One”, or HOTPO[4]) indefinitely. The conjecture is that no matter what number you start with, you will always eventually reach 1. The property has also been called oneness.

Revision control, also known as version control and source control is the management of changes in the source code of computer programs, documents and any software that is being controlled by Version Control Systems, where someone manages logically organized revisions of those softwares. Where various of those tools are currently integrated in IDEs, Office Suites and similar software. A software developer, for example, uses a VCS to control his source code. There are various well known VCS and DVCS or Distributed Version Control Systems, like git, subversion, mercurial, darcs and others.

My approach on problem solving is very similar to the divide and conquer approach. Almost all problems on programming have three main layers to be solved properly: retrieval or accessing data, processing data, and result output. Most problems can use that perspective to be solved faster than viewing them as a single procedure or function. So, you can have the same approach as single view of most problems, where if you think a little, you can see most problems as functions, and you can group complex problems in composite functions.

There is a myth where you do not need skilled people, because the technology that you are using is easy to handle, easy enough to avoid hiring skilled people. But that myth is not real, if you have experience, you know very well that skilled people are who drives the project to the right way. Without skilled people, probably your team will not reach the proper speed and performance to avoid falling in mistakes on any stage of the development process, even if you are using agile methodologies or not.

How many times do hear the word resource to refer to some co-worker, or even yourself in your daily routine? A resource strictly is a «source or supply from which benefit is produced». If you are called resource in your daily work, probably you do not have more value for your employer than the server where the web application that you are developing is running. If your employer calls you resource, rather than co-worker or even employee, of course he will use the Spanish Theory to get the maximum benefit from your work.

As you I am a Haskell programmer. I have started a FOSS project called Apache Log Reviser, or logrev as short name. I have been playing with code optimizations in Haskell on that project. So, I want to share some experience and considerations regarding its memory usage, mainly on what is related to lazy evaluations and non-strict bindings. Where lazy evaluations should be used every time you need to read or write data with delayed behaviour, for example reading large lists or even lazy lists, and non-strict bindings should be used every time you need to request data to be placed on memory for immediate reading or writing.