on reducing barriers in the Racket community

[Matthew Butterick]

I'm not a member of Racket management. But I spend a lot of time using & promoting Racket. Most recently, I taught the Beautiful Racket Workshop as part of Racket Week 2019.

I care a lot about Racket — the technology, but especially the human community that makes it possible.

I've heard from a few people that events before, during, or after Racket Week left them questioning Racket's commitment to making everyone feel welcome. And to be honest, it wasn't the first time.

This saddens me. It's not consistent with my own values. It's not what I want Racket to stand for. I want everyone to feel welcome, wanted, and valued.

In a nearby thread, Matthew Flatt talked about the importance of "reducing barriers" in a technical sense. But it matters in a community sense too, of course.

If Racket is putting up social barriers — even unwittingly — that are frustrating newcomers (or existing members) then we ought to be able to hear this with an open mind & heart, and make adjustments. This is our duty as empathetic, moral members of a community.

I'm not sure what I can do to improve this situation. I'm open to suggestions. I can at least offer the following (I would rather risk looking foolish than doing nothing):


1) If you've had an experience where the Racket community made you feel less than totally welcomed, I invite you to add it to this thread, or contact me privately. If you want details of your story shared, in some anonymized way, I can do that.

I recognize the irony of making this offer on the racket-users mailing list — those who've had a bad experience are likely long gone. But I also know there are people here who, like me, want to help make Racket better, even on rough days.


2) Gently, I suggest that we work together to reduce the volatility of these conversations. I know that some feel that these matters are better handled away from the racket-users list. But this is counterproductive: it amounts to saying that we should feel free to harvest the benefits of Racket-the-technology while avoiding obligations to Racket-the-community. As a matter of logic and ethics, I can't see how they are divisible.


3) Today, I'm a reasonably well-adjusted adult (or at least my dog thinks so). But a long time ago, I was a fat and dorky and smart kid. For years, I was physically and verbally bullied at school. It was relentless and terrifying. But as was true for a lot of kids like me during that era, computers were a refuge. They never judged me. They rewarded my curiosity.

I mention this not to put my experience on a footing with anyone else's. But it reminds me that while our contributions to Racket may be public, what Racket MEANS to each of us is necessarily private. Right now, there are people in our community for whom Racket is a bright spot in difficult times. If you haven't been there yet — you will.

To my mind, discussing these matters openly is about preserving the paramount virtue of a community based on sharing knowledge: to accept everyone just as they are. When we're falling short in this regard, we shouldn't avoid these facts, lest we make a virtue of ignorance. Or if we can't do this, and people bypass Racket in preference to other communities, then we'll have no one to blame but ourselves.

With much gratitude to everyone who makes Racket possible.

[Stephen De Gabrielle]

Thank you.

S.

--
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/8964B1F7-C0A5-44BA-AFE3-FF87E038F3CE%40mbtype.com.

--

----

[Dexter Lagan]

First I’d like to express my immense gratitude for your contributions to the Racket community. Beautiful Racket greatly enhanced my understanding of language-oriented programming and macros in general.

TL;DR: Racket is the most inspiring language and ecosystem I have ever used. I use it not just because it does the job, but because I’m having an absolute blast writing code in it, something that hasn’t happened to me since uhh.. x86 macro-assembler, or Pascal. All it needs is a simpler, localized, more practical intro page for existing programmers, and lots of promotion. Oh and maybe more speed, but it’s fast enough for my use.

Now, the wall of text:

From my perspective the only barrier of entry to Racket is the documentation: it is very clear, detailed and well-written, but to certain of my students they can also be quite obscure, especially to those who don’t have comp-sci background and those whose first language isn’t English. The best example is the few pages about continuations. For quite a while I could not understand what they were about from the Racket docs, and it took quite a bit of web crawling to find meaningful examples of their use. I also found the pages about macros lacking simple examples, and it’s not until Beautiful Racket that I finally found very basic uses.

My opinion doesn’t count for much, but from my experience and the feedback I got from my employees and students, the main Racket site and docs is missing a very basic presentation of the language. Something really clear, concise, that does not use comp-sci or advanced vocabulary. The best example that comes to my mind is say, Go’s tour pages - in 20 languages. I understand there is Matthew’s Quick Introduction on the main page, but somehow I’m imagining a smaller, quicker ‘batteries included’, practical intro, for programmers familiar with other languages :

1) how to read/write from/to a file
2) how to display text on the screen
3) how to use conditionals and loops
4) how to write a function
5) how to compile functions into modules

The hyperpolyglot.org/lisp ultra concise, parallel presentation of languages helped me more than once make sense of a new language. If only Racket had something similar for say, C, Java, Python and Racket. That way Python and Java programmers (perhaps Racket’s main target in the production env) could get a very quick sense of how things work.

Localisation would also go a long way towards bringing Racket to the world. I’m currently in France and Racket is completely unknown here, yet sorely needed when I see the slow-motion Java disaster going on in every engineering school and every company.

Dex

[Caleb Allen]

As an additional data point, I can share my very fast introduction into Racket and the community. You asked for experiences where the community may have made people feel unwelcome, but mine is a positive experience. I share it to perhaps give an angle of what is right, and the parts of the racket community which helped me go from an "outsider" to feeling welcome and secure. My brief experience with this community has been wonderful, and I want to contribute to making that experience the norm, if it is not already.

A few short months ago I came across The Little Schemer as recommended by a mentor of mine, and in my subsequent Scheme research came across your Racket Con videos on Pollen. Your enthusiasm made me feel okay about being enthusiastic myself! I watched a dozen or so Racket Con talks from as many speakers. Seeing how enthusiastic and dynamic the speakers were showed me that it was the entire community, not any single person, pushing this forward with passion and care. This apparent diversity of people and opinion was in stark contrast to many of the language communities I'd studied or participated in up to this point, which I'm sure you could guess.

As others have alluded to, the documentation might have intimidated me (as any documentation for a new language does), and my foray was instead through video. When I landed on the racket homepage and saw that Racket Week was just weeks away in my own city of Salt Lake, I knew I'd have to go, despite my uneasiness. For context, I attended the University of Utah in parallel with an internship at a startup, but dropped out after two years to go full time at the startup. In light of that decision I was nervous about being back on campus among academics I admired, and I questioned whether I was really qualified to even attend.

Each day of Racket Week put me more at ease, as I found mutual interests with other attendees and had interesting conversations that continued after the week was up. During introductions on day one (in the LOP course), I took note of people I'd like to pester about interesting things, and the conversations during off-time and meals had me stumbling into some of the coolest projects, ideas and passions I've ever heard. The week, for me, was a resounding success, and I hope to be integrating myself further into the community as the months and years go by.

From my perspective, the nature of the language itself may have been the biggest intimidating factor: there is a long history of very, very smart people who are very passionate about pushing this forward. Nobody enjoys making a fool of themselves and my biggest worry was asking a stupid question or being too unfamiliar with tooling. From the technical perspective, DrRacket did more for me as a gentle (but powerful) introduction to Racket than anything else I've used with any language. When I did encounter problems, the documentation and its ease of access from DrRacket made my previous documentation experience feel like reading a thesaurus, when I really wanted an encyclopedia. Racket's tooling is in a league of its own in terms of usability, and it was not a factor in deterring me.

I'd echo Dexter's sentiment to add some practical, hard examples somewhere, aimed at users of C like languages. I'm convinced of the power of LOP now that I've gotten the full context from Matthias during Racket Week and I will be using it extensively. But documentation of macros and building my own language was difficult to reason about on my early encounters, when I was still fighting the urge to slap curly braces somewhere in my code. I don't know how that gets solved, because Racket's power was both its draw as well as what intimidated me.

I may have been lucky in being in the right place at the right time, but I wanted to voice my appreciation for what has been done so far. I heard about Racket was less than two months ago and now I feel more enthusiastic than I have since learning TI-Basic on my TI-84 and sharing games with my friends in high school. This experience wasn't without a good dose of anxiety, but making friends in the community made all the difference.

Caleb

[Brian Adkins]

On Monday, July 22, 2019 at 1:07:21 PM UTC-4, Caleb Allen wrote:

As an additional data point, I can share my very fast introduction into Racket and the community. You asked for experiences where the community may have made people feel unwelcome, but mine is a positive experience. I share it to perhaps give an angle of what is right, and the parts of the racket community which helped me go from an "outsider" to feeling welcome and secure. My brief experience with this community has been wonderful, and I want to contribute to making that experience the norm, if it is not already. [...]

Thanks for articulating your thoughts so well Caleb.

Although my recent comments have probably focused more on technical aspects, the Racket community was *very* high on my priority list when I was looking for my next language. I was appreciative of answers I received to questions on the mailing list and/or IRC channel, and it was clear that top contributors were (and are) willing to take the time to deal with my newbie questions, and that, in turn, inspired me to want to get to the point where I could give back in a similar fashion (not quite there yet!).

From *my* perspective, the Racket community has good *and* long track record, and I don't expect the current *hiccup* to change that :) And, if others have unfortunately had a worse experience, my sense is that we as a community are motivated to change that.

[Neil Van Dyke]

Matthew Butterick wrote on 7/21/19 4:46 PM:

> But as was true for a lot of kids like me during that era, computers were a refuge. They never judged me. They rewarded my curiosity.

There's a complementary acceptance component to the microcomputer&online
revolutions, which I think are relevant to Racket/tech community
inclusiveness...

As people first started to get online, and find social-heavy topical
interest circles, it disproportionately attracted people who were
diverse in ways that weren't accepted as much in "real life".

For example, in some techie social circles, that we knew of, there were
quite a lot of people who were eventually open online about being gay
(when that wasn't OK where they lived), or being transgender (before
most of society even knew that existed), and it was fine -- whether
people were there for the topic/socializing alone, or because they felt
drawn to an Island of Misfit Toys themselves.

Right now, most of the world is running software some of those people
helped write, when society didn't accept them at the time. And one of
them, a person who seemed to have a bit of anxiety, and perhaps was
socializing online because of that, turned out to start a groundbreaking
technology most of the world is now using.  Another one, who was a very
nerdy girl who sought out other nerds, has since become a celebrated
entrepreneur you've probably heard of.  And another woman, who was a
serious math nerd, who is currently giving tech industry conference
talks on big things.  And people all over the world, including at least
one who later turned out to be nobility in their original country, but
was somewhat restricted due to being female.  (Younger people with early
online access were often children of university employees or computer
industry people, or of wealthy classes who could go all-out on the
child's home computer, mixed in with adult computer nerds.)  And one
child actor would occasionally drop by one group, as a typical nerdy
computer kid in real life, before most people could Tweet at
celebrities' PR personae.  Fortunately, for parochial me, everyone spoke
English.

There was also not yet things like Facebook presences (perpetuating
primary/high school looks/popularity contests well into adulthood), so
we often didn't even know what people looked like, and just took people
on the merits of what they said.  Which resulted in some funny
revelations, like the person you visualized like another stereotypical
computer nerd, who turned out to be very conventionally attractive and
charismatic (and who, of course, became an executive at a prominent
dotcom).  Or the exceptionally kind and thoughtful person, who it turned
out looked like what one might've thought (with one's real-world
prejudices and stereotypes) was some scruffy metalhead.  (Which makes me
think contemporary social media would be healthier and more beneficial,
if people didn't post photos of themselves, compete for "influencer"
funding, etc.)

Today, now that I'm in my 40s, it turns out that half of the American
techies I socialize with frequently identify as some flavor of
conservative -- which I would've found alarming years ago (I identify as
very liberal/progressive, in the American sense).  One, for example, is
very smart and thoughtful, seems like a great family person, and seems
implicitly totally comfortable with gay/trans/whatever, but will
frequently rant about what he sees as progressive grandstanding in the
news.  I still don't agree with him on a lot of what's a problem and
needs to be said in society right now, and what doesn't, but it turns
out that conservatives overall are not so bad.

In pre-"social media" online, we sometimes made mistakes (including
inadvertently being very unwelcoming in some ways, including by myself
sometimes, I'm still embarrassed to recall), and of course there are
always human conflicts and dramas, but we learned a lot about what
communities can be, and that a lot of dumb real-world prejudices outside
our community exist, and don't have to be that way.

[Jérôme Martin]

Thank you very much Matthew and Neil for those refreshing write-ups!

I'm really glad to see the question of inclusion, diversity (not the politically charged American meaning), and overall well-being in an mostly online community.

DISCLAIMER: Please take what I'm going to say with a distance. It might be shocking for some, or politically inclined/incorrect for some. I am dedicated in fighting racism and sexism in my life and everything written down below is oriented toward that goal.

In my personal life, I'm involved a lot into improving the inclusion of women, black people and other often excluded communities into the technology field.

From my experience, I'd say one of the most important point is not saying "we are open, just come", but showing it through visual and overall public communication.

Examples:

- Show the faces of speakers in conferences, in which we can clearly see that some are black, some are women..etc

- Explicitly create some Racket events/workshops dedicated to women (this is NOT so called "reverse sexism", please)

- This is more of a personal feeling, but I think embracing functional programming as "a more feminine way" (because you let the program flow naturally) compared to "imperative programming" (which sound very masculine, in control, by shouting orders to a computer) can also be a way to show Racket is different.

My point is: Since our society is inherently biased and unequal, simply saying you are open is not enough. To really counterbalance the inequality, we need to *actively* reach a different audience.

I know some of you don't agree with that because it feels "political". It feels like Racket is taking side in a fight. But everything in life, especially big human communities, are inherently political, whether they want it or not. If we don't side for women, for black people, for excluded people, we automatically side for the dominators.

This is my personal point of view, it has been stated now as an advice in the direction I personally feel is right for any community trying to improve its diversity. You are now free to throw stones at me and happily share your disagreement.

I am a thousand times thankful for all that the Racket community has achieved so far. Thank you for making the best language in the world, not only for it's technological background, but especially for it's community and the values of freedom of speech and expression it promotes.

I look forward to seeing this community grow and I am happy to be a part of it.

Jérôme

[Atlas Atlas]

1. To increase inclusiveness of some group of people, you educate people from this group on the subject of lisp racket computer science etc.

2. By lowering "barriers" you just welcome someone who doesn't care for the project and ruining community from inside.

3. By making a show about what project is NOT, you lying to people you want to attract, and insult people who are already in the project.

4. The is no possible reason to counterbalance the inequality, people a not equal, from the moment of conception. Society must acknowledge this inequality and build hierarchy of competence.

If you want to help uneducated people - educate them. This is the only way to fight poverty unemployment and other social problems.

IT communities never was biased on gender and skin color, by "fighting" imaginary unfairness you insulting every single programmer in the world. And actually creating ground for real racism and chauvinism.

When I first watched RacketCon videos I was surprised by diversity of people interested in Racket, this is wonderful people united by they passion, and not they genitalia or skin color problems. This is how it should be. So I don't think racketeers need such kind of help.

I think that optimization must begin from slowest parts, so, there is highly chauvinistic IT corporation like Google Apple Amazon, they desperately need such kind of help.

I believe that all social justice forces must be immediately thrown at this Real Big problems. You will be able to cure millions of small projects as Racket when you get rid of the main problems in Google and Amazon.

среда, 24 июля 2019 г., 12:00:32 UTC+3 пользователь Jérôme Martin написал:

[Matthew Butterick]

Mr. Atlas, since this seems to be only your second contribution to the racket-users list (the first was yesterday) I'm reluctant to impute much weight to your views, since I can't verify that there's a sincere human behind them. 

In any case, I can agree with you on the value of education. But the idea that lowering barriers is equivalent to "ruining community", "lying to people", and "insult[ing] people who are already in the project" — no, I don't agree, and those ideas are inconsistent with everything I've learned about how Racket operates.

[Atlas Atlas]

I never said that lowering barriers is lying or insulting.

I say that lowering barriers by lying (by making an impression instead of a reality demonstration) is really bad way to go.

If there is actual barriers, the work must be putted to improve on them, and not to improve on showing that this barriers don't exist.

There is also some barriers that you newer should break, for example people must be actually interested in writing computer programs in some way at least.

And regarding to this message must(this is just my opinion) be clear - "we welcome anyone who want to learn".

- "This is how Racket looks like" 

- "This is how community looks like"

- "This is how contribution is happening"

- "This is main people behind the project"

Openness is helping a lot.

People clearly can see when what showed to them is real deal or marketing.

I really like RacketCon videos in this regard, they a honest. And honesty is the way to build social relations.

Unfortunately, I cannot up this discussion to scientific proof level because this is not practical for me (It takes big

effort for me to write in English).

And perhaps will be impropriety thing to do.

My personal wish is to see some way to internationalize Racket...

If someone will want to translate site or documentation to other languages, what it might look like?

четверг, 25 июля 2019 г., 20:02:01 UTC+3 пользователь Matthew Butterick написал:

[Neil Van Dyke]

Atlas, I will have to think more about your message, but I think you're
right to suggest that FAANGs might be part of a problem.  For example,
see yesterday's outreach email from a FAANG (quoted at end of this
email), posted as an apparent diversity initiative, to students of a
big-name CS department, inviting them to a "10-week workshop series", to
prep for (IMHO: submit to, and game by playing to the metrics) the
company's recruiting hazing process and supposed metrics.

(Such hazing processes were not a thing when I got my first software
engineering internship, before FAANGs.  Perhaps coincidentally, half the
engineers at my internship were women, and they were all highly-skilled
and accomplished, doing impressive things, and had the same prestigious
responsibilities and recognition as the men did (though executive,
marketing, and field sales were very different stories, unfortunately). 
Later, in grad school, in a "gender issues in CS" interest group, I
learned there were some problems other places.  Then I started to see
various kinds of unwelcoming and barriers in academia, after I switched
universities (regrettably, moving from a school known for being
warm-fuzzy, to one known for egos and sharp elbows).  At the start of
dotcoms, the only software company I recall being known for things like
puzzle interviews was also the company that was later most cited by
female interns for sexism among employees.  Just at that time, the
dotcom gold rush started, and IPO-driven VCs and 20yo founders seemed to
institute brogramming culture.  It seemed a Californian veneer variation
on the infamous 1980s coked-up Wall Street culture, which needed
aggressive worker drones for their earlier version of dotcoms' "move
fast and break things" -- which has turned out to be a euphemism for
grabbing money and power, by being the most irresponsible. Fortunately,
individuals are better than the aggressive worker drones some companies
have seemed to want, but individuals can only do so much about a
top-down culture, so I'm criticizing the companies here, not the
individuals trapped in it.)

In what I see as some degree of contrast, the Racket community overall
(including at the top) seems to care genuinely about being thoughtfully
constructive, we already have some diversity of perspectives (and some
of the talk, including my own, sometimes sounds unfamiliar, and maybe
wrong, to some others, perhaps *because* of that diversity), and I get
the impression we want more diversity.  Collectively and individually,
we still have many things to figure out, in how to welcome and support
people, but we seem to have genuine and good intentions, and have made
some progress already.  Still, I'm sure people can point to some
problems that are obvious to them, but that others of us (including
myself) didn't really notice or appreciate as much as we should.

Maybe Racket needs a better channel for talking about such things, and
figuring out how to get good movement on them.  Maybe starting with a
different email list, with some guidelines?


As possible "comic relief" (I try to have a sense of humor about
upsetting things), here's yesterday's FAANG hazing outreach:

> Want to boost your readiness for [Company] technical interviews?
>
> This Fall, we're expanding our Above & Beyond Computer Science (ABCS)
> program to Atlanta, Boston, New York City, San Francisco, and
> Washington D.C. to build a diverse pipeline of future software engineers.
>
> Participants collaborate with peers and [Company] software engineers
> in a 10-week workshop series to help increase their competitiveness
> for their coding interviews. You’ll gain in-depth and applied practice
> on common interview topics, learn interview best practices, and
> collect rigorous preparatory materials to unlock their full potential.
>
> Hear from one of our past participants:
>
> “The ABCS program gave me the extra nudge that I needed to strengthen
> my technical interview skills. The program was an absolute success and
> coincidentally, I will be starting at [Company] later this year as a
> Software Engineer Intern and I can directly say that it was a result
> from the lessons and valuable skills I learned at ABCS.” - Lauren L,
> ABCS Boston, 2018
>
> Last fall, 76% of our program participants landed competitive summer
> internships or jobs in tech.
>
> Are you ready to apply to a software engineering internship or
> full-time job and want to go above and beyond to set yourself up for
> success?
>
> Apply for an ABCS program near you: [...]

[Atlas Atlas]

It is crucial to understand that "lowering barriers" can mean different even opposite things.

You can lower barrier by helping someone to learn.

And you can actually "lower barrier" by diminishing the goal.

And when we talking about social interaction we must acknowledge that people a different, and the is at lest three ways to deal with this difference, respect it, try to make everyone the same, or respect only some differences of some groups.

For example men in general more aggressive then women, they also pursue different social goals. You cannot ignore this, or blame the men for what they are. You also cannot ignore the fact that people in general driven by their sexuality.

My personal answer, first step after nip off violence is to educate people on their differences so they can build respect for each other.

But this is not of course task for programming language community, it is just something that must be taken in to account.

And teaching is whole another problem.

1. For different people learning something takes different effort, sometimes crucially different.

So different people require different teaching approaches. And the metric is more complex then just easy/hard duality.

But even this simple metric emerge a lot of problems.

2. Some people unable to learn some things no matter how hard they try.

So the goal must be described in honest way. So people do not build false expectations.

четверг, 25 июля 2019 г., 20:51:01 UTC+3 пользователь Atlas Atlas написал:

[Atlas Atlas]

If we want more women, or any other group of people, involved in Racket,

the only way to achieve this is to explain to this groups of people why do they need Racket.

(And openness and honesty is a great way to do it)

And try to answer this question for ourselves.

What Racket can offer to this social group?

And if there is no answer, then perhaps no point in marketing something that this group of people does not need or want.

What my experience says, any social groups based on general similarities(gender, skin color) as a groups interested not in many things at all.

They also act very aggressive not so to other groups but to individuals of any king.

Because individual is what conceptually opposes to any group.

And I honestly believe that it is individuals who are interested in Racket.

It is individuals to whom Racket can offer something.

Therefore, I believe that to individuals we need advertise Racket, not to groups.

Individuals may face different barriers, but I imagine very rarely associated with they gender.

The main barrier is they a not yet a part of Racketeers group, if we a talking about community.

It is crucial for small projects to have place where newbies can go, ask silly questions, write stupid things, and get wise guidance.

And mailing list is something that younger generation even don't know to exist.

So it will be nice to have at least community forum in this regard.

четверг, 25 июля 2019 г., 21:10:49 UTC+3 пользователь Neil Van Dyke написал:

[Mike G.]

On Thu, Jul 25, 2019 at 02:10:44PM -0400, Neil Van Dyke wrote:
> Atlas, I will have to think more about your message, but I think you're

> right to suggest that FAANGs might be part of a problem....

Perhaps I'm the only one, but I had no idea what "FAANG" meant. For similar folks:

"FAANG is an acronym for the market's five most popular and best-performing tech stocks, namely Facebook, Apple, Amazon, Netflix and Alphabet’s Google."

https://www.investopedia.com/terms/f/faang-stocks.asp
--
READ CAREFULLY. By accepting this material, you agree, on behalf of your
employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with
your employer, its partners, licensors, agents and assigns, in perpetuity,
without prejudice to my ongoing rights and privileges. You further
represent that you have the authority to release me from any BOGUS
AGREEMENTS on behalf of your employer.

[Jérôme Martin]

On Thursday, July 25, 2019 at 9:39:08 PM UTC+2, Atlas Atlas wrote:
> For example men in general more aggressive then women, they also pursue different social goals. You cannot ignore this, or blame the men for what they are. You also cannot ignore the fact that people in general driven by their sexuality.

This kind of idea is the heart of the problem I'm trying to highlight.
Recent (and old) studies show that considering men and women as having different motivations driven by their gender is false and was created by most modern societies as a way to justify social differences by finding a fake reason in "the laws of nature".

In the beginning of IT, writing computer programs was considered a low value job and was assigned to women (as always). Then men started to realize that it might be an important task after all, and got rid of women as soon as they found out it was some kind of "engineering", therefore a highest valued job. Barriers were closed, women were left behind.

If a woman wants to work in IT today, she has to:
- Work twice as hard
- Let men get the rewards from her work
- Bear with the fact that every time she says something in a meeting, a man will repeat it and get more traction
- If she has a blog or a social media account, bear with sexual harassment and rape threats every single day
- Bear with more aggressive code reviews
- Accept to earn less money and don't get promoted
- Be told that she was not able to "seize opportunities"

When a woman tough enough to cope with this comes into an open source community.. guess what?
She faces the same issues!

After having experienced all that, will she accept to be told that "it's natural", that "men and women have different social goals", that "people are driven by their sexuality" ?
I'm a man, but I couldn't accept that if it happened to me. I couldn't accept to see the violence perpetuated on me justified by my gender and some kind of "law of nature".

I got into IT because I love programming and solving problems. But I must never forget that I got here easily because I'm a man. I must accept that I benefited from some kind of artificial privilege.
This is not a blame on me, but a responsibility I must take to make sure that I can help people who don't benefit from such privilege.

This is why saying "look, we are open" will never be enough.
Companies which say they are "open" are the same which say that they fired this woman because "she didn't fit well", "she didn't have the right spirit", "she didn't come to after-work parties because she can't take jokes".
"Look, it's not our fault, she is the one not being open enough".

Enough of this, please.

Racket is one of the communities in which I feel the most at home, because of threads like this one. Because people actually take the time to think about what we are doing collectively and question our direction every day.
I am confident in Racket to be the perfect community to experiment new ways of being an open source community. I am confident in Racket to be exactly the playing grounds in which we can differentiate ourselves from the classic white-male-tech-bro culture that is commonly found in every open source groups.

I am NOT trying to make this community restricted to such or such minority group. Everyone is welcome. But we need to acknowledge that even if we welcome everyone, we don't welcome people with the same story, the same background, the same culture.
We tend to think that everyone who come here are by default "a smart guy who like lisp languages and has comfortable income". We need to shift from that lens to a broader one. We need to accept that some people might come here with memories of rape threats and bad racist jokes. We need to understand that there is no "one-size-fits-all" way to welcome people in a community.

I'd like some parts of the Racket ecosystem to involve women, some part of Racket to involve black people...etc
This is in no way a restriction, but an evolution. There is enough room for all of us.

Black women programmers are already there. They are just told everywhere they go that they don't "seize opportunity".
If we can be the first open source community to prevent that, we can be the best open source community that ever was.

Some links to go further (I recommend this wiki to anyone trying to get more insight about this issue):
- https://geekfeminism.wikia.org/wiki/Women-friendly_events
- https://geekfeminism.wikia.org/wiki/Promotion_to_women
- https://geekfeminism.wikia.org/wiki/Women-friendly_forums

[Hendrik Boom]

On Fri, Jul 26, 2019 at 02:59:03AM -0700, Jérôme Martin wrote:
> On Thursday, July 25, 2019 at 9:39:08 PM UTC+2, Atlas Atlas wrote:
> > For example men in general more aggressive then women, they also pursue
> different social goals. You cannot ignore this, or blame the men for what
> they are. You also cannot ignore the fact that people in general driven by
> their sexuality.
>
>
> This kind of idea is the heart of the problem I'm trying to highlight.
> Recent (and old) studies show that considering men and women as having
> different motivations driven by their gender is false and was created by
> most modern societies as a way to justify social differences by finding a
> fake reason in "the laws of nature".

There are significant differences between man and women, and between
their interests, driven by societh ane evolution.

But they are statistical differences and should never be considered
when dealing with individuals. Many of the variations within groups
are greater than the variations between groups. You have to judge
individuals as individuals, ane not as average members of a group.
Certainly this is so for variations in those aptitudes related to
the use of Scheme.

>
> In the beginning of IT, writing computer programs was considered a low
> value job and was assigned to women (as always).

This was so in the 1950's.

Then men started to
> realize that it might be an important task after all, and got rid of women
> as soon as they found out it was some kind of "engineering", therefore a
> highest valued job. Barriers were closed, women were left behind.

By the 1960's women in computing were relegated to being typists.

>
> If a woman wants to work in IT today, she has to:
> - Work twice as hard
> - Let men get the rewards from her work
> - Bear with the fact that every time she says something in a meeting, a man
> will repeat it and get more traction
> - If she has a blog or a social media account, bear with sexual harassment
> and rape threats every single day
> - Bear with more aggressive code reviews
> - Accept to earn less money and don't get promoted
> - Be told that she was not able to "seize opportunities"
>
> When a woman tough enough to cope with this comes into an open source
> community.. guess what?
> She faces the same issues!

Unless she disguises herself by using a male or gender-ambiguous name.
Online existence by itself doesn't reveal her gender.
She shouldn't have to do this.

...
...

>
> Enough of this, please.

Sad, but currently true. The last thing we should do is to try to
become more "inclusive" by appealing to stereotypes. We can instead
treat everyone based on the merit of technical contributions and
questions, and curtail attacks based on the usual list of
prejudices.

-- hendrik

[Liwei Chou]

Dexter Lagan於 2019年7月22日星期一 UTC+8下午4時52分42秒寫道

  From my perspective the only barrier of entry to Racket is the documentation: it is very clear, detailed and well-written, but to certain of my students they can also be quite obscure, especially to those who don’t have comp-sci background and those whose first language isn’t English. The best example is the few pages about continuations. For quite a while I could not understand what they were about from the Racket docs, and it took quite a bit of web crawling to find meaningful examples of their use. I also found the pages about macros lacking simple examples, and it’s not until Beautiful Racket that I finally found very basic uses.

I agree with Dexter's opinion about documentation.

I was reading "The Racket Guide" and found it too verbose for a newcomer with some programming experience. Then I discovered "Teach Yourself Racket", which is easy to read and I'm really enjoy.

https://cs.uwaterloo.ca/~plragde/flaneries/TYR/

I strongly recommend to include "Teach Yourself Racket" in the beginner's guide section of Racket 's official website. Or produce some more materials like that.

Another aspect is about the tooling.

Stephen helpful forwarded my feedback here.
https://groups.google.com/d/msg/racket-users/PftpYnJt49c/2abSsQOYAgAJ

I just quote here. A little bit about my journey as a newbie.

When I started to learn Racket, due to the slow startup time and huge memory consumption of DrRacket, the overall impression given to me was that it’s very inefficient.

After done some micro-benchmark, it did show that it did not perform well, and It did make me hesitate. (barrier for beginners)

But I still want to try it, because I am very interested in its expressiveness. And I’m happy to find out it’s actually quite fast.

The micro-benchmark I ran is.

> (time (for ([i (in-range 10000000)])
          (void)))
cpu time: 115 real time: 115 gc time: 0

(Now I know it’s due to the debugging stuff...)

Turn out in DrRacket, it’s about 16x slower than in Racket REPL.

However, there isn't a convenient way to separate normal build/run from debug build/run, which conventional development environments usually do.

My point is, the impression of this language is not very efficient, which is bad, and will scare some people out. Which is a barrier also. It would be better if not the case.

[Dexter Lagan]

Hi Liwei,

  I believe disabling debugging and tracing does accelerate the evaluation quite a bit from inside DrRacket. On my system, it seems to be running my code at the same speed as the main racket binary.

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/140e226d-ed25-4aac-ae95-4f5f347bb3ba%40googlegroups.com.

[Liwei Chou]

Thanks Dexter,

Yes, now I know it’s due to the debugging and tracing configuration. After turn off debugging and profiling, it becomes.

cpu time: 20 real time: 20 gc time: 0

If disable Preserve stacktrace also, I got.

cpu time: 7 real time: 7 gc time: 0

Which is pretty decent, 16x acceleration.

It's not a problem for me now. However, this behavior may give some new users the wrong impression that the language may not be very efficient, which may make some people choose not to continue trying it.

From the perspective of increasing adoption and reducing barriers, it's not a good thing.

If Racket team can consider making normal run and debug run using different default settings, which conventional development environments usually do, that can easily solve this problem.

Dexter Lagan於 2020年4月25日星期六 UTC+8下午5時17分31秒寫道：

[Sorawee Porncharoenwase]

It could go either way, no? I've also heard a lot of people complaining that debugging Racket programs is difficult because the stack trace is not useful, and this is because they use the command-line version which doesn't have errortrace enabled (by default). 

Perhaps what you really are complaining is that the option to enable/disable errortrace is not easily discoverable. Would it help if at:

the text is changed from `racket, with debugging` to `racket, with debugging (slower)`. And the texts are linkified so that when `racket` is clicked, it leads you to the non-detailed language setting, and when `with debugging (slower)` is clicked, it leads you to the detailed language setting?

--

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/cb5e4fa5-2766-4242-aff5-8933bee637c6%40googlegroups.com.

[sleepnova]

That may help to reduce misimpression. And plus, maybe append some message to error message to inform user that they can turn on errortrace if they need more detailed debugging information, when errortrace doesn't enabled.

To be clarify, what you mentioned is "Preserve errortrace" option, what about "Debugging" option, is it a must enabled option in a non-debugging run?

Sorawee Porncharoenwase <sorawe...@gmail.com> 於 2020年4月25日 週六 下午8:17寫道：

--

- sleepnova

呼叫小黃創辦人 & CEO

[Gustavo Massaccesi]

I like the idea of adding a "with debugging" to the banner when a program is run in DrRacket, but I´m not sure it is possible. (It would be even better if the user can click it and go to the help page about the configuration of the language). But I'm not sure it is possible.

Another possibility is to have two "Run" buttons, a normal "Run" button and a "Run fast" button. The problem is that too many buttons make the UI confusing for beginners.

Gustavo

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CABa2-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%40mail.gmail.com.

[Sorawee Porncharoenwase]

I like the idea of adding a "with debugging" to the banner when a program is run in DrRacket, but I´m not sure it is possible.

It current exists already! The screenshot I attached above is from the actual DrRacket when debugging is enabled.

 

(It would be even better if the user can click it and go to the help page about the configuration of the language). But I'm not sure it is possible.

Right, and that's my proposal. Make it a link, put the word "slow" there to draw attention. I think it would be nice if the language configuration control is self-explanatory so that we don't need the help page.

 

Another possibility is to have two "Run" buttons, a normal "Run" button and a "Run fast" button. The problem is that too many buttons make the UI confusing for beginners.

I considered this possibility too and reached the same conclusion. Also, I'm not sure if multiple "Run" buttons make sense for every language in Racket.

 

[Liwei Chou]

Similar discussion here.
https://groups.google.com/forum/#!topic/racket-users/WvThwc98kMU

Sorawee Porncharoenwase於 2020年4月26日星期日 UTC+8上午2時03分13秒寫道：

[Dexter Lagan]

  There’s one thing I noticed: if debugging is disabled, then parenthesis highlighting is also disabled (as well as other visual aids, if I remember well?). The editor also feels faster because of this, but navigating parentheses becomes slightly more tedious without it.

Dex

On Apr 25, 2020, at 3:25 PM, sleepnova <wanp...@gmail.com> wrote:



That may help to reduce misimpression. And plus, maybe append some message to error message to inform user that they can turn on errortrace if they need more detailed debugging information, when errortrace doesn't enabled.

To be clarify, what you mentioned is "Preserve errortrace" option, what about "Debugging" option, is it a must enabled option in a non-debugging run?

<截圖 2020-04-25 下午9.22.20.png>

Sorawee Porncharoenwase <sorawe...@gmail.com> 於 2020年4月25日 週六 下午8:17寫道：

It could go either way, no? I've also heard a lot of people complaining that debugging Racket programs is difficult because the stack trace is not useful, and this is because they use the command-line version which doesn't have errortrace enabled (by default). 

Perhaps what you really are complaining is that the option to enable/disable errortrace is not easily discoverable. Would it help if at:

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CABa2-7O1cv_sOrGRWxoHetdwDLiKLSOpZdt8T3YPj4yQQome7w%40mail.gmail.com.

[Hendrik Boom]

On Thu, Apr 30, 2020 at 09:36:15AM +0200, Dexter Lagan wrote:
> There’s one thing I noticed: if debugging is disabled, then parenthesis highlighting is also disabled (as well as other visual aids, if I remember well?). The editor also feels faster because of this, but navigating parentheses becomes slightly more tedious without it.

And that's exactly the parenthesis problem. For a language as
parenthesis-heavy as Scheme or Lisp, you need a
parenthesis-oriented editor. DrRacket does this very well bu
shading the background (but apparently not all the time). Emacs
does it too, in principle, but isn't reaally great at it.

I hate being at the mercy of whatever editor I'm stuck using.

I stongly recommend that we get a language with less of a
parenthesis problem so that code is readable without having to haul
it into a specialised editor.

It is possible to do this without creating a hugely complicated and
unintuitive syntax for the language! We don't need to savage
the language to accomplish this!

One thing that greatly mitigates parentheses without affecting the
semantic of the language or the syntax (much) is the equivalent of
tail-recursion for parenthesis nesting. It the last component of a
list is itself a list, instead of enclosing it in parentheses, you
just put a prefix in front it it.

In an old List I used '/' for this, so i got expressions like
(if a b / if c d / let s t /if s foo bar)

Let no longer needs its heavy bracket structure because it's easy
to chain let's without parenthesis nesting. Wimilaarly, cond
itself become unnecessry, and it's easy to chain ifs, lets, and so
forth.

Of course '/' is already taken in Racket; as is the also natural
';'.

There must be some # code we could use for this (I believe one
has already been mentioned on this list sometime in the past year
os so) but this symbol tends to become *so* prevalent that it
should ideally feel like a single character with a dostinctieve
apearance.

Actual parentheses becoma *startlingly* sparser.
And language constructions whose primary purpose seems to be to
avoid nesting become mostly unnecessary.

(Still stuck with letrec though)

-- hendrik

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/71148F23-E424-4580-8CAB-DC40AA0B5D47%40gmail.com.

[George Neuner]

On Thu, 30 Apr 2020 11:16:10 -0400, Hendrik Boom
<hen...@topoi.pooq.com> wrote:

>I stongly recommend that we get a language with less of a
>parenthesis problem so that code is readable without having to haul
>it into a specialised editor.
>
>It is possible to do this without creating a hugely complicated and
>unintuitive syntax for the language! We don't need to savage
>the language to accomplish this!

ML and Haskell both look very similar to what you seem to want. So
does Python for that matter.

But it isn't possible to write integrated, reflexive macros in any of
those languages. They DO allow macros (of a sort), but their macros
have to be written using a different, more restrictive language ...
ie. you don't write an ML macro in ML, you write it in the subset
language M(acro)ML.

Consequently, macros are not used heavily in any of those languages.
And use of DSLs with those languages are rare.


If you look at the history of Lisp, you'll see that originally it was
intended to have a more conventional syntax: the S-expr parenthesis
laden syntax we still use was intended as a stopgap until the
conventional "M-expr" syntax could be implemented. But macros proved
to be very difficult to adapt to the M-expr syntax, and macros were so
important to Lisp that they caused McCarthy to abandon the idea of
M-exprs.

George

[David Storrs]

On Thu, Apr 30, 2020 at 11:16 AM Hendrik Boom <hen...@topoi.pooq.com> wrote:

On Thu, Apr 30, 2020 at 09:36:15AM +0200, Dexter Lagan wrote:
>   There’s one thing I noticed: if debugging is disabled, then parenthesis highlighting is also disabled (as well as other visual aids, if I remember well?). The editor also feels faster because of this, but navigating parentheses becomes slightly more tedious without it.

And that's exactly the parenthesis problem.  For a language as
parenthesis-heavy as Scheme or Lisp, you need a
parenthesis-oriented editor.  DrRacket does this very well bu
shading the background (but apparently not all the time).  Emacs
does it too, in principle, but isn't reaally great at it.

Not to minimize your experience but I'm speaking up simply as a counterpoint:  I haven't had this issue, even without Racket's equivalence between () [] and {}.

Also is there a programming editor that *won't* do parenthesis matching?

[Hendrik Boom]

Evidently the Racket editor whan debugging is disabled, if
understand Dexter Lagan correctly.

-- hendrik

[Sorawee Porncharoenwase]

I have debugging disabled, but my parenthesis highlighting is NOT disabled. Are we talking about the same parenthesis highlighting? Can you attach the screenshot of this "parenthesis highlighting is also disabled" to the mailing list?

[Dexter Lagan]

  I put my foot in my mouth again, it's working. I must have had something else disabled. I clearly remember not being able to make the cursor 'jump' around expressions.

Dex

[Stephen De Gabrielle]

On Thu, 30 Apr 2020 at 20:01, Hendrik Boom <hen...@topoi.pooq.com> wrote:

[...]

> Also is there a programming editor that *won't* do parenthesis matching?

Evidently the Racket editor whan debugging is disabled,

I’m not sure that’s true.

Kind regards

Stephen

--

----

[Dexter Lagan]

  No it’s not, I checked again and couldn’t reproduce the problem. Please ignore my earlier comment.

  I’ve been tracking a bug that causes the colouring of a part of the code as comment and disable parenthesis handling, and since I switch debugging on and off often, I assumed it was related. I’ll dig further and post the issue if I can find out what triggers it.

Dex

On Apr 30, 2020, at 10:06 PM, Stephen De Gabrielle <spdega...@gmail.com> wrote:



--

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/CAGHj7-K_AbF4jmakuSixjnY_rNwPCqYgrd-JSWOrKFjash1Cvg%40mail.gmail.com.

[Sorawee Porncharoenwase]

I hate being at the mercy of whatever editor I'm stuck using.

I agree with this in principle, but in practice, it's really a matter of what mainstream editors support. Editors in the past don't universally support automatic indentation, and I could imagine a criticism like "Indentation sucks, because I hate being at the mercy of whatever editor I'm stuck using." But now, automatic indentation is universal, and the criticism goes away.

 

I stongly recommend that we get a language with less of a
parenthesis problem so that code is readable without having to haul
it into a specialised editor.

Personally, I don't find parenthesis makes code unreadable by itself. The rightward drift, in my opinion, is the real problem. I believe that `define*` that I proposed at https://github.com/racket/rhombus-brainstorming/issues/46 will somewhat mitigate the problem.

In an old List I used '/' for this, so i got expressions like
   (if a b / if c d / let s t /if s foo bar)

Using `/` to reduce parentheses looks nice once it's written down, but my concern is that it might not be easily editable. In fact, it ironically looks like this notation needs an extra support from editors to consider `/` as a delimiter. 

To clarify what I mean: non S-exp languages usually have a line as a unit of code, so editors need to support "jump to the beginning/end of line"  to make editing pleasant. S-exp languages in contrast has a parenthesized expression as a unit of code, so editors need to support "jump to a matching parenthesis" to make editing pleasant. In your notation, it looks like editors need to also support "jump to closest /" to make editing pleasant.

Also, does it actually make code more readable? I guess I'm not accustomed to it, and might find it easier to read it once I am.

 

There must be some # code we could use for this (I believe one
has already been mentioned on this list sometime in the past year
os so) but this symbol tends to become *so* prevalent that it
should ideally feel like a single character with a dostinctieve
apearance.

This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

 

[George Neuner]

On 4/30/2020 5:40 PM, Sorawee Porncharoenwase wrote:

  :

To clarify what I mean: non S-exp languages usually have a line as a unit of code, so editors need to support "jump to the beginning/end of line"  to make editing pleasant.

Actually, in the majority of programming languages there is no connection between program source and line grouping in an editor.  Statement based languages define some character to be the statement "terminator" (or statement "separator" - yes, there is a semantic difference), but most often that character is the semi-colon, not   #\return or  #\linefeed.

Racket, like Scheme and Lisp, is expression based, NOT statement based, and it can't do the same (at least not easily) because expressions can be nested arbitrarily, and they can't be limited to a single line.

S-exp languages in contrast has a parenthesized expression as a unit of code, so editors need to support "jump to a matching parenthesis" to make editing pleasant. In your notation, it looks like editors need to also support "jump to closest /" to make editing pleasant.

Also, does it actually make code more readable? I guess I'm not accustomed to it, and might find it easier to read it once I am.

Once you use Racket (or Scheme or Lisp) long enough, you cease to see the parentheses and instead perceive the structure of the code from its indentation.  Most editors will happily match parentheses and many can understand Scheme structure enough to properly indent things.

George

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:40:00PM -0700, Sorawee Porncharoenwase wrote:
> >
> > I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.
>
>
> > I stongly recommend that we get a language with less of a
> > parenthesis problem so that code is readable without having to haul
> > it into a specialised editor.
> >
>
> Personally, I don't find parenthesis makes code unreadable by itself. The
> rightward drift, in my opinion, is the real problem. I believe that
> `define*` that I proposed at
> https://github.com/racket/rhombus-brainstorming/issues/46 will somewhat
> mitigate the problem.

Yes, rightward drift is one of the problems. That's why I introduced '/'
in a Lispish language I implemented decades ago.

>
> In an old List I used '/' for this, so i got expressions like
> > (if a b / if c d / let s t /if s foo bar)

If course this is a different let from the traditional, age-old one.

> >
>
> Using `/` to reduce parentheses looks nice once it's written down, but my
> concern is that it might not be easily editable. In fact, it ironically
> looks like this notation needs an extra support from editors to consider
> `/` as a delimiter.

Yes, of course. Whatever you use has to be ecognised as a delimiter.

>
> To clarify what I mean: non S-exp languages usually have a line as a unit
> of code, so editors need to support "jump to the beginning/end of line" to
> make editing pleasant. S-exp languages in contrast has a parenthesized
> expression as a unit of code, so editors need to support "jump to a
> matching parenthesis" to make editing pleasant. In your notation, it looks
> like editors need to also support "jump to closest /" to make editing
> pleasant.

In practise, you get things like

( if a (cadr foo)
/ if c
(d u / v w)
/ let s t
/ if s foo bar
)

>
> Also, does it actually make code more readable? I guess I'm not accustomed
> to it, and might find it easier to read it once I am.

I foud it so. Especially for large, complicared expressions involving
intermixed let's and if's.

Of course, I also adapted mu Lisp to make better advantage if the "/" syntax.

multiple let's just become tail-nested let's, without rightward drift.

(let a b
/let c a
/let e (f c)
/big expression incolving these
)

>
>
> > There must be some # code we could use for this (I believe one
> > has already been mentioned on this list sometime in the past year
> > os so) but this symbol tends to become *so* prevalent that it
> > should ideally feel like a single character with a dostinctieve
> > apearance.
> >
>
> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

That is lovely.

-- hendrik

[sleepnova]

Thanks for sharing. I see "Nested parentheses" only one way to represent tree structure. There are certainly other cleverer ways to do it. Once it appears, the representation of the tree transform (macro) may also be better. I'm looking forward to seeing better representation.

https://en.wikipedia.org/wiki/Tree_structure#Nested_parentheses

Sorawee Porncharoenwase <sorawe...@gmail.com> 於 2020年5月1日 週五 上午5:40寫道：

--

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/CADcuegsYr6KKeZg5sV1ocgcywnCTbi8rf_gB5_MiQG9%3D_W_cFQ%40mail.gmail.com.

[Hendrik Boom]

On Thu, Apr 30, 2020 at 02:40:00PM -0700, Sorawee Porncharoenwase wrote:
>

> This is Nia's parendown: https://docs.racket-lang.org/parendown/index.html

Just wondering: Is there a way to write division if Nia's parendown is in effect?
There would be no problem with this if it was originally designed into the language,
but language add-ons give the probem of syntax-versus-name confliicts.

-- hendrik

[Christopher Lemmer Webber]

Sorawee Porncharoenwase writes:

>>
>> I hate being at the mercy of whatever editor I'm stuck using.
>
>
> I agree with this in principle, but in practice, it's really a matter of
> what mainstream editors support. Editors in the past don't universally
> support automatic indentation, and I could imagine a criticism like
> "Indentation sucks, because I hate being at the mercy of whatever editor
> I'm stuck using." But now, automatic indentation is universal, and the
> criticism goes away.

You don't even need to imagine it... when Python was taking off, one of
the biggest arguments was that it forced people to learn to do
reasonable indentation. Doesn't seem like as much of a good argument
now as I thought it was then, and that's partly because most code is
indented fine these days due to, as you say, good IDE support.

[George Neuner]

I haven't followed all the discussion regarding a potential successor to
Racket.  AFAIHS, no one actually has suggested a required indentation
scheme ala Python, but since source indentation (and formatting in
general) currently is under discussion, I wanted to make known my
feelings on the matter.

If you don't feel strongly about source indentation, you can skip this.

George

The indentation requirement - aka "significant whitespace" - is one of
the main things I dislike about Python [the other is its comprehension
syntax].  An argument certainly can be made for advocating a readable
coding style ... but on principle I disagree with a language *requiring*
any particular style.


As it happens, I am old enough to remember when Fortran required very
particular formatting: worse even than Python, Fortran was designed
around 80-column punch cards, and for a VERY long time it was necessary
that particular things be placed in particular columns ... else the
statement would not compile.

    see https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

Fortran's adherence to rigid source formatting really did not simplify
the compiler much at all  (actually an argument can be made that it
unnecessarily complicated recognizing certain constructs). And if it
ever helped, it wasn't necessary for long - by 1962 [Fortran was
introduced in 1959] compilers were able to deal with free form code. 
The first version of Lisp [1961] was on punch cards as well, but from
the beginning Lisp never had column based restrictions on source format.

Fortran ... still recognizes the old style, but ... no longer requires
column based formatting.  Free form source has been supported by
compilers since Fortran90.

Historically, there have been a handful of (higher level, non-assembly)
languages that had odd source formatting requirements, but none were as
onerous as Fortran, and none of them survived very long.  But just as
Fortran finally was giving up on the idea, Python came along to revive
it.  [Python began at about the same time Fortran90 was in committee.]


Forcing programmers to do menial tasks like configuring editors to
certain modes [spaces vs tabs], and to manually count spaces when
corresponding scoped lines are too far apart to eyeball the vertical
alignment is simply counterproductive - there are plenty of more
important things that programmers should be worrying about. Programming
editors having language structural awareness have been around since the
80's ... there is no reason ever to bake such things as indentation
requirements into the language.

Just my 2 cents.

[Dexter Lagan]

  Is there value in Rob Pike’s comment on avoiding significant white space in the Go language?

“We have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code.” — Rob Pike, 2012

  I personally dislike white space and prefer either mustaches or parenthesis, just so I know my code will still work if line feeds are stripped somehow, or that some piece of code is embedded or quoted in another language, which is what I gather Rob was talking about. However, Haskell and Python people don’t seem to mind, and if it saves us more keystrokes while keeping expressiveness, why not?

Dex

On May 1, 2020, at 10:20 PM, George Neuner <gneu...@comcast.net> wrote:



--
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/e180703e-6e2e-ea6b-d918-b46ff4eebb07%40comcast.net.

[George Neuner]

On 5/1/2020 4:35 PM, Dexter Lagan wrote:

  Is there value in Rob Pike’s comment on avoiding significant white space in the Go language?

“We have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code.” — Rob Pike, 2012

I'm not really sure what Pike is getting at there:  I haven't used SWIG myself, but if I understand it correctly, Python code would have to be in a module to be called from "other" language code.  If so, I don't see how the indentation of the "other" code could affect the Python.

That aside:

Even working only in Python, programmers routinely get tripped up by copy/paste errors - so it is evident that indentation sensitivity is not any real solution to scope related logic problems.  It might [for some definition] help newbies identify stupid errors, but I believe that even moderately experienced programmers are more hindered than helped by it.

  I personally dislike white space and prefer either mustaches or parenthesis, just so I know my code will still work if line feeds are stripped somehow, or that some piece of code is embedded or quoted in another language, which is what I gather Rob was talking about. However, Haskell and Python people don’t seem to mind, and if it saves us more keystrokes while keeping expressiveness, why not?

Well, few people use Haskell, so I would discount it as a data point.  Even so, one of the tutorials includes this interesting tidbit:

With good text editor, programming is fun. Of course, you can get along with simplistic
editor capable of just cut-n-paste, but good editor is capable of doing most of the chores
for you, letting you concentrate on what you are writing. With respect to programming
in Haskell, good text editor should have as much as possible of the following features:

• Syntax highlighting for source files
• Indentation of source files
• Interaction with Haskell interpreter (be it Hugs or GHCi)
• Computer-aided code navigation
• Code completion

The implication is that Haskell is difficult to write without proper editor support.  So too is Python.  Decent syntax and structure aware editors are not really a problem any more, but they can go only so far:  they can fail spectacularly when code gets complicated and the language syntax provides no clues to figure out the scoping.

S-exprs do not suffer from this affliction.


Also mentioned previously is my concern that indentation sensitivity may make implementing macros as we enjoy them in Racket difficult.  Or maybe impossible.  Although certainly there are indentation languages which have macro facilities, I am not aware of any in which the macros can be written in the same language.  All the ones I know of implement a separate DSL macro language.

I have designed and implemented a few languages: including a Scheme-ish mostly functional language [but lacking macros].   I have not thought through all the nuances of implementing a language that can reflectively manipulate the structure of a program in the midst of compiling it  [or in the case of Lisp - running it].  However, I have to think there are reasons for existing indentation languages not having done so.

YMMV,
George

[Liwei Chou]

Any one consider this style? Minimizing visual interference while preserving parentheses. Even Java program can be written like Python.

https://www.quora.com/What-is-the-most-frustrating-thing-about-being-a-computer-programmer/answer/Jesse-Jaun

Though it's kind of like making fun with different coding style. There might be some inspiration for us.

gneuner2於 2020年5月2日星期六 UTC+8上午8時12分53秒寫道：

[Raoul Duke]

$0.02, whitespace sensitivity is just bad ux in the long run. haskell can get away with it more than python because haskell can be written more concisely i feel than python. but even in H it is sorta unfortunate. 

i like how iirc clojure uses sexprs but allows other kinds of parens, fairly arbitrarily. 

(foo '{2 3 4} '[a b c])

same thing as

(foo '(2 3 4) '(a b c))

so humans can make some parts stand out a little bit differently. 

[David Storrs]

Racket does the same thing. (), [], and {} are all equivalent as long as they match consistently. (i.e. you can't do '(] because that doesn't match consistently.)

--
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/CAJ7XQb67vFEX7D0hHOxJXVG6344ngYU1%3DtmmQ0m6%3DVijqODEQw%40mail.gmail.com.

[Dexter Lagan]

  For the sake of discussion, here’s a long rant:

  I might have a very uninformed opinion here, but wouldn’t having significant white space and no scope-defining character amount to multiple spaces and line feeds being part of the syntax? The next best thing being, allowing semicolons in place of line feeds. I’m no language designer, so let me try to give you my perspective as an average programmer:

  I find editing Python and Haskell a pain, because of white spaces. I can’t count the times I got that dreaded ‘invalid indentation’ error, because I’m editing code with a different editor on a different system. I also had to reformat entire programs after somebody saved using the incorrect tab setting, and I avoid Python because of this. Yet I haven’t heard this complaint from Python programmers, so I always believed I was just too dumb.

  I haven’t seen a better solution than s-expr to make expressions and scope ultra-visible and easy to manipulate. Yet s-expressions still bring their own requirements for comfortable editing: most people still require a specialized editor or a plugin for lisps. I fact, is there any language that doesn’t require some sort of plugin or specialized editor to be attractive to new programmers? Thinking of it, isn’t the IDE almost as important as the syntax or the language these days? Some JavaScript programmers can’t work without VSCode, scope-sensitive autocomplete, a linter and god knows how many other plugins. PHP programmers also feel naked without a fancy IDE and a host of plugins. I keep hearing people complain about x or y language because it doesn’t have a good editor, IDE or plugin for VSCode. Globally, people use more and more tools to program in the same languages.

  That’s what turned me into a sort of ‘digital minimalist’. I take comfort in not being dependant on anything other than a compiler/interpreter and a simple editor I can whip out of any system in seconds. I think there’s value in reducing our dependencies, including on tools, editors, IDEs and plugins. That being said, I love DrRacket and its facilities, also because it’s self-contained and bundled with Racket. One less thing to install.

  These are the considerations I’d take in account when thinking of a new syntax. Still, like I said before, I’m excited by the fact that the Racket team is looking for a solution to this problem, and I’ll be the first to applaud a way to keep the next Racket expressive and powerful, while making it more attractive to people used to more familiar syntax. Parentheses are, and always will be a barrier to entry for potential Racket adopters, and this is no small matter. I think Julia is a good example of the right balance between simple, attractive syntax and power. Are there downsides to their approach?

Cheers,

Dex

On May 2, 2020, at 2:12 AM, George Neuner <gneu...@comcast.net> wrote:



[Stephen De Gabrielle]

Quick question: Would it better if this discussion happened over at https://github.com/racket/rhombus-brainstorming/blob/master/resources/goals.md

or on the Racket Slack #rhombus channel?

I’m aware that email and slack is a bit ephemeral - it is probably a good idea to turn any proposals into RFC’s or issues at https://github.com/racket/rhombus-brainstorming - so they are not lost.

Kind regards
Stephen

[George Neuner]

On 5/2/2020 4:58 AM, Dexter Lagan wrote:
>   For the sake of discussion, here’s a long rant:
>
>   I might have a very uninformed opinion here, but wouldn’t having
> significant white space and no scope-defining character amount to
> multiple spaces and line feeds being part of the syntax? The next best
> thing being, allowing semicolons in place of line feeds. I’m no
> language designer, so let me try to give you my perspective as an
> average programmer:
>
>   I find editing Python and Haskell a pain, because of white spaces. I
> can’t count the times I got that dreaded ‘invalid indentation’ error,
> because I’m editing code with a different editor on a different
> system. I also had to reformat entire programs after somebody saved
> using the incorrect tab setting, and I avoid Python because of this.
> Yet I haven’t heard this complaint from Python programmers, so I
> always believed I was just too dumb.

Python is as much a cult as a programming language.

>   I haven’t seen a better solution than s-expr to make expressions and
> scope ultra-visible and easy to manipulate. Yet s-expressions still
> bring their own requirements for comfortable editing: most people
> still require a specialized editor or a plugin for lisps. I fact, is
> there any language that doesn’t require some sort of plugin or
> specialized editor to be attractive to new programmers? Thinking of
> it, isn’t the IDE almost as important as the syntax or the language
> these days?

For most languages, IDEs are mainly needed for debugging.  For just
editing, the majority of languages really don't need syntax or structure
awareness.  Syntax coloring is nice, but programmers got along fine
without it for ~50 years.

Most languages in use now have syntax based (however loosely) on C and
mostly are not WS sensitive.  The compiler doesn't care about how the
code is formatted:  there is a statement terminator (or separator [there
is a difference]) character that serves to keep the compiler
synchronized with the source.

In Pascal, you can write an entire program on a single edit line. In C
and C++, the preprocessor is line sensitive, so it isn't possible to
write a whole program in one line - but the mainline code is WS
indifferent, and you can write entire functions, or even multiple
functions, in one line.

But no one does that except in those competitions trying to pack a whole
program into 255 characters or less.

For most languages it is visual debugging: tracing and breaking
execution, probing runtime values, while seeing the source ... *that* is
where an IDE comes into its own.


S-expr languages are different in this respect because they are
expression based rather than statement based.  Expressions can be nested
arbitrarily, and it is more difficult to visually identify things
without some editor assistance like coloration, parenthesis matching,
and syntax directed indentation.

S-expr languages have long used - though not required - indentation as a
guide to visualize program structure.  When you program with Racket (or
Scheme or Lisp) for a while, you cease to see the parentheses and really
mostly see only the indentation structure.

For debugging: tracing and breaking S-expr code is more complicated to
*display* and interact with reasonably - the UI matters greatly to
programmer efficiency.  But the actual debugger internally is not really
much different from a debugger for a statement language - it's mostly
how the programmer interacts with it that needs to change.

> Some JavaScript programmers can’t work without VSCode, scope-sensitive
> autocomplete, a linter and god knows how many other plugins. PHP
> programmers also feel naked without a fancy IDE and a host of plugins.
> I keep hearing people complain about x or y language because it
> doesn’t have a good editor, IDE or plugin for VSCode. Globally, people
> use more and more tools to program in the same languages.

Programmers today are spoiled.  My first program was written on a
teletype connected by modem to a PDP-10 at some nearby college.  It took
half an hour to get a 10 line program working.

>   That’s what turned me into a sort of ‘digital minimalist’. I take
> comfort in not being dependant on anything other than a
> compiler/interpreter and a simple editor I can whip out of any system
> in seconds. I think there’s value in reducing our dependencies,
> including on tools, editors, IDEs and plugins. That being said, I love
> DrRacket and its facilities, also because it’s self-contained and
> bundled with Racket. One less thing to install.
>
>   These are the considerations I’d take in account when thinking of a
> new syntax. Still, like I said before, I’m excited by the fact that
> the Racket team is looking for a solution to this problem, and I’ll be
> the first to applaud a way to keep the next Racket expressive and
> powerful, while making it more attractive to people used to more
> familiar syntax. Parentheses are, and always will be a barrier to
> entry for potential Racket adopters, and this is no small matter. I
> think Julia is a good example of the right balance between simple,
> attractive syntax and power. Are there downsides to their approach?

Julia is interesting, but I confess, I don't know it as well as I
probably should.  It claims to have reflective macros, so that would
make it a data point in favor of a non-S-expr syntax.

But one thing I'm not a fan of is cluttering source with compiler
directives. Julia uses directives rather liberally to control threading,
and I find that distracting.  YMMV.


George

[Dexter Lagan]

Spoiled is an understatement. I wrote a lot of programs in debug (DOS). And it was nice! Turbo Pascal was what really spoiled me. :) I miss the in-line asm days.

Dex

> On May 3, 2020, at 9:46 PM, George Neuner <gneu...@comcast.net> wrote:
>
>