new post, some style

Gemfile.lock

@@ -1,7 +1,7 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    activesupport (4.2.8)
+    activesupport (4.2.9)
       i18n (~> 0.7)
       minitest (~> 5.1)
       thread_safe (~> 0.3, >= 0.3.4)
@@ -11,9 +11,10 @@ GEM
     coffee-script (2.4.1)
       coffee-script-source
       execjs
-    coffee-script-source (1.12.2)
+    coffee-script-source (1.11.1)
     colorator (1.1.0)
-    ethon (0.10.1)
+    concurrent-ruby (1.0.5)
+    ethon (0.11.0)
       ffi (>= 1.3.0)
     execjs (2.7.0)
     faraday (0.13.1)
@@ -21,25 +22,25 @@ GEM
     ffi (1.9.18)
     forwardable-extended (2.6.0)
     gemoji (3.0.0)
-    github-pages (157)
+    github-pages (168)
-      activesupport (= 4.2.8)
+      activesupport (= 4.2.9)
       github-pages-health-check (= 1.3.5)
-      jekyll (= 3.5.2)
+      jekyll (= 3.6.2)
-      jekyll-avatar (= 0.4.2)
+      jekyll-avatar (= 0.5.0)
-      jekyll-coffeescript (= 1.0.1)
+      jekyll-coffeescript (= 1.0.2)
       jekyll-default-layout (= 0.1.4)
       jekyll-feed (= 0.9.2)
       jekyll-gist (= 1.4.1)
-      jekyll-github-metadata (= 2.9.1)
+      jekyll-github-metadata (= 2.9.3)
       jekyll-mentions (= 1.2.0)
       jekyll-optional-front-matter (= 0.2.0)
       jekyll-paginate (= 1.1.0)
       jekyll-readme-index (= 0.1.0)
       jekyll-redirect-from (= 0.12.1)
-      jekyll-relative-links (= 0.4.1)
+      jekyll-relative-links (= 0.5.1)
       jekyll-sass-converter (= 1.5.0)
       jekyll-seo-tag (= 2.3.0)
-      jekyll-sitemap (= 1.0.0)
+      jekyll-sitemap (= 1.1.1)
       jekyll-swiss (= 0.4.0)
       jekyll-theme-architect (= 0.1.0)
       jekyll-theme-cayman (= 0.1.0)
@@ -55,13 +56,13 @@ GEM
       jekyll-theme-tactile (= 0.1.0)
       jekyll-theme-time-machine (= 0.1.0)
       jekyll-titles-from-headings (= 0.4.0)
-      jemoji (= 0.8.0)
+      jemoji (= 0.8.1)
-      kramdown (= 1.13.2)
+      kramdown (= 1.14.0)
       liquid (= 4.0.0)
       listen (= 3.0.6)
       mercenary (~> 0.3)
       minima (= 2.1.1)
-      rouge (= 1.11.1)
+      rouge (= 2.2.1)
       terminal-table (~> 1.4)
     github-pages-health-check (1.3.5)
       addressable (~> 2.3)
@@ -69,32 +70,34 @@ GEM
       octokit (~> 4.0)
       public_suffix (~> 2.0)
       typhoeus (~> 0.7)
-    html-pipeline (2.7.0)
+    html-pipeline (2.7.1)
       activesupport (>= 2)
       nokogiri (>= 1.4)
-    i18n (0.8.6)
+    i18n (0.9.1)
-    jekyll (3.5.2)
+      concurrent-ruby (~> 1.0)
+    jekyll (3.6.2)
       addressable (~> 2.4)
       colorator (~> 1.0)
       jekyll-sass-converter (~> 1.0)
       jekyll-watch (~> 1.1)
-      kramdown (~> 1.3)
+      kramdown (~> 1.14)
       liquid (~> 4.0)
       mercenary (~> 0.3.3)
       pathutil (~> 0.9)
-      rouge (~> 1.7)
+      rouge (>= 1.7, < 3)
       safe_yaml (~> 1.0)
-    jekyll-avatar (0.4.2)
+    jekyll-avatar (0.5.0)
       jekyll (~> 3.0)
-    jekyll-coffeescript (1.0.1)
+    jekyll-coffeescript (1.0.2)
       coffee-script (~> 2.2)
+      coffee-script-source (~> 1.11.1)
     jekyll-default-layout (0.1.4)
       jekyll (~> 3.0)
     jekyll-feed (0.9.2)
       jekyll (~> 3.3)
     jekyll-gist (1.4.1)
       octokit (~> 4.2)
-    jekyll-github-metadata (2.9.1)
+    jekyll-github-metadata (2.9.3)
       jekyll (~> 3.1)
       octokit (~> 4.0, != 4.4.0)
     jekyll-mentions (1.2.0)
@@ -108,13 +111,13 @@ GEM
       jekyll (~> 3.0)
     jekyll-redirect-from (0.12.1)
       jekyll (~> 3.3)
-    jekyll-relative-links (0.4.1)
+    jekyll-relative-links (0.5.1)
       jekyll (~> 3.3)
     jekyll-sass-converter (1.5.0)
       sass (~> 3.4)
     jekyll-seo-tag (2.3.0)
       jekyll (~> 3.3)
-    jekyll-sitemap (1.0.0)
+    jekyll-sitemap (1.1.1)
       jekyll (~> 3.3)
     jekyll-swiss (0.4.0)
     jekyll-theme-architect (0.1.0)
@@ -161,36 +164,36 @@ GEM
       jekyll (~> 3.3)
     jekyll-watch (1.5.0)
       listen (~> 3.0, < 3.1)
-    jemoji (0.8.0)
+    jemoji (0.8.1)
-      activesupport (~> 4.0)
+      activesupport (~> 4.0, >= 4.2.9)
       gemoji (~> 3.0)
       html-pipeline (~> 2.2)
       jekyll (>= 3.0)
-    kramdown (1.13.2)
+    kramdown (1.14.0)
     liquid (4.0.0)
     listen (3.0.6)
       rb-fsevent (>= 0.9.3)
       rb-inotify (>= 0.9.7)
     mercenary (0.3.6)
-    mini_portile2 (2.2.0)
+    mini_portile2 (2.3.0)
     minima (2.1.1)
       jekyll (~> 3.3)
     minitest (5.10.3)
     multipart-post (2.0.0)
     net-dns (0.8.0)
-    nokogiri (1.8.0)
+    nokogiri (1.8.1)
-      mini_portile2 (~> 2.2.0)
+      mini_portile2 (~> 2.3.0)
     octokit (4.7.0)
       sawyer (~> 0.8.0, >= 0.5.3)
-    pathutil (0.14.0)
+    pathutil (0.16.0)
       forwardable-extended (~> 2.6)
     public_suffix (2.0.5)
     rb-fsevent (0.10.2)
     rb-inotify (0.9.10)
       ffi (>= 0.5.0, < 2)
-    rouge (1.11.1)
+    rouge (2.2.1)
     safe_yaml (1.0.4)
-    sass (3.5.1)
+    sass (3.5.3)
       sass-listen (~> 4.0.0)
     sass-listen (4.0.0)
       rb-fsevent (~> 0.9, >= 0.9.4)
@@ -203,7 +206,7 @@ GEM
     thread_safe (0.3.6)
     typhoeus (0.8.0)
       ethon (>= 0.8.0)
-    tzinfo (1.2.3)
+    tzinfo (1.2.4)
       thread_safe (~> 0.1)
     unicode-display_width (1.3.0)
 
@@ -214,4 +217,4 @@ DEPENDENCIES
   github-pages
 
 BUNDLED WITH
-   1.15.4
+   1.16.0

_posts/2017-11-11-its-about-self-control.md

@@ -0,0 +1,103 @@
+---
+layout: news
+author: Torsten
+---
+
+Since i currently have no time to do actual work, i've been doing some research.
+
+Reading about other implementations, especially transpiling ones. Opal, ruby to
+javascript, and jruby, ruby to java, or jvm instructions.
+
+## Reconsidering the madness
+
+One needs to keep an open mind off course. "Reinventing" the wheel is not good, they
+say. Off course we don't invent any wheels in IT, we just like the way that sounds,
+but even building a wheel, when you can buy one, is bad enough.
+And off course i have looked at using other peoples code from the beginning.
+
+A special eye went towards the go language this time. Go has a built in assembler, i
+didn't know that. Sure compilers use assembler stages, but the thing about go's
+spin on it is that it is quite close to what i call the risc layer. Ie it is machine
+independent and abstracts many of *real* assemblers quirks away. And also go does
+not expose the full assembler spectrum , so there are ways to write assembler within
+go. All very promising.
+
+Go has closures, also very nice, and what they call escape analysis. Meaning that while
+normally go will use the stack for locals, it has checks for closures and moves
+variables to the heap if need be.
+
+So many goodies. And then there is the runtime and all that code that exists already,
+so the std lib would be a straight pass through, much like mri. On top one of the best
+gc's i've heard about, tooling, lot's of code, interoperability and a community.
+
+The price is off course that one (me) would have to become an expert in go. Not too
+bad, but still. As a preference i naturally tend to ruby, but maybe one can devise
+a way to automate the bridge somewhat. Already found a gem to make extensions in go.
+
+And, while looking, there seems to be one or two ruby in go projects already out there.
+Unfortunately interpreters :-(
+
+## Sort of dealbreaker
+
+Looking deeper into transpiling and using the go runtime i read about the type system.
+It's a good type system i think, and go even provides reflection. So it would be
+nice to use it. This would provide good interoperability with go and use the existing
+facilities.
+
+Just to scrape the alternative: One could use arrays as the basic structure to build
+objects. Much in the same way MRI does. This would mean *not* using the type system,
+but instead building one. Thinking of the wheels ... no, no go.
+
+So a go type for each of what we currently have as Type. Since the current system
+is built around immutable types, this seems a good match. The only glitch is that,
+eg when adding an instance or method to an existing object, the type of that object
+would have to change. A glitch, nothing more, just breaking the one constant static
+languages are built on. But digging deep into the go code, i am relatively
+certain one could deal with that.
+
+Digging deeper i read more about the go interfaces. I really can't see a way to have
+*only* specific (typed) methods or instances. I mean the current type model is about
+types names and the number of slots, not typing every slot, as go. Or for methods,
+the idea is to have a name and a certain amount of arguments, and specific implementations for each type of self. Not a separate implementation for each possible combination of types. This means using go's interfaces for variables and methods.
+
+And here it comes: When using the reflect package to ensure the type safety at runtime,
+go is really slow.
+10+ [times slower](http://blog.burntsushi.net/type-parametric-functions-golang/)
+maybe. I'm guessing it is not really their priority.
+
+Also, from an architecture kind of viewpoint, having all those interfaces doesn't seem
+good. Many small objects, basically one interface object for every object
+in the system, just adds lots of load. Unnecessary, ugly.
+
+## The conclusion
+
+I just read about a go proposal to have int overflow panic. Too good.
+
+But in the end, i've decided to let go go. In some ways it would seem transpiling
+to C would be much easier. Use the array, bake our types, bend those pointers.
+While go is definitely the much better language for working in, for transpiling into
+it seems to put up more hurdles than provide help.
+
+Having considered this, i can understand rubinius's choice of c++ much better.
+The object model fits well. Given just a single slot for dynamic expansion one
+could make that work. One would just have to use the c++ classes as types, not as ruby
+classes. Classes are not types, not when you can modify them!
+
+But at the end it is not even about which code you're writing, how good the fit.
+
+It is about design, about change. To make this work (this meaning compiling a dynamic language to binary), flexibility is the key. It's not done, much is unclear, and one
+must be able to change and change quickly.
+
+Self change, just like in life, is the only real form of control. To maximise that
+i didn't use metasm or llvm, and it is also the reason go will not feature in this
+project. At the risk of never actually getting there, or having no users. Something
+Sinatra sang comes to mind, about doing it a specific way :-)
+
+There is still a lot to be learnt from go though, as much from the language as the
+project. I find it inspiring that they moved from a c to a go compiler in a minor
+version. And that what must be a major language in google has less commits than
+rails. It does give hope.
+
+PPS: Also revisited llvm (too complicated) and crystal (too complicated, bad fit in
+type system) after this. Could still do rust off course, but the more i write, the
+more i  hear the call of simplicity (something that a normal person can still understand)

css/stylesheet.css

@@ -1,5 +1,5 @@
 body {
-	font: 300 15px "Roboto",Arial,sans-serif;
+	font: 300 1rem "Roboto",Arial,sans-serif;
   text-rendering: optimizelegibility;
   margin-top: 50px;
 	/*background: #FCFCFC url(../img/pattern.png) top left repeat;*/
@@ -69,7 +69,6 @@ hr {
     padding: 15px 40px;
     text-shadow: none;
     text-transform: uppercase;
-    font-size: 12px;
 }
 
 .navbar .nav > li > a:hover {
@@ -214,7 +213,7 @@ hr {
 }
 
 .theme p {
-  font-size:15px;
+  font-size: 1.1rem;
   line-height:1.4;
 }