From mboxrd@z Thu Jan 1 00:00:00 1970 From: root To: 9fans@cse.psu.edu Subject: Re: [9fans] same functions everywhere Message-ID: <20030508182121.GA28503@littlegreenmen.armory.com> References: <6d1c7c5cd789aff4b0539ab9eed3c168@plan9.bell-labs.com> <200305081814.h48IEr525849@augusta.math.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305081814.h48IEr525849@augusta.math.psu.edu> User-Agent: Mutt/1.4.1i Date: Thu, 8 May 2003 11:21:21 -0700 Topicbox-Message-UUID: a506c29a-eacb-11e9-9e20-41e7f4b1d025 You guys are headed down the wrong track. The right way to program is with small modules written in several different languages which are meant for specific purposes. -Phil/CERisE On Thu, May 08, 2003 at 02:14:53PM -0400, Dan Cross wrote: > You totally missed my point. What I was trying to convey is that one > size doesn't fit all; there's no one single language for doing everything, > but people tend to take a language and stick to it like glue, no matter > that it might not be the best candidate for any given job. > > > > Sounds like a good candidate for writing in C++ or a similar language. > ^^^^^^^^^^^^^^^^^^^^^ > > > C isn't optimal for writing really big applications; it's great for > > > smaller things like utilities, text editors, systems software, etc. > > > But it's frankly inconvenient for building huge programs. It's just > > > too low-level. E.g., if I ever have to write another hashing function > > > to try and implement some sort of string-based lookup again, I'll > > > scream. > > > > All this and more can be said of C++. > > Perhaps. However, note that I said, ``or a similar language.'' C++ is > a contrived example. However, I don't need to add a string type or > exceptions to it, and the STL more or less eliminates the need to > write stuff like linked lists or growable arrays or generic dictionary > containers. That's a win if I want to get something done, and not > fiddle around with a lot of low-level details. From the sounds of Doug's > example, he had to do a lot of low-level wrangling. > > > > I don't understand why everyone feels the need to try and shoehorn > > > their favorite language into every conceivable problem domain. > > > > Because when you start out writing a program in one language, > > once you get a lot of code written it's costly to switch to another. > > Or maybe you want to use some outside libraries available only in C. > > Continuing the C++ example, C++ makes it very easy to call C code. In > fact, I'd go so far as to say that most languages one might seriously > consider for writing big applications do. > > > > C doesn't need a low-level string type, nor does it need exceptions; what > > > programmers who are looking for those things need to do is look for > > > another language. > > > > And what language is going to give it to them? C++? Ha. Ha ha ha. > > No, Limbo. > > C++ *does* give you a string type and exceptions. Is it suitable for > every job? No, but I never said it was. In fact, my point was that no > single language is. Once again, the use of C++ was a contrived example. > > > What happens when C++ is too low-level for the job at hand? It's not > > any more malleable than C is (though it is quite a bit more amorphous). > > So use something else. > > There are any number of languages available to fill all kinds of roles. > Use whatever fits. > > > I've been looking for another language for a few years now, and I > > don't see it. Would you have us not write programs because there's > > no good language to write them in? > > What part of what I wrote makes you think that's what I meant? > > > Claiming that the language designer will correctly anticipate the > > exact level of abstraction required for your huge program is ridiculous. > > I don't recall ever making that claim. Perhaps you can cite where I did. > > I do recall claiming that no one language is suitable for every > application domain, and that trying to shoehorn C into being so is a > mistake. > > > The programmer has to be able to build up abstractions as necessary. > > Agreed. > > > And you can do this in C as well as you can in any of the other languages > > commonly used for systems programming. > > Note that I mentioned ``applications programming,'' not just ``systems > programming.'' For systems programming, you're right. For applications > programming, you're not. > > > The only language that facilitates programmer-based extension > > outstandingly well is Lisp, but Lisp has other problems. > > That's subjective. I could argue that any number of functional > programming languages do just as good a job as Lisp in this arena. > > But hell, why don't we all just program in some kind of generic > assembly language? We can define a set of opcodes that map to useful > operations, and build a macro assembler that provides a generic string > type and exceptions. And why have a seperate shell language that we > write scripts in? Why not write everything as a C program? > > - Dan ``One size doesn't fit all'' C. >