Newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.cobol,comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!gatech!howland.reston.ans.net!xlink.net!slsv6bt!news
From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: C++ not OOP? (Was: Language Efficiency
In-Reply-To: gclements@keps.com's message of Thu, 18 May 1995 07:59:42 -0500
Message-ID: <KANZE.95May19121658@slsvhdt.lts.sel.alcatel.de>
Lines: 69
Sender: news@lts.sel.alcatel.de
Organization: SEL
References: <dewar.797512974@gnat> <3mbmd5$s06@icebox.mfltd.co.uk>
	<3n8jdv$jer@watnews1.watson.ibm.com> <3n8rjd$90a@disunms.epfl.ch>
	<19950421T230840Z.enag@naggum.no>
	<rshapiro-1305951849430001@ipa.bbn.com>
	<GIROD.95May15105836@dshp01.trs.ntc.nokia.com>
	<rshapiro-1605952054040001@ipa.bbn.com>
	<1995May17.175411.9737@rcmcon.com>
	<gclements-1805950759420001@155.50.21.58>
Date: 19 May 1995 10:16:57 GMT
Xref: glinda.oz.cs.cmu.edu comp.object:31102 comp.lang.c++:128986 comp.lang.ada:30070 comp.lang.cobol:3370 comp.lang.clos:2939

In article <gclements-1805950759420001@155.50.21.58>
gclements@keps.com (Geoffrey Clements) writes:

|> In article <1995May17.175411.9737@rcmcon.com>, rmartin@rcmcon.com (Robert
|> Martin) wrote:

|> > rshapiro@bbn.com (R Shapiro) writes:
|> > 
|> > >In article <GIROD.95May15105836@dshp01.trs.ntc.nokia.com>, Marc Girod
|> > ><girod@trshp.trs.ntc.nokia.com> wrote:
|> > >>Static typing provides with something very valuable too, even for
|> > >>rapid prototyping
|> > 
|> > >Explain to me how any C++ environment could possibly support rapid
|> > >prototyping without dynamic, incremental compilation at the function/class
|> > >level. Static typing is irrelevant. The problems are (1) the edit-cycle
|> > >time in C++ gets way too long as soon as your system gets bigger than a
|> > >toy; and (2) the language doesn't support debug-time code change and
|> > >recovery. In both dimensions, C++ stands in sharp contrast to Lisp,
|> > >Smalltalk and probably Dylan.
|> > 
|> > C++ neither allows nor disallows incremental compilation.  

|> I have been thinking about this for the last couple of days. The main
|> difficulty in creating a dynamic, incremental environment is C/C++'s UNIX
|> background. When a programmer sits down to write C/C++ code he expects to
|> use emacs to edit his files, make to build his project, cc to compile his
|> files and link to create executables. These are all separate tools that
|> read and emit a stream of bytes. There is no integration between the
|> parts. Once the tool is finished there is no remembered state. UNIS loves
|> separate little tools for every little operation.

I don't buy this.  Everyone I know uses make, e.g.: edit, make, run.
Replace make with an intelligent incremental compiler system, and I
don't think you will have any resistance.

|> I asked myself what would it take to create a dynamic C or C++ development
|> environment. The main stumbling block is an environment that can remeber
|> the state of all code compiled up to the current time including what file
|> that code came out of so that the static keyword could be honored. This is
|> just a Lisp environment that uses a C/C++ compiler rather than a Lisp
|> compiler. I'm no language development expert but I don't think it would be
|> that hard. Although the macro sytem will probaly screw things up. If you
|> redefine a macro you would have to recompile everything.

This is the real problem.  C/C++ use textual inclusion of the source
as its means of separate compilation; formally, you have one copy of
the declaration for each compilation unit.  It is non-trivial to
decide which copies are (should be) the same, and which really are
different things.

|> B-( Maybe The
|> Right Thing to do would be to replace the C/C++ macro sytem with one like
|> Lisp has. Call it an extension. This would break most people's existing
|> code. And would probably keep most companies from switching to the new
|> environment.

|> Would you use such an environment? I think most people would say yes.
|> Especially people who have used a good dynamic development environment in
|> the past. Now ask your manager if he would pay to convert all his current
|> projects over to an environment like this. I think most would say no, even
|> though it might be beneficial in the long run.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung


