Wednesday, 7 December 2016

You don't speak JavaScript

For some reason JavaScript is a language that even top programmers are not willing to learn and understand properly.
Joe Armstrong. The father of the Erlang language. The language that has concurrency in its core. I've just finished reading an article of Mr Armstrong in which he compares JavaScript's concurrency to Erlang's. Now, what can we expect from The Average JavaScript Programmer if this is what I've read?

You write something like this:
    var done  = function(x){ ... do something with x ..};
    var error = function(x){ .... x ...}
    read(Something, {onSuccess:done, onError:error});
    ... more code ...
Code like this melts my brain.

When the program is executing somewhere inside “_more code_”, the read completes, and I'm time warped back in time to the code in _done_, then back to wherever I came from in “_more code_” when _done_ completes. I find this very difficult to understand.
But what happens if an event is triggered in the time interval between removing an event handler and adding a new one.

No Mr Armstrong. That is not how JavaScript callbacks are executed :(

Tuesday, 22 November 2016

"Branches" in git

Sometimes people want to see "branches" in git. They come to you and say Show me please the master branch. What they want to see is the commits that !at the time when they were created! were pointed to by the master reference. And when, for example at the time of master-dev merge, all you have is this:
o  <- master, dev
| \
o  o
Then you are like

But if you consistently apply a small tweak and instead of the usual workflow:
git checkout dev
git merge master
git checkout master
git merge dev
#this is a simplified process;
#there are pulls happening there
#optionally temp merge branches created
#conflicts resolved...
#but those are irrelevant here
You do:
git checkout dev
git merge master
git checkout master
git merge --no-ff dev
Now that small change gives us a graph like this:
o  <- master
| \
|  o  <- dev
| /|
o  |  (<- master^)
|  |
o  |  (<- master^^)
|  o  (<- dev^)

The benefits are: when you use UI tools to visualise the git log, those tools almost certainly keep the master branch in a nice straight line through all these merges. And from the command line you have the option
git log --first-parent master
And there it is: a "master branch"!

Saturday, 10 September 2016

Embrace the platform

Instead of building with tools, and using all of these tools to build our website and we ship all the tools to our users, essentially. What if we would write using the primitives on the web and then what the users get is just a slightly augmented version of that depending what their browser support. So it's like our tools become part of our deploy process, but not part of our development process.

Thursday, 2 June 2016

Clojure code browser in Emacs

A post from ProDevTips blog landed in my feed reader through PlanetClojure's RSS feed describing a custom-developed Clojure function browser in Emacs. I just wanted to post a simpler, built-in solution because I had this in my configuration and I find it a really neat feature. First, here is the end result:
Clojure function browser in Emacs
The package that does the magic is speedbar and sr-speedbar. Speedbar is a built-in feature of Emacs, the sr-speedbar package embeds speedbar in the buffer's frame, because otherwise it opens in a new frame. And to make speedbar work with Clojure you need this in your init file:
(require 'speedbar)
(speedbar-add-supported-extension ".clj")
For me this worked out-of-the-box, but I think it relies on one of the Clojure or programming packages I configured earlier. Here is the list of my packages that I think can be related:
  • cider
  • ac-cider
  • clojure-mode
  • projectile
  • company

Sunday, 15 May 2016

The decline of Programming

MIT has changed their curriculum some years ago: they started using Python instead of Scheme as they did in the legendary 6.001 introductory course, the one that gave us SICP. UC Berkeley did the same and many other universities use Python now in their introductory courses. What's wrong with that? Lisp is a niche language(family), almost nobody uses it today, it was a mistake in the first place to teach it for so long, very academical and useless knowledge. And I disagree. Yes, Lisp is not widely used, to say the least. And yes, Python is one of the most productive languages out there. This is amazing. I don't think such an easy solution would be possible in other programming environments. My problem is not with Python per se. The problem is that Python is completely inadequate to teach programming principles. It is a nice language to use but it is a terrible language to teach any principles. Let's see for example object oriented programming. I am not a big fan of OO, but if there is something worse than OO that's OO implemented badly. And Python's OO is the worst I've ever seen. Actually it fails so badly that, in my opinion, it's a mistake to call it OO in the first place. Or let's talk about parallel programming. It's a fact that one can't ignore parallel programming in the recent and especially the coming years. Yet, Python has no real answer to overcome the limitations of GIL. It is not the topic of an introductory course, but it's basically impossible to teach parallel programming principles using Python.

These are theoretical arguments. It is still a fact that Python is about a million fold more useful language than Scheme. So the question still stands: What's my problem with teaching a so much more practical language instead of a theoretically beautiful but more or less useless language? My problem is the degradation of Programming as an art and intellectual activity to a mere Coding as a conveyor belt job. It's not a new thing, it's happening for quite some time now. More about that in another post. But what makes it really bad now is that the most prominent institutes accepted and have signed up to this trend.