This is an awesome talk that compares software to music and explores why 400+-year-old music can still be played … in different keys … on a variety of instruments … etc.
Tag: Programming
JavaScript History as Seen From 2035
Gary Bernhardt presents a thought-provoking history of JavaScript as seen from 2035.
His arguments are that
- With asm.js JavaScript VMs ran code with 50% of native speed (even in 2013)
- Anything that can be compiled can be compiled into asm.js
- Asm.js has basically become the universal runtime
So by further moving the JavaScript VM into the kernel we save ourselves the overhead of hardware process isolation as the VM does this any way.
All this lead to interesting consequences
- Nobody uses binaries any more, everything is asm.js
- The windowing systems of old have been ported to the DOM
- Deployments are as simple as a push
- JavaScript (as a language) is effectively dead
- Overall developer happiness has increased
:’D
Ruby Monsters
Very entertaining talk about some of Ruby‘s quirks. 😀
Programming is Meaningless
Researchers seemingly have found a way to tell-apart students which will do well in computer science classes and those who won’t. More eloquently put they’ve devised a way “[to] separate programming sheep from non-programming goats.” 😀
And they come to an interesting conclusion:
Formal logical proofs, and therefore programs – formal logical proofs that particular computations are possible, expressed in a formal system called a programming language – are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion. In the test the consistent group showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group, on the other hand, looks for meaning where it is not. The blank group knows that it is looking at meaninglessness, and refuses to deal with it.
— Saeed Dehnadi and Richard Bornat, 2006, “The camel has two humps (working title)”
I have accepted it. -.-
Monitor Activity in your OS X Dock
Just found a nice trick on TUAW on how to make the OS X Activity Monitor show graphs in place of its app icon.
Poetic APIs
During PyCon 2014 Erik Rose gave a very insightful talk about dos and don’ts of designing APIs. Towards the end he “gets meta” and groups all his points into categories drawing connections how different design goals influence each other. You see two main groups–”lingual” and “mathematical”–and he closes with this gem: 😀
This spotlights something that programming languages have over ordinary human languages. Programs are alive! They not only mean things when people read them, but they actually do things when run. So, very literally a program with carefully chosen symbols is poetry in motion.
— Erik Rose (PyCon 2014)
https://youtu.be/JQYnFyG7A8c
ArsTechnica on first-world-problems … ehm, Soylent
ArsTechnica has probably the best piece I’ve read covering the meta-problem with Soylent.
Nobody will live off of Soylent for extended periods of time. And even if there were people like that they would be considered at least as weird or crazy as maybe vegans or people with similarly “limited” diets.
Soylent won’t destroy anything in our food culture that hasn’t been already destroyed. Why would anyone care if you drank Soylent instead of eating your drive-through fast-food alone. Chugging down a glass of Soylent instead of munching a chocolate bar between meetings. The cultural aspect of eating together is moot in those cases. At least Soylent would provide a “nutritiously balanced” choice here.
Yes, people must eat, but people don’t *need* to cook (themselves). And honestly many people don’t. I can’t really see the difference between eating out, just heating things up in a microwave or oven or drinking Soylent for that matter. The cultural aspect of preparing food is lost in those cases anyway. This may be partly because of the next aspect.
Cooking is not as easy as it may sound. It requires following “discrete series of steps guided by a mix of instruction, experience, and intuition” “surrounded with a complex support scaffolding” (I really advise you to read the 2nd page of that article). It is as easy and as necessary for a fairly normal everyday life as is compiling software. (I still believe that cooking is the analog equivalent of programming). I second the argument that as easy and essential it may look to some, it looks equally impenetrable and “magic” to others.
One interesting aspect I’ve not thought of previously was that Soylent may be a way to relieve people with eating disorders of guilt and anxiety when eating the “wrong food”. Since “for people struggling with food-related issues, it can be like a damaging drug that you can never quite quit cold turkey” it may provide an unambiguous food choice that is “satiating without being delicious.” It makes preparing and consuming food quantifiable which was the problem for the last two groups of people in the first place.
I don’t really care if it’s Soylent or something else. If find the possibilities intriguing. It’ll get a lot more interesting once anyone cared to study the long-term effects of consuming Soylent. But I’ll definitely try some once it gets available in Germany. 😉
MagicDict
If you write software in Python you come to a point where you are testing a piece of code that expects a more or less elaborate dictionary as an argument to a function. As a good software developer we want that code properly tested but we want to use minimal fixtures to accomplish that.
So, I was looking for something that behaves like a dictionary, that you can give explicit return values for specific keys and that will give you some sort of a “default” return value when you try to access an “unknown” item (I don’t care what as long as there is no Exception raised (e.g.
KeyError
)).
My first thought was “why not use MagicMock?” … it’s a useful tool in so many situations.
from mock import MagicMock m = MagicMock(foo="bar")
But using MagicMock where dict is expected yields unexpected results.
>>> # this works as expected >>> m.foo 'bar' >>> # but this doesn't do what you'd expect >>> m["foo"] <MagicMock name='mock.__getitem__()' id='4396280016'>
First of all attribute and item access are treated differently. You setup MagicMock using key word arguments (i.e. “dict syntax”), but have to use attributes (i.e. “object syntax”) to access them.
Then I thought to yourself “why not mess with the magic methods?”
__getitem__
and
__getattr__
expect the same arguments anyway. So this should work:
m = MagicMock(foo="bar") m.__getitem__.side_effect = m.__getattr__
Well? …
>>> m.foo 'bar' >>> m["foo"] <MagicMock name='mock.foo' id='4554363920'>
… No!
By this time I thought “I can’t be the first to need this” and started searching in the docs and sure enough they provide an example for this case.
d = dict(foo="bar") m = MagicMock() m.__getitem__.side_effect = d.__getitem__
Does it work? …
>>> m["foo"]
'bar'
>>> m["bar"]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File ".../env/lib/python2.7/site-packages/mock.py", line 955, in __call__
return _mock_self._mock_call(*args, **kwargs)
File ".../env/lib/python2.7/site-packages/mock.py", line 1018, in _mock_call
ret_val = effect(*args, **kwargs)
KeyError: 'bar'
Well, yes and no. It works as long as you only access those items that you have defined to be in the dictionary. If you try to access any “unknown” item you get a
KeyError
.
After trying out different things the simplest answer to accomplish what I set out to do seems to be sub-classing defaultdict.
from collections import defaultdict class MagicDict(defaultdict): def __missing__(self, key): result = self[key] = MagicDict() return result
And? …
>>> m["foo"]
'bar'
>>> m["bar"]
defaultdict(None, {})
>>> m.foo
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'MagicDict' object has no attribute 'foo'
Indeed, it is. 😀
Well, not quite. There are still a few comfort features missing (e.g. a proper
__repr__
). The whole, improved and tested code can be found in this Gist:
The Last Thing D Needs
Scott Meyers’ hilarious talk about C++ idiosyncrasies. 😀
Why Programming is Difficult
There are three other things that make programming difficult:
- Fixing things that should not be broken
- No time for learning things
- Bad environment for programming
Let’s look at these things – these are all “time thieves”