jan.varwig

Ola Bini manages to express my feelings about the difference between Ruby and Python:

So what’s the point? Well, the point is Ruby. In fact, Ruby has almost all of the flexibility of Perl to do things in different ways. But at the end of the day, none of the Perl problems tend to show up. Why is this? And why do I feel so comfortable in Ruby’s “There is more than one way to do it” philosophy, while the Perl one scares me?

I think it comes down to language design. The Python approach is impossible for the simple reason that what the language designer chooses is going to be the “one way”, by fiat. Some people will agree, and some will not. But what I’m seeing in Ruby is that the many ways have been transformed into idioms and guidelines. There are no hard rules, but the community have evolutionary evolved idioms that work and found out many of the ways that doesn’t work. This seems to be the right way - if you do the choice as a language designer, you have actually chosen the people that will use your language: that’s going to be the persons who doesn’t dislike the language designers choices. But if you leave it open enough for evolutionary community design to happen you can actually get the best of both world: both a best way to do things, and something that works for a much larger percentage of the programmer world.

– http://ola-bini.blogspot.com/2008/02/language-design-philosophy-more-than.html

I like constraints, they can be liberating, but I also want to be treated as a grownup when it comes to breaking them. So Ruby’s socially suggested guidelines are much more comfortable to work with than Python’s enforced style.

http://platypope.org/yada/emacs-demo/ ;-)

I actually tried emacs before but didn’t stick with it long enough to really learn anything.

One school is that everything is fully deterministic in practice (“Theory D”). If development appears, from the outside, to be probabilistic, it is only because we haven’t discovered the “hidden variables” that fully determine the outcome of software development projects. And, since we are talking about development in practice, it is practical to measure the variables that determine the outcome such that we can predict that outcome in advance.

The other school of thought is that development is fully probabilistic in practice (“Theory P”), that there are no hidden variables that could be used to predict with certainty the outcome of a software development project. Theory P states that the time and effort required to measure all of the variables influencing a software development project precisely enough to predict the outcome with certainty and in advance exceeds the time and effort required develop the software.

…

To date, Theory P is the clear winner on the evidence, and it’s not even close. Like any reasonable theory, it explains what we have observed to date and makes predictions that are tested empirically every day.

Theory D, on the other hand, is the overwhelming winner in the marketplace, and again it’s not even close. The vast majority of software development projects are managed according to Theory D, with large, heavyweight investments in design and planning in advance, very little tolerance for deviation from the plan, and a belief that good planning can make up for poor execution by contributors.

Does Theory D reflect reality? From the perspective of effective software development, I do not believe so. However, from the perspective of organizational culture, theory D is reality, and you ignore it at your peril.

– http://weblog.raganwald.com/2007/06/which-theory-first-evidence.html

What clicked about Smalltalk was a few things: one was simply the maturity, both of the community and of the technology. Smalltalk implementations have been refined over the last 25 years, and they’ve really benefited from it.

One of the major benefits, in my opinion, is that Smalltalk VMs are fast enough that it’s reasonable to implement all of the standard libraries – Array, Hash, Thread, and so on – in Smalltalk itself. So there’s no barrier where you switch from your Ruby code to the underlying C implementation; it’s “turtles all the way down”. This may not seem like a big deal but once you have it, it’s really hard to give it up.

…

In Smalltalk, you don’t have to choose one file layout or order of methods and classes in your code; you’re constantly switching views on what’s basically a database of code.

My friend Brian Marick hates this, because you lose any “narrative” that might have existed by putting the code in a certain order in the file, and it’s hard to get used to, but for me, it’s the ultimate power tool for hacking on a large code-base.

– http://www.akitaonrails.com/2007/12/15/chatting-with-avi-bryant-part-1
– http://www.akitaonrails.com/2007/12/22/chatting-with-avi-bryant-part-2

Long story short, the key to being bad and nationwide is to do something useful. Create something new, that definitely came from you, that other people value. Rails, Adhearsion, or even just a blog. This simple step is much more important than most people realize. It has to trace back to you personally, or it’s useless for your career. As programmers, we are in the position of working for people who do not have the ability to determine whether or not we are good at our jobs. Even other programmers sometimes have trouble figuring out who is or isn’t a good programmer. For potential managers and/or potential clients, the hiring and firing processes are both essentially random, unless you have some obvious distinguishing feature. That makes marketing yourself essential

– http://gilesbowkett.blogspot.com/2007/10/im-bad-im-nationwide-job-security-vs.html

Ironically, “I want to be a manager” is just about the worst sentiment a would-be manager could possibly express, because the statement has absolutely nothing to do with leadership. A leader doesn’t fixate on management, which is after all just a bureaucratic framework that attempts to simulate leadership through process and protocol.

http://steve-yegge.blogspot.com/2006/05/not-managing-software-developers.html

also

http://steve-yegge.blogspot.com/2006/03/moores-law-is-crap.html

Arduino is an open-source electronics prototyping platform based on flexible, easy-to-use hardware and software. It’s intended for artists, designers, hobbyists, and anyone interested in creating interactive objects or environments.

Arduino can sense the environment by receiving input from a variety of sensors and can affect its surroundings by controlling lights, motors, and other actuators. The microcontroller on the board is programmed using the Arduino programming language (based on Wiring) and the Arduino development environment (based on Processing). Arduino projects can be stand-alone or they can communicate with software on running on a computer (e.g. Flash, Processing, MaxMSP).

http://www.arduino.cc/

“I don’t think we’re going to make it,” John Doerr proclaims, in an emotional talk about climate change and investment. Spurred on by his daughter, who demanded he fix the mess the world is heading for, he and his partners at Kleiner Perkins Caufield & Byers embarked on a greentech world tour — surveying the state of the art, from the ethanol revolution in Brazil to Wal-mart’s (!) eco-concept store in Bentonville, Arkansas. KPCB is investing $200 million in green technologies to save the planet and make a profit to boot. But, Doerr fears, it may not be enough.

Read the rest of this entry »

http://blog.pmarca.com/2007/09/the-pmarca-gu-1.html:

The first rule of career planning: Do not plan your career.

The world is an incredibly complex place and everything is changing all the time. You can’t plan your career because you have no idea what’s going to happen in the future. You have no idea what industries you’ll enter, what companies you’ll work for, what roles you’ll have, where you’ll live, or what you will ultimately contribute to the world. You’ll change, industries will change, the world will change, and you can’t possibly predict any of it.

Trying to plan your career is an exercise in futility that will only serve to frustrate you, and to blind you to the really significant opportunities that life will throw your way.

Career planning = career limiting.

The sooner you come to grips with that, the better.

The second rule of career planning: Instead of planning your career, focus on developing skills and pursuing opportunities.

…

via svn

Microsoft Research: TrueSkill

The TrueSkill ranking system is a skill based ranking system for Xbox Live developed at Microsoft Research. The purpose of a ranking system is to both identify and track the skills of gamers in a game (mode) in order to be able to match them into competitive matches. The TrueSkill ranking system only uses the final standings of all teams in a game in order to update the skill estimates (ranks) of all gamers playing in this game.