top down programming in a bottom up language

241 views
Skip to first unread message

Jeff

unread,
Jan 18, 2008, 5:00:33 AM1/18/08
to
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.

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

unread,
Jan 18, 2008, 5:49:47 AM1/18/08
to
Jeff <ros...@gmail.com> 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)))
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

unread,
Jan 18, 2008, 6:19:59 AM1/18/08
to

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

unread,
Jan 18, 2008, 6:36:57 AM1/18/08
to
On Jan 18, 11:49 am, p...@informatimago.com (Pascal J. Bourguignon)
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

Message has been deleted
Message has been deleted

Peter Hildebrandt

unread,
Jan 18, 2008, 7:25:28 AM1/18/08
to
On Fri, 18 Jan 2008 12:53:47 +0100, Jose A. Ortega Ruiz <j...@gnu.org>
wrote:

> p...@informatimago.com (Pascal J. Bourguignon) writes:
>>
>> 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.

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

unread,
Jan 18, 2008, 8:24:44 AM1/18/08
to
Jeff <ros...@gmail.com> writes:

> 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

unread,
Jan 18, 2008, 8:27:24 AM1/18/08
to
"Jose A. Ortega Ruiz" <j...@gnu.org> writes:

> 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

unread,
Jan 18, 2008, 9:05:52 AM1/18/08
to
På Fri, 18 Jan 2008 14:27:24 +0100, skrev Pascal J. Bourguignon
<p...@informatimago.com>:

and edit macro and function definitions with ED.. :)

http://www.gnu.org/fun/jokes/ed.msg.html

--------------
John Thingstad

Ken Tilton

unread,
Jan 18, 2008, 9:33:34 AM1/18/08
to

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

unread,
Jan 18, 2008, 8:11:19 PM1/18/08
to
On Jan 19, 2:24 am, p...@anevia.com (Pascal J. Bourguignon) wrote:

[[ ... ]]

> 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

unread,
Jan 19, 2008, 4:11:27 AM1/19/08
to

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

unread,
Jan 19, 2008, 5:20:04 AM1/19/08
to

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

unread,
Jan 19, 2008, 4:08:28 PM1/19/08
to

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

unread,
Jan 19, 2008, 5:45:26 PM1/19/08
to
>>>>>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?

...

>>
>>>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

unread,
Jan 19, 2008, 7:09:35 PM1/19/08
to
On Sat, 19 Jan 2008 13:08:28 -0800, Jeff wrote:

> 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

unread,
Jan 19, 2008, 11:00:21 PM1/19/08
to
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).

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

unread,
Jan 19, 2008, 11:22:32 PM1/19/08
to
On Sat, 19 Jan 2008 20:00:21 -0800 (PST), funkyj <fun...@gmail.com> wrote:

> 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

http://weitz.de/eclm2008/

Real email: (replace (subseq "spam...@agharta.de" 5) "edi")

Andreas Davour

unread,
Jan 19, 2008, 11:58:57 PM1/19/08
to
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?

/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

unread,
Jan 20, 2008, 12:13:12 AM1/20/08
to
Andreas Davour wrote:
> 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

unread,
Jan 20, 2008, 12:16:30 AM1/20/08
to
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?

vanekl

unread,
Jan 20, 2008, 12:47:44 AM1/20/08
to
funkyj wrote:
> 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

unread,
Jan 20, 2008, 12:57:02 AM1/20/08
to
On Jan 19, 11:45 pm, Ken Tilton <kennytil...@optonline.net> wrote:
> >>>>>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?
>
> ...
>
> > 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.

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

unread,
Jan 20, 2008, 1:16:32 AM1/20/08
to
funkyj <fun...@gmail.com> wrote:
+---------------

| 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

unread,
Jan 20, 2008, 1:18:07 AM1/20/08
to
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.

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

unread,
Jan 20, 2008, 1:18:22 AM1/20/08
to
On Sat, 19 Jan 2008 20:00:21 -0800, funkyj wrote:

> 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

unread,
Jan 20, 2008, 1:34:50 AM1/20/08
to
Edi Weitz wrote:
[...]

> 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

unread,
Jan 20, 2008, 5:30:29 AM1/20/08
to
On Sun, 20 Jan 2008 07:18:07 +0100, Sohail Somani <soh...@taggedtype.net>
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

unread,
Jan 20, 2008, 6:15:15 AM1/20/08
to
On Jan 20, 5:22 am, Edi Weitz <spamt...@agharta.de> wrote:
> 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

unread,
Jan 20, 2008, 6:46:43 AM1/20/08
to
On Sat, 19 Jan 2008 22:34:50 -0800 (PST), Pillsy <pill...@gmail.com> wrote:

> Has anyone written a paredit equivalent for the LW editor.

I suppose they're all waiting for you to do it...

Edi Weitz

unread,
Jan 20, 2008, 6:49:05 AM1/20/08
to
On Sun, 20 Jan 2008 03:15:15 -0800 (PST), Tayssir John Gabbour <tayssi...@googlemail.com> wrote:

> 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

unread,
Jan 20, 2008, 7:32:51 AM1/20/08
to

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

unread,
Jan 20, 2008, 7:38:06 AM1/20/08
to

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

unread,
Jan 20, 2008, 7:39:34 AM1/20/08
to
On Sun, 20 Jan 2008 00:09:35 +0000, tim Josling 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
> 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

unread,
Jan 20, 2008, 1:27:40 PM1/20/08
to
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?

When in doubt about what a poster means, ask the poster instead of
trying to outguess him, was what I thought.

/andreas

Ken Tilton

unread,
Jan 20, 2008, 1:43:08 PM1/20/08
to

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

unread,
Jan 20, 2008, 2:52:34 PM1/20/08
to
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!

Robert Uhl

unread,
Jan 20, 2008, 9:20:53 PM1/20/08
to
Jeff <ros...@gmail.com> writes:
>
> 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

unread,
Jan 20, 2008, 10:39:56 PM1/20/08
to

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

unread,
Jan 20, 2008, 11:10:19 PM1/20/08
to
Den Sun, 20 Jan 2008 06:18:07 +0000 skrev Sohail Somani:

> 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

unread,
Jan 21, 2008, 1:08:27 AM1/21/08
to

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

unread,
Jan 21, 2008, 2:34:50 AM1/21/08
to
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).

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

unread,
Jan 21, 2008, 3:07:24 AM1/21/08
to
On Jan 20, 12:15 pm, Tayssir John Gabbour

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

unread,
Jan 21, 2008, 4:36:21 AM1/21/08
to
On Mon, 21 Jan 2008 07:34:50 +0000, Slava Akhmechet wrote:

> 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

unread,
Jan 21, 2008, 5:27:44 AM1/21/08
to
How about him working with weblocks so we could have one great
framework instead of few dozen of mediocre ones.

Slobodan
>
> --
> Sohail Somanihttp://uint32t.blogspot.com

Maciej Katafiasz

unread,
Jan 21, 2008, 7:47:45 AM1/21/08
to

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

unread,
Jan 21, 2008, 9:48:21 AM1/21/08
to

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

unread,
Jan 21, 2008, 12:07:16 PM1/21/08
to
On Mon, 21 Jan 2008 12:47:45 +0000, Maciej Katafiasz wrote:

>> 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

unread,
Jan 21, 2008, 5:56:02 PM1/21/08
to

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

unread,
Jan 21, 2008, 7:07:29 PM1/21/08
to
On 21 ene, 13:47, Maciej Katafiasz <mathr...@gmail.com> 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:
>
> [...]

Try django ;-)

> Cheers,
> Maciej

vanekl

unread,
Jan 21, 2008, 7:45:20 PM1/21/08
to
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

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

unread,
Jan 21, 2008, 8:08:48 PM1/21/08
to
On Jan 21, 8:34 am, Slava Akhmechet <coffee...@gmail.com> wrote:
> 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

unread,
Jan 21, 2008, 8:44:25 PM1/21/08
to
Slava Akhmechet wrote:
> 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

unread,
Jan 21, 2008, 8:47:30 PM1/21/08
to
On Jan 21, 1:47 pm, Maciej Katafiasz <mathr...@gmail.com> 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. 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

unread,
Jan 21, 2008, 8:54:00 PM1/21/08
to
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 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

unread,
Jan 21, 2008, 9:31:52 PM1/21/08
to
Jeff <ros...@gmail.com> writes:

>> > 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

unread,
Jan 21, 2008, 9:58:30 PM1/21/08