Currently showing entries with the tag: SQL Server
|
page 1 of 1
|
Book Review: Programming Erlang
October 23, 2007 • 8:54PM • permalink
As you may know from reading my previous blog entries, I've recently been trying to mix up the books in my reading queue by exploring the benefits of a few new programming languages. Recently a friend of mine told me a few things about functional programming, concurrency and Erlang which inspired me to check it out.
Joe Armstrong, one of the creators of the Erlang language, has recently published a new book on the topic and its truly a fascinating read.
One of the biggest complaints I hear from other developers about any introductory level book about a new programming language is the lack of useful programs that can be created upon completion of the book. What I mean is that you may be able to do the normal "Hello World", Fibonacci sequence output, etc. - but you probably won't be able to do anything really useful. This isn't the case with Armstrong's book.
The main ideas of the book and of Erlang (free for most environments at http://www.erlang.org) in general is concurrency or the simultaneous execution of code. While C and its variants offer multi-threading, it is still essentially executing sequential code and hence subject to deadlocks, race-conditions, etc. Erlang enforces some strict rules from the get-go to support concurrency and allow for true simultaneous execution that is free from not only race-conditions and deadlocks, but from semaphores, mutexes and locks as well.
In order to do that, Erlang turns computer science on its head (from a sequential programming point-of-view) which Armstrong is quick to point out at every turn. For example, variables are only called as such because it makes things easier. The fact is they can't actually vary and an Exception is thrown if you even try.
On that same note, the equal sign is not the assignment operator like it usually is in programming, it is instead used to perform pattern matching. An example would probably work best to explain it:
1>X = 5.
5
2>X = 5.
5
3>X = 3.
=ERROR REPORT==== 16-Oct-2007::21:26:12 ===
Error in process <0.30.0> with exit value: {{badmatch,3},[{erl_eval,expr,3}]}
** exited: {{badmatch,3},[{erl_eval,expr,3}]} **
As I stated before, the = is not the assignment operator, it is instead used for pattern matching. An additional caveat though, when used with an uninitialized variable (which usually start with Capital letters), the variable is assigned that value. In line 1 above, we match the variable X against the literal value 5. Since X is uninitialized at the time we match it against the literal 5, it then takes on that value.
This is why, when we repeat the action in the second line, it returns the value 5 (indicating a match). Consequently, when we hit the third line, the shell throws an exception since we're matching X against 3, when it has already taken on the value 5.
You may wonder what the value of such an operator is, but when you dive into server programming, you'll see that it can be used (among other things) to direct functionality within network protocols. By matching against certain patterns, you can essentially code mini-conditional statements to perform various actions upon receipt of certain data. It seems complicated, but it's really not - since this is a Book Review and not an Introduction to Erlang, so I'll leave the explanation to Armstrong...
Within 75 pages, I had gained an enthusiasm for Erlang that was apparently infectious and it has been embraced by a few other developers in my Department (including Jon over at Rusty Razor Blade). While we're still not 100% sure it will be able to support the traffic load and perform fast enough, we're motivated enough to try. Armstrong makes it easy to learn from example too, since the book contains Erlang source to create a server for almost any major network protocol or project you could think of including IRC, SHOUTcast, a simple Error logger, a SQL Server and a Web Server.
We've discussed a plethora of different ideas we could run on our "new Erlang Framework", some more ambitious than others. We're convinced we could rewrite memcached in a few hundred lines of code, including all the features of the original - a few that are missing and commonly implemented in other cache systems - as well as a few of our own custom design. We figure if we can even get 80% of the throughput of our current memcached implementation than it will be worth our trouble. Especially if it enables us to build a Erlang Framework to support any scalable idea we can come up with.
So if the idea of scalable server applications, functional programming or Erlang in general seems interesting, I highly suggest you check out Programming Erlang.
Joe Armstrong, one of the creators of the Erlang language, has recently published a new book on the topic and its truly a fascinating read.
One of the biggest complaints I hear from other developers about any introductory level book about a new programming language is the lack of useful programs that can be created upon completion of the book. What I mean is that you may be able to do the normal "Hello World", Fibonacci sequence output, etc. - but you probably won't be able to do anything really useful. This isn't the case with Armstrong's book.
The main ideas of the book and of Erlang (free for most environments at http://www.erlang.org) in general is concurrency or the simultaneous execution of code. While C and its variants offer multi-threading, it is still essentially executing sequential code and hence subject to deadlocks, race-conditions, etc. Erlang enforces some strict rules from the get-go to support concurrency and allow for true simultaneous execution that is free from not only race-conditions and deadlocks, but from semaphores, mutexes and locks as well.
In order to do that, Erlang turns computer science on its head (from a sequential programming point-of-view) which Armstrong is quick to point out at every turn. For example, variables are only called as such because it makes things easier. The fact is they can't actually vary and an Exception is thrown if you even try.
On that same note, the equal sign is not the assignment operator like it usually is in programming, it is instead used to perform pattern matching. An example would probably work best to explain it:
1>X = 5.
5
2>X = 5.
5
3>X = 3.
=ERROR REPORT==== 16-Oct-2007::21:26:12 ===
Error in process <0.30.0> with exit value: {{badmatch,3},[{erl_eval,expr,3}]}
** exited: {{badmatch,3},[{erl_eval,expr,3}]} **
As I stated before, the = is not the assignment operator, it is instead used for pattern matching. An additional caveat though, when used with an uninitialized variable (which usually start with Capital letters), the variable is assigned that value. In line 1 above, we match the variable X against the literal value 5. Since X is uninitialized at the time we match it against the literal 5, it then takes on that value.
This is why, when we repeat the action in the second line, it returns the value 5 (indicating a match). Consequently, when we hit the third line, the shell throws an exception since we're matching X against 3, when it has already taken on the value 5.
You may wonder what the value of such an operator is, but when you dive into server programming, you'll see that it can be used (among other things) to direct functionality within network protocols. By matching against certain patterns, you can essentially code mini-conditional statements to perform various actions upon receipt of certain data. It seems complicated, but it's really not - since this is a Book Review and not an Introduction to Erlang, so I'll leave the explanation to Armstrong...
Within 75 pages, I had gained an enthusiasm for Erlang that was apparently infectious and it has been embraced by a few other developers in my Department (including Jon over at Rusty Razor Blade). While we're still not 100% sure it will be able to support the traffic load and perform fast enough, we're motivated enough to try. Armstrong makes it easy to learn from example too, since the book contains Erlang source to create a server for almost any major network protocol or project you could think of including IRC, SHOUTcast, a simple Error logger, a SQL Server and a Web Server.
We've discussed a plethora of different ideas we could run on our "new Erlang Framework", some more ambitious than others. We're convinced we could rewrite memcached in a few hundred lines of code, including all the features of the original - a few that are missing and commonly implemented in other cache systems - as well as a few of our own custom design. We figure if we can even get 80% of the throughput of our current memcached implementation than it will be worth our trouble. Especially if it enables us to build a Erlang Framework to support any scalable idea we can come up with.
So if the idea of scalable server applications, functional programming or Erlang in general seems interesting, I highly suggest you check out Programming Erlang.
0 comments
Writing SQL Scripts to Generate SQL Scripts
September 01, 2007 • 6:43AM • permalink
This came up at work the other day, but it's a very helpful trick if you find yourself replicating the same set of tables over and over again.
Let's say you have the following table:
CREATE TABLE [countries]
(
country_id INT,
country NVARCHAR(64)
);
Let's say I use a common list of countries everytime I create a new website. The above data is prepopulated and we'll say its filled with about 200 rows. While there are a few easy ways to generate the script, it seems like a waste to do something like create an entire C# program or even a write Python script.
Fortunately, you can use the fact that SELECT can return static data to quickly generate the script, like so:
SELECT
'INSERT INTO [countries]
(country_id, country)
VALUES
(' + CAST (country_id AS VARCHAR(3)) + ', ''' + country + ''');'
FROM [countries];
This would return the following:
INSERT INTO countries (country_id, country) VALUES (1, 'United States');
INSERT INTO country (country_id, country) VALUES (2, 'Afghanistan');
INSERT INTO country (country_id, country) VALUES (3, 'Albania');
...
All you're doing is SELECTing out a concatenated string that will generate your commands. Then you can copy and paste it to a text file, which you can use as a reusable utility script.
This can be very helpful when you use a common framework that gets replicated for several projects. I personally use it for doing things like the above country example, prepopulating geographical information, adding default administrator accounts to new websites, and propagating a list of banned IPs.
Let's say you have the following table:
CREATE TABLE [countries]
(
country_id INT,
country NVARCHAR(64)
);
Let's say I use a common list of countries everytime I create a new website. The above data is prepopulated and we'll say its filled with about 200 rows. While there are a few easy ways to generate the script, it seems like a waste to do something like create an entire C# program or even a write Python script.
Fortunately, you can use the fact that SELECT can return static data to quickly generate the script, like so:
SELECT
'INSERT INTO [countries]
(country_id, country)
VALUES
(' + CAST (country_id AS VARCHAR(3)) + ', ''' + country + ''');'
FROM [countries];
--Note the use of the '' to escape the single-quote for output
This would return the following:
INSERT INTO countries (country_id, country) VALUES (1, 'United States');
INSERT INTO country (country_id, country) VALUES (2, 'Afghanistan');
INSERT INTO country (country_id, country) VALUES (3, 'Albania');
...
All you're doing is SELECTing out a concatenated string that will generate your commands. Then you can copy and paste it to a text file, which you can use as a reusable utility script.
This can be very helpful when you use a common framework that gets replicated for several projects. I personally use it for doing things like the above country example, prepopulating geographical information, adding default administrator accounts to new websites, and propagating a list of banned IPs.
|
page 1 of 1
|
