Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

Sunday, May 24, 2015

On C Programming: Some Pitfalls

I have programmed in C for almost 20 years, and over the years, I have my fair share of lessons learned. Here are some of the pitfalls that are very common. Learn these and you don't have to spend hours or even days to debug

  • = and == confusions
 The '=' operator is for assignment, while '==' is for comparison. Mix these up and you will have a major headache as the variable has been changed (or not)
  •  The 'if' block
Consider the following, assume x, y, and z are defined somewhere else:
if (x == 3)
  y = 43;
  z = 0;

{do something more}

Guess what? if x is equal to 3, only the statement 'y = 43;' will be executed, while 'z = 0' will be executed no matter what, which isn't the initial intention.

There are a list of programming pitfalls here

Studying Notes on Elixir

Elixir is a Erlang VM (BEAM) based language (http://elixir-lang.org/). This post serves as a note and thoughts while exploring this language.

On Installation

  1. It is much easier to install Erlang and Elixir via Homebrew, if you are using Mac, you definitely should consider this route
brew install elixir
brew install erlang

On Syntax

  1. true and :true are the same, same goes to false and :false. These have data type of booleans
  2. Constants, or symbols are called atoms. For example :hello is an atom.
  3.  The atom version of booleans (i.e. :true and :false) are special cases, and will be treated as booleans.  As can be shown below by the interactive output of Elixir. Note :hello is an atom, but not a boolean
  4. iex(7)> is_boolean :true
    true
    iex(8)> is_boolean :false
    true
    iex(9)> is_atom :true
    true
    iex(10)> is_atom :false
    true

    iex(11)> is_boolean :hello
    false
    iex(12)> is_atom :hello 

Monday, November 06, 2006

Negation of Good Software Engineering

While I was reading some random blogs, Stevey's blog on good and bad agile programming caught my eyes. That article is a long-winded one, touching on the agile programming methodology.

As an example of good programming practices, he quoted Google. What I found amusing was everything we did then was exactly the negation of what is being done in Google. The up-side for me is all these things I realized were unproductive and complained loudly to the management. Even though nothing was done and I left, but I am glad at least I tried.

Here are some examples (as according to Stevey):
  • Most Google managers code at least half-time
  • Schedule pressure is minimum, at least there is no Gantt chart floating around
  • Developers are encouraged to spend 20% of their WORK hour on their own projects. Please note I high-lighted 'work' to signify these are real working hours, instead of weekend or evening hours
  • There aren't many meetings
  • The work space is quiet

Friday, October 20, 2006

Optimal Function Size

How big should a function be? Someone has very practical answer, paraphrasing what the author said:

"Once my friend interviewed a candidate for programming job, in the interview my friend casually asked how the candidate tell if a function is too big. 'When it is bigger than my head', the candidate replied. My friend was puzzled, thinking this candidate was referring to his brain capacity. The candidate went on to explain 'I will stick my head on the monitor and if the function is bigger than my head, it is not good'."


This is probably one of the most practical definition for optimal function size I have seen so far, mainly you have something very measureable during formal code reviews. i.e. What? you think your function is all right? You have a 2-feet face?

If I were the interviewer, I would have hired that guy.

So dear reader, do your have bigger-than-your-head functions today?

Wednesday, October 18, 2006

Demise of Lisp in JPL

An interesting article on demise of Lisp in JPL (Jet Propulsion Lab) to give way to more 'hip' programming languages like C++ and Java:

http://www.flownet.com/gat/jpl-lisp.html


If you ever spent any respectable days in the tech industry, you will see the industry is usually not controlled and managed by the ablest and most competent people
. In fact, most people (especially managers and up) are:
  • Clueless about the technology
  • Always assuming the hottest technologies are the best, regardless of the skillsets of the engineers and the applicability of the problems at hand

Thursday, October 12, 2006

Playing with Fibonacci Number

Fibonacci number is defined simply by the following equations:

y(1) = 1
y(2) = 1
y(k) = y(k-1)+y(k-2) for all k > 2

Hence we will have a sequence like this: 1, 1, 2, 3, 5, 8, 13,... ad infinitum

The Challenge
To code a complete program fib(n) that will generate the first n-th Fibonacci number as compact as possible on the source code level. This is in contrary with the the common code optimization which depend a lot on the hardware and compiler. What I am striving to do here is to accomplish this task with the minimum number of statements.

But first question you, my dear reader may ask is "What is this for?". Answer: nothing, just for the hack of it due to boredom. Subsequent question could be "This is not fair to compare language X against language Y because X is for some A purpose and Y is for some B purpose, etc.", well, I will do this in a way as fair as I could make it, but in the real programming world, you seldom get the tool which is truly apt for the problem in hand. Don't believe me? Join a large company and see.

Any language can be used, including assembly language (bless you though).

You may assume the input parameter n is a positive integer > 2 (to avoid the corner cases) and is always valid and sane.

To kick start this, let's have our first foray in C.

To compile: 'gcc -o fib fib.c'.

#include <>

int main()
{
int i = 0;
for(i=1; i<10; i++)
printf("Fib %d is %d\n", i, fib(i));
return 0;
}/* main */

int fib (int n)
{
if (n <= 2) return 1;
else return fib(n-1) + fib(n-2);

}/* fib */