[Prev][Next][Index][Thread]

Re: A question

Michael T. Richter <mtr@ottawa.com> wrote in message
news:orMe4.418$yO2.447@198.235.216.4...
> Stephen J. Guthrie <steve.guthrie@mantissa.com> wrote in message
> IIJe4.12685$Ce.290611@monger.newsread.com">news:IIJe4.12685$Ce.290611@monger.newsread.com...
> > OK, I'll give you the closed, Smalltalk-centric  world.  What makes
> > this less of a choice than the closed, Dylan-centric world.
>
> I'm currently writing most of my personal software in Dylan.  Dylan lacks
> certain features I need, so I enhance it by embedding a Lua interpreter in
> my software.  This is made possible because of the C-FFI (C language
foreign
> function interface) that my Harlequin (now Functional Objects) Dylan
> environment provides.

All of the commercial Smalltalk environments I have used provide excellent
C-language interoperability. You can write primitives in C and link them
into your Smalltalk environment or you can call C code that has been
compiled into DLLs. You can also use COM, CORBA, DDE or just about anything
else you can imagine.

> Over and above this embedding of other languages (through external C
> libraries), I also have the capacity to use COM and CORBA interfaces
> provided by third-party vendors, a capacity which I routinely use.

This is easily and routinely available in the Smalltalk world as well.

> This means I can use my Dylan software to drive word processors,
spreadsheets,
> databases, etc.

Ditto in Smalltalk.

> Indeed I can, using either ODBC or the COM database API,
> back-end any of my applications with any database which provides an ODBC
or
> COM-DB service provider -- most DBMS systems, in other words.

Ditto in Smalltalk.

> I've never seen a Smalltalk environment which didn't basically assume that
> the outside world doesn't exist.

Well, that begs the obvious question of which ones you have seen (and when
did you see them)? Based upon your obvious misconceptions, my guess is that
you have not "seen" any of the modern commercial dialects of Smalltalk (of
which there are at least half a dozen available).

> Most have some kind of mechanism for specifying interaction
> with the outside world, but ultimately they're so painful to use
> and so difficult to hammer into shape that it isn't worth
> even starting.

I couldn't disagree more. Pure unadulterated FUD.

> This means that, ultimately, whatever services your Smalltalk
> environment provides are the *only* services you can reasonably
> use.

Not even remotely true. More FUD.

> You need to interface with a particular database vendor's
> product? Tough.

Nope. Easy.

> They only provide an ODBC/OLEDB interface.

You can easily use their native libraries as well.

> You want to embed a powerful textual pattern matching library in
> your application?  Oh well, you'll have to hack one up yourself.

Nope. Assuming this library exists as a DLL, you would have no problem
accessing it from Smalltalk.

> You want to use a huge, extremely fast graphics library?

Also very easy to do in Smalltalk (and has been done many times in the
past).

> You know the drill already.  You might as well just give
> up.

Uh, huh. Pretty easy to say that when you obviously haven't tried any of
things you claim can't be done.

If you're going to answer Stephen's question, why not just focus on what
makes Dylan nice (and it is a very nice language indeed) rather than making
up FUD about Smalltalk?

-Eric
References: