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
... 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
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