Re: [tlug] C vs. other languages

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Josh" == Josh Glover <tlug@example.com> writes:

    Josh> Programmers are expensive compared to machines. Why pay 10
    Josh> months of a programmer's salary to develop something in C
    Josh> that he could develop in five months in Java or Perl or
    Josh> whatever, but needs to run on a $15,000 server rather than a
    Josh> $5000 one?

Because you can sell one copy to the guy who can afford a 10,000
upgrade, and 25 to people who will Just Say No, maybe?

    Josh> And voila! MS was right, hardware is now a commodity (it
    Josh> wasn't when MS was founded).

And had Gates not been a robber baron in the classic mold, I have
think MS Office would have withered on the vine, and quite possibly
the company with it.

In the 1980s, I didn't know anybody who bought _any_ of the Microsoft
OA components; people who have money to spend bought WordPerfect, or
Quattro, or dBASE II, etc.  People who needed close integration
between their spreadsheet and the word processor would take the whole
suite, of course.  But the real reasons why MS Offense rules the
desktop are (1) MS's practice in the late 80's and early 90's of
subsidizing OEM giveaways of Office on new hardware (2) deliberate
sabotage of competing products via unadvertised APIs and API semantic
changes with new releases of Windows.  ("And if you really that good,
the lights go out when you got the ball.  Can't beat a ghetto team in
they own gym.")  Not because people bought CPU and RAM fodder to feed
dem hawgs.

    Josh> If I have a choice between using up 15% of a CPU that is
    Josh> almost always idle anyway with a Java / Perl / what have you
    Josh> program or using up %5 of that same CPU, why would I *ever*
    Josh> choose C? 

Because 0.5% of the time, every single one of those processes is on
the critical path simultaneously.  These things are generally peak
load issues, not average load.

For this argument, you either have to get into details such that you
would probably have to kill us after telling us, or you should stick
to the desktop, where (for example) Emacs users spend about 10% of
their time looking at the GC cursor spinning, but live with it.

That said, this is a good summary and bears repeating:

    Josh> It is not usually. The main points that I am making are these:

    Josh> 1. Programmers cost way more money than machines.
            ^
      Good_/   A bad programmer can cost you more than both combined,
and a bad manager could put you right out of business. ;-)

    Josh> 2. Most of the time, the performance of software written in
    Josh> higher level languages than C is good enough.

    Josh> 3. Bad performance results more often from bad algorithms
    Josh> (the programmer's fault) than a choice of language.

    Josh> Now having said that, BeOS was written almost entirely in
    Josh> C++, IIRC, and seemed to be pretty efficient.

C++ is an assembler on steriods with classes.  ;-)

    >> What about the mailer I use?

    Josh> I dunno which mailer you use, but if you had to *write* a
    Josh> mailer today, would you really do it in C? I sure as helll
    Josh> would not. I would use Perl, and take advantage of how easy
    Josh> string parsing is, since that is at least three-forths of
    Josh> the work of a mailer.

And you'd probably use Perl for the next mailer you write, too,
because you couldn't remember how the first one worked when you need
to fix it.  ;-)

    Josh> A GUI is the one place where not using OO is just plain
    Josh> stupid. Even GUI libraries written in C emulate OO.

It's not "emulation"; it's a question of whether the objects are
managed by the system or not, and what aspects of the objects are
managed by the system.  But Xt and Athena are real OO, just they
depend on the programmer to do a lot of the object management.  Take a
look at http://www.jwz.org/doc/censorzilla.html[1], and note the
number of times that resources and toolkits figure in that context.
It's not an accident.

However, good GUI implementation is a very special kind of OO:
event-driven programming.  Sure, messages are being passed to objects,
but (especially in the X Window System), most of those messages are
not sent from object to object, but rather are collected from the
environment.

In fact, GTK+ v.1 was a _regression_ from Xt in that sense.  One of
the big advantages that GTK+ implementors had was that they generally
assumed that (1) the client and the server were on the same machine
(about the same time that X11 finally purged the Xdefaults style of
resource database, the G* folks were reinventing it, in XML of
course), and (2) the client only connects to one display at a time.
Both of these made the function invocation model of inter- object
communication much more plausible, and that's what you see in a lot of
the GTK+ v.1 internals.  Admittedly, the "signal wiring" model of
events that GTK+ uses is a big improvement on the "callback" model
that the X Window System uses.

I can't speak for GTK v.2; I gather that they've made things more
thoroughly OO, though.

    Josh> The reason that more Open Source tools are not written in
    Josh> Java is (at least) twofold:

    Josh> 1. ...

    Josh> 2. ...

    3. The open source implementations suck and are typically a full
       minor version behind whatever Sun is pushing.

    Josh> But Perl, OTOH, makes me feel really productive, and allows
    Josh> me to concentrate on the logic of my program, not the boring
    Josh> memory management shite that will hold my exquisite house of
    Josh> cards together! :)

You know, you can get MM with the Boehm garbage collector.  "Malloc
and forget," basically.

Really, for most application software, the issue is OO, and a single
type (maybe a pair) at that: the string (the optional second type
being the regexp).

    Josh> Shit, ESR himself agrees with me on this point, as do the
    Josh> Pragmatic Programmers, K & P, Joel (of Joel on Software),
    Josh> the Peopleware chaps, the list goes on of people who have
    Josh> said: For Thy First Stab at Writing Code to Solve a Problem,
    Josh> Thou Shalt Useth a High Level Language; Oftimes Thou Shalt
    Josh> not Even Need to "Throw out Thy Prototype" and Write Thy
    Josh> "Real Programme".

Then why are you talking about Perl and Java?  ;-)  Assemblers with
reference-counting garbage collectors, pthah.


Footnotes: 
[1]  I quote Jamie not because he's smarter than everybody else, but
because I know his code from specification to nittygritty bitflicking
and the "five steps of the Waterfall Life Cycle" in between, and he
does it all tolerably well.  And then because I like a little
togarashi in my cooking.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.