[racket-users] Re: Rhombus project plan

[George Neuner]

On Wed, 29 Apr 2020 21:38:49 +0200, Dexter Lagan
 wrote:

>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.

My suspicion is that they are comparing to something like Python's
IDLE, which in fairness IS more responsive than DrRacket ... but it
also does much less.  

It might be interesting to compare DrRacket built with RacketCS and
see if its performance is significantly different.


>  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. 

I can't say for certain, but I think it's due to garbage collection.
DrRacket pulls in and JITs a lot of code at startup. If you watch the
memory use (at the bottom), you'll see that after startup it increases
for quite a while (~10 seconds on my machine) before peaking and
falling back to some "base" level (that it never goes below).  If you
start typing before the memory use stabilizes, it seems triggers a
major collection.


>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.

I haven't noticed this particular problem, but perhaps my typical
source files aren't large enough to manifest it.


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/fcbkaf97b1lrmbqfd6s02t3q5mfh34kpbf%404ax.com.

Re: [racket-users] Rhombus project plan

[Sorawee Porncharoenwase]

(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.

[racket-users] Re: Should I stop sending packages to the catalog?

[Alex Harsanyi]

You could both send packages to the package catalog and instruct your users 
to use a different package source if they wish to use old versions.  I 
don't see these two options in conflict with each other.

As an application writer, I am on the other side of this problem, by 
depending on other packages. Having limited time to work on my project I 
want to upgrade package dependencies at my own pace.   The solution I found 
is to use git submodules and add each package as a submodule to my 
application.  I  construct a catalog of these packages, at an exact git 
commit, and simply run a raco pkg install, knowing that the exact version 
that I want will be there.  From time to time, I update these submodules 
and allow some time for fixing any problems that might result from these 
updates.  This has worked reasonably well so far, and I can reliably 
reconstruct older versions of the application knowing that all dependencies 
will be correct for that old version.

For my part, for any packages that my application depends on, their authors 
can make any breaking changes they want, as this will not immediately break 
my application.  At a later date I can review these changes, update my 
application and move to the new version.

The only downside is that installed packages are at "user scope" rather 
than "application scope" so once installed from the git submodules, that 
package becomes available to all applications on my computer.   So far this 
has not been a real issue, although I had to uninstall, switch catalogs and 
re-install a few times.

I personally regard pkgs.racket-lang.org as the source for the latest 
package versions, for users which just started using the package. Users who 
need precise versioning, can always setup their own package catalogs (i 
discovered that it is a really simple process)

Alex.


On Thursday, April 30, 2020 at 12:47:25 AM UTC+8, Sage Gerard wrote:
>
> April 9th in the #general Slack channel taught me that there was no clean 
> way to
> release a breaking change in a package. I'm open to working on version 
> pinning
> support in raco pkg provided that a maintainer can walk me through some 
> code.
>
> In the meantime, as much as I appreciate the efforts made in the current 
> system,
> I'm considering stopping my contributions to the package catalog until 
> further notice.
> I'm open to submitting packages if I am confident in their longevity, but 
> I don't want
> to end up in the position I've been in for the last few weeks when 
> planning a release.
> That position being an inability to release an edition that is not in some 
> way "aware"
> of a prior edition. In my view, changing the package/collection name is an
> example of that problem, not a solution to it.
>
> I'm considering asking my users to specify different package sources in 
> their info.rkt
> files when dealing with my work. Before I commit to that decision, I 
> wanted to tap into
> those of you who have already been here. How have you handled breaking 
> changes
> for your projects? How have you communicated with your users to make sure 
> they
> were adequately prepared? Am I being too black-and-white about this?
>
> *~slg*
>
>
>

-- 
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/b3b54ccf-b4f1-425e-802a-110d5ac26591%40googlegroups.com.

Re: [racket-users] Rhombus project plan

[Matthew Flatt]

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

[Dexter Lagan]

  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

[Sam Tobin-Hochstadt]

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

[Dexter Lagan]

  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] Re: Question about generating urls with dispatch-rules from imported modules

[Yury Bulka]

Greg Hendershott  writes:

> Although I haven't tried to use it hands-on, the description of the
> imperative flavor makes me think it might be intended to help with this?
>
> https://docs.racket-lang.org/web-server/dispatch.html#%28part._.Imperative_.Dispatch_.Containers%29
Hm, that's interesting - it seems to allow modifying a set of already
defined urls; but there might be a usage pattern for my use case that
I'm failing to see.

> p.s. In general you *can* do mutual requires with lazy-require. However you
> defer some errors to runtime, and, you need to list explicitly each
> definition you want to import. IMHO it's better for when the motivation to
> be lazy is about deferring loading and initializing a module, than it is
> for mutual imports. For the latter I tend to just try to move the shared
> definitions to some new module that the others require.
Thank you for commenting on that. Good to know.

-- 
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/87sggmgio1.fsf%40privacyrequired.com.

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

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] Should I stop sending packages to the catalog?

[David Storrs]

On Wed, Apr 29, 2020 at 12:47 PM Sage Gerard  wrote:

> April 9th in the #general Slack channel taught me that there was no clean
> way to
> release a breaking change in a package. I'm open to working on version
> pinning
> support in raco pkg provided that a maintainer can walk me through some
> code.
>
> In the meantime, as much as I appreciate the efforts made in the current
> system,
> I'm considering stopping my contributions to the package catalog until
> further notice.
> I'm open to submitting packages if I am confident in their longevity, but
> I don't want
> to end up in the position I've been in for the last few weeks when
> planning a release.
> That position being an inability to release an edition that is not in some
> way "aware"
> of a prior edition. In my view, changing the package/collection name is an
> example of that problem, not a solution to it.
>
> I'm considering asking my users to specify different package sources in
> their info.rkt
> files when dealing with my work. Before I commit to that decision, I
> wanted to tap into
> those of you who have already been here. How have you handled breaking
> changes
> for your projects? How have you communicated with your users to make sure
> they
> were adequately prepared? Am I being too black-and-white about this?
>
> *~slg*
>

+1 on this.  I'm having the same issue.


>
>
> --
> 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/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.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/CAE8gKod5udG7pkEcg0yEvDfHuVLXswmDb2jLjG6uWmdvvq9thQ%40mail.gmail.com.

[racket-users] Semantic overhaul of Scribble with RDFa

[Greg Trzeciak]

I currently deal with semantic data on a daily basis and a year ago I 
started to work on a project in Racket that involved building RDF toolset 
that I was hoping to open source and use it for implementing the proposal 
outlined in the issue I've just started.
Unfortunately lack of existing toolset and hard interop with Java, forced 
me to abandon the idea of developing the project in Racket and instead 
forced me to switch to Java and Javascript (where the toolset is mostly 
complete).

For these and financial reasons I had to put off (abandon?) building the 
prototype for the solution I believe could solve some issues currently 
being discussed like allowing to reference source location of the code in 
scribble, improve "querability", SEO.

But since some discussion started to float around I decided to outline the 
solution I had in mind for long term Scribble direction. If you have any 
technical details regarding the proposal I suggest github issue here:

https://github.com/racket/scribble/issues/228


-- 
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/98804331-c7c3-40cd-9ad7-252d85a04299%40googlegroups.com.

Re: [racket-users] Rhombus project plan

[Dexter Lagan]

  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

[Anurag Mendhekar]

>
>
> 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.

[racket-users] Should I stop sending packages to the catalog?

[Sage Gerard]

April 9th in the #general Slack channel taught me that there was no clean way to
release a breaking change in a package. I'm open to working on version pinning
support in raco pkg provided that a maintainer can walk me through some code.

In the meantime, as much as I appreciate the efforts made in the current system,
I'm considering stopping my contributions to the package catalog until further 
notice.
I'm open to submitting packages if I am confident in their longevity, but I 
don't want
to end up in the position I've been in for the last few weeks when planning a 
release.
That position being an inability to release an edition that is not in some way 
"aware"
of a prior edition. In my view, changing the package/collection name is an
example of that problem, not a solution to it.

I'm considering asking my users to specify different package sources in their 
info.rkt
files when dealing with my work. Before I commit to that decision, I wanted to 
tap into
those of you who have already been here. How have you handled breaking changes
for your projects? How have you communicated with your users to make sure they
were adequately prepared? Am I being too black-and-white about this?

~slg

-- 
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/3tKIr3GrU9Jnl7V-5yzb52OL3mjt8XNe9F_Qv9HDKwy8xC4j9lQo2e5eGSle4ZFHAee_FiGVhr15lXoovUE6yqoARP-ZNi3kXXz8ETXdufg%3D%40sagegerard.com.

Re: [racket-users] Rhombus project plan

[David Storrs]

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

[Sage Gerard]

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

[David Storrs]

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

[Dominik Pantůček]

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

[David Storrs]

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

[Matthew Flatt]

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

[Dexter Lagan]

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