Mark Carter wrote:
> Interestingly, Perl, PHP, Python and Ruby are all driven by a central
> character determined to make their respective language a success.
Maybe
> that is what's lacking in Lisp.
You are indeed correct, it is lacking in lisp. However, an alternate
view is these languages could not possibly survive without central
characters, since the language can only be meaningfully extended by
central designers.
Therefore that person's caring is a precondition for success. The term
"benevolent dictator" is most telling. Dictatorships can be successful
with the right dictators. I believe Hammurabi, Charlemangne and Vlad
Tepes (Dracula) are considered good. (Though yes, punishments could
definitely be severe.)
A republic is a bit different, where the president is a salaried public
servant. I think such decentralized bodies can let people specialize in
what they want, without having to be "personalities." So someone like
Paul Graham can come along, who attracts those interested in
personalities, and he can spend his time writing essays and doing R&D,
instead of working on CL.
> Ruby certainly seems to be gaining momentum, and it will be
interesting
> to see how well adopted it is in a few years time. Perhaps it will
have
> to overcome the inertia of the Perl, PHP and Python advocates who
will
> want to know the answer to the question of Why Another Language. Has
> anyone noticed any particular takeup or slowdown in Lisp's popularity
> over the past couple of years?
I hope Ruby gains more success. I like its flexibility, though
admittedly my only real Ruby knowledge came when I looked into its
"code blocks" and links to Smalltalk.
Tayssir John Gabbour wrote:
> I hope Ruby gains more success. I like its flexibility, though
> admittedly my only real Ruby knowledge came when I looked into its
> "code blocks" and links to Smalltalk.
Ruby is my favorite scripting language, bar none. It is all the power
of Perl with all the readability of Python and all the not really caring
about whitespace of C. I've even written a solar system simulator in
Ruby, I liked it so much.
But I haven't used it much lately, spending my hobby coding time
learning Lisp. I wish I had a reasonable-sized project to attempt in
Lisp, though, as everything I have now is either too small or far too
big for my free time to accommodate.
As a long-time C and C++ programmer, Lisp and Ruby are the only
languages that have in any real way excited me in the past 5 years. C#
kind of does with some of its syntactic sugar, but Ruby gets you the
same sugar and CLOS overcomes C++ as the most powerful object-oriented
system I know.
Ari Johnson <·····@hotmail.com> wrote in message news:<·················@lakeread01>...
> But I haven't used it much lately, spending my hobby coding time
> learning Lisp. I wish I had a reasonable-sized project to attempt in
> Lisp, though, as everything I have now is either too small or far too
> big for my free time to accommodate.
It's not super big, but have you considered writing an exterior
balistics calculator in Lisp?
·····@david-steuber.com (David Steuber) writes:
> Ari Johnson <·····@hotmail.com> wrote in message
> news:<·················@lakeread01>...
>> But I haven't used it much lately, spending my hobby coding time
>> learning Lisp. I wish I had a reasonable-sized project to attempt in
>> Lisp, though, as everything I have now is either too small or far too
>> big for my free time to accommodate.
>
> It's not super big, but have you considered writing an exterior
> balistics calculator in Lisp?
The OP could also consider using the problems from the ACM programming
contest. The resulting programs will be small, but the problems are
sufficiently interesting to afford good experience to someone learning
a new language.
--
John M. Adams
John M. Adams wrote:
> ·····@david-steuber.com (David Steuber) writes:
>
>
>>Ari Johnson <·····@hotmail.com> wrote in message
>>news:<·················@lakeread01>...
>>
>>>But I haven't used it much lately, spending my hobby coding time
>>>learning Lisp. I wish I had a reasonable-sized project to attempt in
>>>Lisp, though, as everything I have now is either too small or far too
>>>big for my free time to accommodate.
>>
>>It's not super big, but have you considered writing an exterior
>>balistics calculator in Lisp?
>
>
> The OP could also consider using the problems from the ACM programming
> contest.
Newbies who know C should create a set of bindings to the library they
will miss most if they switch to Lisp. The C knowledge will make UFFI
easy to understand, they will not have to learn all that much Lisp, they
will solve a problem for themselves (that of losing access to the
library), they can count on help from Lisp gurus since they are making a
contrib to Lisp, the proof-of-concept demo will be hefty enough to teach
them some Lisp but need not be so ambitious as to be intractable, and
they go from newbie to the Lisp Hall of Fame in a month. My2.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> Newbies who know C should create a set of bindings to the library they
> will miss most if they switch to Lisp. The C knowledge will make UFFI
> easy to understand, they will not have to learn all that much Lisp,
> they will solve a problem for themselves (that of losing access to the
> library), they can count on help from Lisp gurus since they are making
> a contrib to Lisp, the proof-of-concept demo will be hefty enough to
> teach them some Lisp but need not be so ambitious as to be
> intractable, and they go from newbie to the Lisp Hall of Fame in a
> month. My2.
I've been playing with Bosco by Mikel Evans. I've actually been
stalled a bit lately because of real life stuff. Also I'm very slowly
making my way through Keene's CLOS book. A framework for OpenMCL that
wraps Carbon may be useful.
Although I'm not sure whether application frameworks are really
worthwhile. And Lisp seems to make them that much less valuable as
the preferred style seems to be building the language up to the
program domain. The Carbon API (or Cocoa for that matter) has the
stuff for doing GUIs.
I thought the OP would find an Exterior Ballistics Calculator useful
as I know I would. I can't get Internet out on the range.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> wrote in message news:<··············@david-steuber.com>...
> Although I'm not sure whether application frameworks are really
> worthwhile. And Lisp seems to make them that much less valuable as
> the preferred style seems to be building the language up to the
> program domain.
Application frameworks are just a method of building up the language
to the highest common point between programs designed to do whatever
_____ application framework helps with.
I think that such things are more valuable for Lisp, not less, since
they can be much more flexible than is typical in other languages,
and therefore can apply more broadly, or at a higher level in the
current application, saving work for the second app, et al.
Or maybe I misunderstood you. :)
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
·······@randallsquared.com (Randall Randall) writes:
> David Steuber <·····@david-steuber.com> wrote in message news:<··············@david-steuber.com>...
> > Although I'm not sure whether application frameworks are really
> > worthwhile. And Lisp seems to make them that much less valuable as
> > the preferred style seems to be building the language up to the
> > program domain.
>
> Application frameworks are just a method of building up the language
> to the highest common point between programs designed to do whatever
> _____ application framework helps with.
>
> I think that such things are more valuable for Lisp, not less, since
> they can be much more flexible than is typical in other languages,
> and therefore can apply more broadly, or at a higher level in the
> current application, saving work for the second app, et al.
It's possible that I am still missing something of the Lisp Way.
In other languages like C++, Objective-C, and probably others, a
common tool to use is a WYSIWYG GUI builder. Interface Builder for OS
X is a good example. It is used with Xcode and the two tools end up
generating some boiler plate code for you to then edit.
What I would like to see is no need for generating so much as a single
line of boiler plate. I see it as messy. It smacks of copy and
paste.
Idealy, every line of code I write for my application should be
application specific. That includes the other code in my files.
There should be no pasted code. I don't know how close it is possible
to come to that ideal. There are probably user interactions with the
menus and other GUI elements that have to be dealt with every time.
I guess your definition of a framework has a more useful meaning than
what I was thinking of. I also have a fairly strong association
between framworks and OS features like Win32, Carbon, Cocoa, what have
you. I know further abstraction is possible as CLIM and TrollTech's
Qt C++ library have shown.
Right now I'm working on learning the Carbon API in C with the intent
of transferring that knowledge to Lisp using OpenMCL. I would like to
use Interface Builder for designing the GUI stuff in a Lisp
application for OS X. Throw in some CLOS and maybe that can take me
somewhere.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> wrote in message news:<··············@david-steuber.com>...
> ·······@randallsquared.com (Randall Randall) writes:
> > I think that such things are more valuable for Lisp, not less, since
> > they can be much more flexible than is typical in other languages,
> > and therefore can apply more broadly, or at a higher level in the
> > current application, saving work for the second app, et al.
>
> It's possible that I am still missing something of the Lisp Way.
No clue. Your Way is undoubtedly stronger than mine; I've only
been seriously doing Lisp for five months. :)
> In other languages like C++, Objective-C, and probably others, a
> common tool to use is a WYSIWYG GUI builder. Interface Builder for OS
> X is a good example. It is used with Xcode and the two tools end up
> generating some boiler plate code for you to then edit.
>
> What I would like to see is no need for generating so much as a single
> line of boiler plate. I see it as messy. It smacks of copy and
> paste.
Oh, this isn't what I was referring to, and I didn't understand
that it was what you meant. What I was talking about was a set
of functions and/or objects that do the drudgery of low-level things
in an application, leaving only the things essential to that app.
For instance, web application frameworks like UnCommon Web by Marco
Baringer, or my own PSILISP (both of which are in a rather early
state, in my opinion).
> Idealy, every line of code I write for my application should be
> application specific. That includes the other code in my files.
> There should be no pasted code. I don't know how close it is possible
> to come to that ideal. There are probably user interactions with the
> menus and other GUI elements that have to be dealt with every time.
Well, in PSILISP, there are a coupla macros, deform and with-form, that
handle a lot of the things you'd have to write over and over when getting
input from a user, so, when it's closer to 1.0, you wouldn't have to
bother with anything but specifying the kind of data you want from the
user of the app. My vision of application frameworks is like that; they're
just a way to build up the language so that some things never have to be
written again.
--
Randall Randall <·······@randallsquared.com>
Property law should use #'EQ , not #'EQUAL .
David Steuber wrote:
> ·······@randallsquared.com (Randall Randall) writes:
>
>
>>David Steuber <·····@david-steuber.com> wrote in message news:<··············@david-steuber.com>...
>>
>>>Although I'm not sure whether application frameworks are really
>>>worthwhile. And Lisp seems to make them that much less valuable as
>>>the preferred style seems to be building the language up to the
>>>program domain.
>>
>>Application frameworks are just a method of building up the language
>>to the highest common point between programs designed to do whatever
>>_____ application framework helps with.
>>
>>I think that such things are more valuable for Lisp, not less, since
>>they can be much more flexible than is typical in other languages,
>>and therefore can apply more broadly, or at a higher level in the
>>current application, saving work for the second app, et al.
>
>
> It's possible that I am still missing something of the Lisp Way.
>
> In other languages like C++, Objective-C, and probably others, a
> common tool to use is a WYSIWYG GUI builder. Interface Builder for OS
> X is a good example. It is used with Xcode and the two tools end up
> generating some boiler plate code for you to then edit.
>
> What I would like to see is no need for generating so much as a single
> line of boiler plate. I see it as messy. It smacks of copy and
> paste.
This is not a "Lisp Way" issue. Case in point: AllegroCL/win32 has an
interactive GUI builder. But you do not have to use it to use the Common
Graphics application framework, itself a relatively thin layer atop
win32 GDI.
My feeling is that GUI builders exist because most application
frameworks are hard to learn. And I agree, they offer their own set of
negatives.
Where Lisp per se can win is by offering a better solution than
interactive GUI building. A little macrology can provide the same boiler
plate generated by the GUI builder, so that, yes, all the code is
"yours", because the boiler plate goes away when the developer feels
confident enough to toss in their own code.
My frameworks offer a macro such as:
(make-stack ()
(widget...)
(widget...))
When it is time to get fancy:
(make-stack (:justify :right :spacing 24 :outset 12)
(widget...)
(widget...))
make-stack is an insanely thin wrapper for:
(make-instance 'stack-frame....)
because I have learned the hard way not to cripple the flexibility and
extensibility of my code by smothering the OO. basically, if one knows
CLOS and can work out the semantics of the slots of the various
framework classes, one is good to go, even where one wants to wreak
havoc with my design choices and go in a different direction than I had
in mind.
When I see CLIM code, I wonder if that is not the mistake that was made.
Here is this lovely, superpowerful macro def-whatever, and it is utterly
opaque, though CLOS is under there somewhere. But CLOS is not what one
needs to learn; one needs to learn some new embedded language. But I
digress.
kt
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton <·······@nyc.rr.com> writes:
> When I see CLIM code, I wonder if that is not the mistake that was made.
> Here is this lovely, superpowerful macro def-whatever, and it is utterly
> opaque, though CLOS is under there somewhere. But CLOS is not what one
> needs to learn; one needs to learn some new embedded language. But I
> digress.
They're not specified to be opaque, for the macros I know off the top of
my head in CLIM. There is an object that is created that you can
manipulate procedurally, and you can subclass the type involved and
create your own behaviors. Of course, I don't recall the DEF-WHATEVER
macro in CLIM, but maybe you're thinking of DWIM. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist