Towards a Statically Typed Universe? Fun with ocaml

When I was younger, i was a zealot of static types. Today, I admit that I have more fun working in dynamically typed languages (namely JavaScript).

Now I'm older, I find that using the right tool for the job is the best way to ensure professional happiness. The type system is just a tool to be utilized to gain either a sense of correctness or performance.

While in my heart, JavaScript wins these days for my hobby coding, I'm diving into OCaml for fun.

It seems to me that statically typed languages are converging (or, trying to converge) in terms of happiness towards dynamically typed languages. It is as if the promoters of statically typed languages are actively working towards "programmer happiness". Well, with languages like Ruby and JavaScript, there is a massive debt to be paid.

Paying off a bit of the debt

I remember when compile time was a big black mark on statically typed languages. Back in the day, when CPU power was limited, this was a talking point against compiled languages since compiling was a major interruption to the flow of work. Now, the issue seems to be a matter of productivity. For instance, working in C# with KayakHTTP is a huge PITA. I have to close the running server, compile, start it back up again, switch to my browser, and finally I need to hit refresh. This takes too freaking long.

Well, I discovered an awesome *nix tool that really helps in streamlining the process for my new (unannounced) project.

inotify-tools

I recommend checking it out (in your flavor of *nix).

For me (your mileage may vary), this enables me to work with node.js and ocaml very efficiently. I can treat server side development the same as I do web based development. That is, i save my file and refresh my browser. Now, I just need a Firefox plug in to listen for refresh events on some socket (or other mechanism).

How?

Here is how I use it for developing new project. The general pattern is

• wait for file changes
• kill
• compile
• launch

I hope you find this technique useful because it makes my life better.

An Asynchronous Life for the Happy Hacker

I used to use notepad + a little bit of discipline to organize the non-hacking things in my life. Now, i have the EpicWin app; its... EPIC.

poll() loop
Unfortunately (or fortunately depending on your point of view), EpicWin doesn't interrupt my day. This can be a problem when the flow has set in and morning turns to night; my love comes home to find out that well... I didn't do anything for her and now I have to deal with wife-aggro-damage-control. Using the alarm clock, I set three interrupts for 9:30am, 1:30pm, and 8:00pm. I use these interrupts to go get things done related to my life.

This really helps in finding balance between the awesome work I do and dealing with the mundane aspects of life. So, I thought I would share my quest list with the world.

Every Day Tasks

• 75 pushups (+200 str)
• 100 bicep curls (+150 stamina)
• 100 crunches (+150 stamina)
• Drink 32 ounces water [9am] (+100 spirit)
• Drink 32 ounces water [2pm] (+100 spirit)
• Take Afternoon Calcium +D [2pm] (+100 spirit)
• Drink 32 ounces water [10pm] (+100 spirit)
• Deal with Dishes (+200 stamina)
• Take Evening ZMA [11pm] (+100 spirit)
• Read Twitter [9am] (+50 social)
• Read Twitter [2pm] (+50 social)
• Read Twitter [10pm] (+50 social)

Every Sunday

• Cook Level 3 Dinner (+300 social)
• Read Current Book (+300 int)

Every Monday

• Get groceries at HyVee (+100 stamina)
• Cook Level 1 Dinner (+150 social)

Every Tuesday

• Walk 6-12 miles (+300 stamina)

Every Wednesday

• Get groceries at Whole Foods (+100 stamina)
• Cook Level 2 Dinner (+100 social)
• Watch The Colony (+100 social)
• Go Drink'in at Buffalo Wild Wings with friends (+100 social)
  

Every Thursday

• Prepare Level 0 Dinner (+100 social)
  
• Walk 5 miles (+300 stamina)
• Catch up on HN and comment as appropriately (+100 int)

Every Friday

• Cook Level 2 Dinner (+100 social)
  
• Take out Trash (+100 str)
• Write blog post (+300 int)
• Play Settlers of Catan/Mario Kart with friends (+300 social)

Every Saturday

• Solve one PhD problem (+300 int)
• Walk 3-6 miles (+300 stamina)
  
• Publish and post edited blog post (+300 int)
• Grind on Bills and Validate Financial Integrity (+200 int)
• Hang out with Family 2.0 (+200 social)
• Clean Kitchen (+100 stamina)
• Fill vitamins for next week (+150 spirit)
  

aside) 3 segment work day
I'm one of those people that can hack all day. Sit in front of a computer and enter the flow. This is great for research, hacking, making things work, and getting things done. Problematically, I have to interact with the world beyond my the limits of my skull, and my mind is supported by a problematic human body that is frail and needs to get out into the light. Ergo, I have to control the flow before it destroys me.

While I wish I could hack all day and all night, I limit myself to a maximum of 12 hours a day for work/hacking. While 12 hours is way more than needed, I break it up into 3 segments. I think anywhere between 2-4 hours is enough to get any serious task done (or series of tasks within one context). Once the flow ends, I switch to a different context. I call this the "Hardy Hack" since GH. Hardy wrote in his apology that 4 hours is the limit of time to get any serious math done; I extend this with the caveat that 4 hours is the time limit per context. If you finish the task in less than 4 hours, then goof off and have fun. The hard part is finding the discipline to make sure you are honest in how you plan your day out.

Tips for Asynchronous Behavior

• Learn to think critically while exercising.
• Channel all interruptions (i.e. cell phone or email) to occur during mundane tasks.
• Have you significant other go through your twitter while you do the dishes.
• Learn to negotiate with the your significant other to shard tasks.
• Group as many mundane tasks together and get them done with (i.e. use proper cpu scheduling)

Redemption of a Cowboy Coder

Often, cowboy coding is looked down upon as a form of egotistical manic programmer that doesn't work well in the team environment. This can be very true, but it is an over simplistic view that is depressing for smart people who tend to cowboy up more often than not.

For a cowboy coder, the right thing to do is to do a start-up and then cowboy up so hard core that the product is awesome. Get the product into the market. Get it sellable. If it sells (which is way harder than making the product), then jobs have been created to support the product since the cowboy coder probably made a lot of mistakes that need human intervention.

I have a theory that this is one reason that most commercial software kinda sucks, but it is also why the job market for coders will always be strong.

Four signs of an awesome coder (or person)

1) Studies the craft

When I talk to a person, and I find out that they read @codinghorror or some other technology blog, then I know "hey, this person is trying to catch up". If they have read both dragon books, then I know "this person is super cool and super awesome". I believe that core to being awesome is to be in a state where you know there is always more to learn and actively work towards knowing more than you did yesterday.

2) Codes for fun

What you do in your spare time says orders more about you than what is on your resume. If you wrote a super awesome CMS that enables you to publish your own content in a way you think is awesome, then you are awesome.

It doesn’t really matter what you write in your spare time because we all do what we do to make our lives better. I knew a guy in college (in the math department) writing his own parser generator language. Why? Because he was awesome, that’s why.

Also, you should never need to justify you work unless someone is paying you to do something else. Your work is what will make you awesome. I wrote a computer algebra system in graduate school, and many people asked me “why don’t you just use mathematica”. Any answer besides "Because I’m awesome." is wrong and disingenuous (of course, you should try to keep the ego in check)

3) Has a metric of quality

The most awesome coders have a sense of beauty in some form of metric that gives them a direction. This is the source of most (if not all) of the flame wars in the field since people have to work together yet have to do so with different (and often incompatible) metrics. Your metric may be performance, brevity, organizational, extensibility, obfuscated, or any other innumerable metrics that we judge code by.

As long as you have a metric, then you are awesome. You should grab a sword and shield and head toward reddit to do battle. Myself, I used to battle in the realm of type systems. These days, I'm going to champion NoSQL and kick some RDBMS ass.

3.5) Get shits done

Thanks to a comment in HN. Having just a metric implies being a critic. One also needs the process/fortitude to hone the craft to be an artisan. Or, as the commenter put it: "gets shit done".

4) Has an open mind

An open mind enables objectivity and the ability to change your mind. If you can change your mind and try something new, then you can advance your knowledge and learn something new rather than keep stale knowledge alive. Learning something new is always the best way to expand your skill-set and maximize your metric.

The more open you mind is, the more science you can do, and the more awesome you can be.

Advice) Toward a better future

Now, having pointed out the signs, I can give you my awesomeness advice. Read at least one to two books every year and follow at least one technology blog/aggregator. Start a new open source project that you think will be awesome, or join another project that you think is going to be awesome. Ask yourself, what is beauty? Is it fast code? Is it brevity? Is it clarity? Once you know thyself, then you can start to measure and hone your craft. When you find yourself faced with a change, think about it. Do you have more to gain or lose? How can you experiment with the change? How can you measure the effects? How can you isolate the change? How can you bound your fear? How can you reap the reward?

Dangers) Life

If you want to be awesome, then you have to learn to deal with one very difficult part of human life. Disappointment in others, your environment, the world, the government, and yourself. Becoming awesome is hard work, and many can't get there because life is non-linear and from our perspective non-deterministic. Along the way, you may realize that you can't reach the level of awesome that you dream about due to any number of reasons (not enough something, shit happens like a bus, or you changed your mind).

Let go of negativity. Learn to adapt. Being awesome is being able to get up and adapt to something else. My personal hero in life is Bruce Lee with this awesome quote to his credit.

"Empty your mind, be formless, shapeless - like water. Now you put water into a cup, it becomes the cup, you put water into a bottle, it becomes the bottle, you put it in a teapot, it becomes the teapot. Now water can flow or it can crash. Be water, my friend." - Bruce Lee

The ultimate way to be awesome as a coder is to be water, my friend. This advice probably extends to anyone, so go forth and be awesome. Or, at least try.

Why Open Source/Free Software Rocks!

For most of my formative years, I was primarily interested in building stuff as a personal hobby. Back then, when I first learned about Open Source, I was skeptical for one primary reason: financial (I need money ergo I need a job/gig). This reason is no longer a concern due to the brave souls that made open source software lucrative for businesses to build on.

The world we live in is not an absolutely rational world as there are no universal metrics of quality. This is where irrationality and human psychology comes in kicking over my objectivist dreams of being Hank Rearden and building the most awesome ... thing .. ever.

We humans are interesting creatures.

Why does having code rock?

I believe that having access to code, being able to extend other's ideas, and being able to combine code accelerates the art of computing through a form of evolution.

I used to have the idea that having access to code stinted the progress of innovation, but I didn't know the jargon/idea to effectively communicate it. Now I know that it is called Anchoring. By itself, anchoring is extremely bad for innovation. It forces us to use old technology to solve new problems. While this isn't bad for business as usual, it makes it harder to be disruptive and solve new problems.

Fortunately, there is a stronger force called Not Invented Here (NIH). Usually, NIH is referenced in the negative. However, if you are aiming to provide a new service or enable people to kick ass, then you need to execute and make it happen rather than being anchored to existing technology just because it worked for your old problems.

These forces combine and enable new inventions to mature to the point where the next step can be visible to someone in the community. The next step may be a small contribution, be a complete rewrite, or something entirely new and unexpected. It doesn't matter, it just speeds up our collective awesomeness.

I'm glad to have finally caught on... I wonder if I am in the early minority or the late majority.

NoSQL and You, what is the daily deal for databases

To promoters of the relational world, I wish to speak to you as a concerned human being. Your days are numbered just like the days were numbered for COBOL developers. I wager I'm in the middle group between innovators and early majority, and I'm working towards figuring out what NoSQL solutions mean for businesses that rely on persistance.

This isn't a rant about scalability.

Scalability is just one facet that the NoSQL movement aims to provide, and it is the big facet that will get important players involved to fund the polish that makes NoSQL solutions awesome. Scalability isn't the biggest argument that promotes NoSQL solutions. The biggest and best argument is flexibility and how we can design software around NoSQL and solve problems quickly.

Flexibility always Wins

Unless your art (or job) demands you work in assembly, then you don't work in assembly. The struggle to produce high level languages has yielded a multitude of languages that are in-arguably superior to older languages for many domains. The quest for a better way to express how we compute continues on. and on. and on. and on.

The NoSQL movement is no different, and it is core to our quest for a better way to represent and share data. We seek better ways to store data. We seek better ways to share and transact data with other processes over a network. We want need our queries to be fast, optimal, and beautiful.

I believe the current generation of NoSQL solutions provide a platform for making our lives better, our work more productive, and enable us the flexibility to refine our services.

Momentum

Due to the companies that sponsor the work behind NoSQL solutions because they have scalability problems, we have enough momentum and interest to overcome the technical debt that causes typical databases to remain entrenched in small and medium sized sectors. NoSQL solutions are untested in many sectors and domains, but the current generation of start-ups are going to test them and polish them to make them work for a larger class of problems. Due to the open source nature of the multitude of NoSQL solutions, the knowledge to solve problems and the tools will be available either for free or offered by a vendor. This is great!

What is wrong with a Database?

Nothing! But, there is nothing wrong with assembly either. Sure, you can build any NoSQL solution offering with a Database. But then you are building on top of a crappy NoSQL offering. What matters in NoSQL isn't where or how you store data, but how you design and build services. Being competitive in this day and age means being flexible to adapt and iterate. How does one enable flexibility with NoSQL? How does one execute and deliver change to make services better? These are open questions that the programming community is facing now, and we will be answering them soon.

The Complement Set

The relational theory set forth back in the 70s is an amazing mathematical model. However, it is just one model. Is it complete? What is the set of all solutions that span the offering of a database package? Is it everything? No. The problem that set me on the path towards NoSQL solutions is that of graph traversals. Relational databases are horrible at graphs. It is no surprise that due to the rise of social networks, the interest in graph based databases has gone up as well. While this is a single problem, it is sufficient to demonstrate that relational databases are not the everything panacea that some claim it to be.

Better Database Education?

"Just learn everything your database offers!" While this is an argument that I would have given years ago, it is not an appropriate response for entrepreneurial computer science (the name of my future book). It is far more important to create a product that generates revenue, so if I run into a business problem that depends on code then I need to solve it quickly to test viability and get market feedback.

Using a database may be the wrong way to persist data, which means that what you initially learned about databases is probably bunk. Most medium sized problems can be solved by using insane amounts of memory as an intermediate cache to some Key Value Pair System (for backups and failure persistence). If I go back in time, I would unlearn what I know about databases and just make a product like I was doing when I was 16. All the knowledge of how seek time affects hard drive performance, network latency, and all the other tier data bottlenecks is bullshit (given that in today's world I can get commodity servers with insane memory). I can use that memory to solve problems at both the small and medium scale to get revenue, and that revenue will fund the larger scale version which may be easier to build due to the choice of NoSQL designs in the beginning.

I believe NoSQL techniques are the path from transient memory to a persisted disk, and I feel that designing and learning how to make NoSQL work will be more valuable than knowing how to configure and consume a database package.

In the End

What matters most is providing a service to the world.

If you argue that a relational database is good enough, then it is good enough... for you. If that is the case, then don't tell me what is good enough because you don't know the crazy shit I'm working on that could change the world for the better!

Journey back to OCaml; a land forgotten by marketing

Some years ago (3?), I used to regularly hack in OCaml. I'm picking it up again as my hobby/research language since it resonates with how I think (and more importantly how I think about the universe from a static typing/academic/math perspective/performance perspective).

Picking up OCaml is like riding a bike after three years in a hospital, and it is awesome; it just makes me happy to use.

Since I've been dealing with web stuff mostly, I wanted a platform that makes my life in OCaml well.... pleasant. I also want to build distributed systems with OCaml where machines can work together holding hands and drinking each other's koolaid. So, I'm building that platform first. It is called node.ocaml and can be found on github.

My hope is that my platform performs well and enables me to experiment and build some interesting services.

I choose OCaml because it's interesting, and because it is not marketable. It makes the boundary between my work coding and hobby coding very crisp.