start on a log (since i have no b, to make it a blog)

principles.md

@@ -0,0 +1,39 @@
+Good Principles
+---------------
+
+Good principles, or rules of thumb, are not so easy to formulate. They come from experience and abstract it.
+If they don't come from, or not enough, experience they easily become just abstract and who really can tell
+ the difference (only one with more experience off course, and he/she does not need to read about principles). 
+A conundrum.
+
+- Microkernel
+  Or "leave it out if you can", is definately something i go by. A variation of make it as simple as you can,
+  but not more simple.
+  
+- Walk the straight line
+  Or "No futureproof" means not to design before you code. Not to anticipate, only to do the job that
+  needs doing. Better design should be extracted from working code.
+  
+- tdd extreme
+  Having suffered from broken software (small feature add breaks whole software) so many times, the new tdd
+  wind is not just nice, it is essential. Software size is measured in tests passed, not lines written. Any
+  new feature is only accepted with enough tests, bugs fixed after a failed test is written.
+
+- Layers represent an interface, not an implementation
+  It is said that every problem in computing can be solved by adding anohter layer of indirection. And so 
+  we have many layers, which, when done right, help us to understand the system. (Read, layers are for us,
+  not the computer)
+  But implementing each layer comes with added cost, often unneccessary. Layers can and should be collapsed
+  in the implementation. Inlining, is a good example, a Jit another.
+  
+- Use names rightly
+  or the principle of least surprise. Programming is so much naming, so if done right will lead to a 
+  natural understanding, even of code not read. 
+  Good names are Formatter or compile, but unfortunately not everything we have learnt is named well, like
+  Array (should be ordered list), Hash (names implementation not function) or string (should be word, or bytebuffer).
+
+- No sahara
+  There has been much misunderstood talk about drying things up. Dry is good, but was never meant for code, but
+  for information (configuration). Trying to dry code leads to overly small functions, calling chains that
+  are difficult to understand and serve only a misundertood slogan.
+

progress.md

@@ -0,0 +1,24 @@
+Some steps along the way
+-------------------------
+
+Since i forget easily i will write down some milesstones. Project start was around 10.4.2014
+
+First Assmbly 
+-------------
+
+With the help of Mikko, there was start for assembler. Threw the parser, wrote lots of tests. First "hello" executable, written in dsl assembler, after 2 weeks.
+
+First Parses
+------------
+
+With Kaspers great parsing library (parslet) was able to get up to speed relatively quickly. Thought it was impossible, but it's only very tricky. Lots of tests at first, then came a good "harness" for the stages. 
+Parsing simple types, if and while, function definition and call, 2 weeks.
+
+First Executables
+-----------------
+
+Going from the parsed ast to assembly was tricky, unknown territory. Uncertainty about right abstractions (eg, Values vs Variables) together with debugging by reading assembler, which i just learn 4 weeks ago, made it tricky.
+Still, first executables after 2 weeks, hello, fibo, if,while and recursion after 3 weeks.
+
+
+