C++ or (Smalltalk and C++)? 
Author Message
 C++ or (Smalltalk and C++)?

The subject says it all. We have to suggest programming languages
for an oo-development environment of a finance organisation.

The alternatives are:
1. C++
2. C++ and Smalltalk

There are a lot of COBOL-programmers and few experiences with oo.

Which alternative is the best? Do you have experiences with a
heterogenous environment like Smalltalk and C++?
Any comments will be greatly appreciated. Please email your answer.
Thanks in advance

Thomas
------------------------------------------------------------------------
Thomas Grotehen
IFI Uni Zuerich                        
Winterthurestr. 190            
CH-8057 Zuerich        
Tel.: +41-1-257-4337            
Fax:  +41-1-363-0035    

------------------------------------------------------------------------



Sun, 25 Aug 1996 21:57:29 GMT  
 C++ or (Smalltalk and C++)?

I have both worked with Smalltalk & C++. Maybe my experience can
help you a little bit.

Quote:
>The subject says it all. We have to suggest programming languages
>for an oo-development environment of a finance organisation.
>The alternatives are:
>1. C++
>2. C++ and Smalltalk

I would would not mix C++ and Smalltalk. Maybe you think you could
use Smalltalk as a frontend and C++ to do the fast computations, but
as far as I know, you have only the possibility to mix Smalltalk an C.
This should be no problem (extern "C" ....), but I think it is never
a good solution to mix an OO-with an non OO-language.
If you choose C++, you will also need:

        - a OO-method (for example Booch), or your cobol programmers
          will never programm OO
        - a "container" class library (for example Tools.h++, Booch
          components or another)
        - a GUI C++ library (or a GUI builder, where you won't need
          to touch the generated code...)
        - and two month of time, to teach everybody what OO means...

With Smalltalk you get all this (without the method) in one. And the
best: your cobol programmers will have to learn OO! In Smalltalk there
exist only objects. But your applications will need a lot of memory, run
slow and maybe one day you will have to switch to C++.

Please email me, if you have more questions.

        --Philipp

 ****************************************************************************

 Philipp Schneider                    |\/\/\/|
 Interkantonales Technikum Rapperswil |      |
 Rechenzentrum                        | (o)(o)
 Obertseestr.10                       c      _)
 CH-8640 Rapperswil                   | '___|

                                      |   /
                                      /____\
                                     /      \
 ****************************************************************************



Sun, 25 Aug 1996 23:35:13 GMT  
 C++ or (Smalltalk and C++)?

Quote:
> With Smalltalk you get all this (without the method) in one. And the
> best: your cobol programmers will have to learn OO! In Smalltalk there
> exist only objects. But your applications will need a lot of memory, run
> slow and maybe one day you will have to switch to C++.

Granted, the Smalltalk environment might actually need more memory than
a *small* C++ program. But once you start building large, complex
applications that becomes a negliable quantity. What I don't understand
is why ST is supposed to be slow? Modern Smalltalk system compile either
into pure machine code or fast intermediate code. And if that doesn't do
the trick, external C code can be linked in.

ciao (hristian

phone  +49 202/45 09 92
fax    +49 202/45 09 93
CIS    100330,263

## CrossPoint v2.92 ##



Tue, 27 Aug 1996 21:42:00 GMT  
 C++ or (Smalltalk and C++)?

Quote:
Swensson) writes:
> Your choice should really depend on the type of application you
> are developing. For rapid development and flexibility ST would be
> the choice. If you are developing an application that will not
> change much in the future and runtime speed/space is at premium
> you should opt for C++.

Yes, I agree.

But now, I'm in a dilemma.

The fact is that I don't like the idea to have two completely different  
languages to support the dual goals in a single system. The common execuse is  
that we should have different proper tools for different purposes. We even use  
asscembly to write machine-dependent part of an OS kernel; so why we cannot use  
different languages for different purposes? This is wrong. I do not have  
objection if we use different languages for separated things that have no need  
to TRANSFER among each other in the future.

What I like is to have the rapid development and flexibility of ST at  
development phase and have the effciency at the product finalization for many  
speed/space critical systems. The problem is that I cannot get both. I am not  
willing to sacrifice the rapidess in development with these application.

Let's consider an example. ObjectTime provides two different languages:  
SmallTalk-like RTL for rapid prototyping, and C++ for product development. But  
there is no way to translate the RTL into C++. They suggest that we use C++ as  
comments when we write programs in RTL for rapid prototyping, so that the  
MANUAL translation into C++ could become "easier".

Many object-oriented operating system uses two languages: a static langauge for  
writing kernel, and a dynamic script for application. Again, there is no way to  
translate a script into C++. If I am going to develop a new device driver, or  
new communication protocol that will be a part of the operating system kernal,  
there is nothing that can help me for a quick prototyping. Should I use the  
script first, and then translate it into C++ manually?

There is no existing language or design tool that can solve this conflict. I'm  
looking at a reasearch group interested in making a new language that can fill  
the gap between the dynamic and the static. Does anybody know?

David



Wed, 28 Aug 1996 00:41:21 GMT  
 C++ or (Smalltalk and C++)?

Quote:
>Many object-oriented operating system uses two languages: a static langauge for  
>writing kernel, and a dynamic script for application. Again, there is no way to  
>translate a script into C++. If I am going to develop a new device driver, or  
>new communication protocol that will be a part of the operating system kernal,  
>there is nothing that can help me for a quick prototyping. Should I use the  
>script first, and then translate it into C++ manually?
>There is no existing language or design tool that can solve this conflict. I'm  
>looking at a reasearch group interested in making a new language that can fill  
>the gap between the dynamic and the static. Does anybody know?
>David

Close but it might do: use one statically typed compiler languge
which also has an interpreter.  There are C interpreters around for free,
and the Sather system will have an interpreter (when 1.0 is released
someday for the past year and a half).  Interpreters for annoying
compiler languages still speed up development over compiling.

FTP to icsi-ftp.berkeley.edu to find the current Sather stuff.

--

Lance Norskog

Artisputtingtogether. Art  s th ow n  aw y.



Thu, 29 Aug 1996 09:48:43 GMT  
 C++ or (Smalltalk and C++)?
: Close but it might do: use one statically typed compiler languge
: which also has an interpreter.  

With ISE Eiffel's 'melting ice' incremental compiler-interpreter, the
turn around from change to executable system is seconds.

There really is no need to sacrifice the safety of static-typing just
because you're prototyping something.

Follow-ups redirected to comp.object only.

Regards
--

6 Spring View, Ossett, Yorkshire, WF5 0QB, UK

        ...Arrive without travelling, see all without looking...



Thu, 29 Aug 1996 18:47:17 GMT  
 C++ or (Smalltalk and C++)?

: >Many object-oriented operating system uses two languages: a static langauge for  
: >writing kernel, and a dynamic script for application. Again, there is no way to  
: >translate a script into C++. If I am going to develop a new device driver, or  
: >new communication protocol that will be a part of the operating system kernal,  
: >there is nothing that can help me for a quick prototyping. Should I use the  
: >script first, and then translate it into C++ manually?

: >There is no existing language or design tool that can solve this conflict. I'm  
: >looking at a reasearch group interested in making a new language that can fill  
: >the gap between the dynamic and the static. Does anybody know?

: >David

: Close but it might do: use one statically typed compiler languge
: which also has an interpreter.  There are C interpreters around for free,
: and the Sather system will have an interpreter (when 1.0 is released
: someday for the past year and a half).  Interpreters for annoying
: compiler languages still speed up development over compiling.

I don't think that's quite a language ability that the original poster
was interested in.

What about this low-level option.  To me it seems that statically typed
langauges can encompass dynamic ones but not the other way around.  In a
dynamic language you just don't specify all the things that you do in a
static language.  The compiler can't always figure it out of nothing.  (it
can see what you actually *do* in the present, but it can't see what you
intended for past, present and *future*).

So what's a difference between static and dynamic?  In a static language
you could always just declare types to be Eiffel's ANY.

But in a static language most calls will fail on ANY because it can't be
assured that the method exists for the particular run-time object.

In a dynamic language it will go ahead and try anyway and give a message
if it fails.  So why not allow that in a static langauge:

        object.method_call(arguments);  --- regular type-checked static call
        object?.method_call(arguments); -- "?." means *attempt* the call
                                        -- or raise an exception.

"?." is in analogy with "?=":  attempt a reverse-assignment.

So if you're programming "dynamically" you use "?.".  It might also
be useful to be "half-static":  you could declare variables to be of
some broad abstract type that was still narrower than ANY.

: Lance Norskog

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Fri, 30 Aug 1996 07:43:06 GMT  
 C++ or (Smalltalk and C++)?
: > With Smalltalk you get all this (without the method) in one. And the
: > best: your cobol programmers will have to learn OO! In Smalltalk there
: > exist only objects. But your applications will need a lot of memory, run
: > slow and maybe one day you will have to switch to C++.

: Granted, the Smalltalk environment might actually need more memory than
: a *small* C++ program. But once you start building large, complex
: applications that becomes a negliable quantity. What I don't understand
: is why ST is supposed to be slow? Modern Smalltalk system compile either
: into pure machine code or fast intermediate code. And if that doesn't do
: the trick, external C code can be linked in.

How about this:  In a statically typed language you are giving
more information to the compiler than in a dynamically typed language.

As in mathematics, the more narrow the assumptions, the more powerful the
possibilities.  With static typing the compiler can assume more and apply
more transformations to make fast code.

: ciao (hristian

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Fri, 30 Aug 1996 12:31:59 GMT  
 C++ or (Smalltalk and C++)?

Quote:


> : > With Smalltalk you get all this (without the method) in one. And the
> : > best: your cobol programmers will have to learn OO! In Smalltalk there

i would say all the cobol programmers should be fired and you should hire
college freshmen to learn smalltalk from the beginning. it is much much harder
for a cobol programmer to learn OOP than a person without any programming
experience.

Quote:
> : > exist only objects. But your applications will need a lot of memory, run
> : > slow and maybe one day you will have to switch to C++.

if you do it right, the runtime program written in smalltalk should not use
much more momery than the same thing in c++. and the development environment
use much much less memory than c++ environments. my symantec c++ (mac) use 4
meg minimum with TCL. i had to add it to 6 after adding a couple of classes.
than i need another 4 meg for Object Master which add smalltalk style browser
to c++. and compiling is really time-consuming on c++.

Quote:
> : Granted, the Smalltalk environment might actually need more memory than
> : a *small* C++ program. But once you start building large, complex
> : applications that becomes a negliable quantity. What I don't understand
> : is why ST is supposed to be slow? Modern Smalltalk system compile either
> : into pure machine code or fast intermediate code. And if that doesn't do
> : the trick, external C code can be linked in.

> How about this:  In a statically typed language you are giving
> more information to the compiler than in a dynamically typed language.

this is true. however, if you write real OOP code, with function overloading,
inheritance, polymorphism.....C++ LOSS the advantage pretty quickly. indeed,
there is a FAQ file downloadable on certain FTPs, in which some people compare
smalltalk and c++ in real life applications, and the finding is c++ is only
_marginal_ faster (executable) and need 3 to 5 as much time to develop.
wa

Quote:
> As in mathematics, the more narrow the assumptions, the more powerful the
> possibilities.  With static typing the compiler can assume more and apply
> more transformations to make fast code.

i learned c++ first and truely loved it (bedfore  that, i am a c programmer).
however, after learning smalltalk, c++ looks like typical computer nerd's thing
-doing less in more code with more bugs.

-john

Quote:
> : ciao (hristian

> --

> -Institute for Nonlinear Science, University of California, San Diego
> -*** AD: Archive for nonlinear dynamics papers & programs: FTP to
> -***     lyapunov.ucsd.edu, username "anonymous".



Fri, 30 Aug 1996 05:16:28 GMT  
 C++ or (Smalltalk and C++)?
yeah, fire all the cobol programmers. And while you're at it, fire everyone
who thinks the best means to new means is to destroy people's lives.

I'd rather see every OO language suddenly disappear than use them as
justification, UP FRONT NO LESS, for terminating heretofore useful and
responsible employees.

My suggestion to an author from a .EDU site is "stay in school buddy. Its the
only place where you understand learning."



Fri, 30 Aug 1996 16:30:00 GMT  
 C++ or (Smalltalk and C++)?
C can be linked to C++ as well.

It still comes down to "getting over the OO hurdle" and picking the right tools
to get the job done.  I hope no one is starting to assert that either ST or C++
is THE language for every task.  Any good architect will be able to pose a
problem space where one or the other is better suited.

--------------------------------------------------
Randy Volters
AT&T Global Information Solutions; 3245 Platt Springs Rd. W. Cola. SC 29170



Fri, 30 Aug 1996 21:39:52 GMT  
 C++ or (Smalltalk and C++)?


Quote:
> i would say all the cobol programmers should be fired and you should hire
> college freshmen to learn smalltalk from the beginning. it is much much harder
> for a cobol programmer to learn OOP than a person without any programming
> experience.

Do you base this on any empirical knowledge? The only study I have seen
on this came to the opposite conclusion. See OPPSLA 92 procedings.

_____________________________

Niklas Bjornerstedt      tel: +46-8-80 97 00 fax: +46-8-26 04 76

Gustavslundsv. 151 G
S-161 36 Bromma
Sweden



Fri, 30 Aug 1996 23:53:16 GMT  
 
 [ 36 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. C++ or (Smalltalk and C++)?

2. C++ or (Smalltalk and C++)? Experience added

3. C++ question for Smalltalk/C++ programmers

4. C++/Smalltalk differences and keys to learning C++

5. Smalltalk to C and/or Smalltalk to C++

6. Smalltalk Manifesto Update - future of Smalltalk, C++, Java

7. NYC C++ mtg 9/7/95 Building a C++ Class Library

8. to CS: or not to CS: in F-PC assembler

9. Cellular automata benchmarks: Java vs C++ vs Java vs C++

10. Request advice about C++ and Visual C++ topics

11. Migrating from UNIX C++ to MVS C++

12. Translations from Scheme to C++ as aid to teaching C++ after Scheme

 

 
Powered by phpBB® Forum Software