I’m a notorious parallel reader, jumping between books all the time.
Here I give a couple opinions on the books currently in my pipeline:
- Deep Learning, Ian Goodfellow and Yoshua Bengio and Aaron Courville
- Fluent Python, Luciano Ramalho
- Seven Languages in Seven Weeks, Bruce Tate
- Clojure for the Brave and True, Daniel Higginbotham
- A Tour of C++, Bjarne Stroustrup
- The Rust Programming Language, Steve Klabnik and Carol Nichols
- (Hyperion, Dan Simmons)
I’ve recently answered a question on the German Quora (https://de.quora.com/Warum-sollte-man-in-Java-lieber-auf-die-Rekursion-verzichten/answer/Markus-Toman) that stated: “Why should you refrain from recursion in Java?”.
I think we should avoid recursion by default, except if:
- you are working in a language where recursion is essential and highly-optimized (Haskell, LISP dialects, Erlang/elixir and most other functional languages)
- the recursive version is much easier to maintain and understand AND does not negatively affect performance to an unreasonable degree
- the recursive algorithm is easier parallelizable (typically because of immutability)
In this post we discuss this topic, starting with high-level Python, going over to C++ and finally ending up in assembly.
Disclaimer: this is an opinionated article, flowing directly from brain to keyboard without lots of references and explanations. I know much of its content is debatable and it just reflects my current opinions and mindset, likely to change without notice.
Recently I watched the Design Patterns Coursera course (https://www.coursera.org/learn/design-patterns) and noticed that it’s full of Gang of Four (GoF) design patterns. If you are a programmer reading about programming online, you’ll find that discussions and material on GoF has been very sparse in the recent years, especially with the uprising functional programming hype (if we can call it a hype).
I wondered about this and a bit of investigation led me to (mostly) the following opinions:
- GoF patterns are now common knowledge and therefore nobody talks about it anymore, just like nobody talks about using functions or control structures anymore.
- They were a fail, born in the object-oriented-Java-mindset, made software even more complex and went overboard with useless abstractions.
- They were there to help with programming language shortcomings which are less and less of in issue now, especially with functional features entering existing languages.
So, was OOP a fail? Will functional programming save us? Are strapped-on design patterns useless and replaced by simpler language features? How did we get to the current situation, where will we and up?
(Dear international readers, this content appeared first in the German “IT Freelancer Magazin” and is unfortunately only available in German)
Es war Anfang 2012 als ich mich für ein Doktorat im Bereich Sprachsynthese bewarb. Ehrlich gesagt konnte ich mir damals nicht viel darunter vorstellen, aber die Ausschreibung beinhaltete Machine Learning und Künstliche Intelligenz. Und es klang irgendwie… anders. Heute – über 5 Jahre später – habe ich einen ganz guten Überblick über das Thema, stoße aber im Gespräch mit anderen Menschen stets auf das selbe Unverständnis, das ich damals aufwies. Dieser Artikel soll nun in groben Zügen und allgemeinverständlich die Aufgabenstellung und Probleme moderner Sprachsynthese aufzeigen.
This is part 2 of “Examples for performance optimization in C and C++”, you can find part 1 here: Examples for performance optimization in C and C++, Part 1
This brief case report shows an example for performance gains that can be achieved in C and C++ by simple analysis and code restructuring. It does not describe performance optimization in detail.
I’ve recently been implementing the Speech Synthesis SDK on iOS at VocaliD and wanted so share some quick hints on working with the Apple Audio Queue Services. This is no thorough treatise but just a few bullets points that might be helpful.
I’ve recently been reading the article “Coding needs a new youth movement” in which the author proposes that beginner programming courses should focus on “frontend” technologies to motivate students. Instead of “backend” technologies like Java, that is. This lead me to take a look back at the time when I wrote my first lines of code, which was more than 20 years ago. I assume that many creators of said programming courses also started at least back then, probably being the reason why the courses are structured in the way the are.
So here I would like to share (the beginning of) my journey from interested kid to CS PhD. This might end up as some sort of boring, archaeological curiosity but I still hope I can share at least some funny stories, pictures and lots of links (you notice all the highlighted words, right?).