--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/8964B1F7-C0A5-44BA-AFE3-FF87E038F3CE%40mbtype.com.
As an additional data point, I can share my very fast introduction into Racket and the community. You asked for experiences where the community may have made people feel unwelcome, but mine is a positive experience. I share it to perhaps give an angle of what is right, and the parts of the racket community which helped me go from an "outsider" to feeling welcome and secure. My brief experience with this community has been wonderful, and I want to contribute to making that experience the norm, if it is not already. [...]
From my perspective the only barrier of entry to Racket is the documentation: it is very clear, detailed and well-written, but to certain of my students they can also be quite obscure, especially to those who don’t have comp-sci background and those whose first language isn’t English. The best example is the few pages about continuations. For quite a while I could not understand what they were about from the Racket docs, and it took quite a bit of web crawling to find meaningful examples of their use. I also found the pages about macros lacking simple examples, and it’s not until Beautiful Racket that I finally found very basic uses.
> (time (for ([i (in-range 10000000)])
(void)))
cpu time: 115 real time: 115 gc time: 0
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/140e226d-ed25-4aac-ae95-4f5f347bb3ba%40googlegroups.com.
cpu time: 20 real time: 20 gc time: 0
cpu time: 7 real time: 7 gc time: 0
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CABa2-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%40mail.gmail.com.
I like the idea of adding a "with debugging" to the banner when a program is run in DrRacket, but I´m not sure it is possible.
(It would be even better if the user can click it and go to the help page about the configuration of the language). But I'm not sure it is possible.
Another possibility is to have two "Run" buttons, a normal "Run" button and a "Run fast" button. The problem is that too many buttons make the UI confusing for beginners.
On Apr 25, 2020, at 3:25 PM, sleepnova <wanp...@gmail.com> wrote:
That may help to reduce misimpression. And plus, maybe append some message to error message to inform user that they can turn on errortrace if they need more detailed debugging information, when errortrace doesn't enabled.To be clarify, what you mentioned is "Preserve errortrace" option, what about "Debugging" option, is it a must enabled option in a non-debugging run?
<截圖 2020-04-25 下午9.22.20.png>
Sorawee Porncharoenwase <sorawe...@gmail.com> 於 2020年4月25日 週六 下午8:17寫道:
It could go either way, no? I've also heard a lot of people complaining that debugging Racket programs is difficult because the stack trace is not useful, and this is because they use the command-line version which doesn't have errortrace enabled (by default).Perhaps what you really are complaining is that the option to enable/disable errortrace is not easily discoverable. Would it help if at:
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CABa2-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%40mail.gmail.com.
On Thu, Apr 30, 2020 at 09:36:15AM +0200, Dexter Lagan wrote:
> There’s one thing I noticed: if debugging is disabled, then parenthesis highlighting is also disabled (as well as other visual aids, if I remember well?). The editor also feels faster because of this, but navigating parentheses becomes slightly more tedious without it.
And that's exactly the parenthesis problem. For a language as
parenthesis-heavy as Scheme or Lisp, you need a
parenthesis-oriented editor. DrRacket does this very well bu
shading the background (but apparently not all the time). Emacs
does it too, in principle, but isn't reaally great at it.
[...]
> Also is there a programming editor that *won't* do parenthesis matching?
Evidently the Racket editor whan debugging is disabled,
On Apr 30, 2020, at 10:06 PM, Stephen De Gabrielle <spdega...@gmail.com> wrote:
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAGHj7-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%40mail.gmail.com.
I hate being at the mercy of whatever editor I'm stuck using.
I stongly recommend that we get a language with less of a
parenthesis problem so that code is readable without having to haul
it into a specialised editor.
In an old List I used '/' for this, so i got expressions like
(if a b / if c d / let s t /if s foo bar)
There must be some # code we could use for this (I believe one
has already been mentioned on this list sometime in the past year
os so) but this symbol tends to become *so* prevalent that it
should ideally feel like a single character with a dostinctieve
apearance.
:
To clarify what I mean: non S-exp languages usually have a line as a unit of code, so editors need to support "jump to the beginning/end of line" to make editing pleasant.
S-exp languages in contrast has a parenthesized expression as a unit of code, so editors need to support "jump to a matching parenthesis" to make editing pleasant. In your notation, it looks like editors need to also support "jump to closest /" to make editing pleasant.
Also, does it actually make code more readable? I guess I'm not accustomed to it, and might find it easier to read it once I am.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CADcuegsYr6KKeZg5sV1ocgcywnCTbi8rf_gB5_MiQG9%3D_W_cFQ%40mail.gmail.com.
“We have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code.” — Rob Pike, 2012
On May 1, 2020, at 10:20 PM, George Neuner <gneu...@comcast.net> wrote:
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.
Is there value in Rob Pike’s comment on avoiding significant white space in the Go language?
“We have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code.” — Rob Pike, 2012
I personally dislike white space and prefer either mustaches or parenthesis, just so I know my code will still work if line feeds are stripped somehow, or that some piece of code is embedded or quoted in another language, which is what I gather Rob was talking about. However, Haskell and Python people don’t seem to mind, and if it saves us more keystrokes while keeping expressiveness, why not?
With good text editor, programming is fun. Of course, you can get along with simplistic
editor capable of just cut-n-paste, but good editor is capable of doing most of the chores
for you, letting you concentrate on what you are writing. With respect to programming
in Haskell, good text editor should have as much as possible of the following features:
• Syntax highlighting for source files
• Indentation of source files
• Interaction with Haskell interpreter (be it Hugs or GHCi)
• Computer-aided code navigation
• Code completion
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAJ7XQb67vFEX7D0hHOxJXVG6344ngYU1%3DtmmQ0m6%3DVijqODEQw%40mail.gmail.com.