A quiet life without a TV tuner

I've been spending time without TV at home since this (2008) September. And I recommend you to do so too for living a quiet life.

I decided to stop watching TV regularly; no airwave, no satellite, no cable channel at all. Actually the condo building I live is cable-TV ready. But I decided to quit. I gave our LCD TV to my wife's Mom. We instead listen to the radio when we're at home and having a dinner or lunch and we want some news. Most of airwave TV programs are junk. And most of non-airwave (that is, paid) TV programs are also junk. And we know most of airwave radio programs are junk. But some of them, including news and classic music programs of our national broadcaster (in Japan), are fortunately not. I carry around a pocket radio when I travel in Japan to listen to the same night program called Radio Shin-ya-bin, a rather-quiet-and-calm program without ads.

We still want to see the DVD contents. We have a DVD player. So I decide to newly buy and install a new PC display instead. It accepts DVI, VGA, component and NTSC video, and even HDMI. It has 1920x1200 pixel resolution; an excessive spec for DVD or an old PC. It doesn't have a TV tuner, however. It doesn't have speakers either, but that is OK, because I installed a pair of speakers and an amplifier with AM/FM radio tuner installed. So no problem for enjoying audio.

The good thing about not watching TV while on a family meal is that we rather talk and make a lot of conversations. And we started to read a lot of books and talk about them. It's like living in the world of 1950s or 1960s, though we still use PCs.

We have also quit subscribing newspapers since this April. I decided so because even Nikkei Shimbun, let alone other papers, were carrying junk articles these days. The New York Times and The Economist have already allowed people to read their articles online freely, as other media companies follow. So I told my wife we didn't need a newspaper subscription at home anyway. She first complained, but eventually she also learned to enjoy reading something instead, or to spend the time for being exposed to mass media to something else.

We don't have any game machines such as Sony's PlayStation or Microsoft's Xbox. Our eyes can no longer follow or respond to artificial graphic pictures.

We mostly use PC to read letters and design presentations; we don't make active 3D graphics and we will not unless we need to visualize something for our works. And of course we see visual presentations on YouTube and elsewhere. The good news is, however, they are on-demand only. Unless you explicitly tell PCs to show them, you don't have to watch at those on-demand videos.

Why choosing Erlang for concurrent processing

A few weeks ago I was reading a blog article called Erlang, the next Java. While I agreed with the author's views, I felt something was bugging me in the article, which eventually lead me to write this blog article.

I didn't choose Erlang just because it's a functional language. I have chosen Erlang to learn because Erlang programming requires and has to enforce the programmers to write the concurrent code. Concurrent programing should minimize the number and size of critical regions and bottlenecks. And I think writing such programs is very difficult without the assistance of the programming language.

Many programming languages claim or plan to be capable of running a part of code based on concurrent processing. For example, Ruby will incorporate distributed storage mechanism called Roma and the task administration subsystem called Fairy. Another good example is Haskell concurrency: it is implemented as a language feature called Parallel Haskell.

I think, however, introducing concurrency while allowing programmers to write code to use shared memory will cause a lot of problems. Joe Armstrong has already described his concern on shared memory in his blog. I support his arguments; those arguments an important part of the reason why I decided to learn Erlang.

I should add another problem programmers will face when dealing with code allowing shared memory; rewriting the code for removing shared access to run it efficiently on concurrent environment will be an incredibly difficult task.

Unfortunately, most existing languages have already had a lot of code written assuming shared memory areas. For example, C code with extern variables implicitly assume those are shared between the functions in all source code files linked together. I assume I can hardly find any set of C code without using an extern declaration. I have learned that even Common Lisp has special declaration for the variables, which allows multiple functions share the same object, out of lexical scopes.

Another example of shared-memory concurrency is the operating system (OS) threads. C/C++/Java threads inherently share the parent OS process address space and environment in common. Python has the Thread Objects. While OS threads often ease implementation of concurrent servers by reducing the task switching time, the semantics is implicit and error-prone.

I understand and agree that sharing objects itself cannot be completely eliminated under the read-world constraints of processing and communication timings between programming language functions. I think, however, that programming languages should help the programmers to minimize writing code including shared memory areas, which will turn themselves into critical regions.

Erlang imposes necessary restriction on avoiding implicit data sharing between functions by:

• prohibiting multiple variable assignments in a function;


• enforcing and helping the programmers to conduct message-passing programming between functions, by not providing any implicit data-sharing facility between the functions;


• providing fast task-switching capabilities, by giving the definition that functions are the minimum concurrent execution units; and


• restricting the usage of data-sharing facilities between functions to the minimum, such as process dictionaries, ETS, DETS, Mnesia, and the global naming service shared between connected Erlang nodes, by requring explicitly writing so in the code.
  

In short, I think adding concurrent features is not enough for concurrent programming; prohibiting non-concurrent habits and enforcing writing concurrent programs are necessary as part of the programming language specifications. I believe concurrent programming under coming multi-processor environment is only possible under such a hard-liner attitude to the programmers. I feel programmers including myself are very conservative and rigid to change their sequential-programming habits.

And actually, I was one of those programmers who did not recognize the urgency of learning concurrent programming in 2007.