[racket-users] Re: Racket News - Issue 32 is here!

[Liwei Chou]

Saw this cool paper Sham: A DSL for Fast DSLs 
. Can 
this be used to optimize Racket itself? :)

Paulo Matos於 2020年6月2日星期二 UTC+8上午1時46分00秒寫道：
>
> Racket News - Issue 32 is here!
>
> No time to wait, go grab a coffee and enjoy!
> https://racket-news.com/2020/06/racket-news-issue-32.html
>
> -- 
> Paulo Matos
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/c947d01e-b0cd-459e-a4d9-81d4a7119d9c%40googlegroups.com.

[racket-users] About using RSound

[Liwei Chou]

Found RSound Sound Engine for Racket package, but not much tutorial. Does 
any one know more instructions or tutorial for this package?

https://docs.racket-lang.org/rsound/index.html

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/4fad7bb7-b16e-4a05-bb69-2590df9f8275%40googlegroups.com.

Re: [racket-users] Reducing parentheses without language damage.

[Liwei Chou]

Any one consider this style? Minimizing visual interference while 
preserving parentheses. Even Java program can be written like Python.

[image: main-qimg-8d66f35cd3da4c55a380d0d08c11d930.png]

https://www.quora.com/What-is-the-most-frustrating-thing-about-being-a-computer-programmer/answer/Jesse-Jaun

Though it's kind of like making fun with different coding style. There 
might be some inspiration for us.

gneuner2於 2020年5月2日星期六 UTC+8上午8時12分53秒寫道：
>
>
> On 5/1/2020 4:35 PM, Dexter Lagan wrote:
>
>   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'm not really sure what Pike is getting at there:  I haven't used SWIG 
> myself, but if I understand it correctly, Python code would have to be in a 
> module to be called from "other" language code.  If so, I don't see how the 
> indentation of the "other" code could affect the Python.
>
> That aside: 
>
> Even working only in Python, programmers routinely get tripped up by 
> copy/paste errors - so it is evident that indentation sensitivity is not 
> any real solution to scope related logic problems.  It might [for some 
> definition] help newbies identify stupid errors, but I believe that even 
> moderately experienced programmers are more hindered than helped by it.
>
>
>   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?
>
>
> Well, few people use Haskell, so I would discount it as a data point.  
> Even so, one of the tutorials includes this interesting tidbit:
>
> 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
>
>
> The implication is that Haskell is difficult to write without proper 
> editor support.  So too is Python.  Decent syntax and structure aware 
> editors are not really a problem any more, but they can go only so far:  
> they can fail spectacularly when code gets complicated and the language 
> syntax provides no clues to figure out the scoping.
>
> S-exprs do not suffer from this affliction.
>
>
> Also mentioned previously is my concern that indentation sensitivity may 
> make implementing macros as we enjoy them in Racket difficult.  Or maybe 
> impossible.  Although certainly there are indentation languages which have 
> macro facilities, I am not aware of any in which the macros can be written 
> in the same language.  All the ones I know of implement a separate DSL 
> macro language.
>
> I have designed and implemented a few languages: including a Scheme-ish 
> mostly functional language [but lacking macros].   I have not thought 
> through all the nuances of implementing a language that can reflectively 
> manipulate the structure of a program in the midst of compiling it  [or in 
> the case of Lisp - running it].  However, I have to think there are reasons 
> for existing indentation languages not having done so.
>
> YMMV,
> George
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a7b75492-0a76-4d18-b586-2cde1c7acee4%40googlegroups.com.

[racket-users] Re: Racket documentation translations

[Liwei Chou]

Thanks for sharing.

Hi also has a blog.

Racket編程指南 (The Racket Guide)
https://blog.csdn.net/chinazhangyong/category_7386082.html

Racket stuff
https://blog.csdn.net/chinazhangyong/category_7386249.html

Awesome material.

Stephen De Gabrielle於 2020年4月26日星期日 UTC+8下午10時26分20秒寫道：
>
> Hi 
>
> I just discovered 
> https://github.com/OnRoadZy/RacketGuideInChinese
>
> I think this is awesome! 
> Thank you to 张恒源 (OnRoadZy)
>
> Are there any other translations out there?
>
> Kind regards
>
> Stephen
> -- 
> 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f1cdaa9e-77a3-4e17-85d3-8a536a192724%40googlegroups.com.

Re: [racket-users] on reducing barriers in the Racket community

[Liwei Chou]

Similar discussion here.
https://groups.google.com/forum/#!topic/racket-users/WvThwc98kMU

Sorawee Porncharoenwase於 2020年4月26日星期日 UTC+8上午2時03分13秒寫道：
>
> 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 current exists already! The screenshot I attached above is from the 
> actual DrRacket when debugging is enabled.
>  
>
>> (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.
>>
>
> Right, and that's my proposal. Make it a link, put the word "slow" there 
> to draw attention. I think it would be nice if the language configuration 
> control is self-explanatory so that we don't need the help page.
>  
>
>> 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.
>>
>
> I considered this possibility too and reached the same conclusion. Also, 
> I'm not sure if multiple "Run" buttons make sense for every language in 
> Racket.
>  
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/cd970f80-2c11-40ca-b40c-7b346586b2e4%40googlegroups.com.

Re: [racket-users] on reducing barriers in the Racket community

[Liwei Chou]

Thanks Dexter,

Yes, now I know it’s due to the debugging and tracing configuration. After 
turn off debugging and profiling, it becomes.

cpu time: 20 real time: 20 gc time: 0

If disable Preserve stacktrace also, I got.

cpu time: 7 real time: 7 gc time: 0

Which is pretty decent, 16x acceleration.

It's not a problem for me now. However, this behavior may give some new 
users the wrong impression that the language may not be very efficient, 
which may make some people choose not to continue trying it.

>From the perspective of increasing adoption and reducing barriers, it's not 
a good thing.

If Racket team can consider making normal run and debug run using different 
default settings, which conventional development environments usually do, 
that can easily solve this problem.

Dexter Lagan於 2020年4月25日星期六 UTC+8下午5時17分31秒寫道：
>
> Hi Liwei,
>
>   I believe disabling debugging and tracing does accelerate the evaluation 
> quite a bit from inside DrRacket. On my system, it seems to be running my 
> code at the same speed as the main racket binary.
>
> Dex
>

-- 
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+unsubscr...@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.

Re: [racket-users] on reducing barriers in the Racket community

[Liwei Chou]

Dexter Lagan於 2019年7月22日星期一 UTC+8下午4時52分42秒寫道
>
>   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. 
>

I agree with Dexter's opinion about documentation.

I was reading "The Racket Guide" and found it too verbose for a newcomer 
with some programming experience. Then I discovered "Teach Yourself 
Racket", which is easy to read and I'm really enjoy.

https://cs.uwaterloo.ca/~plragde/flaneries/TYR/

I strongly recommend to include "Teach Yourself Racket" in the beginner's 
guide section of Racket 's official website. Or produce some more materials 
like that.

Another aspect is about the tooling.

Stephen helpful forwarded my feedback here.
https://groups.google.com/d/msg/racket-users/PftpYnJt49c/2abSsQOYAgAJ

I just quote here. A little bit about my journey as a newbie.

When I started to learn Racket, due to the slow startup time and huge 
memory consumption of DrRacket, the overall impression given to me was that 
it’s very inefficient.

After done some micro-benchmark, it did show that it did not perform well, 
and It did make me hesitate. *(barrier for beginners)*
But I still want to try it, because I am very interested in its 
expressiveness. And I’m happy to find out it’s actually quite fast.

The micro-benchmark I ran is.

> (time (for ([i (in-range 1000)])
  (void)))
cpu time: 115 real time: 115 gc time: 0

(Now I know it’s due to the debugging stuff...)
Turn out in DrRacket, it’s about 16x slower than in Racket REPL.

However, there isn't a convenient way to separate normal build/run from 
debug build/run, which conventional development environments usually do.

My point is, the impression of this language is not very efficient, which 
is bad, and will scare some people out. Which is a barrier also. It would 
be better if not the case.

-- 
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+unsubscr...@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.

[racket-users] Re: Rhombus project plan

[Liwei Chou]

As a newcomer from industry, I would like to share some of my thoughts.

First, about the syntax.

I suggest you to watch this video. This guy talks about the approaches 
Wolfram Language takes to solve this problem. By stacking up different 
layer of syntax like FullForm, InputForm for different level of 
abstractions or purpose. Which involves M-expression, the concept of 
syntactical equivalence, two-way conversion...etc. I think it works very 
well, because many researchers in the world are using it without any 
problem.

https://youtu.be/z_ScPCh_rSE

REBOL language is also worth checking out. It's a language advocate DSL at 
its core. The core language is pretty concise, like the microkernel of the 
language. Then trying to build all kinds of small dialects on top of that 
to deal with different problem, and can still inter-op with each other. The 
outcome is a very concise language with very small footprint. The 
downloadable size of the runtime with GUI support is less than 1 MB.

https://en.wikipedia.org/wiki/Rebol

Second, about increasing adoption rates or lowering barriers. I think the 
key is usefulness, that is, wow much work can be done with a certain amount 
of time and resources.

I'v post similar idea in another thread about the landing page of Racket 
website.

To be short, the most important thing is to answer following questions.

1. Can this thing solve my problem? (current and future)
2. Why would I choose (to invest my time on) this language instead of 
others?
3. By investing time learning this language, what kind of benefits can I 
get? (short term and long term)

https://groups.google.com/d/msg/racket-users/6ePaiAnqMtk/_iX8IiPJAAAJ

In the field of entrepreneurship, there is a theory called "Jobs to be 
done". (Proposed by Clay Christensen)

https://blog.fullstory.com/clayton-christensen-jobs-to-be-done-framework-product-development/

The idea is people buy stuff for solving their problem. For choosing 
language, people tend to invest time on the language they think they can 
solve more (practical) problem with less amount of effort.

I won't go too long. Just for you to get the idea.

The main reason I chose to spend time learning racket is because of its 
outstanding expressiveness. Which let me believe it's the language that can 
make me "*Do more with less*". So, please continue to let people "*Do more 
with less*."

Matthew Flatt於 2019年10月3日星期四 UTC+8上午3時27分50秒寫道：
>
> [[NOTE: "Rhombus" is the new name for a design project formerly known 
>   as "Racket2", but "Rhombus" IS NOT THE FINAL NAME OF THE NEW LANGUAGE. 
>
>   "Rhombus" is the name of the project that will develop a language, 
>   and "Rhombus" is a temporary stand-in for a language name to be 
>   determined later. Phase 3 of the plan includes the mandatory step of 
>   picking a new language name.]] 
>
> Rhombus is about building on the good parts of Racket and advancing the 
> frontier of Racket-style language-oriented programming. A significant 
> part of the experiment is trying a surface syntax other than 
> parenthesized prefix notation. Another part is simplifying and 
> generalizing elements of `#lang racket`, such as its data structures 
> for streams and binding with integrated and extensible 
> pattern-matching. While some of these goals could be pursued 
> independently, taking them together offers opportunities to make the 
> whole language fit together better. 
>
> Whether Rhombus will become a suitable alternative for current `#lang 
> racket` can be determined only as the experiment progresses. It starts 
> with that ambition, but the project may fail. It may fail for technical 
> reasons, process reasons, or social reasons: 
>
>  - On the technical side, we're trying to do something new. 
>
>  - On the process side, we are trying a more visible and open approach 
>than we have used for past major changes, even to the point of 
>opening up the early exploratory phase. 
>
>  - On the social side, we hope that skeptical Racketeers will make room 
>for the experiment and understand that putting the experiment in the 
>open (and being up-front about development costs) is part of the 
>more open process. 
>
> Matthew Flatt will lead the project with the guidance and consent of 
> Racket project leadership. In early phases of the experiment, Matthew 
> is responsible for delegating and deciding when the next phase starts. 
> Toward the end of the process, Racket leadership is responsible for 
> deciding whether to continue. Community participation is built into the 
> process by keeping the design discussion open and by using an RFC 
> process for the eventual design elements. 
>
>
> What Will Happen to Racket During Rhombus 
> - 
>
> The Racket team will continue to maintain the language and its 
> implementations: 
>
>  - The existing ecosystem will continue to function as always. 
>
>  - Existing `#lang racket` programs will continue to run, 

[racket-users] Suggestions for "The Racket Guide"

[Liwei Chou]

Hello there, I’m reading "The Racket Guide" online and I have a little 
suggestion that if you can make the code easier to copy, it will be much 
easier for beginners to go through.

For example, just like Wolfram Language’s tutorial, if you hover your mouse 
over a code snippet, it will appear a little bubble. If you click that 
bubble, it copies the code to the clipboard.
https://www.wolfram.com/language/fast-introduction-for-programmers/en/interactive-usage/

My two cents. :)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/ec5187fb-cdb5-4903-801b-5125292b83b5%40googlegroups.com.