From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: mdw@excessus.demon.co.uk (Mark Wooding) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/11 Message-ID: <4ul191$38j@excessus.demon.co.uk>#1/1 X-Deja-AN: 173522880 x-nntp-posting-host: excessus.demon.co.uk references: <31FBC584.4188@ivic.qc.ca> <01bb8342$88cc6f40$32ee6fcf@timhome2> <4u7grn$eb0@news1.mnsinc.com> <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> <4u89c4$p7p@solutions.solon.com> <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> organization: Straylight Development Lab reply-to: mdw@excessus.demon.co.uk newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-11T00:00:00+00:00 List-Id: Dan Pop wrote: > In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim Behrendsen" writes: > > >For example, look at OOP. Very naive implementations of OOP > >used a huge amount of dynamic memory allocation, which can cause > >severe performance problems. That's why I don't use C++ for my > >products; to do it right you have to do a very careful analysis > >of how your classes are going fit together efficiently. > > > >I've spoken to enough people that have had C++ disasters to > >convince me that the more abstraction there is, the more > >danger there is of inefficient code. This shouldn't be that > >hard to believe; any time you abstract away details you are > >giving up knowledge of what is going to be efficient. > > Nonsense. The efficiency of an implementation can be also thought in > abstract terms, you don't need to know how the compiler works or > assembly language in order to implement your application in an efficient > way. Or you may know all these irrelevant details and still write > inefficient code, because it's so much easier in many OOPLs. Indeed. But in the same way, if you use (the same) good algorithms in the non-OOPy language, I suspect you'll end up with it going faster. It's important to get your algorithms right, but it's also important to get the right level of abstraction. > More nonsense. Unless your applications spend the bulk of their CPU > time in the user interface, that should be a non-issue. Applications do tend to be spending a suspiciously long time in their user interfaces. You're right that it /should/ be a non-issue, but it doesn't appear to be. Responsiveness of interfaces is rather important as far as producing a good impression is concerned. On a platform I've done a lot of work on, the main user interface kit has wandered in the direction of being more abstract and HLL-based. I spotted this trend a couple of years ago, wrote a user interface library entirely in assembler (it took two of us about a year); it ended up being considerably more responsive, more featureful, and smaller by about a factor of five. This scared me quite a lot. > And if the wrong algorithm has been chosen in the first place, no > amount of micro-optimization will save the code performance. The guy > who can do a decent algorithm analysis (an entirely abstract > operation) will always beat the one who is an expert assembly > programmer but prefers to spend his time coding instead of dealing > with abstractions. An easy solution presents itself: do both. Implementing a complicated algorithm in assembler isn't much harder than implementing it in C (so I've found), and maybe I'm just a bit odd, but my assembler code is usually less buggy and easier to debug. I'd only consider using a HLL if development time is really tight, quality is totally unimportant, portability is an issue or the instruction set in question is truly horrid. > This is an old story (it happened during the early to mid eighties) > and I forgot the details. One software company had a nice product for > the PC, but it was rather slow. To get the "best" performance, it was > coded in assembly. Another company decided to emulate that product > and they did it quite successfully (their version is about 4 times > faster). They implemented it in C, but they've carefully chosen their > algorithms. I shan't stand here and defend assembler programmers who use the wrong algorithms: that's silly. But an assembler programmer who uses the /right/ algorithms, now there's someone to look up to. Why is it, by the way, that no-one here (apart from me) has mentioned the issue of code size? Does no-one care? If it's accepted that the performance of 90% of a program is not particularly relevant, why isn't it written to save space? Surely /this/ is the reason that programs are too big. -- [mdw] `When our backs are against the wall, we shall turn and fight.' -- John Major