From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Cross Message-Id: <200104271631.MAA27560@augusta.math.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Awk or Limbo ? In-Reply-To: <3AE976A5.34B30300@arl.army.mil> References: <20010426231220.A2383@localhostnl.demon.nl> <200104270119.VAA23482@augusta.math.psu.edu> Cc: Date: Fri, 27 Apr 2001 12:31:36 -0400 Topicbox-Message-UUID: 94ce8018-eac9-11e9-9e20-41e7f4b1d025 In article <3AE976A5.34B30300@arl.army.mil> you write: >Dan Cross wrote: >> ... Plus, the [C++] object system is all wrong, >> forcing bizarre constructs like templates on the programmer, ... > >? Templates seem like one of C++'s better features. >That and namespaces. They are, but that doesn't necessarily mean that they integrate well with the rest of the programming environment, nor does it decrease their bizarreness. In this case, I think it's pretty clear that templates were an afterthought, and they're grafted on in a convoluted way. That said, if forced into using C++, they are useful, but they ain't pretty.... As a specific example, create a class hierarchy, and then use templates to create a container of objects from your class hierarchy. (Or even use the STL). Note, now, that when you copy a subclass into the container, it's converted to an instance of the base class and you loose your subclass data. Argh! This is because polymorphism in C++ is only acheived when you refer to an object through a pointer or reference, and templates are dumb. Eiffel has a similar concept (I believe they even call them templates), but I seem to recall that it integrates into the language in a *much* less obtrusive way than in C++. >"Object orientation" fits GUI rather well, but is certainly >not natural for several other common programming needs. Yes. >> One of the things about C, though, is that (IMHO) it works best as a >> systems programming language. As an application development language, >> it has all sorts of traps and pitfalls (indeed, Koenig wrote a book >> by that name once, listing many of them), and other annoyances, like >> the lack of built-in ADTs (why should I build a dictionary myself? >> 99% of the time, I just want to use it; I don't care about how it's >> implemented). > >ADTs are easy to build in C; but part of it is that the programmer >himself must provide some of the discipline. Sure, it's easy, but it's also easy to tie my shoes. That doesn't make it any less annoying. :-) When working on a problem, I start to envision what kind of structures (in the sense of ``computational structures,'' not necessarily data structures) I want to use to solve it. For instance, I know that I'll need an associative lookup, some sort of list, I'll have to put a sort in some place, etc. When I'm working in C, I have to go off and implement most of that stuff before I can proceed. It's not hard, but it is tedious and annoying. When working in another language (say, smalltalk, for example) most of that stuff is already done for me, and so I can just use it. That's handy. >> One does wonder, however, if the Unix utilities had been written in >> another language like Limbo if we would be whitnessing all the stupid >> buffer overrun attacks that the kids are using for bypassing security >> these days. > >Buffer overruns are not inherent in C; they're the result of >insufficient care by the undergraduates who whipped together >networking code that the industry then adopted without any >sensible review. Similar problems occur using other languages. No, they're not *inherent*, but they're a lot easier to make a mistake which results in one. Your example of undergraduates wreaking havoc on the industry is right on, but if you think *those* undergraduates were bad, you should see the code they write in industry! But don't get me wrong; I like C, a lot. I just think that it's important to recognize that it's not the right tool for every job. - Dan C.