OCaml: The Fastest Powerful Programming Language Ever?

OCaml seems to be a (yet another) very interesting programming tool.

Objective Caml (OCaml) is the main implementation of Caml (Categorical Abstract Machine Language), which is based on ML. The Meta-Language (ML) was originally developed at Edinburgh University in the 1970’s as a language designed to efficiently represent other languages. The language was pioneered by Robin Milner for the Logic of Computable Functions (LCF) theorem prover. The original ML, and its derivatives, were designed to stretch theoretical computer science to the limit, yielding remarkably robust and concise programming languages which can also be very efficient.

There is an interpreter which runs OCaml code in a virtual machine (VM) and two compilers, one which compiles OCaml to a machine independent byte-code which can then be executed by a byte-code interpreter and another which compiles OCaml directly to native code. The native-code compiler is already capable of producing code for Alpha, Sparc, x86, MIPS, HPPA, PowerPC, ARM, ia64 and x86-64 CPUs and the associated run-time environment has been ported to the Linux, Windows, MacOS X, BSD, Solaris, HPUX, IRIX and Tru64 operating systems.

Check out its massive features!

OCaml with Ubuntu Gutsy and Compiz Fusion
OCaml interpreter session on my computer.

OCaml programs are thoroughly checked at compile-time such that they are proven to be entirely safe to run, e.g. a compiled OCaml program cannot segfault.
Functions may be nested, passed as arguments to other functions and stored in data structures as values.
Strongly typed
The types of all values are checked during compilation to ensure that they are well defined and validly used.
Statically typed
Any typing errors in a program are picked up at compile-time by the compiler, instead of at run-time as in many other languages.
Type inference
The types of values are automatically inferred during compilation by the context in which they occur. Therefore, the types of variables and functions in OCaml code does not need to be specified explicitly, dramatically reducing source code size.
In cases where any of several different types may be valid, any such type can be used. This greatly simplifies the writing of generic, reusable code.
Pattern matching
Values, particularly the contents of data structures, can be matched against arbitrarily-complicated patterns in order to determine the appropriate action.
Programs can be structured by grouping their data structures and related functions into modules.
Data structures and related functions can also be grouped into objects (object-oriented programming).
Separate compilation
Source files can be compiled separately into object files which are then linked together to form an executable. When linking, object files are automatically type checked and optimized before the final executable is created.

Time for some sample code, to calculate f(x)=x3x−1:

# let f x = x *. x *. x -. x -. 1.;;
val f : float -> float = <fun>

According to Kevin Murphy, “… benchmarks … suggests the Ocaml compiler generates the second fastest code of any of the currently available compilers (gcc and the Intel C compilers being first). Given that Ocaml is also a beautiful language to program in, this is pretty compelling.”


Oz Multiparadigm Concurrent Programming Language, The

I’m not sure about you, but to me Oz looks like a cool programming language to learn… and use:

Oz is a multiparadigm programming language, developed in the Programming Systems Lab at Saarland University.

Oz contains most of the concepts of the major programming paradigms, including logic, functional (both lazy and eager), imperative, object-oriented, constraint, distributed, and concurrent programming. Oz has both a simple formal semantics (see chapter 13 of the book mentioned below) and an efficient implementation. Oz is a concurrency-oriented language, as the term was introduced by Joe Armstrong, the main designer of the Erlang language. A concurrency-oriented language makes concurrency both easy to use and efficient.

In addition to multi-paradigm programming, the major strengths of Oz are in constraint programming and distributed programming. Due to its factored design, Oz is able to successfully implement a network-transparent distributed programming model. This model makes it easy to program open, fault-tolerant applications within the language. For constraint programming, Oz introduces the idea of “computation spaces”; these allow user-defined search and distribution strategies orthogonal to the constraint domain.

See it in action on my computer:

Oz Mozart in action

Far from bad, eh?

The language is pretty nice and clean, yet has advanced built-in features like concurrency… whoa…

   Z = X+Y     % will wait until both X and Y are bound to a value.
   {Browse Z}  % shows the value of Z.
thread X = 40 end
thread Y = 2 end

The primary tool for developing Oz applications is Mozart Programming System.

So, now, anything interesting? 😉

Semantic Interface Driven Architecture and Continuous Change Driven Development

The time has come for yet another wishful thinking. With the rise of Service Oriented Architecture (SOA) and Event Driven Architecture (EDA), and Test Driven Development (TDD) extended with Behavior Driven Development (BDD), and a bunch of other buzzwords… let me introduce something else for the enterprise world:

Semantic Interface Driven Architecture (SIDA)

In short, it’s a Model Driven Architecture (MDA), sprinkled with interfaces to reduce coupling of inter-model transformations, and semantic inferences in the spirit of topic maps and RDF+OWL, implemented on top of SOA and EDA.

MDA allows different services to communicate with each other by transforming models. The interfaces provide agreeing on specifications to common semantics. Semantics themselves are inferable, and navigable. Thus, it is possible to interrelate models even though they are entirely in different layers and/or (heterogeneous/external) systems.

Continuous Change Driven Development (CCDD)

In short, it’s a development approach where the requirements are constantly changing. Constantly, that is, as in “real-time”, in order of milliseconds. One millisecond you need to have this table, the next you have to add a column, the next you have to drop a whole table, and in the next you want a whole form, relationships…

Requirements are not specified upfront, but simply as a “starting point”. Much like the way (probably) the universe started during the Big Bang. Everything else is evolutionary, and can be changed in real time by the individual users of the application. It might also be named Real-time Evolution Driven Development (REDD), which is probably more buzzy.

Some of the general traits of this approach are:

  • extensive use of ultra meta-programming
  • taken-for-granted interoperability with other SIDA systems
  • fuzzy specifications/requirements (i.e. “want” instead of “what/how”)
  • generatively programmable systems
  • decentralized source code management (i.e. version control) is taken for granted


Let me know of your comments. If you are interested in doing research together, by all means please do. I’m serious.


Erlang: The Concurrent Programming Language

Thank you Orbitz for posting [Erlang vs.] Java and and Threads (Jetty):

The basic idea is, instead of using 1 thread per connection, since connections can last awhile, they use 1 thread per request that a connection has. The hope being, a connection will idle most of the time and only send requests once in awhile. The problem that they ran into is, a piece of software is using a request timeout to poll for data. So requests are now sticking around for a long time, so they have all these active threads that they don’t want. So to deal with this, they use a concept of continuations so the thread can die but the request still hang around, and then once it’s ready to be processed a thread is created again and the request is handled. So having all these requests hanging around that arn’t doing anything is no longer a problem.

ell, this begs the question, why are you using a dynamic number of threads in the first place if you are going to have to limit how many you can even make. If the problem, in the first place, is they have too many threads running, then their solution works only for idle threads doesn’t it? Being forced to push some of the requests to a continuation means they have applied some artificial limit to the number of threads which can be run. What happens then, when the number of valid active requests exceeds this limit? What then? Push active requests to a continuation and get to then when you have time? Simply don’t let the new requests get handled? If they want to to use threads to solve their problem then putting a limit on them seems to make the choice of threads not a good one. Too poorly paraphrase Joe Armstrong, are they also going to put a limit on the number of objects they can use? If threads are integral to solving your problem, then it seems as though you are limiting how well you can solve the problem.

This also got me thinking about other issues involving threading in non-concurrent orientated languages. Using a COL (Concurrent Orientated Language) all the time would be nice (and I hope that is what the future holds for us). But today, I don’t think it is always practical. We can’t use Erlang or Mozart or Concurrent ML for every problem due to various limiting factors. But on the same token, using threads in a non-COL sometimes makes the solution to a problem a bit easier to work with. At the very least, making use of multiple processors sounds like a decent argument. But writing code in, say, java, as if it was Erlang does not work out. I think the best one can hope to do is a static number of threads. Spawning and destroying threads dynamically in a non-COL can be fairly expensive in the long run and you have to avoid situations where you start up too many threads. I think having a static number of threads i a pool or with each doing a specific task is somewhat the “best of both worlds”. You get your concurrency and you, hopefully, avoid situations like Jetty is running into. As far as communication between the threads is concerned, I think message passing is the best one can hope for. The main reason I think one should use message passing in these non-COL’s is, it forces all of the synchronization to happen in one localized place. You can, hopefully, avoid deadlocks this way. And if there is an error in your synchronization, you can fix it in one spot and it is fixed everywhere. As opposed to having things synchronized all over the code, god knows where you may have made an error.

…although it seems not all his readers corroborate with what he meant by “concurrent oriented languages”.

I strongly concur that languages *such as* Erlang (I’m saying such as, because Erlang got the concept right, and other languages /platforms/technologies may follow) will lead or at least make the transition into the future easier.

What the hell is Erlang anyway? Well:

Joe Armstrong had fault tolerance in mind when he designed and implemented the Erlang programming language in 1986, and he was subsequently the chief software architect of the project which produced Erlang/OTP, a development environment for building distributed real-time high-availability systems. More recently Joe wrote Programming Erlang: Software for a Concurrent World. He currently works for Ericsson AB where he uses Erlang to build highly fault-tolerant switching systems.

Erlang is a concurrent functional programming language. Basically there are two models of concurrency:

  • Shared state concurrency
  • Message passing concurrency

Virtually all language use shared state concurrency. This is very difficult and leads to terrible problems when you handle failure and scale up the system.

Erlang uses pure message passing concurrency. Very few languages do this. Making things scalable and fault-tolerant is relatively easy.

Erlang is built on the ideas of:

  • Share nothing. (Process cannot share data in any way. Actually, this is not 100% true; there are some small exceptions.)
  • Pure message passing. (Copy all data you need in the messages, no dangling pointers.)
  • Crash detection and recovery. (Things will crash, so the best thing to do is let them crash and recover afterwards.)

Erlang processes are very lightweight (lighter than threads) and the Erlang system supports hundreds of thousands of processes.

It was designed to build highly fault-tolerant systems. Ericsson has managed to achieve nine 9’s reliability [99.9999999%] using Erlang in a product called the AXD301. [Editor’s Note: According to Philip Wadler, the AXD301 has 1.7 million lines of Erlang, making it the largest functional program ever written.]

While people are talking about 16-, 32-, 64- bits… And limit their “stuff” (whatever it is, threads, objects, RAM, …) accordingly, in Erlang there is no such hard limit.

Erlang processes can grow as big as it wants, provided you give it *enough resources*. Which means, the *same* Erlang program can run on 1 node on a single workstation, or on 1,000 servers spread across different buildings (or continents). The programmer doesn’t care anyway.

How much limited RAM? How much sockets can be open? etc. doesn’t depend on the programmer, and hopefully the programmer won’t need to care about it. Who will care about it is the one who’ll be deploying and running the Erlang program.

Most people still think of programming (and worse, think of Erlang) as procedural languages, then built things on top of it including threading… a threading framework.

Erlang on the other hand is sort of kernel (hence why it’s called a VM, not simply an interpreter but a real VM that manages processes the way a OS manages OS processes). Every function runs on different processes. A process may run in its own Erlang VM node, a different VM node in the server, or on another server. The program doesn’t really care that much (it can care, but doesn’t have to use a “distributed framework” the way other languages do.)

More information about this exciting language:

Update: Some frameworks, in particular Message Queueing systems (e.g. Microsoft’s and Sun Java’s), I think got it right… but on a more complicated, heavyweight level. Erlang/OTP is, under the hood, a message queueing system but much lighter on the CPU… and much lighter on the programmer brain overhead. 😉

Update 2: As of now I still don’t know what OTP stands for 😉

Ubuntu, Muslim Edition

Buat yang Islam, dan pengen komputernya juga terisi hal-hal yang bertema Islami… Baru nemu, keren juga.

Dari udienz:

Bismillahirrohmanirrohiem, Assalamualikum

Di Linux kita bisa mengoprek system sesuka kita (tp harus jadi root), hm… kemarin iseng iseng lihat ubuntu-me via website resminya, dan sempat kecewa sih sebenarnya karena tidak ada perubahan signifikan dari Ubuntu , cuma tambah beberapa program aja… (mungkin butuh kontribusi kita kali ya…)

oke akhirnya saya pengen membuat Ubuntu feisty saya menjadi Ubuntu-ME, pertimbangan:

1. ribet install ulang

2. males konfigurasi ulang

3. ga ada waktu lagi…

gimana caranya biar ubuntuku jadi Ubuntu-ME???

seperti yang telah kita ketahui Ubuntu-ME menambahkan program-program tambahan di distro tersebut, yaitu ubuntume-artwork, wcc (Web Content Control tool), islamiccal, zekr, minbar. perincianya adalah sebagai berikut:

1. Ubuntu-Me artwork adalah paket yang menyediakan theme, splash screen, dll

Gambar.1 Wallpaper Ubuntu-Me

Gambar 2. Tampilan Log-In

Gambar 3. Alternatif Tampilan Log-In

Gambar 4. splash screen

Gambar 5 Tampilan Theme

2. wcc (Web Content Control tool), cocok buat yang mau jaga si kecil dari situs porno dan tampilan seronok

Gambar 6 Pengaturan

Gambar 7 ups…. ada yang mau ke situs PlayBoy

3. Islamic Calender, kalo yang ni ga ussah di jelasih semua pada udah tau lah….

4. zekr, ini yang aku suka, dia menampilakan text Al-Qur’am secara lengkap dan bagus

Gambar 8 Tampilan Zekr

5. minbar, masih ingat program Athlan di *indows??? mirip seperti ini… ni program cocok buat pelupa, coz dapat mengingatkan kita waktu sholat


Untuk instalasi dan info lengkap baca Feisty jadi Ubuntu Muslim Edition.

Best Ubuntu Tutorials by Christer Edwards

I just found a very nicely packed with useful information site for Ubuntu called Ubuntu Tutorials, created by Christer Edwards.

Among the top Ubuntu tutorials he posted include:*

I found his site while searching for a way to install Thunderbird And hey, he also have tried Ubuntu 7.10 Gutsy Gibbons (pre-release).

If you’re not aware of Ubuntu, visit Ubuntu web site. Summary: Excellent free operating system. 🙂

I’ve also written some articles about Ubuntu.

* As of this writing.

Makan Pelan + Mengunyah itu *Sangat* Penting!

Anda sering atau sedang mengalami masalah kesehatan? Obesitas, diabetes, maag, diare, dan lain-lain?

Cobalah tips yang sangat sederhana ini: mengunyah makanan dengan pelan pada saat makan, jangan tergesa-gesa.

Alasannya? Artikel Irvan Tambunan ini sangat bagus:

Menurunkan berat badan. Menurut penelitian, saat makan dengan pelan, kita mengonsumsi beberapa kalori. Faktanya, cukup untuk mengurangi 10 kilogram dalam setahun tanpa melakukan sesuatu
apapun. Otak memerlukan waktu 20 menit untuk menyadari bahwa kita sudah kenyang. Makan dengan pelan, menyadari bahwa kita sudah kenyang, dan kita dapat berhenti makan tepat waktu. Jadi, untuk mengurangi berat badan, kita harus makan dengan pelan.

Menikmati makanan. Ini merupakan alasan yang sangat masuk akal. Saya teringat dengan kejadian yang dialami teman saya.Karena makan dengan cepat, dia sempat tersedak saat makan. Wah, tentu hal ini sangat menyiksa. Suasana makan pun terasa tidak enak lagi. Dengan makan pelan, kita dapat merasakan nikmatnya rasa makanan yang kita santap.

Pencernaan yang baik. Jika kita makan dengan pelan, kita dapat mengunyah makanan secara sempurna. Saya teringat pelajaran di SD bahwa kita harus mengunyah makanan sebanyak 32 kali sebelum ditelan. Ini dapat membuat pencernaan kita menjadi lancar. Karena sudah dikunyah dengan sempurna di dalam mulut, usus halus tidak perlu bersusah payah menguraikan makanan lagi untuk menyerap sari-sari makanan. Dengan ini, pencernaan menjadi lebih baik.

Mengurangi stres. Saat makan dengan pelan, otomatis konsentrasi hanya tertuju pada makanan. Kita tidak akan berpikir pada masalah yang sedang dihadapai. Dengan demikian, masalah yang dapat membuat kita stres akan hilang sementara. Ada beberapa orang yang percaya bahwa salah satu cara mengurangi stres adalah dengan makan. Menurut saya, hal ini ada benarnya juga. P

Melawan terhadap fast food dan fast life. Gaya hidup instan membuat kita sering untuk memakan makanan cepat saji. Sebut saja restoran fast food yang terkenal seperti McDonald’s. Hal ini membuat hidup kita menjadi tidak sehat, penuh dengan stres, dan tidak menyenangkan. Saya menyarankan kepada anda agar tidak sering mengunjungi restoran tersebut. Sebisa mungkin untuk dihindari. Makanlah di restoran yang sehat, atau lebih baik masaklah makanan anda sendiri. Selain lebih sehat, memasak dapat memberikan kesenangan kepada kita. D


Kalo masih nggak percaya, coba kunjungi Slow Food Manifesto.

What The Movies Taught Me About Philosophy, Episode I

Sometimes you learned enough just by watching enough movies…

taught me that every ending has a beginning, but you can never be sure what caused that beginning.
Tomorrow Never Dies
taught me that you can always predict the future if you made sure the it will happen.
taught me that tiny things may make big changes.
Sky Captain and The World of Tomorrow
taught me that you can not only predict what happens in the future, but you can also schedule it.
The Talented Mr. Ripley
taught me that nobody has capability, or even willingness, to accept the truth.
taught me everything.
The Shawshank Redemption
taught me that you’re the only person who knows your plans better than anybody else.
Blast from The Past
taught me that lies heal.
taught me that imperfections make the world the perfect place to perfect ourselves.
The Butterfly Effect
taught me that however bad your situation is right now, it always could have been worse had you tried to do it differently in the past.

taught me that if loving someone is wrong, you better make sure you’d still be alright when you lose it.

taught me that nobody cares about how good you are, only what they feel.
taught me that even if you can control the world, but you can never control how the world will respond to you.
Pay It Forward
taught me that you can never change, much less fix, anyone. But you can make the world a better place for people to blame others.

Life is Beautiful (La Vita è bella)
taught me that you can choose to be a special person whenever you want, but you should not expect others to respect the choice you made.

The Secret
taught me that atheists now has a better way of saying that they’re atheists.
Trivia: If David Heinemeier Hansson were to direct a movie, it would have taught me that 20% of the world’s goodness accounts for 80% of evil.

Credits: Thanks to magenSaa yang suka nonton & ditonton 😉


Emosi merupakan sifat bawaan manusia. James Gwee, motivator bisnis ternama dari Singapura, mengatakan:

Customer yang sedang emosi tidak akan bisa menerima penyelesaian masalah.

Singkatnya, dalam keadaan emosi manusia tidak bisa berpikir dengan jernih. Hal ini terjadi baik pada laki-laki dan terutama perempuan.

Teman-teman saya sering tidak percaya bahwa saya berusaha untuk bersikap berbalik dengan mood saya saat itu. Saya sendiri dalam menilai orang, berusaha memperhatikan mood orang tersebut, dan bukan hanya sikapnya.

Ada prinsip mendasar dari “keanehan” tersebut.

James Gwee, lagi-lagi pernah mengatakan dalam sebuah seminar bisnisnya:

Apabila Anda melakukan A, Anda akan mendapatkan A. Apabila Anda menginginkan B, Anda harus melakukan B. Tidak bisa Anda menginginkan B tapi tetap melakukan A. Karena antara keinginan Anda dengan usaha Anda tidak sinkron.

Bila seseorang bahagia dan dia tersenyum, itu wajar!
Bila seseorang sedih dan dia cemberut, itu juga wajar!
Bila seseorang kesal dan dia marah-marah, itu sangat wajar!

Dalam sebuah hubungan, juga sama…

Bila di dalam “hati” seseorang ada cinta buat Anda, dan dia selalu memperlakukan Anda dengan spesial, itu biasa!
Bila orang itu membenci Anda dan dia selalu berpikir negatif tentang Anda, itu juga biasa!

Entah kenapa, sebagian orang tidak menyadari perbedaan antara sikap seseorang, dengan pendorong orang tersebut bersikap seperti itu. Pendorong sendiri sering disebut dengan istilah “motivasi.” (disclaimer: ada juga yang mengaitkan motivasi dengan tujuan yang ingin dicapai, tapi bukan itu yang saya maksud di sini, melainkan penyebabnya.)

Kalau mendengar kata “motivasi”, mungkin orang berpikir macam-macam, mulai dari bisnis, MLM, sampai belajar untuk ujian. Namun, yang perlu diperhatikan adalah, motivasi mendorong kita untuk melakukan sesuatu.

Motivasi di sini dalam artian luas, bahkan emosi juga termasuk “motivasi”.

Contoh saja, orang marah-marah, juga karena adanya motivasi atau pendorong. Motivasinya, tentu saja adalah emosi dia yang sedang kesal. Akan sangat aneh rupanya, jika orang sedang kesal tapi dia tertawa terbahak-bahak. Atau jika hatinya sedang bahagia tapi malah marah-marah.

Namun, yang ternyata jarang disadari orang, adalah motivasi menutupi niat sebenarnya dari sikap seseorang.

Analoginya adalah jika Anda menaruh sebuah gerobak di atas bukit yang menurun, maka gerobak tersebut akan berjalan dengan sendirinya tanpa Anda harus berbuat apa-apa. Ini beda dengan gerobak yang berada di tanah datar, atau lebih hebatnya lagi adalah gerobak yang berada di lembah, dan Anda harus berusaha mendorongnya ke atas sambil melawan gravitasi.

Ini alasan mengapa saya berusaha menghargai seseorang lebih karena niatnya daripada sikapnya.

Sekedar ilustrasi, misalnya ada seseorang yang Anda minta dari Kediri ke Surabaya. Dia sampai dalam waktu 3 jam, naik bus. Anda seharusnya puas. Tapi, andai saja, ternyata keadaannya saat dia hendak berangkat tidak seperti itu. Ada hujan badai, sehingga dia basah kuyup. Tidak ada bus yang lewat setelah ditunggu lama. Dan dia kecopetan.

Apakah dia tetap berangkat ke Surabaya?

Bila dia membatalkan niatnya, itu wajar. Karena motivasinya sudah dilemahkan oleh berbagai kesulitan yang dia hadapi. Tanpa motivasi, hanya tertinggal niat. Dan tanpa niat, orang tak akan melakukan apapun.

Namun, mungkin juga dia tetap kukuh menjalankan niatnya. Dia berusaha mengayuh sepeda dari Kediri ke Surabaya. Terlepas dari berhasil tidaknya, dia pantas diberikan penghargaan atas usahanya ini.

Emosi adalah motivator yang sangat besar, namun jarang diberi perhatian.

Apakah Anda akan memberi penghargaan bagi orang yang suka tersenyum?

Bagaimana dengan orang yang hatinya sedang sangat kalut tapi dia berusaha tersenyum untuk Anda? Akankah Anda memberinya penghargaan?

Pernahkah (atau seringkah?) Anda mendengar: “Maklum dong, waktu itu aku kan lagi emosi. Sekarang aku udah gak marah lagi…”

Atau mungkin: “Waktu itu aku kan lagi senang. Sekarang aku lagi marah nih…!!”

Atau mungkin: “Waktu itu aku kan lagi suka ama kamu, tapi sekarang…”

Anda mungkin bisa melihat niat seseorang yang sebenarnya di balik sikap dan motivasinya… Sikap seseorang bisa berubah dalam hitungan detik. Motivasi bisa berubah seiring waktu.

Niat seseorang, sebagaimana pun sulitnya untuk dicari, juga bukanlah suatu hal yang konstan, bisa berubah-ubah, tidak jauh berbeda dengan emosi manusia itu sendiri.

Everybody always starts a mistake at all times. They just don’t know when, they will realize each mistake they started. In the mean time, they’re simply enjoying it… 🙂

Artikel-artikel yang relevan berikut ini juga menarik lho: