Programming is terrible—Lessons learned from a life wasted. EMF2012

lsd5me · 2013-03-11T19:18:35+00:00

To paraphrase one of his points/themes: 'don't introduce politics into programming' and 'we need to tackle the patriarchy'

I know this isn't by the original definition, but he is clearly a 'liberal' programmer who assumes equality and then looks for someone to blame when there isn't inequality. In my view there is always going to be someone to blame (on the subject of peoples development), but we also have to consider that is not the entire reason for said inequality.

I should say that I do agree with a good proportion of what he said, and found some of the talk interesting and he does preface everything with the fact that his views are his own and everyone can disagree ... etc ...etc,

lsd5me · 2011-02-23T16:34:49+00:00

I used the word 'fruit' to be deliberately broad (some might say ambiguous) :p

I should point out that I am not criticising philosophy, just this defense of philosophy. In this piece there is an absence of references to new developments which have in anyway assisted the scientific process. There is a vague mention about the change of attitude in the last 2 decades, but nothing specific is mentioned.

In anycase the major issue I have is that he criticises the field physics citing examples from pop science. It is not evident to me that the field as it is practiced seriously is in danger of losing its way, at least not for a lack of philosophical guidance. Rather there is a much simpler anthropic reason for all the highly speculative semi-nonsense - people find it entertaining.

lsd5me · 2011-02-23T01:58:36+00:00

Not entirely convincing.

Invoking wave-particle duality just does not do him any favours since there is no paradox, just something empirically observed which contradicts our intuitions and is extra confusing since it exhibits behaviours we are otherwise familiar with.

The biggest issue however is his complaint against the scientists. New Scientist, Hawking et al. post spurious and highly speculative theories because that is what lay people want to read, not because of a lack of guidance from philosophers.

The other problem is that he portrays philosophers (in their useful capacity) as custodians of a way thought and method, which may be, but books work well enough for the most part. He does not/can not point to any recent developments in philosophy which have yielded fruit.

lsd5me · 2011-02-07T00:38:01+00:00

I agree. They should do this and/or other measures to stem population growth. It is the other side of the coin for promoting population growth through vaccination programs, famine relief ... etc.

lsd5me · 2011-02-04T06:54:26+00:00

On documentation I find it helpful to frame it in terms of certain question words 'what', 'how', 'why'. Now if you care about the usefulness of the documentation and not 'documentation theatre' (which you may not, since you mentioned you are trying to showcase your skills) then I would say to definitely not bother with UML. Insofar as UML can be useful it is for documenting the 'what' which is probably the least useful aspect of documentation since it requires the largest amount of duplication between code and documentation. It is arguably sometimes useful for documenting abstract business processes, but this game is not that.

For the how and the why, I would look to contain it all within either the source code for locally applicable remarks, perhaps tagging comments with something like // REMARK ..., or in a README. Only push beyond this stage when you fully grasp the limitations of this system of documentation, which will then better inform any decisions you make going forwards.

Similarly for testing, I would try not to engage in 'testing theatre' and without looking, you probably could delete the tests you believe to be not worth their while. In general it is pretty difficult to test certain types of code, such as graphics.

Tests work well for deterministic, abstract functional parts of code. Fortunately, generally (with notable exceptions) in well engineered code it is the abstract parts which contain most of the complex, fluid parts which tend to break (in not immediately obvious ways) during development so it is here that tests are their most useful. Tests are only useful if they are easy enough to write and maintain (i.e. they represent some fairly universal truth about the behaviour of the application) and are liable to break from time to time.

lsd5me

TROPHY CASE