Software engineering doesn’t work
This is the best presentation on software engineering I've ever seen, everyone should watch this:
Real Software Engineering by Glenn Vanderburg
Tweet
A modern set of OpenGL Tutorials
Wow, this is the only good set of modern OpenGL Tutorials I've seen:
A bit more up to date than NeHe..
Tweet
It’s finally done
So the next C++ standard is finally a reality. Speaking as someone who used to live and breathe C++, someone who used to wait for the next batch of the C++ ISO working group's mailing discussions; I can definitely say: it's too late - I don't care anymore.
C++ just feels old and rusty compared to the shinier toys out there: python/tornado/PyPy, HTML5/CSS3, JS/node.js/coffescript, Erlang, Go.
It's actually fascinating to see how so many really really smart people can spend so much effort and time on something and not realizing that it won't matter. C++ will never be modern and exciting again. While the new standard is bringing some great improvement (auto, for each loops and lambdas for example) - it's not doing much to solve the big issues:
1. An extensive standard library; look at the standard libraries for Python, PHP or even the recently invented Go. They have everything! New C++ programmers are instead encouraged to write 'cross platform' code by sticking to the C++ standard library, which pretty much locks you up in a room without being able to interact with the world in any meaningful way whatsoever. And Boost is not the solution, it has too little practical real world stuff and too much confusing template metamagic.
2. Garbage collection, even a performance junkie such as me has to agree it's pretty damn useful.
3. Compile time and runtime reflection. If we could have this, then the community would be able to write tools, libraries and even invent our own language constructs to improve the language without having to wait 10 years for the next standard update to give us too little too late.
4. Readability, sure - you can write pretty C++ code. But take a look at any big C++ project or library being used in production; it makes your eyes hurt.
5. Robustness, C and C++ programs crash and leak memory and have holes through which malicious code can be injected.
6. The rest: there's no standard way of loading modules dynamically. Utf8 support sucks. Unreadable compiler error messages. Compile times are way worse than any other language, etc..
So, while C++ might be slowly dying - let me focus on the things it got right and other languages could learn from:
1. Abstractions without overhead, I just love how C++ let's you have your cake and eat it too. Look at all the bells and whistles a std::vector<MyAwesomeClass> provides without having any memory or performance overhead compared to a malloc:ed array of structs. Outside of the C++ world people always seem to assume that abstractions come with runtime overheads. And while it is harder to achieve this in more dynamic languages, I don't think it is impossible; really smart trace or JIT compilers could take us a long way.
2. Generic programming, I think Alexander Stepanov's work provides a fundamental shift in how to understand, teach and use data structures and algorithms. But it hasn't yet had much of an impact on how programmers design and write code. I hope the further development being done for D2 will bring us closer to enlightenment.
Tweet
Tofu pop monk, mesh networking, and moving beyond the cloud
Trust on first use, persistence of pseudonym, mesh overlay network keysigning.
Which basically says, that having a hierarchy of trust (as we have for HTTPS certificates) is less reliable than having a distributed mesh of peers putting trust in each other; based on the principle that it's easy to fool one person once, but hard to fool all people all the time.
Now, I'm not all that interested in the intricacies of encryption, but everything related to mesh networks get's my attention. The cool technology aside; it's the subversive, anti-authoritarian aspects of it as well as the almost biological resistance and adaptability such systems possess that attracts me. And I'm not the only one, read Charles Stross or Cory Doctorow's writing for example.
Some things we could do if our world was based on mesh networks:
- The protesters in northern africa could spread their messages even if the government shuts down the mobile network masts
- If several people on the same train were looking at the same youtube video, the data could be shared between them resulting in faster downloading
- People's mobile phones would still be usable after catastrophes such as the recent earthquake in Japan
- Server's won't overload, but instead spread the data through the mesh distributing the load
Doc Searls has a great blog post called A sense of bewronging where he highlights the oddity of insisting to build so much of our technology around the server/client model; when it has so many obvious shortcomings.
If governments fail to stop it - after the age of computing in the cloud there will be an age of computing in the swarm. Where you don't build a web app and set up a server, you just release it into the swarm. And you will never have any scalability problems, because the more users you have, the more resources you will have. Of course, in order to gain something, you have to pay something - and that something is power. You will not have complete authority over your creation, because the swarm would not accept that. It would just not trust any one entity with so much control.
Update:
Decentralized Web Standard Under Development by W3C
Tweet
Rob pike on modern programming languages
OSCON 2010: Rob Pike, "Public Static Void" is a great presentation:
Tweet
Testing and the three categories of software bugs
This was interesting. But I'm not thinking about the intricacies of operator precedence. I'm thinking about the amount of bugs existing in high profile, seemingly working software. These bugs seem to render the affected code just wrong, so how come no one noticed this immediately? The only explanation I can think of is that this code almost never executes with the parameters that would trigger the buggy behavior.
But I was also surprised by the nature of the bugs. Let me explain: let's say that when a programmer writes some piece of code he goes through three stages:
- Understanding the problem
- Coming up with a solution
- Implementing the solution
How to install vimgolf on ubuntu
Vimgolf doesn't seem to like the default gems package; this worked for me:
sudo apt-get install ruby ruby-dev
wget http://production.cf.rubygems.org/rubygems/rubygems-1.7.2.tgz
tar xzvf rubygems-1.7.2.tgz
cd rubygems-1.7.2
sudo ruby setup.rb
sudo gem1.8 install vimgolf
vimgolf setup
Cutting edge graphics programming topics
Wolfgang Engel writes:
http://altdevblogaday.org/2011/03/15/thoughts-on-the-knowledge-of-an-up-to-date-graphics-programmer/
I wish I could have time to keep up with this stuff.. I especially think real time global illumination must be fascinating to try and find nice solutions for.
Tweet
