[comp.sys.mac] C vs. Pascal for the mac, vs C for MSDOS

tedj@hpcilzb.HP.COM (Ted Johnson) (01/21/88)

I talked to a THINK representative at MacWorld last Sat. about
a debugger for LSC and he said:

	(1)he couldn't give me a date for when the debugger
           would be out, but it would definitely be "before
           it gets cold again (in Massachusetts)".

	(2)the debugger will be in LSC 3.0.  This will be a
           MAJOR upgrade, so they will probably charge for
           it.  He couldn't give me any $ estimates though.

	(3)they're trying to make the debugger in LSC look
           similiar to the one in LSP.  From what I've heard
           of LSP, this seems to be a good idea.



	-Ted

garyb@hpmwtla.HP.COM (Gary Bringhurst) (02/02/88)

>
>C++ provides the sort of strong type checking and modularity
>that Pascal users appreciate so much - it has a notion of
>function prototypes very similar to those in ANSI C.
>In addition, it has the potential to avoid many of the
>problems with existing C implementations. My favorite C
>problem is implementing String255. In C++, a class can be
>defined with the same storage layout as the Pascal String,
>but all of the right semantic properties, and it doesn't
>take pointer magic or kludges or glue or any of the other
>evil stuff that gets in the way of good code.

I'm glad this got into the discussion.  C++ is obviously the language of
choice for real-world tasks _at this time_.  It addresses efficiency issues
with inline functions, and typechecking and other protective features via the
object-oriented extensions.  I heartily endorse the use of C++, until something
better comes along.

Gary Bringhurst

(My opinions are rarely, if ever, those of my employer)

shap@sfsup.UUCP (J.S.Shapiro) (02/06/88)

In article <2270004@hpmwtla.HP.COM>, garyb@hpmwtla.HP.COM (Gary Bringhurst) writes:
> ....  C++ is obviously the language of
> choice for real-world tasks _at this time_.  It addresses efficiency issues
> with inline functions, and typechecking and other protective features via the
> object-oriented extensions.  I heartily endorse the use of C++, until
> something better comes along.
> 
> Gary Bringhurst

At the risk of sounding like advertising, I have just finished a
(non Mac) large application written entirely in C++ (with the 
exception of the C library and another local utility library).
C++, once you warp your head so as to look at it correctly,
is an extremely powerful language, and for many problems, the
conceptions it forces the programmer to think in result in
smaller and faster code.

On the other side of the coin, there are some flaws that Bjarne
Stroustrop acknowledges are not straightforward to fix. Examples:

	Current version lacks an usable exception mechanism
		(setjmp doesn't work in C++ the way it does in C,
		because a stack-allocated object can create heap
		allocated objects in its constructor, and the
		longjump() doesn't let you destroy them properly.)
	
	Improper cleanup of tasks (my opinion - tasks should have
		separate heaps)
		
	Lack of graceful parameterized types. (Unless you use rather
		kludgey specially constructed macros, there is no
		way, for example, to write a generic binary tree
		class [i.e. type of tree-members not encapsulated
		in the definition of the tree] from which you could
		derive classes of specific trees)

In isolation each of these problems is straightforward. In combination
they are hard to solve well.

I think it is a very interesting question whether as PC's become
more powerful, it doesn't become very reasonable to run interpreted
garbage-collecting languages, or at least garbage collecting languages.
For those of you who will object that garbage collection takes time,
you are right, but current real-time garbage collection schemes take
a bit less than 10%, and I am think on a Mac II this might not be
a problem...

Jon

bayes@hpfcdc.HP.COM (Scott Bayes) (02/11/88)

>Actually, on the type-checking and modularity fronts, C++ is far and
>away superior to Pascal.  Especially the modularity part.  In capitol letters.

Could you provide some support for this statement? It's hard to believe
without some specifics, though it may well be true.

Scott:=Bayes
bayes@hpfclw