Lisp or Smalltalk for Specific Suicide Mission (er...Project)?
dev...@runbox.com
Assume, for a few terrifying moments, that you are a pointy-haired boss
put in charge of a team who are expected to implement some fairly
advanced software using a language they don't know.
Given the set of parameters below, would you choose Lisp or Smalltalk
for the project...and why?
1. Most of team members are "systems analysts" (i.e. business and MIS
majors), not programmers. No experience with Emacs or Store, etc.
2. Project will be internet and intranet software -> browser-based UI.
3. Much of functionality is standard business-type stuff (groupware,
etc.)
4. Part of functionality, however, will rely on natural language
processing of 30,000 or so data feeds, many of which are XML-based.
5. Specific implementation choices are between SBCL or LispWorks and
VisualWorks Smalltalk.
6. Would like to benefit from as much open-source code as possible.
7. There are only a couple real programmers to mentor the team.
8. Would like at least a remote possibility of project succeeding...
Thanks in advance for helping me with this sick little
(non-hypothetical) exercise.
Pascal Bourguignon
Both are valid choices.
The major problem you have is point 1.
Why don't you hire programmers to do programming works?
Do you hire electricians to cook?
Or nurses to install your electric wires and transformers?
Now, if you'd hire me, I would rather use Common-Lisp, since I'm
slightly more experienced with it than with Smalltalk.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Kelly Hall
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
You're probably boned either way, but I'd suggest the smalltalk route
since the GUI is prettier for the non-programmers and the language is
slightly less obsolete.
Cheers,
Kelly
Martin DeMello
> An appeal to the collective wisdom of c.l.l. and c.l.s:
>
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
Depending on your requirements, take a look at Ruby too - to a very
simplified approximation, it's Smalltalk with a Unix accent.
martin
Steven Kelly
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
>
> 1. Most of team members are "systems analysts" (i.e. business and MIS
> majors), not programmers. No experience with Emacs or Store, etc.
> 2. Project will be internet and intranet software -> browser-based UI.
> 3. Much of functionality is standard business-type stuff (groupware,
> etc.)
> 4. Part of functionality, however, will rely on natural language
> processing of 30,000 or so data feeds, many of which are XML-based.
> 5. Specific implementation choices are between SBCL or LispWorks and
> VisualWorks Smalltalk.
> 6. Would like to benefit from as much open-source code as possible.
> 7. There are only a couple real programmers to mentor the team.
> 8. Would like at least a remote possibility of project succeeding...
I'd suggest you use Java or C#. Then when the project fails, you can blame these languages and everybody will be happy
(most importantly, the denizens of c.l.l. and c.l.s.) ;->
More seriously, I don't know current Lisp capabilities for XML and web apps, but certainly VW can do this and Smalltalk
may be easier to learn as a language than Lisp, for this team. Whether this is true also depends on the teachers,
presumably the 'real programmers'. In any case, I don't want to start a language war over which is easier to learn: I
found Lisp exciting and easy to learn, but Smalltalk even easier. I suspect VW Smaltalk's better IDE played a
significant role.
Steve
dev...@runbox.com
>
> Why don't you hire programmers to do programming works?
>
> Do you hire electricians to cook?
>
> Or nurses to install your electric wires and transformers?
Though obviously not an ideal situation, there are two reasons for this
requirement:
1. It is a low-budget "skunkworks"-type project. Not enough of a
budget to bring in outside consultants unless absolutely necessary.
2. The management wishes to develop more in-house programmers. One
of the better ways to promote from within and to cultivate a deeper
pool of talent is thru on-the-job training...and we might as well be
training while building something useful, eh?
Edi Weitz
Yes, this is sick.
Sorry, but it really smells like a troll. What on earth do you expect
except for most of the c.l.s inhabitants recommending Smalltalk and
most of the c.l.l inhabitants recommending Lisp? If you're lucky you
get a nice flame war and I guess this is what you want.
If you were serious you wouldn't crosspost this to both groups but
you'd ask specific questions in the individual groups.
Edi.
PS: Follow-up to comp.lang.lisp set.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Pascal Bourguignon
Yes, but OP wrote that there won't be any GUI, only a WUI.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
dev...@runbox.com
for me. [No offense to anyone, of course, just not my cup of tea.]
If we went with a scripting language, we would be much more likely to
use Python because of the available libraries and existing code (for
NLP, groupware, etc.)
Although we really like the learning curve of Python, some of the
reasons we nixed it in favor of Lisp/Smalltalk are:
1. I really dig image-based development.
2. Slower execution of Python scripts (even using Psyco,etc.)
3. Not ideally suited if we ever have to deploy standalone executables
in the future.
John Thingstad
How fast does the code need to run?
Learning python is much quicker than any of the alternatives you mentioned.
In any case you should have a pilot project to get the programmers up to
speed.
Better to have them learn by making mistakes there than in you application.
For a console based app I would prefer Lisp but it probly take 6 months
for the programmers to get productive in it. Are you sure you can afford
NOT to hire experienced programmers. (you can get consultants from
say manpower for temporary employment.)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Chris Uppal
> 3. Much of functionality is standard business-type stuff (groupware,
> etc.)
> 4. Part of functionality, however, will rely on natural language
> processing of 30,000 or so data feeds, many of which are XML-based.
I'm not a lisper, so I may be biased. Still, I'd have expected that Smalltalk
would be better suited to (3) -- which you say is the bulk of the project --
so, even though I doubt if Smalltalk would be better for (4), I'd guess that ST
would be the better overall. However...
> 7. There are only a couple real programmers to mentor the team.
> 8. Would like at least a remote possibility of project succeeding...
Then you have no choice but to use whatever the "couple of real programmers"
are /already/ comfortable with.
You mentioned that this is at least partially a training exercise, but there's
no way that you can use it to train the /entire/ team at the same time. Either
the "real programmers" are teaching (ST or Lisp or whatever) or they are
learning it. I doubt whether you stand a cat in Hell's chance if you expect
them to be doing both at once.
-- chris
Christopher C. Stacy
Andreas Thiele
news:1106207345.9...@f14g2000cwb.googlegroups.com...
Hi,
this problem is so crazy, it must be a real world problem. I mean it must be
true ;-)
I wonder about two things:
1. what has natural language processing to do with XML? If natural language
is of importance I would think of Lisp.
2. Why are you already committed to SBCL or LispWorks? clisp might be
another choice.
I think, if you choose Lisp, you should have 1 to 3 experienced Lisp
developers. They might build a system which will be fed by the non
programmers in some specialized language created by the Lisp guys (maybe
with some GUI on top). This is actually a way I worked before. Lisp is the
choice if you are not too certain about what has to be developed and is
great in developing languages 'on the fly'. Those 3 Lisp guys might create
such a system in some month. If you don't have experienced Lisp developers I
think they'll need approx. 1 year to achieve the required skill. Meanwhile
the others wouldn't have anything to work on.
I only have little knowledge on Smalltalk, so I cannot say much about it.
Smalltalk seems to have great OO.
Andreas
dev...@runbox.com
This is not a troll, and I'm most definitely NOT trying to start a
language war.
I didn't ask which language was "better." I asked which language would
be best for this specific scenario AND WHY. I'm more concerned with
the WHY. Obviously, the inexperienced team is the overriding concern -
so I hoped to get a feel for which language had the shorter learning
curve (including tools) and would be easier to grasp for people who
have no background in computer science. I'm assuming the obvious
answer would be Smalltalk as it was designed as a "first programming
language" or whatever, but I'm new enough to both languages that I
thought there might be a something I'm overlooking IN THE LONG RUN.
I didn't ask more specific questions to start because I didn't want to
unduly influence the direction of the discussion - and perhaps miss out
on a post about something that I would have never thought about.
Some specific things I'm interested in:
CLOS is both more flexible and more complex as an O-O system than
Smalltalk, as I understand it - do you think the pros of this
flexibility outweigh the cons of the complexity when dealing with
inexperienced programmers on the one hand and the algorithmic
complexity of NLP on the other hand?
I read an older Usenet posting about the advantages of encapsulation
and "how you think objects should behave" that struck a chord with
me...I was hoping for more of that type of discussion.
The suitability of both languages for NLP. Lisp is, I would think,
much more commonly used in NLP, but I read that Smalltalk is also very
strong...? Specific pros and cons? (Mark Watson...anybody?)
All things (algorithms,etc.) being equal, compiled Lisp is presumably
faster than compiled (VM) Smalltalk...will that be an issue when I'm
talking about performing NLP operations on 30,000 data feeds? Is
there anything I should know about threading issues for this sort of
problem domain? (Green threads vs. native threads, specific
implementation differences and pros/cons between SBCL, VW, and LW?)
Differences in deployment issues and ease between the various options?
It's 4 a.m. where I'm at, so I'm just rambling...but it is a serious
post and I'm very interested in any and all (legitimate) points anyone
thinks I should consider....
Thanks,
- Sergei
Stefan Scholl
> I realize that Ruby is cool, but it has too much of a Perl odor to it
> for me. [No offense to anyone, of course, just not my cup of tea.]
>
> If we went with a scripting language, we would be much more likely to
> use Python
__foo__?
dev...@runbox.com
I totally agree with your point, but this isn't really an issue in this
specific case.
The "real programmers" that will mentor the team will probably be
drawn from a consulting agency we work with depending on which language
we choose. They have several full-time Smalltalk and Lisp programmers
that all have experience as instructors.
I didn't spell that out to start with because...well, I didn't want
financially biased answers or emailed resumes in response to a serious
question...I've had bad experiences with that sort of thing in the
past.
("Platform X is the ONLY solution for this problem...by the way, I
happen to specialize in Platform X, and for a per diem of only...")
Pascal Costanza
let them make their own decision. This will raise their motivation to
actually achieve the goals set for the project. Self-motivation seems to
be one of the most important factors in software projects.
Pascal
Pascal Costanza
I think the obsolesence of both languages are on par.
Pascal
P.S.: I have been recently to a meeting of Smalltalkers who organize a
conference for their language. Yes, the community seems pretty active.
Same for Lisp. Don't make the mistake to think that you're the only
underdogs. ;)
Bulent Murtezaoglu
[...]
d> CLOS is both more flexible and more complex as an O-O system
d> than Smalltalk, as I understand it - do you think the pros of
d> this flexibility outweigh the cons of the complexity when
d> dealing with inexperienced programmers on the one hand and the
d> algorithmic complexity of NLP on the other hand?
Complexity of of CLOS is only there when you try to use it to do complex
things. It does not get in your way otherwise. For efficiency your
problem will probably be your trainees not knowing how to produce
efficient code. (CLOS may give you larger constants over say
defstruct structs but you won't care if your guys are writing
O(n^3) code anyway). If you'll be doing exploratory programming, CLOS
is probably the right choice to get things working quickly. Once you
know how you'll do what you are doing, you can benchmark and
rewrite/refactor.
[...]
d> All things (algorithms,etc.) being equal, compiled Lisp is
d> presumably faster than compiled (VM) Smalltalk...will that be
d> an issue when I'm talking about performing NLP operations on
d> 30,000 data feeds?
Your 30000 data feeds themselves will be a problem. Will they be coming
in simultaneously from the net? Will you guys be up to writing code that
can handle 30k network streams? (spinning 30k threads probably will not
do it on reasonably cheap hardware, you could multiplex them into a single
feed by additional code or do event loops &c.).
d> Is there anything I should know about
d> threading issues for this sort of problem domain? (Green
d> threads vs. native threads, specific implementation differences
d> and pros/cons between SBCL, VW, and LW?) [...]
I'd do a back-of-envelope calculation to see how much memory, etc. I'd
need. You may need a 64 bit machine for this. (then again I haven't
seen original problem was so maybe these are all non-issues). You
won't need it for develeopment of the NLP part, of course, but if
that's the way it seems you'll have to go you'd need to choose a
system that can do 64 bit natively.
cheers,
BM
Lars Brinkhoff
Matthias
> An appeal to the collective wisdom of c.l.l. and c.l.s:
>
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
> [...]
> 7. There are only a couple real programmers to mentor the team.
Ask these people what they want and give it to them. Don't make
decisions on languages you don't know personally on the basis of a
newsgroup posting.
Really: If your programmers are good, they'll know what they need. If
they aren't good your project is doomed, and you'll probably get blamed
for choosing an unconventional language.
Kenny Tilton
Pascal Costanza wrote:
> Give them a few weeks to let them explore the options on their own...
Yes, just break open a smalltalk book and PCL and in two days the
decision will be much better informed. That said...
What I do not like about SmallTalk:
1. all objects all the time
2. precedence of operations varying between unary, binary, and keyword
3. not having source files where I can eyeball a pagefull of code in one go
4. single-inheritance
5. no macros
6. no special variables
7. not enough parentheses (not joking)
8. did I mention all objects all the time?
As for CLOS being complex, it is simply a superset of the capabilities
of Smalltalk.
As for you all being newbies, both languages are very approachable. The
Lispworks IDE counts a lot in keeping up with the ST IDE. But here is a
Deep Thought: you cannot think "non-programmer". If you stay
non-programmers, you will not succeed with this. So becoming programmers
is a must, at which point the only question is, which language is
better. No comment. :)
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Espen Vestre
> 1. Most of team members are "systems analysts" (i.e. business and MIS
> majors), not programmers. No experience with Emacs or Store, etc.
Ouch. As others have pointed out, this is the main obstacle. You
need programmers to program. Period.
However, given your constraints, I guess this actually means you
have to turn these people into programmers, and then there's no
reason not to start out with lisp. Why go for anything less, if
you actually have the choice, and your pupils' brains (presumably)
haven't been hardwired (yet) with prejudices about curly and non-
curly parantheses?
(I've taught Common Lisp to absolute newbies, and it was great fun!)
--
(espen)
Wade Humeniuk
> dev...@runbox.com writes:
>
>
>>1. Most of team members are "systems analysts" (i.e. business and MIS
>>majors), not programmers. No experience with Emacs or Store, etc.
>
>
> Ouch. As others have pointed out, this is the main obstacle. You
> need programmers to program. Period.
>
That is not necessarily the case. Some of the programmers need to
write the core application but if they write a domain specific language
that would make it easier on the "systems analysts". Lisp is great
at creating application specific languages.
Wade
jar...@gmail.com
-- this is concistant - usually a good thing
2. precedence of operations varying between unary, binary, and keyword
-- every language has syntax rule; Smalltalk's are fairly slim. You
can override this with parens
3. not having source files where I can eyeball a pagefull of code in
one go
-- If you really want that, you can file code out.
4. single-inheritance
-- well, I'd argue that multiple inheritance adds complexity that we
don't need - especially given unlimited polymorphism
5. no macros
6. no special variables
7. not enough parentheses (not joking)
-- lol
8. did I mention all objects all the time?
-- you did :)
Marco Antoniotti
If the OP is willing to use a commercial product, Lispworks gives you
native look and feel on Windows and the Mac. The interfaces are very
pretty.
... and since, last I checked, Smalltalk did not have decent and
standardized multi-methods, I'd reassess Common Lisp obsolescence and
Smalltalk modernity. :)
... plus ...
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=247&page=1
Soemthing we lispers have known all along. :)
Cheers
--
Marco
Friedrich Dominicus
>
> How fast does the code need to run?
> Learning python is much quicker than any of the alternatives you
> mentioned.
Friedrich
--
Please remove just-for-news- to reply via e-mail.
Wade Humeniuk
> An appeal to the collective wisdom of c.l.l. and c.l.s:
>
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> for the project...and why?
>
> majors), not programmers. No experience with Emacs or Store, etc.
This is not very important, you need everyone to understand
the problem and develop a vocabulary that your team members can
use to communicate with each other.
> 2. Project will be internet and intranet software -> browser-based UI.
Just details.
> 3. Much of functionality is standard business-type stuff (groupware,
> etc.)
Then your system analysts already have a vocabulary/conceptual
model of the system. You have to tap into this utilize their
knowledge in a meaningful way.
> 4. Part of functionality, however, will rely on natural language
> processing of 30,000 or so data feeds, many of which are XML-based.
There are natural language libraries already written in Lisp.
> 5. Specific implementation choices are between SBCL or LispWorks and
> VisualWorks Smalltalk.
What platform?
> 6. Would like to benefit from as much open-source code as possible.
> 7. There are only a couple real programmers to mentor the team.
Then you have to convert most of the project to not look like
programming. You need some higher level language. Then "programmers"
are spending their time writing very declarative code. If well done
they do not even feel they are programming.
> 8. Would like at least a remote possibility of project succeeding...
>
> Thanks in advance for helping me with this sick little
> (non-hypothetical) exercise.
>
You need an infusion of positive thinking. It may be difficult, but
one step at a time.
Pick Lisp.
Wade
Cesar Rabak
>>The major problem you have is point 1.
>>
>>Why don't you hire programmers to do programming works?
>>
>>Do you hire electricians to cook?
>>
>>Or nurses to install your electric wires and transformers?
>
>
>
> Though obviously not an ideal situation, there are two reasons for this
> requirement:
>
> 1. It is a low-budget "skunkworks"-type project. Not enough of a
> budget to bring in outside consultants unless absolutely necessary.
>
If you put this in the table, I think the best approach would be to
develop the intended SW using the knowledge the team already have.
> 2. The management wishes to develop more in-house programmers. One
> of the better ways to promote from within and to cultivate a deeper
> pool of talent is thru on-the-job training...and we might as well be
> training while building something useful, eh?
>
The outcomes of an on the job training process tend to be exercises of
programming, very seldom 'production' artifacts. _If_ you can factor
this _very_ clearly, you have a chance, otherwise. . .
--
Cesar Rabak
Ng Pheng Siong
> this problem is so crazy, it must be a real world problem. I mean it must be
> true ;-)
;-)
> 1. what has natural language processing to do with XML?
Processing blogs, most likely. The 30,000 number corroborates.
> I only have little knowledge on Smalltalk, so I cannot say much about it.
> Smalltalk seems to have great OO.
Smalltalk is a Lisp with postfix notation, single dispatch and no macros.
But it's really enjoyable.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
John Thingstad
<just-for-...@q-software-solutions.de> wrote:
> "John Thingstad" <john.th...@chello.no> writes:
>>
>> How fast does the code need to run?
>> Learning python is much quicker than any of the alternatives you
>> mentioned.
> Why should it be easier to learn Python then Smalltalk?
>
> Friedrich
Python has a somewhat simpler syntax.
There s a great python tutorial that you can run through in a day.
Already then you can start programming python.
There is a vast number of libraries to interface to the OS.
This includes SAX/DOM support to read and process your XML files.
Python is slow but the libraries, written in C/C++ are not.
So for many applications python seems fast enough.
The exception is extensive calculations.
Even then there is a module num-py which pretty much solves this.
The best way to figure out what you think is to try the python tutorial
and see for yourself. (www.python.org)
Python has a intuitive syntax and things have a tendency to work as a
person expects.
Python was also originally designed to teach people programming
but has proven itself powerful enough for application development.
Smalltalk's syntax is cryptic and takes time to get used to
also it is almost impossible to write a algorithm in a straight
forward way as all you have are messages.
Again download squeak (a MS Windows free environment) and
see for yourself. (www.squeak.org)
Peter Seibel
> An appeal to the collective wisdom of c.l.l. and c.l.s:
>
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
>
> 7. There are only a couple real programmers to mentor the team.
I think this is the key point--who are these programmers and what
languages are they familiar with? If you can only have one "real"
programmer they'd better know whatever language you're going to use
quite well *and* be a good teacher. If you have a Smalltalk guru
hanging around use Smalltalk; if you have a Lisp guru hanging around
use Lisp. If you have one of each, use the language of whoever is the
better teacher. Also you'll want to use programmers who are good
students since presumably they will need to come up to speed quickly
on the domain knowledge provided by your non-programmers.
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel
> Pascal Costanza wrote:
>
>> Give them a few weeks to let them explore the options on their own...
>
> Yes, just break open a smalltalk book and PCL and in two days the
> decision will be much better informed. That said...
>
> What I do not like about SmallTalk:
>
> 1. all objects all the time
But wait, Lisp has that too. ;-) For some (important) definition of
"object".
-Peter
P.S. Since Kenny brought it up, I'll expand the acronym for him: PCL
is _Practical Common Lisp_, soon to be published by Apress, currently
available in draft form at: <http://www.gigamonkeys.com/book/>.
BR
> Better to have them learn by making mistakes there than in you
> application. For a console based app I would prefer Lisp but it probly
> take 6 months for the programmers to get productive in it. Are you sure
> you can afford NOT to hire experienced programmers. (you can get
> consultants from say manpower for temporary employment.)
That raises a question. How long does it take to learn and be proficient
in a given language? Most material on the net is of a technical nature,
and generally ignores the human aspects.
Bulent Murtezaoglu
[...]
BR> That raises a question. How long does it take to learn and be
BR> proficient in a given language? Most material on the net is of
BR> a technical nature, and generally ignores the human aspects.
Most, but not all:
http://www.norvig.com/21-days.html
BM
dev...@runbox.com
I'm going to refactor my question a bit and start a new thread(s),
because I have a better idea of what I'm trying to find out than I did
when I posted my original plea.
drewc
> <dev...@runbox.com> wrote in message news:1106207345.9...@f14g2000cwb.googlegroups.com...
>
>>Assume, for a few terrifying moments, that you are a pointy-haired boss
>>put in charge of a team who are expected to implement some fairly
>>advanced software using a language they don't know.
>>
>>Given the set of parameters below, would you choose Lisp or Smalltalk
>>for the project...and why?
>>
>>majors), not programmers. No experience with Emacs or Store, etc.
>>etc.)
>>processing of 30,000 or so data feeds, many of which are XML-based.
>>VisualWorks Smalltalk.
>
>
> (most importantly, the denizens of c.l.l. and c.l.s.) ;->
>
> More seriously, I don't know current Lisp capabilities for XML and web apps,
Well, i write all my web apps in Lisp, so maybe i can fill you in. IMO,
there is no better language for developing web apps. If you have to use
XML, you can't beat lisp as XML can be transformed to sexps, then
manipulated like any other piece of lisp code. That, mixed with a nice
framework for web-continuations (UncommonWeb serves me well, for
smalltalk there is seaside), and you are light-years ahead of the
scripters. And ,, it's compiled to machine code. fastest web-apps on the
planet.
I've got a little bit on web programming at my lisp wiki if you want to
know a little more :
http://lisp.tech.coop/Web%20Programming
but certainly VW can do this and Smalltalk
> may be easier to learn as a language than Lisp, for this team. Whether this is true also depends on the teachers,
> presumably the 'real programmers'. In any case, I don't want to start a language war over which is easier to learn: I
> found Lisp exciting and easy to learn, but Smalltalk even easier. I suspect VW Smaltalk's better IDE played a
> significant role.
I don't use an IDE (well .. emacs), but i found lisp quite easy compared
to smalltalk. Maybe it's because i never liked the message-passing OO
thing... i never understood objects until i met CLOS.
drewc
>
> Steve
>
>
Kenny Tilton
>>>>>>"BR" == BR <brodr...@comcast.net> writes:
>
> [...]
> BR> That raises a question. How long does it take to learn and be
> BR> proficient in a given language? Most material on the net is of
> BR> a technical nature, and generally ignores the human aspects.
I think it would be harder for a good programmer to change editors than
to change languages. I do not recall slowing down much at all when I
switch to Lisp, because all the advantages over C made up for --- well,
if you just code C-style then away you go. But I can remember having to
stop to think about how to write (lambda...now what was that? So for a
good programmer they will not slow down when switching to Lisp, but they
won't hit warp speed for a few months.
The only catch is that for many programmers changing to Lisp also means
learning a new editor. doh! But the commercial lisps's editors are not
as decelerating as Emacs.
drewc
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>Pascal Costanza wrote:
>>
>>
>>>Give them a few weeks to let them explore the options on their own...
>>
>>Yes, just break open a smalltalk book and PCL and in two days the
>>decision will be much better informed. That said...
>>
>>What I do not like about SmallTalk:
>>
>>1. all objects all the time
>
>
> But wait, Lisp has that too. ;-) For some (important) definition of
> "object".
>
> -Peter
So true! Actually, i was catching up on ARC the other day, and, for a
lanugage that was not supposed to be particularly Object-Oriented, He's
actually managed to make the most consistent object system i've ever
seen. It's turtles all the way down!
That's assuming objects are just "thingies" with state and type. if you
want CLOS or message passing, you are free to build it on top of ARCs
object-type system.
Jeff Brooks
> On Thu, 20 Jan 2005 18:53:01 +0100, Friedrich Dominicus
> <just-for-...@q-software-solutions.de> wrote:
>
>> Why should it be easier to learn Python then Smalltalk?
>
> Python has a somewhat simpler syntax.
Actually, Smalltalk has a simplier syntax than Python.
... snip ...
> Smalltalk's syntax is cryptic and takes time to get used to
> also it is almost impossible to write a algorithm in a straight
> forward way as all you have are messages.
All syntax seems cryptic until you get used to it.
It's easy to write algorithms in Smalltalk using messages.
... snip ...
Jeff Brooks
Kenny Tilton
jar...@gmail.com wrote:
> 1. all objects all the time
>
> -- this is concistant - usually a good thing
actually, I think it is the Classic Mistake(tm): "Hey! Let's use it for
everything!" Case in point: CPL, Guy Steele's constraints programming
language. They did variable assignment as a constraint. Until they came
to their senses. Also, consider Prolog. When ya just want to iterate or
do any number of normal imperative steps, it always has be via logic and
unification, with lotsa cuts thrown in cuz ya really just want to iterate.
We Lispniks are forever beating our chests over the many paradigms we
have at our disposal. If you want polymorphism, define a method. If you
want to add 2 plus 2, for god's sake do not send the + message to the
first 2 with 2 as the operand, just add the little suckers. :)
>
> 2. precedence of operations varying between unary, binary, and keyword
>
> -- every language has syntax rule; Smalltalk's are fairly slim. You
> can override this with parens
>
> 3. not having source files where I can eyeball a pagefull of code in
> one go
>
> -- If you really want that, you can file code out.
No, I also want to work on it as a page of code. Cut and paste a method
three times to jumpstart three variants, or bring a function inline to
the only plave it turns out it gets used by literally dragging it into
the caller. etc etc.
>
> 4. single-inheritance
>
> -- well, I'd argue that multiple inheritance adds complexity that we
> don't need - especially given unlimited polymorphism
But the world we are modeling cannot be expressed with single
inheritance. Delegation is just another way of saying, "Damn, we should
have allowed multiple inheritance!".
MI can be straightforward just as GOTO can be tamed by using it in
strictly limited ways. My rule is to have various singly-inheriting
class trees for any given functional domain, and when
multiple-inheritance is necessary I am allowed to inherit only once from
any given tree. No conflicts possible. It did take me a while to hit on
this policy, tho, so I can see how other people get into trouble and MI
has gotten a bad rap.
Cesar Rabak
[snipped]
>> -- If you really want that, you can file code out.
>
>
> No, I also want to work on it as a page of code. Cut and paste a method
> three times to jumpstart three variants, or bring a function inline to
> the only plave it turns out it gets used by literally dragging it into
> the caller. etc etc.
>
Kenny,
You could get surprised, but this in Smalltalk is seldom needed and
(surprise, surprise ;-) considered a bad programming practice.
my .01999...
--
Cesar Rabak
Kenny Tilton
Hang on. You just changed the assignee of "bad programming practice"
from an Anonymous Considerer (which sounds to me like an invocation of
some Grand Authority) to yourself (at a level of confidence just under
two cents <g>).
So exactly whom am I about to trounce in this debate?
:)
btw, I am reminded fondly of sitting down to help my manager and another
programmer with some code at 10 pm (they had been at it since about 6pm)
and, after a careful review of their predicament, beginning to cut and
paste like a maniac, provoking the manager to shriek and dive for
another terminal to take a copy of the source before I could exit.
banged a shin badly knocking a chair out of the way, IIRC. thems were
the days.
Kenny Tilton
BS, '74, Slash 'n Burn Programming Academy
Friedrich Dominicus
>
> Smalltalk's syntax is cryptic and takes time to get used to
> also it is almost impossible to write a algorithm in a straight
> forward way as all you have are messages.
> Again download squeak (a MS Windows free environment) and
> see for yourself. (www.squeak.org)
Well I have use both, and I can't tell that I had more difficulties to
understand Smalltalk then Python. But I soon started to dislike Python
and now prefer Ruby. The only real problem I see with Smalltalk was
the sheer mass of Libraries available right from the start. Just
looking through some browser, my first impression was simply "wow".
However the syntax of Smalltalk is probably the simples around, for a
good tutorial on Smalltalk I can recommend "on to smalltalk", Pythons
may have more libraries but you have to install them usually
separatly. And Python is IMHO very much rooted in Unix (not per se a
bad thing) whereas Smalltalk is more an OS or way of life in itself. I
shares much of this with Common Lisp and Emacs IMHO.
Regards
Ng Pheng Siong
> Python has a somewhat simpler syntax.
> Smalltalk's syntax is cryptic
This is backasswards.
> [Smalltalk syntax] takes time to get used to
This is true, if only because many people are used to Algol-style syntax.
But I don't think that takes more time than it does to get used to Python's
whitespace-based indentation.
John Thingstad
<ng...@netmemetic.com> wrote:
> According to John Thingstad <john.th...@chello.no>:
>> Python has a somewhat simpler syntax.
>> [...]
>> Smalltalk's syntax is cryptic
>
> This is backasswards.
>
>> [Smalltalk syntax] takes time to get used to
>
> This is true, if only because many people are used to Algol-style syntax.
> But I don't think that takes more time than it does to get used to
> Python's
> whitespace-based indentation.
>
>
>
Well I can't speak for others.
But for me python is MUCH more intuitive.
It reads like the pseudo code I used to write.
From I started reading the tutorial to I started writing
programs in python took days not weeks.
I find indentation base to be intuitive too.
There is a old saying in list circles:
"The parenthesises are for the compiler, the indentation is for the
programmer."
Well in python there is only the indentation and the interpreter reads
them too.
To me fitting into the smalltalk way of doing things is like putting on
a straight jacket. I can't move freely. Always the smalltalk way of
doing things constrained my expression.
I should perhaps add that like to program using multiple paradigms and
choose the approach I find most appropriate for the exact problem be
it procedural, functional or object oriented.
Matthias
> For NLP Lisp is the only show in town.
Bold statement. Could you explain why?
Martin DeMello
>
> I think it would be harder for a good programmer to change editors than
> to change languages.
Quotefiled!
martin
Ng Pheng Siong
> To me fitting into the smalltalk way of doing things is like putting on
> a straight jacket. I can't move freely. Always the smalltalk way of
> doing things constrained my expression.
I am not preaching at you, for I take a dim view of programming language
evangelism personally, so make of the following what you will. ;-)
Here's a story about Bruce Lee which sets the stage for this little
exercise. A master martial artist asked Bruce to teach him everything
Bruce knew about martial arts. Bruce held up two cups, both filled with
liquid. "The first cup," said Bruce, "represents all of your knowledge
about martial arts. The second cup represents all of my knowledge about
martial arts. If you want to fill your cup with my knowledge, you must
first empty your cup of your knowledge."
I got it from here:
http://www.stevepavlina.com/blog/index.php?p=50
Cheers.
Tayssir John Gabbour
boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
Meeting Lisp/Smalltalk users is useful. I know of regular meetings in
the Lisp world which may be convenient for you to attend.
If you mention your situation beforehand, someone might bring a laptop
loaded with the environments you've been eyeing. Or something equally
useful.
MfG,
Tayssir
Kenny Tilton
Ng Pheng Siong wrote:
> According to John Thingstad <john.th...@chello.no>:
>
>>But for me python is MUCH more intuitive.
>>[...]
>>To me fitting into the smalltalk way of doing things is like putting on
>>a straight jacket. I can't move freely. Always the smalltalk way of
>>doing things constrained my expression.
>
>
> I am not preaching at you, for I take a dim view of programming language
> evangelism personally, so make of the following what you will. ;-)
>
> Here's a story about Bruce Lee which sets the stage for this little
> exercise. A master martial artist asked Bruce to teach him everything
> Bruce knew about martial arts. Bruce held up two cups, both filled with
> liquid. "The first cup," said Bruce, "represents all of your knowledge
> about martial arts. The second cup represents all of my knowledge about
> martial arts. If you want to fill your cup with my knowledge, you must
> first empty your cup of your knowledge."
>
> I got it from here:
>
> http://www.stevepavlina.com/blog/index.php?p=50
Good one! Bruce got it from: some students brought their Zen professor
to meet this groovy old monk they had met. The professor came in,
greeted the monk cordially, everyone sat down, and as the monk was
serving tea the learned scholar said, "My young students say you are
wonderful and recommended I come hear you speak on Zen. Students are
easily impressed. Let us see what you can teach me."
At this point the monk reached the professor and filled his cup and kept
on pouring until the cup overflowed. The professor cried out, "Stop! The
cup is full!"
The monk replied, "Your mind is like the cup. I can teach you nothing."
Anyway, I have encountered more than one all-X-all-the-time philosophy
including Smalltalk. They all have the same problem. They take some neat
trick and try to make it serve all needs just because it is neat, and
because they also get excited about the imagined value of consistency.
Consistency is where this subthread started, btw. The only true value in
software development is the isomorphism of the algorithm with the
problem being solved. Some problems can be reasonably modeled as a
message send, but "2 + 2" is not one of them.
Contorting "2 + 2" into a message send preserves consistency within the
language model. yawn. It also fundamentally breaks the programmability
of the language. One is now doomed to endless mental contortions
whenever the message send is the wrong model, where improved
productivity comes from making the language effectively disappear so
that we are expressing ourselves intuitively as we program.
The supposed value of consistency is making everything will be clearer.
The arrow goes the other way. Single inheritance is likewise presumed to
be simpler. Hello delegation and/or interfaces. And first graders were
supposed to learn arithmetic more easily if they first learned set
theory. Chya.
This is what happens when scholars are allowed to decide what goes on in
the trenches.
kt
John Thingstad
<ng...@netmemetic.com> wrote:
>
> Here's a story about Bruce Lee which sets the stage for this little
> exercise. A master martial artist asked Bruce to teach him everything
> Bruce knew about martial arts. Bruce held up two cups, both filled with
> liquid. "The first cup," said Bruce, "represents all of your knowledge
> about martial arts. The second cup represents all of my knowledge about
> martial arts. If you want to fill your cup with my knowledge, you must
> first empty your cup of your knowledge."
>
> I got it from here:
>
> http://www.stevepavlina.com/blog/index.php?p=50
>
> Cheers.
>
You are probaly right.
I am to old to spend more time on learning new languages.
I'd rather stick with what I got and spend it on solving
problems the way I like best.
Jock Cooper
> According to John Thingstad <john.th...@chello.no>:
> > But for me python is MUCH more intuitive.
> > [...]
> > To me fitting into the smalltalk way of doing things is like putting on
> > a straight jacket. I can't move freely. Always the smalltalk way of
> > doing things constrained my expression.
>
> I am not preaching at you, for I take a dim view of programming language
> evangelism personally, so make of the following what you will. ;-)
>
> Here's a story about Bruce Lee which sets the stage for this little
> exercise. A master martial artist asked Bruce to teach him everything
> Bruce knew about martial arts. Bruce held up two cups, both filled with
> liquid. "The first cup," said Bruce, "represents all of your knowledge
> about martial arts. The second cup represents all of my knowledge about
> martial arts. If you want to fill your cup with my knowledge, you must
> first empty your cup of your knowledge."
>
> I got it from here:
>
> http://www.stevepavlina.com/blog/index.php?p=50
>
> Cheers.
>
I think Bruce Lee must have been alluding to the old Zen koan:
A Cup of Tea
Nan-in received a university professor who came to inquire about Zen.
Nan-in served tea. He poured his visitor's cup full and then kept on pouring.
The professor watched the overflow until he could restrain himself no
longer. "It is overfull. No more will go in!"
"Like this cup", Nan-in said, "you are full of your own opinions and
speculations. How can I show you Zen unless you first empty your cup?"
Pascal Costanza
> Contorting "2 + 2" into a message send preserves consistency within the
> language model. yawn.
Be careful: It's actually "2 + 2" in Smalltalk while it's "(+ 2 2)" in
Lisp. This is only to say that this is an example in which both
languages make admissions at some level. The question is what level do
you care about.
Pascal
Kenny Tilton
Pascal Costanza wrote:
> Kenny Tilton wrote:
>
>> Contorting "2 + 2" into a message send preserves consistency within
>> the language model. yawn.
>
>
> Be careful: It's actually "2 + 2" in Smalltalk while it's "(+ 2 2)" in
> Lisp.
True. Lisp does benefit from the ({operator} operands*) consistency, tho
in the case of arithmetic my point is confirmed: expressing a
sufficiently hairy arithemtic expression in Lisp does make me stop and
think. Fortunately that rarely comes up.
Maybe my beef with Smalltalk is that it picked the /wrong/ thing to be
consistent with? Or is it the very message-sending model? Hmmm...
Jeff Brooks
>
> Cesar Rabak wrote:
>
... snip ...
>> Kenny,
>>
>> You could get surprised, but this in Smalltalk is seldom needed and
>> (surprise, surprise ;-) considered a bad programming practice.
>>
>> my .01999...
>
> Hang on. You just changed the assignee of "bad programming practice"
> from an Anonymous Considerer (which sounds to me like an invocation of
> some Grand Authority) to yourself (at a level of confidence just under
> two cents <g>).
>
> So exactly whom am I about to trounce in this debate?
>
> :)
Copy and paste programming is bad programming practice in any language
(Lisp included).
Jeff Brooks
Hans-Martin Mosner
...
> Anyway, I have encountered more than one all-X-all-the-time philosophy
> including Smalltalk. They all have the same problem. They take some neat
> trick and try to make it serve all needs just because it is neat, and
> because they also get excited about the imagined value of consistency.
> Consistency is where this subthread started, btw. The only true value in
> software development is the isomorphism of the algorithm with the
> problem being solved. Some problems can be reasonably modeled as a
> message send, but "2 + 2" is not one of them.
>
> Contorting "2 + 2" into a message send preserves consistency within the
> language model. yawn. It also fundamentally breaks the programmability
> of the language. One is now doomed to endless mental contortions
> whenever the message send is the wrong model, where improved
> productivity comes from making the language effectively disappear so
> that we are expressing ourselves intuitively as we program.
Ahem. You've got real life experience with Smalltalk programming? Does
not sound like it.
For all practical purposes, 2+2 behaves in Smalltalk as it should. It's
an addition, and the result is 4.
Whether the processor puts specific bit patterns into two registers and
executes an ADD opcode or pushes two values onto the stack and sends a
message or calls a function with two arguments is pretty much
irrelevant when it comes to 2+2.
But when it comes to polymorphic data (such as mixed integer, real, and
complex arithmetic, or natural language expressions with different
syntactical structure and meaning) some kind of dynamic dispatch is
necessary. And it's good if it has a solid foundation in the language
and is not just grafted onto it. This applies to Smalltalk, and it most
likely applies to Lisp and a couple other languages of these families.
Whether the language paradigm is the message send or the function
application is more or less a matter of taste.
I hate language wars, so I keep this short (and I try not to attack the
lispers). Others have already said most of what I would say about this
task. The predominant impression of this project is that of unavoidable
failure. And the choice of language has nothing to do with it. As a
Smalltalk advocate I'd prefer if the project would fail with Visual
Basic or Logo or Lisp, but I am fairly sure that it would fail with
Smalltalk as well as with any other language just because the
requirements and the resources don't match. For a successful project,
you either need a team which can work on the task at hand full speed
right from the start, or you need a lot more time and money to make
your existing team into such a winner team.
Cheers,
Hans-Martin
Brian Downing
Kenny Tilton <kti...@nyc.rr.com> wrote:
> The only catch is that for many programmers changing to Lisp also means
> learning a new editor. doh! But the commercial lisps's editors are not
> as decelerating as Emacs.
No, they just have a lower speed limit.
*ducks, runs*
(To be fair, Lispworks' editor looks pretty good to me, although it's
missing tons of operations from GNU Emacs that I expect to be there by
default. Allegro's editor did not impress me, though perhaps I had not
managed to switch it out of Windows-lusering mode.)
-bcd
Kenny Tilton
Hans-Martin Mosner wrote:
> Kenny Tilton <kti...@nyc.rr.com> wrote:
> ...
>
>>Anyway, I have encountered more than one all-X-all-the-time philosophy
>>including Smalltalk. They all have the same problem. They take some neat
>>trick and try to make it serve all needs just because it is neat, and
>>because they also get excited about the imagined value of consistency.
>>Consistency is where this subthread started, btw. The only true value in
>>software development is the isomorphism of the algorithm with the
>>problem being solved. Some problems can be reasonably modeled as a
>>message send, but "2 + 2" is not one of them.
>>
>>Contorting "2 + 2" into a message send preserves consistency within the
>>language model. yawn. It also fundamentally breaks the programmability
>>of the language. One is now doomed to endless mental contortions
>>whenever the message send is the wrong model, where improved
>>productivity comes from making the language effectively disappear so
>>that we are expressing ourselves intuitively as we program.
>
>
> Ahem. You've got real life experience with Smalltalk programming? Does
> not sound like it.
Yes. About two months trying to get early QKS SmalltalkAgents for the
Mac to work.
> For all practical purposes, 2+2 behaves in Smalltalk as it should. It's
> an addition, and the result is 4.
Duh. Now what happens when you do 1 + 2 * 3? Or is it 1 * 2 + 3 which
gives surprising results? I forget.
Jeff Brooks
... snip ...
> Anyway, I have encountered more than one all-X-all-the-time philosophy
> including Smalltalk. They all have the same problem. They take some neat
> trick and try to make it serve all needs just because it is neat, and
> because they also get excited about the imagined value of consistency.
The value of consistency is it makes the language simpler. Simpler
languages are easier to learn.
Adding arbitrary complexity to a language doesn't mean the language is
more expressive than a simpler language. Compare C++, and Lisp. C++ is
more complex but Lisp is more expressive.
> Consistency is where this subthread started, btw. The only true value in
> software development is the isomorphism of the algorithm with the
> problem being solved. Some problems can be reasonably modeled as a
> message send, but "2 + 2" is not one of them.
"2 + 2" models adding two numbers together very well. Smalltalk doing it
as a message send is consistent with it's language model.
> Contorting "2 + 2" into a message send preserves consistency within the
> language model. yawn. It also fundamentally breaks the programmability
> of the language. One is now doomed to endless mental contortions
> whenever the message send is the wrong model, where improved
> productivity comes from making the language effectively disappear so
> that we are expressing ourselves intuitively as we program.
In Lisp adding the numbers together is "(+ 2 2)" which is consistent
with it's language model. Yawn!
When using an argument against an opposing view point you need to make
sure the same argument can't be used against your view point or your
argument is meaningless.
Using your logic I could argue that Lisp fundamentally breaks the
programmability of the language by using lists to represent math.
... snip ...
> This is what happens when scholars are allowed to decide what goes on in
> the trenches.
C++, and Java is what happens when scholars don't decide what goes on in
the trenches. Lisp, and Smalltalk is what happens when they do.
Jeff Brooks
Darin Johnson
> Be careful: It's actually "2 + 2" in Smalltalk while it's "(+ 2 2)" in
> Lisp.
And further, "2 + 2" in Smalltalk is rarely a true message send
anyway, and this operates behind the scenes very much like Lisp
(attempt the arithmetic and then trap if the operands don't match).
--
Darin Johnson
I'm not a well adjusted person, but I play one on the net.
Darin Johnson
> Copy and paste programming is bad programming practice in any language
> (Lisp included).
I had to maintain code once that was written using copy-paste
techniques *without* reindenting the code afterwords. Many
lost hours tracking down bugs that would have been obvious
if the conditionals had lined up...
--
Darin Johnson
"Floyd here now!"
skogstadNielsen(fjern)
> An appeal to the collective wisdom of c.l.l. and c.l.s:
>
> Assume, for a few terrifying moments, that you are a pointy-haired boss
> put in charge of a team who are expected to implement some fairly
> advanced software using a language they don't know.
>
> Given the set of parameters below, would you choose Lisp or Smalltalk
> for the project...and why?
>
> 1. Most of team members are "systems analysts" (i.e. business and MIS
> majors), not programmers. No experience with Emacs or Store, etc.
> 2. Project will be internet and intranet software -> browser-based UI.
> 3. Much of functionality is standard business-type stuff (groupware,
> etc.)
> 4. Part of functionality, however, will rely on natural language
> processing of 30,000 or so data feeds, many of which are XML-based.
> 5. Specific implementation choices are between SBCL or LispWorks and
> VisualWorks Smalltalk.
> 6. Would like to benefit from as much open-source code as possible.
> 7. There are only a couple real programmers to mentor the team.
> 8. Would like at least a remote possibility of project succeeding...
>
> Thanks in advance for helping me with this sick little
> (non-hypothetical) exercise.
>
If your staff is very mature, very hard working, very co-operative then
the choice of platform don't mean much.
If not, then the platform don't mean much either.
Because in the latter case Suicide is sure. - Maybe suicide could be
done in a more funny way.;-)
ps:
If you don't have specs for the project, then the succes of the mission
is gained by having upper managemnt to think it is a success - then the
platform don't mean much either it could be VB6.
just my bet .
soren
John Thingstad
<"skogstadNielsen(fjern)"@ddf.dk> wrote:
> If you don't have specs for the project, then the succes of the mission
> is gained by having upper managemnt to think it is a success - then the
> platform don't mean much either it could be VB6.
>
> just my bet .
> soren
Just a thought. Have you considered design style.
Then take a look at extreme programming.
This is a style that is suitable for both Lisp and Smalltalk.
www.extremeprogramming.org.
Pascal Bourguignon
In my first job I started with a listing 12 cm thick and when I
finished removing duplicate code and adding new features, it was only
3 cm thick.
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Kenny Tilton
Darin Johnson wrote:
You should have ported it all to Lisp first and then auto-indented the
whole source file in one key chord. :)
Y'all do not understand. I am not talking about cutting and pasting and
then turning it in. It is just one way of creating code. Some of youse
guys touch-type, I cut/paste and then go from there.
But hey, maybe this is why I have never had any success as a programmer.
PWUAAA HHAAAH HAAA HAA...
:)
kt
--
Cells? Cello? Cells-Gtkk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Land o' Kenny? http://www.tilton-technology.com/index.html
Obligatory quote to make me seem cool:
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
Kenny Tilton
Jeff Brooks wrote:
> Kenny Tilton wrote:
...
>> Consistency is where this subthread started, btw. The only true value
>> in software development is the isomorphism of the algorithm with the
>> problem being solved. Some problems can be reasonably modeled as a
>> message send, but "2 + 2" is not one of them.
>
>
> "2 + 2" models adding two numbers together very well.
Duh. Now how do you explain:
1 + 2 * 3 => 9
? Or is it?:
3 * 2 + 1 => 9
? I forget which idiocy results from the message-send model being forced
onto arithmetic.
I would have made clear up front that the problem arose with different
operands had I known the ST crowd would claim success at "2 + 2" as
their crowning glory.
<sigh>
> In Lisp adding the numbers together is "(+ 2 2)" which is consistent
> with it's language model. Yawn!
So you agree that consistency cuts both ways? And that in the end what
matters is what matters: programmer productivity.
>
> When using an argument against an opposing view point you need to make
> sure the same argument can't be used against your view point or your
> argument is meaningless.
You like others thought this was a Lisp vs ST argument. It is not. My
point is that yelping "consistency!" does not save
all-objects-all-the-time from being a bad idea, nor does it save Prolog
from being a bad idea, nor does it save CPL from being a bad idea. Even
in Lisp we lose the ability to quickly toss off mixed-operator
arithmetic, we have to (+ 1 (* 2 3)), tho we gain the ability to do "(+
1 2 3)" which actually trumps "1 + 2 + 3". but it still forces the
translator of arithmetic to code to slow down, which is my point.
You have been reading the thread, yes? Or did you just jump in here?
Anyway, the nice thing about Lisp is that in return for the consistency
making rare arithmetic forms harder to code we get procedural macros.
Yummy. :)
Bruce Stephens
> Jeff Brooks wrote:
>
>> Kenny Tilton wrote:
> ...
>
>>> Consistency is where this subthread started, btw. The only true
>>> value in software development is the isomorphism of the algorithm
>>> with the problem being solved. Some problems can be reasonably
>>> modeled as a message send, but "2 + 2" is not one of them.
>> "2 + 2" models adding two numbers together very well.
>
> Duh. Now how do you explain:
>
> 1 + 2 * 3 => 9
I presume it's that message passing is left associative, so 1+2
evaluates to 3, and then 3*3 evaluates to 9. I agree it's initially
confusing, but I'd also guess that after a while someone who programs
in Smalltalk regularly wouldn't need to think about it.
[...]
Dave Harris
> > "2 + 2" models adding two numbers together very well.
>
> Duh. Now how do you explain:
>
> 1 + 2 * 3 => 9
In Smalltalk all binary operators have the same precedence and evaluate
left to right. It is not actually due to message sending. It's an example
of Smalltalk's drive for simplicity. It is hard to have operators with
different precedence without making it hard to read, regardless of how the
operators are dispatched.
For example, C/C++ has a fixed set of operators with hard-wired
precedence, but the precedence depends on the operator. I can remember the
common combinations, but something like:
1 + 2 << 3 | 4
is beyond me even though I use that language daily. If we add user-defined
operators with user-defined precedence (as we surely want to), it gets
even worse. I daresay a machine parser could manage, but humans can't.
Smalltalk's grammar is very simple, but just about complex enough. It has
3 levels of precedence. I got used to it very quickly; much quicker than
all those parenthesis in Lisp.
> I would have made clear up front that the problem arose with different
> operands had I known the ST crowd would claim success at "2 + 2" as
> their crowning glory.
:-) Actually "2 + 2" is for me the worrying case, but for different
reasons. It is a symmetrical expression, but Smalltalk treats it
asymmetrically. One 2 becomes the receiver and the other the argument.
CLOS is better at modelling arithmetic because it has multiple dispatch.
> You like others thought this was a Lisp vs ST argument. It is not. My
> point is that yelping "consistency!" does not save
> all-objects-all-the-time from being a bad idea, nor does it save Prolog
> from being a bad idea, nor does it save CPL from being a bad idea. Even
> in Lisp we lose the ability to quickly toss off mixed-operator
> arithmetic, we have to (+ 1 (* 2 3)), tho we gain the ability to do "(+
> 1 2 3)" which actually trumps "1 + 2 + 3". but it still forces the
> translator of arithmetic to code to slow down, which is my point.
I agree that picking a single model and sticking to it consistently leads
to some compromises. I don't agree that it is therefore a bad idea. I
think it partly depends on the model.
In Smalltalk if we need multiple inheritance or multiple dispatch we have
to simulate it by hand. Although that is not ideal, it is doable, and the
need is rare enough not to damage programmer productivity (at least in my
experience). That's what makes it good: (a) the model is powerful enough
that I rarely need to fight it; and (b) when I do need something
different, I can easily build it within the model. That isn't really true
for Prolog.
-- Dave Harris, Nottingham, UK
Thomas Gagne
>
>
>
> So you agree that consistency cuts both ways? And that in the end what
> matters is what matters: programmer productivity.
There's no such thing as programmer productivity. 20 lines in one language
may accomplish way more than 20 lines in another but too many mistakingly
believe their productiviy is equivalent. How many business features did you
implement? As much as it pains some, some languages have greater velocity at
the latter than others.
Kenny Tilton
Programmer velocity? I like it! That explains my weight problem. At this
point I am so good that any improvement just adds to my mass.
And the unit of measurement is the business feature?
OK, I'll do the sales tax calculation for NYC, you do the feature that
orders a packing list so the warehouse people travel the shortest
distance possible by going down the list in order.
:)
kenny
Hans-Martin Mosner
>
> Hans-Martin Mosner wrote:
...
> > Ahem. You've got real life experience with Smalltalk programming? Does
> > not sound like it.
>
> Yes. About two months trying to get early QKS SmalltalkAgents for the
> Mac to work.
experience with programming. I have tried to get a lisp interpreter to
work about 15 years ago. Does that make me an experienced lisp
programmer? Nah.
>
> > For all practical purposes, 2+2 behaves in Smalltalk as it should. It's
> > an addition, and the result is 4.
>
> Duh. Now what happens when you do 1 + 2 * 3? Or is it 1 * 2 + 3 which
> gives surprising results? I forget.
Somebody else already noted that it is indeed inconsistent with the
traditional algebraic notation. However, I think most programming
languages which try to embrace algebraic notation by implementing
operator precedence fail in the more complex cases. For example, when
it comes to matrix multiplication which is not transitive anymore, most
languages simply don't get it (if they support matrix multiplication
using * anyway).
But as I said, I hate language wars, so that's my last reply to this
part of the thread.
Cheers,
Hans-Martin
pat...@nordebo.com
> Darin Johnson wrote:
>
> > Jeff Brooks <jeff_...@nospam.com> writes:
> >
> >>Copy and paste programming is bad programming practice in any language
> >>(Lisp included).
> > I had to maintain code once that was written using copy-paste
> > techniques *without* reindenting the code afterwords. Many
> > lost hours tracking down bugs that would have been obvious
> > if the conditionals had lined up...
>
> You should have ported it all to Lisp first and then auto-indented the
> whole source file in one key chord. :)
That trick works on most languages though, if you use a decent editor
with support for the language, like Emacs. Lisp has many advantages,
but this isn't really one of them.
Kenny Tilton
Darin Johnson
> You should have ported it all to Lisp first and then auto-indented the
> whole source file in one key chord. :)
Actually, this is what forced me learn about indent-region in emacs...
--
Darin Johnson
"You used to be big."
"I am big. It's the pictures that got small."
Darin Johnson
> In Smalltalk all binary operators have the same precedence and evaluate
> left to right. It is not actually due to message sending. It's an example
> of Smalltalk's drive for simplicity.
True, and it is possible to add "chalkboard standard" precedence to
math operators Smalltalk. But it doesn't really gain anything except
raising complex questions about what to do about all the other
non-math operators (and there are a lot of them).
--
Darin Johnson
Laziness is the father of invention
Rahul Jain
> Learning python is much quicker than any of the alternatives you mentioned.
> In any case you should have a pilot project to get the programmers up to
> speed.
We're talking about people who haven't been corrupted to assume that
computers have the same restricitons as primitive programming languages,
tho. He specifically wants people with no understanding of what a
computer is, what it can do, how it can mess up, or how to structure
things logically to write this program. Of course, it's bound to fail no
matter what language he uses.
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain
> I have tried to get a lisp interpreter to work about 15 years ago.
> Does that make me an experienced lisp programmer? Nah.
Even less of a credible one because you were still using stuff that was
obsolete 50 years ago 15 years ago. ;)
Rahul Jain
> :-) Actually "2 + 2" is for me the worrying case, but for different
> reasons. It is a symmetrical expression, but Smalltalk treats it
> asymmetrically. One 2 becomes the receiver and the other the argument.
> CLOS is better at modelling arithmetic because it has multiple dispatch.
I don't like (raw) CLOS for that because it doesn't understand
commutativity, associativity, and distributivity (there's a better word
for that, but I forget it). However, that gets rather complicated when
you're dealing with different types (such as matrix multiplication or FP
addition or quaternion multiplication).
From what I've seen of weyl, that's the way it needs to be done to get
it right. It uses CLOS under the hood, but the operators are not CLOS
methods. After all, in CL, (+), (+ 1), and (+ 1 2) are all legal, so
multiple-dispatch isn't enough. You need arbitrary-dispatch. However,
you can implement the under-the-hood TWO-ARG-+ as a generic-function,
but given the non-extensibility of built-in classes, that's a bit
wasteful. :)
Rahul Jain
> To be fair, Lispworks' editor looks pretty good to me, although it's
> missing tons of operations from GNU Emacs that I expect to be there by
> default.
It's actually a Hemlock, which is an Emacs. It just doesn't have as many
commands and packages written for it as GNU Emacs does.
Rahul Jain
> 1. all objects all the time
Lisp is also all objects all the time. It's just that it has a broader
definiton of how an object can be represented internally.
Kenny Tilton
Rahul Jain wrote:
> Kenny Tilton <kti...@nyc.rr.com> writes:
>
>
>>1. all objects all the time
>
>
> Lisp is also all objects all the time. It's just that it has a broader
> definiton of how an object can be represented internally.
>
<sigh> Lookit, kiddies, there is all objects all the time and then there
is all objects all the time. I was talking about all objects all the time.
eg, In: (dotimes (n 10) (print n)), what GF is being invoked on the
object 10?
Peter Seibel
> Rahul Jain wrote:
>
>> Kenny Tilton <kti...@nyc.rr.com> writes:
>>
>>>1. all objects all the time
>> Lisp is also all objects all the time. It's just that it has a
>> broader
>> definiton of how an object can be represented internally.
>>
>
>
> <sigh> Lookit, kiddies, there is all objects all the time and then
> there is all objects all the time. I was talking about all objects all
> the time.
But why cede the terminological battle to The Man at the get go. (Not
that Smalltalk is The Man any more than Lisp is. But it's definition
of "all objects all the time" is pretty much in line with The Man's.)
> eg, In: (dotimes (n 10) (print n)), what GF is being invoked on the
> object 10?
What do GF's have to do with objects? Okay, that was rhetorical.
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
John Thingstad
> Brian Downing <see-si...@lavos.net> writes:
>
>> To be fair, Lispworks' editor looks pretty good to me, although it's
>> missing tons of operations from GNU Emacs that I expect to be there by
>> default.
>
> It's actually a Hemlock, which is an Emacs. It just doesn't have as many
> commands and packages written for it as GNU Emacs does.
>
Nor does it need it.
It is primarily designed to edit lisp files.
Since it isn't a OS shell, mail browser Internet browse etc.
it dosn't need as much. I still claim for editing Lisp it
is quite adequate.
Thomas Gagne
I'm learning LISP as well, working through Peter Seibel's "Practical Common
LISP". I'm only on Chapter 3 but what I've noticed so far:
1) I love a language with a consitant model. Everything's an object,
everything's a list, etc. It decreases learning curves.
2) LISP's function names are a little too abbreviated for me. Peter skips
over what "getf" means when applied to plists (another abbreviation) but it
seems reasonable it might stand for "get field".
I already know Smalltalk and can confidentally recommend it. I'm anxious to
use LISP because it is another of those languages, like Smalltalk, that is
spoken highly of by people who have used multiple languages professionally.
Both languages are of the sort that I hear a lot of, "This would be so much
easier in LISP," or "We'd be done already if we used Smalltalk."
How about a Smalltalk with an embedded LISP processor with both capable of
accessing the other's symbols?
Pascal Bourguignon
> dev...@runbox.com wrote:
> 2) LISP's function names are a little too abbreviated for me. Peter
> skips over what "getf" means when applied to plists (another
> abbreviation) but it seems reasonable it might stand for "get field".
Actually not. See recent discussion on the subject in c.l.l.
Are function name such as:
UPDATE-INSTANCE-FOR-DIFFERENT-CLASS UPDATE-INSTANCE-FOR-REDEFINED-CLASS
LOAD-LOGICAL-PATHNAME-TRANSLATIONS LOGICAL-PATHNAME-TRANSLATIONS
MAKE-DISPATCH-MACRO-CHARACTER PPRINT-EXIT-IF-LIST-EXHAUSTED
GET-DISPATCH-MACRO-CHARACTER INVOKE-RESTART-INTERACTIVELY
SET-DISPATCH-MACRO-CHARACTER CONCATENATED-STREAM-STREAMS
HASH-TABLE-REHASH-THRESHOLD LISP-IMPLEMENTATION-VERSION
MAKE-LOAD-FORM-SAVING-SLOTS UPGRADED-ARRAY-ELEMENT-TYPE
COMPUTE-APPLICABLE-METHODS FUNCTION-LAMBDA-EXPRESSION
READ-PRESERVING-WHITESPACE TRANSLATE-LOGICAL-PATHNAME
UPGRADED-COMPLEX-PART-TYPE
too short for you?
Happily, the often used function get abreviations. For example,
instead of the length FIRST, SECOND and REST, you get the shorter:
CAR, CADR, and CDR.
Isn't it wonderful?
In addition, you can always use your own long names:
(defmacro THE-FIRST-ELEMENT-OF-THE-LIST (THE-LIST) `(CAR ,THE-LIST))
(defmacro THE-OTHER-ELEMENTS-OF-THE-LIST (THE-LIST) `(CDR ,THE-LIST))
> How about a Smalltalk with an embedded LISP processor with both
> capable of accessing the other's symbols?
It's a good idea. We already have a Common-Lisp embedded into Java
(ABCL) and one embedded into emacs (emacs-cl). It would be nice to
have one embedded into Smalltalk. We could use it to do Croquet stuff.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Thomas Gagne
> Thomas Gagne <tga...@wide-open-west.com> writes:
>
>>2) LISP's function names are a little too abbreviated for me. Peter
>>skips over what "getf" means when applied to plists (another
>>abbreviation) but it seems reasonable it might stand for "get field".
>
>
> Actually not. See recent discussion on the subject in c.l.l.
>
> Are function name such as:
> UPDATE-INSTANCE-FOR-DIFFERENT-CLASS UPDATE-INSTANCE-FOR-REDEFINED-CLASS
> LOAD-LOGICAL-PATHNAME-TRANSLATIONS LOGICAL-PATHNAME-TRANSLATIONS
> MAKE-DISPATCH-MACRO-CHARACTER PPRINT-EXIT-IF-LIST-EXHAUSTED
> GET-DISPATCH-MACRO-CHARACTER INVOKE-RESTART-INTERACTIVELY
> SET-DISPATCH-MACRO-CHARACTER CONCATENATED-STREAM-STREAMS
> HASH-TABLE-REHASH-THRESHOLD LISP-IMPLEMENTATION-VERSION
> MAKE-LOAD-FORM-SAVING-SLOTS UPGRADED-ARRAY-ELEMENT-TYPE
> COMPUTE-APPLICABLE-METHODS FUNCTION-LAMBDA-EXPRESSION
> READ-PRESERVING-WHITESPACE TRANSLATE-LOGICAL-PATHNAME
> UPGRADED-COMPLEX-PART-TYPE
> too short for you?
>
worth getting used to, no?)
<snip>
>>How about a Smalltalk with an embedded LISP processor with both
>>capable of accessing the other's symbols?
>
>
> It's a good idea. We already have a Common-Lisp embedded into Java
> (ABCL) and one embedded into emacs (emacs-cl). It would be nice to
> have one embedded into Smalltalk. We could use it to do Croquet stuff.
>
That would be fun. I found one paper at <http://citeseer.ist.psu.edu/338691.html>
Christopher C. Stacy
> Not, but the all-upper-case stuff looks unappealing (cosmetic, I know,
> but worth getting used to, no?)
Maybe you should just write your source code in lower case
like almost everybody does all the time?
David Steuber
> Not, but the all-upper-case stuff looks unappealing (cosmetic, I know,
> but worth getting used to, no?)
I NEVER use all upper case.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Pascal Bourguignon
> Pascal Bourguignon wrote:
> > Thomas Gagne <tga...@wide-open-west.com> writes:
> >
> >>2) LISP's function names are a little too abbreviated for me. Peter
> >>skips over what "getf" means when applied to plists (another
> >>abbreviation) but it seems reasonable it might stand for "get field".
> > Actually not. See recent discussion on the subject in c.l.l.
> > Are function name such as: UPDATE-INSTANCE-FOR-DIFFERENT-CLASS
> > UPDATE-INSTANCE-FOR-REDEFINED-CLASS
> > LOAD-LOGICAL-PATHNAME-TRANSLATIONS LOGICAL-PATHNAME-TRANSLATIONS
> > MAKE-DISPATCH-MACRO-CHARACTER PPRINT-EXIT-IF-LIST-EXHAUSTED
> > GET-DISPATCH-MACRO-CHARACTER INVOKE-RESTART-INTERACTIVELY
> > SET-DISPATCH-MACRO-CHARACTER CONCATENATED-STREAM-STREAMS
> > HASH-TABLE-REHASH-THRESHOLD LISP-IMPLEMENTATION-VERSION
> > MAKE-LOAD-FORM-SAVING-SLOTS UPGRADED-ARRAY-ELEMENT-TYPE
> > COMPUTE-APPLICABLE-METHODS FUNCTION-LAMBDA-EXPRESSION
> > READ-PRESERVING-WHITESPACE TRANSLATE-LOGICAL-PATHNAME
> > UPGRADED-COMPLEX-PART-TYPE
> > too short for you?
> >
> Not, but the all-upper-case stuff looks unappealing (cosmetic, I know,
> but worth getting used to, no?)
You don't need to get used to, just set your readtable-case as it pleases you.
> <snip>
> >>How about a Smalltalk with an embedded LISP processor with both
> >>capable of accessing the other's symbols?
> > It's a good idea. We already have a Common-Lisp embedded into Java
> > (ABCL) and one embedded into emacs (emacs-cl). It would be nice to
> > have one embedded into Smalltalk. We could use it to do Croquet stuff.
> >
> That would be fun. I found one paper at <http://citeseer.ist.psu.edu/338691.html>
Interesting.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
Pascal Bourguignon
If that's not obvious, I did not type that list, I typed:
(subseq (sort (list-external-symbols :common-lisp) (lambda (a b) (> (length (string a)) (length (string b))))) 0 50)
[and it happened that my keyboard was not caps-locked at that time],
and my lisp implementation returned the upcases as is specified to be
the default by the standard.
Could we now stop talking about case in lisp?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Gorbag
"Michael D. Kersey" <mdke...@hal-pc.org> wrote in message
news:41f164a3$0$64584$a726...@news.hal-pc.org...
> Matthias wrote:
> > "Michael D. Kersey" <mdke...@hal-pc.org> writes:
> >>For NLP Lisp is the only show in town.
> >
> > Bold statement. Could you explain why?
>
> OK, Lisp or Prolog!8-P
While that was true at one point, a lot of NLP is done in C and Java these
days. Particularly as there has been a big push for statistical methods, but
even amoung the more traditional approaches, the grad students coming in
know C++ or Java, so that's what they use. Sure, *I* use Lisp, but I learned
it back in the 70s, and really haven't used anything else since the mid
80s...
On the other hand, a lot of recent NLP is just reconstructing older systems
too. For the price of learning Lisp they could be making a lot more genuine
progress (at least on the system building end; useful theory construction
continues at the usual glacial pace).
Rahul Jain
> <sigh> Lookit, kiddies, there is all objects all the time and then there
> is all objects all the time. I was talking about all objects all the
> time.
>
> eg, In: (dotimes (n 10) (print n)), what GF is being invoked on the
> object 10?
What does a GF have to do with the issue of whether 10 is an object?
Note that (macro-function 'dotimes) also gives you an object. So an
object is being invoked on an object (which is actually a object, a list
of two objects, lists of objects). So where exactly are the non-objects
here?
;)
Ng Pheng Siong
> How about a Smalltalk with an embedded LISP processor with both capable of
> accessing the other's symbols?
There is an implementation of Lisp in Smalltalk written by Aoki Atsushi
that is available as a Smalltalk/X goodie. There is also a
Prolog-in-Smalltalk, also by Aoki Atsushi, which upon closer inspect, is a
Prolog implemented in the Lisp-implemented-in-Smalltalk.
Said Prolog gave the wrong answer to a correct Prolog formulation of
Einstein's riddle, though.
One of my many NATO projects is to write some Lisp to walk a
Prolog-in-Lisp implementation and generate Lisp-in-Smalltalk code, to get to
Prolog-in-Smalltalk.
See http://sandbox.rulemaker.net/ngps/120
Cheers.
--
Ng Pheng Siong <ng...@netmemetic.com>
http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
http://www.sqlcrypt.com -+- Database Engine with Transparent AES Encryption
Ivan Boldyrev
>> It's actually a Hemlock, which is an Emacs. It just doesn't have as many
>> commands and packages written for it as GNU Emacs does.
>
> Nor does it need it.
> It is primarily designed to edit lisp files.
> Since it isn't a OS shell, mail browser Internet browse etc.
> it dosn't need as much. I still claim for editing Lisp it
> is quite adequate.
But it lacks dired-mode, CVS/SVN/whatever integration and many other
packages important for *development*, not just editing.
--
Ivan Boldyrev
Violets are red, Roses are blue. //
I'm schizophrenic, And so am I.
Thomas Gagne
> According to Thomas Gagne <tga...@wide-open-west.com>:
>
>>How about a Smalltalk with an embedded LISP processor with both capable of
>>accessing the other's symbols?
>
>
> There is an implementation of Lisp in Smalltalk written by Aoki Atsushi
> that is available as a Smalltalk/X goodie. There is also a
> Prolog-in-Smalltalk, also by Aoki Atsushi, which upon closer inspect, is a
> Prolog implemented in the Lisp-implemented-in-Smalltalk.
>
> Said Prolog gave the wrong answer to a correct Prolog formulation of
> Einstein's riddle, though.
>
> One of my many NATO projects is to write some Lisp to walk a
> Prolog-in-Lisp implementation and generate Lisp-in-Smalltalk code, to get to
> Prolog-in-Smalltalk.
>
> See http://sandbox.rulemaker.net/ngps/120
>
> Cheers.
The attributions on
<http://www.exept.de/exept/onlineDoc/english/programming/goody_lisp.html> say,
"Ported from the MEI package as found in the smalltalk archives." It's time
to visit the archives.
>