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. On Wednesday, October 2, 2019 at 12:27:50 PM UTC-7, 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 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 > > -- 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/3171726a-fc8e-4790-b8ed-86b2b9c36463%40googlegroups.com.
