Hi all,
I've helped write a C/C++ system for data acquisition and processing
that uses a number of software components to control external
instruments. My current favorite languages are Python and pure C.
Would Lisp be overkill or perhaps impractical to re-implement this kind
of a system? We have plugins, config files, plots and graphs, and
complex UI's as well.
jonathon
It is basically a question of which would be easier: accepting whatever
problems you are having now and just pushing forward, or pausing to
convert the entire system into a different language where such problems
would go away. In that case, we would need to know some background
about how hard it would be to make the conversion (how long/complex is
your program so far, how long did it take to write) and what sort of
problems you are having that made you consider changing languages.
My first impression from reading your post (plugins, config files,
plots and graphs, and
complex UI's as well) is that you are almost finished with development
because I would never consider adding a complex UI to a project until
everything else was complete and stable. You must have run into some
horrible issues to be considering starting over at such a point.
Another possibility, besides reimplementation, is to write just one
component in Lisp (whichever component is giving you trouble).
···········@bigfoot.com wrote:
> Would Lisp be overkill or perhaps impractical to re-implement this kind
> of a system? We have plugins, config files, plots and graphs, and
> complex UI's as well.
why do you want to implement it again? Of course, Lisp has many advantages
compared to C++, especially if the application has to be very dynamic and
configurable. For example something like LabVIEW should be really fun to
implement in Lisp and really a nightmare with C++. And you can use FFI to
access C libraries for hardware related stuff. But if you have a well
designed system already in C/C++ and it works, why not staying with this
system?
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
···········@bigfoot.com wrote:
> Hi all,
>
> I've helped write a C/C++ system for data acquisition and processing
> that uses a number of software components to control external
> instruments. My current favorite languages are Python and pure C.
>
> Would Lisp be overkill or perhaps impractical to re-implement this kind
> of a system? We have plugins, config files, plots and graphs, and
> complex UI's as well.
Hmmm. You worry about overkill and then seem to try to convey a complex
application. "Overkill" requires a powerful tool (requiring extra effort
to use) and a simple task. I am going to make a wild guess that you know
all that, and therefore (here is the leap) that you have the same
concern that I have run into before, viz., that Lisp is a difficult
language that pays off only when applied to non-deterministic
programming, AI, etc.
No. This is a strange thing to be saying, but at one level Common Lisp
is just an ordinary programming language, with all the usual programming
constructs such as iteration, a very nice object system, etc, etc. It
just does everything ten times better.
The hairier the system, the more benefit you will get out of porting to
Lisp. Others have wondered aloud why you are considering this, but the
mere fact that you are suggests you anticipate more development (or a
long lifetime, which will entail more development since software always
changes).
So run do not walk to Lisp, specifically Lispworks or AllegroCL/win32
(but get the runtime licensing negotiated with Franz before selecting
that tool).
As for the complex GUI, Adobe has just released Adam and Eve, a C++
combo offering a declarative model for building complex GUIs.
"Still, I am convinced that writing correct, high performance, and
feature rich systems can be orders of magnitude simpler than it
currently is. By my estimate, 70% of Adobe's current code base could be
better represented declaratively. The remaining imperative logic could
be largely generic - reused both within and across Adobe's applications.
Realizing even a fraction of this potential would open up a world of
opportunities. I strongly suspect the proportions are similar throughout
the industry."
-- http://opensource.adobe.com/asl_foreword.html
In Lisp you have Cells-Gtk:
http://common-lisp.net/project/cells-gtk/
The Abode report confirms my experience with Cells and various GUIs I
have built over the years.
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
To clarify, we have been working on the product for a few years, and
just shipped the first release last month. However, I have been
assigned to port just a few of the modules (using the same basic design
and architecture) to Linux for a particular customer. I was thinking
of a C++/Python combination, but I thought checking out Lisp wouldn't
hurt. I've come back to it several times, but never with enough
momentum to start. I *love* Python, but I can't get Lisp out of my
head. Of course, I also dread the learning curve with Lisp. I even
looked at SmallTalk, but it's too proprietary.
So, the existing project stands as-is. I'm thinking of Lisp for a Unix
port, basically.
On 2 Apr 2005 15:26:55 -0800, "jonathon" <···········@bigfoot.com>
wrote:
>momentum to start. I *love* Python, but I can't get Lisp out of my
>head. Of course, I also dread the learning curve with Lisp. I even
>looked at SmallTalk, but it's too proprietary.
Huh? You have comercial Smalltalks and OS ones, just as with CL.
Squeak, for instance, is open source and free.
>So, the existing project stands as-is. I'm thinking of Lisp for a Unix
>port, basically.
It probably would be a great projec for you to learn Lisp, but
consider it might take you more time than you expect, as you would be
learning the language.
Fernando wrote:
> On 2 Apr 2005 15:26:55 -0800, "jonathon" <···········@bigfoot.com>
> wrote:
>
>
>
>>momentum to start. I *love* Python, but I can't get Lisp out of my
>>head. Of course, I also dread the learning curve with Lisp. I even
>>looked at SmallTalk, but it's too proprietary.
>
>
> Huh? You have comercial Smalltalks and OS ones, just as with CL.
> Squeak, for instance, is open source and free.
Fine. But let's not pretend that Smalltalk is an alternative to a
serious language like CL. Smalltalk has no preprocessor, and only single
inheritance. It has many fine qualities, but will not scale to Real Work.
>
>
>>So, the existing project stands as-is. I'm thinking of Lisp for a Unix
>>port, basically.
>
>
> It probably would be a great projec for you to learn Lisp, but
> consider it might take you more time than you expect, as you would be
> learning the language.
Nah, Lisp is incredibly approachable. Note also that the OP is merely
doing a port, in which they need only translate FOR statements to LOOP
or DOTIMES or DOLIST. Sure, the superiority of Lisp will draw the OP
into some interesting rewriting, but that is optional; if they love
rewriting they can do it, if not they just do literal translation.
OK, sure, there is a learning effort, but catch a clue: the OP cannot
help thinking about a Lisp port. ie, this is someone who will actually
work faster in a new language, because they actually get a kick out of
learning new things and this will double their energy level.
Bottom line: a Lisp port will /accelerate/ the initial effort, then
benefit the enterprise going forward when the Lisp version gets ported
back to other OSes and lets them refine/extend the system ten times more
easily.
btw, anyone who thinks this is hype (a) has not actually programmed all
that much and (b) needs to read the RtL survey (see sig). This is
under-sell, not over-sell.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
On Sun, 03 Apr 2005 02:25:28 +0000, Kenny Tilton wrote:
> Fine. But let's not pretend that Smalltalk is an alternative to a
> serious language like CL. Smalltalk has no preprocessor, and only single
> inheritance. It has many fine qualities, but will not scale to Real
> Work.
Well I guess we all now know why cross-posting is bad.
BR wrote:
> On Sun, 03 Apr 2005 02:25:28 +0000, Kenny Tilton wrote:
>
>
>>Fine. But let's not pretend that Smalltalk is an alternative to a
>>serious language like CL. Smalltalk has no preprocessor, and only single
>>inheritance. It has many fine qualities, but will not scale to Real
>>Work.
>
>
> Well I guess we all now know why cross-posting is bad.
<g> I definitely checked to make sure there was none before posting that.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"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 <·······@nyc.rr.com>:
| Nah, Lisp is incredibly approachable. Note also that the OP is merely
| doing a port, in which they need only translate FOR statements to LOOP
| or DOTIMES or DOLIST.
"The determined real programmer can write
Fortran programs in any language."
(Newbies too young to recognize the quote should google it, then read
the article.)
| Sure, the superiority of Lisp will draw the OP into some interesting
| rewriting, but that is optional; if they love rewriting they can do it,
Which is probably the real reason why Kenny's advice is a good one?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Kenny Tilton <·······@nyc.rr.com> writes:
> Fernando wrote:
>> On 2 Apr 2005 15:26:55 -0800, "jonathon" <···········@bigfoot.com>
>> wrote:
>>
>>>So, the existing project stands as-is. I'm thinking of Lisp for a Unix
>>>port, basically.
>> It probably would be a great projec for you to learn Lisp, but
>> consider it might take you more time than you expect, as you would be
>> learning the language.
>
> Nah, Lisp is incredibly approachable. Note also that the OP is merely
> doing a port, in which they need only translate FOR statements to LOOP
> or DOTIMES or DOLIST. Sure, the superiority of Lisp will draw the OP
> into some interesting rewriting, but that is optional; if they love
> rewriting they can do it, if not they just do literal translation.
I have some concerns with this approach. In fact, I think it
contributes to the misinformation concerning Lisp and its relevance to
a modern world. I've seen ports of systems from C and other languages
which essentially just translated the code into lisp rather than
translating the algorithims etc. The result is a system which works,
but which doesn't take advantage of some of Lisps great
strengths. For example, ports which just translate C code into lisp
statements tend to not use macros and stay with the type of
abstraction which was fine for C but which can often be done far more
naturally with Lisp (or at least fit more closely to how humans think
about the problem).
Then, after doing all this, they often find the solution done in Lisp
is not as fast as the C version or they code themselves into a corner
in which it is much harder to do something and end up concluding all
the problems are due to the language rather than how it was used.
>
> Bottom line: a Lisp port will /accelerate/ the initial effort, then
> benefit the enterprise going forward when the Lisp version gets ported
> back to other OSes and lets them refine/extend the system ten times
> more easily.
Agree - but this only happens if the Lisp port is only a port of the
basic algorithm and not a mapping of C code to Lisp code in a 'dumb'
mode. If they re-implement the algorithms into Lisp, then they will
probably stand back and look in wonder at the power and simplicity and
start making plans to implement the original version in Lisp as well.
My only other concern would be maintenance overheads and availability
of skill sets. From a commercial perspective, these are important
issues. If one version of the software on one platform is written in a
totally diffeent language than other platform versions, you will need
a wider range of skill sets and probably two different maintenance
teams.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
As it stands now, I have a working prototype of the spinoff Linux
project. If I decide to do something in Lisp, I would probably do a
protoype on my own time, mostly for personal enrichment.
How difficult is it to change the mode of thinking to Lisp-style? As
in, changing algorithms rather than just porting code?
jonathon wrote:
> As it stands now, I have a working prototype of the spinoff Linux
> project. If I decide to do something in Lisp, I would probably do a
> protoype on my own time, mostly for personal enrichment.
>
> How difficult is it to change the mode of thinking to Lisp-style?
one thing that happens a lot is that one reinvents built-in functions,
not realizing they are already built-in. esp. coming from a low level
language like C. but the reinvention itself only takes a few minutes, so
one does not kick oneself too hard.
dropping the imperative style for a functional style was not too hard
for me, because I had been coding C in a functional style.
also, I am not sure there is a Lisp-style. I wish I had learned how
special variables work about seven years before I did, but then I also
wish I had learned loop seven years earlier, and that is just a fancy
iterator. and as I said, you should be coding C functionally already.
CLOS is cool, but you are not coming from an OO background it seems, so
there is not much baggage to forget.
the important thing to realize is that Lisp is multiparadigm and will
allow you to get Lispier (whatever that is) and Lispier over time. So
you will be forever looking back at code you wrote one or two months
earlier and just howling. but that is great fun, because the code at
which you will be howling will be solid code in any other language. The
howling just means you have learned how to marshall Lisp built-ins to
get the same done in two lines what your old code did in twenty.
if you really want to get up to speed fast, get one of Graham's books.
he writes nice code. emulate that. and if you write some code you hate,
post it here and say, "Lisp sucks! This is no better than C!" You will
instantly have a team of ten top Lispniks working for you for free
rewriting your code.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"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 wrote:
> CLOS is cool, but you are not coming from an OO background it seems,
so
> there is not much baggage to forget.
The actual project is written in C++. I've grown to hate C++ and
prefer C when I have the option. Otherwise, I prefer Python.
> get the same done in two lines what your old code did in twenty.
I *love* that. ATM, Python is doing that for me. But I am still
fascinated with Lisp.
> if you really want to get up to speed fast, get one of Graham's
books.
> he writes nice code. emulate that. and if you write some code you
hate,
He *did* make over $20 million, IIRC. I wouldn't mind emulating that
style.
"jonathon" <···········@bigfoot.com> writes:
> As it stands now, I have a working prototype of the spinoff Linux
> project. If I decide to do something in Lisp, I would probably do a
> protoype on my own time, mostly for personal enrichment.
>
> How difficult is it to change the mode of thinking to Lisp-style? As
> in, changing algorithms rather than just porting code?
>
Thats a difficult question. I think it depends on how you are coding
now - many people seem to code in a 'lispish' way even when doing C or
perl etc. If your one of these people, you'll find the transition
almost negligable - in fact, you will probably think "Ah, at last, a
language which works they way I like to work!". Otheres seem to
struggle a lot to get the hang of it.
When I started, I read and heard a lot about learning to think in a
lisp way - I never really understood what this meant and to be honest,
still struggle with it. My first Lisp attempts, when I look at them
now, are extremely funny or embarrasing - depending on my mood. Then
again, I can say the same about my first C, Pascal, Perl or
Java. However, often when I look at a problem someone has posted and
have a go at it, I've noticed my solutions are becoming more and more
similar to solutions posted by those with a lot more experience than
me, so I figure I'm moving in the right direction. I have noticed my
lisp has changed quite a lot - seem to be using 'if's and 'progn's a
lot less and my 'defun's are smaller. I'm also using macros quite a
bit more. I've not started looking at CLOS yet, though I'm beginning
to read about it a bit and getting more familiar with it etc.
So, I find it very
hard to define what "thinking in a lisp way is", but I do notice now
that when I have to work in C or Perl, I'm often cursing at how much
longer or more complicated things can be because I can see how to do
it in two or three lines with Lisp. I've also noticed my C and Perl
style changing a bit - less use of variables being passed around and
more nesting of procedures. for exmaple instead of doing (extreme
example to illustrate)
int x = foo(y);
bar(x);
I'm nore likely to just do
bar(foo(y));
I think probably the hardest thing I found about Lisp was just getting
to know the full breadth of functionality which was available in the
core language and also what was available in add-on packages. I found
macros conceptually straight-forward, but often got my self confused
when actually trying to use them. Usually, I just needed to step back
and think about what I was trying to do and soon I'd be back on track
again. For me, I found it important not to dive in too deeply with the
various features - a broad shallow knowledge of the language to start
with works better for me. Then, as I use the language and become more
familiar with it, I begin to develop depth of knowledge. Trying to go
too deeply into particular aspects of the language too early tends to
lead to confusion and loss of motivation. This is what made my first
few attempts fail. I then took a broad shallow approach and started
using the language for small to medium projects. I then found it
easier to get a depth of knowledge because often the more complex or
'advanced aspects began to make sense as they showed how to get around
problems I'd already encountered plus I would have a more sound
understanding of the bits I had already covered.
I still consider myself very much a novice. Nearly everytime I read
something in a book or even the hyperspec I learn something new even
though I may have already read it several times before. Its one of the
things I really like about learning Lisp - it just seems to continue
to offer more!
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
From: Duane Rettig
Subject: Re: Considering Lisp for project but not sure if it fits
Date:
Message-ID: <464z4478x.fsf@franz.com>
Tim X <····@spamto.devnul.com> writes:
> When I started, I read and heard a lot about learning to think in a
> lisp way - I never really understood what this meant and to be honest,
> still struggle with it. My first Lisp attempts, when I look at them
> now, are extremely funny or embarrasing - depending on my mood. Then
> again, I can say the same about my first C, Pascal, Perl or
> Java. However, often when I look at a problem someone has posted and
> have a go at it, I've noticed my solutions are becoming more and more
> similar to solutions posted by those with a lot more experience than
> me, so I figure I'm moving in the right direction. I have noticed my
> lisp has changed quite a lot - seem to be using 'if's and 'progn's a
> lot less and my 'defun's are smaller. I'm also using macros quite a
> bit more. I've not started looking at CLOS yet, though I'm beginning
> to read about it a bit and getting more familiar with it etc.
> So, I find it very
> hard to define what "thinking in a lisp way is", but I do notice now
> that when I have to work in C or Perl, I'm often cursing at how much
> longer or more complicated things can be because I can see how to do
> it in two or three lines with Lisp. I've also noticed my C and Perl
> style changing a bit - less use of variables being passed around and
> more nesting of procedures. for exmaple instead of doing (extreme
> example to illustrate)
I would characterize it as a matter of relaxation. If you have been
tense for a while, and a friend comes along and says "Relax!", what
is your first inclination? It will inevitably be to tense up in some
way. How do you describe relaxation to another? Relaxation is the
opposite of tension. But how do you communicate _how_ to relax? If
a person hasn't been relaxed for a while, it almost always leads to
the opposite.
In the same way, I view Lisp (and especially Common Lisp, where
everything is possible) to be everything other programming languages
are not; every restriction you've learned to code around in your
previous language, and every feature that other languages have that
simply aren't an issue in CL, must be "relaxed" away from in order to
understand the better ways of doing things. I think it would be
interesting for you to go back over your previous programs and determine
what it was that made you write that way; I think you would conclude
"well, I had thought that that was the way it had to be done". Now, as
you are learning more and more about the lack of restrictions in Lisp,
you can see how arbitrary these restrictions were, and how much they were
based on your experiences with previous languages.
I also have a hard time describing "the lisp way", though I can usually
recognize such coding. I can also recognize "Fortran in Lisp" and "C
in Lisp" styles - Usually, I judge code in terms of how restricted
it seems, and how much of another language's restrictions are being
assumed by the coder. Lispers try to write more beautiful code, and
code which is unencumbered by language restrictions, so it might be
that that could be a measure of how "lispy" the code is.
And yes, learning Lisp makes one a better programmer in other languages;
the liberation that comes with the idea that anything can be done in
any manner allows one to crash through the style ceilings that the other
languages pose on their users - such techniques might be viewed as
advanced, or unorthodox, or even radical and bad, by proponents of
those languages. Usually, though, it simply isn't noticed that the
code has become just a little more understandable and maintainable...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: André Thieme
Subject: Re: Considering Lisp for project but not sure if it fits
Date:
Message-ID: <d2p5s8$t7v$1@ulric.tng.de>
Duane Rettig schrieb:
> And yes, learning Lisp makes one a better programmer in other languages;
Hello Duane, I am not really certain that this is the case. In fact I
tend to say that knowing Lisp can make you /worse/ in other languages.
Why do I think that?
When one started to really really like Lisp it feels bad to program in a
different language. I think this strong preference for Lisp can cause
some psychologic effect which makes you program worse than you could.
Like a recalcitrant little kid one refuses to do something because it
cannot play with ones favourite tool. And I don't mean that as a joke, I
personally am affected by this problem. At work for example I have to
code a lot in PHP. This is so annoying that I am thinking about a
Lisp2PHP code-generator, so that I could code in Lisp.
Another thing: in Lisp several things are easy to do. When you are then
confronted with language XY, where these things are not so easy, you are
wondering how you can do what you want. A good XY programmer would have
already solved the task by applying some design patterns while the
lisper is still trying to figure out how stuff works and why he needs to
do it that (comlicated) way.
Andr�
--
+ Andr� Thieme <······························@justmail.de>:
| Another thing: in Lisp several things are easy to do. When you are
| then confronted with language XY, where these things are not so
| easy, you are wondering how you can do what you want.
By invoking Greenspun's tenth?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
> few attempts fail. I then took a broad shallow approach and started
> using the language for small to medium projects. I then found it
What's a good example of small to medium projects that are suited to
Lisp? I don't think it would be wise to jump right into GUI apps, but
at the same time, are there practical console apps that would be good
to start with?
When I started Python, I wrote a backup program (console) and a
checkbook program (gtk). Then I started porting the app from work,
which was much more complex, of course.
What kind of app would be good for learning Lisp and useful as well?
>What's a good example of small to medium projects that are
>suited to Lisp?
>...
>What kind of app would be good for learning Lisp and useful as well?
Practical Common Lisp covers many small projects, using them as
examples of how to approach problems in Lisp. It won't be published for
another week, but it is available online now:
www.gigamonkeys.com/book
I am also just getting started with Lisp, and my small projects are
school assignments. I've decided to do all of my nuclear reactor
analysis programs in Lisp. The first one was very hard because I needed
arrays but hadn't learned how to use them yet. Doing the same thing
with lists got weird. Now I'm working on the second, which, now that
I've learned a bit more, is probably going to turn out FORTRAN-style.
Slow and steady...
jonathon <···········@bigfoot.com> wrote:
+---------------
| > few attempts fail. I then took a broad shallow approach and started
| > using the language for small to medium projects. I then found it
|
| What's a good example of small to medium projects that are suited to
| Lisp? I don't think it would be wise to jump right into GUI apps, but
| at the same time, are there practical console apps that would be good
| to start with?
+---------------
I had used Scheme for some years before switching to Common
Lisp, but my first major app in Common Lisp was was a web-based
front-end to a "contact information" database for a non-profit.
I used Apache + CMUCL + PostgreSQL. In CMUCL, I used Tim Bradshaw's
HTOUT to generate the HTML [though CL-WHO or maybe others
(see <http://www.cliki.net/Web>) would have worked] and Eric
Marsden's PG (see <http://www.cliki.net/database>) to talk to
the database. Lisp was a real win for this.
If you do decide on doing a web app, you should also look at
"mod_lisp" and "cl-modlisp" (see CLiki "Web" topic, above) for
doing the Apache to Common Lisp interface. [I *didn't* use it,
for organizational reasons (I didn't control the Apache server),
but I used a very similar Apache-to-CL protocol style.]
Even if you don't do something that complex, certainly look
at using CL to write simple web-based apps. A web browser
is certainly simplest GUI to get going! ;-} ;-} A small
example is at <http://rpw3.org/hacks/lisp/appsrv-demo.lhp>.
+---------------
| When I started Python, I wrote a backup program (console) and a
| checkbook program (gtk). Then I started porting the app from work,
| which was much more complex, of course.
+---------------
Well, I also do a lot of small/tiny/toy "scripting" in Lisp,
e.g.: a CLX-based "sysmeter" clone (works in both CMUCL & CLISP),
a random filename generator (for coming up with high-entropy
passwords and obfuscated URLs), a "ketogenic ratio" calculator
(helps with a low-carb diet):
$ random
····@WLauqSRdGiJ
$ random
XdUYZ7csRnTfltaR
$ random
·······@Uk15jZLj
$ keto 8 6 14 # almonds
grams: protein 8 carb 6 fat 14
ketogenic ratio: 1.3890784
total calories: 182
$
I prefer it to Perl since I can still *read* it six months later! ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
The gigamonkeys book is proving to be VERY helpful. That one earns a
bookmark.
Here's one more question... actually, this is one reason why I tried
Python instead. But I'm still not sure yet.
Ever seen this quote?
---------------
Old LISPer that I am, I also looked at various current dialects of Lisp
and Scheme--but, as is historically usual for Lisp, lots of clever
design was rendered almost useless by scanty or nonexistent
documentation, incomplete access to POSIX/UNIX facilities, and a small
but nevertheless deeply fragmented user community.
---------------
Does this argument still have any merit?
"jonathon" <···········@bigfoot.com> writes:
> The gigamonkeys book is proving to be VERY helpful. That one earns a
> bookmark.
If it is proving to be VERY useful, it should earn something more,
perhaps a purchase.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
jonathon <···········@bigfoot.com> wrote:
+---------------
| Ever seen this quote?
| Old LISPer that I am, I also looked at various current dialects of Lisp
| and Scheme--but, as is historically usual for Lisp, lots of clever
| design was rendered almost useless by scanty or nonexistent
| documentation, incomplete access to POSIX/UNIX facilities, and a small
| but nevertheless deeply fragmented user community.
| Does this argument still have any merit?
+---------------
As an "argument", it never did, since there's no sense arguing about
which language works for you (or not).
As a criticism of the state of things, I suspect that some parts of
it were once more-or-less valid, but suggest that things have gotten
a lot better recently, at least in the Common Lisp community [which
is a *completely* different community than the Scheme community, even
though come people consider themselves to hold dual citizenship --
see <http://www.nhplace.com/kent/PS/Lambda.html> for more]. We have
much more community-based help for tools, libraries, packages, etc.:
<http://www.cliki.net/index>
<http://www.cliki.net/cCLan>
<http://sourceforge.net/projects/clocc>
And of course this newsgroup and various mailing lists (and IRC,
see "irc.freenode.net/#lisp").
So if you want to try Coommon Lisp, there's certainly enough help
available...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> jonathon <···········@bigfoot.com> wrote:
>
> I prefer it to Perl since I can still *read* it six months later! ;-}
>
Wow, thats sort of one of the reasons I got interested in Lisp. I
actually liked perl - still do in some ways. For a few years I worked
alone and coded away in Perl. Then I got to work on a team with
everyone using Perl - it only took a few weeks before I started
cursing the "do it your way" approach of perl. I liked this initially,
but once you work with a lot of others who are all doing it their way
and you have a system full of different styles, it becomes a
nightmare.
Somehow, lisp lets me stil do it my way, but I can read my code easily
and more importantly when working with a team, you can all understand
each others code easily and quickly - no spending hours trying to
disassemble some cryptic piece of code which looks like line noise
that someone has written to show how clever they are. In Lisp, I often
see very clever bits of code, but I can always understand what is - it
may take me some pondering before I truely appreciate its elegance or
understand exactly what it does - but at least I *can* read it!
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Tim X wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>
>>Fernando wrote:
>>
>>>On 2 Apr 2005 15:26:55 -0800, "jonathon" <···········@bigfoot.com>
>>>wrote:
>>>
>
>
>>>>So, the existing project stands as-is. I'm thinking of Lisp for a Unix
>>>>port, basically.
>>>
>>>It probably would be a great projec for you to learn Lisp, but
>>>consider it might take you more time than you expect, as you would be
>>>learning the language.
>>
>>Nah, Lisp is incredibly approachable. Note also that the OP is merely
>>doing a port, in which they need only translate FOR statements to LOOP
>>or DOTIMES or DOLIST. Sure, the superiority of Lisp will draw the OP
>>into some interesting rewriting, but that is optional; if they love
>>rewriting they can do it, if not they just do literal translation.
>
>
> I have some concerns with this approach. In fact, I think it
> contributes to the misinformation concerning Lisp and its relevance to
> a modern world. I've seen ports of systems from C and other languages
> which essentially just translated the code...
sure, but I was reading between the lines and the OP was clearly turning
to lisp to see what lisp is all about. that type of mindset does not
actually end up transliterating, even when they try not to get sucked
into rewriting. been there, done that. i was just pointing out that the
transliteration opiton was there for someone looking for the quickest
port. ie, lisp does not /force/ you into a paradigm shift, because it is
itself multi-paradigm.
> My only other concern would be maintenance overheads and availability
> of skill sets. From a commercial perspective, these are important
> issues. If one version of the software on one platform is written in a
> totally diffeent language...
again, reading between the lines, I sensed a search for A Better
Way(tm), which if successful would lead to all-lisp-all-the-platforms.
kt
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"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 <·······@nyc.rr.com> writes:
> Fernando wrote:
> > On 2 Apr 2005 15:26:55 -0800, "jonathon" <···········@bigfoot.com>
> > wrote:
> >
> >>momentum to start. I *love* Python, but I can't get Lisp out of my
> >>head. Of course, I also dread the learning curve with Lisp. I even
> >>looked at SmallTalk, but it's too proprietary.
> > Huh? You have comercial Smalltalks and OS ones, just as with CL.
> > Squeak, for instance, is open source and free.
>
> Fine. But let's not pretend that Smalltalk is an alternative to a
> serious language like CL. Smalltalk has no preprocessor, and only
> single inheritance. It has many fine qualities, but will not scale to
> Real Work.
What a load of rubbish! Did you teleport to an alternate universe and
forget to reset your brain on return?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Fernando wrote:
>>
>>>On 2 Apr 2005 15:26:55 -0800, "jonathon" <···········@bigfoot.com>
>>>wrote:
>>>
>>>
>>>>momentum to start. I *love* Python, but I can't get Lisp out of my
>>>>head. Of course, I also dread the learning curve with Lisp. I even
>>>>looked at SmallTalk, but it's too proprietary.
>>>
>>>Huh? You have comercial Smalltalks and OS ones, just as with CL.
>>>Squeak, for instance, is open source and free.
>>
>>Fine. But let's not pretend that Smalltalk is an alternative to a
>>serious language like CL. Smalltalk has no preprocessor, and only
>>single inheritance. It has many fine qualities, but will not scale to
>>Real Work.
>
>
> What a load of rubbish! Did you teleport to an alternate universe and
> forget to reset your brain on return?
Just the opinion of one simple application programmer. And his monkeys.
:)
kenny
--
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
"Doctor, I wrestled with reality for forty years, and I am happy to
state that I finally won out over it." -- Elwood P. Dowd
"jonathon" <···········@bigfoot.com> writes:
> To clarify, we have been working on the product for a few years, and
> just shipped the first release last month. However, I have been
> assigned to port just a few of the modules (using the same basic design
> and architecture) to Linux for a particular customer. I was thinking
[snip]
> So, the existing project stands as-is. I'm thinking of Lisp for a Unix
> port, basically.
While I'd love to say do it in Lisp, given that you already have a
win32 version and you are talking about a port to another
architecture, I really wouldn't advise it. In fact, if one of my team
approach me with such a suggestion I'd suspect they were perhaps a
little over worked and needed to take a holiday!
My problem here is that you would be creating a new different version
of the software, which would concern me from a long term maintenance
perspective. I realise that if you use something like C or C++, you
still have bits which would be unique to the different platforms and
you would experience different bugs on the different platforms, but
essentially, it would still be the same code base.
The other problem I can see is that if you use Lisp for the Linux port
and C for the win32 port, you are also likely to find the versions
diverging as some things become easier or possible on one plaform than
the other.
In summary, I'd only recommend a Lisp implementation if you are
planning to use it on all platforms the software is going to be
available for - otherwise your maintenance overheads are likely to
blow out.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
"jonathon" <···········@bigfoot.com> writes:
> and architecture) to Linux for a particular customer. I was thinking
> of a C++/Python combination, but I thought checking out Lisp wouldn't
> hurt. I've come back to it several times, but never with enough
> momentum to start. I *love* Python, but I can't get Lisp out of my
> head. Of course, I also dread the learning curve with Lisp. I even
If you want to give Lisp another try, not necessarily for your porting
project, you may check this book:
Practical Common Lisp
http://www.gigamonkeys.com/book/
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
From: Ulrich Hobelmann
Subject: Re: Considering Lisp for project but not sure if it fits
Date:
Message-ID: <3bbi9fF6i6a93U1@individual.net>
jonathon wrote:
> So, the existing project stands as-is. I'm thinking of Lisp for a Unix
> port, basically.
>
Hm, if I assume that you have a C or C++ version running for
windows, it would be a lot easier to just recode the GUI layer on
GTk or Qt for Unix (but be aware of the Qt license; if you aren't
open source, you need to pay for a license).
Lisp might rock, and it doesn't hurt you to learn it ;) but you'd
need to port the GUI anyway, so why not just do that??