-
Notifications
You must be signed in to change notification settings - Fork 2
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
Conversation
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
Thanks! |
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?