11 ms·

Thoughts on Racket2

95 points by spraak 7y ago

lacampbell 7y ago
But in the last 60 years, simply grabbing these dissenters by the lapels and fumigating them with the stinky garlic breath of parenthesized S-expressions has not been a winning strategy.If Lisp partisans want different results in the next 60 years, we need to try something new. Given the rapid increase in programmers across the globe, I'd bet on there being more LISP programmers now than at any other time in human history. So why the obsession with popularity?
- catach 7y ago
  > So why the obsession with popularity? One reason could be altruism. If you believe your tool is superior to the tools that most others are using you may be highly motivated to convince those people to upgrade. Another reason could be that higher popularity leads to more jobs.
  - neilv 7y ago
    Another is that practice relevance (adoption) is a factor in some research grants/funding. There's also adoption of their CS education programs, like HtDP, when clear industry relevance is one of the factors for some. I suppose that attracting students to the professors' own universities, at least undergrads, might also be a factor, though I haven't heard anything about that one.
- JadeNB 7y ago
  > Given the rapid increase in programmers across the globe, I'd bet on there being more LISP programmers now than at any other time in human history. So why the obsession with popularity? I think that there's a difference between a concern with popularity, which this article demonstrates, and an obsession with popularity, which may afflict parts of the Lisp community (not LISP any more, at least in most dialects) but isn't clearly demonstrated here. If quantitative popularity is important at all, then surely it is percentages and not absolute numbers that are most important (e.g., in 2016, Hillary Clinton got more votes in Texas than in Delaware—15 times more!—but that's not the relevant number). Even if quantitative popularity isn't important, surely some basic level of popularity is to be desired by fans of the language; and it must continually be renewed, not taken for granted. Note that more than the popularity of the language as a practical tool is at stake here; the article specifically talks about the declining popularity of Lisp as a teaching language, and, whatever language you use later in your hacking career, it's a shame to embark on that career not having been exposed to the ideas of Lisp (although, to be fair, those ideas have disseminated so much into the mainstream that many of them can be at least as easily found outside of Lisp as inside it).
- jchw 7y ago
  Because popularity is relative. Languages and frameworks benefit strongly from popularity because they are more likely to be well-supported and have thriving ecosystems the more popular they are. I'd say it is fairly healthy to be concerned about a language's popularity when talking about its future.
- JasonFruit 7y ago
  I don't know why this is such an unpopular comment. 5000 users today is the same number of people as 5000 users in 1970, even if there are way more potential users now. We can be pretty pleased that there are a bunch of people who are getting the productivity, fun, and education Lisp can provide, even if we might wish it had a higher percentage of users.
  - lacampbell 7y ago
    I don't know why this is such an unpopular comment. HN can be a weird place. There's a lot of good discussion to be had. But the passive-aggressiveness and walking-on-eggshells behaviour required to not be greyed out into oblivion can be a bit much. It reminds me of visiting my childhood friends that had super strict parents - can't watch the simpsons, in bed at 7, etc etc. Always wondering what they might be upset by. I might go back to lurking. I'm a bad 'cultural fit'!
    - karmakaze 7y ago
      Making wholehearted, rational, unpopular comments is one of my fave HN things to do.
    - dTal 7y ago
      In my experience there is almost always an easily identifiable reason for a post being downvoted, and it's usually a good one. It's very avoidable if you engage your brain into "do not offend" mode before posting, which I find quite a positive habit to develop in other areas of life as well. In the case of your comment, the downvotes can be traced to your use of the unnecessarily negative word "obsession". You implied that people who want Lisp to be more popular are mentally unbalanced, even though this is a quite understandable thing to want. And you must admit that your reasoning is, at the very least, quite arguable, and warranted a greater tone of humility. Insults derived from dubious reasoning are a surefire recipe for downvotes. If you had concluded your post with "so it doesn't appear all that important to me for Lisp to be popular in an absolute sense" I think you would have been fine.
      - 7y ago
- protomyth 7y ago
  The sad truth from a corporate / enterprise perspective, popularity (or perceived popularity) means safety and checklist fulfillment. Management knows it can find people to plug into its empty slots, and HR has a easy thing to look for on the resume. People like comfort and safety. Now, you could say you are a startup and need the advantage. Good, you can do it, but you might have to supply more code to fill the gaps and deployment might require some extra knowledge (ecosystem problems). Its a value judgement as developer productivity isn't the only part of your development. Still, you can have a heck of an advantage. Look no further than the founder of this board, but remember the second part of the story. The Lisp got rewritten because it wasn't a comfortable choice for the new owners. Perceived popularity means comfort and ecosystem.
  - neilv 7y ago
    Exactly. I've been arguing this for awhile. I'd go more specific than startups, to narrow in on those who are doing something unusual, such that they know they'll have to implement nontrivial stuff from scratch, no matter what language and off-the-shelf libraries/frameworks they use. That's one of the places that Racket can be a win. Related to that, I've also been trying to get people to stop saying "batteries included", because that's misleading, and sends the wrong message about what the actual relative strengths are. In practice, I suspect the initial startup adoption will largely be chance/serendipity, until there's at least one great startup success story, to interest and inspire confidence in other startup efforts. (I have one great success story, which was due to such serendipity, but it's a non-public system, and I've been milking that one way too long already in promoting Racket.)
sigwinch28 7y ago
A talk about rebuilding Racket is being given tomorrow (Monday 19th August) at ICFP'19 (10:30am local Berlin time): https://icfp19.sigplan.org/details/icfp-2019-papers/1/Rebuilding-Racket-on-Chez-Scheme-Experience-Report- https://icfp19.sigplan.org/details/icfp-2019-papers/1/Rebuil... This should be live-streamed, with online Q&A: https://icfp19.sigplan.org/attending/Remote+participation https://icfp19.sigplan.org/attending/Remote+participation
- disconcision 7y ago
  To clarify, this talk is about racket-on-chez, a chez-scheme-based rebuild of the racket compiler, which is live now (but optional) as of racket 7.4. This is entirely separate from 'racket2', a loose term for a variety of breaking changes which are beginning to be considered, prompted by matt flatt's state of racket talk at last month's racketcon.
  - tux1968 7y ago
    To save a google search for anyone else interested in watching his talk: https://youtu.be/dnz6y5U0tFs?t=392 https://youtu.be/dnz6y5U0tFs?t=392
xixixao 7y ago
I love reading these ideas, similar in "otherwordliness" to Rich Hickey's, but the silent majority goes against them. Giving every programmer the ability to create a language of their own does not work out well. (similarly, on Rich's ideas, having library authors forever support old implementations to avoid breaking clients does not work out in reality) The truth seems to be closer to having to endure the constant pain of rewrites and reimplementions, imperfect abstractions and systems, that slowly etch us towards some shitty golden medium, something everyone hates but everyone agrees is the best we could come up with so far. The next iteration of that is most likely not gonna come from something completely different, genius, but from something just slightly different, slightly better.
- didibus 7y ago
  Rich's idea is not to forever support old implementation's, but to never mutate an existing one in a breaking way. In the Clojure community, that's actually been working pretty well, and you seldom have to deal with the kind of rewrites other languages forces upon you.
- sigstoat 7y ago
  > Giving every programmer the ability to create a language of their own does not work out well. they've already got that ability. it just results in languages which can't interoperate. and it takes them a lot of effort to get a garbage result. i suppose that "[it] does not work out well" is a reasonable description of the current situation. maybe you're actually arguing _for_ racket!
acbart 7y ago
One of the biggest problems is that these language designers, who want to design an "idealized" language, continue to make big decisions without regards to any kind of actual data collection. I just had the chance to meet and talk with Andreas Stefik, who summarized the utter and embarrassing lack of research by the PL community about actual language usability[1]. I'm not exactly jumping into line to adopt his evidence-based language "Quorum", but thank goodness that someone cares enough to do actual HCI research instead of just arguing theoretical merits. My own history and feelings about Racket are with regards to its connections with the controversial "Program by Design" curriculum - feelings that are both complicated and narrow (all revolving around introductory computing contexts). But I certainly resonate with this quote from the article: "But in the last 60 years, simply grabbing these dissenters by the lapels and fumigating them with the stinky garlic breath of parenthesized S-expressions has not been a winning strategy. If Lisp partisans want different results in the next 60 years, we need to try something new." [1] https://quorumlanguage.com/evidence.html https://quorumlanguage.com/evidence.html
- didibus 7y ago
  I'm big on evidence based, but I'm also not sure I believe evidence can be adequately demonstrated. The PL used is a tool for the programmer. If you take other disciplines, has their ever been proper evidence that some tools are better then others for any practice? What knife a chef chooses to use, what design a F1 car incorporates, etc. It seems a lot of it depends on the practitioner's style and symbiosis. Most evidence based research into PL seems very inadequate, and I'm not sure we'll ever have good experiments. How do you measure the language over its level of mastery? Certain novice somewhat being more productive or making less bugs on trivial programs in beginner contexts doesn't tell you much. Also, the very clear PL improvements have mostly been universally adopted. Lexical scopes for example, if/else conditionals, procedures, runtime types, GCs, dependency managers, unit and integ tests, etc. It's only the insignificant details which are often debated. And for those, I think it becomes much more a decision to be made by masters, like your favourite chef knife, you pick what best fits your style and maximises your own productivity while minimizing your own weaknesses.
- fouric 7y ago
traderjane 7y ago
> Of course, it’s the core team’s prerogative to run the project as they wish. The rest of us are, after all, freeloaders. But procedural transparency isn’t just a mechanism for gathering community feedback, nor is it bureaucratic foofaraw. It’s also a tool for convincing users, especially industry adopters, that Racket has procedures and values that are worthy of time & money commitments—that there is a “rule of law” that guides outcomes. > I may be a visible user and fan of Racket—and even a teacher at Racket School—but I don’t have any influence on the direction of Racket. I think the Racket community is now big enough, however, that pulling off this kind of major change in Racket requires a stronger procedural foundation. The absence of this foundation is, in this fan’s opinion, a greater risk to the success of Racket2 than any technical hurdle.
- neilv 7y ago
  I disagree with that quoted bit about freeloaders. A lot of people have invested a lot of time and energy to building Racket and the community, over close to 20 years. I fully agree with the bits about transparency, and would add to that... The best outcome I can imagine from the recent would be if the leadership articulates unambiguously what I've been calling the "top-level requirements" that guide everything else in Racket. (I have a pretty good guess at the top-level requirements thus far, based on history. I'm also pretty sure that much of the user community still has mistaken ideas about that. Another reason for articulating these top-level requirements is that they might be changing now, as it seems a few things are changing.) After the top-level requirements, as a guide and to also let people know where they stand, then it would be good to have a well-considered model for whatever input (and possibly decision-making) is wanted from the non-leadership.
liability 7y ago
LOP is cool and interesting, but I'm much more interested in a "batteries included" scheme dialect. Is there another language with devs more aligned to that interest?
- _emacsomancer_ 7y ago
  I think Racket is probably a good bet for a 'batteries included' Scheme dialect (and I think rather than Racket2, including more batteries would attract more people to Racket, but I digress...) - it has good crossplatform GUI options, for instance.
  - liability 7y ago
    Yeah, I've been using racket/gui a lot and it would be a real drag to use GTK ffi bullshit or whatever instead.
- neilv 7y ago
  I wouldn't say "batteries included" about any of them, by comparison to Python. Some to look at: Racket, Guile, Gambit, Chicken, Bigloo, Scheme48 (and Scsh).
  - peatmoss 7y ago
    I’ve been looking at Gerbil lately, which seems to add some creature comforts, has some opinionated views, and is built atop Gambit: https://cons.io/ https://cons.io/
    - neilv 7y ago
      I think that one was started by vyzo, and I'm happy to see it with ongoing git activity. I'll have to take a closer look. vyzo previously contributed to Racket (then called PLT Scheme): http://planet.racket-lang.org/display.ss?owner=vyzo http://planet.racket-lang.org/display.ss?owner=vyzo (PLaneT is the nice earlier package system. The current one is "https://pkgs.racket-lang.org/" https://pkgs.racket-lang.org/", but I think vyzo had left by then, or at that time. I should mention: I wouldn't read much into the Open Tickets on that page not having action -- tickets were a feature someone added without some prominent package authors even knowing about it, at a time when authors were expecting to be emailed, so it could be sadly counterproductive. Even if you did eventually learn it existed and people were posting tickets, but didn't want to keep checking and using a Web site (this was before current GitHub conventions), nor wind up with the situation of bug reporters you couldn't contact for more info, you couldn't turn if off.)
_hardwaregeek 7y ago
I attended Racket School and I genuinely want to like Racket. It has utterly fantastic language oriented features like macros and syntax objects, really awesome people behind it and some surprisingly solid tooling. But it's just so hard to do anything "useful" in it. It's the Haskell problem. It's too fancy, too nice to do any nitty gritty work with it. It's a gilded shovel. Writing something as banal as a web server in Racket just seems like a waste. And anything "nice" enough to write in Racket is too niche to really gather wide appeal. Compare this to Ruby, which, while not super popular, has gained a respectable following after a period of hype. Ruby can trick people into thinking that it's a nice, normal scripting language that you can show your parents. And you can treat Ruby as a normal scripting language. Only after a period does Ruby reveal its insane metaprogramming and dynamic features. What I'm saying is Racket needs a little more stupidity in it. It needs to project an image of a good ol' language that you can have a beer with. That you can write a web app in. If that requires removing s-expressions, then fine. If that requires removing conceptual purity, then fine. Racket certainly still has potential. There's quite a lot of DSLs in modern programming. Whether it's the adhoc configuration based DSLs of Docker and DevOps in general (I hate Docker's weird pseudolanguage so so much), or GraphQL in web servers, there's definitely places for Racket to shine. It just needs to get sullied by the messy, imperfect, stupidity that is industry.
- michaelmrose 7y ago
  I don't think you made a remotely adequate case for getting rid of s expressions nor even a good explanation of what changes you think ought to happen. What does it mean to make the language stupider? Ruby is popular because of rails. I don't think the making racket stupider or more familiar will create an analogous scenario to ruby and rails.
  - _hardwaregeek 7y ago
    Fair enough. I didn't really explain that. I'd start with deemphasizing Dr. Racket. Sure it's great and all, but most people aren't gonna use special IDE for your language. They want to use VSCode or whatever. Besides I can't think of a single good experience I've had with a language that encourages using its own custom IDE. Next, start building good interops. If you can figure out a way to get Racket to interop with JS, then boom, you suddenly have access to all of the JS ecosystem. Does this potentially create issues in your type system? Yeah, probably. Does the JS ecosystem kinda suck? Yeah, but people use it. Right now Racket doesn't have a great package ecosystem, so stealing packages from other languages is probably the next best thing. Ruby is popular because DHH was having enough fun in Ruby to build a web framework and get shit done with it. Do you think DHH could have done that in Racket? I'm not so sure. Making a language worse just means killing your darlings. Language designers tend to be very smart and into very interesting, very powerful, but very hard to understand features. Which can be great in small doses. But if your language's idiomatic style relies on said interesting, very powerful but hard to understand features, you're a little screwed when you try to teach people cough monads. Making a language worse means moving off these really amazing features and onto slightly worse, but easier to understand features.
ansible 7y ago
As a programming language dilletante, who has poked around in most interesting languages and dipped into many communities, a major syntax change seems like a very bad idea. That said, if you're going to get rid of parens, look at Haskell. It is actually a very Lisp-y language, where the parens are mostly optional.

95 points by spraak 7y ago

But in the last 60 years, simply grabbing these dissenters by the lapels and fumigating them with the stinky garlic breath of parenthesized S-expressions has not been a winning strategy.If Lisp partisans want different results in the next 60 years, we need to try something new. Given the rapid increase in programmers across the globe, I'd bet on there being more LISP programmers now than at any other time in human history. So why the obsession with popularity?

catach 7y ago
> So why the obsession with popularity? One reason could be altruism. If you believe your tool is superior to the tools that most others are using you may be highly motivated to convince those people to upgrade. Another reason could be that higher popularity leads to more jobs.
- neilv 7y ago
  Another is that practice relevance (adoption) is a factor in some research grants/funding. There's also adoption of their CS education programs, like HtDP, when clear industry relevance is one of the factors for some. I suppose that attracting students to the professors' own universities, at least undergrads, might also be a factor, though I haven't heard anything about that one.
JadeNB 7y ago
> Given the rapid increase in programmers across the globe, I'd bet on there being more LISP programmers now than at any other time in human history. So why the obsession with popularity? I think that there's a difference between a concern with popularity, which this article demonstrates, and an obsession with popularity, which may afflict parts of the Lisp community (not LISP any more, at least in most dialects) but isn't clearly demonstrated here. If quantitative popularity is important at all, then surely it is percentages and not absolute numbers that are most important (e.g., in 2016, Hillary Clinton got more votes in Texas than in Delaware—15 times more!—but that's not the relevant number). Even if quantitative popularity isn't important, surely some basic level of popularity is to be desired by fans of the language; and it must continually be renewed, not taken for granted. Note that more than the popularity of the language as a practical tool is at stake here; the article specifically talks about the declining popularity of Lisp as a teaching language, and, whatever language you use later in your hacking career, it's a shame to embark on that career not having been exposed to the ideas of Lisp (although, to be fair, those ideas have disseminated so much into the mainstream that many of them can be at least as easily found outside of Lisp as inside it).
jchw 7y ago
Because popularity is relative. Languages and frameworks benefit strongly from popularity because they are more likely to be well-supported and have thriving ecosystems the more popular they are. I'd say it is fairly healthy to be concerned about a language's popularity when talking about its future.
JasonFruit 7y ago
I don't know why this is such an unpopular comment. 5000 users today is the same number of people as 5000 users in 1970, even if there are way more potential users now. We can be pretty pleased that there are a bunch of people who are getting the productivity, fun, and education Lisp can provide, even if we might wish it had a higher percentage of users.
- lacampbell 7y ago
  I don't know why this is such an unpopular comment. HN can be a weird place. There's a lot of good discussion to be had. But the passive-aggressiveness and walking-on-eggshells behaviour required to not be greyed out into oblivion can be a bit much. It reminds me of visiting my childhood friends that had super strict parents - can't watch the simpsons, in bed at 7, etc etc. Always wondering what they might be upset by. I might go back to lurking. I'm a bad 'cultural fit'!
  - karmakaze 7y ago
    Making wholehearted, rational, unpopular comments is one of my fave HN things to do.
  - dTal 7y ago
    In my experience there is almost always an easily identifiable reason for a post being downvoted, and it's usually a good one. It's very avoidable if you engage your brain into "do not offend" mode before posting, which I find quite a positive habit to develop in other areas of life as well. In the case of your comment, the downvotes can be traced to your use of the unnecessarily negative word "obsession". You implied that people who want Lisp to be more popular are mentally unbalanced, even though this is a quite understandable thing to want. And you must admit that your reasoning is, at the very least, quite arguable, and warranted a greater tone of humility. Insults derived from dubious reasoning are a surefire recipe for downvotes. If you had concluded your post with "so it doesn't appear all that important to me for Lisp to be popular in an absolute sense" I think you would have been fine.
    - 7y ago
protomyth 7y ago
The sad truth from a corporate / enterprise perspective, popularity (or perceived popularity) means safety and checklist fulfillment. Management knows it can find people to plug into its empty slots, and HR has a easy thing to look for on the resume. People like comfort and safety. Now, you could say you are a startup and need the advantage. Good, you can do it, but you might have to supply more code to fill the gaps and deployment might require some extra knowledge (ecosystem problems). Its a value judgement as developer productivity isn't the only part of your development. Still, you can have a heck of an advantage. Look no further than the founder of this board, but remember the second part of the story. The Lisp got rewritten because it wasn't a comfortable choice for the new owners. Perceived popularity means comfort and ecosystem.
- neilv 7y ago
  Exactly. I've been arguing this for awhile. I'd go more specific than startups, to narrow in on those who are doing something unusual, such that they know they'll have to implement nontrivial stuff from scratch, no matter what language and off-the-shelf libraries/frameworks they use. That's one of the places that Racket can be a win. Related to that, I've also been trying to get people to stop saying "batteries included", because that's misleading, and sends the wrong message about what the actual relative strengths are. In practice, I suspect the initial startup adoption will largely be chance/serendipity, until there's at least one great startup success story, to interest and inspire confidence in other startup efforts. (I have one great success story, which was due to such serendipity, but it's a non-public system, and I've been milking that one way too long already in promoting Racket.)

sigwinch28 7y ago

A talk about rebuilding Racket is being given tomorrow (Monday 19th August) at ICFP'19 (10:30am local Berlin time): https://icfp19.sigplan.org/details/icfp-2019-papers/1/Rebuilding-Racket-on-Chez-Scheme-Experience-Report- https://icfp19.sigplan.org/details/icfp-2019-papers/1/Rebuil... This should be live-streamed, with online Q&A: https://icfp19.sigplan.org/attending/Remote+participation https://icfp19.sigplan.org/attending/Remote+participation

disconcision 7y ago
To clarify, this talk is about racket-on-chez, a chez-scheme-based rebuild of the racket compiler, which is live now (but optional) as of racket 7.4. This is entirely separate from 'racket2', a loose term for a variety of breaking changes which are beginning to be considered, prompted by matt flatt's state of racket talk at last month's racketcon.
- tux1968 7y ago
  To save a google search for anyone else interested in watching his talk: https://youtu.be/dnz6y5U0tFs?t=392 https://youtu.be/dnz6y5U0tFs?t=392

xixixao 7y ago

I love reading these ideas, similar in "otherwordliness" to Rich Hickey's, but the silent majority goes against them. Giving every programmer the ability to create a language of their own does not work out well. (similarly, on Rich's ideas, having library authors forever support old implementations to avoid breaking clients does not work out in reality) The truth seems to be closer to having to endure the constant pain of rewrites and reimplementions, imperfect abstractions and systems, that slowly etch us towards some shitty golden medium, something everyone hates but everyone agrees is the best we could come up with so far. The next iteration of that is most likely not gonna come from something completely different, genius, but from something just slightly different, slightly better.

didibus 7y ago
Rich's idea is not to forever support old implementation's, but to never mutate an existing one in a breaking way. In the Clojure community, that's actually been working pretty well, and you seldom have to deal with the kind of rewrites other languages forces upon you.
sigstoat 7y ago
> Giving every programmer the ability to create a language of their own does not work out well. they've already got that ability. it just results in languages which can't interoperate. and it takes them a lot of effort to get a garbage result. i suppose that "[it] does not work out well" is a reasonable description of the current situation. maybe you're actually arguing _for_ racket!

acbart 7y ago

One of the biggest problems is that these language designers, who want to design an "idealized" language, continue to make big decisions without regards to any kind of actual data collection. I just had the chance to meet and talk with Andreas Stefik, who summarized the utter and embarrassing lack of research by the PL community about actual language usability[1]. I'm not exactly jumping into line to adopt his evidence-based language "Quorum", but thank goodness that someone cares enough to do actual HCI research instead of just arguing theoretical merits. My own history and feelings about Racket are with regards to its connections with the controversial "Program by Design" curriculum - feelings that are both complicated and narrow (all revolving around introductory computing contexts). But I certainly resonate with this quote from the article: "But in the last 60 years, simply grabbing these dissenters by the lapels and fumigating them with the stinky garlic breath of parenthesized S-expressions has not been a winning strategy. If Lisp partisans want different results in the next 60 years, we need to try something new." [1] https://quorumlanguage.com/evidence.html https://quorumlanguage.com/evidence.html

didibus 7y ago
I'm big on evidence based, but I'm also not sure I believe evidence can be adequately demonstrated. The PL used is a tool for the programmer. If you take other disciplines, has their ever been proper evidence that some tools are better then others for any practice? What knife a chef chooses to use, what design a F1 car incorporates, etc. It seems a lot of it depends on the practitioner's style and symbiosis. Most evidence based research into PL seems very inadequate, and I'm not sure we'll ever have good experiments. How do you measure the language over its level of mastery? Certain novice somewhat being more productive or making less bugs on trivial programs in beginner contexts doesn't tell you much. Also, the very clear PL improvements have mostly been universally adopted. Lexical scopes for example, if/else conditionals, procedures, runtime types, GCs, dependency managers, unit and integ tests, etc. It's only the insignificant details which are often debated. And for those, I think it becomes much more a decision to be made by masters, like your favourite chef knife, you pick what best fits your style and maximises your own productivity while minimizing your own weaknesses.
fouric 7y ago

traderjane 7y ago

> Of course, it’s the core team’s prerogative to run the project as they wish. The rest of us are, after all, freeloaders. But procedural transparency isn’t just a mechanism for gathering community feedback, nor is it bureaucratic foofaraw. It’s also a tool for convincing users, especially industry adopters, that Racket has procedures and values that are worthy of time & money commitments—that there is a “rule of law” that guides outcomes. > I may be a visible user and fan of Racket—and even a teacher at Racket School—but I don’t have any influence on the direction of Racket. I think the Racket community is now big enough, however, that pulling off this kind of major change in Racket requires a stronger procedural foundation. The absence of this foundation is, in this fan’s opinion, a greater risk to the success of Racket2 than any technical hurdle.

neilv 7y ago
I disagree with that quoted bit about freeloaders. A lot of people have invested a lot of time and energy to building Racket and the community, over close to 20 years. I fully agree with the bits about transparency, and would add to that... The best outcome I can imagine from the recent would be if the leadership articulates unambiguously what I've been calling the "top-level requirements" that guide everything else in Racket. (I have a pretty good guess at the top-level requirements thus far, based on history. I'm also pretty sure that much of the user community still has mistaken ideas about that. Another reason for articulating these top-level requirements is that they might be changing now, as it seems a few things are changing.) After the top-level requirements, as a guide and to also let people know where they stand, then it would be good to have a well-considered model for whatever input (and possibly decision-making) is wanted from the non-leadership.

liability 7y ago

LOP is cool and interesting, but I'm much more interested in a "batteries included" scheme dialect. Is there another language with devs more aligned to that interest?

_emacsomancer_ 7y ago
I think Racket is probably a good bet for a 'batteries included' Scheme dialect (and I think rather than Racket2, including more batteries would attract more people to Racket, but I digress...) - it has good crossplatform GUI options, for instance.
- liability 7y ago
  Yeah, I've been using racket/gui a lot and it would be a real drag to use GTK ffi bullshit or whatever instead.
neilv 7y ago
I wouldn't say "batteries included" about any of them, by comparison to Python. Some to look at: Racket, Guile, Gambit, Chicken, Bigloo, Scheme48 (and Scsh).
- peatmoss 7y ago
  I’ve been looking at Gerbil lately, which seems to add some creature comforts, has some opinionated views, and is built atop Gambit: https://cons.io/ https://cons.io/
  - neilv 7y ago
    I think that one was started by vyzo, and I'm happy to see it with ongoing git activity. I'll have to take a closer look. vyzo previously contributed to Racket (then called PLT Scheme): http://planet.racket-lang.org/display.ss?owner=vyzo http://planet.racket-lang.org/display.ss?owner=vyzo (PLaneT is the nice earlier package system. The current one is "https://pkgs.racket-lang.org/" https://pkgs.racket-lang.org/", but I think vyzo had left by then, or at that time. I should mention: I wouldn't read much into the Open Tickets on that page not having action -- tickets were a feature someone added without some prominent package authors even knowing about it, at a time when authors were expecting to be emailed, so it could be sadly counterproductive. Even if you did eventually learn it existed and people were posting tickets, but didn't want to keep checking and using a Web site (this was before current GitHub conventions), nor wind up with the situation of bug reporters you couldn't contact for more info, you couldn't turn if off.)

_hardwaregeek 7y ago

I attended Racket School and I genuinely want to like Racket. It has utterly fantastic language oriented features like macros and syntax objects, really awesome people behind it and some surprisingly solid tooling. But it's just so hard to do anything "useful" in it. It's the Haskell problem. It's too fancy, too nice to do any nitty gritty work with it. It's a gilded shovel. Writing something as banal as a web server in Racket just seems like a waste. And anything "nice" enough to write in Racket is too niche to really gather wide appeal. Compare this to Ruby, which, while not super popular, has gained a respectable following after a period of hype. Ruby can trick people into thinking that it's a nice, normal scripting language that you can show your parents. And you can treat Ruby as a normal scripting language. Only after a period does Ruby reveal its insane metaprogramming and dynamic features. What I'm saying is Racket needs a little more stupidity in it. It needs to project an image of a good ol' language that you can have a beer with. That you can write a web app in. If that requires removing s-expressions, then fine. If that requires removing conceptual purity, then fine. Racket certainly still has potential. There's quite a lot of DSLs in modern programming. Whether it's the adhoc configuration based DSLs of Docker and DevOps in general (I hate Docker's weird pseudolanguage so so much), or GraphQL in web servers, there's definitely places for Racket to shine. It just needs to get sullied by the messy, imperfect, stupidity that is industry.

michaelmrose 7y ago
I don't think you made a remotely adequate case for getting rid of s expressions nor even a good explanation of what changes you think ought to happen. What does it mean to make the language stupider? Ruby is popular because of rails. I don't think the making racket stupider or more familiar will create an analogous scenario to ruby and rails.
- _hardwaregeek 7y ago
  Fair enough. I didn't really explain that. I'd start with deemphasizing Dr. Racket. Sure it's great and all, but most people aren't gonna use special IDE for your language. They want to use VSCode or whatever. Besides I can't think of a single good experience I've had with a language that encourages using its own custom IDE. Next, start building good interops. If you can figure out a way to get Racket to interop with JS, then boom, you suddenly have access to all of the JS ecosystem. Does this potentially create issues in your type system? Yeah, probably. Does the JS ecosystem kinda suck? Yeah, but people use it. Right now Racket doesn't have a great package ecosystem, so stealing packages from other languages is probably the next best thing. Ruby is popular because DHH was having enough fun in Ruby to build a web framework and get shit done with it. Do you think DHH could have done that in Racket? I'm not so sure. Making a language worse just means killing your darlings. Language designers tend to be very smart and into very interesting, very powerful, but very hard to understand features. Which can be great in small doses. But if your language's idiomatic style relies on said interesting, very powerful but hard to understand features, you're a little screwed when you try to teach people cough monads. Making a language worse means moving off these really amazing features and onto slightly worse, but easier to understand features.

ansible 7y ago

As a programming language dilletante, who has poked around in most interesting languages and dipped into many communities, a major syntax change seems like a very bad idea. That said, if you're going to get rid of parens, look at Haskell. It is actually a very Lisp-y language, where the parens are mostly optional.