|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Victor Metelitsa 2:5020/400 21 Mar 2001 15:09:17
To : All
Subject : "íÒÕÆÕÞÊÝÌÞÚ ÐHÂÉÞ ÃÏÅÌÕÚ" HÄÌHÖH ÕÃ ÉÏÑÎÌÅÈÜÕÓ ÎÏHÕÃÁHÄÕÐÅÊÅÈ ST [Re:C
--------------------------------------------------------------------------------
[Re:Choice]
[http://www.cincomsmalltalk.com:8080/CincomSmalltalkWiki/Why+Smalltalk%3F]
Why Smalltalk?
Why Smalltalk rather than, for example, C++ or Java? The simple answer
is that a good Smalltalker is more productive and writes better quality
code than a C++ or Java programmer with similar experience. Research
shows that Smalltalk programmers solve a given problem quicker and end
up writing less code (typically 1/2 û 1/3 of a C++/Java programmer) -
and with fewer bugs. While implementing the same functionality, a Java
developer will create three times as many bugs as a Smalltalk developer
û a C++ developer will create six times as many . Fewer bugs means
spending less time trying to fix bugs. Fewer bugs means less code to be
maintained later. See Linea Engineering Research
[http://www.lineaengineering.com/Resources/Productivity_/productivity_.html]
for the paper.
Smalltalk is a very simple language to learn (only 5 reserved words!)
because it is one of the most consistent languages around; in Smalltalk
everything is an object. This is particularly important if you want to
move legacy programmers to the object-oriented world. Apart from the
transition to the OO world, if they do not have a Unix/C background,
they have to learn the C syntax that Java and C++ are based on, as well
as coming to grips with OO thinking. In Smalltalk they will not be
confused by Java²s and C++²s hybrid development model. In C++ and Java
you have primitive data types and objects that behave differently (a
primitive data type will not understand if you try to send it a
message). In Smalltalk everything is consistent, everything is an object
- and consistency aids learning by shortening the learning curve. In
Smalltalk you do not worry about pointers or memory management since
this is taken care of by the garbage collector.
Smalltalk is a dynamically typed language and as such you will sometimes
hear the argument that static typing (as in C++ or Java) is better at
catching type errors. You will sometimes hear that a dynamically typed
system (like Smalltalk) will not catch errors when you compile your
code. Theoretically there is some truth to this, but as the figures in
'What about Static Typing?'
[http://www.cincomsmalltalk.com:8080/CincomSmalltalkWiki/What+about+Static+Typin
g%3F]
show, in practice this is not actually the case. This is so because a
Smalltalk developer concentrates on solving business problems, while the
C++ or Java developer spends much more time on technical implementation
details - details that are not directly connected to the business
problem that needs to be solved. There are also circumstances where a
statically typed compiler will miss type errors, making the code
correspondingly more difficult to debug. In Smalltalk any problems due
to a type error (or any other bug) will land you in a debugger (rather
than crash your program) that will immediately allow you to trace the
call stack, find the problem, correct the mistake and continue executing
the program! This is true whether one is developing an client/server
application or a distributed internet application. This can also be true
with production environments; there is no need to take a Smalltalk
server down in order to patch it.
Refactoring is also far easier in Smalltalk. Lets say you wish to do
some prototype refactoring where you make sweeping changes in some
section of your application. In Smalltalk you can make dramatic changes
and then exercise just the section of interest, whereas in Java you will
have to propagate the static type changes throughout the entire program
before you can even test the section you are interested in. The amount
of time spent modifying interface definitions, static types, return
types, and assorted casts make refactoring Java lengthy and error prone.
Since the goal of refactoring is to make the internal structure of the
software easier to understand and cheaper to modify without changing its
observable behavior, this has a direct cost in the maintenance cycle of
the product. We have reports from the field that Smalltalk breaks the
80/20 rule (80% of your cost is in maintenance, and 20% is in the
initial development). One example was a product with
~2000 classes being maintained by a single developer, who also had
responsibility for adding new functionality and web enablement.
A big argument that Java advocates use to promote Java is the
portability between various platforms. This is theoretically correct,
but currently there are numerous different JVM²s (made by different
vendors) that are not 100% compatible. This makes it difficult to write
Java code that is truly portable. This is not a problem with the
VisualWorks VM²s. A VisualWorks image will run on any of the supported
platforms without any modification to the Smalltalk code (unless it has
been created with platform specific extensions, e.g. wrapping of DLL²s
on a Windows platform, but this is an issue with Java as well). Another
problem with Java today is that it is very much a moving target. The
Java specifications keep changing while with Smalltalk you have a mature
language that includes all of Java²s virtues (and more). It is not
uncommon for large Java projects to have to work with more than one
version of Java because the functionalities they need are not available
at the same release.
Unlike Java, VisualWorks Smalltalk allows the developer to tune the size
of all the memory zones in the virtual machine as well as deciding on
the best garbage collection strategy to get the best performance out of
a system (in a standard Java virtual machine a developer can only set
the minimum and maximum size of the memory used). This also means that a
Smalltalk system scales better than the equivalent Java system.
With VisualWorks Smalltalk you also get a Smalltalk plugin for your
browser that will allow you to run VisualWorks Smalltalk within a
browser - see "Why is VW better than Java"
[http://www.cincomsmalltalk.com/vwisbetter.html]?. It has the added
bonus of not running in the browser's address space, thus making it
immune to any stability problems the browser might have. There is also a
framework for digital signatures so that you can make sure you can trust
the application you want to run. The biggest advantage of using the VW
plugin over a Java applet is that Smalltalk applets do not require any
special construction techniques compared to a normal client application
(a Java applet has to be constructed differently from a Java client
application). This means that you can create a Smalltalk applet from an
existing application (why waste time building something new if you
already have it?) or move an applet off the browser. Since the Smalltalk
applet does not run within a sandbox, there is no extra work involved
if you want to use the same application as both a web based application
and a normal client application.
To summarize, Smalltalk is a simpler, more effectively portable system
than is available elsewhere. Don't believe it? Just download it yourself
and try it out. Visit the Cincom Smalltalk Home Page
[http://www.cincom.com/smalltalk] and see for yourself.
Questions? Send feedback to the Cincom Smalltalk Product Manager
--- ifmail v.2.15dev5
* Origin: CSSC of TAT (2:5020/400)
Âåðíóòüñÿ ê ñïèñêó òåì, ñîðòèðîâàííûõ ïî: âîçðàñòàíèå äàòû óìåíüøåíèå äàòû òåìà àâòîð
|
