Rhombus project plan
2,213 views
Skip to first unread message
Matthew Flatt
Oct 2, 2019, 3:27:50 PM10/2/19
to Racket-Users List
[[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 agreement on specific design constraints and the outline of a
design to move to the next phase.
Failure is an option; some of the original goals may be abandoned, and
the project as a whole may be abandoned if the project leader cannot
identify a suitable product to move on to the next phase.
The project leader will also use this first process to identify
contributors and working-group leaders for the second phase.
Phase 2: Iterative Design (years)
-------------------------
GOAL AND OUTPUT: Specification and a coherent prototype for the overall
language design, stable enough for practical work and at the same time
subject to refinement through practice.
PROCESS: This phase starts work on an implementation that is intended
to last, consolidating ideas that emerged from the brainstorming phase
and exposing how well different ideas fit together at scale. The design
will evolve in response to the implementation effort, but it should
eventually converge.
The design and implementation will take place in publicly visible
repositories and discussion forums. The process will use an RFC-style
mechanism, with documents that pin down the design and with specified
comment and conclusion timelines.
The project leader will delegate RFC production and conclusion to
groups of contributors that are identified by participation in the
brainstorming phase (specification and implementation as well as
discussion). Those groups will take feedback from the community at
large, and they will be explicit about their rationales for final
design decisions. Possible groups include a reader group, a macro
group, a data structures and generics group, a library-organization
group, and so on.
CONCLUSION: When this phase produces sufficiently clear, detailed, and
coherent specifications plus a significant implementation, the project
can move to the next phase.
Failure is still an option. If the project leader is never able to
identify such a result, the project will be declared a failure.
Phase 3: Conversion (months or years)
-------------------
GOAL AND OUTPUT: Complete language, libraries, and documentation,
including a name for the language.
PROCESS: This phase starts the attempt to port and adjust appropriate
existing code and documentation (e.g., in the Racket main distribution)
to make sure it works and to continue sorting out any mismatches
between the new language and `#lang racket` at an even larger scale.
A language name --- as opposed to a temporary project name --- must be
picked at this point. By delaying the choice of name until we know what
the language is, we avoid confusion and misinformation due to
historical properties of Rhombus-in-development that end up not being
true about the completed language.
CONCLUSION: The decision of whether this conversion succeeds ---
including which things really should be converted or not and when
progress is sufficient to consider the next step --- is up to Racket
project leadership.
Failure is not yet ruled out. If the Racket project leadership never
approves the language for direct support, then the project fails.
Phase 4: Transition (years)
-------------------
GOAL AND OUTPUT: Unified distribution and presentation for the new
language and the existing Racket ecosystem.
PROCESS: If Rhombus is likely to appeal to a large number of people,
the team will make adjustments to the existing Racket infrastructure:
- the distribution,
- the web pages,
- the pedagogic material,
- the communication channels, and
- other outward-facing aspects.
It's difficult to say what transition will be needed without knowing
what the actual language will look like, but it's easy to predict that
some transition will be needed if the Rhombus project manages to
progress to this point.
Racket project leadership, expanded with leaders emerging from the
Rhombus project, will make the calls at this phase.
Failure is no longer an option at this point.
CONCLUSION: The new language is at least as well supported and
available as `#lang racket`.
What Will Happen to Racket by the End
-------------------------------------
Transitioning does not mean that Racket will disappear.
- Existing `#lang racket` programs will continue to run beyond Phase 4.
- The documentation for `#lang racket` will co-exist with whatever we
call the new language.
Put differently, Racket will become a component of the overall new
distribution.
- Jay, Matthew, Matthias, Robby, and Sam
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 agreement on specific design constraints and the outline of a
design to move to the next phase.
Failure is an option; some of the original goals may be abandoned, and
the project as a whole may be abandoned if the project leader cannot
identify a suitable product to move on to the next phase.
The project leader will also use this first process to identify
contributors and working-group leaders for the second phase.
Phase 2: Iterative Design (years)
-------------------------
GOAL AND OUTPUT: Specification and a coherent prototype for the overall
language design, stable enough for practical work and at the same time
subject to refinement through practice.
PROCESS: This phase starts work on an implementation that is intended
to last, consolidating ideas that emerged from the brainstorming phase
and exposing how well different ideas fit together at scale. The design
will evolve in response to the implementation effort, but it should
eventually converge.
The design and implementation will take place in publicly visible
repositories and discussion forums. The process will use an RFC-style
mechanism, with documents that pin down the design and with specified
comment and conclusion timelines.
The project leader will delegate RFC production and conclusion to
groups of contributors that are identified by participation in the
brainstorming phase (specification and implementation as well as
discussion). Those groups will take feedback from the community at
large, and they will be explicit about their rationales for final
design decisions. Possible groups include a reader group, a macro
group, a data structures and generics group, a library-organization
group, and so on.
CONCLUSION: When this phase produces sufficiently clear, detailed, and
coherent specifications plus a significant implementation, the project
can move to the next phase.
Failure is still an option. If the project leader is never able to
identify such a result, the project will be declared a failure.
Phase 3: Conversion (months or years)
-------------------
GOAL AND OUTPUT: Complete language, libraries, and documentation,
including a name for the language.
PROCESS: This phase starts the attempt to port and adjust appropriate
existing code and documentation (e.g., in the Racket main distribution)
to make sure it works and to continue sorting out any mismatches
between the new language and `#lang racket` at an even larger scale.
A language name --- as opposed to a temporary project name --- must be
picked at this point. By delaying the choice of name until we know what
the language is, we avoid confusion and misinformation due to
historical properties of Rhombus-in-development that end up not being
true about the completed language.
CONCLUSION: The decision of whether this conversion succeeds ---
including which things really should be converted or not and when
progress is sufficient to consider the next step --- is up to Racket
project leadership.
Failure is not yet ruled out. If the Racket project leadership never
approves the language for direct support, then the project fails.
Phase 4: Transition (years)
-------------------
GOAL AND OUTPUT: Unified distribution and presentation for the new
language and the existing Racket ecosystem.
PROCESS: If Rhombus is likely to appeal to a large number of people,
the team will make adjustments to the existing Racket infrastructure:
- the distribution,
- the web pages,
- the pedagogic material,
- the communication channels, and
- other outward-facing aspects.
It's difficult to say what transition will be needed without knowing
what the actual language will look like, but it's easy to predict that
some transition will be needed if the Rhombus project manages to
progress to this point.
Racket project leadership, expanded with leaders emerging from the
Rhombus project, will make the calls at this phase.
Failure is no longer an option at this point.
CONCLUSION: The new language is at least as well supported and
available as `#lang racket`.
What Will Happen to Racket by the End
-------------------------------------
Transitioning does not mean that Racket will disappear.
- Existing `#lang racket` programs will continue to run beyond Phase 4.
- The documentation for `#lang racket` will co-exist with whatever we
call the new language.
Put differently, Racket will become a component of the overall new
distribution.
- Jay, Matthew, Matthias, Robby, and Sam
Matthew Butterick
Oct 3, 2019, 10:19:50 PM10/3/19
to Matthew Flatt, Racket-Users List
Fantastic! In these confusing times, this fills my mind with warmth and optimism.
Chris Nelson
Oct 7, 2019, 8:36:21 PM10/7/19
to Racket Users
One part of me thinks of glorious success of Perl 6 and the rapid conversion to Python 3.x from Python 2.x ...
... the other part says, "Racket is your research project, you do what you want to do."
Good Luck and have Fun!
Chris
Liwei Chou
Apr 24, 2020, 1:14:24 PM4/24/20
to Racket Users
As a newcomer from industry, I would like to share some of my thoughts.
First, about the syntax.
I suggest you to watch this video. This guy talks about the approaches Wolfram Language takes to solve this problem. By stacking up different layer of syntax like FullForm, InputForm for different level of abstractions or purpose. Which involves M-expression, the concept of syntactical equivalence, two-way conversion...etc. I think it works very well, because many researchers in the world are using it without any problem.
REBOL language is also worth checking out. It's a language advocate DSL at its core. The core language is pretty concise, like the microkernel of the language. Then trying to build all kinds of small dialects on top of that to deal with different problem, and can still inter-op with each other. The outcome is a very concise language with very small footprint. The downloadable size of the runtime with GUI support is less than 1 MB.
Second, about increasing adoption rates or lowering barriers. I think the key is usefulness, that is, wow much work can be done with a certain amount of time and resources.
I'v post similar idea in another thread about the landing page of Racket website.
To be short, the most important thing is to answer following questions.
1. Can this thing solve my problem? (current and future)
2. Why would I choose (to invest my time on) this language instead of others?
3. By investing time learning this language, what kind of benefits can I get? (short term and long term)
In the field of entrepreneurship, there is a theory called "Jobs to be done". (Proposed by Clay Christensen)
The idea is people buy stuff for solving their problem. For choosing language, people tend to invest time on the language they think they can solve more (practical) problem with less amount of effort.
I won't go too long. Just for you to get the idea.
The main reason I chose to spend time learning racket is because of its outstanding expressiveness. Which let me believe it's the language that can make me "Do more with less". So, please continue to let people "Do more with less."
Matthew Flatt於 2019年10月3日星期四 UTC+8上午3時27分50秒寫道：
Anurag Mendhekar
Apr 27, 2020, 1:25:09 PM4/27/20
to Racket Users
First of all, Thank you to the team for making such a fantastic system available for the rest of us. I don't know what I'd have done without it. As a very long time Schemer/Racketeer/Lisper and a consistent industry practitioner (I have used Chez Scheme and Racket as critical parts of every one of my companies in the past 20 years).
It is somewhat unclear to me from reading this proposal what the expected outcomes of this project are, or ought to be (in terms of making a real change in the language ecosystem). But, if one of the outcomes is to gain widespread adoption, my first thoughts upon reading this proposal are as follows.
1. The obsession with parentheses/syntax is misplaced. My analysis of the psychology of parentheses that it is a redirection of frustration with functional-style programming. Let's acknowledge the fact that functional programming is a difficult paradigm for the average CS graduate and they generally skew imperative (it's probably rooted in human psychology, since that is how our systems are organized: around change of state). In any case, the frustration in dealing with it is directed towards syntax in the case of Racket. Other functional languages with conventional syntax suffer the same outcome: lack of widespread adoption because of perceived "annoyances". While I would welcome the ability to more easily add new (possibly infix) notation into my own syntactic extensions, spending too much time designing a new "better" syntax for racket is not going to reduce the adoption barrier. So, I would rather own it than defend it.
2. Adoption will be widespread once the language and its accompanying platform can stake out a claim for itself in terms of what can be built with it.
I can't speak to the other aspects of internal design that this post talks about but here is what I believe we need in the industry to convince my new crop of engineers to start adopting Racket at a larger scale. In some ways, I'm looking at it as a "sell" job, and here are the things I know I can sell. This is not so much about language design as much as it is about the Platform itself, although I'm sure Racketeers can do a far better job of bringing in elements of language design into this. Of course, the community needs to work towards doing this along with the Racket team, but as a community, we should set an agenda and work towards it. The Rhombus discussion provides an opportunity for this. So here are my two cents.
A) Performance. As a point of comparison, the JVM has gotten amazingly good over the past couple of decades, but Java continues to be derided as a terrible language with much lower productivity. Given how productive one can be in Racket, combining that with comparable performance will make it an easy sell. This has largely been Go's and Rust's strategy. C++ level performance with high productivity. For this day and age, this would have to include GPU support (kind of like openCL).
B) Web First. The current the built-in web framework is not enough. The language must support end-to-end development of asynchronous web-applications, and it must be trivial to tack on web front-ends to anything. This is the Node/JS and Ruby/Rails strategy. Racket has some elements of this, but building a web-app in racket is still a lot of work. With web-assembly on the horizon, Racket can very easily be a front-end language as well as a back-end language.
C) Mobile First (ok, Second :-). The language must provide inherent support for building mobile front-ends (both android and IoS). This is the Swift/XCode strategy.
D) AI Support. AI is clearly the next wave of software and people are going to be building AI into their systems for decades to come. In this instance, Lisp's AI legacy might actually be of help, if we can make it very easy to develop AI applications. While Python seems to be the preferred language right now, I don't believe it will last too long. AI programming in Python is at best a puke-worthy experience.
E) Cloud Ready out of the box - Simple deployment using docker, AWS Lambda and the like; built-in support for directly working with cloud resources (buckets, ACL's, Logs, etc.)
F) Broad IDE support. Rather than focus on Emacs/Dr. Racket, I believe Racket should take the approach of integrating with all the different IDE's. (JetBrains' IDEA, NetBeans, Visual Studio, Eclipse) Most are now good enough to be scripted and in many cases the click-happy younger generation deals with it better, and probably much less work than trying to maintain Dr.Racket.
G) Other desirables, but less important than the ones above:
- FFI for Java libraries. (One of the biggest reasons for Clojure's appeal)
- CLOS. It is still the finest object system ever that most effortlessly blends functional-style with objects. Scala's success can be attributed to its functional+object+Java interoperability strategy, type-system not withstanding.
Anurag.
unlimitedscolobb
Apr 28, 2020, 5:08:57 AM4/28/20
to Racket Users
Hello everyone and thank you for this very interesting discussion!
I'd like to share my opinion on parenthesized prefix syntax: I actually switched to Racket/Lisp because of it! This highly uniform structure best fits the shape of mind as of today.
Now, I explicitly don't pretend to be representative. Consider me to be the voice of those folks out there who are actually fond of parenthesis.
-
Sergiu
David Storrs
Apr 28, 2020, 11:23:46 AM4/28/20
to Racket Users
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.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20191002192745.F408C650189%40mail-svr1.cs.utah.edu.
Dexter Lagan
Apr 29, 2020, 5:15:24 AM4/29/20
to David Storrs, Racket Users
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 <david....@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKof%3DcqMfVE-meV0R3WNX7mp20zVKm02eYOcM-rUAgiCZzg%40mail.gmail.com.
Matthew Flatt
Apr 29, 2020, 8:21:12 AM4/29/20
to Dexter Lagan, Racket Users
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?
> 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?
David Storrs
Apr 29, 2020, 9:35:58 AM4/29/20
to Matthew Flatt, Dexter Lagan, Racket Users
On Wed, Apr 29, 2020 at 8:21 AM Matthew Flatt <mfl...@cs.utah.edu> 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&feature=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...@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.
Dominik Pantůček
Apr 29, 2020, 10:26:44 AM4/29/20
to racket...@googlegroups.com
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
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
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
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,
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 business and
only remotely for my academic activities. But I guess that I am a corner
case here :)
>
>
> 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.
You would be surprised, why so many people in the industry use Perl.
They use it for producing what is effectively a pile of DSLs. And they
are really keen on trying to do the same with Racket once they find out
they can. I really think that it the perception that making languages is
something hard is biased. If you go to a carpenters workshop, you
probably won't understand much of what they say, even though you are
talking the same language. Then if you would come to visit aerospace
engineers and hear them talking about their latest improvements to
whatever they are doing, again, it will be a different dialect. And in
my opinion, this is exactly what Racket provides us with - common
platform (Racket, English, UTF-8, math ...) and you can create a dialect
that suits your needs. Quickly and without sacrificing any
inter-operational possibilities.
And - as it is evident - I don't need project Rhombus for my work. I am
really happy with Racket as it is. I do not even use brackets...
everything is just plain parentheses to me. Yet I am really closely
following the project to see what it will bring. Because although I use
parentheses exclusively, I use at-exp for certain use-cases and it
boosts my productivity tenfold at least. But on my own, I would never
think about something like at-exp syntax. So I don't know what will
project Rhombus bring and I am pretty sure that right now it is
something I cannot help with, but I can definitely say I like the
approach the core team is taking to research the possibilities.
Wow, that was a long one :). But I hope it shows nicely, that different
people with different use-cases can bring interesting ideas to the
discussion.
Cheers,
Dominik
[1] https://pkgs.racket-lang.org/package/futures-sort
[2] https://defn.io/
[3] https://pkgs.racket-lang.org/package/koyo
I can't leave this without reaction...
>
> To the point: what would make Racket2 the ultimate tool (for me):
>
> 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".
> 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.
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
> internal tools, but it quickly becomes slow, tedious and limited for
> more complex client-facing UIs.
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
> 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).
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?
I prepare support materials for my students with Racket, I actually
teach Clojure - so for me, Racket is tool mostly for my business and
only remotely for my academic activities. But I guess that I am a corner
case here :)
>
>
> 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.
They use it for producing what is effectively a pile of DSLs. And they
are really keen on trying to do the same with Racket once they find out
they can. I really think that it the perception that making languages is
something hard is biased. If you go to a carpenters workshop, you
probably won't understand much of what they say, even though you are
talking the same language. Then if you would come to visit aerospace
engineers and hear them talking about their latest improvements to
whatever they are doing, again, it will be a different dialect. And in
my opinion, this is exactly what Racket provides us with - common
platform (Racket, English, UTF-8, math ...) and you can create a dialect
that suits your needs. Quickly and without sacrificing any
inter-operational possibilities.
And - as it is evident - I don't need project Rhombus for my work. I am
really happy with Racket as it is. I do not even use brackets...
everything is just plain parentheses to me. Yet I am really closely
following the project to see what it will bring. Because although I use
parentheses exclusively, I use at-exp for certain use-cases and it
boosts my productivity tenfold at least. But on my own, I would never
think about something like at-exp syntax. So I don't know what will
project Rhombus bring and I am pretty sure that right now it is
something I cannot help with, but I can definitely say I like the
approach the core team is taking to research the possibilities.
Wow, that was a long one :). But I hope it shows nicely, that different
people with different use-cases can bring interesting ideas to the
discussion.
Cheers,
Dominik
[1] https://pkgs.racket-lang.org/package/futures-sort
[2] https://defn.io/
[3] https://pkgs.racket-lang.org/package/koyo
Sam Tobin-Hochstadt
Apr 29, 2020, 10:27:21 AM4/29/20
to David Storrs, Matthew Flatt, Dexter Lagan, Racket Users
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
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKoe%3D5XYkfveAKUy2b6iq7pfNJsZVr%3Djhh7G-8rszHrwfbQ%40mail.gmail.com.
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
David Storrs
Apr 29, 2020, 11:06:20 AM4/29/20
to Sam Tobin-Hochstadt, Matthew Flatt, Dexter Lagan, Racket Users
Cool, thanks! Ping sent.
Sage Gerard
Apr 29, 2020, 11:58:18 AM4/29/20
to users\@racket-lang.org
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 ‐‐‐‐‐‐‐
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
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 ‐‐‐‐‐‐‐
> 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)
>
>
> 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: Complete language, libraries, and documentation,
> including a name for the language.
>
> PROCESS: This phase starts the attempt to port and adjust appropriate
> existing code and documentation (e.g., in the Racket main distribution)
> to make sure it works and to continue sorting out any mismatches
> between the new language and `#lang racket` at an even larger scale.
>
> A language name --- as opposed to a temporary project name --- must be
> picked at this point. By delaying the choice of name until we know what
> the language is, we avoid confusion and misinformation due to
> historical properties of Rhombus-in-development that end up not being
> true about the completed language.
>
> CONCLUSION: The decision of whether this conversion succeeds ---
> including which things really should be converted or not and when
> progress is sufficient to consider the next step --- is up to Racket
> project leadership.
>
> Failure is not yet ruled out. If the Racket project leadership never
> approves the language for direct support, then the project fails.
>
> Phase 4: Transition (years)
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> GOAL AND OUTPUT: Complete language, libraries, and documentation,
> including a name for the language.
>
> PROCESS: This phase starts the attempt to port and adjust appropriate
> existing code and documentation (e.g., in the Racket main distribution)
> to make sure it works and to continue sorting out any mismatches
> between the new language and `#lang racket` at an even larger scale.
>
> A language name --- as opposed to a temporary project name --- must be
> picked at this point. By delaying the choice of name until we know what
> the language is, we avoid confusion and misinformation due to
> historical properties of Rhombus-in-development that end up not being
> true about the completed language.
>
> CONCLUSION: The decision of whether this conversion succeeds ---
> including which things really should be converted or not and when
> progress is sufficient to consider the next step --- is up to Racket
> project leadership.
>
> Failure is not yet ruled out. If the Racket project leadership never
> approves the language for direct support, then the project fails.
>
> Phase 4: Transition (years)
>
>
> GOAL AND OUTPUT: Unified distribution and presentation for the new
> language and the existing Racket ecosystem.
>
> PROCESS: If Rhombus is likely to appeal to a large number of people,
> the team will make adjustments to the existing Racket infrastructure:
>
> - the distribution,
> - the web pages,
> - the pedagogic material,
> - the communication channels, and
> - other outward-facing aspects.
>
> It's difficult to say what transition will be needed without knowing
> what the actual language will look like, but it's easy to predict that
> some transition will be needed if the Rhombus project manages to
> progress to this point.
>
> Racket project leadership, expanded with leaders emerging from the
> Rhombus project, will make the calls at this phase.
>
> Failure is no longer an option at this point.
>
> CONCLUSION: The new language is at least as well supported and
> available as `#lang racket`.
>
> What Will Happen to Racket by the End
>
>
> GOAL AND OUTPUT: Unified distribution and presentation for the new
> language and the existing Racket ecosystem.
>
> PROCESS: If Rhombus is likely to appeal to a large number of people,
> the team will make adjustments to the existing Racket infrastructure:
>
> - the distribution,
> - the web pages,
> - the pedagogic material,
> - the communication channels, and
> - other outward-facing aspects.
>
> It's difficult to say what transition will be needed without knowing
> what the actual language will look like, but it's easy to predict that
> some transition will be needed if the Rhombus project manages to
> progress to this point.
>
> Racket project leadership, expanded with leaders emerging from the
> Rhombus project, will make the calls at this phase.
>
> Failure is no longer an option at this point.
>
> CONCLUSION: The new language is at least as well supported and
> available as `#lang racket`.
>
> What Will Happen to Racket by the End
>
>
> Transitioning does not mean that Racket will disappear.
>
> - Existing `#lang racket` programs will continue to run beyond Phase 4.
> - The documentation for `#lang racket` will co-exist with whatever we
> call the new language.
>
> Put differently, Racket will become a component of the overall new
> distribution.
>
> - Jay, Matthew, Matthias, Robby, and Sam
>
>
> - Existing `#lang racket` programs will continue to run beyond Phase 4.
> - The documentation for `#lang racket` will co-exist with whatever we
> call the new language.
>
> Put differently, Racket will become a component of the overall new
> distribution.
>
> - Jay, Matthew, Matthias, Robby, and 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20191002192745.F408C650189%40mail-svr1.cs.utah.edu.
> You received this message because you are subscribed to the Google Groups "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
>
David Storrs
Apr 29, 2020, 12:47:07 PM4/29/20
to Jeffrey Edgington, Sam Tobin-Hochstadt, Racket Users
On Wed, Apr 29, 2020 at 11:15 AM Jeffrey Edgington <jedg...@cs.du.edu> 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 <sa...@cs.indiana.edu> 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
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
Anurag Mendhekar
Apr 29, 2020, 1:01:11 PM4/29/20
to Racket Users
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.
Dexter Lagan
Apr 29, 2020, 1:47:08 PM4/29/20
to Dominik Pantůček, Racket Users
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
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7d816c28-21a7-85d0-355d-b32030d60354%40trustica.cz.
Dexter Lagan
Apr 29, 2020, 3:39:05 PM4/29/20
to Dominik Pantůček, Racket Users
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.
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 easy. I don't use version control beyond Fossil's basic functions, so I'll have to read up on all this. I'd love to contribute to documentation.
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 business and
only remotely for my academic activities. But I guess that I am a corner
case here :)
Same here, apart from myself, I don't know anybody else who uses Racket for production. I'm the Lisp/Racket evangelist in my department, and I can't imagine using anything else for automation and exploratory programming. It has replaced every other language in my toolset, apart from C++/Qt, for the reasons mentioned previously.
You would be surprised, why so many people in the industry use Perl.
They use it for producing what is effectively a pile of DSLs. And they
are really keen on trying to do the same with Racket once they find out
they can. I really think that it the perception that making languages is
something hard is biased. If you go to a carpenters workshop, you
probably won't understand much of what they say, even though you are
talking the same language. Then if you would come to visit aerospace
engineers and hear them talking about their latest improvements to
whatever they are doing, again, it will be a different dialect. And in
my opinion, this is exactly what Racket provides us with - common
platform (Racket, English, UTF-8, math ...) and you can create a dialect
that suits your needs. Quickly and without sacrificing any
inter-operational possibilities.
Racket's language oriented programming idea always fascinated me, but I could never wrap my head around it. I use macros a lot, but an entire language? It's hard enough to have decent naming conventions, I can't imagine what it would be, having to explain to other programmers how my DSL works just so they can contribute to my code base. I try to stick to very strict style standards, and try hard to keep my code pure and dependency-free, and I still step on my toes when I go a little bit too crazy on macros. I will never understand how they mix languages in the Racket codebase. A higher form of intelligence is probably required :)
And - as it is evident - I don't need project Rhombus for my work. I am
really happy with Racket as it is. I do not even use brackets...
everything is just plain parentheses to me. Yet I am really closely
following the project to see what it will bring. Because although I use
parentheses exclusively, I use at-exp for certain use-cases and it
boosts my productivity tenfold at least. But on my own, I would never
think about something like at-exp syntax. So I don't know what will
project Rhombus bring and I am pretty sure that right now it is
something I cannot help with, but I can definitely say I like the
approach the core team is taking to research the possibilities.
Same here, parens all the way, I don't use brackets. I'm very excited by the possibility of having a non-s-expr syntax that keeps Racket's language-oriented superpowers.
Cheers,
Dex
Dexter Lagan
Apr 29, 2020, 5:10:32 PM4/29/20
to Sam Tobin-Hochstadt, David Storrs, Matthew Flatt, Racket Users
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 <sa...@cs.indiana.edu> wrote:
>
> Hi David,
Cheers,
Dex
> On Apr 29, 2020, at 4:27 PM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
>
> Hi David,
Sam Tobin-Hochstadt
Apr 29, 2020, 5:12:13 PM4/29/20
to Dexter Lagan, David Storrs, Matthew Flatt, Racket Users
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 <dexte...@gmail.com> 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 <sa...@cs.indiana.edu> wrote:
> >
> > Hi David,
https://github.com/racket/scribble/pull/223
Sam
On Wed, Apr 29, 2020 at 5:10 PM Dexter Lagan <dexte...@gmail.com> 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 <sa...@cs.indiana.edu> wrote:
> >
Dexter Lagan
Apr 29, 2020, 5:24:46 PM4/29/20
to Matthew Flatt, Racket Users
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 <mfl...@cs.utah.edu> wrote:
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 <mfl...@cs.utah.edu> wrote:
Matthew Flatt
Apr 29, 2020, 5:48:30 PM4/29/20
to David Storrs, Jeffrey Edgington, Sam Tobin-Hochstadt, Racket Users
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
> 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...?
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
Sorawee Porncharoenwase
Apr 29, 2020, 8:50:34 PM4/29/20
to Matthew Flatt, David Storrs, Jeffrey Edgington, Sam Tobin-Hochstadt, Racket Users
(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?
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5ea9f62b.1c69fb81.d0413.1033SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
George Neuner
Apr 29, 2020, 10:06:18 PM4/29/20
to racket...@googlegroups.com
On Wed, 29 Apr 2020 21:38:49 +0200, Dexter Lagan
<dexte...@gmail.com> 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
<dexte...@gmail.com> 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.
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.
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.
source files aren't large enough to manifest it.
George
Dexter Lagan
Apr 30, 2020, 2:41:11 AM4/30/20
to Matthew Flatt, Racket Users
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 <dexte...@gmail.com> 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 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 <dexte...@gmail.com> 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.
Ben Greenman
Apr 30, 2020, 9:09:09 AM4/30/20
to Racket Users
On 4/29/20, Sorawee Porncharoenwase <sorawe...@gmail.com> 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.
> (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.
Unfortunately there are a lot of them.
Sam Tobin-Hochstadt
Apr 30, 2020, 10:42:35 AM4/30/20
to Ben Greenman, Racket Users
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
Laurent
Apr 30, 2020, 2:30:43 PM4/30/20
to Sam Tobin-Hochstadt, Ben Greenman, Racket Users
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.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BZ5k%2BFk2guk8sxe8gs-kQ9NcKJLkHGeWprrucFzqZ%2BABA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages