 |
 |
On Fri, 26 Mar 2010, Doran, Michael D wrote: >> As a first language, you want something that let's you Get Stuff Done >> with a minimum of fuss... > > If you are getting started and if you are not planning on being a > full-time programmer, then you want to be looking at the high-level > languages as Mike suggests: "the strong candidates include Perl, Python, > arguably PHP and my own favourite, Ruby..." Even *if* you are looking to be a full-time programmer, I'd recommend most people do stuff in higher-level languages. That earlier development effort that I mentioned, the majority of their work is being done in C -- the system needs to go live in ~30 days, and they're *still* finding memory leaks (signs of poor garbage collection), string and integer overflows (one of the joys of strict typing), etc. Yes, I've done a fair bit of C, and even a little assembler -- and it's fine, if you really, really, need the speed boost. (and some people would argue that this might be a case where they *do* need it, but it'd have been more cost-effective to throw hardware at it, rather than a 10 person team for 2-3 years, even with their 100-node cluster; or better yet, wait to see what happens under real load, and optimize then, rather than building a system with no requirements, and no testing of simulated data flows until 2 months before launch) I've had my share of problems in Perl, where it'd attempt to assume what I mean has led to problems. (specifically, SOAP::Lite's attempt at guessing that a string full of numbers was an integer, not a string, and that a URL should be marked as such, and not a string ... once in a while, I'll hit one of the edge cases with braces where you have to force it as a block or a hash) ... but those are few and far between compared to the segfaults that I've gotten in trying to port their code over to a non-linux system. (spent months on it, as each new version would either not fix the problem, or break new things ... it doesn't help they decided to write their own configuration and build tools because someone must've read 'recursive make considered harmful') ... we finally gave up and just bought new hardware for our caching sites, as we had a feeling that we'd have to keep going through these headaches every new update through the life of the mission. ... sorry, went off on a tangent again. Anyway, the point is -- even us full-time programmers would rather be making new and interesting things, rather than trying to work around problems with our tools. If I'm painting a room, the roller gets the job done fast, and I can deal with a brush for the corners and edges -- there's no reason to do the whole thing with a brush, and it'd just look like crap if I tried doing the whole thing with a roller. Take the same approach in programming -- if you can do 90% of the work really fast and really well in one language, and have to do the other 10% in another language, it doesn't mean you need to do the *whole*thing* the slow way. I believe that all of the 'higher level' languages support some form of linking to C code, should you need it. (although, you don't always need it ... after dealing with scientists insisting that I use their libraries, and trying to get it compiled as an object so I could call it as a postgres function, I finally just gave up and hard-coded the table in PGPLSQL ... I'll just have to update it every few years as leap-seconds are added to UTC) ...crap, tangent again. okay, back to the hell of debugging crappy code with off-by-one errors and race conditions due to lack of locking, and no error checking to see if processes completed. -Joe