[rust-dev] on quality & success

Gaetan gaetan at xeberon.net
Thu Jan 2 07:09:48 PST 2014

I also agree this thread doesn't add grist to the mill. Let's cut it.


2014/1/2 Palmer Cox <palmercox at gmail.com>

> Everyone is entitled to their own opinions. However, those opinions should
> be expressed in a polite manner. Phrases such as "Choice he (since its
> mostly men)" and "mentally masturbate" do not seem to foster a welcoming,
> inclusive environment. Quoting from
> https://github.com/mozilla/rust/wiki/Note-development-policy#conduct:
> * We are committed to providing a friendly, safe and welcoming
> environment for all, regardless of gender, sexual orientation, disability,
> ethnicity, religion, or similar personal characteristic
> Thanks,
> -Palmer Cox
> On Tue, Dec 31, 2013 at 6:56 AM, spir <denis.spir at gmail.com> wrote:
>> Holà!
>> [This is a rather personal and involved post. Press del if you feel like
>> it...]
>> [also, it is long]
>> [copy to rust-dev mailing list: actually the post is inspired by a thread
>> there "Thoughts on the Rust Roadmap"]
>> There is a point obvious to me; apparently most people including many
>> language designers don't share it, or act as if they did not:
>>     a language should be successful iff it is of high quality
>> A kind of symmetric statement also holds;
>>     let us hope low quality languages have no success!
>> There are various reasons to hope this, the most stupid beeing that
>> successful languages influence others, present & future. This is in my view
>> a symptom of our civilisation's funny spirit (read: madness), and related
>> to the actual points I intend to state (if, for once, I manage to express
>> my thought).
>> Apparently, many language designers proceed more or less the following
>> way: there are a few key points (for them) they consider mis-designed or
>> missing or wrong in some way in existing languages (not all the same for
>> every language). Thus, they want to make a language that repairs these
>> points, all together. Then, certainly in fear that too many changes may
>> repel potential adopters of their language, in hope to maximise its chances
>> of success *despite* it breaking habits on the key points more important to
>> them, they won't change anything else, or only the bare minimum they can.
>> They want instead to remain as mainstream as possible on everything else.
>> [4]
>> I consider this spirit bad; I mean, very bad. This is the way basic
>> design errors propagate from successful languages to others, for instance.
>> [1] Apparently, it takes a great dose of courage to break any existing
>> practice in a _new_ language: tell me why, I do not understand.
>> Note that I am here talking of wrong design points in the opinion of a
>> given language designer. Choices he (since it's mostly men) would not do if
>> programming were a new field, open to all explorations. (There are indeed
>> loads of subjective or ideological design points; see also [1] & [3])
>> However, while programming is not a new field anymore, it is indeed open to
>> all explorations, for you, for me, if you or me wants it. Nothing blocks us
>> but our own bloackages, our own fears, and, probably, wrong rationales,
>> perhaps non-fully-conscious ones.
>> Deciding to reuse wrong, but mainstream, design decisions in one's own
>> language is deciding to intentionally make it of lower quality. !!! Funny
>> (read: mad), isn't it? It is thus also intentionally deciding to make it
>> not worth success. This, apparently, to make its actual chances of success
>> higher. (Isn't our culture funny?)
>> Then, why does one _actually_ make a new language? For the joy of making
>> something good? To contribute to a better world, since languages and
>> programming are a common good? [2] For the joy of offering something of as
>> high a quality as humanly possible? Else, why? For fame, honour, status,
>> money, power? To mentally masturbate on the idea of having made something
>> "sucessful" (sic!)?
>> We are not in need of yet another language trying, or pretending, to
>> improve on a handful of disparate points, leaving all the rest as is,
>> meaning in bad state. And, as an example, we are not in need of yet another
>> failed trial for a successor to C as major low-level lang.
>> Differences, thought of by their designer as significant quality
>> improvements, are the *reasons* for programmers to adopt a new language.
>> There are the _only_ (good) reasons to do so. Thinking that programmers may
>> adopt a new language _despite_ its differences is thinking backwards; this,
>> in addition to preventing oneself from working for the common good; by
>> fear, probably; fear of truely thinking by oneself and/or of making one's
>> true thinking public truely. (I can understand that, however: I often do
>> not disclose my thinking by fear of the terrible level of violence, in my
>> view, present in the programming "community" [hum!], and among geeks in
>> general. This, rather than sharing and mutual help and cooperation, for the
>> common wealth. Our civilisation... again.)
>> I have recently decided to adopt possible differences even if i am not
>> that convinced of their betterness; to give alternatives a try; to give
>> them at least a chance to show us (or just me) how good they actually are,
>> or not, in practice, maybe on the long term [3].
>> This may go too far; it is a personal decision.
>> However, deciding not to change what one sees wrong is weird for the
>> least. It means removing points of quality according to one's own views,
>> removing chances to contrbute to a better world, removing sources of
>> personal satisfaction, removing reasons for others to judge a language
>> better, thus removing motivation for programmers to adopt it. Maybe,
>> certainly, many programmers do not adopt a language on the base of its
>> quality, only; however, this counts; people I wish would adopt my lang, if
>> ever, are those people who judge first on quality, not hype followers or
>> otherwise conservatives.
>> What I mean is, apart from working against the common wealth, in addition
>> to preventing one's own enjoyment of doing what one does, such an attitude
>> may also work against a language's potential success. Is this (a factor)
>> why we have no successor to C yet, what do you think? because most
>> designers kept most of its design bugs unchanged? [4] just to have a
>> minimal chance, should a potential successor instead break as much as
>> possible? (And not have a builtin interface to C? ???)
>> Also note that attitudes and spirits are psycho-sociologically
>> contagious. In particular, fear and lack of courage and angst are highly
>> contagious (in our world, with such a close to universal high level of
>> anxiety...) What if more (would-be) language designers boldly thought by
>> themselves and boldly assumed their thoughts?
>> Final note: isn't it weird that such conformism is _that_ prevalent among
>> language designers? Precisely the ones who should be bearers of novelty?
>> the one "milieu" which could & should be a network of interacting
>> counter-cultures and individual iconoclasts (idol breakers)?
>> I do not expect anyone shares (all of) this. I just hope it may open new
>> ways of thinking or questionning to a few.
>> Denis
>> [1] Including the funny usage of "=" for assignment and "==" for
>> equality, after at least 5 decades, lol! Still my favorite syntactic error
>> after dozens of thousands of hours of programming in languages which nearly
>> all use this amusing convention. Why not use "if" to mean 'try' or 'switch'
>> or 'foreach', and "ifif" to mean 'if'? What do you think?
>> [2] Actually, they are both communal and social. Better quality languages
>> may contribute to a better world, at a communal level because we
>> programmers share code and read others' code all the time, and at a social
>> level because apps are a significant part of the world's state.
>> [3] As you certainly know, it takes time to unlearn, especially to stop
>> judging something bad while it is just different. (Think at C programmers
>> and their beloved code block {} braces. I for one have better usage for
>> brace ;-.)
>> [4] As an anecdote, somewhat complementary, in the course of my
>> explorations about programming languages, I often stepped on lists of C
>> design bugs, at least a dozen of them. Typically endless lists that take a
>> quarter of an hour to read in one go, without comments. There is space to
>> works for a language lover :-). If not enough, usually such critics seems
>> to agree on more than half of the points (and the remaining ones may not
>> figure on some lists just because the critic not think at it or did not
>> study this point) (but their solutions may diverge...).
>> _______________________________________________
>> Rust-dev mailing list
>> Rust-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140102/fab41107/attachment-0001.html>

More information about the Rust-dev mailing list