One area where a notion of Project comes in handy is with cross-file
refactoring.
E.g. Right now I am in the midst of renaming a #:keyword and resorting to
grep to find dependencies in other files. Is there a smarter existing way
of doing this kind of thing in DrRacket? Or is this a use-case for f
Thanks, that clarifies the point. The manifesto maybe puts it too strictly
indeed.
On Thu, Mar 26, 2015 at 1:58 PM, Matthias Felleisen
wrote:
>
> Thanks for sending this, again. I was writing a response very
> much along these lines when your post came in.
>
> 1. No, we cannot and will not repla
Thanks for sending this, again. I was writing a response very
much along these lines when your post came in.
1. No, we cannot and will not replace all tools. Quite the opposite,
I foresee a future in which we will produce many more tools. [Your
effort will make me think twice before I write a
I didn't understand the manifesto as saying Racket should try to be a
lisp machine or OS (we already have Emacs for that :)) or that all
external tools are bad (despite what I wrote quickly; sorry). Instead
I understood it to mean, let's minimize gratuitous tools that do stuff
that would be more na
Laurent writes:
> Furthermore, files and github are not chosen by Racket, so I don't
> personally mind that much using a few external tools if Racket
> can't do it itself (I'd still rather have Racket do it itself of
> course; I want a Racket machine). What's more, whether `raco` is
I'd go on
That's also what I understand, and I find this philosophy pretty appealing
too, for what it's worth.
However it still worries me as this sounds a like "I'm not wearing shoes
because the problem is not your feet but the pavement; What we need is a
pavement that makes it possible to walk without sho
I think this only prohibits projects as an 'extra linguistic' mechanism.
I think extending #lang info is probably fine?
Maybe even a '#lang project' would be ok? (but I'm not sure what that would
do)
S.
---
3. Racket turns extra-linguistic mechanisms into linguistic constructs.
When programmers
Thank you Greg. I couldn't have said it any better (probably worse).
This is exactly the point -- Matthias
On Mar 25, 2015, at 12:07 PM, Greg Hendershott
wrote:
> My personal/casual take on this:
>
> There are language systems where you to need to run some
> make-a-new-project tool -- even
My personal/casual take on this:
There are language systems where you to need to run some
make-a-new-project tool -- even for a single source file.
In Racket you can create multi-file collections without needing such a
tool. Only at the point where you want to package it share with
others, do you
In the manifesto, I'm a bit surprised by the following:
> this philosophy prohibits the idea of “projects,” as found in other IDEs,
> because this also externalizes resource management, linking, and other
> aspects of program creation.
Couldn't one call package designing a project?
Sure, a packa
10 matches
Mail list logo
