*** ObjTcl is a MUST TRY! ***
Hadar Pedhazur
There are a number of reasons for that, but that might be the subject
for another post ...
Anyway, for the past year I have been Beta Testing Objective-Tcl
(ObjTcl) from TipTop Software, in its various incarnations. Due to my
complete belief in the honor code of non-disclosure, I was not able to
share my thoughts on this product with *anybody* for the entire year
:-(. Now that it has been officially released, I would like to make
some very strong statements about this product. I am *not* affiliated
with TipTop Software in *any* way, and in fact, have never even spoken
to Pedja Bogdonavich other than via 100's (if not 1000's) of emails. I
am also an extremely happy customer of their TipTop (modem and
terminal) product.
To my mind, this is the single most important advancement to the
development process on NEXTSTEP (NS) since the MiscKit (MK). The MK
was (and is) fantastic on many levels, possibly the most important one
being the standardization of many very common tasks, e.g.
multi-windowed doc management (actually thanks to Mike Ferris and
MOKit for this abstraction). As wonderful as MK is, it is really
mostly a major (really major!) time saver, rather than a new paradigm
for developing software on NS.
ObjTcl is (or certainly can be if we use it creatively!) a new
paradigm for creating software on NS. For those who missed the
announcement, most briefly, ObjTcl is both a full blown Objective-C
(ObjC) style interpreter, and, an embeddable interpreter (within ObjC
programs) which allows 100% transparency between ObjC and ObjTcl via
the ObjC runtime. In other words, one can not tell whether classes,
methods, etc., are written in ObjC or ObjTcl.
I believe that it is a paradigm shift for NS developers, and as such,
a very few will see it and instantly think "Unbelievable, I can think
of 100's of things I can use this for ...", while most will think
"Cute, an interpreter ... now let's get back to work!". I mean no
disrespect to the second group of folks in making that statement. I
think that most of us are busy trying to get our jobs done, and if a
new "tool" does not strike us as immediately useful in our current
assignment, we tend to dismiss it. This is natural. This is why I am
taking the time to expound upon some of the virtues of ObjTcl, so that
some of you (hopefully more than just some :-)) will stop and take a
little more time to look at it than you might have otherwise.
First, let's start out with the licensing. The package (unlicensed)
will allow you to do everything you could do with a licensed version,
though it might get annoying (with prompts and reminders, etc.) after
a while. This, therefore, leaves no one with an excuse for not trying
it out (except for the other excuses that is :-)).
OK, Hadar, enough *background*, what's so special about it? Well, I
mentioned two strong points above (there are more, like IB
integration, etc., but let's ignore them for this post!!!), and I will
deal with them each in turn.
1) An ObjC style interpreter.
What I mean by "ObjC style" is that it is not 100% the same syntax as
ObjC, though there are tremendous similarities. It would have been
nice to have the syntax be identical, but the fact that the
interpreter is TCL, actually gives it enough advantages over normal
ObjC stuff, that net net, I really think that the advantages outweigh
the disadvantage of having a slightly different syntax.
First, a trivial example, then a slightly more interesting one:
a) Here's a simple session from the objtclsh (command line ObjTcl
shell). It is a little long, and I don't want to interrupt the flow
with commentary, so I will make a few comments *now* and you can
follow along below. First, I create a new instance of Object. I then
ask that instance if it is a kind of Object (and it responds TRUE). I ask
it if it is a kind of Window, and it responds FALSE. I then ask it if
it is a kind of Hadar, and the debugger intercepts, telling me that
there is no class with the name Hadar defined, and it gives me a
chance to CORRECT that problem right now. I choose not to, so I
continue, and the error is returned to me. (You can enable or disable
debugging.) I then CREATE the definition of a class Hadar
interactively, with one instance variable, and two methods. I then ask
again if the instance of Object is a kind of Hadar, and this time,
instead of being an error, the answer is simply FALSE. Lastly, I
instantiate a new Hadar object, and send it the name method (and it
behaves as expected). Pretty simple, and yet powerful. Here it is:
hudson 3 ~: objtclsh
ObjTcl Shell 2.0. Copyright 1994, 1995 TipTop Software
URL: http://www.tiptop.com/ Email: <in...@tiptop.com>
## This is a 30-day evaluation / educational copy of Objective-Tcl.
## The license terms are specified in:
## /LocalDeveloper/Documentation/ObjTcl/License/01_Evaluation.rtf,
and
## /LocalDeveloper/Documentation/ObjTcl/License/05_Educational.rtf
## respectively. If you don't agree with the terms you must stop
using ObjTcl.
## To order a license and register, contact TipTop Software at
+1-301-656-3837
## email: in...@tiptop.com, URL: http://www.tiptop.com, or simply type:
## objtcl_register
% set obj [Object new]
@Object@000a2bb0
% $obj isKindOf: Object
1
% $obj isKindOf: Window
0
% $obj isKindOf: Hadar
?: unhandled_error: No class Hadar.
Type 'h' for the list of debugger commands.
Type 'c' to continue.
Dbg% c
No class Hadar.
% class Hadar Object {
> {STR lastName}
> } {
> method -initName: {STR name} {
> set lastName $name
> return $self
> }
>
> method {STR} -name {
> return $lastName
> }
> }
Hadar
% $obj isKindOf: Hadar
0
% set h [[Hadar alloc] initName: Pedhazur]
@Hadar@00099828
% $h name
Pedhazur
%
OK. You say this is cool, but how do I get anything *real* done like
this? Two quick answers, a) obviously anything you can type
interactively, you can also put in a file so that you can build up
complex programs rather easily while testing them along the way, and
b) you can include complete libraries in the interpreter as well, so
you can test (and or develop) significantly more *real* things than
the above trivial example.
There are two ways (other than adding your own custom classes as we
just saw) to extend the interpreter. You can create a *custom
interpreter* by simply linking the 5 line example main program with
*any* libs you want to be automatically included in your interpreter,
*or*, you can *dynamically load* any libs that you would like. I will
give a complete example of the latter, which can be used, for example,
to test out the functionality of a Kit! In this example, I will show
you everything you need to do to interactively test the MiscKit! I
will leave the commentary out as it should be self-explanatory:
hudson 6 /tmp: cd /LocalDeveloper/Libraries
hudson 7 /LocalDeveloper/Libraries: cc -r -nostdlib -all_load -o
misckit.O libMiscKit.a
hudson 8 /LocalDeveloper/Libraries: l misckit.O
-rw-r--r-- 1 hadar wheel 865224 Aug 12 12:04 misckit.O
hudson 9 /LocalDeveloper/Libraries: cd /tmp
hudson 10 /tmp: objtclsh
ObjTcl Shell 2.0. Copyright 1994, 1995 TipTop Software
URL: http://www.tiptop.com/ Email: <in...@tiptop.com>
## This is a 30-day evaluation / educational copy of Objective-Tcl.
## The license terms are specified in:
## /LocalDeveloper/Documentation/ObjTcl/License/01_Evaluation.rtf,
and
## /LocalDeveloper/Documentation/ObjTcl/License/05_Educational.rtf
## respectively. If you don't agree with the terms you must stop
using ObjTcl.
## To order a license and register, contact TipTop Software at
+1-301-656-3837
## email: in...@tiptop.com, URL: http://www.tiptop.com, or simply type:
## objtcl_register
% objtcl_load /LocalDeveloper/Libraries/misckit.O
% set s [MiscString newWithString: "Mary had a little lamb ..."]
@MiscString@00099ff0
% set b [TextFieldCell new]
Couldn't find default font for default NXSystemFonts
Couldn't find default font for default NXBoldSystemFonts
@TextFieldCell@000a24b0
% set m [TextFieldCell new]
@TextFieldCell@000b1540
% set a [TextFieldCell new]
@TextFieldCell@000b1648
% $s grep: "HAD" occurrenceNum: 0 caseSensitive: 0 \
> before: $b middle: $m after: $a
1
% $b stringValue
Mary
% $m stringValue
had
% $a stringValue
a little lamb ...
%
The above example is *complete*. There is some line wrapping going on
from my paste in the terminal (TipTop :-)), sorry, but that is where I
actually turn the libMiscKit.a into a dynamically loadable file,
misckit.O (obviously the name is arbitrary). The warning messages for
Couldn't find default font are due to the fact that there is no
Application Object in this interpreter (though there could have
been!!!). Clearly, while this is a *very* powerful tool for learning
things like the MiscKit (or any kit), it is particularly useful to us
at UBS for doing things like verifying that new apps are using our
analytic libraries correctly. When results don't appear to be correct
in the UI of a new app, one can fire up an objtclsh (with our libs
pre-linked, or simply dynamically loaded) and test the results with no
UI and known parameters to see if the results are correct at the
library level. Most often they are :-), and the developer can
concentrate on how he/she mismatched the user's desired inputs with
the actual calling syntax of our models :-)
2) The interpreter can be embedded in any ObjC program. I will not
give any direct examples of this, and I will further muddy the waters
by telling you that this is the conceptually harder part (though the
much bigger win part as well!).
This is much harder because there are too numerous ways for you to
decide exactly how/when/why you will give access to ObjTcl. For
example, in some of our apps, we include *one* line of source (and one
header file :-)), and all we accomplish with this is that we embed an
interpreter, and *ask it to publish itself as a Distributed Object
Server!!!*. The remainder of the app is untouched. Now, when the app
is running, we can use a different command line program, dosh, which
is essentially an "objtclsh" with no interpreter in it. It merely
connects (via D.O.) to an already running interpreter (across networks
if desired, *of course, it's real D.O.!!!*) and can now be used to
"examine" the running app (ala gdb, but the app is actually running,
not frozen at the breakpoint!!!), and/or *change* the app, via
Category definitions, new classes, etc.
We have apps that range in ObjC-ObjTcl mixture from 20 lines of ObjC
plus 1000 lines of ObjTcl, to an app which is 44,000 lines of ObjC
plus 100 lines of ObjTcl. Again, the hardest problem is determining
exactly what level of control you wish to give the user, whether you
wish to "call" ObjTcl to perform very specific functions, or whether
you wish to permit a completely open design where it is unknown and
transparent whether something is written in ObjC or ObjTcl.
Lastly (I promise), the seperate product Objective-Browser (OB) is so
amazing (and extensible!!!) that it alone justifies purchasing ObjTcl,
just to run the Browser!
I can not stress enough that if you are building NS Apps, and do not
take a look (a serious one at that!) at this product, then you are
doing yourself a serious disservice! If this were a product that we
developed in house, we would be guarding it so jealously that I wonder
at times why I was busting at the seems to discuss this with
people outside of UBS for the past year. However, we did *not* develop
it, and we *do* use it heavily, so I would rather see it thrive, have
others deliver software to *UBS* that uses it, and have it continue to
evolve. Hence, the evangelism. Enjoy it!
If there is enough traffic warranting further examples, etc., then I
will consider putting out some more stuff.
--
Hadar Pedhazur
Global Equity Derivatives
Union Bank of Switzerland (UBS)
Marc Guenther
> Anyway, for the past year I have been Beta Testing Objective-Tcl
> (ObjTcl) from TipTop Software, in its various incarnations. Due to my
This all sounds amazing, but I'm wondering (forgive me of it's obvious, but
I don't know much about this stuff) what is the difference between this
product, and the freely available libtclobjc library ?
Yoda
Hadar Pedhazur
: hadar@amazon (Hadar Pedhazur) wrote:
: > Anyway, for the past year I have been Beta Testing Objective-Tcl
: > (ObjTcl) from TipTop Software, in its various incarnations. Due to my
: This all sounds amazing, but I'm wondering (forgive me of it's obvious, but
: I don't know much about this stuff) what is the difference between this
: product, and the freely available libtclobjc library ?
: Yoda
This is a good question. For one, the Objective-Browser, which requires
the ObjTcl from TipTop :-), is something that really needs to be used to
be appreciated. Second, and I admit that I stopped looking at the free
stuff (of which there were at least two if I recall) a *long* time ago,
there were things that they simply could not do that this one can.
When I last looked, you could *instantiate* objects, but could not *define*
them (in other words, create classes, create categories, etc.) on the fly.
That may indeed have changed since I last looked.
Another factor is the seemless support for Distributed Objects (something
that we use heavily, but others might not find as useful). Built in
"interactor" support, so that you may give your users access to ObjTcl
without writing any UI for that piece (not a big deal, but every little
bit helps). IB support (which I don't think is in any of the PD stuff).
You can do some pretty amazing things in IB with ObjTcl, and in fact can
control IB through the D.O. support, which is pretty hot stuff. It permits
you to *automate* a lot of mundane IB tasks (I purposely left out the IB
stuff from my last post, and maybe I shouldn't have :-). As far as IB
automation is concerned, one of the examples, Examples/ObjTcl/EOF-IB
came from UBS directly. It shows how easy it is to automatically
connect an EOController to an NXTableView with *no* ctrl-dragging for
each association!
I could probably go on, but your question is a valid one, and if the
only thing that ObjTcl does is excite people to the possibilities, and
then the PD versions get better, then so be it (sorry Pedja :-). I for
one, would rather use them *now*, have them from a vendor who has
demonstrated high quality software for a number of years, coupled with
high quality support, and at the prices he's offering the product at,
I consider the investment as close to PD as commercially possible
:-).
Frank M. Siegert
raises the question what language an integrated interpreter
(embedded in IB) should use.
There was a discussion on gnu.misc.discussion in 1994 about
the choice of the gnu extension language and they choose a
different kind of language (Scheme, IMHO a good choice).
See http://minsky.med.virginia.edu/sdm7g/LangCrit/Tcl/ for
more information about the 1994 language war.
Please try to understand my point, I really don't want to bash on
ObjTCL, as Pedja has undoubtedly made it a good product. I just
want to raise the question "Why using TCL for this?"
Why not using an objective-c interpreter (or ... )?
- Frank
---
Frank M. Siegert [fr...@miranda.tue.schwaben.de]
NeXTSTEP & PostScript Guy
Nelson Minar
Frank M. Siegert <fr...@miranda.tue.schwaben.de> wrote:
>Please try to understand my point, I really don't want to bash on
>ObjTCL, as Pedja has undoubtedly made it a good product. I just
>want to raise the question "Why using TCL for this?"
This is an ideal introduction for a major flamewar, one I'll dodge.
I will say, though, why I'm using Tcl as a scripting language for a
non-NeXTstep Objective C system I'm developing. Tcl works. It's a
mature, functional product. Given the current lack of alternatives,
this makes sense. Now, when Guile comes out I'll be all for shifting
to it.
But the real reason I'm posting is to see if anyone out there is using
libtclobjc. If so, could you drop me a note? I'm in the process of
producing a minor revision of libtclobjc, and want to hear from other
users of the library. Changes I've made are a new configure script,
minor change for Tcl 7.4, and a couple of extra methods to Tk.m to get
access to Tk data structures.
--
__
nel...@santafe.edu \/ http://www.santafe.edu/~nelson/
Hadar Pedhazur
: In article <40r5qm$4...@gate.seicom.net>,
Also not to get into a flame war, even if GUILE were mature, stable,
well received, etc., do you have a version that *is* integrated with the
runtime?, that *is* integrated with IB?
Again, I do *not* want to flame, but I *do* want to get *work* done *today*!
ObjTcl let's me do that better *today* than I could *yesterday* without it
(OK, that's a lie, I have been using ObjTcl for quite a while, and therefore
it has been helping me for longer than just yesterday :-)).
Oh oh, and I *really* do mean it when I say that I don't want to start a
flame war here ... but:
While I understand the religious ferver that people ascribe to Perl vs Tcl
wars, Scheme vs Tcl, etc., I will point out that ObjTcl does not suffer
from *all* of the normal "one language vs another language" problems. We
must keep in mind that ObjTcl has full ObjC standing behind it, and Tcl is
merely *glue*. In other words, you do not have to write 10000 line ObjTcl
programs that are pure Tcl! You might have 10000 lines of ObjTcl (possibly
with zero Objective-C behind it!), but you have the richness of *types*,
a *runtime*, with *instances*, etc., so it isn't exactly Tcl either ...
Please forgive me, and don't explain to me why GUILE is better anyway,
unless you also show me how to leverage my current ObjC libraries with it
:-).
Andrew McCallum
Please forgive me, and don't explain to me why GUILE is better anyway,
unless you also show me how to leverage my current ObjC libraries with it
What is libguileobjc?
=====================
I have implemented glue that lets you send messages to Objective-C
objects from GUILE. It can pass and return long, int, short, char,
float, double, and Objective-C objects.
This is an early release---far from polished or complete.
It adds the following new primitives to GUILE:
(objc-lookup-class class-string) ; returns class object
(objc-id? any)
(objc-classnames) ; returns a list of class names
(objc-msg-send receiver method [args]...)
and a macro the handles the quoting of method names:
(objc-send receiver method [args]...)
It uses the functions in libobjects' mframe.m to construct method
calls on the fly (the same mechanism as used by distributed objects).
For example, you can do things like:
(define foo (objc-send List new))
(objc-send foo addObject: (objc-send Object new))
(objc-send foo addObject: (objc-send Object new))
(objc-send foo addObject: (objc-send Object new))
(define bar (objc-send foo objectAt: 1))
(define count (objc-send foo count))
(objc-send foo replaceObjectAt:with: 1 (objc-send Object new))
What's new?
===========
Libguileobjc version 0.2 compiles with guile-ii. Version 0.1 was
based on guile-i.
Where can you get it?
=====================
ftp://ftp.cs.rochester.edu/pub/u/mccallum/guileobjc-0.2.tar.gz
Happy hacking,
Andrew
Andrew Kachites McCallum EBOX: mcca...@cs.rochester.edu
Computer Science Dept VOX: (716) 275-2527, (716) 275-1372 (lab)
University of Rochester FAX: (716) 461-2018
Rochester, NY 14627-0226 http://www.cs.rochester.edu/u/mccallum
--
Andrew Kachites McCallum EBOX: mcca...@cs.rochester.edu
Computer Science Dept VOX: (716) 275-2527, (716) 275-1372 (lab)
University of Rochester FAX: (716) 461-2018
Rochester, NY 14627-0226 http://www.cs.rochester.edu/u/mccallum
Frank M. Siegert
>This is an ideal introduction for a major flamewar, one I'll dodge.
free to choose whatever language seems fit for the problem at hand.
I do not deny the fact that TCL is stable, mature and avaiable. All I
do is deny TCL the right to be declared as the final solution for all
situations and problems. I have not worked with ObjTCL yet, it is
quite possible that in this context TCL is a good solution.
I just liked to hear your opinions. Having now a working product
based on TCL does IMHO not imply to stay with TCL for all times.
Andrew McCallum wrote:
>I have implemented glue that lets you send messages to Objective-C
>objects from GUILE. It can pass and return long, int, short, char,
>float, double, and Objective-C objects.
Now that sounds interesting.... (guess the lisp programmer breaks though 8-))
Hadar Pedhazur
: Just one question: what about speed?
: --Gerben
It is quite acceptable. Again, depends on what you are doing. If ObjTcl
is the glue, the scripting code, the interpreter, but the heavy work
(whatever that means!) is in your objects (ObjC), then it is fantastic.
I have entire apps that are written in 100% ObjTcl, but they are NOT
analytical, just Data Gathering and dissemination, and they are fine
(if they are slower, it is not enough for me to notice or care ...).
Gerben Wierda
Hadar Pedhazur
: >Gerben Wierda (G.C.Th...@AWT.NL) wrote:
: >: Just one question: what about speed?
: >: --Gerben
: >It is quite acceptable. Again, depends on what you are doing. If ObjTcl
: >is the glue, the scripting code, the interpreter, but the heavy work
: >(whatever that means!) is in your objects (ObjC), then it is fantastic.
: >I have entire apps that are written in 100% ObjTcl, but they are NOT
: >analytical, just Data Gathering and dissemination, and they are fine
: >(if they are slower, it is not enough for me to notice or care ...).
: Transparent auto-release semantics? Has is memory managed?
: --
: The views and opinions expressed in this article
: are those of the poster and not his employer.
Seriously, I am *not* sure what you are asking (or implying?). I think
that you either had a typo or a grammatic error? Anyway, I will answer
as *if* you were asking a question as to whether ObjTcl supports
autorelease, etc. (hope that was what you were getting at :-)):
ObjTcl is fully FoundationKit compliant (and aware). As such, there are
a number of convenience procs for handling NSStrings, NSDictionaries,
and NSArrays. Of course, having seen this simple yet extremely useful
procs, one realizes just how easy it is to extend that to anything else
(Foundation or otherwise).
Anyway, there *are* autorelease semantics built in (via procs) to ObjTcl.
As one example, in certain circumstances, you will use rrset rather than
set (rrset = retain/release set!). Hope this helps ... (someone, if not
you Robert :-)).
t...@concerto.best.com
| This is an ideal introduction for a major flamewar, one I'll dodge.
| non-NeXTstep Objective C system I'm developing. Tcl works. It's a
| mature, functional product. Given the current lack of alternatives,
| this makes sense. Now, when Guile comes out I'll be all for shifting
| to it.
Note also that if you write your functions to the Tcl API, they will
usually be trivial to interface with any other scripting language you
might choose later, since the Tcl API is so straightforward.
In fact, the GUILE announcement said that GUILE would support the Tcl
API and Tcl scripts directly.
Cheers,
Thomas.