Hi.
I'm studing the 3th. curse of my carreer, I have to do a proyect in Lisp,
but the problem is that I haven't got any idea. I've programed a lot in C,
and another languages. and I see that the Lisp language is very simple,
very poor.
If anybody have a proyect, please, send me it.
I would be very thankful.
Thanks
please .. the answer by e-mail (·········@NEXO.ES)
Bye.
In article <···························@dcervinoredestb>, "David Cervino" <·········@NEXO.ES> writes:
> Hi.
>
> I'm studing the 3th. curse of my carreer, I have to do a proyect in Lisp,
> but the problem is that I haven't got any idea. I've programed a lot in C,
^^^^^^^^^^^^^^^^^^^^^^^^^
Are you sure? I mean if you haven't used lisp, how can you be programming?
Hacking, maybe, but *programming*? ;)
To answer your request for a project, here are some, in increasing order of
difficulty ...
(1) A symbolic differentiator
(2) A symbolic integrator
(3) A prolog interpreter
(4) A non programming project in which you really learn about lisp and write a
report documenting its strengths and weaknesses.
There's also a nice book called Building Problem Solvers which might give you
some ideas for more application-oriented projects.
> and another languages. and I see that the Lisp language is very simple,
> very poor.
>
Helpful hint: Unless you're interested in starting a flame war, DON'T post to a
newsgroup called "comp.lang.lisp" if you intend to be disparaging about the
subject of discussion. Or, if you do, at least be sure that you have decent
substantiating arguments. How about ANY substantiating arguments?
If you think lisp is simple, it is. Simple to understand for a mathematician
(though I'm not one!)
However, this kind of simplicity isn't actually a bad thing. In contrast,
given that the common lisp standard has just about the largest set of functions
and datastructures of any high level language, I would claim that it is rather
complex!
Poor? Well, that's a matter of opinion, I suppose. There are inevitably
tradeoffs implicit in a language that offers the flexibility of lisp, so whether
it suits you or not is going to depend on your needs and your programming biases.
For my part, programming in lisp removes much of the overhead that's involved
with using other languages such as C. Typically, because I now have, with lisp,
a wide choice of datastructures and functions to manipulate them, I can focus on
the best representation and algorithms to use, rather than on implementational
details. Almost without exception, code I write in lisp tends to be faster
overall, simply because I have been able to write it better. Then again, this is
probably because I'm a shitty C/C++ programmer...
Good luck!
Rama Lakshmanan
In article <··········@teith.chemeng.ed.ac.uk>,
Ramachandran Lakshmanan <····@chemeng.ed.ac.uk> wrote:
>
>There's also a nice book called Building Problem Solvers which might give you
>some ideas for more application-oriented projects.
>
Seems like a very interesting book.
The authors mention that the accompanying code is available
at an unspecified ftp site -- unspecified because they find
ftp locations to be too impermanent to be set down in a
book. They ask the reader to email them directly for the
current location of the code. I did, but perhaps because
email addresses are equally impermanent, I haven't been able
to get a response. Does anyone know if and where the code
is available on the Net?
--d
* Dorai Sitaram
| Seems like a very interesting book.
I can vouch for that.
| The authors mention that the accompanying code is available at an
| unspecified ftp site -- unspecified because they find ftp locations to be
| too impermanent to be set down in a book. They ask the reader to email
| them directly for the current location of the code. I did, but perhaps
| because email addresses are equally impermanent, I haven't been able to
| get a response. Does anyone know if and where the code is available on
| the Net?
when I asked the authors back in october, 1994, the answer was
parcftp.xerox.com in /pub/bps. the files are still there.
#\Erik
--
hypertext -- too much text.
hypotext -- too little text.