Creating beats with Excel

Many years ago, a friend who is also a physicist like me, visited me and we talked about a few matters. When he told me that he began learning Excel, I knew I could impress him. I told him that I use Excel a lot and added: “Do you want to see how easy it is to create beats with Excel?”.

Beats are a dear and well studied subject among physicists, so his answer was the obvious one.

I opened Excel (here I will provide a screenshot using a much newer version of Excel) and created 4 columns.  The first column contained the numbers 0, 0.1, 0,2 and so on. The first cell of the second column contained the formula = SIN(A1), which I copied down. The first cell of the third column contained the formula = SIN(A1*0.9), which I copied down. The first cell of the fourth column contained the formula = B1+C1, which I copied down.

I considered the first column as containing the angle in radians. I considered the second column as containing the first sine wave. I considered the third column as containing the second sine wave, with a frequency close to the frequency of the first sine wave. I choose 0.9 as the coefficient. I could have chosen 1.1, or 0.09, or 1.01, etc. I considered the fourth column to be the sum of the two sine waves. So, the fourth column represented a beat, because a beat is the sum of two sine waves that have similar (but not exactly equal) frequencies.

For the coefficient and angle step that I chose, I found that with 2000 rows of data, I could nicely get a few periods of the beat.

I plotted each of the second, third, and forth columns, showing my friend each sine wave and the beat. I also plotted them all three in the same graph. At the end, I plotted the two sine waves together and I plotted the beat using the same scale (graph width) underneath the graph of the sine waves. This demonstrated the beat really nicely:

Beat

My friend was impressed.

Posted in Science

How should you mention your experience with a particular programming language?

In my opinion, the years of experience with a programming language do not indicate much, just by themselves. In your resume, it is better to write what you have created or achieved using a particular language.

Is there code written by yourself that your evaluator can review? Is there a finished program, web site, or other project that your evaluator can see and use?

Finally, do you believe that you are up to the task at hand? If so, why? List your knowledge (along with corresponding proof, if possible) in all the areas that may be needed for the project you will be hired to do.

For example, say that someone wants to hire you to do C# programming for a project. You may have been programming with C# for five years, but the particular project might require you to have advance knowledge in threads.

If you do not know what threads are, you will benefit by beginning to learn about them. But you will not be a good fit for the project, because threads should usually be implemented by highly specialized and knowledgeable developers.

You can learn about threads and create proof of concept programs in less than a day, but to master them you need quite a bit of time.

Now, if you know a lot about threads, concurrent, and asynchronous programming in C#, you should mention it along with proof (books you have read, projects that you were involved in, code you have written). Only then will the years of your experience with a particular language start to make sense.

Posted in Management

How can you switch to a different position within the same company?

How can you switch to a different position within the same company? That depends on the culture of the particular company you are working for.

There are companies that do not mind when employees want to change their position, for whatever reason. Some employees may want to make their work more challenging, others less challenging, others different, etc. If, by changing her position within the company, an employee will be happier, then the company will also be happier.

The problem is that most companies do not “think” like that. Most companies are shortsighted. So they will only let you progress “vertically”, but not “horizontally”. Let me explain.

By “vertical progress”, I mean that you *progress* from a job that demands less to a job that demands more within the same field.

By “horizontal progress”, I mean that you *switch* from a field to a different field, but you remain at the same (or lower) level in the company hierarchy.

Most companies are shortsighted and will not let you progress horizontally, because they did not hire you for the particular field you want to switch to.

For these companies, once a carpenter, you are always a carpenter; you cannot be a blacksmith. But you can be a manager of carpenters, and then a manager of managers of carpenters and so on.

This company culture is shortsighted, because it does not let an individual find her right place in the workplace. This culture forces her to leave her job in order to achieve that.

When I started working, I was a software developer. It took me two whole years to finally realize that what I wanted to be was a “systems engineer”.

So I switched fields and I have been extremely happy that I did that. (That does not mean I do not like software development. At the moment I use Haskell a lot, for fun. And it is rare to find a company that uses Haskell for a software development. So, win win. I get to be a systems engineer, something that I love, and I also continue to program with the languages that *I* love.

So, how could you switch (move horizontally) within the same company?

Well, again, it all depends on the culture of the particular company. Some companies, mostly for idiotic reasons, consider some fields to be of high profile and some fields to be of low profile. So they give great honors and compensation to those who work in the first type of fields, whereas they consider those who work in the second type of fields as second class employees.

Well, try to make a switch from a low profile field to a high profile field or from a high profile field to a low profile field and all hell will break loose. The company will not want such a switch to happen and all your colleagues will ridicule you, either for wanting too much or for wanting too little. In any case, you are better off if you resign and seek employment elsewhere.

Now, in companies that wholeheartedly allow you to change fields, if you find yourself wanting to do so, you should make this known to the company. This way both you and the company can work together towards this common goal: you switching to a field that will make you happier.

Posted in Management

The IO Monad

It is time to study the most important and most intuitive Monad: the IO Monad. IO stands for Input/Output. IO is considered a side effect and it is treated as such. This is why Haskell has a Monad especially for it. In this blog post, we are going to study this Monad. Its study will allows us to better understand the monadic concept in general.

Let us begin with the following program:

module Main where

myFunction   :: String -> Int
myFunction xs = (length xs) + 10 

main :: IO ()
main  =
   do
      putStrLn "Program begins."
      
      print (myFunction "Dimitrios Kalemis")
      
      putStrLn "Program ends."

The output of the following program is:

Program begins.
27
Program ends.

Let us concentate on myFunction. myFucntion takes a String as input and returns an Int as output. This Int is the length of the String plus 10. I do not know whether myFunction is a function worth having, but let us pretend it is. So, we can call myFunction passing any String to it and it will return an Int equal to the number of characters in the string plus 10.

myFunction is purely functional. It takes a String as input, does computations, has no side effects, and produces an Int as output.

Let us now change myFunction from purely functional to monadic. Let the definition of myFunction now be String -> IO Int. The new program with the new myFunction will be as follows:

module Main where

myFunction   :: String -> IO Int
myFunction xs =
   do
      return ((length xs) + 10) 

main :: IO ()
main  =
   do
      putStrLn "Program begins."
      
      a <- myFunction "Dimitrios Kalemis"
      print a

      let b = myFunction "Dimitrios Kalemis"
      b >>= print
      
      myFunction "Dimitrios Kalemis" >>= print
     
      putStrLn "Program ends."

The output of the previous program is:

Program begins.
27
27
27
Program ends.

In the previous program, we can see that the myFunction is monadic. I also showcase the three equivalent ways in which to call the monadic myFunction and print its result.

Although myFunction is expressed in a monadic way (the Monad being IO in this case), myFunction exhibits no side effects. So, let us add IO side effects to myFunction.

The following program showcases a myFunction full of IO side effects: When myFunction is called, and without us having to print or otherwise use its output, myFunction prints to the screen, prompts the user for input, accepts input from the user, concatenates it, and prints it to the screen.

module Main where

myFunction   :: String -> IO Int
myFunction xs =
   do
      putStrLn "Inside the function that returns the length of a string plus 10."
      putStrLn "Type something and press Enter"
      inputData <- getLine
      putStrLn ("This is what you typed: " ++ inputData)
      return ((length xs) + 10)

main :: IO ()
main  =
   do
      putStrLn "Program begins."

      a <- myFunction "Dimitrios Kalemis"

      putStrLn "Program ends."

The output of the previous program follows:

Program begins.
Inside the function that returns the length of a string plus 10.
Type something and press Enter
something
This is what you typed: something
Program ends.

We can see that I typed the word “something” when the program prompted me. All that was written in the screen when myFunction was called was IO side effects.  Why? Because a pure function only accepts arguments as input and returns a result. It cannot do anything else. So, printing to the screen and accepting input from the user are side effects. We welcome these side effects because we need them. The point is that they are “hidden” inside a monadic function. This way, we control and regulate these side effects. And we do not let the side effects surprise us. The function declaration (String -> IO Int) warns us that we will have IO side effects.

The last program finished without really using the Int result from myFunction. But we could have inserted a print a statement after the call of myFunction, in order to see the output of myFunction. Be sure that this output will be the number 27.

As far as the function named “main” is concerned, it has the following declaration: main :: IO (). This declaration means that main is IO monadic (i.e. it may produce IO side effects) and that it takes no input (there is no “<type> ->”) and produces no output, which is denoted by: ().

Finally, since we are talking about a Monad, I would like to show its “return” and “bind” at work. Well, the second program shows “return” in action: “return” in this case takes an Int and returns an IO Int. “return” took its name because it elevates a type a to the type IO a, but it does not produce any IO side effects. Thus, it does not print anything on screen; it just “returns” the IO type. So, “return” “returns” without printing anything to the line.

As far as “bind” (>>=) is concerned, the following program shows this at work. We have three IO monadic functions. Each one has a side effect, which is the putStrLn statement. I show how these are combined in the main program using >>=.

module Main where

myFunction1   :: String -> IO Int
myFunction1 xs =
   do
      putStrLn "Function1."
      return ((length xs) + 10)

myFunction2  :: Int -> IO [Int]
myFunction2 x =
   do
      putStrLn "Function2."
      return ([1..x])

myFunction3   :: [Int] -> IO (Int,Int)
myFunction3 xs =
   do
      putStrLn "Function3."
      return ((length xs, sum xs))

main :: IO ()
main  =
   do
      putStrLn "Program begins."

      myFunction1 "Dimitrios Kalemis" >>= myFunction2 >>= myFunction3 >>= print

      putStrLn "Program ends."

The output of the previous program follows:

Program begins.
Function1.
Function2.
Function3.
(27,378)
Program ends.

myFunction1 takes a string of length 17 and returns the Int 27. 27 is passed to myFunction2 which returns the list [1..27]. The list [1..27] is passed to myFunction3 which returns the tuple (27, 378). The tuple’s first member is the length of the list (which is also the output of myFunction1) and the tuple’s last member is the sum of the numbers from 1 to 27.

To show that returns does not “harm” such compositions, please note that the line in the main program can be equivalently written as:

myFunction1 "Dimitrios Kalemis" >>= return >>= myFunction2 >>= return >>= myFunction3 >>= return >>= print

The previous program showed the composition of three functions that are not purely functional. This is why we used the >>= operator.

As a bonus, I will present the same program, recreating the functions so that they have no side effects, and show the normal way to compose them: with the . operator.

module Main where

myFunction1   :: String -> Int
myFunction1 xs = (length xs) + 10 

myFunction2  :: Int -> [Int]
myFunction2 x = [1..x]

myFunction3   :: [Int] -> (Int,Int)
myFunction3 xs = (length xs, sum xs)

main :: IO ()
main  =
   do
      putStrLn "Program begins."
      
      print ((myFunction3 . myFunction2 . myFunction1) "Dimitrios Kalemis")       

      putStrLn "Program ends."

The output of the previous program is

Program begins.
(27,378)
Program ends.

If you would like to refresh your memory about the normal composition of pure functions, you could (re)read my blog post “Notations for function application and composition in Haskell”.

Posted in Development

Creating state with IORef

In my previous blog post, I wrote about the State Monad and how it cannot be used to create a stateful counter. Fortunately, there are many ways and additions in Haskell (like special libraries, etc.) that can be used to create state the way it is meant to be.

In this blog post, I will demonstrate IORef, which is a way to define mutable entities (variables) in Haskell. Immutable is something that cannot change. Mutable is something that can change. So, a mutable variable is a variable whose value can change. Thus, it constitutes a perfect way to keep state and it also makes a perfect counter, whose value can be, for example, increased by one, each time it is accessed.

The following program gives us an introduction to IORef. newIORef takes an initial value and creates an IORef with that value. modifyIORef takes an exisiting IORef and a function and applies the function to the IORef, thus producing a new IORef that replaces the old IORef. So, IORef functions like any variable in imperative programming.

In the following program, the IORef ref first stores the value 0. Then, using the fucntion (+1), ref stores the value +1. Then, using the function (+5), ref stores the value 6. And after that, using the function (*2), ref stores the value 12.

module Main where

import Data.IORef

main :: IO ()
main  =
   do
      putStrLn "Program begins." 

      ref <- newIORef 0
      readIORef ref >>= print

      modifyIORef ref (+1)
      readIORef ref >>= print

      modifyIORef ref (+5)
      modifyIORef ref (*2)
      readIORef ref >>= print

      putStrLn "Program ends."

The previous program produces the following output:

Program begins.
0
1
12
Program ends.

The following program will achieve what we wanted to do all along: create a stateful counter. Indeed, startCounter creates and returns an IORef that initially stores the value 0. Each time increaseCounter is caled with the IORef as argument, it increments the IORef by 1 and it displays its new value. Although the statement remains the same (increaseCounter counter), the output is different (each time is 1 more than the previous output). This behavior is stateful behavior, something that is certainly a side effect and an abnormality in pure functional programming. But here, it was this exactly that we were trying to achieve.

module Main where

import Data.IORef

startCounter :: IO (IORef Int)
startCounter  =
   do
      ref <- newIORef 0
      return (ref)

increaseCounter        :: IORef Int -> IO ()
increaseCounter counter =
   do
      modifyIORef counter (+1)
      readIORef counter >>= print

main :: IO ()
main  =
   do
      putStrLn "Program begins." 

      counter <- startCounter

      increaseCounter counter
      increaseCounter counter
      increaseCounter counter

      putStrLn "Program ends."

The previous program produces the following output:

Program begins.
1
2
3
Program ends.

As an added bonus, I thought I would present the four statements in the main program’s do section using the monadic notation instead of the do notation. So, the following program is equivalent to the previous program. The only thing that changes is that the statements in the main program use the monadic notation instead of the do notation. This will help the reader understand in general a little bit better the correspondence and equivalence between the monadic notation and the do notation.

module Main where

import Data.IORef

startCounter :: IO (IORef Int)
startCounter  =
   do
      ref <- newIORef 0
      return (ref)

increaseCounter        :: IORef Int -> IO ()
increaseCounter counter =
   do
      modifyIORef counter (+1)
      readIORef counter >>= print

main :: IO ()
main  =
   do
      putStrLn "Program begins."
 
      startCounter >>= (\counter -> increaseCounter counter >>= (\_ -> increaseCounter counter >>= (\_ -> increaseCounter counter)))

      putStrLn "Program ends."

The previous program is equivalent to the second program and thus produces exactly the same output:

Program begins.
1
2
3
Program ends.
Posted in Development

The disappointing State Monad

So far in my blog posts, we have encountered Monads and have studied them, in order to understand how they behave and how they work. But we have not seen real examples of real Monads in the real professional programming world. We should start studying Monads that do something useful, that is, Monads that hide really useful computations inside them. State, IO, and other side effects are examples of computations that are needed in the real world of professional programming and that are not purely functional. Thus, we need Monads in order to hide these side effects and their deviation from the pure functionality.

Ok, let us start by studying state. Although everyone seems to agree on what state is, Haskell provides a Monad that handles state in a somewhat disappointing manner. The State Monad keeps state inside a computation, but after the computation is over, the state is no longer kept. In this blog post, we will study this disappointing State Monad.

As I mentioned, the State Monad s only useful inside a computation. In the program that follows, I provide examples of functions that return a State Monad. Inside each function, you can keep and read and change and advance state. When the function terminates, all this is lost. So, while you can use the State Monad in order to create temporary counters inside a computation, you cannot use the State Monad in order to create a stateful counter that you can advance between different calls.

Limiting and disappointing as the State Monad can be, it still packs great power. You see, the State Monad handles a state s and a value a. A value of type State s a is a function from initial state s to final value a and final state s: (a,s). What is really important is that the state and the value do not have to be simple entities. They can be tuples, for example. So, the state and value can hold a complex structure of entities, for example, a few or more counters. There is a “get” directive that sets the value equal to the state, a “put x” directive that sets the state equal to x, and a “return x” directive that sets the value to x. There are also functions that help in the use of the State Monad, like runState, evalState, and execState. runState takes an initial state and a seqeunce of actions and returns the final state. evalState and execState return one of the two values that runState returns: evalState returns the final result and execState returns the final state.

As far as bind (>>=) for the State Monad is concerned, it passes the value (as opposed to the state) of its first argument to its second argument.

The following program demonstrates the functionality of the State Monad. It can be broken into smaller independent programs, but I think it will be easier to get a full glimpse into the State Monad’s functionality this way.

In this program, I create different states (and their corresponding values). Each different state is created, referenced and updated in a single function, because this is all the State Monad functionality can do. The state ceases to exist once the function is finished.  These concepts are demonstrated with the first four functions (1 to 4).

The last three functions (5 to 7 )as well as the first function (1) are used to demonstrate the functionality of the bind (>>=) as it is programmed in the State Monad.

It will be very instructive for the reader to change the placement of the myState <- get instruction in the first function. Indeed, the first function can have more than one statement like that, or its placement can change and it can be placed from immediately after do, to immediately before the return statement. The effect of this change on the outputs that depend on the first and seventh functions can be seen by running the program.

module Main where

import Control.Monad.State

-- A value of type (State s a) is a function from initial state s to final value a and final state s: (a,s)
-- "get":        value <- state        and state does not change
-- "put x":      value does not change and state <- x
-- "return x":   value <- x            and state does not change
-- evalState takes an initial state and returns a final value
-- execState takes an initial state and returns a final state
-- >>= passes the value (and not the state) of its first argument to its second argument
-- (>>=) :: State s a -> (a -> State s b) -> State s b

-- The state is the first String and the value is the second String
myFunction1 :: State String String
myFunction1  =
    do
       put "100"
       put "200"
       put "300"       
       put "400"
       myState <- get
       put "5000"
       put "6000"
       put "7000"       
       put "8000"
       return myState

-- The state is the first Int and the value is the second Int
myFunction2 :: State Int Int
myFunction2  =
    do
       myState <- get
       return myState

-- The state is the Int and the value is the String
myFunction3 :: State Int String
myFunction3  =
    do
       put 11
       put 12
       return "AAA"
       return "BBB"

-- The state is the String and the value is the Int
myFunction4 :: State String Int
myFunction4  =
    do
       put "AAA"
       put "BBB"
       return 11
       return 12

-- The state is the second String and the value is the Int
myFunction5   :: String -> State String Int
myFunction5 xs =
   do
      put xs
      return (length xs)

-- The state is the String and the value is the Int
myFunction6 :: State String Int
myFunction6  =
   do
      put "50,000,000"
      let a = evalState ((return "4,000,000") >>= myFunction5) "300,000"
      let b = execState ((return "4,000,000") >>= myFunction5) "300,000"      
      put b
      return a

myFunction7 :: State String Int
myFunction7  =
   do
      put "50,000,000"
      let a = evalState (myFunction1 >>= myFunction5) "300,000"
      let b = execState (myFunction1 >>= myFunction5) "300,000"
      put b
      return a

main :: IO ()
main  =
   do
      putStrLn "Program begins."

      putStrLn "Tests that study the behavior of the state."

      print (evalState myFunction1 "AAA")
      print (execState myFunction1 "AAA")

      print (evalState myFunction2 100)
      print (execState myFunction2 100)

      print (evalState myFunction3 100)
      print (execState myFunction3 200)

      print (evalState myFunction4 "100")
      print (execState myFunction4 "200")

      putStrLn "Tests that study the behavior as a Monad."

      print (evalState myFunction6 "1,000")
      print (execState myFunction6 "20,000")

      print (evalState myFunction7 "1,000")
      print (execState myFunction7 "20,000")

      putStrLn "Program ends."

The output of the previous program is:

Program begins.
Tests that study the behavior of the state.
"400"
"8000"
100
100
"BBB"
12
12
"BBB"
Tests that study the behavior as a Monad.
9
"4,000,000"
3
"400"
Program ends.
Posted in Development

A coding horror story

The year is 1997. And it is the beginning of summer. I knew a consultant that his age was far greater than mine.  This consultant was a foremost expert in a very important area of ERP systems. I do not want to give away many details, in order to keep his identity hidden. This consultant was a very good person and a very polite person. Something hard to find in Greek people.

This consultant and I were working for the same company. But where I was a mere employee, and the lowest of the low at that, he was working in the company as a consultant and was paid a very big salary. Or so the rumors went. The rumors were that he was so capable and knowledgeable, that the company could not afford to hire him full time. And indeed, he was a very knowledgeable person in his field, that particular area of ERP systems. But he knew how that area should function from the point of view of a customer and of an accountant. This consultant was not a developer, did not know how to code, and all he had seen in his life were dummy IBM terminals. This consultant knew nothing about Microsoft Windows.

So, this consultant asked me to visit his home so he could show me the project he was working on. So, I visited his home and met his family. He and his family were so kind and polite to me and I will never forget that.

It turns out that this consultant was just beginning to work on an ERP system of his own. He had decided to build an Enterprise Resource Planning program that would cover all aspects of what an ERP should do: Accounting, etc. Of course, the consultant did not know how to code. For that he had two youngsters, at most 20 years old each: his daughter or niece (I cannot remember which of the two) and her boyfriend. The consultant had chosen Visual Basic as the programming language and SQL Server as the database server. I do not know why he chose VB and SQL Server, but it was a wise decision, especially at that time period. He had encouraged the two youngsters to learn VB and they have been trying to learn VB for a few months.

The consultant wanted me as part of their team, but I kindly refused. First of all, I am not a developer, I am systems engineer. Second, he never made me a clear offer so that I could understand if there was any salary or other benefits. And third, … well keep reading and I will explain.

The consultant wanted to show me how far they had progressed. Of course, everything was at the very beginning, but he wanted to show me what they had done so far. So, he started talking about what an ERP software should be able to do: Accounting, etc. while at the same time running their program, which displayed the following form:

Form

I recreated the form, so I can display it here in this blog post, with a much newer version of Visual Studio. Imagine that the original form really resembled this one, except for minute details.

The consultant wanted me to look at the form and tell him my thoughts. He was proud of the form; he was talking about it with great appreciation. Seconds were passing one after the other and I could not really understand what the purpose of this form with the five list boxes was. They were empty, they were all alone in the form with nothing else but them, and they exhibited no functionality. I knew he was showing me five list boxes neatly organized, but I could not understand why he was showing them to me. And as seconds kept passing, and as he kept talking about ERP systems in general, I was struggling to understand the usefulness of this form. Yes, there were five list boxes there, but what was their purpose?

Half a minute may have passed until it hit me: The consultant was showing me their grid! When I understood what I was looking at, I did not know what to say, so I said nothing. But I was feeling appalled.

In microseconds after that I realized that the consultant, who only knew about dummy terminals, knew nothing about Microsoft Windows and GUIs. When he gathered the two youngsters and they started building the ERP program, their first need was to display data on the window. And they also wanted to display more than one row of data. Knowing only about dummy terminals, the consultant did the best he could to describe this functionality to the youngsters. The youngsters, after a lot of struggle, came up with this solution.

So, like all good developers, the consultant and his team of two subordinates were in need of a grid. But unlike good developers, had no idea about grids. And they tried to implement one using list boxes. To the eyes of the consultant, that construct resembled the columns of data he would see in IBM AS-400 programs.

After the consultant showed me what they had done, which was very little, I knew they were just beginning and they had no knowledge whatsoever of the field of programming  for Microsoft Windows. I did not join the consultant’s team for various reasons, but the most important one was that I was not going to be able to communicate with these people. There was a great knowledge chasm between them and me. I want to be a part of teams were I can be appreciated and helped. These people could never be able to appreciate my knowledge, because they were at point zero. If I would say something, they would struggle to understand whether I was correct or incorrect. And in the event that I would need help and support, they would not be able to provide it to me. In order to be appreciated and in order to be helped, you have to be amongst peers.

Posted in Management