[ruby-talk:26543] Re: Table: Ruby versus Smalltalk, Objective-C, C++, Java;

"Thomas Gagne" <[e-mail]> wrote in message
news:[e-mail]...
> David, your table seems to mix language features with library features.

As to library features, as I have been so recently told (of late) in
SmallScript feedback, quite a number of people take the strong [and, in my
opinion, partially correct] view that libraries and tools are a key part of
the collective elements that form a (dynamic) language. I.e., historically
in most dynamic language systems the frameworks and IDE were an integral
element and play a key role in the development process and thereby define
the language and its capabilities/productivity for its users.

>
> Native Threads - isn't this an implementation issue?  Doesn't Smalltalk MT
use
> native threads?  I personally believe this is a ding against VW.

Keep in mind that I extended a chart I obtained from the Ruby comunity.
Second, and perhaps more importantly, the Smalltalk column is for
"Smalltalk-80" [you know, the way the language was 20 years ago when many of
these other languages did not exist or were mere shadows of their
capabilities today].

The chart does not [by intention] have a column for the ANSI Standard
"Smalltalk-98", which to my view, was less of a standard than one would have
liked in terms of unifying and strengthening the language. Which is another
way of saying that, like scheme and its many dialects, Smalltalk dialects
are individually very strong in some (but not all) key areas and they have
great [mature] facilities, but the language itself cannot claim many of
those elements as being "standard".

In the world of components, scripting, and server systems built on them, the
ability to run the entire execution architecture as plug-in component and
integrate with native threading models is very important. It is a challenge
that classic Smalltalk-80 does not adequately address; various dialects
including VW have made great strides in this area but we're still not on the
leading edge of this curve.

>
> Foreign Function Interface - ST/X does a nice job of this.  Heck, you can
> write C code inside methods!  Is it necessary for a language to define how
it
> interacts with the stacks of other languages and their runtime
environments?
> Is it C's responsibility to know how to interface with Fortran, or is the
fact
> that some vendor's implementations of both languages' runtime environments
> share common stack rules?

Don't confuse the Smalltalk-80 chart capabilities. Again, various dialects
do this to a lesser or greater degree. QKS Smalltalk had this feature from
day-1 when it went into the first users hands 1992. Smalltalk MT has pretty
transparent facilities for COM-ActiveX, Dolphin looks to have even better
facilities. The problem is that these things are dialect specific; which is
why I did not add a Smalltalk-98 column -- I could not say much about how it
is different from Smalltalk-80 so it is better to stick with leaving the
Smalltalk-80 column -- and let SmallScript (a dialect of Smalltalk-98)
stand-in as the placeholder promoting Smalltalk today since it can answer
almost every question with a solid/good response.

SmallScript's Smalltalk facilities provide inline C/C++/Assembly directly
with no special locking, dereferencing, etc. And it also allows direct cut
and paste of enums, #defines, and VB/JScript/C++ function/method
invocations; as well as direct access to all functions in a DLL merely for
dynamically declaring the dll name in a class/namespace. It doesn't really
get much better than that.

>
> Where is support for blocks?  How many languages support that?  It's
certainly
> a useful language feature.

Blocks are a form [the Smalltalk name for the general concepts] of "closures
and continuations".

>
> Should Value Types be a native language feature?  ST/X creates structs
quite
> nicely using ByteArray with great accessors code.  I've done a similar
thing
> in VW.  Does it have to be a language feature?  Must a language define
every
> stinking thing a programmer might do, or should that be the responsibility
of
> standard library features?  C doesn't define a GUI interface, and neither
> should *any* language if you ask me.  GUIs exist only in an environment
that
> includes them, and languages must exist without them.  All they need is a
> compiler/interpreter.  Access to GUIs, relational databases, HTTP, SMTP,
etc.
> are library problems, not language problems.

Again, don't confuse Smalltalk-80 with current dialects. I put SmallScript
in as the "stand-in" for modern Smalltalks because none of these things is
covered "standardly/uniformly" in Smalltalk today.

Dealing with structs is obviously important and it should be easy to do.
This area is essential for broad/general interop within a multi-language
platform like .NET. It is an area that most scripting languages (and dynamic
languages) handle quite poorly because they typically lack notions of
declarative (optional) typing.

>
> Certificate and Security mechanisms - I guess I need an explanation on
that.
> On my computer (at least) security is the responsibility of the operating
> system.  It's responsbile for making sure people only have access to what
> they're supposed to regardless what language a program was written in.  In
the
> database world my database keeps track of who's allowed to do what
regardless
> of what language is used.  Why should this be a language feature?  How
would
> such a language features be useful if not supported/implemented by other
other
> languages used on the same machine/environment?

I'm sorry to punt but there are plenty of resources on the web and elsewhere
to learn and read about the rationale for and intent behind
certificates/digital-signatures.

>
> Isn't RegEX supported in a VW parcel?  Why would that be a language
feature?
> How big a book do you want to write to teach people how to use a language?
> Would a student need to read a chapter that includes discussion on
> startup/compile/execute/shutdown speed?  How about a chapter on the
language's
> deployment footprint?  Should .net languages include the entirety of
Windows
> as part of their footprint?

Hmm. Scripting languages (Perl, Python, Ruby, to name a few) have an
enormous user base [and each is individually much more successful and
growing than Smalltalk or say Scheme had been in recent years]. Those
languages have, perhaps, four or five major characteristics (almost all of
which classic Smalltalk lacks). One of those characteristics is their
specific capabilities for processing text and that is largely tied to their
integration of RegEx facilities into the language. I suggest you look at
some of these languages, how they are being used, and their level of success
and popularity. I think that you'll find answers to the kind of questions
you are raising here.

>
> I appreciate everything you've done for Smalltalk, but your table is more
> propaganda than anything.  Maybe you'd rather build a chart comparing
> Smallscript to specific language environments from specific vendors.  If
you
> want to include the features vendors choose to include/exclude then your
chart
> would make more sense.
>

I'm sorry you feel that way. I think you are focusing, on me, your
frustration with Smalltalk-80 and the negative legacy it has cast over
smalltalk implementations today. However, I can assure you that the
frustration and pain I've felt about that legacy is far, far greater than
yours -- it played significant role in hurting business opportunities for
QKS/SmalltalkAgents and has consistently guided my professional focus over
the last ten years -- ultimately it is what led me to start over and build
SmallScript from scratch. My chart is, honestly, a mere shadow of the weak
items said about Smalltalk-80 in almost every other chart I've seen on the
web, or published in books and magazines.

The problem here is that we cannot make a chart with the title
"Smalltalk-98" and put all this stuff down as "standard"; in that light we
are better off leaving a column on what we had 20 years ago [when most of
the other languages didn't exist or were mere shadows of where they are
today]; and then skirting the issue by hiliting what an implementation of
Smalltalk-2001 can do today [especially since, in comparison to other
scripting languages, it has excellent answers to the requisite feature
comparison items -- since addressing those items were a fundamental part of
its design goals]. This also makes more sense, because SmallScript is not
just a Smalltalk implementation; it is also a new language and includes an
execution architecture that was designed to support (compile/run) multiple
dynamic (incl scripting) languages.

Somehow you sound like your suggesting that I should load the chart up with
each of the Smalltalk dialects, or I should remove the Smalltalk-80 column.
Loading a chart with all the current dialects would be innapropriate since
that is not done for the other languages. Removing Smalltalk-80 would also
have negative ramifications since it would: (a) not stand to correct the
fairly grievous wrongs in other Smalltalk-80 charts; (b) it would
underscore/mislead readers into thinking that SmallScript represented the
entire category of "Smalltalk" when it is in fact, merely a dialect which
has numerous features not found in other dialects.

Before you beat SmallScript up and tout the capabilities of Smalltalk by
telling me that dialect-a has feature-1 and dialect-b has feature-2; take a
look at SmallScript which as a single dialect has each of those features
[which is really the point]. AND, I want to be very clear, the chart came
from the scripting language world where programmers were comparing features
relevant to the scripting and component based software development process.
There are many "development process" features, which are common to most
Smalltalk implementations, which SmallScript in its basic/core form
(currently) does not provide [by intention]. Which is another way of saying
that SmallScript is by no means the best full featured Smalltalk [actually
it is far from it -- and it is a work in progress]; I would have said the
strongest players in this space on a user-base, feature-set,
commercial-level were Cincom VW, IBM VA, Dolphin ST, etc.

OTOH, rather than criticizing my efforts to "correct" and "update" the world
on where Smalltalk (collectively) stands, you could create a chart comparing
all the Smalltalk dialects using my suggested rows [and add your own]. I
would be more than happy to either put the chart on my site or to make a
link to it.

If you want to criticize, I encourage it. But at least sign up to explore
the SmallScript seed so that the criticism will be focused and hit home in
places that are under my control [I am not responsible for the larger world
view of Smalltalk-80 (and the muddled view it casts over Smalltalk today)].

Alternatively, you could sit down and write a book on Smalltalk-98 or
Smalltalk-2001 which would finally result in the academics and other
language folks revising all their books and charts to get rid of the bloody
irritating smalltalk-80 comparisons. I've wanted to do that for a long time
now, but since I cannot write a good collective work about a Smalltalk
standard [other than ANSI-98 which as I've alluded to, would probably do
more harm than good since its been 18 years since the 80 standard and based
on the ANSI standard vis-a-vis what is relevant in these other modern net
enabled languages we could not say competively strong things], I'm settling
for the much harder process of creating a new language which is a superset
of Smalltalk, and then working to make it freely available and looking
forward to publishing a definitive book called SmallScript-2002.

-- Dave S.

>
> --
> .tom
>