Prev: Which is the best implementation of LISP family of languagesfor real world programming ?
Next: A small backquote logjam
From: George Neuner on 12 Jun 2010 14:06
On Sat, 12 Jun 2010 18:57:08 +0300, "Antti \"Andy\" Ylikoski"
<antti.ylikoski(a)gmail.com> wrote:

>OT: (very Off Topic.............)
>I would not trust dolphins to take care of my investments.

Why not? Remember the chimpanzee that picked stocks and beat many
professional fund managers?
http://www.marketwatch.com/story/dart-throwing-chimp-still-making-monkey-of-internet-funds?pagenumber=2


The average dolphin's brain is bigger than the average human's (and
far bigger than a chimpanzee's). Dolphin investment strategies might
look fishy to us but dolphins have a unique point of view on important
industries such as transportation, telecommunications, construction,
tourism, energy exploration, food production, etc.

I'd trust a dolphin over a Wall Street fund manager any day.
From: Pascal J. Bourguignon on 12 Jun 2010 15:54
bolega <gnuist006(a)gmail.com> writes:
>
> > [PAIP]
>
> Is there anything in this old norvig book that makes it worth
> pursuing as a text ?

Yes.

--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Pascal J. Bourguignon on 12 Jun 2010 15:57
George Neuner <gneuner2(a)comcast.net> writes:

> On Sat, 12 Jun 2010 18:57:08 +0300, "Antti \"Andy\" Ylikoski"
> <antti.ylikoski(a)gmail.com> wrote:
>
>>OT: (very Off Topic.............)
>>I would not trust dolphins to take care of my investments.
>
> Why not? Remember the chimpanzee that picked stocks and beat many
> professional fund managers?
> http://www.marketwatch.com/story/dart-throwing-chimp-still-making-monkey-of-internet-funds?pagenumber=2
>
>
> The average dolphin's brain is bigger than the average human's (and
> far bigger than a chimpanzee's). Dolphin investment strategies might
> look fishy to us but dolphins have a unique point of view on important
> industries such as transportation, telecommunications, construction,
> tourism, energy exploration, food production, etc.
>
> I'd trust a dolphin over a Wall Street fund manager any day.

Me too. At least, the dolphin wouldn't be a former SEC president, and
would have no use for our painfully spared dollars.

--
__Pascal Bourguignon__ http://www.informatimago.com/
From: Eli Barzilay on 12 Jun 2010 16:23
Štěpán Němec <stepnem(a)gmail.com> writes:

> Eli Barzilay <eli(a)barzilay.org> writes:
>>> If the environment were open, why would some facilities be hidden in
>>> its tools? Among other things, you can't single step Racket outside
>>> of DrRacket. That sounds as a closed environment to me.
>>
>> How is that closed when the code for doing so is all there as part of
>> any *OPEN* source project? I don't even need to defend some black
>> C-level voodoo that does it, since it's all done in scheme code. It's
>> true that most of the current code uses the GUI, but that's only
>> because nobody felt the need yet for doing so outside of the GUI.
>
> [snip]
>
> I find this really hard to believe.

I don't know what "this" refers to. Most of what I said are facts,
the most important one is that Racket *is* an open system. (At least
it would be damn hard to find a definition of "closed" that will make
it a relevant term.)

Or if you're saying that you don't believe that nobody felt the need
for doing so outside of the gui -- sure, some people felt a need for
it, but it was never substantial enough to result in some form of
working code. The pieces are all there, and they're not that hard to
use either -- yet nobody has picked up the ball. (And that's also a
plain fact.) I've even suggested a route to writing an Emacs package
that will make it possible to have multiple evaluators where each
corresponds to a different buffer using the sandbox library (which can
be seen as the core of what DrRacket uses to do the same). I've
brought this up two or three times, and yet nobody picked it up.


> I use the GUI only for the debugger and macro stepper. I would
> _love_ to have that functionality available in a regular REPL (OTOH,
> especially the macro stepper uses a lot of "eye-candyish" features,
> so it is a bit hard to imagine in some kind of text-only interface).

Like I said -- the debugger is based on mztake, a project that made a
scriptable event-based debugger. You can still get the code for that
at http://www.cs.brown.edu/research/plt/software/mztake/, or you can
start with the current debugger -- the important piece of code is
"collects/gui-debugger/annotator.rkt" which instruments code to be
debugged; and "debug-tool.rkt" is where the gui front end lives.
You'll see that most of the hard work is done in the latter, since the
interface is in general more difficult than the core debugging
facility. You can choose some completely text-based interface, or
some Emacs interface: the core annotator is practically all there in
that "annotator.rkt" file.

So -- here's the ball. Will you pick it up now?

As for the macro stepper -- well, that one already has a textual
interface (see section 3 of the macro debugger manual at:
http://docs.racket-lang.org/macro-debugger/). In fact, it is one of a
few tools that my interactive hack uses. That's a bunch of hacks that
make it easier (for me, at least) to do my work -- see it at
http://barzilay.org/hacks.html. It doesn't have any fancy interface
to stepping through macro expansion -- basically just dumps the steps
out, and it could certainly use more improvements. If you're serious
about making this work, I'll be happy to dump my thing on github to
make it more easily tweakable, and I'll be happy to provide the right
pointers.

So we now have a second ball on the ground. Will you pick this one up
too?

If you pick those balls up, you'll be making something that has a good
chance to be popular (and it will obviously demonstrate that Elena's
statement about Racket being a closed system is bogus). If you don't
pick them up, you'll be providing one more reason why my claim that
"nobody felt the need yet for doing so outside of the GUI" is true.

--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
From: Štěpán Němec on 12 Jun 2010 18:52
Eli Barzilay <eli(a)barzilay.org> writes:

[Just to clarify, my "hard to believe" was only related to the "nobody
felt the need" part.]

>> I use the GUI only for the debugger and macro stepper. I would
>> _love_ to have that functionality available in a regular REPL (OTOH,
>> especially the macro stepper uses a lot of "eye-candyish" features,
>> so it is a bit hard to imagine in some kind of text-only interface).
>
> Like I said -- the debugger is based on mztake, a project that made a
> scriptable event-based debugger. You can still get the code for that
> at http://www.cs.brown.edu/research/plt/software/mztake/, or you can
> start with the current debugger -- the important piece of code is
> "collects/gui-debugger/annotator.rkt" which instruments code to be
> debugged; and "debug-tool.rkt" is where the gui front end lives.
> You'll see that most of the hard work is done in the latter, since the
> interface is in general more difficult than the core debugging
> facility. You can choose some completely text-based interface, or
> some Emacs interface: the core annotator is practically all there in
> that "annotator.rkt" file.
>
> So -- here's the ball. Will you pick it up now?

I don't think so.

> As for the macro stepper -- well, that one already has a textual
> interface (see section 3 of the macro debugger manual at:
> http://docs.racket-lang.org/macro-debugger/). In fact, it is one of a
> few tools that my interactive hack uses. That's a bunch of hacks that
> make it easier (for me, at least) to do my work -- see it at
> http://barzilay.org/hacks.html. It doesn't have any fancy interface
> to stepping through macro expansion -- basically just dumps the steps
> out, and it could certainly use more improvements. If you're serious
> about making this work, I'll be happy to dump my thing on github to
> make it more easily tweakable, and I'll be happy to provide the right
> pointers.

Are you speaking about interactive.ss? I discovered that a week or so
ago, but the command list produced by `,help' doesn't suggest any macro
stepper features?

> So we now have a second ball on the ground. Will you pick this one up
> too?

Thank you (and Sam) for the pointers.

I don't think my very limited abilities would suffice for me to get the
projects you suggest done in any reasonable time (or at all). So maybe
the problem is not that "nobody felt the need", but that most of those
who would benefit are rookies like me -- if we take your example, you
say you use Emacs most of the time, so I'm guessing you don't really
miss the debugging functionality (or at least the part not available
outside DrRacket), and that this might be true for most of those for
whom it would be actually rather easy to implement these features (given
some spare time)?


Štěpán
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Which is the best implementation of LISP family of languagesfor real world programming ?
Next: A small backquote logjam