msgbartop
Code that explodes conventions
msgbarbottom

15 Aug 11 Programming Languages Have Tradeoffs

My friend Bazlur recently wrote a note that asserts, “Functional language will rule the future programming world.”  His assertion has merit, but it misses a key point: programming languages have tradeoffs.  Each language has its own advantages that are well suited for a particular domain.

Bazlur’s affinity for functional programming languages is well founded.  Erlang in particular has been able to achieve dazzling amounts of concurrency.  In fact, Erlang actually runs better on multi-core machines than it does on single-core; its performance in clouded environment is better still.  Other production-ready functional languages like Scala have similar properties, so Bazlur’s admiration for functional languages is very well grounded.

Given the need for massive amounts of concurrency in today’s applications, languages that are less amenable to high concurrency would seem to go by the wayside.  Why would anyone use C, C++, C#, or Java anymore?   Functional languages that are designed to be massively parallel have a weakness.  While a given environment can support more threads with such languages, each thread takes longer to accomplish a given task.   C# and Java are faster at executing a given piece of code; C and C++ are faster than either of those languages.  As a result, the benefits that functional languages provide have tradeoffs.

Balancing the tradeoffs between languages is a discussion for another time.  Where the tradeoffs become a detriment is highly dependent upon the project and the utilization of the language in question, but that question is beyond the scope of this note as well.  This note is merely trying to convey the idea that such considerations should be taken into account when choosing a technology.  To put it simply, there are no magic bullets, and you should avoid falling into the trap of thinking that any technology is.

15 Aug 11 Using Comments as Notes

Every programmer with a decent amount of experience is familiar with comments. The debate over how comments should be used is long standing. The purpose of this entry is not to fire another salvo in that debate; instead, my aim is to elucidate how comments help me as a programmer.

Comments are used to describe code; those descriptions often act as documentation within the code. However, that documentation’s primary purpose is to help future developers. Anyone who has the job of updating your code can read that documentation to understand how it works. When working with particularly idiosyncratic code, comments as documentation can be greatly helpful. While helpful to future developers, comments have a more useful purpose to the current developer.

My experience as developer has taught me an important lesson: what was clear at the time to me is not always clear to me in the future. To clarify, remembering what my thought process was several months or years ago is often difficult. Ferreting the thought process out of straightforward code that follows a recognizable pattern is easy. As code becomes more idiosyncratic and complex, deducing the thinking behind code becomes more difficult. Even your own code can become difficult to understand if enough time has passed.

The solution in part to the problem that was described above is to use comments as notes. Any complex class, function, or statement should have notes attached to it. If code has idiosyncrasies, then you should note the nature of the oddness of your code as well. Even if a piece of code may produce errors, a note should also be made. Noting such things helps jog your memory if you go back to make changes or fix bugs. Speeding up the process of jogging your memory helps save you time and errors. The pain of determining what your own code does is lessened as a result.

I hope that this advice is helpful. It has been helpful to me. When I have had to debug complex applications, my own notes to myself are what saved me from going crazy. As a man who tries to be helpful, I would like to pass this tip to anyone who reads this blog post.

10 Aug 11 Functional language will rule the future programming world

I think, Functional languages will rule the future programming world.

You know, processors have stopped getting faster, socked! Actually that’s why we need multiprocessor computer. So our software needs to become concurrent as well.

Compilers can't automatically parallelize imperative/object oriented code. So programming style has to change. Algorithmically simple concurrency can be achieved using libraries and extensions to existing language. You can use the concurrent package in java.

But building complex, fine-grained concurrent system like Facebook, twitter is not possible. So here we need a functional language. So Erlang or Scala is a solution. You probably don’t know, Facebook use Erlang to handle concurrency. Erlang is a highly fault-tolerant language. Not only Erlang, Facebook use C++, Huskell, Thrift in backend also. You can go with Huskell even; it can go even further with software transactional memory and nested data parallelism.

So guys learn a functional programming language. I think, future programming world is parallel programming world and obviously you need to learn a functional language, like Erlang, Scala, Clojure or Erlang. Why need to learn a functional language, can be your question, of course it is a good question. To write maintainable, scalable, concurrent and fault-tolerant code for a big parallel system, I don’t think, it’s possible with object oriented programming language and that will not be costly enough. Think about Facebook, Google+, if you add any new features today, you can surely assume that immediately millions of user will use it. So its all about a big challenge.

Let me quote an example from a Facebook developer note, its about Facebook chat system :

The most resource-intensive operation performed in a chat system is not sending messages. It is rather keeping each online user aware of the online-idle-offline states of their friends, so that conversations can begin. Each Facebook Chat user now needs to be notified whenever one of his/her friends

(a) takes an action such as sending a chat message or loads a Facebook page (if tracking idleness via a last-active timestamp) or (b) transitions between idleness states (if representing idleness as a state machine with states like "idle-for-1-minute", "idle-for-2-minutes", "idle-for-5-minutes", "idle-for-10-minutes", etc.). Note that approach (a) changes the sending a chat message / loading a Facebook page from a one-to-one communication into a multicast to all online friends, while approach (b) ensures that users who are neither chatting nor browsing Facebook are nonetheless generating server load. Another challenge is ensuring the timely delivery of the messages themselves. Fault tolerance is a desirable characteristic of any big system: if an error happens, the system should try its best to recover without human intervention before giving up and informing the user. The results of inevitable programming bugs, hardware failures, et al., should be hidden from the user as much as possible and isolated from the rest of the system.

The way this is typically accomplished in a web application is by separating the model and the view: data is persisted in a database with each short-lived request retrieving only the parts relevant to that request. This architecture works pretty well in general; it isn't as successful in a chat application due to the high volume of long-lived requests, the non-relational nature of the data involved, and the statefulness of each request.

For Facebook Chat, we rolled our own subsystem for logging chat messages (in C++) as well as an epoll-driven web server (in Erlang) that holds online users' conversations in-memory and serves the long-polled HTTP requests. Both subsystems are clustered and partitioned for reliability and efficient failover. Why Erlang? In short, because the problem domain fits Erlang like a glove. Erlang is a functional concurrency-oriented language with extremely low-weight user-space "processes", share-nothing message-passing semantics, built-in distribution, and a "crash and recover" philosophy proven by two decades of deployment on large soft-realtime production systems.

You can read the full story from here:

https://www.facebook.com/note.php?note_id=14218138919%C2%A0

By the way, these programming language’s syntax are very much weird though, but no big deal.

05 Aug 11 A Barrel of Coding Goodies

The code below represents some useful C# coding techniques  that I've come come across while working on projects.  Take a look.

String.Format

Concatenating strings can be an unwieldy.  Often concatenation is very difficult to ready.  Unreadable code is both hard to debug and understand.   For my money, String.Format helps to address the readability issue.  There is debate as to what use.  At the behest of the Code Rush Visual Studio plugin, I began using it more often.   The result has been more readable string code.   There are trade offs.  Performance is one.  Necessity is another one; using String.Format for one variable is a little pointless.  Still, the benefit of integrating the function into your code is positive on the whole.

Generics and Statics

Anything declared static is stored in one location.   The monkey wrench in this definition is generic statics.   A class member or class may be have generic parameters.

C# requires that each time a different parameter is passed a new version of that particular C# piece be created at compile time.   Consequently, static generics are not stored in one location; rather, each version of the static has its own location.   The static concept still holds in that each version of the static still has one location, but the addition of the generics means that one piece of C# can actually be many at compile time.

The creation of several pieces of code where there would normally only be one has some interesting consequences.   For example, a static constructor, which is normally only called once, can actually be called multiple times when the constructor's class is generic, because each version of a generic class is actually a different class at compile time.   If an event is generic, that same event is actually treated as multiple events, so each of those versions can have its own handler.   Both of those  results can be achieved through creating multiple classes and events, but generics allow one class or event to act like multiple.

The Code

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ABarrelOfGoodies
{
class Program
{
static void Main(string[] args)
{
testStringFormat();
testGenericsAndStatics();
pause();
}

#region Test Methods

///
/// The method below demonstrates the String.Format Method.
/// The benefits on concatentation versus String.Format
/// are debatable. In my opinion, the string below, which uses
/// many variables, is more readable using String.Format.
///
private static void testStringFormat()
{
Console.Out.WriteLine("I am testing String.Format below");

Object[] formatParms = { "Collin", "computer programmer", "new person" };
String stringformatTest = String.Format("Hello my name is {0}. I am a {1}.  It is very nice to meet you, {2}", formatParms); //tests with a null object

Console.Out.WriteLine("Format result: " + stringformatTest);
}

///
/// This function demonstrates the power generics to mold a
/// function to many data types. When combined with statics,
/// a static member is actually multiple members, one for each
/// implementation of the type.  At a class level, the class is
/// actually multiple classes, one for each type.  The multiple
/// callings of the static constructor actually demonstrates
/// that fact. In spite of the multiplicity of runtime
/// implementations, the code is stored in one place.
///
private static void testGenericsAndStatics()
{
Console.Out.WriteLine("I am testing generics and statics below");

GeneraticEventArgsClass stringEventArgs = new GeneraticEventArgsClass();
stringEventArgs.EventData = "Hello World!";
String stringEventReturn = GenericStaticClass.onTestEvent(null, stringEventArgs);
Console.Out.WriteLine("The event's result is " + stringEventReturn);

GeneraticEventArgsClass intEventArgs = new GeneraticEventArgsClass();
intEventArgs.EventData = 10;
int intEventReturn = GenericStaticClass.onTestEvent(null, intEventArgs);
Console.Out.WriteLine("The event's result is " + intEventReturn);
}

#endregion

#region Utility Methods

/*
* barrowed from: http://cboard.cprogramming.com/csharp-programming/83394-system-pause-csharp-warning-noob-question.html
* pauses a console program
*/
public static void pause()
{
Console.Write("Press any key to continue . . . ");
Console.ReadKey(true);
}

#endregion
}
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ABarrelOfGoodies
{
///
/// This class demonstrates how generics modify statics. The
/// example includes static events and delegates
///
public class GenericStaticClass
{
#region Delegates

public delegate T SampleDelegate(Object sender, GeneraticEventArgsClass e);

#endregion

#region Events

public static event SampleDelegate testEvent;

#endregion

#region Constructors

static GenericStaticClass()
{
Console.Out.WriteLine("Calling GenericStaticClas Static Constructor");
testEvent += genericStaticClassTestEventHandler;
}

#endregion

#region Event Handlers

private static T genericStaticClassTestEventHandler(Object sender, GeneraticEventArgsClass e)
{
return e.EventData;
}

#endregion

#region Methods
///
/// This is what is called an event trigger. An event trigger
/// is a launching point for an event.
///
///

<param name="sender" /> /// <param name="e" /> ///
public static T onTestEvent(Object sender, GeneraticEventArgsClass e)
{
SampleDelegate handler = testEvent;

&nbsp;

if (handler != null)
{
return testEvent(sender, e);
}
else
{
return default(T);
}
}

#endregion
}
}

using System;
using System.Collections.Generic;
using System.Linq;

namespace ABarrelOfGoodies
{
///
/// This is an example of extending EventArgs.
///
///
public class GeneraticEventArgsClass : EventArgs
{
#region Data

#endregion

#region Accessors

///
/// This is an example of an auto-implemented property,
/// it does not require explicitly defined variable behind it.
///
public T EventData { get; set; }

#endregion
}
}
Loading...
Join thousands and get updates for free...No-Spam Guarantee