Posted by David N. Welton Tue, 30 Oct 2007 15:15:00 GMT
I've been working on a project that uses graphics created with Plotr, and I wanted to automate that from Rails, so I created Chartr. It's not very complete, but works well enough to create stuff like this:
Help is more than welcome! I think the API is still a bit clumsy, more chart types need adding, and there are other things that could probably be improved, but it does work.
Posted by David N. Welton Wed, 24 Oct 2007 17:43:00 GMT
I was recently talking with some people who develop a BSD licensed product who are a bit worried about competition. I had this to say, and I thought I would share it.
I think the concern is the "Sun Microsystems situation", where there is a second project (B) based on open source project (A), and code only moves in one direction, towards B, a, commercial project. That can be kind of scary, especially when the commercial project has some sort of advantage. There is a real risk that as users and developers move towards project B, network effects take over, and B comes to dominate.
The GPL is one answer to this problem, that the Apache Software Foundation, and others in the "BSD camp" have chosen to eschew, in favor of another solution: 1) making the development community broad enough and strong enough to make it hard to vacuum up all the talent over to project B, and 2) moving fast enough with the project that development outstrips that of project B.
Of course, that strategy is not always possible, but that's the direction to take, I think - make it so that it's a big effort to 'keep up' with project A for the commercial guys, to the point where they don't want to diverge very far from the main development line for fear of not being able to keep up with all the good stuff coming out of it. One of the ways this can happen with a BSD style license is to get lots of companies contributing to the common code base, something that is at times easier if they have no worries about restraints the license may place on their future directions.
Incidentally, I also think people may like the GPL because it makes things "fair", without worrying so much about putting in the effort to "outrun" the competition in terms of code or community.
These are some of the reasons why I don't get too worked up about there being a "best" license. It really depends on the situation, and the goals of the people involved, too much to get fixated with one license being "superior".
Posted by David N. Welton Sun, 14 Oct 2007 17:03:00 GMT
I have a computer with a RaLink RT2561/RT61 wireless card that never worked very well under Feisty, so I decided to try out Gutsy, on a whim.
The good:
The card now works! So that's good news. Other than that, none of the features listed here is a big deal for me, but it's nice to get a lot of programs updated to newer versions.
The bad:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/115616
Luckily it's easy to fix.
The ugly:
Upgrading emacs was a pain, as a lot of packages seem to cause breakage with emacs22. That's not really the fault of the Ubuntu guys, but it would be wonderful if they'd fix it prior to release.
I haven't used the computer much yet, but consider the release isn't official yet, it's not bad, but I think it still needs a little bit of work. Anyway, I'm happy that my card works, I'm happy.
Posted by David N. Welton Tue, 09 Oct 2007 13:06:00 GMT
This is a pretty good take on Tim Bray vs Erlang. However, I'd like to focus on something said at the end:
The fact is, all languages optimize for particular problem domains and I don't think that a universal programming language exists that would perform well on all tasks. Bray rapidly found out that Erlang isn't optimized for doing line-oriented I/O and it's regex library sucks. So what? While those problems could be eliminated from Erlang, the fact that Ericsson has deployed large telecom gear without having to fix those issues means that Erlang is ideally suited to its original programming domain.
The problem is that learning new languages is difficult for many people. They're not going to bother starting from 0 with a new language if what they've got is only 10/20% worse than the other guys. For companies, developing expertise (and trying to maintain it) in lots of languages is probably less productive than picking a few (Google only has four: Java, Python, Javascript and C++, and they're not exactly lacking in brainpower or cash). This is why "the right tool for the right job" works for things like saws and hammers, but not for complicated, idiomatic things like programming languages.
Therefore, it's important that languages that aim to be widely used do lots of things pretty well, and try to avoid doing anything really badly. This is something I've always admired about Python, even if I don't use it anymore. It's a language that you can do a very wide variety of tasks with, and you can be sure there's probably some code out there already, and that Python will be ok for your task, even if it's not the best thing. Performance is a weak point compared to compiled languages, but even there, get the libraries right and things aren't *so* bad.
In any case, my point isn't to bash Erlang (which I like), or put Python on a pillar (I prefer Ruby and Tcl), but to say that a widely used programming language doesn't need to be the best at everything, but it should aim to make people comfortable using it, safe in the knowledge that they can probably do most things *ok* if needs be. That's a far better situation than being able to do one thing realy well, and perform poorly at many other tasks, forcing its users to look elsewhere for solutions to those tasks.
Personally, I think that for concurrency, Erlang is in a bit of a race right now - they're pretty far ahead in terms of concurrency (and also fault tolerance, but fewer people care about that), but behind in other areas (less library code). Other languages don't have as good a tools for concurrency, which isn't an easy problem. So, what will happen first - Erlang catches up elsewhere, other languages get "good enough" concurrency solutions, or a new language (like Scala) comes along and takes the lead?
Posted by David N. Welton Sat, 06 Oct 2007 08:56:00 GMT
The guys at Free Software Magazine just published a Hecl tutorial that I wrote.
They're a pretty good outfit - you won't get rich, but since the article is under a free license, I'll be able to integrate it with the Hecl documentation pretty quickly, which was more important to me than a few dollars here or there.
