Re: [tlug] C vs. other languages (was: tlug-digest Digest V2004 #194)

[Josh Glover <tlug@example.com>]

Quoth Godwin Stewart (Sat 2004-07-31 12:35:54PM +0200):

> On Fri, 30 Jul 2004 22:12:26 -0400, Josh Glover <tlug@example.com> wrote:
> 
> > Programmers are expensive compared to machines.
> 
> Depends where you are.

True. In this thread, I have been thinking in the context of the US, which
is the only one I know. Sorry about that. :)

> > Why pay 10 months of a programmer's salary to develop something in C that
> > he could develop in five months in Java or Perl or whatever,
> 
> Because a C programmer costs less than a C++ or Java programmer right from
> the outset.

True, but you will find that the really good programmers know C++ and
Java, at least a little bit. Most professional developers that really
care about doing a good job (i.e. the ones that I would want writing
code for me) learn about many different languages in order to make the
best decision about how to implement each chunk of code.

Choosing C for every project without even thinking of alternatives is
just as foolish as choosing Java without thinking (a lot of companies
did that during the heady days of the dotcom bubble, and look how fast
they went out of business).

> > Compare yourself to Bill Gates. Who has more money? Sure, you can say
> > that Bill lacks any morals or scruples, but you would be a fool to say
> > that he lacks business sense and management skill.
> 
> That's the only thing of any value at M$. They can't program worth shit but
> they *do* know how to sell their garbage. "This isn't a bug, it's a feature"
> comes to mind, as do the illegal contracts with OEMs forbidding them from
> selling machines without Windwoes installed on them.

Yes, Steve pointed out that BG's robber baron (rubber button?) tactics
had more to do with MS's success than anything. He is probably right,
but I think Microsoft does a lot of things right. For one, they seem to
be very good at management (of software projects, all I care about).
Nearly every programmer that I have talked to or read that has worked
at Microsoft thought it was a good place to work. (And yes, before
someone brings this up, I *have* read Douglas Coupland's _Microserfs_.)

I disagree rather strongly with you about MS not being able to program
worth shit. It is frankly very hard to write an OS that runs on
machines cobbled together from various shitty pieces of hardware that
were made in some Taiwanese basement by a ten year old.

Programmers, especially Open Source types, seem to think that MS is bad
at programming because of the bugs that they will not fix. This is
business skill, not lack of technical skill. Sadly, the consumer soft-
ware market will tolerate disturbingly low quality, but they will not
tolerate having to wait six more months, or not having a word count
feature in their word processor. So in a way, producing zero-defect
software is bad business for Microsoft.

Now, you also need to know that I work for a telecomm company who has
a virtual monopoly on our small niche market: automation of outage
reporting for utility companies. I do not work on consumer software
at all, and all of the consumer software that I use is Open Source. So
I am perhaps not very qualified to talk about consumer software. :)

And I should have made it clear where I am coming from, because that
makes my position a bit different.

> > Some of the best books that I have read on software development and the
> > management of software projects were published by the Microsoft Press,
> > and they all go out of their way to point out that in a tradeoff between
> > programmer time and machine time, programmer time almost always wins.
> 
> Heh - no kidding! Coming from Microsoft that's hardly a surprise.

Perhaps it would be a surprise to you to know that there is no diff-
erence between MS and non-MS books on this issue.

> > 2. Most of the time, the performance of software written in higher level
> >    languages than C is good enough.
> 
> Plus, as you already pointed out, local processing isn't usually the
> bottleneck. I/O is. But it does also depend how often you're going to be
> using the script/program. 0.1s per mail saved on something analysing inbound
> mail, for 100,000 inbound mails each day, means nearly 3h processing saved
> per day.

True, and this is a great case for optimisation, but only if you really
can save 3h/100,000 emails, and only if saving that three hours would
benefit you in some other way than feeling good about how fast your mail
analyser is. (Again, in the Open Source world, it *is* worth doing if it
makes you feel good, because that is a big part of a hobby--feeling
good.)

> libpcre maybe? Perl-compatible regular expressions in C code. Great stuff,
> you should try it.

I know it, and have used it in the unfortunate case when I am stuck need-
ing to do regexps from a C program. It is not as convenient as in Perl,
for certain. You can't just go "$str =~ /^foo/, now can you?

> If it's as time-saving, clean and powerful as you're making out, surely
> that's a good reason in and of itself!

Steve pointed out the bigotry factor, which is exactly how I feel, but I
did not have the cojones to say it.

> However, I think the main reason it hasn't taken off in OSS circles is
> because it means learning a new set of skills in order to produce something
> that isn't as efficient as that which current skills can produce. Whether
> the emphasis is more on the "learning a new set of skills" bit (laziness,
> fear of the unknown) or on the "not as efficient" bit, I don't know.

Java is really just C with OO done reasonably correctly and a *huge*
standard library.

> Furthermore, the main "thing" with OSS is the fact that you're distributing
> source code 99% of the time. Therefore, whether a compiled Java applet can
> run on any platform with a suitable JRE or not is irrelevant because you're
> not distributing the bytecode anyway. Why distrbute something which requires
> both a Java compiler *and* a JRE when you can distribute something which
> requires just a bog standard C compiler with a few (standard) libraries?

That is very true. Joel calls this the chicken and the egg problem.[1]

> What I'll often do is use a higher-level language to work on the logic of a
> program, and then translate the intermediary product into something more
> efficient - IF THERE IS SOMETHING TO BE GAINED. I'm not going to translate a
> 10-line bash script run once a day into C for shits & giggles.

This is exactly what you should be doing, IMO, and this is the crux of
my argument.

> > Anyway, I did not mean for this to degenerate into a holy war. :)
> 
> This could easily have degenerated into a flamefest anywhere else. One of
> the good things about TLUG is that people can disagree but still remain
> civil.

Fuck you! ;)

(Sorry, I could not resist a variation on the old joke:
 Dude #1: "Can you feel the love in this room!?"
 Dude #2: "Shut the fuck up!")

Cheers,
Josh

[1] http://www.joelonsoftware.com/articles/fog0000000054.html

-- 
Josh Glover

Gentoo Developer (http://dev.gentoo.org/~jmglov/)
Tokyo Linux Users Group Listmaster (http://www.tlug.jp/)

GPG keyID 0xDE8A3103 (C3E4 FA9E 1E07 BBDB 6D8B  07AB 2BF1 67A1 DE8A 3103)
gpg --keyserver pgp.mit.edu --recv-keys DE8A3103

Attachment: pgp00000.pgp
Description: PGP signature