🚀 go-pugleaf

In article <1992Dec11.163906.2483@webo.dg.com> dlewine@nf01.webo.dg.com (Donald Lewine) writes:
|
>In my experience (over 30 years of professional programming), your choice of
>algorithm has a much larger effect on performance than your choice of programming
>language or compiler technology.
>
>If programmers spent more time working on their algorithm and less time arguing
>about the efficiency of their compiler, they would produce faster programs sooner.
>
>I have been able to speed up programs by a factor of 1000X or more by changing the
>basic algorithm.  I have never seen a speedup that large from a compiler.  [Except
>in cases where the compiler changes the basic algorithm (e.g. loop unrolling)]

    That's nice, but don't dwell on your years of experience too much, I
    know people with at least that much experience who have trouble
    grasping the basics of modern day programming languages (this is not a
    personal insult directed at you).  Experience is a relative term and
    the phrase 'years of experience' instills no confidence in me when I'm
    interviewing someone for a job.  "It is always the mistake that
    executives make".  My view of experience is to put uncommented
    schematic or source code in front of someone and see if they can figure
    out what it does.

    In the short term, yes.

    In the long term, however, the programming language has a lot to do
    with the maintainability of the software.  Programs can start out good,
    but when you loose the original programming team (which happens all to
    often) the software generally degrades to the point where one is unable
    to address new features required by the user base or even to fix bugs
    in a timely fashion.  Software complexity has an equivalent effect.
    This premise is bourn out by just about every piece of commercial
    software in existance and is why it is so easy for a new company to
    superceed an older company's software.

    People say that you can do anything with any programming language and
    its true enough on theoretical grounds, but not realistic in practical
    terms.  Just because you can doesn't mean you do, and like it or not,
    most people stick pretty close to the models a particular language was
    designed for rather then try to program it in a way it was not designed
    for.

    Take Objective-C and NeXTStep for example... look how hard it was for
    NeXT to make even the simplest of changes in their interface
    specification (the alloc/init combination instead of new). It *still*
    isn't generalized and has special cases all over the place for fonts
    (the sharing of fonts is not hidden and requires one to view font
    operations in special case situations), certain one-time structures use
    a different initialization model, there are all sorts of
    incompatibilities with multi-threaded operation because it turns out
    that Objective-C's run time system is too dynamic... requiring extra
    locking in order to work properly in a multi-threaded environment.	A
    simple call, yes, but a huge gaping special case that became necessary
    when NeXT found out the cost of multi-threading their dynamic caching,
    method call overhead increases 3x best case. I can't even begin to
    describe problems with the distributed objects interface, it is far
    from seamless.

    One could argue that the Objective-C paradigm does NOT fit NeXTStep
    like a glove and it is becomming less general, more special-cased, and
    more difficult to maintain.  Still better then C, of course, but it
    just goes to show that while there is such a thing as a 'better'
    lanugage, there is no such thing as an ultimate language and even if
    one starts out sticking to the bounds of the language model, ongoing
    development tends to introduce new situations that the language cannot
    easily handle well.  If this were not true we would still be
    programming in pseudo-assembly.

					    -Matt

>--
>--------------------------------------------------------------------
>Donald A. Lewine		 (508) 870-9008 Voice
>Data General Corporation	 (508) 366-0750 FAX
>4400 Computer Drive. MS D112A
>Westboro, MA 01580  U.S.A.
>

--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000