Re: Lisp or Smalltalk for Specific Suicide Mission (er...Project)?

From: Friedrich Dominicus (just-for-news-frido_at_q-software-solutions.de)
Date: 01/26/05


Date: Wed, 26 Jan 2005 12:17:10 +0100

You should have known that you will get harsh answers while posting
such a question. Programming languages are just one part of
programming, it's importance can rank from 100% (just coding) to as
less as maybe 15-20 % or the like. And well you wrote "suicide
mission", so what do you think will happen if things go wrong wildly?

You have suggested to use either Smalltalk or Common Lisp. So you'll
get it and of course Smalltalk and Common Lisp will get blamed. Do you
think we appriciate that outlook?

Common Lisp was blamed before for the "failure of AI". Because Lisp
was the language of choice to that time. Of course it is unfair,
because to that time neither the power not the complexity of that
areas was none. The used Common Lisp for what it can be used best,
exploring new areas. Well the Common Lisp users have had the same
attitude to that time the "mainstream" languages user have today.

Hybris, well to put it more nicly extremly optimistic, today we have
another thing added the believe that programming is unimportant, just
put together a nice UML design and just let the "code monkeys" do the
programming. This attitude had got so on my nerves that I resigned
from the ACM. They always wrote about breathtaking abstract things and
spit out more wishiwashi as I could stand any longer.

Well they may be right sometimes but at least I have learned something
different. So have something you have to write/implement/comprehend it
yourself. That means you do have to make you hands dirty. Nothing has
give me more confidence in that I'm on the right track, but the first
principal working program, it can be as small as one can imagine, and
it can be written as bad as one can imagine, fact is: it worked.

I always try to make it as simple as I can, for that kind of working a
large kind of machinery is just a hindrance. Because of this I do like
languages which immediate feedback, languages in which I can try out
my ideas fast, even if I use "cathedral" languages like e.g Eiffel, I
try to get a running system up in which I then add features. I
ususally do not get things right from the start, but that's
independent of the language I use. Just over time and after some
versions am I satisfied with the result. I can not see how any work
can be done without such circles.

My strong opinion is that you have to start as small as possible. A
handful people, which shake out ideas try different approaches and
always accept they could be wrong is the best one can do to succeed in
the end.

Of course I accept that others have other idea and ideals, just this
group are about programming and I do expect to see passioned
programmers here. Or if you like that better practioners, I do not
expect a lot of working academics in comp.lang.smalltalk and
comp.lang.lisp. Because it's much more exiting and interesting to
write papers about "new" or re-invented things. What do we have seen
in the last few years: Java and .NET hype, Patterns, AOP, XML and and

Just see the now gone Hype of Patterns, a lot of patterns I have seen
are simply work-arounds of constraints in the diverse languages, they
are not necessary in less constrained languages.

If would have your choice. I would divide the task. Those who do not
have to learn the used language can start the migration and the others
will get though the used language and while learning they'd get some
"mini-projects of 'real-work'" from those who have started the
work. Of course I
would ask those who start on their estimates, if the constraints are
way too tigtht, it's better not to start....

Regards
Friedrich

-- 
Please remove just-for-news- to reply via e-mail.


Relevant Pages

  • Re: Paul Grahams Arc is released today... what is the long term impact?
    ... not mistaken Common Lisp was just a mash-up of many other lisps. ... was to combine the two languages. ... disagree with a lot about Arc, but to me it's Common Lisp 2, because ... What matters are concepts like functional programming, not concrete functional programming languages; object-oriented programming, not concrete object-oriented programming languages; imperative programming, not concrete imperative programming languages; programmable programming languages, not concrete programmable programming languages. ...
    (comp.lang.lisp)
  • Re: compiler for Chinese development language
    ... This relates to the development of vernacular ... Indian vernacular display, OS and programming languages. ... Bangla and other vernaculars. ...
    (comp.compilers)
  • Re: Head-in-the-Sand Liberals (LA Times Columnist)
    ... You claimed to have known several computer languages, ... If you lie about knowing computer languages, ... of the programming loop for a functional ... You also don't know Java. ...
    (rec.org.mensa)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • Re: GoTo in Java
    ... Scripting languages are programming languages; ... override the method.via an interface, or write a new method in the wrapper. ...
    (comp.lang.cobol)