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.sto...@gmail.com> wrote: > > > I'll throw this in simply so that it's part of this thread. There's nothing > new here, so if you've seen my comments in earlier Racket2 threads then you > can skip this. > > I've said before and continue to think that getting rid of the parenthesis > syntax is a major error. It is inarguable that there are significant > advantages to parenthesis syntax -- to name a few: No need to memorize > precedence tables, ease of code serialization and composition, extreme > friendliness to parsers and generators. So far as I've seen, no one has yet > presented an argument in support of eliminating parenthesis notation aside > from "My students will find it easier." That may or may not be true but I > find myself unconvinced that it is the major barrier to widespread adoption. > I believe that people are not avoiding Racket primarily because it has > parentheses, they are avoiding it because it's one more thing to learn, it's > a huge language with sometimes daunting documentation, and they aren't sold > that the advantages will outweigh the effort + lack of applicability to > getting a job. That's a matter for evangelism and documentation development, > not a language rewrite. > > The Racket documentation is very impressive -- it's aesthetically beautiful, > it's thorough, and once you get comfortable with BNF the Reference becomes > very useful. The documentation also has some weak points, such as the > Reference needing more examples, and it would be helpful to have a visual > distinction between the Guide and the Reference so that when links point back > and forth it's easy to tell which one you're in. More importantly, it's very > difficult to contribute to the documentation without a lot of effort due to > the literate programming style of needlessly templatized chunks, link targets > that don't match page URLs, and excessive numbers of repositories with > filetree layouts that are not intuitive. (Or, at least, aren't intuitive for > *me*. I don't think I'm smarter than the average bear but I'm an experienced > developer who has contributed to multiple open source projects and I don't > think it should be this difficult to figure out.) I'm good at documentation > and would be delighted to contribute a ton of it if those barriers to entry > were lower. > > >> On Wed, Oct 2, 2019 at 3:27 PM Matthew Flatt <mfl...@cs.utah.edu> 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/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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CAE8gKof%3DcqMfVE-meV0R3WNX7mp20zVKm02eYOcM-rUAgiCZzg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7185AAF8-FF4E-4D40-96D0-9EC5477B4ECE%40gmail.com.
