LANDON@ENR.Prime.COM (08/25/89)
/* Written 4:24 pm Aug 24, 1989 by jonnyg@umd5.UUCP in ENR:comp.windows.ms */ /* ---------- "C_Talk review and final review if C" ---------- */ >First of all I finished reviewing CommonView C++. I found it to >be mostly broken. You better come clean, because this statement has no credibility. I've been working with CommonView since its release, and while I've had my frustrations, it's been due to "user error" in most cases. There are bugs but they are being nailed expeditiously. You need to tell the net what your review consisted of and define what you mean by mostly broken. I haven't found this to be the case at all. You need to specify your CommonView release, memory configuration, whether you reviewed the Windows or PM libraries. What in the world did you do to review it? By what standards did you measure it? >The class library is realy bad Compared to what? SmallTalk? Give it a break - it's a new product and has growing pains like anything else. Glockenspiel is cranking and has been diligent in updates. Just the help CommonView is to memory management under Windows is worth the price of the package. >and the examples won't hold water. Your statements don't hold water when you don't back them up. Tell the net exactly what you are talking about and maybe your statements will be credible. >I saw a lot of promises in the read.me's that say so much will >happen in such a short time that I beleive none of it will happen. Glockenspiel has their work cut out for them, but their efforts can only help us as developers, so why the nay-say? Time will tell - what you believe at this point won't slow them down or speed them up. >Now that I fully understand C++ I feel C++ is to OOPS as COBOL is to >stuctured programming! C++ may be an OOPS but it is not a very good one. Since you fully understand C++ I'm sure Bjarne could use some help as could many of the contributors to comp.lang.c++. Your myopic view of C++ will cost your employer dearly. For being such an impotent OOP language it sure has a lot of you guys scared.
jonnyg@umd5.umd.edu (Jon Greenblatt) (08/25/89)
In article <237700003@ENR.Prime.COM> LANDON@ENR.Prime.COM writes: > >/* Written 4:24 pm Aug 24, 1989 by jonnyg@umd5.UUCP in ENR:comp.windows.ms */ >/* ---------- "C_Talk review and final review if C" ---------- */ > >>First of all I finished reviewing CommonView C++. I found it to >>be mostly broken. > >You better come clean, because this statement has no credibility. I've >been working with CommonView since its release, and while I've had my >frustrations, it's been due to "user error" in most cases. There are bugs [ REMOVE FOOT FROM MOUTH... ] I guess I should come clean. I never said the compiler was broken. The compiler is great. My frustrations have been with the fact I need a certian minimum functionality and CommonView is too new to supply it without writing it myself. The memory management hacks do work nicely into media independent databases but I would still not like to be painfuly reminded about this when I try to use them, maybe getting used to them would help. I feel bad that I have shown too much bias against Glockenspiel C++. Like I say the compiler is nice! The class library lacks what I need as a windows programmer but maybe I am biased by the types of apps I need to write. The work I do is best done in a highly virtual environment with garbage collection. If lisp were an assembly language instead of an interpreter I guess I would have it made. In summary, please excuse me for venting my frustrations on the net. I knew if I were realy off base someone would correct me. What I need now is a fast OOPS with garbage collection, virtual operators, and a decent syntax. Maybe I should take up compiler writing! Switching heaps, and object construction/destruction based on scope are good Ideas, I guess I want more! I think it would be nice if a compiled language could keep tract of all pointers and be able to traverse links based on data type, a garbage collection scheem could then be worked into this. I guess I can dream at least.... C_Talk has it's own version of overloading. It's a hack that requires you to name each parameter as you pass it to the message dispatcher. I prefer the C++ method of function/operator overloading. The C_Talk environment is fairly straight forward and easy to use. There are a lot of benifits to this but there are also losses due to this simplicity. The class library in C_Talk is based around windows and has been from the start. I am still frustrated however. I have been dealing with interpreted environments for some time now (Actor/Lisp-OOPS) and its hard to get back into the restrictions compilers force on you. Any compiler writers out there willing to work with me on this? Maybe I could eek up my Idea environment using yacc, then I would show you all!!! Aren't nets nice, you can make a fool out of youself and you can almost fool yourself into thinking no body even notices. JonnyG.
patrickd@chinet.chi.il.us (Patrick Deupree) (08/28/89)
In article <5270@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: >I have been dealing with interpreted environments >for some time now (Actor/Lisp-OOPS) and its hard to get back into the >restrictions compilers force on you. I would like to clear up a misconception that this previous posting may have caused. Actor is half compiled, half interpreted code that runs much more efficiently. Basically, Actor itself is written in Assembly code. When a program is written in Actor (or shall I say a method) that method is compiled into threaded code. That threaded code is then run through the interpreter. After having used man interpreted languages in my day (everything from Basic to Prolog on a Unix system) I can safely say that Actor runs a damn sight better than I thought it would when I started using it. A lot of the "slowness" involved is due to the GUI (in our case this is only Windows at the moment, but the Mac windows and X-Windows would probably pose the same problems). -- "I place my faith in fools. Self confidence, my friends call it." -Edgar Allen Poe Patrick Deupree -> patrickd@chinet.chi.il.us