The title suggests a political discussion, however, this is not what I want to discuss here. (However, I had a ‘more political’ discussion planned for a while.) At a recent conference, I realized many people from the Humanities find it difficult to grasp what the DH even really are – because they are so diverse. I was told a colleague had gone to a short DH summer school but still feels like she doesn’t get what the DH really are. Or that she hasn’t learned any ‘real DH’. How does this happen? How can we make it better? Maybe, as a first step, by trying to answer what the DH are in a way which is easy to grasp for someone who isn’t already part of the DH: It is really an umbrella term for a wide range of topics ranging from digital edition to long-term archiving, digitizing facsimile scans of books or running analyses. I don’t promise to unveil
read more What are ‘real’ Digital Humanities and how to get started?
In this new year, I wanted to make an introduction to programming which mentions all the parts which (albeit being quite essential) many of the other tutorials, books and teaching documents tend to leave out. Things like “How do I even start debugging?” or “How to not lose it if my program doesn’t compile or when nothing works anymore?”. I was fortunate to get taught these skills by friends and helpful colleagues but if you’re a remote-only learner and don’t have access to such people – this series is for you. In this first post, I’ll address the problem that you’re in a situation where your program does not work at all. In the case of LaTeX, this means it won’t compile. Other programming languages which are not compiled will just not run. So what do you do in that dire situation? Step 1: Take a deep breath Stay calm. I repeat, stay calm. Take a deep breath. It’s just
read more Learning to program: What to do if the program doesn’t compile
Is learning how to program like learning a foreign language? Well, it’s a definite “yes and no” from me. I think many people oversimplify this. And then they say that their programmer friends think the same way to ‘prove the point’. Mostly I bite back the question of how many ‘real languages’ the programmer friends have learned or even learned to a native-like level. Because I think that there are some quite important differences. Since I just read this brilliant article The Ancient Case Against Programming “Languages” by Patrick J. Burns on Eidolon (Apr 24, 2017), I thought I could contribute some of my thoughts on the topic as well. They stem less from the interest in not losing funding for second language education, but rather from some of my own experiences in “second language programming education” or whatever one might call it – the act of learning programming (in your 20ies at earliest) after having learned multiple natural languages as
read more Is learning how to program like learning a foreign language?
In my first post on didactical reduction, I argued that reduction of learning materials to meaningslessness can be detrimental, that teachers should trust in their students’ ability to learn and rise to a challenge. In this post I want to discuss ways of reducing complexity which actually makes sense. The gist is: reduce unneccessary detail, not difficulty. Build complexity in a carefully chosen progression. Telling the difference between unnecessary detail and challenging complexity In my post on why programming classes fail and learning ‘algorithmic thinking’, a main example was that students starting out programmig don’t need to know about data types. I will stick with this example here because I just think it illustrates my point so well. The skill to learn I discussed in the post really wasn’t the ‘vocabulary’ of your first programming language, but ‘learning programming’ means successfully communicating with a computer and in order to do that, you need to develop the skill of algorithmic thinking. This
read more Didactical Reduction, Part II
In this short little post, I want to share some thoughts on deliberate practice and how it affects coding, learning how to program, etc. I will argue that, in the long run, you can only become a better programmer with some systematic (self-)education, be it from books or academic classes. Tutorials alone, on the other hand, get you actionable quickly but do this at the expense of providing “the bigger picture” which will ultimately harm and slow down your progress. The concept of deliberate practice I have been intrigued by the concept of ‘deliberate practice’ for a few years now. It mostly comes up in the context of the so-called 10.000h rule (popularized by Malcolm Gladwell’s The tipping point – which is full of blatantly false information by the way and has been debunked by Steven Pinker, see Resources). Deliberate practice is needed for expertise and reaching a level of mastery. If you just want the ‘quick fix’, don’t bother
read more Learn programming from a book vs. tutorial? Thoughts on deliberate practice
This seems to be a bold claim. Let me explain… There are two reasons why I think most introductory programming classes fail ant that is a) because they never actually teach prorgramming (i.e. “algorithmic thinking”, not the syntax of one concrete language / “your first language”)) and b) because they bombard students with tons of complicated subjects which are not necessary at the beginning, so nobody remembers or understands them anyway. But they confuse the students and distract them from what they really should learn like how to interact with the machine and basic flow control. Use a visual language (like Scratch for PC or Catrobat for mobile devices) and thank me later. Algorithmic thinking When we want to learn or teach how to program, we first need to define what programming is. Like in a human language, knowing the words and the grammar is not enough – knowing a language means “knowing how to communicate using that language”. For
read more Why most “learn programming” classes, books and attempts fail