Our company near Boston hired a LISP programmer who was up to speed on
Smalltalk in under 2 months. We were thrilled. He told us LISP is similar to
Smalltalk and that another LISP programmer would have an equally smooth path.
If you are a skilled LISP programmer & are very bright & would like to learn
Smalltalk & live in Massachusetts, please reply.
Thanks.
BobS
In article <·······················@ladder01.news.aol.com>,
··········@aol.com (PSYCHECORP) wrote:
> Our company near Boston hired a LISP programmer who was up to speed on
> Smalltalk in under 2 months. We were thrilled. He told us LISP is
similar to
> Smalltalk and that another LISP programmer would have an equally smooth path.
>
> If you are a skilled LISP programmer & are very bright & would like to learn
> Smalltalk & live in Massachusetts, please reply.
>
> Thanks.
> BobS
Does it work the other way? Making a Lisp programmer out of a Smalltalk
programmer? What do you think?
--
http://www.lavielle.com/~joswig/
From: Eliot & Linda
Subject: Re: Will train LISP programmer in Smalltalk
Date:
Message-ID: <34540CFD.3132@pacbell.net>
Rainer Joswig wrote:
>
> In article <·······················@ladder01.news.aol.com>,
> ··········@aol.com (PSYCHECORP) wrote:
>
> > Our company near Boston hired a LISP programmer who was up to speed on
> > Smalltalk in under 2 months. We were thrilled. He told us LISP is
> similar to
> > Smalltalk and that another LISP programmer would have an equally smooth path.
> >
> > If you are a skilled LISP programmer & are very bright & would like to learn
> > Smalltalk & live in Massachusetts, please reply.
> >
> > Thanks.
> > BobS
>
> Does it work the other way? Making a Lisp programmer out of a Smalltalk
> programmer? What do you think?
I joined a Lisp company after a number of years doing Smalltalk at
University.
I found it a very natural move. CLOS has multiple inheritance, more
powerful method combination, multi-methods and a formalised MOP. Apart
from that all else is syntax, purity, the integrity of the programming
environment, and the class libraries.
(but I can be a real Smalltalk syntax bigot ;)
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace
From: Ken Tilton
Subject: Re: Will train LISP programmer in Smalltalk
Date:
Message-ID: <34575681.571E@bway.net>
> Rainer Joswig wrote:
> >
> > In article <·······················@ladder01.news.aol.com>,
> > ··········@aol.com (PSYCHECORP) wrote:
> >
> > > Our company near Boston hired a LISP programmer who was up to speed on
> > > Smalltalk in under 2 months. We were thrilled. He told us LISP is
> > similar to
> > > Smalltalk and that another LISP programmer would have an equally smooth path.
> > >
> > > If you are a skilled LISP programmer & are very bright & would like to learn
> > > Smalltalk & live in Massachusetts, please reply.
> > >
> > > Thanks.
> > > BobS
> >
> > Does it work the other way? Making a Lisp programmer out of a Smalltalk
> > programmer? What do you think?
>
Actually, you may be onto something: Maybe Psyche should switch to Lisp?
Or is that what you were getting at? :)
In article <·············@bway.net>, ····@bway.net wrote:
> > Rainer Joswig wrote:
> > >
> > > In article <·······················@ladder01.news.aol.com>,
> > > ··········@aol.com (PSYCHECORP) wrote:
> > >
> > > > Our company near Boston hired a LISP programmer who was up to speed on
> > > > Smalltalk in under 2 months. We were thrilled. He told us LISP is
> > > similar to
> > > > Smalltalk and that another LISP programmer would have an equally
smooth path.
> > > >
> > > > If you are a skilled LISP programmer & are very bright & would like
to learn
> > > > Smalltalk & live in Massachusetts, please reply.
> > > >
> > > > Thanks.
> > > > BobS
> > >
> > > Does it work the other way? Making a Lisp programmer out of a Smalltalk
> > > programmer? What do you think?
> >
>
> Actually, you may be onto something: Maybe Psyche should switch to Lisp?
> Or is that what you were getting at? :)
Yeah, move one Lisp programmer into a Smalltalk shop and
let him convert the whole thing.
Well, my question was about how to get competent Lisp programmers
out of Smalltalk/Java/C++/... programmers. Just in case it is
difficult to find native Lisp programmers. Something like
a guide how to introduce them to the Lisp world without losing
after two weeks. How to make sense for them about concepts
like declarative programming, Macrology, ...
--
http://www.lavielle.com/~joswig/
Elaborating on how not to have one's new hires acquire a negative attitude
about one's choice of programming language:
When I started a scheme project as a language learning vehicle, my view of
the problem was data-centric. I needed to compute a value and display it.
To do that, I needed someplace to put it where the compiler and/or
interpreter would find it both when the compute-value routine computed it
and when the display routine retrieved it and formatted it.
There are only two ways to do that: global data, data with constrained
scope available to more than one routine (C static), and passing it to
routines (procedures or functions or objects with methods) as parameters
to a call to the routine. Which way does language X use, does it use both,
when is one or the other appropriate if so and why, what rules apply to
where data of particular declaration syntax is in scope. If you have "too
many" (varies with the tolerance of the programmer for maze-traversal)
exceptions to the rules, you're doomed, programming and maintaining it
will always be a PITA. With too many implicit rules the same principle
applies, because it takes longer to look up in the documentation or
remember through repetition implicit rules than rules whose application to
the problem at hand is obvious from the declarations and definitions in
the code.
How many things are the semantic equivalent of
static [type] func(args) { /* code */ } (C)
in your favorite language without the programmer being able to see
that at a glance from the declaration of the function or procedure
or method? The more of such implicit rules you have, the more irritating
it is for the programmer just learning your language, because it is slow.
"Oh yeah, that rule. The one with no visible tag, you just have to
recognize it in the overall structure of the program."
There is a tradeoff, of course. Implicit rules require less keyboarding,
just because you can imply them with more economy of statement. But first
one has to learn them, and a programmer may never get that far if he/she
has a language where less of the semantics is implicit and more is
explicit. Many programmers would find typing
IMPORT ...
EXPORT ...
a small price to pay for not having to analyze a program from the first to
the last statement in the code to fix some module like the "/" swizzler in
a url resolver, which they could just fix directly if the semantic
implementations of the block that coded it were both explicit and
self-contained. If not self-contained, explicit will do, because they can
find the dependencies in a tags table ala etags or ctags, ie by
*lexically* parsing the code. If the code assumes the state of some object
determined implicitly by code several thousand lines away in the source,
you've lost your new programmer, or at least irritated them severely,
which is not cost-effective in a profession that requires concentration.
Part of this may just be style. Scheme, for example, appears to subscribe
to the self-contained philosophy. It was a PITA to declare global data,
from my experience. This isn't bad in a language, it is sort of the oo
way, and helps reusability of code. But it must be obvious and explicit in
the tutorials how data migrates around from one functional module to
another. That's why we are here, doing this, to manage that data. Let your
training material lose sight of scope of variables, or not communicate it
to the trainee, and he'll go somewhere else that uses "the right tool for
the job" from his own perspective, ie a quick onramp and easy code
maintenance.
Regards, Clayton Weaver ······@eskimo.com (Seattle)
On Wed, 29 Oct 1997, Rainer Joswig wrote:
> Yeah, move one Lisp programmer into a Smalltalk shop and
> let him convert the whole thing.
> Well, my question was about how to get competent Lisp programmers
> out of Smalltalk/Java/C++/... programmers. Just in case it is
> difficult to find native Lisp programmers. Something like
> a guide how to introduce them to the Lisp world without losing
> after two weeks. How to make sense for them about concepts
> like declarative programming, Macrology, ...
> --
> http://www.lavielle.com/~joswig/
Data flow and scope.
Regards, Clayton Weaver ······@eskimo.com (Seattle)
Rainer Joswig <······@lavielle.com> wrote:
: Does it work the other way? Making a Lisp programmer out of a Smalltalk
: programmer? What do you think?
I think you can reasonably consider Smalltalk to be a "subset" of Lisp.
That will give a Smalltalk programmer a leg up on learning Lisp.
OTOH I think the success of any programmer moving from one to the other
will depend on the experience, skills, and inquisitiveness of the
individual more than on characteristics of the languages, per se.
A good Lisp programmer probably has these skills and so can move to any
language. Liewise for a good Smalltalk programmer.
--
Patrick Logan (H) ·············@teleport.com
(W) ···············@gemstone.com
http://www.gemstone.com
There is no such thing as a free variable.