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