This is a description of a fictitious programming language. It is purposefully vague here and there. Nevertheless, I don’t think I’m exactly reaching for the moon here. Or perhaps I am, you tell me. Point is, this is just fantastic, wholesome, and thoroughly enjoyable academic masturbation. Shall we begin?
We need a name for the language, so let’s call it Shark.
Shark uses a purely copy-on-write data model. By this I mean that, as far as the programmer can tell, values are never modified. Once you create an integer, a string, a list, or a forest of suffix trees containing all the words in the Klingon language, you cannot modify it.
Shark is, of course, garbage collected. Shark is also strongly typed, supports both static and dynamic typing, and has type inference. You have your lambdas, partial evaluation, algebraic data types, pattern matching, a fantastic module system, and a clean and concise but not too unfamiliar syntax. As far non-existent programming languages go, Shark is the dog’s bollocks.
Shark has lightweight threads. Spawning new threads is almost free (only a handful of instructions on the CPU). Threads are automatically distributed to your CPUs and cores. Just to be absolutely crystal clear, Shark threads are not the same as operating system threads such as POSIX threads. Shark threads communicate exclusively through message passing. Each thread has a message queue from which it can read incoming messages when it wants to.
There are no locks, condition variables, and no modifiable shared resources. When threads share data they do it explicitly, in a controlled fashion, for selected data only. Shark comes with built-in support for software transactional memory. You can easily build databases from whatever data structures are the most natural for your application. You can kiss all that RDBMS crap goodbye. No more shoehorning your data into an awkward tables-and-columns format, no more marshalling and demarshalling your data to whatever data types the database happens to support, and no more SQL.
The natural model to maintain state in Shark programs is to have a single thread govern the evolution of that state. The thread can then pass around copies of the state, maybe receive operations from other threads to update the state, and so on. Typically the state takes the form of an STM database which can be updated transactionally from multiple threads concurrently.
Just one more thing. Shark STM databases can optionally be stored on disk. It’s so efficient that you can run tens of thousands of transactions per second and have them checkpointed to disk a dozen times per second. This gets you the Durability in ACID, the one piece that regular STM normally doesn’t provide. Even though the entire database must reside in main memory, you’ll need to have a pretty big database for that to become a problem. RAM is insanely cheap nowadays.
So, that’s my hallucinogen-induced (not really) vision of the perfect solution for concurrent programming and database management. Yeah, I know creating your own programming language is basically never the right thing to do. In my defense, at least I haven’t implement Shark. Not yet, at least…
- I Have Seen the Future, and It is Copy-On-Write
- Copy-On-Write 101 – Part 2: Putting It to Use
- Copy-On-Write 101 – Part 1: What Is It?
- The Three Doors of Type Systems
- Programming Problems in Disguise