Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "project values" section #2

Merged
merged 1 commit into from
Apr 14, 2020
Merged

Add "project values" section #2

merged 1 commit into from
Apr 14, 2020

Conversation

hdgarrood
Copy link
Contributor

I've tried to distil points raised from discussion in #1, my own perspective, and also Phil's discourse post on the same topic into a set of project values which we can point contributors to to better set expectations and give people an idea of where the project is heading. What do people think of this?

I've tried to distil points raised from discussion in #1, my own perspective, and also Phil's [discourse post on the same topic](https://discourse.purescript.org/t/the-principles-of-purescript/163) into a set of project values which we can point contributors to to better set expectations and give people an idea of where the project is heading. What do people think of this?
@@ -8,6 +8,13 @@ The core PureScript GitHub organization exists to maintain and develop:
* Documentation
* Package Sets

# Project Values

- PureScript is industrially focused; it is not a vehicle for programming language research. Consequently, stability is a high priority. Feature requests which have a large impact on downstream code are unlikely to be accepted.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the "industrially focused" part of this statement as I think more people might actually decide to use this language rather than alternatives. At the same time, the rendering makes it also sound like PureScript might be trying to eventually become a "mainstream language," which often suffers from the problem of people wanting to dumb things down / stray from the mathematical roots of the language. Should this statement be updated to clarify this ambiguity / where core contributors stand on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t know; I don’t really like the framing of “dumbing things down”, I think it will be read as a jab at alternatives like, say, Elm, which is definitely not what I want. Elm or other alternatives might have a smaller language feature set, or an ecosystem more geared towards simpler code, or a quicker path to being productive coming from an imperative language, but I think that’s really just them solving a problem in a slightly different way and with a slightly different set of values than we are.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy with the phrasing of it as it is - I wouldn't have read it to imply anything other than what is said here. I guess you could drop the "industrially focused" part and just say it's not a research language / stability is valued, etc. but I don't interpret "industrially focused" as a synonym for "mainstream" or following "success at all costs", personally.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My general understanding for why Haskell has the "avoid (success at all costs)" motto is because it's trying to prevent people from making the language less powerful / expressive, which (in my understanding of what others say / what I infer from what I read in various places) tends to occur when languages become more mainstream. I guess the issue here is not with your rendering but with how that I read the meaning, 'mainstream,' into the word, 'industrial,' which is not what you meant. I'm not sure whether others would read it that way, too, or read it as Gary did.

I think it will be read as a jab at alternatives like, say, Elm, which is definitely not what I want.

Oh, that wasn't what I meant at all, but I can see how it could come off that way. I think Elm makes certain tradeoffs (e.g. less powerful type system in exchange for simpler clearer error messages and an easier learning curve) that are valid. I wouldn't want to make those tradeoffs.

@JordanMartinez
Copy link
Contributor

I think your rendering is a good summary of the core values I've seen communicated in various ways throughout my time in the community.

@hdgarrood
Copy link
Contributor Author

Thanks!

@hdgarrood hdgarrood merged commit 3a35247 into master Apr 14, 2020
@hdgarrood hdgarrood deleted the add-project-values branch April 14, 2020 16:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants