tenderlove has quit [Remote host closed the connection]
<ddd>
seacreature: only those with representation on the design council would be permitted to label their implementations as “Common Ruby compatible” sounds WAY too much like an elitist club, *and* its been tried before. Also, it just moves the rights Matz has (to call something 'ruby' regardless if anyone else agrees) to the council which is limited seating, and removes the responsibility to the masses from the council since its *jus
<drbrain>
ddd: you typed too much, cut off at "*jus"
<ddd>
it also serves to make ruby into a fiefdom. if you're not on the council, you don't have a voice, they're under no obligation to listen bcause well, anyone can just walk away or fork.
<ddd>
its *just* what *they* agree upon as ruby and the rest of the world has to take it. it also serves to make ruby into a fiefdom. if you're not on the council, you don't have a voice, they're under no obligation to listen bcause well, anyone can just walk away or fork.
<ddd>
--
BigO_ has quit [Remote host closed the connection]
<seacreature>
If everything you said was true about a council, then the certification would have no meaning
<seacreature>
So there's no danger of that
<seacreature>
I think it's very much reasonable to say "In order to get voting rights on what goes into this standard, you need to implement at least X% of this standard"
d-best is now known as d-snp
<seacreature>
If the council were too beaurocratic, too exclusive, or in any other way were not helpful, then they would cease to be relevant.
<seacreature>
The pressure flows both ways: implementations get to decide whether they care about compatibility with that label, and the council has the responsibility to be reasonable enough so that people *do* care
<ddd>
ok, i'll grant that. but what about where the council itself disagrees amongst itself as to what should or should not be in the standard to the point it stagnates. If the rule is if you don't like it walk, then that leaves people sitting at the table in a waiting game and the standard and ruby stagnates
<seacreature>
Ruby does not stagnate
<ddd>
then you've effectively damaged ruby leaving the 'power' to fix within the stagnant council itself.
<seacreature>
Ruby in my mind is MRI
<seacreature>
whether MRI is compatible with a design council's definition of a common language is only important if that definition is *useful*
<seacreature>
But it's very important to consider the fact that if you made a list of all the things various Ruby implementers, users, and other stakholders agree on vs. disagree on
<seacreature>
The former is several orders of magnitudes greater than that of the latter
<seacreature>
and a design council would only exist to draw the line in the sand between those two things
<ddd>
right, and in general i would agree with you that MRI *is* ruby. It was the first implementation. However, you're taking that away if for whatever reason MRI does not conform to the Common Ruby tag. So now his own invention is no longer 'Ruby'?
<ddd>
oh i see that, i'm playing devil's advocate here to some degree
<drbrain>
like any feature request, I'm skeptical if only the submitter thinks it's necessary
<seacreature>
Call it Peridot, or call it Yurb
<ddd>
now that to me, after discussion, is a good stance
<seacreature>
I don't care at all what you call it
<drbrain>
I'm doubly skeptical when there's a meeting the day before on the same topic and the submitter doesn't incorporate any of that feedback
<seacreature>
Common Ruby is just a nice label in my mind because it expresses to me that it's the Ruby in common among implementations.
<seacreature>
But if the issue is with the name and not the concept, give it a different name
<ddd>
no I understood what you meant by the tag
<ddd>
however, people also do use the tag as a Holy Grail it WILL conform to this or die
<seacreature>
I'm just suggesting that we focus the default target of RubySpec (and our compatibility metrics) to the intersection of what established implementers of Ruby agree on rather than whatever is on the bleeding edge of MRI
<ddd>
and oveer little things too. Look what Microsoft did with the CLR, C#, and other things. They used their marketing power to power things through, pulled behind the scenes pressure of sub members to get them to come to their side of the fence (and there will probably be businesses involved in this)
<ddd>
those types of things are what i would like to see avoided
<seacreature>
ddd: you're talking about really different environments though
<seacreature>
Our zone of agreement among implementations of Ruby is massive
<seacreature>
and all the important players are open source projects
<ddd>
only because we initially are more open. OK, take it closer to home. Look what RedHat which started opensource, is still to much of a degree, look what they tried to do with GCC
<ddd>
and the glibc
<seacreature>
I think that history is relevant but not prescriptive
<seacreature>
rather than dragging up old boogeymen, can we focus on the merits of the ideas presented now?
<ddd>
i just think that if we do implement the idea as you see it, seafeguards do need to be added
<ddd>
oh not trtying to bring in boogeymen. trying to draw parallels to potentials under that idea
<ddd>
thats all.
<seacreature>
So FWIW, when I say I agree with brixen's plan, what I mean is I think the broad strokes make sense to me
<ddd>
that we agree upon
<seacreature>
I'm agreeing that a design council is a good idea, that it doesn't necessarily need to be wide open (but it MUST be transparent and well defined)
<ddd>
the well defined is the 'devil in the details' issue though.
<seacreature>
and that design council should be responsible for defining the commonality between existing implementations
<seacreature>
Yes, and so I am looking at brixen's proposal as only a starting point for a discussion
<ddd>
and yes, i agree there has to be a line in the sand *somewhere* where the council makes directional choices, after all its comprised of the main implementers themselves
charliesome has quit [Ping timeout: 260 seconds]
<seacreature>
I just see this as a way of essentially releasing something as a gem before rolling it into core
<seacreature>
but as a process rather than a program
<seacreature>
We can talk about all the failures of the past, and naysay the fuck out of the future
<seacreature>
but that doesn't get us anywhere.
<ddd>
actually *that* we agree on. a 'trial by fire' i guess we could say?
<nurse>
What level of detail do you think? For example POSIX, SuS, W3C HTML/CSS, ECMAScript?
<nurse>
And how do you think implementation specific features
<seacreature>
nurse: I'm sorry, I wish I had more experience with language implementation to talk about that, I really only have experience with community building
<seacreature>
I feel like Common Ruby should be defined by RubySpec. Maybe start with everything that JRuby, Rubinius, and MRI are passing right now
<seacreature>
and then talk about adding, removing, and changing things from the "common" spec
<nurse>
Did you write rubyspec?
<seacreature>
I have made very small contributions to rubyspec
<seacreature>
so I'm only basing this idea on very limited knowledge
<ddd>
seacreature: i agree with that. since each implementation must/should pass rubyspec as it stands now, what it defines i would consider common if *all* implementations pass, and would like to see that spec itself be the 'living document' for ruby implementations current and future
<nurse>
A standard must define it content and limitation.
<seacreature>
ddd: My feeling is that we could compute the "common" core of Ruby right now, but we also need to define how things become "common"
<nurse>
For example ISO Ruby is a standard defined by council.
<ddd>
would you consider that a valid idea? (or an extension of your own?)
<seacreature>
I think right now the only core problem is that alternative implementers feel like while they can extend Ruby with implementation-specific features, they MUST implement MRI's features, whether they are good ideas or not
<ddd>
seacreature: number of requests in each implementation, independently?
<seacreature>
The process of marking some features as experimental is a good step forward in that sense
<seacreature>
but I'm thinking the benefit of a design council is that they'd treat all features as experimental until consensus was reached
<ddd>
distillation of feature requests down to the most commonly requested across *all* implementations, then codification of that into a working rough, with specs to define (i'll call red from TDD/BDD here) and fleshing out by the committie members?
<seacreature>
I feel like all of those issues are details that I'm not qualified to comment on
<ddd>
if thats how it works now, then I apologize as Im new to the process as well
<nurse>
On such process, when such request is widely usable?
<nurse>
after 1 year? 2yesrs?
<seacreature>
Or when it matters.
<seacreature>
For example, if people are okay with using refinements but knowing that they're not a cross-implementation feature, fine
<nurse>
For example C/C++, it is usable as standard after 10 years
<seacreature>
I think that's not so unreasonable, honestly
<seacreature>
We want two things that seem incompatible, but aren't necessarily
<seacreature>
we want Ruby to be able to change all the time, to keep evolving
carlosantonio has joined #ruby-core
<seacreature>
but we also want to be able to write software that can work across various implementations
<nurse>
yeah ruby is changing, must be changing
enebo has quit [Quit: enebo]
<seacreature>
It seems like by making a conservative "Common Ruby" definition, our definition of "Ruby" (as in MRI) can be very liberal
<seacreature>
Ruby can ship lots of features that are weird and experimental
<seacreature>
and they don't need to wait until Rubinius or JRuby or others agree
<nurse>
yes, portability is sacred
<seacreature>
But as someone weiting a library (say for example the Prawn PDF library)
<seacreature>
I want to be able to run any ruby implementation with a --common flag
<seacreature>
and see warnings or exceptions for the things that are implementation-specific
charliesome has joined #ruby-core
<seacreature>
so if my code uses refinements, I want to know that they aren't portable
<nurse>
Thinking web experience, such common flags will be ambiguous
<seacreature>
*without* having to go and read RubySpec
<seacreature>
But I'd also settle for a nice reporting feature on RubySpec, or a good style guide
<nurse>
Such inspectation should be done by validator.
<seacreature>
Yeah, that would be fine too!
<seacreature>
Another possible and simple idea:
<seacreature>
if Common Ruby did exist
<seacreature>
you could have a Common Ruby API documentation project
<seacreature>
and then each implementation would only need to document their non-standard features
<nurse>
A common Ruby specification is ISO/IEC 30170.
<seacreature>
nurse: I am aware the ISO spec exists
<nurse>
Of course I know it is not what you expect because it is too small.
<seacreature>
It's also was defined by MRI's core team and not the whole Ruby language community if I'm not mistaken
<seacreature>
We need a collaborative process, and a living standard
<seacreature>
not an ISO standard
<seacreature>
But the ISO spec probably gives us a useful starting point, combined with what is already passing on Rubinius, JRuby, and MRI via RubySpec
<nurse>
ISO spec is made by IPA (a standardize organization in Japan), not MRI team
<seacreature>
Okay, but that's even worse :-/
<nurse>
Some members of MRI are participated though
<seacreature>
My hope is that I want to see Ruby (as in MRI / ruby-core) experiment even more over the coming years, but I also want to be able to write a program that will run on JRuby and Rubinius without having to think hard.
<seacreature>
Without having to wait until those other implementations "catch up"
<seacreature>
I want Matz to be free to define Ruby however he wants, but I want to be able to write a "Rubyish" program that runs everywhere.
<nurse>
Brixen seems try to do it by preventing MRI development. (this sentence can be seen as FUD because of my poor English, but it is not what want to say...)
<drbrain>
nurse: I have a similar feeling
<seacreature>
That's what the proposal sounds like
<seacreature>
But we should think about what his *goal* is, and not just the implementation
<seacreature>
alternative implementers do not want to implement every idea that MRI implements, just to remain compatible
<seacreature>
authors of cross-implementation libraries do not want to think about whether or not each feature they use is supported by JRuby, Rubinius, MRI, etc.
<seacreature>
Matz does not want anyone to be in control of Ruby but him, and after two decades, who could blame him?
<seacreature>
MRI wants to be free to change and experiment because that is the heart of what Ruby has been about for all this time
<seacreature>
Is that an accurate summary?
<seacreature>
If so, then the solution I see is to realize there is some language (call it Foo), which all of these implementers agree is useful and good
<seacreature>
Right, well the problem right now is the formula looks like this
<charliesome>
there's a fine line between implementation specific behaviour and bugs
<seacreature>
Alternative = MRI + MRI.bugs + (Alternative Features)
<The_8472>
- not supported stuff
<seacreature>
right
<seacreature>
But Foo is a huge language! It's everything that we *aren't* fighting about, that all three big implementations have implemented
<nurse>
On the context of MRI, matz are persuated if everone but him object an idea.
<The_8472>
java, C, javascript, html... they're all maintained by standards bodies and multiple implementors. you can have implementation-specific features but they're explicitly marked so and you can usually enable a standards-compliance mode in some way or another.
<seacreature>
nurse: I think that matz being the dictator of Ruby is fine, and I think Matz is easily persuaded
<nurse>
For example "Changing nil.to_s as 'nil'" is flamed one, but he finally withdrew his idea
<nurse>
Not "easily" but when he reject an idea, the decision has reasonable at some amount
<charliesome>
please show me a language that is maintained by a standards body that evolves at a regular pace
<charliesome>
The_8472: java, c, javascript and html all evolve painfully slowly
<nurse>
C, C++, ECMAScript, Lisp, COBOL, and so on
<seacreature>
Right, because we're talking about standards rather than conventions
<The_8472>
charliesome, they have been around much longer
<charliesome>
The_8472: javascript is about as old as ruby
<nurse>
strictly to say, "JavaScript" is the lnaguage Mozilla implement
<seacreature>
Ruby wasn't designed by a committee
<seacreature>
it was designed by Matz, and has been developed for two decades
<seacreature>
There's a huge difference between a language born from a council, and a language subset that is defined by a council
<The_8472>
yeah, but how old is the second-oldest implementation?
<seacreature>
Um... JRuby was being worked on when I started working in Ruby
<seacreature>
which was in 2004
<charliesome>
jruby has been around sine 2002 iirc?
<seacreature>
We have three rich, mature implementations, with a huge amount of agreement between them
<seacreature>
but we spend a huge amount of time on the few things we disagree about
<seacreature>
I'd rather see the things we disagree about be tested in the real world, rather than discussed infinitely
<seacreature>
the way I see it is... say that Common Ruby already existed, and MRI implemented refinements and released them as part of Ruby 2.0
<The_8472>
if MRI implements it for "real world testing", then everyone is soon forced to implement it too if it's a popular feature
<seacreature>
Fine... later on, maybe JRuby adds them, because people keep asking for them
<seacreature>
Sooner or later, a proposal is made to add them to common Ruby, because they're common now!
<The_8472>
that's not how proposals should be evaluated
<The_8472>
because then you're pretty much setting the first version in stone
<charliesome>
The_8472: unfortunately that's how things tend to work
<charliesome>
even when you do have a big standards body
<charliesome>
look at vendor prefixes in css
<The_8472>
no, it doesn't. look at java. they went through 3 different lambda syntaxes
<The_8472>
and none of them are legacy baggage
<charliesome>
look at vendor extensions in ecmascript
<seacreature>
The idea is that if you want portability, stick to common Ruby
<The_8472>
but there is no common ruby
<seacreature>
if you use implementation-specific features, follow the implementation's release policy
<charliesome>
The_8472: look at gnu's c extensions, etc
<charliesome>
lots of people were using VLAs before c99 came around, lots of compilers implemented them
<seacreature>
There very much is a common Ruby, it is defined by the features which all major implementations pass in RubySpec
<charliesome>
and they were ratified because they were already in common use
<seacreature>
What we don't have is a model for defining what *should* be common Ruby
<seacreature>
and we don't have good documentation or language support for enforcing common compatibility
<seacreature>
that's where we can maybe make some improvement
<The_8472>
there is rubyspec, sure. but all the developers i've worked with don't even know what exactly is defined in there
<seacreature>
The_8472: maybe you missed the context.. that is the problem to be solved
<seacreature>
RubySpec and the ISO spec give us a starting point, but if we are going to collaborate, we have lots more work to do
<The_8472>
the w3c for example requires that new CSS features have at least 2 independent implementations before the draft can advance.
<The_8472>
vendors are free to propose their own implementations as starting point
<The_8472>
but they have to be marked as experimental
<seacreature>
that's kind of what I'm looking for. But I don't want that design council to define "Ruby"
<The_8472>
and interfaces may change as long as it's experimental. that's an important thing, since it allows discovered design flaws to be fixed
<seacreature>
Because to me and to many others, "Ruby" has always meant Matz's language
<The_8472>
then let the council define common ruby. semantics semantics.
<seacreature>
The naming means everything here.
<seacreature>
I think the reason everyone is so offended by brixen's proposal is because it sounds like he's trying to redefine "Ruby"
<The_8472>
as a developer i honestly do not care, as long as my code runs, is fast and can be moved to a different runtime if i have problems with the current one
<seacreature>
Would his proposal still be so controversial if instead he was just trying to define a useful label for exactly what you just described?
<drbrain>
seacreature: that's not why I'm offended
<The_8472>
remember why everyone hated IE6? Nobody cared about how things are named. they care about compatibility.
<seacreature>
The_8472: That's the end result
<seacreature>
but there is an entire infrastructure and series of processes that cause that problem, and naming is a big part of it
<seacreature>
drbrain: why are you offended then?
<drbrain>
seacreature: on Monday we had a developer's meeting where we discussed parts of this proposal
<seacreature>
I read the notes from that meeting
<drbrain>
hi didn't bother to update his proposal based on what was discussed at the meeting.
<drbrain>
hi -> he
<seacreature>
okay, that is rude (or at least a bit sloppy)
<seacreature>
So I can understand the frustration
<seacreature>
But if he updated the post with those ideas taken into account, would you still disagree with his points?
<drbrain>
the second part is the English-only requirement, not every current committer speaks English well enough to follow along
carlosantonio has quit [Remote host closed the connection]
<drbrain>
not particularly
<seacreature>
This is a legitimate concern, it's why I really favor a "build first, and then discuss" approach with Ruby
<seacreature>
We should really be trading in experiments, rather than theory
<drbrain>
having to implement everything ahead of time before discussion is the way browsers implement CSS today, it's not particularly pretty to have -moz-foo: x; -webkit-foo: x; foo: x;
<brixen>
drbrain: I disagree with what was "decided" (nothing concrete was decided) at the meeting
<The_8472>
that kind of thinking is why mri still has no generational garbage collector
<The_8472>
some things are sufficiently complex that they need to be designed
<brixen>
drbrain: are you saying, I don't have a right to propose a process?
<drbrain>
brixen: no
<brixen>
seacreature: nothing in my proposal excludes build first
<brixen>
seacreature: my proposal explicitly sets that expectation
<seacreature>
brixen: I'm aware of that.
<drbrain>
I'm saying that by not incorporating any feedback at all is arrogant
<brixen>
drbrain: I disagree
<brixen>
it's arrogant to disagree?
<brixen>
nothing was decided in our meeting
<seacreature>
brixen: But your proposal says that something is not part of "Standard Ruby" until it's unanimously agreed upon, and that's what I think is the sticking point
<drbrain>
it's arrogant to ignore it entirely
<brixen>
nothing of substance
<brixen>
drbrain: why is it arrogant of me to disagree but not arrogant of tenderlove to propose something different that what I proposed at RubyConf?
<brixen>
I am truly baffled by that position
<seacreature>
brixen: If you said, "We should have some standard for the common features of the Ruby language called FOO, and it should be defined by the various implementers and not just Matz"
<charliesome>
The_8472: you are welcome to start working on a generational gc, you can start by adding write barriers
<seacreature>
I honestly think that you'd be getting real feedback on point-by-point ideas rather than a "OMG you're trying to steal Ruby away from Matz"
<drbrain>
brixen: ↑
<seacreature>
everyone involved, please don't forget that personal attachment to projects, and cultural inertia are real things we need to deal with
<brixen>
seacreature: your comment makes little sense to me
<drbrain>
brixen: I didn't realize that tenderlove promised to bring up your proposal
<brixen>
seacreature: as in, I don't know what you are contrasting with what I said
<brixen>
drbrain: he didn't promise anything
<seacreature>
brixen: Many people believe that Ruby == MRI == Matz
<brixen>
I gave a proposal at RubyConf
<drbrain>
then I don't understand
<seacreature>
When you suggest that Ruby != MRI and that Ruby != Matz, it offends people because of historical reasons
<brixen>
why was it not arrogant to propose something different to what I had already proposed?
<drbrain>
part of a good proposal is incorporating feedback when bringing it up again
<brixen>
I disagree with the result of the meeting
<drbrain>
ignoring that feedback outright is bad form
<brixen>
what feedback am I ignoring?
<The_8472>
"i want to remain dictator" is not exactly feedback. it's a statement.
<seacreature>
If you say "People use Ruby want to be able to write programs that work on various implementations, and the implementers should have a formal design process to coordinate with each other", that's much less controversial
<drbrain>
[16:19:16] <matz_> I am not going to stop being the dictator, but I want you guys to participate in the process of improving the language
<brixen>
seacreature: I know you are well-intentioned, but I don't understand what you're saying
<drbrain>
[16:21:47] <matz_> evan, you have to persuade me, but no just saying no
<seacreature>
Do we care about every last feature of Ruby being agreed upon, or do we care about making it easy for everyday developers to write portable Ruby?
<brixen>
drbrain: I'm not satisfied with that
<drbrain>
[16:22:02] <matz_> I am very easy to be persuaded
<brixen>
drbrain: I can not be satisfied and still not be arrogant
<brixen>
your making this a personal attack is unjustified
<drbrain>
you need to persuade us
<drbrain>
much like we persuade matz
<brixen>
why don't you attack the proposal and not dismiss it by labeling me arrogant?
<brixen>
drbrain: how should I persuade you?
<brixen>
you just called me arrogant for disagreeing
<brixen>
I persuade you by agreeing with you?
<drbrain>
you could give evidence on how this will help us make a better ruby
<brixen>
so, I didn't make my case well enough?
<brixen>
drbrain: seriously, you should retract that arrogant and borderline insulting accusation
<seacreature>
drbrain, brixen: I understand that you guys are really heated right now, but can I have a couple minutes to clarify my position?
<seacreature>
brixen: I like your proposal a lot (the broad strokes, not necessarily the details)
<drbrain>
brixen: please, you have insulted me in the past month and I dismissed it out of hand
<brixen>
drbrain: how?
<brixen>
this is news to me
<drbrain>
you called me a liar, "disingenuous" was your exact word
<seacreature>
guys, if you're not able to have a civil conversation, why the fuck should anyone listen to either one of you?
<brixen>
drbrain: yes, that is true
<seacreature>
This is a bunch of ad-hominem waste, and I look up to both of you, so I'm disappointed by it
<brixen>
drbrain: you comments on the Rubinius issue were disingenuous
<brixen>
that is accurate and I stand by it
<brixen>
you would not tolerate someone suggesting that you should add __foo__ to all your methods in one of your projects
<brixen>
and your opinion of how Rubinius should implement code is your opinion
<brixen>
it has no special validity
<brixen>
if it is rejected, that's still fair
<drbrain>
I would have tried to bring up an alternative such as evan ended up implementing
<drbrain>
but it was too difficult to continue discussion
<brixen>
evan's change does not alter the discussion
<brixen>
we are still not adding __ methods
<brixen>
nor are we hiding all details
<drbrain>
more creative solutions were available than __foo__ but it was very difficult to discuss them
<brixen>
you insisted that we had to make those changes
<brixen>
which we don't have to, nor will we
<drbrain>
then I wasn't clear enough in my statements
<brixen>
and your insistence was disingenuous because you would not accept such an argument about your own code
<drbrain>
I would, I stand by that
<brixen>
you can go re-read your comments
<drbrain>
if not __foo__, then some other more creative method to solve the user's problem
<brixen>
subclassing Array so you can do write a[1] instead a.name is not code that Rubinius *has* to support
<brixen>
it's a fair decision for us to make
<brixen>
you should go reread your comments
<brixen>
anyway, tit for tat is how you roll?
<brixen>
you think I insulted you so you should insult me?
<The_8472>
you guys are still bickering like children on a playground
<seacreature>
brixen: Can I just have a couple minutes to talk to you and offer an outsider's perspective?
<seacreature>
I'm coming from a position of enormous respect for everyone who is involved in Ruby implementation
<seacreature>
And I'm not invested in this, I just want to offer a small slice of my own historical perspective
<seacreature>
then once I've had a chance to explain it to you, I'll bow out
<seacreature>
is that okay?
<brixen>
The_8472: really? I'll be curious to see how you react when someone is casting personal accusations because they don't like your ideas
carlosantonio has joined #ruby-core
<seacreature>
brixen: I don't doubt that whatever personal conflicts you're in now are real and that you have good reason to be fired up, I just want to talk about well... Ruby, for a minute
<brixen>
seacreature: again, it's not clear to me what you are trying to clarify
<brixen>
seacreature: I read your post, and I'm pretty lost
<seacreature>
Okay, then let's take a step back and try to figure that out
<The_8472>
brixen, usually by argueing more. until i realize or someone else tells me that it's not constructive. and i'm trying to do exactly that to you right now. you guys are discussing how you should talk to each other instead of talking about something... useful
<seacreature>
Imagine your proposal was fully accepted, but that it wasn't called Ruby, it was called ANYTHING_ELSE.
<seacreature>
Would that be a win or a loss for you?
<The_8472>
i'm sure both of you already know how to act like professionals, just decided to not do so for some reason.
<ddd>
let it go so the conversation can go on for now
<brixen>
The_8472: I don't think it's unprofessional to confront someone who is taking a technical decision personal
<seacreature>
brixen: I am not suggesting people switch to a different language
<seacreature>
What I'm asking is, say you had a language called FOO and it had every feature that is currently passing in RubySpec for JRuby, Rubinius, and MRI
<seacreature>
And it had exactly the same design process you described
<brixen>
seacreature: why is it objectionable to decide questions that affect the well-being of Ruby as a group of demonstrably committed implementers?
<brixen>
there is no existing standard for Ruby
<brixen>
we have tried to create one with RubySpec
<seacreature>
It's not!
<brixen>
yet, despite no standard, all implementations have tried *extremely* hard to make a unified language
<brixen>
despite MRI making it extremely difficult to do so
<seacreature>
brixen: you're interrupting me and rejecting my questions impatiently and ignoring the fact that I completely agree with everything you just said
<seacreature>
If you want to be taken seriously, please don't assume that everyone is at war with you.
<seacreature>
Keep in mind that years ago, I specifically wanted to build a tool for you to help with this problem
<seacreature>
showing a compatibility matrix for RubySpec
<brixen>
no, having a language called FOO is not acceptable
<brixen>
seacreature: what is your next question?
<seacreature>
Why does it matter whether the language that we use right now is called Ruby, Common Ruby, or FOO, if it meets your criteria?
<ddd>
the name of the language is immaterial to to the concept he's trying to explain. It culd be called C or C++ or FOO
<brixen>
ddd: what
<seacreature>
That's a serious question, not facetious
<brixen>
?
<brixen>
seacreature: it matters a great deal
<seacreature>
Okay, but why?
<nurse>
I remind SQL is derived from SEQUEL
<brixen>
Ruby is a programming language that people are paid to write
<brixen>
not some hypothetical language that could have a unified spec
<brixen>
seacreature: the question you are asking makes no sense to me
<seacreature>
It's a label, not a language
<brixen>
why did Sun sue MS over changing Java?
<brixen>
it is a language, as well as a label
<seacreature>
Okay, but here's where you're reaching your conflict point
<seacreature>
Ruby-the-label, to many people, means "Matz's language"
<nurse>
brixen forgot SQL's case and ECMAScript.
<brixen>
nurse: what am I forgetting?
<seacreature>
Ruby lacks definition, by definition.
<nurse>
ECMAScript has the different name from JavaScript.
<ddd>
wait, so being paid has something to do with the conversation? I thought this was about bringing around a process of unifying the structure and containing implementation of a language and its features. Something *totally* independent of people being paid for it. It could be "How do we unify the process of making wheels such that all wheel makers have a say and a process to follow to make a common wheel structure.
<brixen>
nurse: how is that relevant to this?
<brixen>
ddd: did you read my post?
<nurse>
SQL is from IBM's SEQUEL, named through standization
<brixen>
nurse: I still don't see how that is relevant
<brixen>
nurse: you are ok with a standardization process that changes Ruby to a new name?
<nurse>
brixen says the name "Ruby" is important. I showed primor example.
<nurse>
*prior*
<brixen>
it's not relevant
<seacreature>
Not *changes* Ruby, but instead, Ruby would be a superset of that language
<seacreature>
as would Rubinius, and JRuby
<brixen>
the standardized language was the one that was used
<ddd>
EAch wheel maker has a different way of making a wheel. There was a first wheel maker that everyone eventually decided to copy the generic structure of, implementing their own little additions and features. Now they want to make it so that they all have a much firmer and more stable definition of what constitutes a wheel.
<nurse>
the standard process creates another language in the case.
<ddd>
thats exactly the same thing thats taking place here
<brixen>
nurse: *any* process creates another language
<brixen>
Ruby is changing all the time
<brixen>
it's still called Ruby
<seacreature>
brixen: you just answered your own question
<nurse>
yeah.
<brixen>
seacreature: no, I totally did not
<brixen>
at all
<seacreature>
Your process changes Ruby in a fundamental way
<brixen>
no, it doesn't change Ruby in a fundamental way
<brixen>
my process hasn't changed Ruby at all
<seacreature>
Explain why
<brixen>
Ruby may be changed via my process
<brixen>
or continue to be changed ad hoc by MRI experimentation
<seacreature>
You're proposing freezing the notion of what "Standard Ruby" is though
<The_8472>
not freezing it, altering the way it gets changed.
<seacreature>
Right, that fundamentally changes what "Standard Ruby" means right now.
<brixen>
seacreature: how does it change Ruby?
<seacreature>
Right now, "Standard Ruby" is defined by Matz, but because it's a defacto standard, that causes many issues.
<seacreature>
If we were talking about law and not programming
<seacreature>
Say we said we kept all the laws as they are, but we are instating a dictator who can change them on a whim
<seacreature>
Would that fundamentally change a government?
<seacreature>
Imagine your process in reverse
<nurse>
It is not correct precondition,
<nurse>
matz is the Creator of this Ruby World.
<nurse>
we are equal but matz.
<ddd>
except like real life global policies, actions, movements, and tools, some things become bigger than their originator or the originator's original ideas and desires.
<ddd>
it grows beyond themselves. this is whats happening with Ruby.
<drbrain>
ddd: I haven't seen matz not be good for Ruby
<ddd>
Its so good it has people fighting to take it to a level different than the original thought or (in this case) implementation and its pattern of doing/creating things
<ddd>
i didn't say that
<drbrain>
I know
xibbar has quit [Remote host closed the connection]
<ddd>
nothing in there at ALL should be contrued as me saying he has done ANYTHING BAD for ruby
<drbrain>
there may come a time when we need more than matz, but I don't think that time is now
<seacreature>
drbrain: *we* in that context does refer to the core team and people deeply embedded in Ruby though
<seacreature>
me as an educator, the people I teach as every day programmers
<seacreature>
well... that's a different *we**
<seacreature>
I think it'd be useful to make a map of all the different roles that exist in the Ruby ecosystem
<nurse>
"we", I said, includes every people in Ruby World
<drbrain>
nurse: that's how I feel too
<seacreature>
brixen does a good job of pointing them out in his proposal, I think we can go much farther though
<nurse>
all rubyist are equal for matz
<ddd>
I see both sides of the coin's position. *I* personally think hey the guy wrote it. whatever he wants to do with it he can do, or not allow to happen. I also temper that with the understanding that now that others are using it and do so deeply, they too have valid ideas and goals.
<nurse>
matz will accept the idea is good, reject bad idea
<drbrain>
ddd: yes, and many of these are incorporated in ruby
<drbrain>
even things without matz' direct approval
<drbrain>
I make many changes to rdoc and rubygems without matz' approval
<The_8472>
<nurse> matz will accept the idea is good, reject bad idea <- if he is infalliable.
<ddd>
and that can detract, BUT that being said, I don't see matz doing anything more than saying OK, lets work this out. yes, as its creator I reserve the right to exercize my right to say No. I'm also promising to do so as sparingly as possible. Now, where do we go from here.
<nurse>
(of course core team can describe their idea better than normal person)
<drbrain>
I added GVL-free operation to zlib without matz' approval
<seacreature>
With all due respect to Matz, we are talking about hundreds of millions of dollars and millions of people
<drbrain>
seacreature: and matz knows this too
<seacreature>
Most of whom he will never recieve feedback from or ever come in contact with
<seacreature>
our superconnected core is not the Ruby world
drbrain has quit [Quit: Leaving...]
<seacreature>
But that said, I personally feel that Ruby can and should belong to Matz
<seacreature>
but that there is a useful set of concepts that Ruby sits on top of, which are more universal
<nurse>
Bundled libraries are not "standard libraries".
drbrian has joined #ruby-core
<nurse>
Some of them are out of matz' owner ship. zlib is such thing.
<ddd>
seacreature: OK, but that doesn't preclude him as the creator to say I want ruby to go in this direction. The whole point of this is to solidify a process that will allow others to make changes within a structured approach govering submittal and grounds for acceptance, that is also acceptable to Matz who has every right to say NO regardless of how mch money others are making off his invention. And to maintain the blessing of Matz in
<seacreature>
Guys, this is fascism.
<seacreature>
*folks
<seacreature>
That's literally what you're describing.
<ddd>
who has every right to say NO regardless of how mch money others are making off his invention. And to maintain the blessing of Matz in order to put controls in place to drmatically limit the potential for a split should he suddenly decide TO say no.
<ddd>
think thats where it cut off the last time
<ddd>
sorry sometimes i find it hard to make a full comment about a frame of thought in a short passage.
<seacreature>
It's fine for Ruby to be Ruby, and for Matz to have control over what "Ruby" means.
<ddd>
no not really. its a guy who wrote something that others found valuable that he still wants to direct as *is* his right.
<seacreature>
But to think that there isn't a common core of ideas underneath Ruby that is a shared platform is very strange to me
<nurse>
C# and Perl also uses dictator Model.
<ddd>
however others have a right (based on the license) to do stuff with it too, and this is both people and the originator trying to find a way ti implement that without bending noses on both sides using a mututally agreed upon process to direct that future
<seacreature>
ddd: such a process will never exist as long as both sides insist on calling it RUby
<ddd>
now THAT i agree with
<ddd>
thats due to the 'value' of the 'tag' ruby
<drbrian>
seacreature: I just don't think we need a change in government at this time
<ddd>
or Ruby
<seacreature>
drbrian: I think that's fine. But what I'm suggesting is more a collection of treaties
<ddd>
hehe i like that choice of wording
<seacreature>
let all of these projects be sovereign, and let them agree on the things they can band together on
<seacreature>
Because *that* language does exist. It's the language I *must* write in if I want to produce portable code
<seacreature>
Not in some theory, but right now in practice
<drbrian>
Is that different from the situation of refinements?
<seacreature>
and it has no name, it has no governance
asarih has joined #ruby-core
<seacreature>
I honestly don't know how to teach that Ruby
<seacreature>
or to write that Ruby
<seacreature>
Or sorry, that <amorphous thing we all refuse to define>
<seacreature>
This blob exists between Ruby versions, too, not just implementations
<ddd>
ok, not sure i understood that last
<seacreature>
I think by entertaining the idea of *trying* to define a common core, we might stumble across the right processes to actually unify the language formally.
<seacreature>
What I want is maximal experimentation along the horizons, and a very conservative and stable core at the center of all implementations
nari has joined #ruby-core
<seacreature>
Is that objectionable in any way?
<ddd>
wait isn't that what the rubyspec does?
xibbar has joined #ruby-core
<nurse>
MRI and Ruby is under matz's private property
<drbrian>
Yes, it sounds much like the current process
<seacreature>
RubySpec is a horrible user experience for the every day teacher and learner
<seacreature>
it's an implementer's tool.
<seacreature>
It could be useful for much more than that, with the right improvements
<drbrian>
Jruby has parallel stuff, Rubinius has actors, MagLev has persistence, MacRuby integrates with OS C
<The_8472>
<nurse> MRI and Ruby is under matz's private property <- do you have to sign over your copyright if you contribute?
<The_8472>
if not, then it's not his sole property.
<nurse>
RubySpec is a compatibility test suite like Java Compatibility Test Tools.
<The_8472>
except that JCT compliance is required that you can call yourself java-compatible.
<nurse>
Read COPYING in ruby repo.
<seacreature>
What I'm suggesting is that if you have many applications which have a common core to them
<seacreature>
you naturally extract the common bits into a gem
<nurse>
"author" (matz) has some special right in Ruby License
<seacreature>
what if we did the same for the common bits of Ruby (at the functionality level, not implementation)
<seacreature>
What is the downside, what is the benefit?
<drbrian>
Rubinius has some of that, but it is coupled to the Rubinius VM
<nurse>
yeah, such validator won't be made from RubySpec.
<drbrian>
Socket and other ffi extensions are not, though
carlosantonio has quit [Remote host closed the connection]
<The_8472>
nurse, i read nowhere that you have to sign over copyright. therefore at best it's part matz' part public domain.
<The_8472>
or, according to german law for example, you cannot sign over copyright, only usage rights, therefore it would be considered joint ownership here unless other agreements have been made
<nurse>
In Japan, contract doesn't need sign.
<seacreature>
I don't know where this crazy discussion about licensing is coming from
<seacreature>
Ruby does not require copyright assignment
<nurse>
A contract is made when both side did something.
<seacreature>
Matz has permission baked into the license to change things how he sees fit, that's what people agree to
<seacreature>
And on top of that there is the MIT license
<seacreature>
(used to be GPL)
<seacreature>
Users can choose which license to follow
<seacreature>
Redistributors and contributors must abide by both
<ddd>
me either. i think it was becaused I mentioned the license insofar as others having the rights to do stuff as well due to the license
<seacreature>
The point is that if you fork Ruby, you don't get to call it Ruby
<seacreature>
same as any other open source project
<seacreature>
so the maintainer has the rights to develop the project as they see fit, and everyone can fork
<nurse>
If you use Ruby License in narrow meaning, you don't get to call it Ruby.
<nurse>
But you can use GPL or BSDL.
<ddd>
right. which is one of the core things (due to the value of the 'name' 'Ruby') to protect by the establishing of this desired process.
<seacreature>
So when brixen says that "Ruby" is anything but what Matz and the core team defines it as
<seacreature>
it's literally false (not just philosophically)
<seacreature>
But what people think of as Ruby is a much more vague, much more broad thing
<ddd>
or at leat i see that as one of the desired things. people working to extend as the *community* feels and sees needed to be added or changed, without butting against a poit wher eMatz would feel the need to exercise a 'veto'
<seacreature>
and there is a valid argument from that angle too
<seacreature>
Until a shared understanding of that point is reached, this argument will go on forever with no progress
<drbrian>
It's like a Star Trek episode where the universal translator is broken
<nurse>
Anyway expressing Ruby as stardard by "Ruby" is misleading. I want to say it as Common Ruby or the Ruby Standard or something
<seacreature>
nurse: okay, that was my entire point of this conversation :-)
<seacreature>
Now that someone has acknowledged it (whether they agree or not), I think I'm done talking.
<ddd>
seacreature: I see that as a nitpick, but not in a way of dismissal. I see it as a nitpicking point with VAST portent. On both sides of the coin. meaning that it seems like a really small distinction, BUT, I agree with you that that is a sticking point that is being missed
<ddd>
the *value* of that point, the .. *importance* of that point is probably better to say
<ddd>
i completely agree that until that particular nitpick is picked and picked *clean* its going to be a sticking point to the process going forward
<seacreature>
In my mind, what brixen calls "Ruby" *is* Common Ruby. What matz calls "Ruby" *is* MRI. And what every person calls Ruby, well... depends on what they think :-)
<ddd>
i think you hit it in a nutshell actually
<drbrian>
Most likely
<ddd>
for *me* I see ruby as the current set of implemented features that work across *all* current implementations. I see MATZ's Ruby as the progenitor of it all, and thus having weight to bring to bear to enforce or cajole, or otherwise direct how things go forward.
<seacreature>
I am for the standardization (by convention and a design council) of what we have in common, against calling it Ruby.
<ddd>
however I also see that the community around that has grown exponentially from its original roots. exactly as the Linux kernel did
<seacreature>
And I've truly run out of things to say at this point.
xibbar has quit [Remote host closed the connection]
<seacreature>
I'm sorry if I've only made things worse by throwing in my thoughts, but if anything I've said is useful, I'm glad I did it.
<ddd>
and the *community* using that set of already-unified features that *already* work across each platform without changes by the user *to* use them regardless of the implementation running those features ont heir behalf is seeking a path to ensur ethat even *more* features can be brought to life that do the eact same thing
<ddd>
and the process *to* do that is whats in question here, as i see it
<drbrian>
Seacreature: I don't think you've made anything worse
<ddd>
unless i've utterly missed the boat
<asarih>
seacreature: I suspect that matz wants some sort of standardization; otherwise he would not have spent time on ISO proposal.
xibbar has joined #ruby-core
<asarih>
(I am still baffled by the ISO proposal, but it may just be me.)
<seacreature>
asarih: My understanding the reason for the ISO standard was because it is important for Japanese business
<ddd>
yes
<seacreature>
but I am recalling a vague hallway conversation with Matz from years ago
<seacreature>
I'm oversimplifying I'm sure.
<asarih>
seacreature: indeed. because the standardization *is* important for businesses.
<seacreature>
What brixen describes is more along the lines of standardization for the health of the whole community
<ddd>
seems nothing can be done business-wise (inter-business) without some standard backing it. but i think thats also a gross misread or possible mischaracterization of the japanese work process. not sure how to accurately describe my understanding.
<asarih>
seacreature: I suspect you're right, but I'll let him speak for himself.
<ddd>
as in the japanese government requires it. anyone from japan that can clarify that a bit?
<ddd>
(if thats important to the discussion. if not no biggie)
xibbar has quit [Remote host closed the connection]
<asarih>
ddd: nurse, I suspect.
<seacreature>
Things have become so personal that I feel like his idea will be ignored just because of the way he presented it
<ddd>
i bring that up as well, because i'm wondering how, whatever panel and community processes are brought to bear, that will affect the ISO if at all
<seacreature>
That's why I came here to talk about it today, but I am just a Ruby teacher, I'm not an implementer. There's very little I can do here to convince anyone.
<ddd>
i'm not even a teacher, i'm a user. however I'm interested in the processes that affect my chosen programming language and the community and the implementations within it
<asarih>
ddd: ISO proposal was already submitted, AFAIK
<drbrian>
Seacreature: pretty much anyone who is involved has a voice
<ddd>
i'm looking at it as well from a growing home business AND as a community member that contributes to the ecosystem that surrounds that language.
<seacreature>
drbrian: I am actually not a fan of internet democracy
<seacreature>
It's one thing to share your thoughts, it's another to think that you ought to have a right to actively be involved in decision making
<seacreature>
But it is very important to recognize that most Ruby programmers are unaware of the fact that ruby-core even exists
<seacreature>
And that the total impact of Ruby on the world reaches far beyond its community
<ddd>
seacreature: but the ability to share your thoughts even on something that you have no direct control or authority over, and know that your words are at least read and thought upon even if eventually dismissed with no hope of appeal is also important.
<ddd>
it lets us be involved even if we can't direct the course by our own hand(s)
<seacreature>
we can't look at our little corner of the world and think that it's a representative sample.
drbrain has joined #ruby-core
<seacreature>
that's what I generally *like* about brixen's proposal, and generally dislike about some of the decisions I've seen from ruby-core. But I think in the end, we're all well intentioned people trying to do something good in the world.
drbrian has quit [Quit: Leaving]
<seacreature>
I hope that this all gets worked out.
<drbrain>
seacreature: well, a voice is not a vote
<seacreature>
For most of us here, this isn't the first bump we've hit in the road. I remember a period of years in which people said that Ruby 1.9 would be the death of MRI
<ddd>
seacreature: well how would you propose getting a representative example? because its not just the big contributors that make money as well. as you said this is literally billions of dollars, and millions of lives. From the big guys like 37Signals and Github, to the little guys making a living only big enough to pay the home bills.
<ddd>
how this plays out has impact at both levels and all stops in between
<seacreature>
We've been through worse before ;-)
<asarih>
seacreature: perish the thought!
<drbrain>
the 1.8 -> 1.9 transition was much more contentious
<drbrain>
so much so that we used up 1.9.0 just testing it!
<seacreature>
hah, I was one of the folks who built a massive piece of software while riding the 1.9 wave (Prawn)
<seacreature>
But I was very much anti-1.8.7 and felt like preseving 1.8.6 was very, very important
<seacreature>
until maybe a year later when I completely ignored 1.8
<drbrain>
there is definitely a big change in feeling between ruby 1.8 and ruby 1.9's core libraries
<drbrain>
many more keyword arguments, more behavior packed into the same method
<seacreature>
My concern with Ruby is not that it doesn't progress, or that it doesn't balance out in the end, but that we burn lots of cycles on tension points
<drbrain>
… mostly in IO/Process
xibbar has joined #ruby-core
<seacreature>
So I am very interested in the kinds of changes we can make that might make collaboration easier in the future
<seacreature>
but again, the only reason I'm still here talking is because I feel very passionately about this issue, not because I have anything more of value to add.
<seacreature>
Maybe it's time to take a rest for the night.
<seacreature>
Thanks for listening and discussing, everyone.
<ddd>
i hope people don't get the feeling that even if these processes were put in place *today* that by next week everything will be all hunky dory and flowing smoothly. or even by the end of next year
<ddd>
night
<drbrain>
'night
<ddd>
time for me to split as well. children to get off to bed. night all
<seacreature>
ddd: sorry, I missed an important question of yours.
<seacreature>
about the representative example: I honestly think Ruby needs people actively doing community management if we care about those things
<seacreature>
people with UX experience, and the ability to think through the many, many, different kinds of people a programming language is meant to serve
<seacreature>
But I'm not sure we have the resources for that, or the desire :-/
<seacreature>
If I could get paid a salary to do that, I'd be all over it though.
<seacreature>
it's just too hard to do as a volunteer thing
<seacreature>
now I'm closing my laptop!
<asarih>
we need more people getting paid to do this full time. ;-)
<asarih>
That would be an interesting metric for the OSS languages.
<drbrain>
more committers helps
<asarih>
drbrain: more *full-time* committers do, yes.
<drbrain>
zzak has been very helpful for documentation even though he is not full-time
<asarih>
drbrain: that's good to hear.
<nurse>
yeah, zzak's work is so great
<asarih>
nurse: when are you going to work for Heroku? :-P
<drbrain>
also, now I can fix rubygems and rdoc bugs for ruby 2.0.0
<asarih>
drbrain: +1
xibbar has quit [Ping timeout: 250 seconds]
<nurse>
Current my job is not so busy that I can chat. If I'm busy, I may go heroku ;-)
<asarih>
lololololol
<drbrain>
heh
The_8473 has joined #ruby-core
<zzak>
thank you!
<zzak>
i am working on irb docs, phase two :D
The_8472 has quit [Ping timeout: 244 seconds]
<zzak>
nurse: where do you work?
<nurse>
A leader of rails/iOS development.
<zzak>
do you work with masui-san?
<nurse>
I adjust client side and server side, it is not a hard job.
<nurse>
No.
<zzak>
full-time?
<asarih>
nurse: didn't know you were a Railer.
<nurse>
full-time
<nurse>
rubyci.org is built with Rails ;-)
<asarih>
the more you know…
<asarih>
nurse: how did you get the client machines for OS X?
<asarih>
for rubyci.org
<nurse>
It is mrkn's machine.
<asarih>
ah
<asarih>
both of them? there are 2.
<nurse>
yes, They are mrkn's
<asarih>
I see.
BigO_ has joined #ruby-core
tarui has quit [Quit: Quit Nadoka 0.8.2-trunk (-)]
tarui has joined #ruby-core
headius has joined #ruby-core
nokada has quit [Read error: Connection reset by peer]
nokada_ has joined #ruby-core
BigO_ has quit [Remote host closed the connection]