top down programming in a bottom up language
Jeff
that they quite often develop in a sort of top down fashion, letting
the debugger take them where they need to be. For example, if they
are writing some code that needs to lookup an item in a database and
then manipulate it, they would create the function and write the
function calls to do the work they need:
(defun example (query)
(let ((record (db-query query))
....
(process-query record)))
Then they compile, and the debugger tells them that the function db-
query does not exist. From there they can choose to implement the
function, and then once implemented continue on. What's cool is that
while they are implementing the db-query function there is a live
query object available to look at and play with. Once continuing they
do the same with process-query, and finally it's all running. This
sort of like an interactive, top-down development seems very
intriguing, and I was wondering if people have done this in lisp
(slime), or for that matter if it would be possible.
On a related note, are there any open source lisp environments that
let you browse packages, refactor, inspect like in a smalltalk
environment? I think lispworks might do this, but I'm a free-
wheeling, open-source hippy so I'd rather stick to open tools.
Cheers,
Jeff
Pascal J. Bourguignon
Where do you think those smalltalk designer guys got the idea from?
C/USER1[105]> (defun example (query)
(let ((record (db-query query)))
(process-query record)))
EXAMPLE
C/USER1[106]> (example "select * from employee")
*** - EVAL: undefined function DB-QUERY
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'DB-QUERY).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (FDEFINITION 'DB-QUERY).
ABORT :R4 ABORT
C/Break 1 USER1[107]> :r3
New (FDEFINITION 'DB-QUERY): #.(lambda (query) "run the query and returns a list of row" (block db-query (return-from db-query (list (list 1 "Jane" "Doe" 55000.00) (list 3 "John" "Doe" 54000.00)))))
*** - EVAL: undefined function PROCESS-QUERY
The following restarts are available:
USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'PROCESS-QUERY).
RETRY :R2 Retry
STORE-VALUE :R3 You may input a new value for (FDEFINITION 'PROCESS-QUERY).
ABORT :R4 ABORT
C/Break 1 USER1[108]> :r3
New (FDEFINITION 'PROCESS-QUERY): #.(lambda (rows) "processes the rows" (block process-query (format t "~{~4D ~20A ~20A ~12,2$~%~}" rows)))
(1 Jane Doe 55000.0) (3 John Doe 54000.0)
*** - There are not enough arguments left for this format directive.
Current point in control string:
~{~4D ~20A ~20A ~12,2$~%~}
|
The following restarts are available:
ABORT :R1 ABORT
C/Break 1 USER1[109]> :r1
C/USER1[110]> (defun process-query (rows) "processes the rows" (format t "~:{~4D ~20A ~20A ~12,2$~%~}" rows))
PROCESS-QUERY
C/USER1[111]> (example "select * from employee")
1 Jane Doe 55000.000000000000
3 John Doe 54000.000000000000
NIL
C/USER1[112]>
--
__Pascal Bourguignon__
Mark Tarver
A friend of mine who introduced me to Lisp back in the 80s programmed
like this and spent his time in the Lisp debugger responding to
'please define this' queries. He used Rutgers DEC-10 Lisp which I
remember as being a very nice environment.
I always work top down; its very natural for hard problems see
http://www.lambdassociates.org/webbook/chap9.htm
Mark
Jeff
wrote:
Cool! Which lisp are you using? This looks like it's close, but
ideally it would be integrated into slime so you could save the text
of your implementations in the correct place rather than having them
lost in the image. Is there a way to determine where the code lives,
or at least save it afterwards?
Currently when I do the same thing in slime using SBCL I get this:
The function DB-QUERY is undefined.
[Condition of type UNDEFINED-FUNCTION]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
"worker" {B82D8D1}>)
Ideas?
-Jeff
Peter Hildebrandt
wrote:
> p...@informatimago.com (Pascal J. Bourguignon) writes:
>>
>> C/USER1[105]> (defun example (query)
>> (let ((record (db-query query)))
>> (process-query record)))
>
> yes, that works nicely in slime/clisp.
Any ideas how to make this work with sbcl? The only options I see in the
slime debugger are
------
The function PROCESS is undefined.
[Condition of type UNDEFINED-FUNCTION]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{A83EC11}>)
------
Suggestions?
I know that I should ask this question on the slime and/or sbcl lists.
But maybe I can get a quick answer here ...
Peter
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Pascal J. Bourguignon
> On Jan 18, 11:49 am, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> *** - EVAL: undefined function PROCESS-QUERY
>> The following restarts are available:
>> USE-VALUE :R1 You may input a value to be used instead of (FDEFINITION 'PROCESS-QUERY).
>> RETRY :R2 Retry
>> STORE-VALUE :R3 You may input a new value for (FDEFINITION 'PROCESS-QUERY).
>> ABORT :R4 ABORT
>> C/Break 1 USER1[108]> :r3
>> New (FDEFINITION 'PROCESS-QUERY): #.(lambda (rows) "processes the rows" (block process-query (format t "~{~4D ~20A ~20A ~12,2$~%~}" rows)))
>> (1 Jane Doe 55000.0) (3 John Doe 54000.0)
>
> Cool! Which lisp are you using? This looks like it's close, but
> ideally it would be integrated into slime so you could save the text
> of your implementations in the correct place rather than having them
> lost in the image. Is there a way to determine where the code lives,
> or at least save it afterwards?
>
> Currently when I do the same thing in slime using SBCL I get this:
>
> The function DB-QUERY is undefined.
> [Condition of type UNDEFINED-FUNCTION]
>
> Restarts:
> 0: [ABORT] Return to SLIME's top level.
> 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
> "worker" {B82D8D1}>)
>
> Ideas?
I used clisp. I guess the restarts don't depend on slime, but on the
implementation, even if you can add new restarts.
When working with separate source files, instead of giving directly
the function with #.(lambda ...), you could, while in the debugger,
define the function as usual, in your source, and have slime send it
to the implementation, and then tell the restart to use
#.(fdefinition 'query-db)
clisp also has these restarts available as soon as there is an eval
frame on the stack:
Redo :rd re-evaluate form in EVAL frame
Return :rt leave EVAL frame, prescribing the return values
so even if the error is not a function undefined error, you can
redefine some functions in the debugger, and either redo the current
form or return, and let it call the new functions in the next
iteration.
Finally, if you like smalltalk-like in-image development, you could
use and extend IBCL:
http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
(this is just a Q&D proof of concept).
--
__Pascal Bourguignon__
mailto:pascal.bo...@anevia.com
http://www.anevia.com
Pascal J. Bourguignon
> p...@informatimago.com (Pascal J. Bourguignon) writes:
>
>>
>> Where do you think those smalltalk designer guys got the idea from?
>>
>>
>> C/USER1[105]> (defun example (query)
>> (let ((record (db-query query)))
>> (process-query record)))
>> [... Nice sample session with the debugger ...]
>
> yes, that works nicely in slime/clisp. i have a question, though.
> typically, in smalltalk environments, when you define the new functions
> the source gets into the image and you can go back to it and modify the
> initial definition at any time. is this possible in a lisp/slime
> environment? that would mean, i guess, writing the function to a file in
> some way at the debugger's prompt for a new definition...
See my answer to Jeff about IBCL:
http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
--
__Pascal Bourguignon__
John Thingstad
<p...@informatimago.com>:
and edit macro and function definitions with ED.. :)
http://www.gnu.org/fun/jokes/ed.msg.html
--------------
John Thingstad
Ken Tilton
Jeff wrote:
> I was talking with some smalltalking colleagues, and they were saying
> that they quite often develop in a sort of top down fashion, letting
> the debugger take them where they need to be. For example, if they
> are writing some code that needs to lookup an item in a database and
> then manipulate it, they would create the function and write the
> function calls to do the work they need:
>
> (defun example (query)
> (let ((record (db-query query))
> ....
> (process-query record)))
>
> Then they compile, and the debugger tells them that the function db-
> query does not exist. From there they can choose to implement the
> function, and then once implemented continue on. What's cool is that
> while they are implementing the db-query function there is a live
> query object available to look at and play with. Once continuing they
> do the same with process-query, and finally it's all running. This
> sort of like an interactive, top-down development seems very
> intriguing, and I was wondering if people have done this in lisp
> (slime), or for that matter if it would be possible.
Sure, one can go either way. But development is more fun when one has
working code at hand, so I think the classic Lisp/RAD/XP model is to get
something going ASAP and then build out on functionality, which is to be
distinguished from up/down. Building out might mean turning to the thing
that is going to call the bit I have working, ie, building up, or it
might mean refining a subcomponent that was given a very simple
treatment in round one but now must be fleshed out to be a lot fancier,
and that would be building down.
>
> On a related note, are there any open source lisp environments that
> let you browse packages, refactor, inspect like in a smalltalk
> environment? I think lispworks might do this, but I'm a free-
> wheeling, open-source hippy so I'd rather stick to open tools.
So you can slave away for hours just to get your tools working and then
have half the tool you would have with a commercial IDE? ie, If it feels
bad, do it? Sounds more irritating than free-wheeling, and then you are
limping when you could be soaring. Hippies ain't what they used to be.
But you have been sucked into the FSF matrix and suckered into their
definition of free, so this all probably looks like Strawberry Fields to
you.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
szergling
[[ ... ]]
> Finally, if you like smalltalk-like in-image development, you could
> use and extend IBCL:http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
> (this is just a Q&D proof of concept).
While we're on this, here's a feature request: ibcl needs another
layer on top that stores raw text. This way, we don't lose comments
and reader macros (what else?). In CL, comments may be "free hanging",
unassociated with any functions/macros/forms, so something else is
needed aside from redefining all the def**** forms.
To approach the OS-like integration and usability of Smalltalk, we'll
still need "always restartable" stack frames, probably first class
environments, visual? environments (a port of bitblt will be cool --
is CLIM on bitblt a good idea?), mouse input, version control, ...
Most CL implementations have bits and pieces of some of those, but who
has all of them? Is this too hard for CL? Just some thoughts I've been
going over.
Jeff
Well what I'd really like to be able to do is write a unit test
function, then run it and have the debugger take me to a new source
file where I can implement the new method which the test is trying to
use. I think this sounds better because you actually have live
arguments to play with and inspect while implementing your method,
which seems pretty handy. The up/down title of the post was being
fun, but probably somewhat orthogonal to the question.
>
> > On a related note, are there any open source lisp environments that
> > let you browse packages, refactor, inspect like in a smalltalk
> > environment? I think lispworks might do this, but I'm a free-
> > wheeling, open-source hippy so I'd rather stick to open tools.
>
> So you can slave away for hours just to get your tools working and then
> have half the tool you would have with a commercial IDE? ie, If it feels
> bad, do it? Sounds more irritating than free-wheeling, and then you are
> limping when you could be soaring. Hippies ain't what they used to be.
> But you have been sucked into the FSF matrix and suckered into their
> definition of free, so this all probably looks like Strawberry Fields to
> you.
Hahahaha. I guess this is why lisp has wallowed in obscurity for the
last decade. The FSF matrix, give me a break. The community I'm
interested in working with on open source projects is the community of
hackers who program because they enjoy it. Quite often this will be
college students, like myself, or other people who don't have the
funds to buy ridiculously expensive development environments that also
lock you in to proprietary libraries. ($1300 plus $50 shipping and
handling for Lispworks... No way in hell.) If I spend time on a
piece of software or setting up my development environment, then I
want to be able to share it and interact with other developers who can
use the same stuff. I'm not against proprietary software, but it's
not what I want to use as the basis for projects. Even if I were
developing a closed solution I'd want to be able to open-source
libraries and other aspects of the project that aren't core to the
value of the business. It just makes sense.
There are plenty of irritations in the open source world, but whether
you like it or not my friend, we are entering the digital age of
Aquarius. Information, including software, is only going to be
getting more and more open as time goes on. People can complain about
community driven projects as much as they want, but I don't see Linux,
Apache, GCC, Emacs, Vim, or Wikipedia going anywhere but up.
Time to go eat some strawberries.
-Jeff
> kt
>
> --http://www.theoryyalgebra.com/
Ken Tilton
Sounds like infatuation with a stupid albeit often handy pet trick.
Normal development is not straight line enough, so inside of 10 minutes
yer gonna have to start from scratch anyway.
>
>
>>>On a related note, are there any open source lisp environments that
>>>let you browse packages, refactor, inspect like in a smalltalk
>>>environment? I think lispworks might do this, but I'm a free-
>>>wheeling, open-source hippy so I'd rather stick to open tools.
>>
>>So you can slave away for hours just to get your tools working and then
>>have half the tool you would have with a commercial IDE? ie, If it feels
>>bad, do it? Sounds more irritating than free-wheeling, and then you are
>>limping when you could be soaring. Hippies ain't what they used to be.
>>But you have been sucked into the FSF matrix and suckered into their
>>definition of free, so this all probably looks like Strawberry Fields to
>>you.
>
>
> Hahahaha. I guess this is why lisp has wallowed in obscurity for the
> last decade.
No, it's the parentheses. We have a couple people working on getting rid
of those.
kt
--
Jeff
Say what you will, but I'd be willing to wager that if and when lisp
goes main stream again it will be on the shoulders of open source
tools and open source libraries, not the same closed solutions that
have been sitting around for years... Just think, if Franz or
Lispworks came out with a great closed lisp sans parenthesis do you
think it would change the world of lisp programming? Nope, not
really. Ruby and Python are moving closer as time goes on, and they
are as open as it gets. Furthermore, I bet the money earned by those
communities makes the lisp based income look like pennies. If you
look around you see that most of that money is in developing solutions
too, not selling tools.
-Jeff
Ken Tilton
>>>>>let you browse packages, refactor, inspect like in a smalltalk
>>>>>environment? I think lispworks might do this, but I'm a free-
>>>>>wheeling, open-source hippy so I'd rather stick to open tools.
>>
>>>>So you can slave away for hours just to get your tools working and then
>>>>have half the tool you would have with a commercial IDE?
...
>>
>>>Hahahaha. I guess this is why lisp has wallowed in obscurity for the
>>>last decade.
>>
>>No, it's the parentheses. We have a couple people working on getting rid
>>of those.
>>
>>kt
>
>
> Say what you will,
OK, I will say you should go sell tie-dyed t-shirts until you can afford
a proper environment if you really do just want to have fun.
but I'd be willing to wager that if and when lisp
> goes main stream again
have you been paying attention? MS was denouncing Lisp a year or two
ago, and java has signed up: http://groovy.codehaus.org/
game over, dude.
it will be on the shoulders of open source
> tools and open source libraries,
What have you /not/ been smoking? The herd is chasing from language to
language trying to find Lisp; it is Lisp itself that is sucking them in,
and nothing else.
not the same closed solutions that
> have been sitting around for years... Just think, if Franz or
> Lispworks came out with a great closed lisp sans parenthesis do you
> think it would change the world of lisp programming? Nope, not
> really. Ruby and Python are moving closer as time goes on, and they
> are as open as it gets. Furthermore, I bet the money earned by those
> communities makes the lisp based income look like pennies. If you
> look around you see that most of that money is in developing solutions
> too, not selling tools.
Hunh? All I said was, if you really wanted to get some work done you
would get it done sooner and more hippily with a commercial environment.
Now get hack to your room and see if you can get SBCL to compile.
tim Josling
> Say what you will, but I'd be willing to wager that if and when lisp
> goes main stream again it will be on the shoulders of open source
> tools and open source libraries, not the same closed solutions that
> have been sitting around for years... Just think, if Franz or
> Lispworks came out with a great closed lisp sans parenthesis do you
> think it would change the world of lisp programming? Nope, not
> really. ...
> -Jeff
The parenthesis notation was supposed to be a temporary solution for
lisp until a more algebraic notation that was good enough could be found.
Some attempts at this include
- Dylan*
- Arc(*?)
- Haskell**
- Within lisp
Various infix packages
eg http://www.dwheeler.com/readable/sweet-expressions.html
Loop
Format
- Ruby***
* Has macros
* Probably has macros
** Has macros but reportedly little used due to the complexity of the
parse tree you need to work to.
*** No macros but metaprogramming is significantly possible by dynamically
adding methods, renaming them etc.
Tim Josling
funkyj
> The parenthesis notation was supposed to be a temporary solution for
> lisp until a more algebraic notation that was good enough could be found.
>
> Some attempts at this include
>
> - Dylan*
> - Arc(*?)
> - Haskell**
> - Within lisp
I like parenthesis. What is wrong with them? Don't s-expressions
make writing macros a whole lot easier?
I believe arc plans to keep parenthesis, not that it matters -- I
think arc is a dead end due to lack of BDFL (PG doesn't seem to have
the drive to be a BDFL).
arc tangent: I really like the idea of a better CL. I'm a lisp newbie
and, like other newbies what I really crave is a standard and easy to
understand package system.
As some one who works professionally in C/C++, I would like to use CL
where I currently use Perl/Python (i.e. small utility programs and
hobby projects) but it is currently way too hard to do these small
programs in lisp. I know, I know, you serious macho lisp programmers
sneer at my desire to have a CL suitable for scripting but that is
what I want.
scripting lisp tangent: I remember a while back seeing an announcement
of a new lisp dialect that was intended for scripting. When I
investigated I was befuddled to find that dynamic scoping and a host
of other non-CL behaviors had been adopted which seem to completely
miss the point. Oh well.
SLIMED: A while back I tried SLIME with CLISP (on cygwin) and was very
pleased. That is until I upgraded CLISP and SLIME broke. I spent
many hours upgrading SLIME and hacking it (pathetic for a newbie)
before I finally gave up.
COMMERCIAL LISP: my two main objections to use a commercial (i.e. cost
hundreds of $$$) CL are:
(1) Lisp is a hobby right now and does not qualify for such
an expenditure. If a suitable lisp environment was free for
personal use but cost $$$ for commercial use that would be OK.
(2) I really want my lisp environment integrated with emacs. I
really
do not like the "MS developer studio" type GUI environment. I'm
not against whizbang tools, I just want to be able to drive
them
from emacs or, at the very least, for them to have a good
emacs compatibility mode (i.e. key bindings) and the ability to
rebind keys.
Well, I've wandered far and wide from my original "what is wrong with
parenthesis" remark!
A lisper wannabe,
--jfc
Edi Weitz
> COMMERCIAL LISP: my two main objections to use a commercial (i.e. cost
> hundreds of $$$) CL are:
>
> (1) Lisp is a hobby right now and does not qualify for such an
> expenditure. If a suitable lisp environment was free for personal
> use but cost $$$ for commercial use that would be OK.
> (2) I really want my lisp environment integrated with emacs. I
> really do not like the "MS developer studio" type GUI environment.
> I'm not against whizbang tools, I just want to be able to drive
> them from emacs or, at the very least, for them to have a good
> emacs compatibility mode (i.e. key bindings) and the ability to
> rebind keys.
Why is (2) an objection to use one of the commercial implementations?
Have you ever tried one of them? LispWorks, for example, is centered
around an Emacs editor (a Hemlock descendant, actually). Basically,
it's just an Emacs written in Common Lisp. And of course you can
rebind keys.
I also fail to see how anybody who has worked with it for more than
five minutes could call it an "MS developer studio type environment."
The next time, please do your homework first, then try to spread FUD.
Thanks,
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Andreas Davour
> On Jan 19, 4:09 pm, tim Josling <tejgcc_nos...@westnet.com.au> wrote:
>
>> The parenthesis notation was supposed to be a temporary solution for
>> lisp until a more algebraic notation that was good enough could be found.
>>
>> Some attempts at this include
>>
>> - Dylan*
>> - Arc(*?)
>> - Haskell**
>> - Within lisp
>
> I like parenthesis. What is wrong with them? Don't s-expressions
> make writing macros a whole lot easier?
>
> I believe arc plans to keep parenthesis, not that it matters -- I
> think arc is a dead end due to lack of BDFL (PG doesn't seem to have
> the drive to be a BDFL).
BDFL?
/Andreas
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
vanekl
> funkyj <fun...@gmail.com> writes:
>
>> On Jan 19, 4:09 pm, tim Josling <tejgcc_nos...@westnet.com.au> wrote:
>>
>>> The parenthesis notation was supposed to be a temporary solution for
>>> lisp until a more algebraic notation that was good enough could be found.
>>>
>>> Some attempts at this include
>>>
>>> - Dylan*
>>> - Arc(*?)
>>> - Haskell**
>>> - Within lisp
>> I like parenthesis. What is wrong with them? Don't s-expressions
>> make writing macros a whole lot easier?
>>
>> I believe arc plans to keep parenthesis, not that it matters -- I
>> think arc is a dead end due to lack of BDFL (PG doesn't seem to have
>> the drive to be a BDFL).
>
> BDFL?
benevolent dictator for life
> /Andreas
>
Edi Weitz
> BDFL?
He probably meant this:
Otherwise, this new "Google" thing seems to be quite helpful
sometimes. Ever heard of it?
vanekl
> On Jan 19, 4:09 pm, tim Josling <tejgcc_nos...@westnet.com.au> wrote:
>
>> The parenthesis notation was supposed to be a temporary solution for
>> lisp until a more algebraic notation that was good enough could be found.
>>
>> Some attempts at this include
>>
>> - Dylan*
>> - Arc(*?)
>> - Haskell**
>> - Within lisp
>
> I like parenthesis. What is wrong with them? Don't s-expressions
> make writing macros a whole lot easier?
yes, the consistent syntax makes macros practical.
i never understood why people get hung-up on parenthesis, either.
i'm still a little in awe of the beauty of the language, and all
some people can do is gripe.
> I believe arc plans to keep parenthesis, not that it matters -- I
> think arc is a dead end due to lack of BDFL (PG doesn't seem to have
> the drive to be a BDFL).
>
> arc tangent: I really like the idea of a better CL. I'm a lisp newbie
> and, like other newbies what I really crave is a standard and easy to
> understand package system.
there is a standard package system. I agree, it could have been made
a little easier to use. You may be thinking of the auto-loading dependent
package mechanisms (e.g. asdf), which aren't standardized, and are complex.
> As some one who works professionally in C/C++, I would like to use CL
> where I currently use Perl/Python (i.e. small utility programs and
> hobby projects) but it is currently way too hard to do these small
> programs in lisp. I know, I know, you serious macho lisp programmers
> sneer at my desire to have a CL suitable for scripting but that is
> what I want.
If you haven't tried Ruby, you should. It's a wonderful scripting language.
You can actually still read your code 6 months after you write it. Try
doing that with Perl.
> scripting lisp tangent: I remember a while back seeing an announcement
> of a new lisp dialect that was intended for scripting. When I
> investigated I was befuddled to find that dynamic scoping and a host
> of other non-CL behaviors had been adopted which seem to completely
> miss the point. Oh well.
>
> SLIMED: A while back I tried SLIME with CLISP (on cygwin) and was very
> pleased. That is until I upgraded CLISP and SLIME broke. I spent
> many hours upgrading SLIME and hacking it (pathetic for a newbie)
> before I finally gave up.
I agree that the OSS-Lisp/Windows combination has a few land mines that can
be highly distracting.
> COMMERCIAL LISP: my two main objections to use a commercial (i.e. cost
> hundreds of $$$) CL are:
>
> (1) Lisp is a hobby right now and does not qualify for such
> an expenditure. If a suitable lisp environment was free for
> personal use but cost $$$ for commercial use that would be OK.
> (2) I really want my lisp environment integrated with emacs. I
> really
> do not like the "MS developer studio" type GUI environment. I'm
> not against whizbang tools, I just want to be able to drive
> them
> from emacs or, at the very least, for them to have a good
> emacs compatibility mode (i.e. key bindings) and the ability to
> rebind keys.
>
> Well, I've wandered far and wide from my original "what is wrong with
> parenthesis" remark!
>
> A lisper wannabe,
> --jfc
Lou the Lisper,
desperately hoping a little keyboard intercourse will lead to sleep
Jeff
> >>>>>On a related note, are there any open source lisp environments that
> >>>>>let you browse packages, refactor, inspect like in a smalltalk
> >>>>>environment? I think lispworks might do this, but I'm a free-
> >>>>>wheeling, open-source hippy so I'd rather stick to open tools.
>
> >>>>So you can slave away for hours just to get your tools working and then
> >>>>have half the tool you would have with a commercial IDE?
>
> ...
>
>
> OK, I will say you should go sell tie-dyed t-shirts until you can afford
> a proper environment if you really do just want to have fun.
Looking at your CLL history, it seems you get into this kind of thing:
"I suggest you try bartender's school to support yourself, start
programming for fun again."
-- Ken Tilton
I take the jump to personal attacks as a sign of intellectual
weakness. If an argument moves to this kind of stuff I think it's
losing steam. The thing is, if the goal is to make me feel sad,
small, and maybe to question my hippy like ways, it's not working.
Making tie-dyed t-shirts is actually pretty fun, but unfortunately I
doubt they would sell well here in Switzerland where I'm working on my
PhD.
> have you been paying attention? MS was denouncing Lisp a year or two
> ago, and java has signed up:http://groovy.codehaus.org/
>
> game over, dude.
Game over? You mean lisp is dead and groovy is the next big thing? I
programmed a bit of groovy commercially a few years ago, and it was
pretty much a dynamic Java that was trying to copy features from
Ruby. It doesn't seem to be much more than that now, unless I'm
missing the announcement for macros. Oh, and Java as well as the most
popular development environment for it, Eclipse, are open source.
Have fun grooving though...
> it will be on the shoulders of open source
>
> > tools and open source libraries,
>
> What have you /not/ been smoking? The herd is chasing from language to
> language trying to find Lisp; it is Lisp itself that is sucking them in,
> and nothing else.
You are right, that does seem to be happening; however, unless the
lisp community has a breadth of good open source tools and libraries
it won't ever arrive at lisp. I think with SBCL, slime and a lot of
the good libs that exist now things are close, but with this kind of
response on the mailing list to someone like myself who I think
represents a large portion of the Ruby/Python communities, it's not
looking good.
> Hunh? All I said was, if you really wanted to get some work done you
> would get it done sooner and more hippily with a commercial environment.
> Now get hack to your room and see if you can get SBCL to compile.
>
> kt
I had SBCL running along with Slime in no time, thanks to the joys of
Ubuntu. I've played a bit with lispworks personal as well, but I
think for the majority of developing time I prefer my customized Slime
features and workflow. (Admittedly, it would be great to have some of
those browsers and inspectors...) Anyway back to coding... Oh yeah,
I'm following your advice:
"You should just do Lisp all day and add to the open source libraries
to speed Lisp's ascendance."
May we succeed!
Peace,
Jeff
Rob Warnock
+---------------
| As some one who works professionally in C/C++, I would like to use CL
| where I currently use Perl/Python (i.e. small utility programs and
| hobby projects) but it is currently way too hard to do these small
| programs in lisp. I know, I know, you serious macho lisp programmers
| sneer at my desire to have a CL suitable for scripting but that is
| what I want.
|
| scripting lisp tangent: I remember a while back seeing an
| announcement of a new lisp dialect that was intended for scripting.
Hunh?!? Who needs a "new" Lisp dialect for scripting?!?
I use CL for "small utility programs" all the time!!
Scripting works just fine in CMUCL[1]:
$ cat hello.cmucl
#!/usr/local/bin/cmucl -script
(format t "Hello, world!~%")
(loop for arg in (cons *script-name* *script-args*)
and i from 0
do (format t "argv[~a] = ~s~%" i arg))
$ ./hello.cmucl -foo bar baz
Hello, world!
argv[0] = "./hello.cmucl"
argv[1] = "-foo"
argv[2] = "bar"
argv[3] = "baz"
$
And in CLISP:
$ cat hello.clisp
#!/usr/local/bin/clisp
(format t "hello world!~%")
(loop for arg in (cons (namestring *load-pathname*) *args*)
and i from 0
do (format t "argv[~a] = ~s~%" i arg))
$ ./hello.clisp -foo bar baz
hello world!
argv[0] = "hello.clisp"
argv[1] = "-foo"
argv[2] = "bar"
argv[3] = "baz"
$
For other implementations, see <http://www.cliki.net/ShellScripting>
or <http://www.cliki.net/cl-launch> or maybe even the program
<http://www.chez.com/emarsden/downloads/cmucl-trampoline.c>
hacked up for a non-CMUCL (since you don't really need it for
CMUCL, given [1]).
This is a non-problem.
-Rob
[1] See <http://rpw3.org/hacks/lisp/site-switch-script.lisp>
for how to add "-script" to CMUCL without recompiling.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Sohail Somani
> You are right, that does seem to be happening; however, unless the lisp
> community has a breadth of good open source tools and libraries it won't
> ever arrive at lisp. I think with SBCL, slime and a lot of the good
> libs that exist now things are close, but with this kind of response on
> the mailing list to someone like myself who I think represents a large
> portion of the Ruby/Python communities, it's not looking good.
I have not followed your thread but you seem to be new here (I'm not as
new!) Please take Kenny's responses to be indicative of.. Kenny. Not cll
nor Lisp users in general.
Once you get past that, he is quite entertaining. I'm still waiting for
him to get back to me about me calling him uncivilized (after he called
me a peeing fish or something.) I think after that, he put me in his kill
file :-)
I agree that the OSS Lisp offerings need to be strong and I think they
are. Better than Python anyway (except for the batteries included part.)
Having worked in the Visual C++ world for far too long, they are
definitely better than that side of the world.
By "they" I mean development tools like Emacs, Slime and SBCL. You have
OSS libraries for most things but definitely not as many as Python.
Actually, I don't even know what is missing as I haven't needed anything
that isn't written in CL.
How about you port Rails to Lisp and lets take it from there? :-)
--
Sohail Somani
http://uint32t.blogspot.com
tim Josling
> On Jan 19, 4:09 pm, tim Josling <tejgcc_nos...@westnet.com.au> wrote:
>
>> The parenthesis notation was supposed to be a temporary solution for
>> lisp until a more algebraic notation that was good enough could be found.
>>
>> Some attempts at this include
>>
>> - Dylan*
>> - Arc(*?)
>> - Haskell**
>> - Within lisp
>
> I like parenthesis. What is wrong with them?
Nothing is wrong with them, in most cases.
Sometimes they are over the top. FORMAT is an example where using
parentheses would be over the top, also loop is better than lots of
parentheses. Maybe also arithmetic expressions - look at all the infix
projects.
I recently wrote a lexical analyser. I used nested expressions for
defining the regular expressions and it was kind of klunky. So maybe
regexes are another example where parentheses are too cumbersome.
Tim Josling
Pillsy
[...]
> Why is (2) an objection to use one of the commercial implementations?
> Have you ever tried one of them? LispWorks, for example, is centered
> around an Emacs editor (a Hemlock descendant, actually). Basically,
> it's just an Emacs written in Common Lisp. And of course you can
> rebind keys.
Has anyone written a paredit equivalent for the LW editor. I keep
giving LW second chances, and keep running up against not having
paredit, and giving up, and deciding that wasn't really a fair test,
and lathering, rinsing and repeating. I'm not sure I'm so motivated to
try it that I want to spend a lot of time learning how to customize it
well enough to port paredit over, though.
Cheers,
Pillsy
Peter Hildebrandt
wrote:
> On Sat, 19 Jan 2008 21:57:02 -0800, Jeff wrote:
>
>> You are right, that does seem to be happening; however, unless the lisp
>> community has a breadth of good open source tools and libraries it won't
>> ever arrive at lisp. I think with SBCL, slime and a lot of the good
>> libs that exist now things are close, but with this kind of response on
>> the mailing list to someone like myself who I think represents a large
>> portion of the Ruby/Python communities, it's not looking good.
There have been enough threads on this topic on cll already, yet I feel
your discussion lacks a few points:
(1) The CL library landscape is good, but in some areas confusing as there
are several libraries doing the same thing (all those utilities libs
(cl-utilities, pod-utils, kt-utils etc) or take the recent question about
ffis.).
The list of recommended libraries on Cliki [1] is a good starting point,
but lacks good libraries like bordeaux-threads, cl-cairo2, cl-opengl,
cl-weblocks, clg, etc. The CL Gardeners [2] address the same question,
but IMO it is hard to find concrete information on that site.
[1] http://www.cliki.net/Current%20recommended%20libraries
[2] http://www.lispniks.com/cl-gardeners/
(2) Some libraries are hard to find (eg. for cello, celtk, cells you need
the link to cvs. Searching the archives of the cells-devel list is your
best bet.)
ASDF-Install is obviously the answer to the retrieve/install problem, but
again, a (more complete) list of recommended libraries would help. Some
people do an amazing job of keeping their packages up to date, other
projects seem not to have the ressources.
(3) Keeping libraries up to date is non-trivial
Maybe I missed it: Is there an (asdf-install:upgrade) that updates all my
asdf-install'd packages?
(4) According to the thread on GUI programming there is no satisfying GUI
solution at this point. (Again, there are several, but each has its own
problems. This is confusing for the newbie: Which one do I take? Where
is the best community?)
The advent of webapps surely remedies this point, but there are still a
number of use cases where one needs the full power of a local GUI (e.g
graphic intense stuff). Lisp is highly suitable to dynamic UIs, but
currently there is no easy way to do it. clg lacks cells, celtk looks
unacceptable with tk<=8.4 on linux, cells-gtk is not quite complete (e.g.
drawing), cello has only few widgets.
(5) Emacs/Slime is powerful ... but
- the threshhold is *high*. Weird keybindings, the minibuffer, ... all
that takes some time to get used to.
- to get antialiasing on linux you need an unofficial snapshot build (!)
- lisp-specific features need custom extensions (paredit etc.) that need
to be installed manually
Again, I know there are lisp-in-a-box distros, but as soon as you want to
customize it a little you find yourself digging knee-deep in config files.
I would describe myself as quite ready to adopt new technologies, but it
took me about six months of being constantly upset about one thing or
another in cusp [3] until I finally decided to get started with emacs.
[3] http://bitfauna.com/projects/cusp/index.html
In case you wonder: I'm doing my share extending cells-gtk to include a
few more involved widgets like a tree-view based on cells and
drawing-areas supporting cairo and opengl.
But it'd be great if more people in the lisp world cared to share their
experience -- and if people could get together to keep things like the
list of recommended libraries up to date.
So far,
Peter
> I have not followed your thread but you seem to be new here (I'm not as
> new!) Please take Kenny's responses to be indicative of.. Kenny. Not cll
> nor Lisp users in general.
>
> Once you get past that, he is quite entertaining. I'm still waiting for
> him to get back to me about me calling him uncivilized (after he called
> me a peeing fish or something.) I think after that, he put me in his kill
> file :-)
>
> I agree that the OSS Lisp offerings need to be strong and I think they
> are. Better than Python anyway (except for the batteries included part.)
> Having worked in the Visual C++ world for far too long, they are
> definitely better than that side of the world.
>
> By "they" I mean development tools like Emacs, Slime and SBCL. You have
> OSS libraries for most things but definitely not as many as Python.
> Actually, I don't even know what is missing as I haven't needed anything
> that isn't written in CL.
>
> How about you port Rails to Lisp and lets take it from there? :-)
>
--
Tayssir John Gabbour
> LispWorks, for example, is centered around an Emacs editor (a
> Hemlock descendant, actually). Basically, it's just an Emacs
> written in Common Lisp. And of course you can rebind keys.
Even better, you can use Emacs with Lispworks as I do! Discussed here:
http://bc.tech.coop/blog/050106.html
http://bc.tech.coop/blog/040315.html
(Now, these instructions are a bit outdated... I recall I had to look
up how to do the -init thing in the Lispwork docs. Can't remember,
sorry. But they're basically correct.)
So I have my paredit and whatnot. (I don't think that Lispworks's
editor is that extendable? Or am I wrong?)
Tayssir
Edi Weitz
> Has anyone written a paredit equivalent for the LW editor.
I suppose they're all waiting for you to do it...
Edi Weitz
> I don't think that Lispworks's editor is that extendable? Or am I
> wrong?
I think you're wrong. Why should an editor that is written in Common
Lisp and comes with source code not be extendable? Admittedly, GNU
Emacs has a better framework for extensions and more existing support
code, though.
Ken Tilton
Jeff wrote:
> On Jan 19, 11:45 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
...
>>What have you /not/ been smoking? The herd is chasing from language to
>>language trying to find Lisp; it is Lisp itself that is sucking them in,
>>and nothing else.
>
>
> You are right, that does seem to be happening; however, unless the
> lisp community has a breadth of good open source tools and libraries
> it won't ever arrive at lisp.
Please study that paragraph of yours and think a little: How is it that
the whole programming language thing is converging on Lisp with nothing
out there but half-baked, incomplete, abandoned open source libraries
and tools?
It's the /idea/ dude, not the infrastructure. Java succeeded in part
because Sun provided lotsa infrastructure (the other part was being like
C but safer and having GC), but Python and Ruby succeeded by being more
fun to work with (including being more interactive, less type-obsessed,
yadda, yadda). Absent a Sun, a Great Thing grows by being great so Real
Programmers see it is worth it to roll up their sleeves and Just Use It,
libraries or no. Some are smart enough to put some energy into bridges
to other worlds, such as CFFI and Verrazano, to jump start the
infrastructure.
I think with SBCL, slime and a lot of
> the good libs that exist now things are close, but with this kind of
> response on the mailing list to someone like myself who I think
> represents a large portion of the Ruby/Python communities, it's not
> looking good.
Sure, Lisp would have been designated by he US DOD to replace Ada by now
if Kenny was not so mean to noobs on c.l.l. That is a feature of my plan
to keep Lisp to myself, not a bug. Meanwhile...
Jeez, all I did was make fun of the idea that using free software is
liberating as opposed to enslaving*, and I did so on Usenet. You now
feel personally put-upon, offended, attacked, blah blah blah. I don't
think it works that way.
kt
* When I was in college a shade-tree mechanic could still work on their
own car. I did so, to save money. My net result was cash negative thanks
to screw-ups, and that was with the standard FSF rate of zero for my
time. Something like that. k
Ken Tilton
Sohail Somani wrote:
> I have not followed your thread but you seem to be new here (I'm not as
> new!) Please take Kenny's responses to be indicative of.. Kenny. Not cll
> nor Lisp users in general.
Thanks! But be careful taunting cll users in general like that, they'll
be on you like a Frisco zoo tiger.
>
> Once you get past that, he is quite entertaining. I'm still waiting for
> him to get back to me about me calling him uncivilized (after he called
> me a peeing fish or something.) I think after that, he put me in his kill
> file :-)
No, I thought you were insulting the fish.
Andrew Reilly
> The parenthesis notation was supposed to be a temporary solution for
> lisp until a more algebraic notation that was good enough could be
> found.
>
> Some attempts at this include
>
> - Dylan*
> - Arc(*?)
> - Haskell**
> - Within lisp
> Various infix packages
> eg http://www.dwheeler.com/readable/sweet-expressions.html
> Loop
> Format
> - Ruby***
PLT scheme has "Honu", although I'm not entirely sure why: it doesn't
seem to be used for anything in particuar within the PLT universe. Maybe
it was just put in as a proof that it was possible? Mabe it supports the
Java and Algol "Teachpacks".
Cheers,
--
Andrew
Andreas Davour
> On Sun, 20 Jan 2008 05:58:57 +0100, Andreas Davour
> <ant...@updateLIKE.uu.HELLse> wrote:
>
>> BDFL?
>
> He probably meant this:
>
> http://www.bdfl.de/
>
> Otherwise, this new "Google" thing seems to be quite helpful
> sometimes. Ever heard of it?
When in doubt about what a poster means, ask the poster instead of
trying to outguess him, was what I thought.
/andreas
Ken Tilton
Andreas Davour wrote:
> Edi Weitz <spam...@agharta.de> writes:
>
>
>>On Sun, 20 Jan 2008 05:58:57 +0100, Andreas Davour
>><ant...@updateLIKE.uu.HELLse> wrote:
>>
>>
>>>BDFL?
>>
>>He probably meant this:
>>
>> http://www.bdfl.de/
>>
>>Otherwise, this new "Google" thing seems to be quite helpful
>>sometimes. Ever heard of it?
Thx! Yer right!: http://www.ssvc.com/bdfl/index.htm
Google rocks!
> When in doubt about what a poster means, ask the poster instead of
> trying to outguess him, was what I thought.
We prefer guessing and being deliberately annoying so as to drive away
unworthy noobs, defined as anyone we can drive away by being annoying.
So far the only people in our net are unworthy dorks who sob that Kenny
was mean to them as their parting shot. I have a belt with notches...
hth,kt
ps. http://en.wikipedia.org/wiki/Guido_van_Rossum
Edi Weitz
> Thx! Yer right!: http://www.ssvc.com/bdfl/index.htm
>
> Google rocks!
Ah, right, sorry. I forgot that 99.9% of all Google users only ever
click on the first search result. D'oh!
Robert Uhl
>
> Well what I'd really like to be able to do is write a unit test
> function, then run it and have the debugger take me to a new source
> file where I can implement the new method which the test is trying to
> use.
I'd think that might be relatively easy to do. Given a list of restarts
which are known redo restarts, then it should be pretty simple to open a
new buffer. Although, one file per method is _ugly_. If there were a
way to figure out which existing buffer the method should go into,
that'd be cool. But with generic functions I don't think that there's a
clean solution.
> Hahahaha. I guess this is why lisp has wallowed in obscurity for the
> last decade. The FSF matrix, give me a break. The community I'm
> interested in working with on open source projects is the community of
> hackers who program because they enjoy it.
No, you don't get advocates of proprietary software. They think that
paid 'companionship' is better than marriage. It's all about them: they
hand over their money, they get what they want and they leave. Free
software, OTOH, is altogether different: it's a relationship based on
something more than an exchange of cash for services.
Proprietary software advocates are the sort of people who think that
allowing professional athletes into the Olympic Games was an
improvement.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I unplug the UPS every month or so so that the electric
company thinks the machines have been shut off.
--Graham Reed, sharing uptime DSW tips
Ken Tilton
Edi Weitz wrote:
> On Sun, 20 Jan 2008 13:43:08 -0500, Ken Tilton <kenny...@optonline.net> wrote:
>
>
>>Thx! Yer right!: http://www.ssvc.com/bdfl/index.htm
>>
>>Google rocks!
>
>
> Ah, right, sorry. I forgot that 99.9% of all Google users only ever
> click on the first search result. D'oh!
>
First result? First?!!! Do you have any idea how many pages I had to
click through to get to that link?! You keep selling me short...we'll
settle this once and for all in Amsterdam!!
kt
Maciej Katafiasz
> How about you port Rails to Lisp and lets take it from there? :-)
Let's not. Rails is a really shitty way of doing things.
Cheers,
Maciej
Sohail Somani
I don't really care either way, but Rails has gotten Ruby usage. This
might be because it is quite Mickey Mouse... But why is Rails a really
shitty way of doing things?
Slava Akhmechet
> But why is Rails a really shitty way of doing things?
Every reason why Seaside is a great way of doing things is the reason
why Rails isn't a great way of doing things.
Rails is actually very good, if you consider ASP/JSP/PHP as its
competition. There is no doubt about it. Beyond that, Rails is kind of
weak compared to mature component-oriented frameworks. Even ASP.NET
(whose engineers, IMO, made the right decision to go with
component-based approach and then screwed up every decision that
followed) blows Rails out of the water when it comes to raw
productivity once you get past the ORM mapping.
Web applications tend to have four pillars that support them - model
data, HTML output, UI state transitions, and "business logic" (this maps
exactly to MVC, except that in Rails "C" is responsible for the last two
tasks). Rails gets the first part right via ActiveRecord and doesn't do
much at all for the other three beyond PHP improvements (which is a
really bad standard to go by).
HTML should be generated automatically from a high level declarative
spec (I'll check this into Weblocks soon, and I believe Seaside can do
this via Magrite library). UI state transitions should be stored and
managed by widgets (where they belong). This lets you actually focus on
business logic and high level UI definition, instead of writing HTML
templates and doing server redirects.
Yeah, Rails is better than PHP, but that's not a very big
accomplishment.
--
Regards,
Slava Akhmechet.
Marco Antoniotti
I think you are. The problem as usual is with documentation and lack
of examples. Plus, people use LW mostly for Lisp hacking. On a
recent occasion I had the need to hack Prolog in LW (LW commercial
comes with a very vice Prolog with Edinburgh syntax) and the editor
does not have a Prolog Mode. It'd be nice to figure out how to ad
modes to the LW editor. Maybe it is just a matter of digging in the
Hemlock manuals.
Cheers
--
Marco
Sohail Somani
> Sohail Somani <soh...@taggedtype.net> writes:
>
>> But why is Rails a really shitty way of doing things?
> Every reason why Seaside is a great way of doing things is the reason
> why Rails isn't a great way of doing things.
>
[snip]
> Yeah, Rails is better than PHP, but that's not a very big
> accomplishment.
This post will go down in history. As soon as you check in that DSL ;-)
Slobodan Blazeski
framework instead of few dozen of mediocre ones.
Slobodan
>
> --
> Sohail Somanihttp://uint32t.blogspot.com
Maciej Katafiasz
First, I completely agree with what Slava said. Now to expand that a bit
with my own thoughts:
Rails is 100% magic with 0% design. It sports all the great quality and
consistency you've come to expect from PHP, except with loads more magic.
There's no overarching design or scheme of things, it's just a bucket of
tools with some glue poured in. This has a couple of important
consequences:
- There's no reasoning about Rails -- more familiarity won't give you
better chances of figuring out something new because that's what follows
from the design, only because that's how it usually ends up being
implemented and because you have memorised more things, so your guesses
are better. In essence, being better in Rails means being better at
grepping the internet.
- There's no thought given to the general problem to solve, it's just
improved PHP + "ActiveRecord, lol". This means Rails doesn't have
solutions that are particularly good or scalable or make sense, only
hacks that happened to solve someone's specific problem at a time and
were implementable in 5 minutes or less. Rails is heaps better than PHP,
but it's still only good for what PHP is good, and that's not writing
webapps. This permeates Rails all the way down: it's got hacky modules
that only solve particular problems, those modules have hacky functions
that only solve particular problems and those functions only do hacky
things that solved someone's particular problem.
Some examples:
* AR's find family of functions. It's a horrible hack, for instance,
they support the :group clause, which has semantics ("return a collection
of groups of things") incompatible with find's base semantics ("return a
collection of things"). Rails answer? It implicitly relies on MySQL's
retarded interpretation of SQL and the fact that given a table with two
columns, id and colour, it will silently interpret "SELECT * FROM table
GROUP BY colour" as "SELECT FIRST(id), colour FROM table GROUP BY
colour". End result? A valid combination of clauses in AR will generate
incorrect SQL Postgres will (correctly) choke on.
* AR's find again, it supports :join (which documentation hilariously
describes as "rarely needed"), except that it doesn't return real objects
then, but make-believe fake readonly objects that will only have some
attributes filled in (because they have no backing with physical rows),
but will *still* have the base type and all the methods of the class you
queried on! So if you go with that and try to call one of the methods
that depend on unfilled attributes, you die horribly.
- Reading and, in general, understanding Rails is horribly difficult,
since it's no design and layers upon layers of magic. Very often you will
find 5-7 layers of functions delegating the work deeper and deeper in,
until you arrive to a completely undocumented internal function that in
turn splits the work to three other, unrelated internal functions. Given
that each of those 10 functions takes a hash called "options", each layer
altering it subtly, but none having the complete picture, and that 9
times out of 10 that hash is not documented on any level, figuring out
what your choices are is pure hell. It's made even more fun by the fact
that different parts of Rails are accessible at various points of
handling the request, and you can't just jump in and poke things from the
console, since it won't have 99% of the things that only magically spring
to life once a request is live.
- As a rule, there's no quality assurance, and the average quality is
very low. Because it's such a patchwork, it will only have parts of
things implemented, some other (not necessarily overlapping) parts
documented, and a whole load of missing things just dangling and waiting
for you to run into them. For example, the docs for
text_field_with_auto_complete discuss how you can use options to make it
complete only parts of entries (which was exactly what I needed, to show
"foo (123)" in the popup, but only insert "foo" in the text field). What
it doesn't tell you, however, is that none of the stock completion-
generating methods will prepare such splittable data for you, and you're
supposed to copy their code and hack it on your own instead. It took me
half a day to finally understand that it wasn't me being stupid and
unable to find it, but it was actually Rails documenting interfaces that
_weren't there_.
- And to stress the first point again, Rails never concerns itself with
the big-picture problem of "writing webapps". It only thinks as big as
"outputting HTML strings" and "querying the DB for a list of things".
This means the important, actually hard stuff like handling the stateless
nature of HTTP, or sanitising and escaping the user input is just not
adressed at all, and you only learn about them when one day you discover
84 possible XSS injection points (actual number from a Rails app I'm
somewhat famililar with).
I'm a huge fan of innovative frameworks like Weblocks, because they
actually stopped and thought about the whole thing for a moment, and try
things that will address the problem as a whole. And even if some
specific things will turn out to be harder to do that by just churning
out raw HTML, and there will be abstraction leaks, it's still better
because they try out new things to find a solution that has a chance
work. Rails doesn't, because its entire culture seems to be fundamentally
incapable of thinking more than 5 minutes into the future.
Cheers,
Maciej
Slobodan Blazeski
Interesting talk, I've never tried rails but was curious what it look
likes to work with it. Oh lisp, I hope that old curse worse is better
wouldn't strike again.
cheers
Slobodan
Sohail Somani
>> I don't really care either way, but Rails has gotten Ruby usage. This
>> might be because it is quite Mickey Mouse... But why is Rails a really
>> shitty way of doing things?
>
> First, I completely agree with what Slava said. Now to expand that a bit
> with my own thoughts:
Thanks to you (and Slava) for taking the time! I only have book knowledge
of Rails as I have read a couple of their bibles.
uncle
I fail to see how weblocks addresses "big-picture problem of writing
webapps" while rails does not. In fact, rails was the first thing out
there that did address the big picture without requiring pulling
together your own framework from other stuff (ASP.NET excluded of
course, but you probably don't know squat about that either).
msaelices
> Den Mon, 21 Jan 2008 06:08:27 +0000 skrev Sohail Somani:
>
> > On Mon, 21 Jan 2008 04:10:19 +0000, Maciej Katafiasz wrote:
> >> Let's not. Rails is a really shitty way of doing things.
>
> > I don't really care either way, but Rails has gotten Ruby usage. This
> > might be because it is quite Mickey Mouse... But why is Rails a really
> > shitty way of doing things?
>
> First, I completely agree with what Slava said. Now to expand that a bit
> with my own thoughts:
>
Try django ;-)
> Cheers,
> Maciej
vanekl
> Den Mon, 21 Jan 2008 06:08:27 +0000 skrev Sohail Somani:
>
>> On Mon, 21 Jan 2008 04:10:19 +0000, Maciej Katafiasz wrote:
>>> Let's not. Rails is a really shitty way of doing things.
>> I don't really care either way, but Rails has gotten Ruby usage. This
>> might be because it is quite Mickey Mouse... But why is Rails a really
>> shitty way of doing things?
>
> First, I completely agree with what Slava said. Now to expand that a bit
> with my own thoughts:
>
> Rails is 100% magic
Yup, there is a lot of "magic." Classes are changed at run-time depending on
what database is being used, and what fields activerecord finds in the db,
among other things.
> ... with 0% design.
Then what is Ruby's adherence to MVC if not a part of design?
> It sports all the great quality and
> consistency you've come to expect from PHP, except with loads more magic.
I hope you're being sarcastic here about quality and consistency.
It's hard to tell.
> There's no overarching design or scheme of things, it's just a bucket of
> tools with some glue poured in.
+80K lines of Ruby code is more substantial than how you make it sound.
> This has a couple of important
> consequences:
>
> - There's no reasoning about Rails
The reasoning is that the framework is "lifted" straight out of
DHH's website code. Every line of code has earned it's keep, according to that metric.
It's certainly not theoretic reasoning, however, if that's what you are
referring to.
-- more familiarity won't give you
> better chances of figuring out something new because that's what follows
> from the design, only because that's how it usually ends up being
> implemented and because you have memorised more things, so your guesses
> are better. In essence, being better in Rails means being better at
> grepping the internet.
Rails documentation is better than the majority of the frameworks out there.
It's probably one of the keys to its success. There's even been books published.
> - There's no thought given to the general problem to solve, it's just
> improved PHP + "ActiveRecord, lol". This means Rails doesn't have
> solutions that are particularly good or scalable
Yeah, this is bothersome. Some of ARs code doesn't scale, and
you just have to scratch your head and ask "why bother?"
It's even worse than this: the classes load and morph at run-time.
Ah, you mention this below.
> Given
> that each of those 10 functions takes a hash called "options",
The reason why this is done is because this is the poor-man's method
of using key words, since Ruby doesn't have this capability.
Yes, you're right, hashes as a substitute for keyword parameters is a hack.
> each layer
> altering it subtly, but none having the complete picture, and that 9
> times out of 10 that hash is not documented on any level, figuring out
> what your choices are is pure hell. It's made even more fun by the fact
> that different parts of Rails are accessible at various points of
> handling the request, and you can't just jump in and poke things from the
> console, since it won't have 99% of the things that only magically spring
> to life once a request is live.
>
> - As a rule, there's no quality assurance, and the average quality is
> very low.
You're right about this. DHH thinks shipping _any_ code often is more
important than shipping stable code. It's marketing. Keeps the crowd involved.
It's pretty much the rule rather than the exception that there is a major
bug that is hastily squashed shortly after each major release.
> Because it's such a patchwork, it will only have parts of
> things implemented, some other (not necessarily overlapping) parts
> documented, and a whole load of missing things just dangling and waiting
> for you to run into them. For example, the docs for
> text_field_with_auto_complete discuss how you can use options to make it
> complete only parts of entries (which was exactly what I needed, to show
> "foo (123)" in the popup, but only insert "foo" in the text field). What
> it doesn't tell you, however, is that none of the stock completion-
> generating methods will prepare such splittable data for you, and you're
> supposed to copy their code and hack it on your own instead. It took me
> half a day to finally understand that it wasn't me being stupid and
> unable to find it, but it was actually Rails documenting interfaces that
> _weren't there_.
>
> - And to stress the first point again, Rails never concerns itself with
> the big-picture problem of "writing webapps".
DHH definitely has a big picture, it just doesn't appear to line up with
your big picture. His blog discusses his big-picture goals. And considering
his marketing success he's doing something right, if nothing other than
having a large number of practitioners.
> It only thinks as big as
> "outputting HTML strings"
Yeah, I was also disappointed when this finally occurred to me, too.
It's more string-based than component-based.
> and "querying the DB for a list of things".
Unfortunately, there's a lot of boring things that have to be done when
programming web apps, and there's nothing wrong with making that job
less painful. I'm not arguing that it couldn't have been done better, though.
> This means the important, actually hard stuff like handling the stateless
> nature of HTTP, or sanitising and escaping the user input is just not
> adressed at all,
Here's just a partial sample of the sanitizing code I found in my Rails code base.
def escape_string(str)
str.gsub(/([\0\n\r\032\'\"\\])/) do
case $1
when "\0" then "\\0"
when "\n" then "\\n"
when "\r" then "\\r"
when "\032" then "\\Z"
else "\\"+$1
end
end
end
alias :quote :escape_string
Maybe you're referring to something else?
> ...and you only learn about them when one day you discover
> 84 possible XSS injection points (actual number from a Rails app I'm
> somewhat famililar with).
Do you have a link for these 84 different exploits? I would be interested.
> I'm a huge fan of innovative frameworks like Weblocks, because they
> actually stopped and thought about the whole thing for a moment, and try
> things that will address the problem as a whole. And even if some
> specific things will turn out to be harder to do that by just churning
> out raw HTML, and there will be abstraction leaks, it's still better
> because they try out new things to find a solution that has a chance
> work. Rails doesn't, because its entire culture seems to be fundamentally
> incapable of thinking more than 5 minutes into the future.
>
> Cheers,
> Maciej
You left out awkward,
1. programming when more than one db used;
2. db compound-key support;
3. legacy db support, unless it follows Rail's conventions.
--
Maybe I can defuse the situation with the Premature Godwin Maneuver:
Look! Over there! It's Hitler!
Jeff
> Sohail Somani <soh...@taggedtype.net> writes:
> > But why is Rails a really shitty way of doing things?
>
> Every reason why Seaside is a great way of doing things is the reason
> why Rails isn't a great way of doing things.
>
> Rails is actually very good, if you consider ASP/JSP/PHP as its
> competition. There is no doubt about it. Beyond that, Rails is kind of
> weak compared to mature component-oriented frameworks. Even ASP.NET
> (whose engineers, IMO, made the right decision to go with
> component-based approach and then screwed up every decision that
> followed) blows Rails out of the water when it comes to raw
> productivity once you get past the ORM mapping.
>
> Web applications tend to have four pillars that support them - model
> data, HTML output, UI state transitions, and "business logic" (this maps
> exactly to MVC, except that in Rails "C" is responsible for the last two
> tasks). Rails gets the first part right via ActiveRecord and doesn't do
> much at all for the other three beyond PHP improvements (which is a
> really bad standard to go by).
You obviously haven't actually done much rails programming. There is
a lot of support for things like session handling, login mechanisms,
tons of stuff. Unless you can really talk about specific things that
are missing I don't think your criticism is especially useful.
> HTML should be generated automatically from a high level declarative
> spec (I'll check this into Weblocks soon, and I believe Seaside can do
> this via Magrite library). UI state transitions should be stored and
> managed by widgets (where they belong). This lets you actually focus on
> business logic and high level UI definition, instead of writing HTML
> templates and doing server redirects.
I think declarative style HTML generation and UI transitions can be
very cool, but you are just dead wrong to say that this is clearly the
best way to do things. I also disagree with your characterization of
what is important in a web application, and what is provided by rails.
In many serious web deployments the gui will be designed by artists.
People who understand design, color, graphics and html. These
designers will build out the entire site in pure html (maybe with
javascript if you are lucky), and as the project progresses the
developers will be using these pages to drive development of the back-
end. In this kind of development scenario it is absolutely better to
use the strategy used in rails, where the dynamic parts of a page can
be replaced with bits of ruby which can be placed inline. This makes
it easier for web designers to update pages in the future, because
they have not been converted to a programming language DSL, and it
saves the developers HUGE amounts of time in getting a site up and
running. I won't argue that this is the only way to develop a web
application, but I think it has very strong merits that I've yet to
see be improved upon.
If you want to put together a web app on your own, or with a hacker
buddy, then sure, a declarative style is probably quicker and cooler.
There is a downside to this type of setup though, all sites created
with the same library tend to look the same. Sure, you can style it
out a bit, but realistically they tend to look the same. I think for
supporting a wide variety of sites the inline way is more flexible.
That said, there is absolutely no reason why a framework, rails
included, could not allow for both styles of html output.
> Yeah, Rails is better than PHP, but that's not a very big
> accomplishment.
I think the primary stack that rails (and Django) is replacing
industry wide is not PHP as much as Tomcat, Spring, Hibernate, etc.
Seaside is also a very nice framework, but I've talked at length with
seaside developers and they get many ideas from the rails world too.
They've also run into some major scalability problems with the
continuation based design, and many of the original features they
implemented are being replaced by more rails type design using AJAX to
give the same interactive user experience.
-Jeff
> --
> Regards,
> Slava Akhmechet.
d...@telent.net
> Rails is actually very good, if you consider ASP/JSP/PHP as its
> competition.
Non-specific urethritis is not to be turned down out of hand either, if
the alternative is being blinded in both eyes. I've heard of "faint
praise", but ...
-dan
Jeff
>
> > On Mon, 21 Jan 2008 04:10:19 +0000, Maciej Katafiasz wrote:
> >> Let's not. Rails is a really shitty way of doing things.
>
> > I don't really care either way, but Rails has gotten Ruby usage. This
> > might be because it is quite Mickey Mouse... But why is Rails a really
> > shitty way of doing things?
>
> First, I completely agree with what Slava said. Now to expand that a bit
> with my own thoughts:
>
> Rails is 100% magic with 0% design. It sports all the great quality and
> consistency you've come to expect from PHP, except with loads more magic.
> There's no overarching design or scheme of things, it's just a bucket of
> tools with some glue poured in. This has a couple of important
> consequences:
This is just dribble. If you sit in the rails mailing lists you will
find that people have and continue to spend a lot of time thinking
about design. There are absolutely overarching themes, and I would
even argue that it is exactly these themes which have made it so damn
popular. I think there have been two major lessons learned in rails
that many people have taken to other projects. First, is the whole
convention over configuration mantra. It gets annoying to hear this
kind of stuff so often in rails land, but it is a major benefit of
rails. Unlike many other frameworks, you don't spend eons writing XML
mappings for your ORM layer, or configuring 900 layers with
connections and parameters. They have plugged it all together in a
way that suites a large subset of web application needs, and if your
app fits in that bucket then it saves you a hell of a lot of time.
Once you know rails you really can build sites extremely fast because
so much of the work has already been taken care of.
> - There's no thought given to the general problem to solve, it's just
> improved PHP + "ActiveRecord, lol". This means Rails doesn't have
> solutions that are particularly good or scalable or make sense, only
> hacks that happened to solve someone's specific problem at a time and
> were implementable in 5 minutes or less. Rails is heaps better than PHP,
> but it's still only good for what PHP is good, and that's not writing
> webapps. This permeates Rails all the way down: it's got hacky modules
> that only solve particular problems, those modules have hacky functions
> that only solve particular problems and those functions only do hacky
> things that solved someone's particular problem.
This is just wrong. The "general problem" is creating database backed
websites that fall into certain constraints. Given the large number
of rails based sites I would say that many people have found they fall
within those constraints. I've built a number of sites in rails, and
I was never once forced to jump into the implementation of anything in
order to figure out what was happening. Unless you have some example
of a web framework that is doing things better at the higher layers, I
think you are just spouting B.S. when it comes to being good and
scalable. Many large sites are running rails, including some I've
helped implement, and a large number of people with web experience
have been quite happy with their increased productivity due to its
features. I would never argue that rails is the only way to build web
apps, but until you can provide some good examples of doing concrete
tasks better I don't think this is very useful.
A while ago I implemented an object relational mapping layer in
Javascript on the mozilla framework, and I used ActiveRecord as a
guide, so I have gone through the source quite thoroughly. I would
not say it is a major feat of design, but they have done a pretty good
job of abstracting out common functionality, wrapping DBs in a way
that makes it easy to add support for new back-ends, and I didn't find
any complex "magic."
> Some examples:
> * AR's find family of functions. It's a horrible hack, for instance,
> they support the :group clause, which has semantics ("return a collection
> of groups of things") incompatible with find's base semantics ("return a
> collection of things"). Rails answer? It implicitly relies on MySQL's
> retarded interpretation of SQL and the fact that given a table with two
> columns, id and colour, it will silently interpret "SELECT * FROM table
> GROUP BY colour" as "SELECT FIRST(id), colour FROM table GROUP BY
> colour". End result? A valid combination of clauses in AR will generate
> incorrect SQL Postgres will (correctly) choke on.
I can understand your frustration with this kind of thing, but you
have to realize that in supporting many different back-ends you always
run into this kind of problem. You can just do a find_by_sql() if you
want to do it yourself though, so I think this is a pretty obscure
complaint.
> * AR's find again, it supports :join (which documentation hilariously
> describes as "rarely needed"), except that it doesn't return real objects
> then, but make-believe fake readonly objects that will only have some
> attributes filled in (because they have no backing with physical rows),
> but will *still* have the base type and all the methods of the class you
> queried on! So if you go with that and try to call one of the methods
> that depend on unfilled attributes, you die horribly.
I have worked on top of a number of different database layouts using
ActiveRecord, and I have never once used :join. You will almost
always specify relations using the has_many, has_and_belongs_to_many,
or whatever declarations, which will add methods to your model class
and save you from having to ever do this.
> - Reading and, in general, understanding Rails is horribly difficult,
> since it's no design and layers upon layers of magic. Very often you will
> find 5-7 layers of functions delegating the work deeper and deeper in,
> until you arrive to a completely undocumented internal function that in
> turn splits the work to three other, unrelated internal functions. Given
> that each of those 10 functions takes a hash called "options", each layer
> altering it subtly, but none having the complete picture, and that 9
> times out of 10 that hash is not documented on any level, figuring out
> what your choices are is pure hell. It's made even more fun by the fact
> that different parts of Rails are accessible at various points of
> handling the request, and you can't just jump in and poke things from the
> console, since it won't have 99% of the things that only magically spring
> to life once a request is live.
You should use the debugger. You can insert a debug method call
anywhere you want, and then trace things or play with objects in the
middle of handling a request. Rails is probably one of the best
documented open source projects I have ever used, so although many of
the back-end is not fully documented, I think you are whining here.
If you want to know what options can be passed you should read the
documentation for the high level methods. If it's not there then you
shouldn't be using it. Any good design is built on a number of
layers, and that does mean that you have to go through them to trace
how things work. Putting everything into one or two layers would not
be better.
>
> - As a rule, there's no quality assurance, and the average quality is
> very low. Because it's such a patchwork, it will only have parts of
> things implemented, some other (not necessarily overlapping) parts
> documented, and a whole load of missing things just dangling and waiting
> for you to run into them. For example, the docs for
> text_field_with_auto_complete discuss how you can use options to make it
> complete only parts of entries (which was exactly what I needed, to show
> "foo (123)" in the popup, but only insert "foo" in the text field). What
> it doesn't tell you, however, is that none of the stock completion-
> generating methods will prepare such splittable data for you, and you're
> supposed to copy their code and hack it on your own instead. It took me
> half a day to finally understand that it wasn't me being stupid and
> unable to find it, but it was actually Rails documenting interfaces that
> _weren't there_.
Quality assurance? Dude, this is an open source project with a lot of
developers. They try pretty hard to make things clean and bug free.
I have run into issues like this as well so I agree it is not perfect,
but not a single piece of software I've used is.
> - And to stress the first point again, Rails never concerns itself with
> the big-picture problem of "writing webapps". It only thinks as big as
> "outputting HTML strings" and "querying the DB for a list of things".
> This means the important, actually hard stuff like handling the stateless
> nature of HTTP, or sanitising and escaping the user input is just not
> adressed at all, and you only learn about them when one day you discover
> 84 possible XSS injection points (actual number from a Rails app I'm
> somewhat famililar with).
There is very extensive session handling support with back-ends that
can go from in memory to in database to using a clustered in-memory
database for high speed scalability. You can also store small session
data in cookies. This is what you use for stateless HTTP, and it is
handled and discussed at length. Sanitising and escaping are handled
automatically for the vast majority of cases, and if you need to do it
by hand you can use their helper methods. A google search or a find
in the main ActiveRecord documentation would have shown you a number
of methods that start with sanitize_sql_*. For protecting from XSS
attacks there is a helper which makes this pretty easy. If you are
inserting user generated content from your database back into a view
you can use the h() method, which does html meta character conversion.
(Stopping you from using chars like < and >.)
<%=h post.text %>
> I'm a huge fan of innovative frameworks like Weblocks, because they
> actually stopped and thought about the whole thing for a moment, and try
> things that will address the problem as a whole. And even if some
> specific things will turn out to be harder to do that by just churning
> out raw HTML, and there will be abstraction leaks, it's still better
> because they try out new things to find a solution that has a chance
> work. Rails doesn't, because its entire culture seems to be fundamentally
> incapable of thinking more than 5 minutes into the future.
> Cheers,
> Maciej
I hope to give weblocks a try pretty soon. You need to be able to do
a real analysis of the benefits and drawbacks of a system before
complaining and creating something better. I have plenty of
complaints about Rails myself, but I haven't found solutions anywhere
else yet.
-Jeff
Jeff
>
> >>On Sun, 20 Jan 2008 05:58:57 +0100, Andreas Davour
> >><ante...@updateLIKE.uu.HELLse> wrote:
>
> >>>BDFL?
>
> >>He probably meant this:
>
> >> http://www.bdfl.de/
>
> >>Otherwise, this new "Google" thing seems to be quite helpful
> >>sometimes. Ever heard of it?
>
> Thx! Yer right!:http://www.ssvc.com/bdfl/index.htm
>
> Google rocks!
>
> > When in doubt about what a poster means, ask the poster instead of
> > trying to outguess him, was what I thought.
>
> We prefer guessing and being deliberately annoying so as to drive away
> unworthy noobs, defined as anyone we can drive away by being annoying.
> So far the only people in our net are unworthy dorks who sob that Kenny
> was mean to them as their parting shot. I have a belt with notches...
No sobbing here. I have really enjoyed getting into lisp and I want
the lisp world to figure its shit out so we can get an active, dynamic
community here doing interesting things. (That's not meant as
criticism towards what is here now, but I think everyone agrees that
life could be easier in lisp land.) I'm coming to realize you are just
a smart-ass and I was probably taking you too serious. That said my
comments are valid in terms of the attitude turning away people who
this community wants to attract. Fill that notch back in sensei. I'm
planning on hitting you with some pretty solid competition for cells/
cello in the future too, so get ready for a one-two combo punch!
-Jeff
> hth,kt
>
> ps.http://en.wikipedia.org/wiki/Guido_van_Rossum
>
> --http://www.theoryyalgebra.com/
Andreas Davour
>> > When in doubt about what a poster means, ask the poster instead of
>> > trying to outguess him, was what I thought.
>>
>> We prefer guessing and being deliberately annoying so as to drive away
>> unworthy noobs, defined as anyone we can drive away by being annoying.
>> So far the only people in our net are unworthy dorks who sob that Kenny
>> was mean to them as their parting shot. I have a belt with notches...
>
> No sobbing here. I have really enjoyed getting into lisp and I want
> the lisp world to figure its shit out so we can get an active, dynamic
> community here doing interesting things. (That's not meant as
> criticism towards what is here now, but I think everyone agrees that
> life could be easier in lisp land.) I'm coming to realize you are just
> a smart-ass and I was probably taking you too serious. That said my
> comments are valid in terms of the attitude turning away people who
> this community wants to attract. Fill that notch back in sensei. I'm
> planning on hitting you with some pretty solid competition for cells/
> cello in the future too, so get ready for a one-two combo punch!
Ken have in fact told me not to take him seriously. :)
Reading c.l.l have always been something of an Art. The kind of people
that show up here sometimes have a very obnoxious persona and sometimes
they are still worth listening to, and sometimes don't. Who deserves
what treatment is the Art. Good luck.
/Andreas
Slava Akhmechet
> You obviously haven't actually done much rails programming. There is
> a lot of support for things like session handling, login mechanisms,
> tons of stuff.
Absolutely, there is support for web-related special cases, but there is
no comprehensive solution for handling UI state (which component-based
framework provide with ease) and interaction-based state transitions
(which become almost trivial with lexical closures and judicial use of
continuations).
> In many serious web deployments the gui will be designed by artists.
I think you're confusing cause and effect. The only reason this setup
became an almost de-facto development model for doing web applications
is because early tools (ASP/JSP/PHP) strongly encouraged it, and because
CSS was in its infancy. Once you move past template engines and into the
world where you can effectively style pages with CSS, this development
model becomes obsolete.
> There is a downside to this type of setup though, all sites created
> with the same library tend to look the same. Sure, you can style it
> out a bit, but realistically they tend to look the same.
This is wrong! Just take a look at css zen garden - there dozens of
pages that look nothing like each other, but share the same HTML
file. Everything is done in CSS.
> They've also run into some major scalability problems with the
> continuation based design [...]
They don't run into scalability issues because of continuations. They
run into scalability issues because of the way they use continuations. I
actually disagree with this aspect of their design, and Weblocks uses
continuations very differently from Seaside (which I believe fixes the
scalability issues). In particular, I use delimited continuations, I
don't serialize them, and I don't store UI state in them (only the
stack). This way you get to write nicely structured code and forget
about redirects, but you don't attempt to use continuations and back
button as a form of undo (which I believe is a bad idea).
--
Regards,
Slava Akhmechet.
Ken Tilton
Jeff wrote:
> On Jan 20, 7:43 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>
>>Andreas Davour wrote:
>>
>>>Edi Weitz <spamt...@agharta.de> writes:
>>
>>>>On Sun, 20 Jan 2008 05:58:57 +0100, Andreas Davour
>>>><ante...@updateLIKE.uu.HELLse> wrote:
>>
>>>>>BDFL?
>>
>>>>He probably meant this:
>>
>>>> http://www.bdfl.de/
>>
>>>>Otherwise, this new "Google" thing seems to be quite helpful
>>>>sometimes. Ever heard of it?
>>
>>Thx! Yer right!:http://www.ssvc.com/bdfl/index.htm
>>
>>Google rocks!
>>
>>
>>>When in doubt about what a poster means, ask the poster instead of
>>>trying to outguess him, was what I thought.
>>
>>We prefer guessing and being deliberately annoying so as to drive away
>>unworthy noobs, defined as anyone we can drive away by being annoying.
>>So far the only people in our net are unworthy dorks who sob that Kenny
>>was mean to them as their parting shot. I have a belt with notches...
>
>
> No sobbing here. I have really enjoyed getting into lisp and I want
> the lisp world to figure its shit out...
Note to others: this is precisely where buttheads like ANdreas go on the
sh*t l*st of the CL community. Fortunately for Andreas there is no CL
community, went extinct in '92 IIRC.
> ...so we can get an active, dynamic
> community here doing interesting things.
Oh, goody, Andreas is here to save us! (Do we have any more room in the
back yard, or are we going to have to find a new place to bury these
self-appointed geniuses?)
Go do something interesting and get back to us, will you?
> (That's not meant as
> criticism towards what is here now, but I think everyone agrees that
> life could be easier in lisp land.)
Self-appointed judge of what we all agree on as well. Yer shootin fer
the record, aren't you?
> I'm coming to realize you are just
> a smart-ass and I was probably taking you too serious.
The latter cannot be done, so the former is irrelevant.
> That said my
> comments are valid in terms of the attitude turning away people who
> this community wants to attract.
I see. You have zero understanding of the language-chasing herd.
> Fill that notch back in sensei. I'm
> planning on hitting you with some pretty solid competition for cells/
> cello in the future too, so get ready for a one-two combo punch!
We're on the edge of our seats.
kt
--
Ken Tilton
Ken Tilton wrote:
>
>
> Jeff wrote:
>
>> On Jan 20, 7:43 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>>
>>> Andreas Davour wrote:
>>>
>>>> Edi Weitz <spamt...@agharta.de> writes:
>>>
>>>
>>>>> On Sun, 20 Jan 2008 05:58:57 +0100, Andreas Davour
>>>>> <ante...@updateLIKE.uu.HELLse> wrote:
>>>
>>>
>>>>>> BDFL?
>>>
>>>
>>>>> He probably meant this:
>>>
>>>
>>>>> http://www.bdfl.de/
>>>
>>>
>>>>> Otherwise, this new "Google" thing seems to be quite helpful
>>>>> sometimes. Ever heard of it?
>>>
>>>
>>> Thx! Yer right!:http://www.ssvc.com/bdfl/index.htm
>>>
>>> Google rocks!
>>>
>>>
>>>> When in doubt about what a poster means, ask the poster instead of
>>>> trying to outguess him, was what I thought.
>>>
>>>
>>> We prefer guessing and being deliberately annoying so as to drive away
>>> unworthy noobs, defined as anyone we can drive away by being annoying.
>>> So far the only people in our net are unworthy dorks who sob that Kenny
>>> was mean to them as their parting shot. I have a belt with notches...
>>
>>
>>
>> No sobbing here. I have really enjoyed getting into lisp and I want
>> the lisp world to figure its shit out...
>
>
> Note to others: this is precisely where buttheads like ANdreas go on the
s/andreas/jeff/w
kt
Andreas Davour
You are talking to the wrong person. Take another look at the
quoting.
/Andreas
Fishy Maps
> Den Mon, 21 Jan 2008 06:08:27 +0000 skrev Sohail Somani:
>
> > On Mon, 21 Jan 2008 04:10:19 +0000, Maciej Katafiasz wrote:
> >> Let's not. Rails is a really shitty way of doing things.
>
> > I don't really care either way, but Rails has gotten Ruby usage. This
> > might be because it is quite Mickey Mouse... But why is Rails a really
> > shitty way of doing things?
>
> First, I completely agree with what Slava said. Now to expand that a bit
> with my own thoughts:
>
> Rails is 100% magic with 0% design. It sports all the great quality and
> consistency you've come to expect from PHP, except with loads more magic.
> There's no overarching design or scheme of things, it's just a bucket of
> tools with some glue poured in. This has a couple of important
> consequences:
>
Have you actually built a web app with RoR? I've been using Java for
years and decided to give Ruby on Rails a try for my new fishing
website (http://www.Hooked-in.com). It was really easy to get up and
running (way easier than Java). The "convention vs. configuration"
concept took some getting used to, but once I understood it (which did
not take too long) it was really easy to deal with. Active record is
excellent. It's an excellent web application framework and I
recommend it to anyone who asks. I'm not a religious RoR bandwagon
guy, but I have to give the language and framework a lot of credit
based on my personal experience with it.
That said, if you said the thread model and concurrency is shitty, I
would agree with you. Java is night and day better. I'm hoping they
can fix that in the future.
- Joe
d...@telent.net
> Once you move past template engines and into the
> world where you can effectively style pages with CSS, this development
> model becomes obsolete.
Client: "What's that in the top right corner?"
Designer: "That's the email address of the current user"
Client: "Oh, can we have the italicised text 'You are logged in as' in
front of it?"
Designer: "Er, I'd better talk to the programmers ..."
(You can put plain text in a CSS "before" property, or an external
object such as an image. You can't, as far as I'm aware, put actual
document tree elements there)
-dan
Maciej Katafiasz
large part due to my post being #1 on programming.reddit.com for 16h or
so. So I'll say some things here and then let it die, if you excuse such
a rude behaviour on my part. ]
Den Tue, 22 Jan 2008 11:17:29 -0800 skrev Fishy Maps:
> On Jan 21, 7:47 am, Maciej Katafiasz <mathr...@gmail.com> wrote:
>> Rails is 100% magic with 0% design. It sports all the great quality and
>> consistency you've come to expect from PHP, except with loads more
>> magic. There's no overarching design or scheme of things, it's just a
>> bucket of tools with some glue poured in. This has a couple of
>> important consequences:
>>
> [...]
>
> Have you actually built a web app with RoR?
Yes. In fact, my current job description includes "RoR programmer",
though that's not what I actually do atm. But I have worked with a
decidedly non-trivial, commercial, pre-existing RoR app.
> I've been using Java for
> years and decided to give Ruby on Rails a try for my new fishing website
> (http://www.Hooked-in.com). It was really easy to get up and running
> (way easier than Java).
That's no argument. It's also way easier than BASIC and a few other
languages I could name. I never questioned claims that Rails was a
*better* way to build web apps than some other ways. I said it doesn't
make it *good* just because of that.
Tell you what, I've ported some (external) PHP code to Rails. It was a
joy, mostly because the original code was really badly written, but the
thing it did was fairly easy, only needed some simple DB access to
compute some hashes and then print them out. It wasn't even HTML. The
code is clean, around 40% of the original SLOC count, easy to read and
follow. For pretty much every webby thing PHP did (like accessing GET
variables, etc.), for which PHP is supposed to have dedicated and native
solutions, the corresponding Rails code was shorter, clearer, less
painful and more elegant. Ruby is remarkably lispy in certain aspects
(like everything being an expression, and having :keywords, which it
calls symbols), so it was fairly enjoyable to write in.
But even then, the ugly side of Rails reared its head several times. For
instance, AR explicitly says in the connection() method documentation:
"This can also be used to "borrow" the connection to do database work
unrelated to any of the specific Active Records."
But if you actually try to do this, you will find that sanitize_sql() is
protected, for no goddamn reason. Which makes it impossible to use
outside of AR, unless you open the class and un-protect the methods. That
nicely sums up the amount of thought given to AR.
Another problem was obtaining your own URL (ie. the one you were accessed
with). There's about a bazillion different places (and all of them
created dynamically, so looking them up in the docs is damn hard) that
should have the info, but they either have it only partially (e.g. sans
the GET string), don't at all, or don't work. The method I finally found
to work did so in violation of its docs.
>The "convention vs. configuration" concept took
> some getting used to, but once I understood it (which did not take too
> long) it was really easy to deal with. Active record is excellent.
It's not. AR is widely considered to be the worst part of Rails. It's a
terrible 20% hack that gives you some 60% or so of the most common cases
"for free", but pushing it even 0.001% further is impossible. And it
generates invalid SQL and fake objects, see my original post.
> It's an excellent web application framework and I recommend it to anyone
> who asks. I'm not a religious RoR bandwagon guy, but I have to give the
> language and framework a lot of credit based on my personal experience
> with it.
And I will continue to protest when someone gives it as a model for our
kids to follow, because our kids deserve better models.
> That said, if you said the thread model and concurrency is shitty, I
> would agree with you. Java is night and day better. I'm hoping they
> can fix that in the future.
I have honestly never interacted with that part of RoR, and I have
absolutely no interest in doing that.
Cheers,
Maciej
Maciej Katafiasz
> Slava Akhmechet wrote:
>> Once you move past template engines and into the world where you can
>> effectively style pages with CSS, this development model becomes
>> obsolete.
>
> Client: "What's that in the top right corner?"
> Designer: "That's the email address of the current user"
> Client: "Oh, can we have the italicised text 'You are logged in as' in
> front of it?"
> Designer: "Er, I'd better talk to the programmers ..."
Client: "Can you display "Welcome, <user's first name>" instead of the
email there?"
Designer: "Er, I'd better talk to the programmers ..."
So what? Content separation is an illusion, you ain't gonna have it. The
kind of content separation Weblocks does is way better, because it
actually insulates you from the fact it's all gonna be serialised into
HTML, which is a terrible medium for expressing user interfaces.
Cheers,
Maciej
Slava Akhmechet
> Client: "What's that in the top right corner?"
> Designer: "That's the email address of the current user"
> Client: "Oh, can we have the italicised text 'You are logged in as' in
> front of it?"
> Designer: "Er, I'd better talk to the programmers ..."
You know, I've worked on a number of web applications in defferent
contexts, and not once did something like this happen in practice. Most
of the time designers are paid to produce the design and are nowhere to
be found after that.
This seems to me to be a huge case of premature optimization. "May be,
when we actually get users, they'll ask us to change stuff, so we should
design software in a way that lets designers change bits of HTML." It
seems to me that basing your whole architecture on this premise is
silly.
--
Regards,
Slava Akhmechet.
Rainer Joswig
Slava Akhmechet <coff...@gmail.com> wrote:
I found that users do that all the time while we develop
software and after we have deployed the software. What we did
was to develop an architecture that puts the programmer
out of the way as much as possible and give the power
to the users (the online group of a sales department).
They change the layouts, they do the updates,
they do the analysis. This keeps the user happy and
they had given the team I was working with the highest praise.
Over several years the users have requested many additional
features - but they are using them - not the programmer.
If we had reserved layouts (really complex stuff involving
complex user models and pages assembled based on rights
of the user) to developers, the project would have died
early. Actually we revived the project by working
closely with the online department and trying to empower
them as much as possible. It was a constant flow
of sub-projects together with designers, content developers,
the online group, the developers and the guys operating the
systems. We tried to keep each groups in their area of competence.
Web programmers are usually poor web designers - and there
were lots of discussions what capabilities for changes
the online group needed. That was lots. Sometimes the
legal department requested changes on friday afternoon
that had to be implemented, tested and up and running on
friday evening. You can imagine that the developers did
everything to be able to stay out of THAT friday afternoon
loop and leave that to the online group. ;-)
Slava Akhmechet
> What we did was to develop an architecture that puts the programmer
> out of the way as much as possible and give the power to the users
> (the online group of a sales department).
I am all for giving power to the users! If the UI language is designed
correctly, you can create a UI to manipulate UIs via point and
click. You're making a good argument, but I still don't think it's an
argument in favor of templating systems.
Anyway, just give me a few more days to check in working code, then we
can talk about something concrete :)
--
Regards,
Slava Akhmechet.
nagler+b...@bivio.biz
> You obviously haven't actually done much rails programming. There is
> a lot of support for things like session handling, login mechanisms,
> tons of stuff. Unless you can really talk about specific things that
> are missing I don't think your criticism is especially useful.
I'll list a few that are missing from all frameworks I've seen
except bOP:
* Client-side-only continuations: no server side state to GC
* Stateless scalability: db is only non-GC state
* Transaction resources: single commit for emails, dbms, etc.
* Locks: OLTP requires non-db-centric complex computations
* Long transactions: import of complex data from client
* Integrated testing: workflows including mail, HTML, WebDAV, etc.
One of the problems with frameworks like Rails, Weblocks, and
Seaside is they are language-centric, just like PHP. bOP is
problem-centric. It's Perl but no Perl programmer would go near
it. :-) We have spent a tremendous amount of time pushing up
interesting components like WebDAV, file systems, testing, etc.
into bOP due the extreme constraint of a handful of programmers
actively developing and operating a dozen complex apps. We had
to solve the above problems and much more, because our dozen
different customers demanded they be solved, correctly.
Cheers,
Rob Nagler
bivio.biz
Slava Akhmechet
> I'll list a few that are missing from all frameworks I've seen
> except bOP:
>
> 1 Client-side-only continuations: no server side state to GC
> 2 Stateless scalability: db is only non-GC state
> 3 Transaction resources: single commit for emails, dbms, etc.
> 4 Locks: OLTP requires non-db-centric complex computations
> 5 Long transactions: import of complex data from client
> 6 Integrated testing: workflows including mail, HTML, WebDAV, etc.
Very interesting, thanks! I'll have to take a closer look.
Weblocks is specifically designed *not* to support 2 - I am very much
against RESTful web applications. IMO they provide an artificial limit
of what can be accomplished on the web. So Weblocks does the very
opposite and stores as much UI state as possible on the server. For the
same reason I actively avoided 1.
It seems to me that many frameworks have 3.
Numbers 4, and 5 seem to solve problems many web applications don't need
to solve, so it isn't a surprise you can't find them.
Could you talk a little bit more about 6 (or give a link to a
description)? How do you accomplish this?
--
Regards,
Slava Akhmechet.
d...@telent.net
> d...@telent.net writes:
>
>> Client: "What's that in the top right corner?"
>> Designer: "That's the email address of the current user"
>> Client: "Oh, can we have the italicised text 'You are logged in as' in
>> front of it?"
>> Designer: "Er, I'd better talk to the programmers ..."
> You know, I've worked on a number of web applications in defferent
> contexts, and not once did something like this happen in practice. Most
> of the time designers are paid to produce the design and are nowhere to
> be found after that.
As the saying goes, YMMV. I worked on web sites and web applications
for five years (actually, I'm doing it again now, but in a team of one
these situation tend not to arise as much ;-) and we used to get that
kind of request all the time - in fact, to the extent that we'd often
send the programmers to client meetings instead of the designers.
-dan
Jaroslaw Zabiello
> Rails is 100% magic with 0% design.
False. RoR is very clean framework using MVC paradigm, DRY and
Conventions Over Configurations principles.
> It sports all the great quality and
> consistency you've come to expect from PHP,
PHP is a piece of inconsistent mess. No namespace, inconsistent
function names, poor dynamism, no threading, loose typing. This was
created as template language only for C. On the other side, Ruby is
multithreaded, general purpose, full OO, strict typed, very higlevel,
dynamic language. PHP is a language, Rails is an aplication. So
comparing one to another is stupid. You can compare PHP with Ruby or
Symfony with Rails (or better - Merb).
> - There's no thought given to the general problem to solve, it's just
> improved PHP + "ActiveRecord, lol".
You have no idea what is Rails, LOL :-D
> * AR's
Forget about AR, check DataMapper (http://datamapper.org/) or better -
Sequel (http://code.google.com/p/ruby-sequel/wiki/CheatSheet) or even
AcriveHibernate (http://ola-bini.blogspot.com/2007/04/activehibernate-
any-takers.html). They can be used as a replacement for weaker Active
Record. Rails can also use JRuby (http://jruby.codehaus.org/) so you
can have access to all Java libraries just that.
> - Reading and, in general, understanding Rails is horribly difficult,
So do not use it. Use better and faster Merb (http://merbivore.com/)
Clean, fast, multithread etc. Merb is just better Rails :)
> I'm a huge fan of innovative frameworks like Weblocks,
It does not look mature. Why not Seaside? :)
> Rails doesn't, because its entire culture seems to be fundamentally
> incapable of thinking more than 5 minutes into the future.
It is only your oppinion. It is not too bad. BTW, I prefer Merb to
Rails. There are also more powerfull Zope3 (http://wiki.zope.org/zope3/
Zope3Wiki) and Pylons (http://pylonshq.com), but they use Python.
--
Jaroslaw Zabiello
http://blog.zabiello.com
nagler+b...@bivio.biz
> > 1 Client-side-only continuations: no server side state to GC
> > 2 Stateless scalability: db is only non-GC state
> > 3 Transaction resources: single commit for emails, dbms, etc.
> > 4 Locks: OLTP requires non-db-centric complex computations
> > 5 Long transactions: import of complex data from client
> > 6 Integrated testing: workflows including mail, HTML, WebDAV, etc.
>
> against RESTful web applications. IMO they provide an artificial limit
> of what can be accomplished on the web. So Weblocks does the very
> opposite and stores as much UI state as possible on the server.
In order for an application to scale, it must be stateless at some
level. Otherwise, routing and GC becomes a serious issue. I haven't
written a lot on statelessness, but this chapter in my book covers it:
http://www.extremeperl.org/bk/its-a-smop
> For the same reason I actively avoided 1.
Again, the more stateless the server (therefore the more state you
store on the client), the more scalable the application is. This is
the theory behind AJAX, unfortunately, most implementations require
way too many messages, thus destroying perceived scalability by
increasing path length unnecessarily.
> It seems to me that many frameworks have 3.
A transaction resource is something participates actively in a
transaction. Here's a scenario that bOP handles: Request requires a
file to be written to disk, an email to be sent to the user, and some
state committed to the database. If, say, there isn't enough disk
space, what happens to the SQL transaction and pending email? bOP
rollsback the entire transaction treating the email, disk file, and db
as a collection of transaction resources.
Transaction resources are very important for ACID semantics across
multiple databases.
> Numbers 4, and 5 seem to solve problems many web applications don't need
> to solve, so it isn't a surprise you can't find them.
An example of a long running job might be importing a book's text into
Amazon's Kindle site. The book has to be broken into chapters,
formatted properly (errors reported), and even better yet, the links
in the book might be analyzed for validity. I guess that Amazon
doesn't handle this latter part, because "web applications don't need
to solve" this type of problem.
Web applications need locking if they are doing anything more than
simple CRUD. For example, a web application should audit consistency
after certain types of transactions. On bivio.com, to give a specific
example, we need to make sure that member share allocations are
corrected when a historical accounting transaction is edited. You
have to lock the investment club's accounting data, but all clubs'
acccounting data. Another example might be adding inventory to a web
store. You'd like to do this when the shipment comes in, not in
batch, so that you have the most current inventory information on your
site at all times. Typically, people solve this by using stored
procedures, which of course kills scalability.
bOP is problem-centric, or in linguistic terms, proscriptive. Your
statements about Weblocks and web applications in general indicates a
prescriptive attitude, that is, there's an assumption about what a web
application is, which is limited by your world view. Go back and read
the 1980s SIGPLAN articles, if you are interested in the proscriptive
vs prescriptive debate. It's rather hilarious.
bivio's real world business constraints are purely proscriptive. We
don't get to choose what we implement for our customers. Rather, our
job is translating their desires into executable code. We've been
doing this successfully for 9 years now. We do not debate
prescriptive vs. proscriptive, we solve problems for real customers
and evolve bOP to better suite their needs. Our change log might help
you understand what it is we have faced, and the types of
architectural changes we've implemented.
> Could you talk a little bit more about 6 (or give a link to a
> description)? How do you accomplish this?
bOP is open source, and has been since 2001, including it's
(antiquated) Pet Shop demo application. This includes about 300+ unit
tests and about 30 or so acceptance tests.
Cheers,
Rob
bivio.biz
Andrew Reilly
> Here's a scenario that bOP handles: Request requires a file to be
> written to disk, an email to be sent to the user, and some state
> committed to the database. If, say, there isn't enough disk space, what
> happens to the SQL transaction and pending email? bOP rollsback the
> entire transaction treating the email, disk file, and db as a collection
> of transaction resources.
How do you roll-back the sending of an e-mail? Does the transaction
system leave the things that can't be revoked or repaired to a final step?
Cheers,
--
Andrew
Joost Diepenmaat
> But if you actually try to do this, you will find that sanitize_sql() is
> protected, for no goddamn reason.
This is why I've concluded that protected methods are the work
Satan. Methods should be either fully public (and fucking documented
too) or fully private.
IIRC even Stroustrup was unconvinced of the usefullness of protected
methods.
--
Joost.
nagler+b...@bivio.biz
users.org> wrote:
> How do you roll-back the sending of an e-mail? Does the transaction
> system leave the things that can't be revoked or repaired to a final step?
You can't rollback the email, but you can say whether it is likely for
the email to be queued by the MTA. This is all a DBMS does. The
advantage a DBMS has is that all it has to do is figure out if there's
enough allocable space and if the transaction is consistent.
A simpler example is a disk file object. The first phase consists of
writing the file to disk -- first locking the associated database
record. If this works, the transaction resource is put on the request
context's transaction resources list. If this doesn't work (e.g. no
more disk space), an exception is thrown and all resources are
notified to rollback -- pending emails are tossed, databases are
rolled back, pending disk files are deleted, etc.
Here's something that talks in general terms about transaction
resources:
http://www.iona.com/support/docs/orbix/gen3/33/html/orbixots33_pguide/intro.html
None of this is new, nor is it unique to the problems we solve at
bivio. As usual with history, we are so ready to escape the past
(e.g. transaction managers like Tandem's Pathway) that we forget all
the stuff that was learned when all software development was
server-side only. Here's something I wrote back in 2001 on the
subject:
http://www.bivio.biz/hm/why-bOP
Cheers,
Rob
r
> - And to stress the first point again, Rails never concerns itself with
> the big-picture problem of "writing webapps". It only thinks as big as
> "outputting HTML strings" and "querying the DB for a list of things".
> This means the important, actually hard stuff like handling the stateless
> nature of HTTP, or sanitising and escaping the user input is just not
> adressed at all, and you only learn about them when one day you discover
> 84 possible XSS injection points (actual number from a Rails app I'm
> somewhat famililar with).
>
My god you guys, bOP and Weblocks are sporting demos that look JUST
LIKE PHP BUSINESS APPS FRAMEWORK CALLED "ATK":
:-)
Howling in the wilderness...
Maciej Katafiasz
> nagler+b...@bivio.biz writes:
>
>> I'll list a few that are missing from all frameworks I've seen except
>> bOP:
>>
>> 1 Client-side-only continuations: no server side state to GC 2
>> Stateless scalability: db is only non-GC state 3 Transaction resources:
>> single commit for emails, dbms, etc. 4 Locks: OLTP requires
>> non-db-centric complex computations 5 Long transactions: import of
>> complex data from client 6 Integrated testing: workflows including
>> mail, HTML, WebDAV, etc.
> Very interesting, thanks! I'll have to take a closer look.
>
> Weblocks is specifically designed *not* to support 2 - I am very much
> against RESTful web applications. IMO they provide an artificial limit
> of what can be accomplished on the web. So Weblocks does the very
> opposite and stores as much UI state as possible on the server. For the
> same reason I actively avoided 1.
Where does the limit come from though? If we assumed that client-side
closures could express exactly the same as server-side (ie. you'd be able
somehow to reconstruct the closure precisely from its stored description,
and it'd be indistinguishable from the original), would you still oppose
it?
Stored continuations are a really good thing for the programmer UI (and
implicitly also the end-user UI, as you can do more interesting things
when you have better tools), but they also have definite sharp and ugly
edges, namely the limited lifetime of URLs and the fact you can't
reliably link them (nor can you read a "closureified" URL and infer its
meaning the way you can do that with "sort_by=name&order=ascending").
What I'd really want to have would be a mixed approach solution that
would get you the best of both worlds -- have the stored closures and use
them, but also encode them in readable URLs and provide sort of "default
constructors" that could interpret such a readable URL and construct
baseline state to work with in the absence of stored one. Linking is a
powerful tool, you can't really take it out of the Web and call it Web
still.
Rob: how does bOP fit into the above? Does what I say make sense to you?
Cheers,
Maciej
nagler+b...@bivio.biz
> Rob: how does bOP fit into the above? Does what I say make sense to you?
It makes sense, and if we could solve the halting problem, we could do
what you want. Since you can't trust the client, you have to validate
the program that comes back.
bOP takes a limited approach. The stack is limited to a specific set
of parameters which are well known (task, realm, query, path info,
form data) which can be validated easily, since that's what happened
the first time around. We don't encrypt this data, since it is was
probably sent from the client anyway. (We never give the client
something that it didn't give you or couldn't get otherwise.)
For proper closures, you'd have to store actual code. You can't
guarantee that the code will terminate. You could do run-time limits,
and perhaps that's good enough for typical UI code. You would also
have to sandbox the code.
The complexity of "seamless" client-side closures begs the question if
they are realy needed. I don't think so. People build interesting
distributed UIs without them. I also don't think you can get around
the fact that messages get lost, delayed, and duplicated in a
distributed system. (Read the CATOCS debate.)
Extremely complex systems have been built with idempotent messages,
and the way I see it, that's good enough for me. I prefer idempotency
for its simplicity (and hence security/reliability) over multi-path
stateful designs.
It requires some work to think statelessly, but it's really just a
different set of abstractions than what you may be used to. Just like
Lisp is a different set of abstractions than what most programmers are
used to -- I knew I could work Lisp back into the conversation. :-)
Well, not really, because "any sufficiently [complex system] contains
an ad-hoc, informally-specified bug-ridden slow implementation of half
of Common Lisp."
I confess that bOP is a prime example of something that could be
better written in Lisp. However, that's not where we are, and it's
not much of a hindrance to program in Perl. The hard part for me is
figuring out the application abstractions, anyway.
Cheers,
Rob
Rob Warnock
<nagler+b...@bivio.biz> wrote:
+---------------
| Maciej Katafiasz <mathr...@gmail.com> wrote:
| > Rob: how does bOP fit into the above? Does what I say make sense to you?
|
| It makes sense, and if we could solve the halting problem, we could do
| what you want. Since you can't trust the client, you have to validate
| the program that comes back.
|
| bOP takes a limited approach. The stack is limited to a specific set
| of parameters which are well known (task, realm, query, path info,
| form data) which can be validated easily, since that's what happened
| the first time around. We don't encrypt this data, since it is was
| probably sent from the client anyway. (We never give the client
| something that it didn't give you or couldn't get otherwise.)
|
| For proper closures, you'd have to store actual code.
+---------------
Actually, you don't. What it a closure, anyway? It's just a tuple
of a function and its lexical environment. The code for the function
is (effectively) static within the application, is probably compiled
[at least for Lisp], and making multiple closures with the same
function code doesn't require copying the code for the function.
So you can safely send just the lexical environment portion of
the closure as "data" to the user's browser [I tend to use POST
forms with <INPUT TYPE='hidden'> data for that instead of encoding
it into a GET URL] and get it back when the form gets submitted.
You can recreate the original closure if you could only create
a suitable lexical environment and close the original function
over it.
Enter the technique of <http://en.wikipedia.org/wiki/Lambda_lifting>
a.k.a. closure conversion. "All you have to do" [yes, I know I'm
oversimplifying horribly] is lambda-lift the function from the
original closure [*once*, not every time you create a new closure],
externalize the values of the free variables at the time of closure,
and send the externalized values in the web page as hidden data
in a form (or forms), plus one additional tag to indicate *which*
of the many lambda-lifted functions should be called when the
response comes back [when the user submits the form]. When it does,
a dispatch function in your forms processor validates the returning
data by some appropriate means[1], and then calls the lambda-lifted
function, within which call the (newly-)bound (formerly-free)
variables will have the same values as when the original closure
was captured. Simple. ;-}
[1] Yes, the lambda-lifting operation needs to be provided with
enough meta-information so that it know not only how to
externalize the current values of the function's free variables
but also how to validate those values when they come back from
the user's browser. A cryptographic hash (such as an HMAC) of
the closure data in the form data pretty much takes care of the
validation part, so the client can't ever get you to respond to
a closure environment you didn't send it first. On the other hand,
validating the *variable* input data the client is *supposed* to
provide is a much harder problem.
+---------------
| You can't guarantee that the code will terminate.
+---------------
Yes you can, since the function itself (which you wrote) is never
sent to the user -- only the closure environment data.
+---------------
| You could do run-time limits, and perhaps that's good enough for
| typical UI code. You would also have to sandbox the code.
+---------------
No you don't, since the code was/is only on the server, inside
your application. You *do* need to sanitize/validate the closure
data values coming back from the user, though, as well as any
user-provided variable input. See [1] above.
If you don't want to have to fake up more-or-less real "continuations"
to run the lambda-lifted functions + data (closures) in, you can of
course CPS-transform your application manually, such that *every*
user request goes through an OLTP-like dispatcher which simply runs
the proper (lambda-lifted) global function with "the right" args.
[That's the way I tend to write my Lisp-based server-side applications.]
But even just having the *idea* of closures in your head when doing
so makes it a lot easier to structure the user interactions. It lets
you keep all that ugly "session" data [e.g., state of "shopping carts"]
out of the server, which helps scalability. It lets the user explore
alternative interaction paths in multiple browser windows without
unwanted "leakage" between them -- which cookies don't! [Sometimes
you *want* a little bit of controlled "leakage", of course, such as
a quiz where you let the user try as many paths as they want, but
then only let them "submit" one of them for credit.]
Anyway, I'm just trying to point out that the only part of a closure
you need to send/retrieve from the client is the closure's lexical
environment (hopefully externalizable data), *not* the code for the
function itself.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Slava Akhmechet
> Where does the limit come from though?
From what I understand, the process of serializing, storing, loading,
and deserializing continuation objects puts a large strain on the
server. I suppose some IO can be optimized with caching, but I can see
how doing this for every request can get very expensive.
> If we assumed that client-side closures could express exactly the same
> as server-side (ie. you'd be able somehow to reconstruct the closure
> precisely from its stored description, and it'd be indistinguishable
> from the original), would you still oppose it?
I am not sure, may be. The idea of sending the lexical environment back
and forth to the client doesn't appeal to me.
> Stored continuations are a really good thing for the programmer UI (and
> implicitly also the end-user UI, as you can do more interesting things
> when you have better tools)
I am not convinced of that. Continuations are really good for
structuring code, but I don't see the practical benefits of storing UI
state them and using them as a time machine.
--
Regards,
Slava Akhmechet.
r
Also, I don't mind if Rails, which I don't use, continues to be
unstoppable...it just means more support for Prototype/Scriptaculous
which I do use!
ATK bundles those two libs :-)
I don't care if PHP is considered crap and no self-respecting
programmer would pursue it--look at ATK...it's declarative as I need
it to be for the plumbing with enough nooks and crannies to get
anything done. And declarative without being some powerless markup or
"mini-language". Declarative in the language.
nagler+b...@bivio.biz
> No you don't, since the code was/is only on the server, inside
> your application. You *do* need to sanitize/validate the closure
> data values coming back from the user, though, as well as any
> user-provided variable input. See [1] above.
[The other other Rob responds. ;-]
I think this is oversimplified. Version management would be a
nightmare if all you sent was the lexical context's values. Each
function's lexical context would have to be signed in such a way that
you would know that the lexical context changed between browser
clicks.
This seems similar to the problem of stored procedures with the
ability to pass continuations to the database.
> If you don't want to have to fake up more-or-less real "continuations"
> to run the lambda-lifted functions + data (closures) in, you can of
> course CPS-transform your application manually, such that *every*
> user request goes through an OLTP-like dispatcher which simply runs
> the proper (lambda-lifted) global function with "the right" args.
> [That's the way I tend to write my Lisp-based server-side applications.]
Interesting. This is what we do in bOP, but we formalize a few
things. All FormModels are versioned so we can detect when a client
submits old form data or when the client calls a "continuation". (We
say "unwinds FormContext", but it's the same thing.) IOW, the entire
lexical context is versioned explicitly, which means we can do
releases any time, and be (relatively :-) sure the code will execute
safely. Also, all form data goes back through a FormModel's
validation code before it is executed (but not when it is unwound,
since the initial data may have been invalid, e.g. the user went to go
look for a stock ticker symbol).
> But even just having the *idea* of closures in your head when doing
> so makes it a lot easier to structure the user interactions. It lets
I agree. I have found that it's very hard for people to understand
continuations. I barely understand them, and I wrote the damn
code. :-) The big problem for many programmers is that these
continuations hang out in cyberspace until someone clicks. That's
fairly tricky to understand, because it can happen when you least
expect it. And, with bOP's FormContext, you can "reach up the stack"
to modify a variable (upvar in Tcl, but I'm sure there's an equivalent
in Lisp). This is a very useful and easy to use feature, but keeping
all that state in one's head is difficult. That's why I think
generalized CPS over the wire would likely result in many security
holes. Even our limited CPS approach has resulted in numerous
security holes.
> Anyway, I'm just trying to point out that the only part of a closure
> you need to send/retrieve from the client is the closure's lexical
> environment (hopefully externalizable data), *not* the code for the
> function itself.
I was thinking you need both for version consistency.
Also, I believe the HMAC validation opens you up to Black Swans. If
the HMAC was cracked, you'd have a very nasty injection attack on your
hands. I also think that you would open yourself up by transferring
interesting (and well-structured) state which would then be subject to
offline (read: parallel) attacks. This is probably my biggest concern
of generalized client-side continuations. You are divulging
significant application state AND a way to inject arbitrary code (via
the lexical environment which might include an eval along the way).
That's also why I was thinking about sandboxing and run-time limits --
as protections against Black Swans.
Cheers,
Rob
P.S. There I was just typing my response in Emacs, and was ready to
stuff it back into GoogleGroups, which said:
Your session has expired, please try again later.
If you believe this is an error, please contact Google Support.
Yes, sessions are an error. :-)
Rob Warnock
+---------------
| rp...@rpw3.org (Rob Warnock) wrote:
| > Anyway, I'm just trying to point out that the only part of a closure
| > you need to send/retrieve from the client is the closure's lexical
| > environment (hopefully externalizable data), *not* the code for the
| > function itself.
|
| I was thinking you need both for version consistency.
It doesn't really help, so why waste the bandwidth? Yes, as you
pointed out, you really need versioning on the stuff that comes
back from the user [thanks for this observation!], but it really
doesn't matter whether the function code for the closure is
physically sent to/from the user or not -- you still have the
version consistency problem in either case.
That is, if the function code for the closure isn't sent [as I
recommended], then as you noted you can have version skew between
the externalized lexical environment and the function code. But
even if the closure function code *is* sent, you can still have
version skew between the code that was sent and what the *current*
execution environment in which that function code is going to run
expects. That is, what's *around* the continuation execution has
to match the continuation in either case. So given that, there's no
advantage [and plenty of disadvantages] in sending the actual code.
[Let us now drift even further off-topic, into cryptography... ;-} ]
+---------------
| Also, I believe the HMAC validation opens you up to Black Swans.
| If the HMAC was cracked, you'd have a very nasty injection attack
| on your hands.
+---------------
Note that I *didn't* say "use some random hash as a MAC" (Message
Authentication Code); I said "use HMAC", by which I meant specifically
the algorithm defined in RFC 2104 "HMAC: Keyed-Hashing for Message
Authentication" <http://www.ietf.org/rfc/rfc2104.txt>. The salient
point here is the *key*, which in this scenarios would be a secret
key stored only on the server. Specifically, the client *never knows*
the key! It is never transmitted. Only the HMAC result is transmitted
and then received/verified. The client (or an attacker) can't even
duplicate the HMAC they received, even with the cleartext data in hand.
If HMAC-SHA-256 or even just HMAC-SHA-1 [see RFC 2104] were to be
"cracked", a whole lot more financial towers would be falling than
your or my web sites! HMAC-SHA-n (for n = 1, 256, 384, 512) are used
*everywhere*, including in IPsec. [There might even be a Nobel Prize
in that achievement.]
But the HMAC construction is *significantly* stronger than just
the hash that is used. Even HMAC-MD5 is still thought to be quite
safe, even though weaknesses have been demonstrated in MD5 itself in
certain specific contexts [which don't include the usage in HMAC-MD5].
Finally, an HMAC neatly handles the versioning problem: simply
change the HMAC key when the version changes, and previous closure
states will no longer validate!
+---------------
| I also think that you would open yourself up by transferring
| interesting (and well-structured) state which would then be
| subject to offline (read: parallel) attacks.
+---------------
HMAC is much, *much* less vulnerable to an offline attack than
"just a hash". For the latter, yes, a massive offline collision
attack might allow you to twiddle some bits of the state, e.g.,
the now-well-known collision attack against MD5 can change a small
number [three? six?] of specific bits in a 1024-bit message. [Not
any six bits, mind, but six specific bits in fixed places within
the 1024-bit message. Only those few bits, and either all are
flipped or none are.] MD5 has *still* not been shown to be vulnerable
to the more useful "second preimage attack" with anything less
than brute force, with cost 2^128/n hashes, where n is the number
of hashes you're trying to break simultaneously.[1]
As I said above, for HMAC neither an attacker nor even the client
*itself* can duplicate the hash output given only the input data
(state). The secret key is required, since the algorithm is:
H(K XOR opad, H(K XOR ipad, text)) [see RFC 2104, sect. 2 p. 3]
Without knowing the key, an offline attack is not feasible.
[An online attack is, but the attacker would have to submit
an average of 2^127 forged requests to your server to get
just one through. Fat chance. He'd look like a DoS attack and
you'd firewall him off long before he got anywhere close.]
And if you're using HMAC-SHA-1 or HMAC-SHA-256 instead of HMAC-MD5,
then replace all of the "2^128" above with "2^160" or "2^256".
+---------------
| This is probably my biggest concern of generalized client-side
| continuations. You are divulging significant application state...
+---------------
O.k., then encrypt just the application state with something strong,
like AES-CTR with a nonce as part of the key. BUT STILL USE AN HMAC
ANYWAY! [And be sure to do do crypt-before-auth, *NOT* auth-before-crypt.
The latter is provably weaker.]
+---------------
| ...AND a way to inject arbitrary code (via the lexical environment
| which might include an eval along the way).
+---------------
Not with an HMAC with any of the strong hashes. But again, see [1]
for the dangers of plain hashes as MACs in the presence of EVAL...
-Rob
[1] See the following for how in the presence of some sort of
interpreter process (e.g., Postscript files, say, or Lisp EVAL)
even the limited Wang/Feng/Lai/Yu-style MD5 collisions can
be used to perform attacks that look on the surface *as if*
they're full "chosen second preimage" attacks:
http://www.docbug.com/blog/archives/000372.html
http://www.cits.rub.de/MD5Collisions/
An even faster approach is here:
http://eprint.iacr.org/2006/105
Vlastimil Klima, "Tunnels in Hash Functions:
MD5 Collisions Within a Minute"
So your concerns about an unrestricted EVAL of the closure
state is well-warranted... *if* using simple hashes for MACs.
But again, unless the attacker knows the key, HMAC is immune
to these types of attacks [for less than brute-force cost].
Damien Kick
> Jeez, all I did was make fun of the idea that using free software is
> liberating as opposed to enslaving*, and I did so on Usenet. You now
> feel personally put-upon, offended, attacked, blah blah blah. I don't
> think it works that way.
When Fanboys Shill FSF, everybody loses.
Damien Kick
> Proprietary software advocates are the sort of people who think that
> allowing professional athletes into the Olympic Games was an
> improvement.
The kind of people who think that sports competitions are enhanced when
all of the best athletes are allowed to compete?
robn...@gmail.com
> expects. That is, what's *around* the continuation execution has
> to match the continuation in either case. So given that, there's no
> advantage [and plenty of disadvantages] in sending the actual code.
How do you solve the versioning problem?
Cheers,
Rob
Rob Warnock
+---------------
| rp...@rpw3.org (Rob Warnock) wrote:
| > expects. That is, what's *around* the continuation execution has
| > to match the continuation in either case. So given that, there's no
| > advantage [and plenty of disadvantages] in sending the actual code.
|
| How do you solve the versioning problem?
I take it you didn't bother to read the *rest* of my reponse?
-Rob
nagler+b...@bivio.biz
> I take it you didn't bother to read the *rest* of my reponse?
I did, but don't see how it relates to versioning. I understand
your position that HMAC is secure in detecting changes on the
client side. Just don't see how that helps with server side changes.
Specifically, how do you distinguish when an incoming request can
no longer be satisfied by the resident lexical context?
Cheers,
Rob
Rob Warnock
+---------------
(*sigh*) I thought it was clear, but I'll try again. Quoting myself:
Finally, an HMAC neatly handles the versioning problem: simply
change the HMAC key when the version changes, and previous closure
states will no longer validate!
*Only* the server ever has the HMAC key(s)! All you have to do
is pair HMAC keys with versions, and when you change versions on
the server change the key [on the server]. Changing the HMAC key
automatically invalidates any previous lexical contexts saved on
the client.
To be even more explicit: When constructing an HTTP response containing
the lexical context for a closure, perform an HMAC over the closure
context using the current server-side key, which is associated with
the current version of both the closure's function code and the code
*around* the closure in which the continuation will run. Send the
result of that HMAC as part of the HTTP response along with the
closure context [and the rest of the response page, forms, menus,
text boxes, etc.]. If/When the client uses a form on that response
page to make a further request, *both* the lexical context and the
HMAC will be submitted back to the server [along with the rest of
the request, including any variable data supplied by the user].
When the server gets the new request, once again compute an HMAC
over the lexical context in the request, using the key *NOW CURRENT*
on the server. Compare the result to the HMAC sent from the client.
If they match, then (1) the client hasn't tampered with the closure
context and (2) the closure context is still of the proper version.
Create an enviroment containing the closure context and call the
closure function to handle the request. [If no match, return a
"session expired" error page (or equiv.).]
Capsiche?
-Rob
p.s. If you want to get really fancy, you can save a sliding
window of acceptable previous closure code versions along with
their keys, and try matching previous keys with HMACs of submitted
client data. If there are too many acceptable previous versions,
this may become somewhat expensive in CPU time, since for each
request received by the server it will have to completely recompute
the HMAC once for each previous still-valid version, but it might
prove helpful to at least have the option in some situations.
nagler+b...@bivio.biz
> closure function to handle the request. [If no match, return a
> "session expired" error page (or equiv.).]
I see how this avoids the problem of closures executing in incorrect
lexical contexts. What I don't understand is how you would avoid
bumping the key on every release.
The larger systems we develop and maintain have 500 to 1000 tasks
(entry points). We would have no idea if one of us (and there are
only five of us :-) touched something that would affect a lexical
context of any particular continuation. Therefore, we'd have to bump
the version on every release.
While it is certainly possible to bump a global version every release,
this really doesn't solve the problem I would like to solve, namely,
seamless releases. When we release a new version of our apps, users
don't notice unless their browser happens to have a stored
continuation which has had its version bumped. If the particular
continuation is used frequently, e.g. the login continuation, we can
handle multiple versions in the same server to make the upgrade
seamless.
With a global version number (key), users will get bumped off the
system after every release, just like a session-based system. The
coupling between the client and server is too tight, in other words.
While I understand this is all well and good for small apps, but I
could argue that pretty much any other solution (sessions, Seaside,
.NET, etc.). The versioning problem in small apps is red herring,
because there aren't enough users for it to matter.
Rob
beck...@googlemail.com
Maciej Katafiasz wrote:
> Den Mon, 21 Jan 2008 06:08:27 +0000 skrev Sohail Somani:
>
> > On Mon, 21 Jan 2008 04:10:19 +0000, Maciej Katafiasz wrote:
> >> Let's not. Rails is a really shitty way of doing things.
> >
> > I don't really care either way, but Rails has gotten Ruby usage. This
> > might be because it is quite Mickey Mouse... But why is Rails a really
> > shitty way of doing things?
>
> First, I completely agree with what Slava said. Now to expand that a bit
> with my own thoughts:
>
> Rails is 100% magic with 0% design.
I get your point,but perhaps no design is a good thing?. No one knows
what tomorrow will bring, and chances are that your design today won't
meet your needs of tomorrow (the basic idea behind YAGNI - You Ain't
Going to Need It). The idea of deferring design design to the last
possible moment doesn't only occur in software, but underpins lean
product development, manufacturing etc.
In my epxerience BUF (Big Upfront Design) is almost always wrong for
any given specific instance and often represents waste (time that
could have been better spent doing something else) and restricts
freedom and alternative design choices later on. Perhaps Rails is
successful because it makes very few big design decisions, leaving
those decisions to the application programmer?
I am not a Rails expert, but what I like about it is that it is
basically a bottom up framework, which bubbles up useful DSLs which
address common problems in the web programming domain. It doesn't try
to "solve the big picture". It is a toolbox of bits which are
relatively transparent and simple.
I am not sure about it being 100% magic. To me a Rails application is
very readable. The whole point of a good DSL is that it should be
readable. The fact that Rails DSLs use meta techniques don't make them
magic. The code is there if you need to understand the detail. If the
DSL is designed well though and the code is self documenting then you
shouldn't need to delve under the covers into "meta-land". You may be
right that some of the DSLs in Rails could be improved. But DSLs
evolve over time anyway.
Rails is just one approach. No big picture, just a bunch of neat DSLs.
Alternatively Seaside for example takes the alternative approach -
"Big Picture", which ties you into an overall design. I see value and
beauty in both, I don't believe that either one or the other is
intrinsically "better".
Paul.
Robert Maas, see http://tinyurl.com/uh3t
> > lisp until a more algebraic notation that was good enough could be found.
> From: funkyj <fun...@gmail.com>
> I like parenthesis. What is wrong with them? Don't s-expressions
> make writing macros a whole lot easier?
Indeed, a case where something intended as a temporary hack turned
out to be such a truly big win that it was kept forever, despite
attempts to make notation more "algebraic" as with Pratt's CGOL (on
top of MacLisp) and Hearn's Reduce/Rlisp (on top of SL and PSL) and
MacSyma (on top of MacLisp) and other various similar mathematics
application frameworks.
There's a real advantage, IMO, in *seeing* the parse tree *all* the
time as you write code, so when it's time to write a macro that
generates a parse tree it comes naturally because you already know
what you want to generate from months/years of practical experience
and mental visualization. Imagine if you programmed in something
like Java's syntax but internally it was all in parse-tree form,
and you had to suddenly think back and forth between the
source-language you already know and the parse-tree you never saw
before when you try to write your first macro? (No wonder Java
doesn't support macros! Nobody would be able to figure out how to
use it except Don Knuth and a couple other people like that.)
> arc tangent: I really like the idea of a better CL. I'm a lisp
> newbie and, like other newbies what I really crave is a standard
> and easy to understand package system.
IMO, CL has several really winning new mechanisms compared to
earlier Lisps that I used: Keyword parameters, Multiple value
returns, Anonymous lexical closures that are so very easy to use
(compared for example with Java's anonymous inner methods). I still
think it would be nice to be able to define new types of streams,
like MacLisp filearrays. Maybe the best way to do that is to
convert all existing streams to fullfledged OO-objects, or at least
allow CLOS objects to be passed to all stream-handling primitives
such as OPEN and READ-CHAR, then it'll be easy to use CLOS to
define new types of streams as standalones or as wrappers upon
existing stream types?
Otherwise I think all CL needs is to implement all the goodies such
as XML parsing and UUENCODED-FORM-CONTENTS and HTTP streams etc.
that Java has already, and all that can be done as add-on packages
with existing implementations of CL. No need to change the language
itself.
As for co-routines (call/cc), would threads be sufficient to
emulate that decently enough?
> ... I would like to use CL where I currently use Perl/Python
> (i.e. small utility programs and hobby projects) but it is
> currently way too hard to do these small programs in lisp.
You gotta be kidding!!! CL is the *best* language for scripting!!
Unlike shell scripts, everything is *structured*, as lists nested
cleanly to arbitrary level! I dare you to cleanly write a Unix
shell script that takes three parameters, each of which contains a
list of arbitrary many sub-parameters of arbitrary name.
For example, what's the Unix shell-command equivalent of:
(compile-and-load-and-run (-compileANSI-Pedantic -silent-type-coercion)
(-require-libraries (stdio xml)
-memory-optimize-paging (megabytes 8))
(-load (foo bar gletch intarith)
-asdf (simmat ansiquaternions)))
Note that loading foo etc. is done at runtime, but stdio is built
in at load time, just because I felt like doing that today.
When you mention Perl/Python, I assume you are really using those
languages to be invoked to process Unix shell commands with -parms?
So you suffer the same flat syntax from Unix shell commands that
you'd get if you used sh or csh scripts instead?
So to emulate nested parameters to a script, you must go through
painful contortions, so painful that instead you write the nested
parameters as s-expressions or indented notation in a file and then
have Perl or Python parse that file to recover the intended
structure in the parms?
For example, suppose you have an application that can load in
several dictionaries, then collate several text files per those
dictionaries to compare usage of all the words in the dictionaries.
How would you pass the list of dictionaries and the list of files
to be collated to your Perl or Python script that interfaces to
that application?
Wouldn't it be nicer to use Lisp's R-E-P as your shell, so that you
can use parents to group sub-lists within your parameters you pass
to your script?
Note that CMUCL has a function called RUN-PROGRAM which can pass
control via Unix shell calling conventions to an arbitrary
standalone program. If Unix shell calling conventions aren't
sufficient to pass structured parameters, you could easily arrange
that CMUCL passes print-representation of those structured
parameters via a pipe or file to the program running on the
sub-process, passing the Unix stream handle or the temporary
filename via regular Unix parameters. It's easy to encapsulate all
this (Unix parameters, and structured parameters via side channels)
into a Lisp script running in CMUCL. So you call that toplevel Lisp
script in the same way you call any regular Lisp function, and all
the machinations to pass the structured and non-structured
parameters to the called application are transparent to the person
invoking the script.
> I know, I know, you serious macho lisp programmers sneer at my
> desire to have a CL suitable for scripting but that is what I want.
Not *this* serious lisp programmer!! (OK, I'm not macho, I don't go
around kicking sand in other guys' faces and stealing their
girlfriends.) I use CL to answer simple questions by writing
on-the-fly scripts very frequently. For example, just the other day
I absentmindely forgot whether 2^16 was 65536 or 65526, so I
started up lisp and asked (expt 2 16) and there was my answer.
How non-serious use of Lisp can you imagine!
Another example: I used to have a Lisp-based system to
automatically collect spam-complaint addresses for all IP ranges
that I was getting spam from. I had a database as a file full of
s-expressions. For example:
("200.034.000.000" "200.034.255.255" "adm...@intervan.net")
("207.219.000.000" "207.219.159.255" "ni...@psi.ca")
("152.169.000.000" "152.169.255.255" "tro...@aol.net")
There was a function to look up a given IP number in that database.
Sometimes I'd use it manually by making a direct call to that
lookup function from the keyboard, and then copy&paste the result
into a newsgroup article I was in the middle of composing.
(2) I really want my lisp environment integrated with emacs.
That's not too hard actually. A year or so ago I integrated Java's
BeanShell with emacs on Linux. I mark a range of Java source text
in a file I'm editing with Emacs, then click a control sequence
such as C-X C-B or somesuch, and that range of text would be passed
through a FIFO with BeanShell waiting at the other end to parse and
evaluate it in the window that was running Java+BeanShell. It would
be even easier to do the same thing with Common Lisp instead of
Java/BeanShell in the other window.
My typical usage was to write and debug one line of code at a time
(within an intended method definition I'm building up in the emacs
buffer) using a non-OO flavor of Java to separately execute each
line of code "manually", i.e. all intended local variables are
global BeanShell variables. Then as soon as all the lines of code
of the method are working I mark the entire span of the method
definition and pass that to BeanShell. Then I immediately execute a
test script manually to make sure the method as a whole works.
(The test script is in a /* comment */ immediately after the method
definition, so I just mark the region of the test script and pass
through the FIFO the same as before.)