Re: [racket-users] Rhombus project plan
Also, if I remember correctly, the timings given in the said (excellent) tutorial are very conservative or outdated. If you have a multicore machine, it will speed up the process by up to a factor 8. On Thu, Apr 30, 2020, 15:42 Sam Tobin-Hochstadt wrote: > On Thu, Apr 30, 2020 at 9:09 AM Ben Greenman > wrote: > > > > On 4/29/20, Sorawee Porncharoenwase wrote: > > > (Not directly related to Rhombus) Speaking of “how to contribute”, I > find > > > that it is not friendly at all to setup stuff in order to contribute to > > > Racket core and main distribution. According to > > > > https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html, > > > if I want to make a change to, say, https://github.com/racket/math, I > > > should start with: > > > > > > $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org > math > > > $ raco pkg update --clone math > > > > > > The estimated time to run the above two commands is ONE HOUR! The > second > > > command in particular seems to compile every Racket packages (why does > it > > > need to do that?!?) which takes a lot of time. > > > > That second command recompiles only the packages that depend on math. > > Unfortunately there are a lot of them. > > To follow up on that, here are some strategies for reducing that time: > > 1. Start with Minimal Racket, install "math", then follow the steps > above. That will just rebuild `math`, not everything that depends on > it, since they won't be installed. > > 2. (Dangerous) Do the following: >$ raco pkg update --no-setup --clone math # fast >$ raco setup math > > This will only setup "math", and thus be faster, but will potentially > cause other parts of the installation to not work correctly until you > run "raco setup". > > Making the original commands go faster would require one of three > things (in increasing order of difficulty): detecting that many zo > files can be re-used from the previous installation in some fashion, > making Typed Racket faster, or making Racket macro expansion more > incremental. > > Sam > > -- > 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/CAK%3DHD%2BZ5k%2BFk2guk8sxe8gs-kQ9NcKJLkHGeWprrucFzqZ%2BABA%40mail.gmail.com > . > -- 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/CABNTSaHpG5ACme4ZWiAhmrJ6avbJs2k3jXMoPfLB1CJEDBWjqQ%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
On Thu, Apr 30, 2020 at 9:09 AM Ben Greenman wrote: > > On 4/29/20, Sorawee Porncharoenwase wrote: > > (Not directly related to Rhombus) Speaking of “how to contribute”, I find > > that it is not friendly at all to setup stuff in order to contribute to > > Racket core and main distribution. According to > > https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html, > > if I want to make a change to, say, https://github.com/racket/math, I > > should start with: > > > > $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org math > > $ raco pkg update --clone math > > > > The estimated time to run the above two commands is ONE HOUR! The second > > command in particular seems to compile every Racket packages (why does it > > need to do that?!?) which takes a lot of time. > > That second command recompiles only the packages that depend on math. > Unfortunately there are a lot of them. To follow up on that, here are some strategies for reducing that time: 1. Start with Minimal Racket, install "math", then follow the steps above. That will just rebuild `math`, not everything that depends on it, since they won't be installed. 2. (Dangerous) Do the following: $ raco pkg update --no-setup --clone math # fast $ raco setup math This will only setup "math", and thus be faster, but will potentially cause other parts of the installation to not work correctly until you run "raco setup". Making the original commands go faster would require one of three things (in increasing order of difficulty): detecting that many zo files can be re-used from the previous installation in some fashion, making Typed Racket faster, or making Racket macro expansion more incremental. Sam -- 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/CAK%3DHD%2BZ5k%2BFk2guk8sxe8gs-kQ9NcKJLkHGeWprrucFzqZ%2BABA%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
On 4/29/20, Sorawee Porncharoenwase wrote: > (Not directly related to Rhombus) Speaking of “how to contribute”, I find > that it is not friendly at all to setup stuff in order to contribute to > Racket core and main distribution. According to > https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html, > if I want to make a change to, say, https://github.com/racket/math, I > should start with: > > $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org math > $ raco pkg update --clone math > > The estimated time to run the above two commands is ONE HOUR! The second > command in particular seems to compile every Racket packages (why does it > need to do that?!?) which takes a lot of time. That second command recompiles only the packages that depend on math. Unfortunately there are a lot of them. -- 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/CAFUu9R6DkRjxd_YNrLGLa%2BCc2q8zUk5MfuTDzcP%2BpAZ_CM43eQ%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
I just read myself, I meant runtime errors, not compile-time errors. One big complain I hear from people used to compiled languages - when they first use dynamic and interpreter languages - is the idea of having errors occur at runtime, which ‘should’ have been picked up by the interpreter before runtime. I understand there’s a major trade off here, and there are things that are possible to do with interpreters that aren’t with compilers, and vice versa. What I was referring to, is a way to analyse further the source, to identify potential errors before they happen at runtime. I thought that’s what contracts and typing in general was supposed to catch, and I have yet to experiment with contracts in my code, in production. However I have encountered this problem many times : (get-text-from-user ...) returns a string of #f. If I use the output of this function, I always run the risk of having the user click cancel, and get a contract error returned by the next function. So I always have to have something like (unless result (exit 0)) ...or something more involved to deal with the possibility of getting #f like: (if result (do-something-with result) (display-error-and-do-something-else)) Somehow I’ve always been surprised by the behaviour, and I wish there was a solution to this, apart from literally filling my code with checks (which is what I do now). If only there was a way to trace the possible output of functions against the permitted input of the next function in the chain (through continuation marks?), then maybe we could solve a piece of that runtime errors puzzle. Dex > On Apr 29, 2020, at 11:24 PM, Dexter Lagan wrote: > > You’ve always been very inspiring to me. I’ll do my best to better the > docs if there’s a guide on how to do so. Bear with me, I have no background > in computer science and I don’t even know what a pull request is. I only > recently started using version control. I’ve always worked alone, until > recently - now I have to lead a team, and I can not longer escape the hard > stuff. > > I have a million questions, about Racket’s direction and symbolic > computation in general. I’ve been reading day and night on everything I > should have learned in comp-sci. > > My dream is to find a solution to compile-time errors (through some kind of > analysis, maybe contracts already solve this?), and find a way to teach kids > how to program. Thanks for telling me about bootstrapworld. I’ll check it out. > > Dex > >>> On Apr 29, 2020, at 2:21 PM, Matthew Flatt wrote: >>> >>> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: >>> To the point: what would make Racket2 the ultimate tool (for me): >>> Performance. Faster startup times, shorter execution times in general. >>> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps >>> binaries, bypassing the JIT altogether, would be a game-changer. As far as >>> high levels languages with functional concepts and metaprogramming >>> facilities >>> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not >>> a >>> Lisp, and it’s not Racket. >>> Production-quality, modern and fast GUI facilities. I’ll take properly >>> documented, complete Qt bindings. Racket/GUI is great for internal tools, >>> but >>> it quickly becomes slow, tedious and limited for more complex client-facing >>> UIs. >>> One complete, commercial-grade Web framework, inspired from Symphony or >>> Laravel. Security and ease of use first, continuations later. >>> Better documentation: Racket docs are aesthetically very pleasing, complete >>> and detailed. However some parts are still very obscure and lacking simple >>> examples (if only the part about Continuations included just one basic >>> example, such as a ‘return’ implementation, on the very first page. If only >>> the Macros documentation started with define-simple-macro and a few very >>> basic, practical examples. Instead we’re greeted with pattern-based macros, >>> which although very powerful, are very hard to comprehend for newcomers). >> >> Which of these things will you be working on? >> >> >>> I am well aware that what I’m wishing for isn’t necessarily compatible with >>> Racket’s intended public’s needs (comp-sci teachers and students? That’s >>> the >>> impression I’m getting). But Racket is the most advanced general purpose >>> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited >>> to >>> academic use? >> >> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be >> >> -- >> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com. --
Re: [racket-users] Rhombus project plan
(Not directly related to Rhombus) Speaking of “how to contribute”, I find that it is not friendly at all to setup stuff in order to contribute to Racket core and main distribution. According to https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html, if I want to make a change to, say, https://github.com/racket/math, I should start with: $ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org math $ raco pkg update --clone math The estimated time to run the above two commands is ONE HOUR! The second command in particular seems to compile every Racket packages (why does it need to do that?!?) which takes a lot of time. I really feel turned off by the thought of having to wait for one hour (with my laptop becoming very hot from CPU usage at 100%, and I can’t really do other work that has heavy computation during this period). So I usually skip this step, but that also means I can’t test my PR locally. Instead, I need to rely on CI to catch any mistake that I made. The obvious drawback is that it generates a lot of noises to people watching the repo and some repos don’t even have CI setup… (In some cases, I can test locally by isolating the changes to a new Racket program, but that’s not always possible.) Is it possible to improve this somehow? On Wed, Apr 29, 2020 at 2:48 PM Matthew Flatt wrote: > At Wed, 29 Apr 2020 12:46:50 -0400, David Storrs wrote: > > In related news, a question for the list: Once I have a handle on this, > I > > would like to write a "How to Contribute to Racket Documentation" guide. > > Where would be the right place for this? Should it be an expansion to an > > existing document (if so, which), an entirely new one, or...? > > I suggest making it part of "Building, Distributing, and Contributing > to Racket": > > https://docs.racket-lang.org/racket-build-guide/index.html > > which is also rendered as > > https://github.com/racket/racket/blob/master/build.md > > > The source is > > https://github.com/racket/racket/tree/master/pkgs/racket-build-guide > > -- > 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/5ea9f62b.1c69fb81.d0413.1033SMTPIN_ADDED_MISSING%40gmr-mx.google.com > . > -- 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/CADcuegsVu9Je%3D_7Md3aD1nC5DEyKV__7_i3oHadZk5168nX87A%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
At Wed, 29 Apr 2020 12:46:50 -0400, David Storrs wrote: > In related news, a question for the list: Once I have a handle on this, I > would like to write a "How to Contribute to Racket Documentation" guide. > Where would be the right place for this? Should it be an expansion to an > existing document (if so, which), an entirely new one, or...? I suggest making it part of "Building, Distributing, and Contributing to Racket": https://docs.racket-lang.org/racket-build-guide/index.html which is also rendered as https://github.com/racket/racket/blob/master/build.md The source is https://github.com/racket/racket/tree/master/pkgs/racket-build-guide -- 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/5ea9f62b.1c69fb81.d0413.1033SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
Re: [racket-users] Rhombus project plan
You’ve always been very inspiring to me. I’ll do my best to better the docs if there’s a guide on how to do so. Bear with me, I have no background in computer science and I don’t even know what a pull request is. I only recently started using version control. I’ve always worked alone, until recently - now I have to lead a team, and I can not longer escape the hard stuff. I have a million questions, about Racket’s direction and symbolic computation in general. I’ve been reading day and night on everything I should have learned in comp-sci. My dream is to find a solution to compile-time errors (through some kind of analysis, maybe contracts already solve this?), and find a way to teach kids how to program. Thanks for telling me about bootstrapworld. I’ll check it out. Dex > On Apr 29, 2020, at 2:21 PM, Matthew Flatt wrote: > > At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: >> To the point: what would make Racket2 the ultimate tool (for me): >> Performance. Faster startup times, shorter execution times in general. >> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps >> binaries, bypassing the JIT altogether, would be a game-changer. As far as >> high levels languages with functional concepts and metaprogramming >> facilities >> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not >> a >> Lisp, and it’s not Racket. >> Production-quality, modern and fast GUI facilities. I’ll take properly >> documented, complete Qt bindings. Racket/GUI is great for internal tools, >> but >> it quickly becomes slow, tedious and limited for more complex client-facing >> UIs. >> One complete, commercial-grade Web framework, inspired from Symphony or >> Laravel. Security and ease of use first, continuations later. >> Better documentation: Racket docs are aesthetically very pleasing, complete >> and detailed. However some parts are still very obscure and lacking simple >> examples (if only the part about Continuations included just one basic >> example, such as a ‘return’ implementation, on the very first page. If only >> the Macros documentation started with define-simple-macro and a few very >> basic, practical examples. Instead we’re greeted with pattern-based macros, >> which although very powerful, are very hard to comprehend for newcomers). > > Which of these things will you be working on? > > >> I am well aware that what I’m wishing for isn’t necessarily compatible with >> Racket’s intended public’s needs (comp-sci teachers and students? That’s the >> impression I’m getting). But Racket is the most advanced general purpose >> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to >> academic use? > > https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be > > -- > 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com. -- 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/99FC74E9-A31E-4D9A-AA82-2B393ED35A87%40gmail.com.
Re: [racket-users] Rhombus project plan
See the comment I just left in this PR: https://github.com/racket/scribble/pull/223 Sam On Wed, Apr 29, 2020 at 5:10 PM Dexter Lagan wrote: > > I’d like to help too, so if I understand this pull request correctly, > there’s demand for a guide on how to update the docs? I was about to ask > precisely that, how to contribute to the docs. If there’s JavaScript to make, > I can take a look. I don’t use Slack, is there an alternative? > > Cheers, > > Dex > > > On Apr 29, 2020, at 4:27 PM, Sam Tobin-Hochstadt > > wrote: > > > > Hi David, > > > > If you ping me on Slack, I'll be happy to walk you through how to make > > changes to the docs. And maybe you can lend a hand to finally > > completing https://github.com/racket/racket/pull/874 which I think is > > mostly a matter of JavaScript programming now. > > > > Sam > > > >> On Wed, Apr 29, 2020 at 9:35 AM David Storrs > >> wrote: > >> > >> > >> > >>> On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt wrote: > >>> > >>> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: > To the point: what would make Racket2 the ultimate tool (for me): > Performance. Faster startup times, shorter execution times in general. > Optionally, a ‘lite’ version of Racket that compiles directly to no-deps > binaries, bypassing the JIT altogether, would be a game-changer. As far > as > high levels languages with functional concepts and metaprogramming > facilities > that compiles to tiny, fast bins, Nim comes dangerously close, but it’s > not a > Lisp, and it’s not Racket. > Production-quality, modern and fast GUI facilities. I’ll take properly > documented, complete Qt bindings. Racket/GUI is great for internal > tools, but > it quickly becomes slow, tedious and limited for more complex > client-facing > UIs. > One complete, commercial-grade Web framework, inspired from Symphony or > Laravel. Security and ease of use first, continuations later. > Better documentation: Racket docs are aesthetically very pleasing, > complete > and detailed. However some parts are still very obscure and lacking > simple > examples (if only the part about Continuations included just one basic > example, such as a ‘return’ implementation, on the very first page. If > only > the Macros documentation started with define-simple-macro and a few very > basic, practical examples. Instead we’re greeted with pattern-based > macros, > which although very powerful, are very hard to comprehend for newcomers). > >>> > >>> Which of these things will you be working on? > >> > >> > >> I'll step up. > >> > >> Matt, I need some help with Scribble and how to contribute to the Racket > >> docs. I'd be willing to pay for a couple hours of your time (or whomever > >> else's has the skill/knowledge) to walk me through that. After that I'll > >> be happy to pitch in by offering documentation patches. This will be a > >> big help for me, since I'm finding myself having trouble writing docs for > >> my own code. > >> > >>> > >>> > >>> > I am well aware that what I’m wishing for isn’t necessarily compatible > with > Racket’s intended public’s needs (comp-sci teachers and students? That’s > the > impression I’m getting). But Racket is the most advanced general purpose > programming tool I’ve ever seen. Wouldn’t it be a shame if it was > limited to > academic use? > >>> > >>> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be > >>> > >>> -- > >>> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com. > >> > >> -- > >> 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/CAE8gKoe%3D5XYkfveAKUy2b6iq7pfNJsZVr%3Djhh7G-8rszHrwfbQ%40mail.gmail.com. -- 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/CAK%3DHD%2Bb9MYd6Os09dH15TmNg3ij9_vPe%3D4C2BYdL1DMiGXUuxQ%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
I’d like to help too, so if I understand this pull request correctly, there’s demand for a guide on how to update the docs? I was about to ask precisely that, how to contribute to the docs. If there’s JavaScript to make, I can take a look. I don’t use Slack, is there an alternative? Cheers, Dex > On Apr 29, 2020, at 4:27 PM, Sam Tobin-Hochstadt wrote: > > Hi David, > > If you ping me on Slack, I'll be happy to walk you through how to make > changes to the docs. And maybe you can lend a hand to finally > completing https://github.com/racket/racket/pull/874 which I think is > mostly a matter of JavaScript programming now. > > Sam > >> On Wed, Apr 29, 2020 at 9:35 AM David Storrs wrote: >> >> >> >>> On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt wrote: >>> >>> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: To the point: what would make Racket2 the ultimate tool (for me): Performance. Faster startup times, shorter execution times in general. Optionally, a ‘lite’ version of Racket that compiles directly to no-deps binaries, bypassing the JIT altogether, would be a game-changer. As far as high levels languages with functional concepts and metaprogramming facilities that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not a Lisp, and it’s not Racket. Production-quality, modern and fast GUI facilities. I’ll take properly documented, complete Qt bindings. Racket/GUI is great for internal tools, but it quickly becomes slow, tedious and limited for more complex client-facing UIs. One complete, commercial-grade Web framework, inspired from Symphony or Laravel. Security and ease of use first, continuations later. Better documentation: Racket docs are aesthetically very pleasing, complete and detailed. However some parts are still very obscure and lacking simple examples (if only the part about Continuations included just one basic example, such as a ‘return’ implementation, on the very first page. If only the Macros documentation started with define-simple-macro and a few very basic, practical examples. Instead we’re greeted with pattern-based macros, which although very powerful, are very hard to comprehend for newcomers). >>> >>> Which of these things will you be working on? >> >> >> I'll step up. >> >> Matt, I need some help with Scribble and how to contribute to the Racket >> docs. I'd be willing to pay for a couple hours of your time (or whomever >> else's has the skill/knowledge) to walk me through that. After that I'll be >> happy to pitch in by offering documentation patches. This will be a big >> help for me, since I'm finding myself having trouble writing docs for my own >> code. >> >>> >>> >>> I am well aware that what I’m wishing for isn’t necessarily compatible with Racket’s intended public’s needs (comp-sci teachers and students? That’s the impression I’m getting). But Racket is the most advanced general purpose programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to academic use? >>> >>> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be >>> >>> -- >>> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com. >> >> -- >> 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/CAE8gKoe%3D5XYkfveAKUy2b6iq7pfNJsZVr%3Djhh7G-8rszHrwfbQ%40mail.gmail.com. -- 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/741E3460-796E-4DCC-B7D6-7B54CC7C031F%40gmail.com.
Re: [racket-users] Rhombus project plan
Thanks so much for your reply, it's very nice to see another perspective. I added specific comments below : They say that Racket is slow. I would like to know who are "they". > Same here, never had a problem, but I do understand there may be requirements for real-time apps and system programming. Everything I said about performance really should be put into the context of wider acceptance. I don't look at benchmarks, but all of my colleagues do, and that deeply saddens me. Being a better tool isn't necessarily just being a faster tool, but performance attracts people and businesses. If there was two things I'd love to look at, performance-wise - and they aren't related to Racket itself - it would be the 2-3s lock-up I get after opening DrRacket. I can type a line of code, and everything locks up for a few seconds before I can type again. It's nothing big, but it's so annoying that I'm considering downloading the source tree and hack at it. The other problem I'm encountering is the relatively slow scrolling / navigation, again in DrRacket. I usually disable all the plugins, and sometimes even debugging to get smoother performance. But Racket itself isn't slow at all. Considering the power it provides, it's very fast. > My experience is quite contrary to that. In the last three years we were > forced to develop a few GUI tools used by our customers and there are no > complains only against the tools using racket/gui. Yes, it is far from > perfect - but it is the only thing that really behaves consistently > across all three platforms we need to support (Linux, Mac, and ... > Windows). Python+Qt and go+Qt are absolutely insupportable without a > long list of per-platform/per-widget hacks. It might be that we are just > hitting corner cases (actually that's pretty probably), yet with Racket > there were no such hurdles. > True, Racket's gui seems to cross over much better than most frameworks. I use MrEd to make more complex GUIs, and so far the main limitation that prevents me from using it for production (beyond tiny UIs for internal tools) is the relatively limited listbox (I haven't figured out how to edit cells or color text. But that's probably because I haven't dug the docs enough, and I stopped looking when I read other people's similar complains (for ex https://news.ycombinator.com/item?id=18048347) > > > * One complete, commercial-grade Web framework, inspired from Symphony > > or Laravel. Security and ease of use first, continuations later. > > And this is the part that made me actually hit the "Reply List" button. > The good thing about mentioned PHP frameworks is only that anyone can > start producing something with them without any prior experience. So > right now we are encountering vulnerable and unmaintainable code > anywhere we bump into some 3rd party "web application" we are hired to > audit. With Racket - the entry barrier is really high, I agree. I > actually spent many days getting through it - but once you pass the > barrier, it really helps you write applications where you can focus on > the actual functionality and let the libraries do the rest for you. And > securing such application is almost trivial task. Yes, I have hit some > corner cases here as well, but if you follow for example Bogdan's > work[2][3], you'll see that there are solutions readily available. It is > just necessary to read the docs and understand how the whole thing works. > I couldn't get myself to go through the Web app tutorials. I ended up writing a framework in NewLisp mainly made out of macros spitting out Boostrap chunks. https://github.com/dexterlagan/newstrap I ran out of time when I hit multi-page navigation. That's when I understood why everybody uses WP or Symphony. Time is money, and most people who make a living out of Web apps/sites just don't have the time to learn a new language. I asked some of the Web developers in my team to go through the Racket Web tutorials, and all of them loved the power, but went straight back to WordPress, where they feel at home surrounded by thousands of plugins they can simply install and invoice to our clients. All of this really annoys me, and I stay away from the Web side of things, just because I can't stand the idea of making something, only to have to write it again in two years using a different framework, in a different language. I think that until there's a real commercial interest in making a competitive framework in Racket, people will not use the language for the commercial Web. Maybe it's better this way? > I am not sure whether it is the best thing to start with > define-simple-macro (if anything, I'd start with define-syntax-rule), > but yes, more examples are always useful. Just write them and send a > pull request to appropriate repository - I was pleasantly surprised when > I first did this. All the Racketeers are super helpful when it comes to > incorporating any improvements. (Thanks Ben!) > I didn't know it was that
Re: [racket-users] Rhombus project plan
To be clear, I have never had a problem with Racket's performance, I'm just thinking about ways to push for a wider adoption. Personally, anything faster than Python is more than enough, especially with a good FFI. I'm guessing a lot of people look at Rust and Go just because it's supposed to be faster (than Java) and safer (than C). I strongly believe performance depends on who's in front of the keyboard, not which compiler one uses. Dex On Wed, Apr 29, 2020 at 4:26 PM Dominik Pantůček < dominik.pantu...@trustica.cz> wrote: > Hi, > > I can't leave this without reaction... > > > > > To the point: what would make Racket2 the ultimate tool (for me): > > > > * Performance. Faster startup times, shorter execution times in > > general. Optionally, a ‘lite’ version of Racket that compiles > > directly to no-deps binaries, bypassing the JIT altogether, would be > > a game-changer. As far as high levels languages with functional > > concepts and metaprogramming facilities that compiles to tiny, fast > > bins, Nim comes dangerously close, but it’s not a Lisp, and it’s not > > Racket. > > They say that Racket is slow. I would like to know who are "they". > > Racket can be surprising. For example - our GUI application on RPi has a > start-up time of 24s... But when we compile it using `raco exe`, it goes > down under 2s including some hardware setup the program does. Usually > the slow startup times are caused by not using compiled byte-code. > > As I have mentioned a few times on this list, I am working on a side > project right now which pushes Racket to its limits and let's say that > the results might look impossible to many people. Full 3D rendering > pipeline in pure Racket with no external libraries (no OpenGL, no SDL, > just pure Racket) which can run at 60fps FullHD kind of beats the > argument "Racket is slow". Racket can be REALLY fast. But you need to > know how to achieve that (think contract boundaries, unsafe ops guarded > by other mechanisms, ultimate parallelism support - yes, once you grasp > futures to their full extent, you will see what performance gains you > get virtually for free... see my sorting package[1]) > > > * Production-quality, modern and fast GUI facilities. I’ll take > > properly documented, complete Qt bindings. Racket/GUI is great for > > internal tools, but it quickly becomes slow, tedious and limited for > > more complex client-facing UIs. > > My experience is quite contrary to that. In the last three years we were > forced to develop a few GUI tools used by our customers and there are no > complains only against the tools using racket/gui. Yes, it is far from > perfect - but it is the only thing that really behaves consistently > across all three platforms we need to support (Linux, Mac, and ... > Windows). Python+Qt and go+Qt are absolutely insupportable without a > long list of per-platform/per-widget hacks. It might be that we are just > hitting corner cases (actually that's pretty probably), yet with Racket > there were no such hurdles. > > > * One complete, commercial-grade Web framework, inspired from Symphony > > or Laravel. Security and ease of use first, continuations later. > > And this is the part that made me actually hit the "Reply List" button. > The good thing about mentioned PHP frameworks is only that anyone can > start producing something with them without any prior experience. So > right now we are encountering vulnerable and unmaintainable code > anywhere we bump into some 3rd party "web application" we are hired to > audit. With Racket - the entry barrier is really high, I agree. I > actually spent many days getting through it - but once you pass the > barrier, it really helps you write applications where you can focus on > the actual functionality and let the libraries do the rest for you. And > securing such application is almost trivial task. Yes, I have hit some > corner cases here as well, but if you follow for example Bogdan's > work[2][3], you'll see that there are solutions readily available. It is > just necessary to read the docs and understand how the whole thing works. > > > * Better documentation: Racket docs are aesthetically very pleasing, > > complete and detailed. However some parts are still very obscure and > > lacking simple examples (if only the part about Continuations > > included just one basic example, such as a ‘return’ implementation, > > on the very first page. If only the Macros documentation started > > with define-simple-macro and a few very basic, practical examples. > > Instead we’re greeted with pattern-based macros, which although very > > powerful, are very hard to comprehend for newcomers). > > I am not sure whether it is the best thing to start with > define-simple-macro (if anything, I'd start with define-syntax-rule), > but yes, more examples are always useful. Just write them and send a > pull request to appropriate repository - I was
Re: [racket-users] Rhombus project plan
> > > They say that Racket is slow. I would like to know who are "they". > > Racket can be surprising. For example - our GUI application on RPi has a > start-up time of 24s... But when we compile it using `raco exe`, it goes > down under 2s including some hardware setup the program does. Usually > the slow startup times are caused by not using compiled byte-code. > > As I have mentioned a few times on this list, I am working on a side > project right now which pushes Racket to its limits and let's say that > the results might look impossible to many people. Full 3D rendering > pipeline in pure Racket with no external libraries (no OpenGL, no SDL, > just pure Racket) which can run at 60fps FullHD kind of beats the > argument "Racket is slow". > I would be very interested in understanding how you've been able to achieve this and look at the code as well if possible. I'm working right now on a machine learning toolkit that could use performance boosts. A. -- 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/efd81309-99d5-4d76-8bfb-368b0f7f25f6%40googlegroups.com.
Re: [racket-users] Rhombus project plan
On Wed, Apr 29, 2020 at 11:15 AM Jeffrey Edgington wrote: > > Greetings, > > I would be interested as well. > > Thanks, > > Jeff > > Sam and I started to do this on Slack and will connect again later to do more. I'm taking thorough notes and will pass them along once I've got something worked out. In related news, a question for the list: Once I have a handle on this, I would like to write a "How to Contribute to Racket Documentation" guide. Where would be the right place for this? Should it be an expansion to an existing document (if so, which), an entirely new one, or...? On Apr 29, 2020, at 8:27 AM, Sam Tobin-Hochstadt > wrote: > > Hi David, > > If you ping me on Slack, I'll be happy to walk you through how to make > changes to the docs. And maybe you can lend a hand to finally > completing > https://urldefense.com/v3/__https://github.com/racket/racket/pull/874__;!!NCZxaNi9jForCP_SxBKJCA!E1HW0DYeDaBURU0NVZ0qTBoXcScUGqgl1F962-iW9Qn3LDAl5HBdsyRd6LAwe2w$ > which I think is > mostly a matter of JavaScript programming now. > > Sam > > On Wed, Apr 29, 2020 at 9:35 AM David Storrs > wrote: > > > > > On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt wrote: > > > At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: > > To the point: what would make Racket2 the ultimate tool (for me): > Performance. Faster startup times, shorter execution times in general. > Optionally, a ‘lite’ version of Racket that compiles directly to no-deps > binaries, bypassing the JIT altogether, would be a game-changer. As far as > high levels languages with functional concepts and metaprogramming > facilities > that compiles to tiny, fast bins, Nim comes dangerously close, but it’s > not a > Lisp, and it’s not Racket. > Production-quality, modern and fast GUI facilities. I’ll take properly > documented, complete Qt bindings. Racket/GUI is great for internal tools, > but > it quickly becomes slow, tedious and limited for more complex client-facing > UIs. > One complete, commercial-grade Web framework, inspired from Symphony or > Laravel. Security and ease of use first, continuations later. > Better documentation: Racket docs are aesthetically very pleasing, complete > and detailed. However some parts are still very obscure and lacking simple > examples (if only the part about Continuations included just one basic > example, such as a ‘return’ implementation, on the very first page. If only > the Macros documentation started with define-simple-macro and a few very > basic, practical examples. Instead we’re greeted with pattern-based macros, > which although very powerful, are very hard to comprehend for newcomers). > > > Which of these things will you be working on? > > > > I'll step up. > > Matt, I need some help with Scribble and how to contribute to the Racket > docs. I'd be willing to pay for a couple hours of your time (or whomever > else's has the skill/knowledge) to walk me through that. After that I'll > be happy to pitch in by offering documentation patches. This will be a big > help for me, since I'm finding myself having trouble writing docs for my > own code. > > > > > I am well aware that what I’m wishing for isn’t necessarily compatible > with > Racket’s intended public’s needs (comp-sci teachers and students? That’s > the > impression I’m getting). But Racket is the most advanced general purpose > programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited > to > academic use? > > > > https://urldefense.com/v3/__https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be__;!!NCZxaNi9jForCP_SxBKJCA!E1HW0DYeDaBURU0NVZ0qTBoXcScUGqgl1F962-iW9Qn3LDAl5HBdsyRdNRfm5wI$ > > > -- > 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://urldefense.com/v3/__https://groups.google.com/d/msgid/racket-users/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING*40gmr-mx.google.com__;JQ!!NCZxaNi9jForCP_SxBKJCA!E1HW0DYeDaBURU0NVZ0qTBoXcScUGqgl1F962-iW9Qn3LDAl5HBdsyRdaDXQ6Z4$ > . > > > -- > 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://urldefense.com/v3/__https://groups.google.com/d/msgid/racket-users/CAE8gKoe*3D5XYkfveAKUy2b6iq7pfNJsZVr*3Djhh7G-8rszHrwfbQ*40mail.gmail.com__;JSUl!!NCZxaNi9jForCP_SxBKJCA!E1HW0DYeDaBURU0NVZ0qTBoXcScUGqgl1F962-iW9Qn3LDAl5HBdsyRdUJLTSrA$ > . > > > -- > 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 >
Re: [racket-users] Rhombus project plan
Apologies if this is a tired question, and please link me to any answer I missed. If Racket is a component of the overall system, does that imply that it can "reach out" from it's new home in the ecosystem and use all of the new features available beyond Phase 4? ~slg ‐‐‐ Original Message ‐‐‐ On Wednesday, October 2, 2019 3:27 PM, Matthew Flatt wrote: > [[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, just as in > the 6.x and 7.x series of releases. > > - The team will release updated versions, occasionally making modest > incompatibilities with explicit transition paths as needed --- all > as usual. > > This does not mean that the language and its implementation will evolve > at the same speed as it has in the past, but it means that we will > maintain our standard commitment to reliability and quality. > > Phase 1: Brainstorming (months) > > > GOAL AND OUTPUT: A design sketch and collection of prototype > implementations that reflect key ideas and design constraints. > > PROCESS: This is the current phase --- a discussion of ideas and > potential directions at > > https://github.com/racket/rhombus-brainstorming > [formerly "racket2-rfcs"] > > There will be some implementation in this phase to try things out, but > at first only for exploration purposes. > > Initially, we want to address > > - generality in the data structures and libraries, > - consistency in the binding names and terminology, and > - a surface syntax other than parenthesized-prefix notation. > > We also presuppose a potential transition from `#lang racket`, which > will constrain the space of plausible languages. Depending on how this > phase unfolds, we are willing to consider the addition of goals, their > removal, or their reformulation. > > This process will take a while, because the space is very large, > because different participants in the discussion will start with one > set of opinions and end with different ones, and because all of this > brainstorming and exploration will be publicly visible. > > Some draft proposals using the RFC template will be useful at this > phase, similar to prototype implementations, but the process will be > informal (so, not really an RFC process). The existing "Racket2 wish > list" is also part of this phase, but some effort will be needed to > select, consolidate, and elaborate wish-list items. > > CONCLUSION: The project leader will decide on the point where there's > enough
Re: [racket-users] Rhombus project plan
Cool, thanks! Ping sent. On Wed, Apr 29, 2020 at 10:27 AM Sam Tobin-Hochstadt wrote: > Hi David, > > If you ping me on Slack, I'll be happy to walk you through how to make > changes to the docs. And maybe you can lend a hand to finally > completing https://github.com/racket/racket/pull/874 which I think is > mostly a matter of JavaScript programming now. > > Sam > > On Wed, Apr 29, 2020 at 9:35 AM David Storrs > wrote: > > > > > > > > On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt > wrote: > >> > >> At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: > >> > To the point: what would make Racket2 the ultimate tool (for me): > >> > Performance. Faster startup times, shorter execution times in general. > >> > Optionally, a ‘lite’ version of Racket that compiles directly to > no-deps > >> > binaries, bypassing the JIT altogether, would be a game-changer. As > far as > >> > high levels languages with functional concepts and metaprogramming > facilities > >> > that compiles to tiny, fast bins, Nim comes dangerously close, but > it’s not a > >> > Lisp, and it’s not Racket. > >> > Production-quality, modern and fast GUI facilities. I’ll take properly > >> > documented, complete Qt bindings. Racket/GUI is great for internal > tools, but > >> > it quickly becomes slow, tedious and limited for more complex > client-facing > >> > UIs. > >> > One complete, commercial-grade Web framework, inspired from Symphony > or > >> > Laravel. Security and ease of use first, continuations later. > >> > Better documentation: Racket docs are aesthetically very pleasing, > complete > >> > and detailed. However some parts are still very obscure and lacking > simple > >> > examples (if only the part about Continuations included just one basic > >> > example, such as a ‘return’ implementation, on the very first page. > If only > >> > the Macros documentation started with define-simple-macro and a few > very > >> > basic, practical examples. Instead we’re greeted with pattern-based > macros, > >> > which although very powerful, are very hard to comprehend for > newcomers). > >> > >> Which of these things will you be working on? > > > > > > I'll step up. > > > > Matt, I need some help with Scribble and how to contribute to the Racket > docs. I'd be willing to pay for a couple hours of your time (or whomever > else's has the skill/knowledge) to walk me through that. After that I'll > be happy to pitch in by offering documentation patches. This will be a big > help for me, since I'm finding myself having trouble writing docs for my > own code. > > > >> > >> > >> > >> > I am well aware that what I’m wishing for isn’t necessarily > compatible with > >> > Racket’s intended public’s needs (comp-sci teachers and students? > That’s the > >> > impression I’m getting). But Racket is the most advanced general > purpose > >> > programming tool I’ve ever seen. Wouldn’t it be a shame if it was > limited to > >> > academic use? > >> > >> https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be > >> > >> -- > >> 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com > . > > > > -- > > 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/CAE8gKoe%3D5XYkfveAKUy2b6iq7pfNJsZVr%3Djhh7G-8rszHrwfbQ%40mail.gmail.com > . > -- 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/CAE8gKoe6LLOZk6Up_SCzXTaZH7fwEVDs%3DagbZ%2BqbY9pWVxLykw%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
Hi, I can't leave this without reaction... > > To the point: what would make Racket2 the ultimate tool (for me): > > * Performance. Faster startup times, shorter execution times in > general. Optionally, a ‘lite’ version of Racket that compiles > directly to no-deps binaries, bypassing the JIT altogether, would be > a game-changer. As far as high levels languages with functional > concepts and metaprogramming facilities that compiles to tiny, fast > bins, Nim comes dangerously close, but it’s not a Lisp, and it’s not > Racket. They say that Racket is slow. I would like to know who are "they". Racket can be surprising. For example - our GUI application on RPi has a start-up time of 24s... But when we compile it using `raco exe`, it goes down under 2s including some hardware setup the program does. Usually the slow startup times are caused by not using compiled byte-code. As I have mentioned a few times on this list, I am working on a side project right now which pushes Racket to its limits and let's say that the results might look impossible to many people. Full 3D rendering pipeline in pure Racket with no external libraries (no OpenGL, no SDL, just pure Racket) which can run at 60fps FullHD kind of beats the argument "Racket is slow". Racket can be REALLY fast. But you need to know how to achieve that (think contract boundaries, unsafe ops guarded by other mechanisms, ultimate parallelism support - yes, once you grasp futures to their full extent, you will see what performance gains you get virtually for free... see my sorting package[1]) > * Production-quality, modern and fast GUI facilities. I’ll take > properly documented, complete Qt bindings. Racket/GUI is great for > internal tools, but it quickly becomes slow, tedious and limited for > more complex client-facing UIs. My experience is quite contrary to that. In the last three years we were forced to develop a few GUI tools used by our customers and there are no complains only against the tools using racket/gui. Yes, it is far from perfect - but it is the only thing that really behaves consistently across all three platforms we need to support (Linux, Mac, and ... Windows). Python+Qt and go+Qt are absolutely insupportable without a long list of per-platform/per-widget hacks. It might be that we are just hitting corner cases (actually that's pretty probably), yet with Racket there were no such hurdles. > * One complete, commercial-grade Web framework, inspired from Symphony > or Laravel. Security and ease of use first, continuations later. And this is the part that made me actually hit the "Reply List" button. The good thing about mentioned PHP frameworks is only that anyone can start producing something with them without any prior experience. So right now we are encountering vulnerable and unmaintainable code anywhere we bump into some 3rd party "web application" we are hired to audit. With Racket - the entry barrier is really high, I agree. I actually spent many days getting through it - but once you pass the barrier, it really helps you write applications where you can focus on the actual functionality and let the libraries do the rest for you. And securing such application is almost trivial task. Yes, I have hit some corner cases here as well, but if you follow for example Bogdan's work[2][3], you'll see that there are solutions readily available. It is just necessary to read the docs and understand how the whole thing works. > * Better documentation: Racket docs are aesthetically very pleasing, > complete and detailed. However some parts are still very obscure and > lacking simple examples (if only the part about Continuations > included just one basic example, such as a ‘return’ implementation, > on the very first page. If only the Macros documentation started > with define-simple-macro and a few very basic, practical examples. > Instead we’re greeted with pattern-based macros, which although very > powerful, are very hard to comprehend for newcomers). I am not sure whether it is the best thing to start with define-simple-macro (if anything, I'd start with define-syntax-rule), but yes, more examples are always useful. Just write them and send a pull request to appropriate repository - I was pleasantly surprised when I first did this. All the Racketeers are super helpful when it comes to incorporating any improvements. (Thanks Ben!) > > > I am well aware that what I’m wishing for isn’t necessarily compatible > with Racket’s intended public’s needs (comp-sci teachers and students? > That’s the impression I’m getting). But Racket is the most advanced > general purpose programming tool I’ve ever seen. Wouldn’t it be a shame > if it was limited to academic use? As far as I can tell, it is definitely limited to academic use. Although I prepare support materials for my students with Racket, I actually teach Clojure - so for me, Racket is tool mostly for my
Re: [racket-users] Rhombus project plan
On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt wrote: > At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: > > To the point: what would make Racket2 the ultimate tool (for me): > > Performance. Faster startup times, shorter execution times in general. > > Optionally, a ‘lite’ version of Racket that compiles directly to no-deps > > binaries, bypassing the JIT altogether, would be a game-changer. As far > as > > high levels languages with functional concepts and metaprogramming > facilities > > that compiles to tiny, fast bins, Nim comes dangerously close, but it’s > not a > > Lisp, and it’s not Racket. > > Production-quality, modern and fast GUI facilities. I’ll take properly > > documented, complete Qt bindings. Racket/GUI is great for internal > tools, but > > it quickly becomes slow, tedious and limited for more complex > client-facing > > UIs. > > One complete, commercial-grade Web framework, inspired from Symphony or > > Laravel. Security and ease of use first, continuations later. > > Better documentation: Racket docs are aesthetically very pleasing, > complete > > and detailed. However some parts are still very obscure and lacking > simple > > examples (if only the part about Continuations included just one basic > > example, such as a ‘return’ implementation, on the very first page. If > only > > the Macros documentation started with define-simple-macro and a few very > > basic, practical examples. Instead we’re greeted with pattern-based > macros, > > which although very powerful, are very hard to comprehend for newcomers). > > Which of these things will you be working on? > I'll step up. Matt, I need some help with Scribble and how to contribute to the Racket docs. I'd be willing to pay for a couple hours of your time (or whomever else's has the skill/knowledge) to walk me through that. After that I'll be happy to pitch in by offering documentation patches. This will be a big help for me, since I'm finding myself having trouble writing docs for my own code. > > > > I am well aware that what I’m wishing for isn’t necessarily compatible > with > > Racket’s intended public’s needs (comp-sci teachers and students? That’s > the > > impression I’m getting). But Racket is the most advanced general purpose > > programming tool I’ve ever seen. Wouldn’t it be a shame if it was > limited to > > academic use? > > https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be > > -- > 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com > . > -- 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/CAE8gKoe%3D5XYkfveAKUy2b6iq7pfNJsZVr%3Djhh7G-8rszHrwfbQ%40mail.gmail.com.
Re: [racket-users] Rhombus project plan
At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote: > To the point: what would make Racket2 the ultimate tool (for me): > Performance. Faster startup times, shorter execution times in general. > Optionally, a ‘lite’ version of Racket that compiles directly to no-deps > binaries, bypassing the JIT altogether, would be a game-changer. As far as > high levels languages with functional concepts and metaprogramming facilities > that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not a > Lisp, and it’s not Racket. > Production-quality, modern and fast GUI facilities. I’ll take properly > documented, complete Qt bindings. Racket/GUI is great for internal tools, but > it quickly becomes slow, tedious and limited for more complex client-facing > UIs. > One complete, commercial-grade Web framework, inspired from Symphony or > Laravel. Security and ease of use first, continuations later. > Better documentation: Racket docs are aesthetically very pleasing, complete > and detailed. However some parts are still very obscure and lacking simple > examples (if only the part about Continuations included just one basic > example, such as a ‘return’ implementation, on the very first page. If only > the Macros documentation started with define-simple-macro and a few very > basic, practical examples. Instead we’re greeted with pattern-based macros, > which although very powerful, are very hard to comprehend for newcomers). Which of these things will you be working on? > I am well aware that what I’m wishing for isn’t necessarily compatible with > Racket’s intended public’s needs (comp-sci teachers and students? That’s the > impression I’m getting). But Racket is the most advanced general purpose > programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to > academic use? https://www.youtube.com/watch?v=LN0qG-i1iT0=youtu.be -- 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/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
Re: [racket-users] Rhombus project plan
Hi all, I had written a few of my early thoughts about ‘racket2’, but after mulling over all this for a good year, I’d like to write something more definitive. My background: I started programming in BASIC on C64, followed by ADA, Pascal, C and macro-assembly on 8086 with MASM in the 90’s. My main hobby as a teen was to make demos in assembly, trying to squeeze every byte out of 64kb’s. Once my ‘low-level honeymoon’ phase faded, I went on a quest to find a high level language which would make me more productive and spare me the pain of having to explain every little detail directly to the CPU. Through work I have had to write a lot of JavaScript and PHP for the Web, plenty of C++, later replaced by C# for Windows-only projects. I played with Go for network services, toyed with Nim for automation, and later (painfully) learned Rust just to see if it was a viable Assembly substitute. I found Rust way more annoying to learn and use than Assembly. For me, Macro-Assembly + Win32 API is still the combo to beat to produce tiny, fast internal apps with no dependencies other than the OS. Over the years, my MASM macro library has grown so much that I can write an entire GUI app, in a language that looks like BASIC. Only it compiles to a few kilobytes, loads instantly and runs on any version of Windows since 95. If only I could do that in a cross-platform way... so for anything client-facing, x-platform on the desktop, I ended up joining the masses, and use C++/Qt. During my quest for the ultimate language, I played with Common Lisp, Haskell and OCaml, but only found true love with Scheme, which I found ‘purer’ and closer to my idea of a universal, ‘100-years language’. Racket only amplified my attraction to parentheses and multi-paradigm languages. I now use Racket every day to write internal automation tools, and have developed over 100 command-line and GUI apps to do anything from file format conversion to video encoding/decoding, to financial analysis, to production asset tracking and packaging. Some of these tools span dozens of modules. To the point: what would make Racket2 the ultimate tool (for me): Performance. Faster startup times, shorter execution times in general. Optionally, a ‘lite’ version of Racket that compiles directly to no-deps binaries, bypassing the JIT altogether, would be a game-changer. As far as high levels languages with functional concepts and metaprogramming facilities that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not a Lisp, and it’s not Racket. Production-quality, modern and fast GUI facilities. I’ll take properly documented, complete Qt bindings. Racket/GUI is great for internal tools, but it quickly becomes slow, tedious and limited for more complex client-facing UIs. One complete, commercial-grade Web framework, inspired from Symphony or Laravel. Security and ease of use first, continuations later. Better documentation: Racket docs are aesthetically very pleasing, complete and detailed. However some parts are still very obscure and lacking simple examples (if only the part about Continuations included just one basic example, such as a ‘return’ implementation, on the very first page. If only the Macros documentation started with define-simple-macro and a few very basic, practical examples. Instead we’re greeted with pattern-based macros, which although very powerful, are very hard to comprehend for newcomers). I am well aware that what I’m wishing for isn’t necessarily compatible with Racket’s intended public’s needs (comp-sci teachers and students? That’s the impression I’m getting). But Racket is the most advanced general purpose programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to academic use? Racket’s home page starts with ‘Racket - Solve Problems - Make Languages’. That very first line will scare anybody looking to just... write programs. Yes it is the entire point, but why not try and go back to basics with Racket2, and (also) tackle what really matters? Easily writing correct, fast and powerful programs that let us build tomorrow’s technologies. Dex > On Apr 28, 2020, at 5:23 PM, David Storrs wrote: > > > I'll throw this in simply so that it's part of this thread. There's nothing > new here, so if you've seen my comments in earlier Racket2 threads then you > can skip this. > > I've said before and continue to think that getting rid of the parenthesis > syntax is a major error. It is inarguable that there are significant > advantages to parenthesis syntax -- to name a few: No need to memorize > precedence tables, ease of code serialization and composition, extreme > friendliness to parsers and generators. So far as I've seen, no one has yet > presented an argument in support of eliminating parenthesis notation aside > from "My students will find it easier." That may or may not be true but I > find myself unconvinced that it is the major
Re: [racket-users] Rhombus project plan
I'll throw this in simply so that it's part of this thread. There's nothing new here, so if you've seen my comments in earlier Racket2 threads then you can skip this. I've said before and continue to think that getting rid of the parenthesis syntax is a major error. It is inarguable that there are significant advantages to parenthesis syntax -- to name a few: No need to memorize precedence tables, ease of code serialization and composition, extreme friendliness to parsers and generators. So far as I've seen, no one has yet presented an argument in support of eliminating parenthesis notation aside from "My students will find it easier." That may or may not be true but I find myself unconvinced that it is the major barrier to widespread adoption. I believe that people are not avoiding Racket primarily because it has parentheses, they are avoiding it because it's one more thing to learn, it's a huge language with sometimes daunting documentation, and they aren't sold that the advantages will outweigh the effort + lack of applicability to getting a job. That's a matter for evangelism and documentation development, not a language rewrite. The Racket documentation is very impressive -- it's aesthetically beautiful, it's thorough, and once you get comfortable with BNF the Reference becomes very useful. The documentation also has some weak points, such as the Reference needing more examples, and it would be helpful to have a visual distinction between the Guide and the Reference so that when links point back and forth it's easy to tell which one you're in. More importantly, it's very difficult to contribute to the documentation without a lot of effort due to the literate programming style of needlessly templatized chunks, link targets that don't match page URLs, and excessive numbers of repositories with filetree layouts that are not intuitive. (Or, at least, aren't intuitive for *me*. I don't think I'm smarter than the average bear but I'm an experienced developer who has contributed to multiple open source projects and I don't think it should be this difficult to figure out.) I'm good at documentation and would be delighted to contribute a ton of it if those barriers to entry were lower. On Wed, Oct 2, 2019 at 3:27 PM Matthew Flatt wrote: > [[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, just as in >the 6.x and 7.x series of releases. > > - The team will release updated versions, occasionally making modest >incompatibilities with explicit transition paths as needed
Re: [racket-users] Rhombus project plan
Fantastic! In these confusing times, this fills my mind with warmth and optimism. > On Oct 2, 2019, at 12:27 PM, Matthew Flatt wrote: > > 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. -- 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/26232E44-3619-4751-9230-4B3544C8A81B%40mbtype.com.
