<html><head><style type="text/css"><!-- DIV {margin:0px} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div><br>Thanks Lars. I do share your frustration with the limbo state of OpenStreetMap lately, and hope we can push through, start realizing the potential of this great project.<br><br><div>> I have absolutely zero experience of Ruby, which is one reason for <br>> my staying out of software development here.  My assumption is <br>> that Ruby is just as fine as Perl, Python or PHP, and that any <br>> language is fine as long as the programmers like it.  Steve seems <br>> to like Ruby, and so do many other smart people, which makes me <br>> doubt that there could be anything fundamentally wrong with it.  <br>> My own background is in C, C++, Java, and Perl, so I wouldn't mind <br>> a
 migration to Perl.  But I think you would need pretty hard <br>> evidence to (convince Steve to) abandon Ruby.<br><br>I had no experience with Ruby before OpenStreetMap. It hasn't been that hard to pick up, having a copy of the "pickaxe" book has helped me understand what it's about. It is rather nice and concise, and very good for multi-developer web projects, and there's no reason to abondon Ruby on OpenStreetMap. However, for some jobs, Ruby isn't well suited -- like the heavy iterative number crunching required in drawing tiles. My understanding is that everything in Ruby is an object, and every function a method -- even addition! So every math operation actually requiries a function lookup, and that gets pretty inefficient fast.<br><br>For the tiling, ideally the iterative number crunching and drawing would be in C; the Perl was just a quick trial. I haven't done it myself, but Ruby can call C code with SWIG (as it does with ImageMagick). We want to keep
 portions of the Ruby code, so that SQL isn't duplicated. C code to do the tile generation would be awesome here.<br><br><br>As an aside, ideally tile generation would happen in a background process and cached -- you'd never have a tile request from the slippy map or editor hitting the database. But that would require a bit more infrastructure than currently available.<br><br><br>> Thank YOU!  You may now sign off ticket 134 as solved.<br><br>Cool, marked resolved.<br><br>-Mikel<br><br><br></div></div></div></div></body></html>