On Friday, June 15, 2012, Jeremy Apthorp wrote:
> I think you've missed the point of CoffeeScript.
> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com<javascript:_e({}, 'cvml', 'spasqu...@embarkcorp.com');>>
> wrote:
> It's unfortunate that this is written is CoffeeScript. It's a strange
> choice for a revolutionary product -- to intentionally exclude the majority
> of developers, and to convict those remaining to debug hell.
> Such brilliance, dulled. That JG is that brilliant is the only reason we
> see this at all.
> The proper thing is to fork the project into a JS-only initiative,
> properly annotate it, and invite developers.
> In fact...
> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
> For reference... this is a discussion about brunch's approach to plugins:
> > There's a fair bit of thinking we have to do here, about exactly how
> > sharejs should be structured. I'm not too happy with how its
> > structured at the moment - I feel like sharejs is trying to do too
> > much. I'd be interested to see proposals for how it should be
> > rewritten.
> Etherpad Lite has plugins using npm so we could try something like that...
> break up ShareJS into modules and then work on each of those to provide
> proper abstractions and promote code reuse in new contributed modules.
> Projects like brunch allow you to choose the plugins you want to use just
> by adding them to your package.json... these are just two examples but i'm
> sure there are several other approaches to choose from.
> > Yep. I've been promising this for months, and I keep getting
> > distracted. We'll get there.
> Not sure you have donations set up but you should... i understand that
> these days there's just so many neat stuff to do and all hobby projects get
> to a point they feel like an obligation... perhaps we could come up with a
> neat project based on ShareJS for motivating.. how about some sort of game?
> Or a ptp version using webrtc's peerconnection?
> > > - Create sample with participants and cursors (something like
> MarkdownR but
> > > with list of participants and cursor positions)
> > > - Refactor rizzoma's contribution to support "attributes". (They call
> > > "params" as of now but the ideia is the same)
> > > - Create sample rich text editor (using Rizzoma's editor, Halo or any
> other
> > > text-editor - it would be great to have an editor that doesn't depend
> on
> > > content editable - perhaps extracting Wave's editor and providing a
> pure JS
> > > API )
> > > - Support Wave's model ? (conversation, blips, etc...)
> > Wave's model is quite complicated. I'm not sure how much of it we
> > really need. Eg, wave has full XML support (arbitrarily nested
> > elements with attributes) as well as rich text annotations, which are
> > orthogonal to the XML structure. I think thats too much. I'd be happy
> > with just supporting one or the other.
On Friday, June 15, 2012 7:47:23 PM UTC-4, Jeremy Apthorp wrote:
> I think you've missed the point of CoffeeScript.
> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
> It's unfortunate that this is written is CoffeeScript. It's a strange > choice for a revolutionary product -- to intentionally exclude the majority > of developers, and to convict those remaining to debug hell.
> Such brilliance, dulled. That JG is that brilliant is the only reason we > see this at all.
> The proper thing is to fork the project into a JS-only initiative, > properly annotate it, and invite developers.
> In fact...
> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>> For reference... this is a discussion about brunch's approach to plugins:
>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com> >>> escreveu:
>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson.si...@gmail.com> >>> wrote: >>> > > So, to sum up, my roadmap proposal would be something like:
>>> > > - Promote ShareJS to top level at GitHub
>>> > Sure.
>>> Great!
>>> > > - Define a repo structure and guidelines for addons and samples
>>> > Do you think that would help? I'm a little biased, but I think the >>> > repo structure is fairly self explanatory.
>>> This should probably come after the next point... the idea is to define >>> a structure for addons... the repo structure for ShareJS is fine.
>>> > There's a fair bit of thinking we have to do here, about exactly how >>> > sharejs should be structured. I'm not too happy with how its >>> > structured at the moment - I feel like sharejs is trying to do too >>> > much. I'd be interested to see proposals for how it should be >>> > rewritten.
>>> Etherpad Lite has plugins using npm so we could try something like >>> that... break up ShareJS into modules and then work on each of those to >>> provide proper abstractions and promote code reuse in new contributed >>> modules. >>> Projects like brunch allow you to choose the plugins you want to use >>> just by adding them to your package.json... these are just two examples but >>> i'm sure there are several other approaches to choose from.
>>> > Yep. I've been promising this for months, and I keep getting >>> > distracted. We'll get there.
>>> Not sure you have donations set up but you should... i understand that >>> these days there's just so many neat stuff to do and all hobby projects get >>> to a point they feel like an obligation... perhaps we could come up with a >>> neat project based on ShareJS for motivating.. how about some sort of game? >>> Or a ptp version using webrtc's peerconnection?
>>> > > - Create sample with participants and cursors (something like >>> MarkdownR but >>> > > with list of participants and cursor positions) >>> > > - Refactor rizzoma's contribution to support "attributes". (They >>> call >>> > > "params" as of now but the ideia is the same) >>> > > - Create sample rich text editor (using Rizzoma's editor, Halo or >>> any other >>> > > text-editor - it would be great to have an editor that doesn't >>> depend on >>> > > content editable - perhaps extracting Wave's editor and providing a >>> pure JS >>> > > API ) >>> > > - Support Wave's model ? (conversation, blips, etc...)
>>> > Wave's model is quite complicated. I'm not sure how much of it we >>> > really need. Eg, wave has full XML support (arbitrarily nested >>> > elements with attributes) as well as rich text annotations, which are >>> > orthogonal to the XML structure. I think thats too much. I'd be happy >>> > with just supporting one or the other.
>>> The json stuff in ShareJS should be enough to mimic wave's conversation >>> model and the blips could be text with attributes/annotations. So basically >>> we're mostly missing a rich text model. Since rizzoma already has this we >>> could just start by extracting it from their clone.
>>> > > - Create Robot API ? (could just be a ShareJS client but with a nice >>> > > interface)
Let me give you a concrete example. This should help you understand the very simple point I made. I'm assuming you're actually interested in being helpful.
Our team is growing. We build diverse products in a very large space which demands precision and realtime performance. As such, NodeJS has entered into our conversation, and via that pathway, so has ShareJS.
It is an exciting time for realtime, collaborative applications. With Joseph, I want this new niche to become a big niche and maybe even a huge new initiative that will bring even more excitement (and fun, and profit) to the technology sector (https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)
But collaboration isn't just a buzzword: applied correctly, it can greatly improve the user experience, team dynamics, strategy, and other business needs for those of us who are building the software products of the future.
In order to explore these ideas our team constructed a collaborative editing environment using ShareJS, which we now use internally, and when ready, will release as a full-fledged (and open) product.
We do not have anyone on our team who writes Coffeescript. Not because we think it is stupid, or a trend, or we like to complain about the meanies who innovate. We love those meanies! It is also not because we don't "understand" CS, or aren't competent or hip enough to grasp indentation. Just three of many reasons:
1. We don't have anyone who writes CS. So we can't usefully contribute to CS projects. You (might) be able to grasp, given what we are currently working on (and which libraries we are using), why that fact is relevant to this conversation. 2. We are a profit-driven company that does not spend resources uselessly. A convincing business case has yet to be made to me demonstrating the benefit of taking my team off of servicing our customers (fixing bugs, feature care, new products) and learning another way to write code in JS (amazingly, they are really quite good at writing it the old fashioned way). 3. There is clear and unmistakable preponderance of JS coders vs. CS coders. This would put costly strain on our recruiting efforts, which may even put us in the terrible position of not being able to control peer quality at the source (careful selection of team members) due to a desperate need for hands. I do not want to hire anyone for the wrong reasons, (and neither do you).
Consider truth: a small fraction of a developer's time is spent writing new code.
Consider why: mature languages offer the lovely benefit of a vast, existing, codebase which probably already solves that problem. Every time I hear a CS person argue for DRY it kills me a little inside.
Consider analysis: What is *advantage* of the compile step? What is the *advantage* of losing existing IDE tools (mainly their debugging features)? What is the *advantage* of having a CS coder on your staff (it isn't speed -- that is a red herring. See previous.)? How would you argue for budgeting the additional training and recruiting costs to your CEO? What is the *advantage* of bifurcating your development process (given all that JS code that powers your existing systems)?
Consider the point: When I want to encourage contributions to my OS JS project (which this is), why would I make it difficult for JS coders to contribute? This is a great place to think about what I've written in the context of *the point of this entire thread* : why is it that this project has so little activity? Or better: how can we make it more active? Because it should be. Because it is brilliant and timely and effervescent.
I'm suggesting not only a substantial change, but an essential change.
On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
> Yeah, I think if you're going to complain at least suggest a substantial > change, like an Erlang server implementation.
> "C-" for effort.
> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>> I think you've missed the point of CoffeeScript.
>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>> It's unfortunate that this is written is CoffeeScript. It's a strange >> choice for a revolutionary product -- to intentionally exclude the majority >> of developers, and to convict those remaining to debug hell.
>> Such brilliance, dulled. That JG is that brilliant is the only reason we >> see this at all.
>> The proper thing is to fork the project into a JS-only initiative, >> properly annotate it, and invite developers.
>> In fact...
>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>> For reference... this is a discussion about brunch's approach to plugins:
>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com> >> escreveu:
>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson.si...@gmail.com> >> wrote: >> > > So, to sum up, my roadmap proposal would be something like:
>> > > - Promote ShareJS to top level at GitHub
>> > Sure.
>> Great!
>> > > - Define a repo structure and guidelines for addons and samples
>> > Do you think that would help? I'm a little biased, but I think the >> > repo structure is fairly self explanatory.
>> This should probably come after the next point... the idea is to define a >> structure for addons... the repo structure for ShareJS is fine.
>> > There's a fair bit of thinking we have to do here, about exactly how >> > sharejs should be structured. I'm not too happy with how its >> > structured at the moment - I feel like sharejs is trying to do too >> > much. I'd be interested to see proposals for how it should be >> > rewritten.
>> Etherpad Lite has plugins using npm so we could try something like >> that... break up ShareJS into modules and then work on each of those to >> provide proper abstractions and promote code reuse in new contributed >> modules. >> Projects like brunch allow you to choose the plugins you want to use just >> by adding them to your package.json... these are just two examples but i'm >> sure there are several other approaches to choose from.
>> > Yep. I've been promising this for months, and I keep getting >> > distracted. We'll get there.
>> Not sure you have donations set up but you should... i understand that >> these days there's just so many neat stuff to do and all hobby projects get >> to a point they feel like an obligation... perhaps we could come up with a >> neat project based on ShareJS for motivating.. how about some sort of game? >> Or a ptp version using webrtc's peerconnection?
>> > > - Create sample with participants and cursors (something like >> MarkdownR but >> > > with list of participants and cursor positions) >> > > - Refactor rizzoma's contribution to support "attributes". (They call >> > > "params" as of now but the ideia is the same) >> > > - Create sample rich text editor (using Rizzoma's editor, Halo or >> any other >> > > text-editor - it would be great to have an editor that doesn't depend >> on >> > > content editable - perhaps extracting Wave's editor and providing a >> pure JS >> > > API ) >> > > - Support Wave's model ? (conversation, blips, etc...)
>> > Wave's model is quite complicated. I'm not sure how much of it we >> > really need. Eg, wave has full XML support (arbitrarily nested >> > elements with attributes) as well as rich text annotations, which are >> > orthogonal to the XML structure. I think thats too much. I'd be happy >> > with just supporting one or the other.
>> The json stuff in ShareJS
On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
> Yeah, I think if you're going to complain at least suggest a substantial > change, like an Erlang server implementation.
> "C-" for effort.
> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>> I think you've missed the point of CoffeeScript.
>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>> It's unfortunate that this is written is CoffeeScript. It's a strange >> choice for a revolutionary product -- to intentionally exclude the majority >> of developers, and to convict those remaining to debug hell.
>> Such brilliance, dulled. That JG is that brilliant is the only reason we >> see this at all.
>> The proper thing is to fork the project into a JS-only initiative, >> properly annotate it, and invite developers.
>> In fact...
>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>> For reference... this is a discussion about brunch's approach to plugins:
>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com> >> escreveu:
>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson.si...@gmail.com> >> wrote: >> > > So, to sum up, my roadmap proposal would be something like:
>> > > - Promote ShareJS to top level at GitHub
>> > Sure.
>> Great!
>> > > - Define a repo structure and guidelines for addons and samples
>> > Do you think that would help? I'm a little biased, but I think the
It's pretty terrible to lord your "precious paid-time contributions" over a
free/open source project on the basis of the language used to implement it.
If the authors willing to put in the time are happy with CS, it's going to
be in CS. That's the nature of the beast.
If you want pure-JS, put your money where your damn mouth is and show us
the code.
On Tue, Jun 19, 2012 at 6:48 AM, Sandro Pasquali <spasqu...@gmail.com>wrote:
> Let me give you a concrete example. This should help you understand the
> very simple point I made. I'm assuming you're actually interested in being
> helpful.
> Our team is growing. We build diverse products in a very large space which
> demands precision and realtime performance. As such, NodeJS has entered
> into our conversation, and via that pathway, so has ShareJS.
> It is an exciting time for realtime, collaborative applications. With
> Joseph, I want this new niche to become a big niche and maybe even a huge
> new initiative that will bring even more excitement (and fun, and profit)
> to the technology sector (
> https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)
> But collaboration isn't just a buzzword: applied correctly, it can greatly
> improve the user experience, team dynamics, strategy, and other business
> needs for those of us who are building the software products of the future.
> In order to explore these ideas our team constructed a collaborative
> editing environment using ShareJS, which we now use internally, and when
> ready, will release as a full-fledged (and open) product.
> We do not have anyone on our team who writes Coffeescript. Not because we
> think it is stupid, or a trend, or we like to complain about the meanies
> who innovate. We love those meanies! It is also not because we don't
> "understand" CS, or aren't competent or hip enough to grasp indentation.
> Just three of many reasons:
> 1. We don't have anyone who writes CS. So we can't usefully contribute to
> CS projects. You (might) be able to grasp, given what we are currently
> working on (and which libraries we are using), why that fact is relevant to
> this conversation.
> 2. We are a profit-driven company that does not spend resources uselessly.
> A convincing business case has yet to be made to me demonstrating the
> benefit of taking my team off of servicing our customers (fixing bugs,
> feature care, new products) and learning another way to write code in JS
> (amazingly, they are really quite good at writing it the old fashioned way).
> 3. There is clear and unmistakable preponderance of JS coders vs. CS
> coders. This would put costly strain on our recruiting efforts, which may
> even put us in the terrible position of not being able to control peer
> quality at the source (careful selection of team members) due to a
> desperate need for hands. I do not want to hire anyone for the wrong
> reasons, (and neither do you).
> Consider truth: a small fraction of a developer's time is spent writing
> new code.
> Consider why: mature languages offer the lovely benefit of a vast,
> existing, codebase which probably already solves that problem. Every time I
> hear a CS person argue for DRY it kills me a little inside.
> Consider analysis: What is *advantage* of the compile step? What is the
> *advantage* of losing existing IDE tools (mainly their debugging features)?
> What is the *advantage* of having a CS coder on your staff (it isn't speed
> -- that is a red herring. See previous.)? How would you argue for budgeting
> the additional training and recruiting costs to your CEO? What is the
> *advantage* of bifurcating your development process (given all that JS code
> that powers your existing systems)?
> Consider the point: When I want to encourage contributions to my OS JS
> project (which this is), why would I make it difficult for JS coders to
> contribute? This is a great place to think about what I've written in the
> context of *the point of this entire thread* : why is it that this project
> has so little activity? Or better: how can we make it more active? Because
> it should be. Because it is brilliant and timely and effervescent.
> I'm suggesting not only a substantial change, but an essential change.
> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>> Yeah, I think if you're going to complain at least suggest a substantial
>> change, like an Erlang server implementation.
>> "C-" for effort.
>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>> I think you've missed the point of CoffeeScript.
>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>> It's unfortunate that this is written is CoffeeScript. It's a strange
>>> choice for a revolutionary product -- to intentionally exclude the majority
>>> of developers, and to convict those remaining to debug hell.
>>> Such brilliance, dulled. That JG is that brilliant is the only reason we
>>> see this at all.
>>> The proper thing is to fork the project into a JS-only initiative,
>>> properly annotate it, and invite developers.
>>> In fact...
>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>> For reference... this is a discussion about brunch's approach to plugins:
>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com>
>>> escreveu:
>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson.si...@gmail.com>
>>> wrote:
>>> > > So, to sum up, my roadmap proposal would be something like:
>>> > > - Promote ShareJS to top level at GitHub
>>> > Sure.
>>> Great!
>>> > > - Define a repo structure and guidelines for addons and samples
>>> > Do you think that would help? I'm a little biased, but I think the
>>> > repo structure is fairly self explanatory.
>>> This should probably come after the next point... the idea is to define
>>> a structure for addons... the repo structure for ShareJS is fine.
>>> > There's a fair bit of thinking we have to do here, about exactly how
>>> > sharejs should be structured. I'm not too happy with how its
>>> > structured at the moment - I feel like sharejs is trying to do too
>>> > much. I'd be interested to see proposals for how it should be
>>> > rewritten.
>>> Etherpad Lite has plugins using npm so we could try something like
>>> that... break up ShareJS into modules and then work on each of those to
>>> provide proper abstractions and promote code reuse in new contributed
>>> modules.
>>> Projects like brunch allow you to choose the plugins you want to use
>>> just by adding them to your package.json... these are just two examples but
>>> i'm sure there are several other approaches to choose from.
>>> > Yep. I've been promising this for months, and I keep getting
>>> > distracted. We'll get there.
>>> Not sure you have donations set up but you should... i understand that
>>> these days there's just so many neat stuff to do and all hobby projects get
>>> to a point they feel like an obligation... perhaps we could come up with a
>>> neat project based on ShareJS for motivating.. how about some sort of game?
>>> Or a ptp version using webrtc's peerconnection?
>>> > > - Create sample with participants and cursors (something like
>>> MarkdownR but
>>> > > with list of participants and cursor positions)
>>> > > - Refactor rizzoma's contribution to support "attributes". (They
>>> call
>>> > > "params" as of now but the ideia is the same)
>>> > > - Create sample rich text editor (using Rizzoma's editor, Halo or
>>> any other
>>> > > text-editor - it would be great to have an editor that doesn't
>>> depend on
>>> > > content editable - perhaps extracting Wave's editor and providing a
>>> pure JS
>>> > > API )
>>> > > - Support Wave's model ? (conversation, blips, etc...)
>>> > Wave's model is quite complicated. I'm not sure how much of it we
>>> > really need. Eg, wave has full XML support (arbitrarily nested
>>> > elements with attributes) as well as rich text annotations, which are
>>> > orthogonal to the XML structure. I think thats too much. I'd be happy
>>> > with just supporting one or the other.
>>> The json stuff in ShareJS
> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>> Yeah, I think if you're going to complain at least suggest a substantial
>> change, like an Erlang server implementation.
>> "C-" for effort.
>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>> I think you've missed the point of CoffeeScript.
>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>> It's unfortunate that this is written is CoffeeScript. It's a strange
>>> choice for a revolutionary product -- to intentionally exclude the majority
>>> of developers, and to convict those remaining to debug hell.
>>> Such brilliance, dulled. That JG is that brilliant is the only reason we
>>> see this at all.
>>> The proper thing is to fork the project into a JS-only initiative,
>>> properly annotate it, and invite developers.
> It's pretty terrible to lord your "precious paid-time contributions" over
> a free/open source project on the basis of the language used to implement
> it.
> If the authors willing to put in the time are happy with CS, it's going to
> be in CS. That's the nature of the beast.
> If you want pure-JS, put your money where your damn mouth is and show us
> the code.
> On Tue, Jun 19, 2012 at 6:48 AM, Sandro Pasquali <spasqu...@gmail.com>wrote:
>> Sigh.
>> Let me give you a concrete example. This should help you understand the
>> very simple point I made. I'm assuming you're actually interested in being
>> helpful.
>> Our team is growing. We build diverse products in a very large space
>> which demands precision and realtime performance. As such, NodeJS has
>> entered into our conversation, and via that pathway, so has ShareJS.
>> It is an exciting time for realtime, collaborative applications. With
>> Joseph, I want this new niche to become a big niche and maybe even a huge
>> new initiative that will bring even more excitement (and fun, and profit)
>> to the technology sector (
>> https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)
>> But collaboration isn't just a buzzword: applied correctly, it can
>> greatly improve the user experience, team dynamics, strategy, and other
>> business needs for those of us who are building the software products of
>> the future.
>> In order to explore these ideas our team constructed a collaborative
>> editing environment using ShareJS, which we now use internally, and when
>> ready, will release as a full-fledged (and open) product.
>> We do not have anyone on our team who writes Coffeescript. Not because we
>> think it is stupid, or a trend, or we like to complain about the meanies
>> who innovate. We love those meanies! It is also not because we don't
>> "understand" CS, or aren't competent or hip enough to grasp indentation.
>> Just three of many reasons:
>> 1. We don't have anyone who writes CS. So we can't usefully contribute to
>> CS projects. You (might) be able to grasp, given what we are currently
>> working on (and which libraries we are using), why that fact is relevant to
>> this conversation.
>> 2. We are a profit-driven company that does not spend resources
>> uselessly. A convincing business case has yet to be made to me
>> demonstrating the benefit of taking my team off of servicing our customers
>> (fixing bugs, feature care, new products) and learning another way to write
>> code in JS (amazingly, they are really quite good at writing it the old
>> fashioned way).
>> 3. There is clear and unmistakable preponderance of JS coders vs. CS
>> coders. This would put costly strain on our recruiting efforts, which may
>> even put us in the terrible position of not being able to control peer
>> quality at the source (careful selection of team members) due to a
>> desperate need for hands. I do not want to hire anyone for the wrong
>> reasons, (and neither do you).
>> Consider truth: a small fraction of a developer's time is spent writing
>> new code.
>> Consider why: mature languages offer the lovely benefit of a vast,
>> existing, codebase which probably already solves that problem. Every time I
>> hear a CS person argue for DRY it kills me a little inside.
>> Consider analysis: What is *advantage* of the compile step? What is the
>> *advantage* of losing existing IDE tools (mainly their debugging features)?
>> What is the *advantage* of having a CS coder on your staff (it isn't speed
>> -- that is a red herring. See previous.)? How would you argue for budgeting
>> the additional training and recruiting costs to your CEO? What is the
>> *advantage* of bifurcating your development process (given all that JS code
>> that powers your existing systems)?
>> Consider the point: When I want to encourage contributions to my OS JS
>> project (which this is), why would I make it difficult for JS coders to
>> contribute? This is a great place to think about what I've written in the
>> context of *the point of this entire thread* : why is it that this project
>> has so little activity? Or better: how can we make it more active? Because
>> it should be. Because it is brilliant and timely and effervescent.
>> I'm suggesting not only a substantial change, but an essential change.
>> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>>> Yeah, I think if you're going to complain at least suggest a substantial
>>> change, like an Erlang server implementation.
>>> "C-" for effort.
>>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>>> I think you've missed the point of CoffeeScript.
>>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>>> It's unfortunate that this is written is CoffeeScript. It's a strange
>>>> choice for a revolutionary product -- to intentionally exclude the majority
>>>> of developers, and to convict those remaining to debug hell.
>>>> Such brilliance, dulled. That JG is that brilliant is the only reason
>>>> we see this at all.
>>>> The proper thing is to fork the project into a JS-only initiative,
>>>> properly annotate it, and invite developers.
>>>> In fact...
>>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>>> For reference... this is a discussion about brunch's approach to
>>>> plugins:
>>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com>
>>>> escreveu:
>>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson.si...@gmail.com>
>>>> wrote:
>>>> > > So, to sum up, my roadmap proposal would be something like:
>>>> > > - Promote ShareJS to top level at GitHub
>>>> > Sure.
>>>> Great!
>>>> > > - Define a repo structure and guidelines for addons and samples
>>>> > Do you think that would help? I'm a little biased, but I think the
>>>> > repo structure is fairly self explanatory.
>>>> This should probably come after the next point... the idea is to define
>>>> a structure for addons... the repo structure for ShareJS is fine.
>>>> > There's a fair bit of thinking we have to do here, about exactly how
>>>> > sharejs should be structured. I'm not too happy with how its
>>>> > structured at the moment - I feel like sharejs is trying to do too
>>>> > much. I'd be interested to see proposals for how it should be
>>>> > rewritten.
>>>> Etherpad Lite has plugins using npm so we could try something like
>>>> that... break up ShareJS into modules and then work on each of those to
>>>> provide proper abstractions and promote code reuse in new contributed
>>>> modules.
>>>> Projects like brunch allow you to choose the plugins you want to use
>>>> just by adding them to your package.json... these are just two examples but
>>>> i'm sure there are several other approaches to choose from.
>>>> > Yep. I've been promising this for months, and I keep getting
>>>> > distracted. We'll get there.
>>>> Not sure you have donations set up but you should... i understand that
>>>> these days there's just so many neat stuff to do and all hobby projects get
>>>> to a point they feel like an obligation... perhaps we could come up with a
>>>> neat project based on ShareJS for motivating.. how about some sort of game?
>>>> Or a ptp version using webrtc's peerconnection?
>>>> > > - Create sample with participants and cursors (something like
>>>> MarkdownR but
>>>> > > with list of participants and cursor positions)
>>>> > > - Refactor rizzoma's contribution to support "attributes". (They
>>>> call
>>>> > > "params" as of now but the ideia is the same)
>>>> > > - Create sample rich text editor (using Rizzoma's editor, Halo or
>>>> any other
>>>> > > text-editor - it would be great to have an editor that doesn't
>>>> depend on
>>>> > > content editable - perhaps extracting Wave's editor and providing a
>>>> pure JS
>>>> > > API )
>>>> > > - Support Wave's model ? (conversation, blips, etc...)
>>>> > Wave's model is quite complicated. I'm not sure how much of it we
>>>> > really need. Eg, wave has full XML support (arbitrarily nested
>>>> > elements with attributes) as well as rich text annotations, which are
>>>> > orthogonal to the XML structure. I think thats too much. I'd be happy
>>>> > with just supporting one or the other.
>>>> The json stuff in ShareJS
>> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>>> Yeah, I think if you're going to complain at least
This is getting a bit offtopic so we should probably move this discussion to a new post.
Still, I don't see any advantage of JS over CS. The trend is polyglot programming, just use the right tool for the job and JS is becoming the VM for the web so this is like saying "you should have written it in assembly, all that C/C++/... stuff is just adding more complexity to the code base". The motto of CS is CS is just JS so there's nothing stopping you from extending ShareJS with pure JS and if you want to contribute back to the project just publish your work somewhere and someone will gladly port it over to CS (even if it's just a mater of using http://js2coffee.org/)
A port to GWT or Dart is a lot more interesting (specially the latter). Static typing or type checking along with proper tooling support would make it worth while and in the end both of these compile down to JS.
On Wednesday, June 20, 2012 9:51:15 AM UTC+1, Collin Miller wrote:
> If we can't find anybody willing to re-write the whole thing in JS I had > this idea.
> fork it and run:
> coffee -co lib/ src/
> Now you've got a *very clean* pure-js implementation you can work on > without blowing up your cost structure. > And debugging works great.
> I will personally rewrite your patches in coffeescript to get them into > ShareJS proper. For free.
> I'm 100% serious and extend this offer to anybody else who wants to > contribute but can't be bothered to deal with a little coffee script.
> On Wed, Jun 20, 2012 at 3:14 AM, Collin Miller <collintmil...@gmail.com>wrote:
>> It's pretty terrible to lord your "precious paid-time contributions" over >> a free/open source project on the basis of the language used to implement >> it.
>> If the authors willing to put in the time are happy with CS, it's going >> to be in CS. That's the nature of the beast.
>> If you want pure-JS, put your money where your damn mouth is and show us >> the code.
>> On Tue, Jun 19, 2012 at 6:48 AM, Sandro Pasquali <spasqu...@gmail.com>wrote:
>>> Sigh.
>>> Let me give you a concrete example. This should help you understand the >>> very simple point I made. I'm assuming you're actually interested in being >>> helpful.
>>> Our team is growing. We build diverse products in a very large space >>> which demands precision and realtime performance. As such, NodeJS has >>> entered into our conversation, and via that pathway, so has ShareJS.
>>> It is an exciting time for realtime, collaborative applications. With >>> Joseph, I want this new niche to become a big niche and maybe even a huge >>> new initiative that will bring even more excitement (and fun, and profit) >>> to the technology sector ( >>> https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)
>>> But collaboration isn't just a buzzword: applied correctly, it can >>> greatly improve the user experience, team dynamics, strategy, and other >>> business needs for those of us who are building the software products of >>> the future.
>>> In order to explore these ideas our team constructed a collaborative >>> editing environment using ShareJS, which we now use internally, and when >>> ready, will release as a full-fledged (and open) product.
>>> We do not have anyone on our team who writes Coffeescript. Not because >>> we think it is stupid, or a trend, or we like to complain about the meanies >>> who innovate. We love those meanies! It is also not because we don't >>> "understand" CS, or aren't competent or hip enough to grasp indentation. >>> Just three of many reasons:
>>> 1. We don't have anyone who writes CS. So we can't usefully contribute >>> to CS projects. You (might) be able to grasp, given what we are currently >>> working on (and which libraries we are using), why that fact is relevant to >>> this conversation. >>> 2. We are a profit-driven company that does not spend resources >>> uselessly. A convincing business case has yet to be made to me >>> demonstrating the benefit of taking my team off of servicing our customers >>> (fixing bugs, feature care, new products) and learning another way to write >>> code in JS (amazingly, they are really quite good at writing it the old >>> fashioned way). >>> 3. There is clear and unmistakable preponderance of JS coders vs. CS >>> coders. This would put costly strain on our recruiting efforts, which may >>> even put us in the terrible position of not being able to control peer >>> quality at the source (careful selection of team members) due to a >>> desperate need for hands. I do not want to hire anyone for the wrong >>> reasons, (and neither do you).
>>> Consider truth: a small fraction of a developer's time is spent writing >>> new code.
>>> Consider why: mature languages offer the lovely benefit of a vast, >>> existing, codebase which probably already solves that problem. Every time I >>> hear a CS person argue for DRY it kills me a little inside.
>>> Consider analysis: What is *advantage* of the compile step? What is the >>> *advantage* of losing existing IDE tools (mainly their debugging features)? >>> What is the *advantage* of having a CS coder on your staff (it isn't speed >>> -- that is a red herring. See previous.)? How would you argue for budgeting >>> the additional training and recruiting costs to your CEO? What is the >>> *advantage* of bifurcating your development process (given all that JS code >>> that powers your existing systems)?
>>> Consider the point: When I want to encourage contributions to my OS JS >>> project (which this is), why would I make it difficult for JS coders to >>> contribute? This is a great place to think about what I've written in the >>> context of *the point of this entire thread* : why is it that this project >>> has so little activity? Or better: how can we make it more active? Because >>> it should be. Because it is brilliant and timely and effervescent.
>>> I'm suggesting not only a substantial change, but an essential change.
>>> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>>>> Yeah, I think if you're going to complain at least suggest a >>>> substantial change, like an Erlang server implementation.
>>>> "C-" for effort.
>>>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>>>> I think you've missed the point of CoffeeScript.
>>>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>>>> It's unfortunate that this is written is CoffeeScript. It's a strange >>>>> choice for a revolutionary product -- to intentionally exclude the majority >>>>> of developers, and to convict those remaining to debug hell.
>>>>> Such brilliance, dulled. That JG is that brilliant is the only reason >>>>> we see this at all.
>>>>> The proper thing is to fork the project into a JS-only initiative, >>>>> properly annotate it, and invite developers.
>>>>> In fact...
>>>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>>>> For reference... this is a discussion about brunch's approach to >>>>> plugins:
>>>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com> >>>>> escreveu:
>>>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva < >>>>> nelson.si...@gmail.com> wrote: >>>>> > > So, to sum up, my roadmap proposal would be something like:
>>>>> > > - Promote ShareJS to top level at GitHub
>>>>> > Sure.
>>>>> Great!
>>>>> > > - Define a repo structure and guidelines for addons and samples
>>>>> > Do you think that would help? I'm a little biased, but I think the >>>>> > repo structure is fairly self explanatory.
>>>>> This should probably come after the next point... the idea is to >>>>> define a structure for addons... the repo structure for ShareJS is fine.
>>>>> > There's a fair bit of thinking we have to do here, about exactly how >>>>> > sharejs should be structured. I'm not too happy with how its >>>>> > structured at the moment - I feel like sharejs is trying to do too >>>>> > much. I'd be interested to see proposals for how it should be >>>>> > rewritten.
>>>>> Etherpad Lite has plugins using npm so we could try something like >>>>> that... break up ShareJS into modules and then work on each of those to >>>>> provide proper abstractions and promote code reuse in new contributed >>>>> modules. >>>>> Projects like brunch allow you to choose the plugins you want to use >>>>> just by adding them to your package.json... these are just two examples but >>>>> i'm sure there are several other approaches to choose from.
>>>>> > Yep. I've been promising this for months, and I keep getting >>>>> > distracted. We'll get there.
>>>>> Not sure you have donations set up but you should... i understand that >>>>> these days there's just so many neat stuff to do and all hobby projects get >>>>> to a point they feel like an obligation... perhaps we could come up with a >>>>> neat project based on ShareJS for motivating.. how about some sort of game? >>>>> Or a ptp version using webrtc's peerconnection?
>>>>> > > - Create sample with participants and cursors (something like >>>>> MarkdownR but >>>>> > > with list of participants and cursor
I'm glad Joseph took the essential component of Wave and created a simple
way for js programmers to get started with realtime OT. It's a great
project that I was able to deploy on a server to teach a friend some
programming.
The project is well-designed, well-documented, with many examples. How much
better can it get?
I think the roadmap should be whatever Joseph feels inspired to do, he
should do that. Apache Wave has tried all sorts of roadmaps and planning,
and still the Wiki and examples don't hold a candle to ShareJS (despite
being a much older, larger project).
On Wed, Jun 20, 2012 at 2:08 AM, Nelson Silva <nelson.si...@gmail.com>wrote:
> This is getting a bit offtopic so we should probably move this discussion
> to a new post.
> Still, I don't see any advantage of JS over CS. The trend is polyglot
> programming, just use the right tool for the job and JS is becoming the VM
> for the web so this is like saying "you should have written it in assembly,
> all that C/C++/... stuff is just adding more complexity to the code base".
> The motto of CS is CS is just JS so there's nothing stopping you from
> extending ShareJS with pure JS and if you want to contribute back to the
> project just publish your work somewhere and someone will gladly port it
> over to CS (even if it's just a mater of using http://js2coffee.org/)
> A port to GWT or Dart is a lot more interesting (specially the latter).
> Static typing or type checking along with proper tooling support would make
> it worth while and in the end both of these compile down to JS.
> On Wednesday, June 20, 2012 9:51:15 AM UTC+1, Collin Miller wrote:
>> If we can't find anybody willing to re-write the whole thing in JS I had
>> this idea.
>> fork it and run:
>> coffee -co lib/ src/
>> Now you've got a *very clean* pure-js implementation you can work on
>> without blowing up your cost structure.
>> And debugging works great.
>> I will personally rewrite your patches in coffeescript to get them into
>> ShareJS proper. For free.
>> I'm 100% serious and extend this offer to anybody else who wants to
>> contribute but can't be bothered to deal with a little coffee script.
>> On Wed, Jun 20, 2012 at 3:14 AM, Collin Miller <collintmil...@gmail.com>wrote:
>>> It's pretty terrible to lord your "precious paid-time contributions"
>>> over a free/open source project on the basis of the language used to
>>> implement it.
>>> If the authors willing to put in the time are happy with CS, it's going
>>> to be in CS. That's the nature of the beast.
>>> If you want pure-JS, put your money where your damn mouth is and show us
>>> the code.
>>> On Tue, Jun 19, 2012 at 6:48 AM, Sandro Pasquali <spasqu...@gmail.com>wrote:
>>>> Sigh.
>>>> Let me give you a concrete example. This should help you understand the
>>>> very simple point I made. I'm assuming you're actually interested in being
>>>> helpful.
>>>> Our team is growing. We build diverse products in a very large space
>>>> which demands precision and realtime performance. As such, NodeJS has
>>>> entered into our conversation, and via that pathway, so has ShareJS.
>>>> It is an exciting time for realtime, collaborative applications. With
>>>> Joseph, I want this new niche to become a big niche and maybe even a huge
>>>> new initiative that will bring even more excitement (and fun, and profit)
>>>> to the technology sector (https://plus.google.com/** >>>> 116904230181415286707/posts/**MUVpmkAFSd1<https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1>
>>>> )
>>>> But collaboration isn't just a buzzword: applied correctly, it can
>>>> greatly improve the user experience, team dynamics, strategy, and other
>>>> business needs for those of us who are building the software products of
>>>> the future.
>>>> In order to explore these ideas our team constructed a collaborative
>>>> editing environment using ShareJS, which we now use internally, and when
>>>> ready, will release as a full-fledged (and open) product.
>>>> We do not have anyone on our team who writes Coffeescript. Not because
>>>> we think it is stupid, or a trend, or we like to complain about the meanies
>>>> who innovate. We love those meanies! It is also not because we don't
>>>> "understand" CS, or aren't competent or hip enough to grasp indentation.
>>>> Just three of many reasons:
>>>> 1. We don't have anyone who writes CS. So we can't usefully contribute
>>>> to CS projects. You (might) be able to grasp, given what we are currently
>>>> working on (and which libraries we are using), why that fact is relevant to
>>>> this conversation.
>>>> 2. We are a profit-driven company that does not spend resources
>>>> uselessly. A convincing business case has yet to be made to me
>>>> demonstrating the benefit of taking my team off of servicing our customers
>>>> (fixing bugs, feature care, new products) and learning another way to write
>>>> code in JS (amazingly, they are really quite good at writing it the old
>>>> fashioned way).
>>>> 3. There is clear and unmistakable preponderance of JS coders vs. CS
>>>> coders. This would put costly strain on our recruiting efforts, which may
>>>> even put us in the terrible position of not being able to control peer
>>>> quality at the source (careful selection of team members) due to a
>>>> desperate need for hands. I do not want to hire anyone for the wrong
>>>> reasons, (and neither do you).
>>>> Consider truth: a small fraction of a developer's time is spent writing
>>>> new code.
>>>> Consider why: mature languages offer the lovely benefit of a vast,
>>>> existing, codebase which probably already solves that problem. Every time I
>>>> hear a CS person argue for DRY it kills me a little inside.
>>>> Consider analysis: What is *advantage* of the compile step? What is the
>>>> *advantage* of losing existing IDE tools (mainly their debugging features)?
>>>> What is the *advantage* of having a CS coder on your staff (it isn't speed
>>>> -- that is a red herring. See previous.)? How would you argue for budgeting
>>>> the additional training and recruiting costs to your CEO? What is the
>>>> *advantage* of bifurcating your development process (given all that JS code
>>>> that powers your existing systems)?
>>>> Consider the point: When I want to encourage contributions to my OS JS
>>>> project (which this is), why would I make it difficult for JS coders to
>>>> contribute? This is a great place to think about what I've written in the
>>>> context of *the point of this entire thread* : why is it that this project
>>>> has so little activity? Or better: how can we make it more active? Because
>>>> it should be. Because it is brilliant and timely and effervescent.
>>>> I'm suggesting not only a substantial change, but an essential change.
>>>> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>>>>> Yeah, I think if you're going to complain at least suggest a
>>>>> substantial change, like an Erlang server implementation.
>>>>> "C-" for effort.
>>>>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>>>>> I think you've missed the point of CoffeeScript.
>>>>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>>>>> It's unfortunate that this is written is CoffeeScript. It's a strange
>>>>>> choice for a revolutionary product -- to intentionally exclude the majority
>>>>>> of developers, and to convict those remaining to debug hell.
>>>>>> Such brilliance, dulled. That JG is that brilliant is the only reason
>>>>>> we see this at all.
>>>>>> The proper thing is to fork the project into a JS-only initiative,
>>>>>> properly annotate it, and invite developers.
>>>>>> In fact...
>>>>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>>>>> For reference... this is a discussion about brunch's approach to
>>>>>> plugins:
>>>>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com>
>>>>>> escreveu:
>>>>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <
>>>>>> nelson.si...@gmail.com> wrote:
>>>>>> > > So, to sum up, my roadmap proposal would be something like:
>>>>>> > > - Promote ShareJS to top level at GitHub
>>>>>> > Sure.
>>>>>> Great!
>>>>>> > > - Define a repo structure and guidelines for addons and samples
>>>>>> > Do you think that would help? I'm a little biased, but I think the
>>>>>> > repo structure is fairly self explanatory.
>>>>>> This should probably come after the next point... the idea is to
>>>>>> define a structure for addons... the repo structure for ShareJS is fine.
>>>>>> > There's a fair bit of thinking we have to do here, about exactly how
>>>>>> > sharejs should be structured. I'm not too happy with how its
>>>>>> > structured at the moment - I feel like sharejs is trying to do too
>>>>>> > much. I'd be interested to see proposals for how it should be
>>>>>> > rewritten.
>>>>>> Etherpad Lite has plugins using npm so we could try something like
>>>>>> that... break up ShareJS into modules and then work on each of those to
>>>>>> provide proper abstractions and promote code reuse in new contributed
>>>>>> modules.
>>>>>> Projects like brunch allow you to choose the
I'm a javascripter, and certainly not a coffee scripter, but I can see
that coffee script is really
nothing but javascript with 'a queer makeover' but most of the
semantics are still the same
on the inside. a competent javascripter could pretty easily hit the
ground running with coffee script.
it would probably be easier to just learn it than to try and get
ShareJs to change.
On Thu, Jun 21, 2012 at 6:56 AM, Kai Chang <kai.s.ch...@gmail.com> wrote:
> I'm glad Joseph took the essential component of Wave and created a simple
> way for js programmers to get started with realtime OT. It's a great
> project that I was able to deploy on a server to teach a friend some
> programming.
> The project is well-designed, well-documented, with many examples. How much
> better can it get?
> I think the roadmap should be whatever Joseph feels inspired to do, he
> should do that. Apache Wave has tried all sorts of roadmaps and planning,
> and still the Wiki and examples don't hold a candle to ShareJS (despite
> being a much older, larger project).
> On Wed, Jun 20, 2012 at 2:08 AM, Nelson Silva <nelson.si...@gmail.com>
> wrote:
>> This is getting a bit offtopic so we should probably move this discussion
>> to a new post.
>> Still, I don't see any advantage of JS over CS. The trend is polyglot
>> programming, just use the right tool for the job and JS is becoming the VM
>> for the web so this is like saying "you should have written it in assembly,
>> all that C/C++/... stuff is just adding more complexity to the code base".
>> The motto of CS is CS is just JS so there's nothing stopping you from
>> extending ShareJS with pure JS and if you want to contribute back to the
>> project just publish your work somewhere and someone will gladly port it
>> over to CS (even if it's just a mater of using http://js2coffee.org/)
>> A port to GWT or Dart is a lot more interesting (specially the latter).
>> Static typing or type checking along with proper tooling support would make
>> it worth while and in the end both of these compile down to JS.
>> On Wednesday, June 20, 2012 9:51:15 AM UTC+1, Collin Miller wrote:
>>> If we can't find anybody willing to re-write the whole thing in JS I had
>>> this idea.
>>> fork it and run:
>>> coffee -co lib/ src/
>>> Now you've got a very clean pure-js implementation you can work on
>>> without blowing up your cost structure.
>>> And debugging works great.
>>> I will personally rewrite your patches in coffeescript to get them into
>>> ShareJS proper. For free.
>>> I'm 100% serious and extend this offer to anybody else who wants to
>>> contribute but can't be bothered to deal with a little coffee script.
>>> On Wed, Jun 20, 2012 at 3:14 AM, Collin Miller <collintmil...@gmail.com>
>>> wrote:
>>>> It's pretty terrible to lord your "precious paid-time contributions"
>>>> over a free/open source project on the basis of the language used to
>>>> implement it.
>>>> If the authors willing to put in the time are happy with CS, it's going
>>>> to be in CS. That's the nature of the beast.
>>>> If you want pure-JS, put your money where your damn mouth is and show us
>>>> the code.
>>>> On Tue, Jun 19, 2012 at 6:48 AM, Sandro Pasquali <spasqu...@gmail.com>
>>>> wrote:
>>>>> Sigh.
>>>>> Let me give you a concrete example. This should help you understand the
>>>>> very simple point I made. I'm assuming you're actually interested in being
>>>>> helpful.
>>>>> Our team is growing. We build diverse products in a very large space
>>>>> which demands precision and realtime performance. As such, NodeJS has
>>>>> entered into our conversation, and via that pathway, so has ShareJS.
>>>>> It is an exciting time for realtime, collaborative applications. With
>>>>> Joseph, I want this new niche to become a big niche and maybe even a huge
>>>>> new initiative that will bring even more excitement (and fun, and profit) to
>>>>> the technology sector
>>>>> (https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)
>>>>> But collaboration isn't just a buzzword: applied correctly, it can
>>>>> greatly improve the user experience, team dynamics, strategy, and other
>>>>> business needs for those of us who are building the software products of the
>>>>> future.
>>>>> In order to explore these ideas our team constructed a collaborative
>>>>> editing environment using ShareJS, which we now use internally, and when
>>>>> ready, will release as a full-fledged (and open) product.
>>>>> We do not have anyone on our team who writes Coffeescript. Not because
>>>>> we think it is stupid, or a trend, or we like to complain about the meanies
>>>>> who innovate. We love those meanies! It is also not because we don't
>>>>> "understand" CS, or aren't competent or hip enough to grasp indentation.
>>>>> Just three of many reasons:
>>>>> 1. We don't have anyone who writes CS. So we can't usefully contribute
>>>>> to CS projects. You (might) be able to grasp, given what we are currently
>>>>> working on (and which libraries we are using), why that fact is relevant to
>>>>> this conversation.
>>>>> 2. We are a profit-driven company that does not spend resources
>>>>> uselessly. A convincing business case has yet to be made to me demonstrating
>>>>> the benefit of taking my team off of servicing our customers (fixing bugs,
>>>>> feature care, new products) and learning another way to write code in JS
>>>>> (amazingly, they are really quite good at writing it the old fashioned way).
>>>>> 3. There is clear and unmistakable preponderance of JS coders vs. CS
>>>>> coders. This would put costly strain on our recruiting efforts, which may
>>>>> even put us in the terrible position of not being able to control peer
>>>>> quality at the source (careful selection of team members) due to a desperate
>>>>> need for hands. I do not want to hire anyone for the wrong reasons, (and
>>>>> neither do you).
>>>>> Consider truth: a small fraction of a developer's time is spent writing
>>>>> new code.
>>>>> Consider why: mature languages offer the lovely benefit of a vast,
>>>>> existing, codebase which probably already solves that problem. Every time I
>>>>> hear a CS person argue for DRY it kills me a little inside.
>>>>> Consider analysis: What is *advantage* of the compile step? What is the
>>>>> *advantage* of losing existing IDE tools (mainly their debugging features)?
>>>>> What is the *advantage* of having a CS coder on your staff (it isn't speed
>>>>> -- that is a red herring. See previous.)? How would you argue for budgeting
>>>>> the additional training and recruiting costs to your CEO? What is the
>>>>> *advantage* of bifurcating your development process (given all that JS code
>>>>> that powers your existing systems)?
>>>>> Consider the point: When I want to encourage contributions to my OS JS
>>>>> project (which this is), why would I make it difficult for JS coders to
>>>>> contribute? This is a great place to think about what I've written in the
>>>>> context of *the point of this entire thread* : why is it that this project
>>>>> has so little activity? Or better: how can we make it more active? Because
>>>>> it should be. Because it is brilliant and timely and effervescent.
>>>>> I'm suggesting not only a substantial change, but an essential change.
>>>>> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>>>>>> Yeah, I think if you're going to complain at least suggest a
>>>>>> substantial change, like an Erlang server implementation.
>>>>>> "C-" for effort.
>>>>>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>>>>>> I think you've missed the point of CoffeeScript.
>>>>>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>>>>>> It's unfortunate that this is written is CoffeeScript. It's a strange
>>>>>>> choice for a revolutionary product -- to intentionally exclude the majority
>>>>>>> of developers, and to convict those remaining to debug hell.
>>>>>>> Such brilliance, dulled. That JG is that brilliant is the only reason
>>>>>>> we see this at all.
>>>>>>> The proper thing is to fork the project into a JS-only initiative,
>>>>>>> properly annotate it, and invite developers.
>>>>>>> In fact...
>>>>>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>>>>>> For reference... this is a discussion about brunch's approach to
>>>>>>> plugins:
>>>>>>> No dia 5 de Mai de 2012 11:57, "Nelson Silva"
>>>>>>> <nelson.si...@gmail.com> escreveu:
>>>>>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com>
>>>>>>> escreveu:
>>>>>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva
>>>>>>> > <nelson.si...@gmail.com> wrote:
>>>>>>> > > So, to sum up, my roadmap proposal would be something like:
>>>>>>> > > - Promote ShareJS to top level at GitHub
>>>>>>> > Sure.
>>>>>>> Great!
>>>>>>> > > - Define a repo structure and guidelines for addons and samples
>>>>>>> > Do you think that would help? I'm a little biased, but I think the
>>>>>>> > repo structure is fairly self explanatory.
>>>>>>> This should probably come after the next point... the idea is to
>>>>>>> define a structure for addons... the repo structure for ShareJS is fine.
On Tuesday, June 19, 2012 1:48:40 PM UTC+2, Sandro Pasquali wrote:
> Sigh.
> Let me give you a concrete example. This should help you understand the > very simple point I made. I'm assuming you're actually interested in being > helpful.
> Our team is growing. We build diverse products in a very large space which > demands precision and realtime performance. As such, NodeJS has entered > into our conversation, and via that pathway, so has ShareJS.
> It is an exciting time for realtime, collaborative applications. With > Joseph, I want this new niche to become a big niche and maybe even a huge > new initiative that will bring even more excitement (and fun, and profit) > to the technology sector ( > https://plus.google.com/116904230181415286707/posts/MUVpmkAFSd1)
> But collaboration isn't just a buzzword: applied correctly, it can greatly > improve the user experience, team dynamics, strategy, and other business > needs for those of us who are building the software products of the future.
> In order to explore these ideas our team constructed a collaborative > editing environment using ShareJS, which we now use internally, and when > ready, will release as a full-fledged (and open) product.
> We do not have anyone on our team who writes Coffeescript. Not because we > think it is stupid, or a trend, or we like to complain about the meanies > who innovate. We love those meanies! It is also not because we don't > "understand" CS, or aren't competent or hip enough to grasp indentation. > Just three of many reasons:
> 1. We don't have anyone who writes CS. So we can't usefully contribute to > CS projects. You (might) be able to grasp, given what we are currently > working on (and which libraries we are using), why that fact is relevant to > this conversation. > 2. We are a profit-driven company that does not spend resources uselessly. > A convincing business case has yet to be made to me demonstrating the > benefit of taking my team off of servicing our customers (fixing bugs, > feature care, new products) and learning another way to write code in JS > (amazingly, they are really quite good at writing it the old fashioned way). > 3. There is clear and unmistakable preponderance of JS coders vs. CS > coders. This would put costly strain on our recruiting efforts, which may > even put us in the terrible position of not being able to control peer > quality at the source (careful selection of team members) due to a > desperate need for hands. I do not want to hire anyone for the wrong > reasons, (and neither do you).
> Consider truth: a small fraction of a developer's time is spent writing > new code.
> Consider why: mature languages offer the lovely benefit of a vast, > existing, codebase which probably already solves that problem. Every time I > hear a CS person argue for DRY it kills me a little inside.
> Consider analysis: What is *advantage* of the compile step? What is the > *advantage* of losing existing IDE tools (mainly their debugging features)? > What is the *advantage* of having a CS coder on your staff (it isn't speed > -- that is a red herring. See previous.)? How would you argue for budgeting > the additional training and recruiting costs to your CEO? What is the > *advantage* of bifurcating your development process (given all that JS code > that powers your existing systems)?
> Consider the point: When I want to encourage contributions to my OS JS > project (which this is), why would I make it difficult for JS coders to > contribute? This is a great place to think about what I've written in the > context of *the point of this entire thread* : why is it that this project > has so little activity? Or better: how can we make it more active? Because > it should be. Because it is brilliant and timely and effervescent.
> I'm suggesting not only a substantial change, but an essential change.
> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>> Yeah, I think if you're going to complain at least suggest a substantial >> change, like an Erlang server implementation.
>> "C-" for effort.
>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>> I think you've missed the point of CoffeeScript.
>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>> It's unfortunate that this is written is CoffeeScript. It's a strange >>> choice for a revolutionary product -- to intentionally exclude the majority >>> of developers, and to convict those remaining to debug hell.
>>> Such brilliance, dulled. That JG is that brilliant is the only reason we >>> see this at all.
>>> The proper thing is to fork the project into a JS-only initiative, >>> properly annotate it, and invite developers.
>>> In fact...
>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>> For reference... this is a discussion about brunch's approach to plugins:
>>> No dia 5 de Mai de 2012 03:41, "Joseph Gentle" <jose...@gmail.com> >>> escreveu:
>>> > On Tue, Apr 24, 2012 at 7:18 PM, Nelson Silva <nelson.si...@gmail.com> >>> wrote: >>> > > So, to sum up, my roadmap proposal would be something like:
>>> > > - Promote ShareJS to top level at GitHub
>>> > Sure.
>>> Great!
>>> > > - Define a repo structure and guidelines for addons and samples
>>> > Do you think that would help? I'm a little biased, but I think the >>> > repo structure is fairly self explanatory.
>>> This should probably come after the next point... the idea is to define >>> a structure for addons... the repo structure for ShareJS is fine.
>>> > There's a fair bit of thinking we have to do here, about exactly how >>> > sharejs should be structured. I'm not too happy with how its >>> > structured at the moment - I feel like sharejs is trying to do too >>> > much. I'd be interested to see proposals for how it should be >>> > rewritten.
>>> Etherpad Lite has plugins using npm so we could try something like >>> that... break up ShareJS into modules and then work on each of those to >>> provide proper abstractions and promote code reuse in new contributed >>> modules. >>> Projects like brunch allow you to choose the plugins you want to use >>> just by adding them to your package.json... these are just two examples but >>> i'm sure there are several other approaches to choose from.
>>> > Yep. I've been promising this for months, and I keep getting >>> > distracted. We'll get there.
>>> Not sure you have donations set up but you should... i understand that >>> these days there's just so many neat stuff to do and all hobby projects get >>> to a point they feel like an obligation... perhaps we could come up with a >>> neat project based on ShareJS for motivating.. how about some sort of game? >>> Or a ptp version using webrtc's peerconnection?
>>> > > - Create sample with participants and cursors (something like >>> MarkdownR but >>> > > with list of participants and cursor positions) >>> > > - Refactor rizzoma's contribution to support "attributes". (They >>> call >>> > > "params" as of now but the ideia is the same) >>> > > - Create sample rich text editor (using Rizzoma's editor, Halo or >>> any other >>> > > text-editor - it would be great to have an editor that doesn't >>> depend on >>> > > content editable - perhaps extracting Wave's editor and providing a >>> pure JS >>> > > API ) >>> > > - Support Wave's model ? (conversation, blips, etc...)
>>> > Wave's model is quite complicated. I'm not sure how much of it we >>> > really need. Eg, wave has full XML support (arbitrarily nested >>> > elements with attributes) as well as rich text annotations, which are >>> > orthogonal to the XML structure. I think thats too much. I'd be happy >>> > with just supporting one or the other.
>>> The json stuff in ShareJS
> On Friday, June 15, 2012 7:49:58 PM UTC-4, Collin Miller wrote:
>> Yeah, I think if you're going to complain at least suggest a substantial >> change, like an Erlang server implementation.
>> "C-" for effort.
>> On Friday, June 15, 2012, Jeremy Apthorp wrote:
>>> I think you've missed the point of CoffeeScript.
>>> On 15/06/2012, at 23:01, spasquali <spasqu...@embarkcorp.com> wrote:
>>> It's unfortunate that this is written is CoffeeScript. It's a strange >>> choice for a revolutionary product -- to intentionally exclude the majority >>> of developers, and to convict those remaining to debug hell.
>>> Such brilliance, dulled. That JG is that brilliant is the only reason we >>> see this at all.
>>> The proper thing is to fork the project into a JS-only initiative, >>> properly annotate it, and invite developers.
>>> In fact...
>>> On Saturday, May 5, 2012 3:22:36 PM UTC-4, Nelson Silva wrote:
>>> For reference... this is a discussion about brunch's approach to plugins:
CF? I still struggle to understand why people are reluctant to embrace polyglot programming... is it because you invest in lots of meaningless Java / .net certifications? Are you afraid to end up with unmantainable code? Do you still believe in code reuse? I can understand the complexity of a big codebase written in a dynamic language but ShareJS is simple, concise and well tested so CS fits it like a glove. I did a quick port of the text OT stuff to Dart in a couple of days and will try to get the JSON stuff as well so if you have a team available you can probably port it to whatever language you need in no time. You have OT code from etherpad, apache wave, collide, etc... all freely available as well so just pick whatever you want and get it working. I have ShareJS working on rhinojs on vert.x so i can dev modules in any language... just stop with the CS vs JS debate... i would pick CS any day over JS just because it looks and feels better to me but hell, some people even like php so it's really a mater of opinion. Joseph did a great job with ShareJS i think it is better because of CS. If you'd rather use JS look at Etherpad Lite, they even have attributes. If you're into GWT you have Apache Wave and collide.
The problem is that for me, now, CS is not a language worth learning. I'll never use (at least in a foresable future) CF as the language for ANY of my project; I'm perfectly at ease with JS, and I don't need any "dumb down" layers. I need to eventually find good JS programmers to help me out, not CF. So I'd need to learn it JUST to use someone else's project, even if the project is in... JS! I know that this applies with any other languages (using SOLR? Learn Java...), but at least learning a bit of Java makes sense.
We're going to have to learn a lot more JS in the next couple of years (EC6, anyone?), writing compatibility layers, addressing browser issues... do we really need to get our life even more complicated with a level of (fake) abstraction, with a new syntax, written by same random guy? I don't think so.
On Monday, July 30, 2012 3:03:08 AM UTC+2, Nelson Silva wrote:
> CF? > I still struggle to understand why people are reluctant to embrace > polyglot programming... is it because you invest in lots of meaningless > Java / .net certifications? Are you afraid to end up with unmantainable > code? Do you still believe in code reuse? I can understand the complexity > of a big codebase written in a dynamic language but ShareJS is simple, > concise and well tested so CS fits it like a glove. I did a quick port of > the text OT stuff to Dart in a couple of days and will try to get the JSON > stuff as well so if you have a team available you can probably port it to > whatever language you need in no time. > You have OT code from etherpad, apache wave, collide, etc... all freely > available as well so just pick whatever you want and get it working. I have > ShareJS working on rhinojs on vert.x so i can dev modules in any > language... just stop with the CS vs JS debate... i would pick CS any day > over JS just because it looks and feels better to me but hell, some people > even like php so it's really a mater of opinion. > Joseph did a great job with ShareJS i think it is better because of CS. If > you'd rather use JS look at Etherpad Lite, they even have attributes. If > you're into GWT you have Apache Wave and collide.
Unfortunately for you, the web is moving toward polyglot programming with javascript as the 'runtime' (similar to the JVM as the runtime for Clojure, Scala and the like). Now that browsers are starting to support Source Maps, you'll start seeing much more experimentation in client-side browser languages, not less. Expect to see many more interesting projects that use languages that haven't even been invented yet.
If you really have an allergy to CS, you can do as Colin mentioned above and compile ShareJS into JS and use that directly. You'll find the code generated by CS to be really clean and readable (I was able to port the OT model to python directly from the CS, and add a tcp connection that could be used from non-web clients, and this is without much experience in either JS or CS).
On Monday, July 30, 2012 4:33:39 AM UTC-4, Claudio Cicali wrote:
> The problem is that for me, now, CS is not a language worth learning. I'll > never use (at least in a foresable future) CF as the language for ANY of my > project; I'm perfectly at ease with JS, and I don't need any "dumb down" > layers. I need to eventually find good JS programmers to help me out, not > CF. So I'd need to learn it JUST to use someone else's project, even if the > project is in... JS! I know that this applies with any other languages > (using SOLR? Learn Java...), but at least learning a bit of Java makes > sense.
> We're going to have to learn a lot more JS in the next couple of years > (EC6, anyone?), writing compatibility layers, addressing browser issues... > do we really need to get our life even more complicated with a level of > (fake) abstraction, with a new syntax, written by same random guy? I don't > think so.
Come on, CS takes like a couple of minutes to understand. Everyone who uses
it is/should be at ease with JS, it is but a subset to make it more
manageable. JS is very "forgiving" and i really believe you have to be a
ninja to grasp all its quirks.. prototipal inheritance, vars that get
promoted to outer scopes, dozens of different ways to get stuff done,
inconsistent behaviour between browsers, weird type conversions, etc,
etc... if we're stuck with it i really hope we get more of GWT, CS, Dart,
whatever...
Also, there's no need to learn CS to use ShareJS! You can extend it with
pure JS, you can wrap it in jsni and use it in gwt, you can wrap it in an
isolate and use it with Dart, you can run it with v8 and use it with c, c++
whatever, you can run it with rhino and get it on the jvm...
Don't learn JS or Java... learn programming! OO, functional, logical, try a
bit of Scala or haskell for true powerfull type systems, learn C to
understand pointers, try some asm just for fun, learn lisp or smalltalk to
understand where we come from and that the greatest languages have been
here for decades, play with prolog for something different, learn python,
ruby, see how rails and django brought some sense to jee just by keeping it
simple! Try Go, try lua, try Dart... and perhaps in the end you'll feel
like many... so many great languages and we got stuck with JS for the next
couple of years ! Even actionscript its ecma cousin is better...
No dia 30 de Jul de 2012 18:02, "Naveen Michaud-Agrawal" <
naveen.michaudagra...@gmail.com> escreveu:
> Unfortunately for you, the web is moving toward polyglot programming with
> javascript as the 'runtime' (similar to the JVM as the runtime for Clojure,
> Scala and the like). Now that browsers are starting to support Source Maps,
> you'll start seeing much more experimentation in client-side browser
> languages, not less. Expect to see many more interesting projects that use
> languages that haven't even been invented yet.
> If you really have an allergy to CS, you can do as Colin mentioned above
> and compile ShareJS into JS and use that directly. You'll find the code
> generated by CS to be really clean and readable (I was able to port the OT
> model to python directly from the CS, and add a tcp connection that could
> be used from non-web clients, and this is without much experience in either
> JS or CS).
> Naveen
> On Monday, July 30, 2012 4:33:39 AM UTC-4, Claudio Cicali wrote:
>> The problem is that for me, now, CS is not a language worth learning.
>> I'll never use (at least in a foresable future) CF as the language for ANY
>> of my project; I'm perfectly at ease with JS, and I don't need any "dumb
>> down" layers. I need to eventually find good JS programmers to help me out,
>> not CF. So I'd need to learn it JUST to use someone else's project, even if
>> the project is in... JS! I know that this applies with any other languages
>> (using SOLR? Learn Java...), but at least learning a bit of Java makes
>> sense.
>> We're going to have to learn a lot more JS in the next couple of years
>> (EC6, anyone?), writing compatibility layers, addressing browser issues...
>> do we really need to get our life even more complicated with a level of
>> (fake) abstraction, with a new syntax, written by same random guy? I don't
>> think so.
If you already know javascript, it takes about 2 hours to learn
coffeescript. Coffeescript introduces (almost) no semantic changes to
javascript. It takes longer to read & understand Javascript: The Good
Parts than it does to learn coffeescript. Its much easier to teach a
good javascript developer coffeescript than it is to teach a fresh
javascript & coffeescript programmer how to write good JS/CS.
But that isn't really why we're arguing here. Zed Shaw says it better
than I can:
"""
Imagine I break software development clients into two camps:
Collaborators and Customers. Now imagine I then break projects into
two categories of Implementation and Invention.
Collaborators will participate daily and know what's going on because
they are there and will usually pay variable price because of a higher
tolerance of risk. Customers just want something packaged, want it now,
and will only pay a fixed price and if it isn't perfect they'll bitch.
Implementations are things you've done a billion times or that you can
manufacture with a consistent process and have low risk and low
variability. Inventions are done different every time, require creative
thinking, adaptation to randomness and chaos, and generally are riskier
and variable.
In an ideal world, you pair Collaborators with Inventions, and
Customers with Implementations. The other combinations end in
disasters and you really only find them in the corporate world where
the force of tons of cash can make those bad mixes work anyway. In the
open source world where Darwin rules, the good projects gravitate
toward Collaborators+Inventions or Customers+Implementations, with the
former more common than the latter.
The reason some people might get upset at you is that you are saying
(or what they hear) is, "I'm a Customer dammit and I want my
Implementation planned with no risk now." That's ungrateful and
irritating and insults their hard work.
"""
(From http://lua-users.org/lists/lua-l/2007-12/msg00470.html )
ShareJS needs to balance the needs of these two camps. There's a lot
of creative design in ShareJS. But also, it needs to be stable so you
can actually use in your products. If its too planned, contributors
get bored and leave (like me!). But if its too unstable, the project
isn't actually useful.
I feel this struggle constantly in the code. The use of coffeescript
is a concession to creativity and learning - coffeescript is a fun
language to program in, and it makes me feel like a monster stomping
through tokyo. But I also want ShareJS to be stable and not break
between versions. Hence ShareJS has a bajillion lines of unit tests
and CI and whatnot. Unit tests mean ShareJS should never break. But
they're seriously annoying when I want to change the APIs (even
internal ones) because I have >2x as much code to change.
So yes, using coffeescript is a conceit to make the project more fun
to work on. If your developers don't like learning, fork the project,
compile out the coffeescript to javascript then clean it up. The
golden rule of coffeescript is that it maps 1-1 to javascript anyway,
so the JS is surprisingly readable (eg:
https://github.com/josephg/ShareJS/blob/master/webclient/textarea.js ). Its a bit of work maintaining your own fork, but if you've got a
staff I'm sure you can manage it. As a byproduct, you'll learn ShareJS
works internally, which will make hacking on it way easier. I ported a
physics engine (Chipmunk) to javascript at the start of the year and I
understand it _sooo_ much better now than I would have from just
reading the docs or something.
<claudio.cic...@gmail.com> wrote:
> The problem is that for me, now, CS is not a language worth learning. I'll
> never use (at least in a foresable future) CF as the language for ANY of my
> project; I'm perfectly at ease with JS, and I don't need any "dumb down"
> layers. I need to eventually find good JS programmers to help me out, not
> CF. So I'd need to learn it JUST to use someone else's project, even if the
> project is in... JS! I know that this applies with any other languages
> (using SOLR? Learn Java...), but at least learning a bit of Java makes
> sense.
> We're going to have to learn a lot more JS in the next couple of years (EC6,
> anyone?), writing compatibility layers, addressing browser issues... do we
> really need to get our life even more complicated with a level of (fake)
> abstraction, with a new syntax, written by same random guy? I don't think
> so.
> Sorry for the rant.
> On Monday, July 30, 2012 3:03:08 AM UTC+2, Nelson Silva wrote:
>> CF?
>> I still struggle to understand why people are reluctant to embrace
>> polyglot programming... is it because you invest in lots of meaningless Java
>> / .net certifications? Are you afraid to end up with unmantainable code? Do
>> you still believe in code reuse? I can understand the complexity of a big
>> codebase written in a dynamic language but ShareJS is simple, concise and
>> well tested so CS fits it like a glove. I did a quick port of the text OT
>> stuff to Dart in a couple of days and will try to get the JSON stuff as well
>> so if you have a team available you can probably port it to whatever
>> language you need in no time.
>> You have OT code from etherpad, apache wave, collide, etc... all freely
>> available as well so just pick whatever you want and get it working. I have
>> ShareJS working on rhinojs on vert.x so i can dev modules in any language...
>> just stop with the CS vs JS debate... i would pick CS any day over JS just
>> because it looks and feels better to me but hell, some people even like php
>> so it's really a mater of opinion.
>> Joseph did a great job with ShareJS i think it is better because of CS. If
>> you'd rather use JS look at Etherpad Lite, they even have attributes. If
>> you're into GWT you have Apache Wave and collide.
On Tuesday, July 31, 2012 6:33:51 AM UTC+2, Joseph Gentle wrote:
> If you already know javascript, it takes about 2 hours to learn > coffeescript. Coffeescript introduces (almost) no semantic changes to > javascript. It takes longer to read & understand Javascript: The Good > Parts than it does to learn coffeescript. Its much easier to teach a > good javascript developer coffeescript than it is to teach a fresh > javascript & coffeescript programmer how to write good JS/CS.
> But that isn't really why we're arguing here. Zed Shaw says it better > than I can:
> """ > Imagine I break software development clients into two camps: > Collaborators and Customers. Now imagine I then break projects into > two categories of Implementation and Invention.
> Collaborators will participate daily and know what's going on because > they are there and will usually pay variable price because of a higher > tolerance of risk. Customers just want something packaged, want it now, > and will only pay a fixed price and if it isn't perfect they'll bitch.
> Implementations are things you've done a billion times or that you can > manufacture with a consistent process and have low risk and low > variability. Inventions are done different every time, require creative > thinking, adaptation to randomness and chaos, and generally are riskier > and variable.
> In an ideal world, you pair Collaborators with Inventions, and > Customers with Implementations. The other combinations end in > disasters and you really only find them in the corporate world where > the force of tons of cash can make those bad mixes work anyway. In the > open source world where Darwin rules, the good projects gravitate > toward Collaborators+Inventions or Customers+Implementations, with the > former more common than the latter.
> The reason some people might get upset at you is that you are saying > (or what they hear) is, "I'm a Customer dammit and I want my > Implementation planned with no risk now." That's ungrateful and > irritating and insults their hard work. > """ > (From http://lua-users.org/lists/lua-l/2007-12/msg00470.html )
> ShareJS needs to balance the needs of these two camps. There's a lot > of creative design in ShareJS. But also, it needs to be stable so you > can actually use in your products. If its too planned, contributors > get bored and leave (like me!). But if its too unstable, the project > isn't actually useful.
> I feel this struggle constantly in the code. The use of coffeescript > is a concession to creativity and learning - coffeescript is a fun > language to program in, and it makes me feel like a monster stomping > through tokyo. But I also want ShareJS to be stable and not break > between versions. Hence ShareJS has a bajillion lines of unit tests > and CI and whatnot. Unit tests mean ShareJS should never break. But > they're seriously annoying when I want to change the APIs (even > internal ones) because I have >2x as much code to change.
> So yes, using coffeescript is a conceit to make the project more fun > to work on. If your developers don't like learning, fork the project, > compile out the coffeescript to javascript then clean it up. The > golden rule of coffeescript is that it maps 1-1 to javascript anyway, > so the JS is surprisingly readable (eg: > https://github.com/josephg/ShareJS/blob/master/webclient/textarea.js > ). Its a bit of work maintaining your own fork, but if you've got a > staff I'm sure you can manage it. As a byproduct, you'll learn ShareJS > works internally, which will make hacking on it way easier. I ported a > physics engine (Chipmunk) to javascript at the start of the year and I > understand it _sooo_ much better now than I would have from just > reading the docs or something.
> -J
> On Mon, Jul 30, 2012 at 6:33 PM, Claudio Cicali > <claudio.cic...@gmail.com> wrote: > > The problem is that for me, now, CS is not a language worth learning. > I'll > > never use (at least in a foresable future) CF as the language for ANY of > my > > project; I'm perfectly at ease with JS, and I don't need any "dumb down" > > layers. I need to eventually find good JS programmers to help me out, > not > > CF. So I'd need to learn it JUST to use someone else's project, even if > the > > project is in... JS! I know that this applies with any other languages > > (using SOLR? Learn Java...), but at least learning a bit of Java makes > > sense.
> > We're going to have to learn a lot more JS in the next couple of years > (EC6, > > anyone?), writing compatibility layers, addressing browser issues... do > we > > really need to get our life even more complicated with a level of (fake) > > abstraction, with a new syntax, written by same random guy? I don't > think > > so.
> > Sorry for the rant.
> > On Monday, July 30, 2012 3:03:08 AM UTC+2, Nelson Silva wrote:
> >> CF? > >> I still struggle to understand why people are reluctant to embrace > >> polyglot programming... is it because you invest in lots of meaningless > Java > >> / .net certifications? Are you afraid to end up with unmantainable > code? Do > >> you still believe in code reuse? I can understand the complexity of a > big > >> codebase written in a dynamic language but ShareJS is simple, concise > and > >> well tested so CS fits it like a glove. I did a quick port of the text > OT > >> stuff to Dart in a couple of days and will try to get the JSON stuff as > well > >> so if you have a team available you can probably port it to whatever > >> language you need in no time. > >> You have OT code from etherpad, apache wave, collide, etc... all freely > >> available as well so just pick whatever you want and get it working. I > have > >> ShareJS working on rhinojs on vert.x so i can dev modules in any > language... > >> just stop with the CS vs JS debate... i would pick CS any day over JS > just > >> because it looks and feels better to me but hell, some people even like > php > >> so it's really a mater of opinion. > >> Joseph did a great job with ShareJS i think it is better because of CS. > If > >> you'd rather use JS look at Etherpad Lite, they even have attributes. > If > >> you're into GWT you have Apache Wave and collide.
Not sure what is being implied re: Zed. I hope it isn't that "CS developers are inventors" and "JS developers are implementors".
As always, I am thankful for this project (even in its current form) and am actively using it.
This conversation is about how to get more collaborators. My minor point, distilled, is simple: regardless of how easy it is to learn CS, that is still a cost to be borne by someone, at least in time, possibly in interest, possibly in actual monetary cost to a company, which would not be borne if the project was written in JS. All costs are brakes on innovation. There are simply many more developers for ShareJS to attract without that cost. CS automatically, dramatically, lowers the project's chances of attracting contributions. I don't see how this particular analysis can be argued against on its own (and not for other reasons).
That being said, *of course* I am not making demands, implying that Gentle is some kind of jerk for wasting my time with this stinking CS. *Of course* the project existing, at all, in CS or in FooBarScript or something else is more important than it not existing. *Of course* it is so good that some (but not as many as the fanboys may think...) will learn CS *solely* to use it. If it needs to be in CS for the core team to stay interested, of course that is the winning strategy.
Porting to JS is an excellent idea, especially for the pedagogical implications.
On Tuesday, July 31, 2012 12:33:51 AM UTC-4, Joseph Gentle wrote:
> If you already know javascript, it takes about 2 hours to learn > coffeescript. Coffeescript introduces (almost) no semantic changes to > javascript. It takes longer to read & understand Javascript: The Good > Parts than it does to learn coffeescript. Its much easier to teach a > good javascript developer coffeescript than it is to teach a fresh > javascript & coffeescript programmer how to write good JS/CS.
> But that isn't really why we're arguing here. Zed Shaw says it better > than I can:
> """ > Imagine I break software development clients into two camps: > Collaborators and Customers. Now imagine I then break projects into > two categories of Implementation and Invention.
> Collaborators will participate daily and know what's going on because > they are there and will usually pay variable price because of a higher > tolerance of risk. Customers just want something packaged, want it now, > and will only pay a fixed price and if it isn't perfect they'll bitch.
> Implementations are things you've done a billion times or that you can > manufacture with a consistent process and have low risk and low > variability. Inventions are done different every time, require creative > thinking, adaptation to randomness and chaos, and generally are riskier > and variable.
> In an ideal world, you pair Collaborators with Inventions, and > Customers with Implementations. The other combinations end in > disasters and you really only find them in the corporate world where > the force of tons of cash can make those bad mixes work anyway. In the > open source world where Darwin rules, the good projects gravitate > toward Collaborators+Inventions or Customers+Implementations, with the > former more common than the latter.
> The reason some people might get upset at you is that you are saying > (or what they hear) is, "I'm a Customer dammit and I want my > Implementation planned with no risk now." That's ungrateful and > irritating and insults their hard work. > """ > (From http://lua-users.org/lists/lua-l/2007-12/msg00470.html )
> ShareJS needs to balance the needs of these two camps. There's a lot > of creative design in ShareJS. But also, it needs to be stable so you > can actually use in your products. If its too planned, contributors > get bored and leave (like me!). But if its too unstable, the project > isn't actually useful.
> I feel this struggle constantly in the code. The use of coffeescript > is a concession to creativity and learning - coffeescript is a fun > language to program in, and it makes me feel like a monster stomping > through tokyo. But I also want ShareJS to be stable and not break > between versions. Hence ShareJS has a bajillion lines of unit tests > and CI and whatnot. Unit tests mean ShareJS should never break. But > they're seriously annoying when I want to change the APIs (even > internal ones) because I have >2x as much code to change.
> So yes, using coffeescript is a conceit to make the project more fun > to work on. If your developers don't like learning, fork the project, > compile out the coffeescript to javascript then clean it up. The > golden rule of coffeescript is that it maps 1-1 to javascript anyway, > so the JS is surprisingly readable (eg: > https://github.com/josephg/ShareJS/blob/master/webclient/textarea.js > ). Its a bit of work maintaining your own fork, but if you've got a > staff I'm sure you can manage it. As a byproduct, you'll learn ShareJS > works internally, which will make hacking on it way easier. I ported a > physics engine (Chipmunk) to javascript at the start of the year and I > understand it _sooo_ much better now than I would have from just > reading the docs or something.
> -J
> On Mon, Jul 30, 2012 at 6:33 PM, Claudio Cicali > <claudio.cic...@gmail.com> wrote: > > The problem is that for me, now, CS is not a language worth learning. > I'll > > never use (at least in a foresable future) CF as the language for ANY of > my > > project; I'm perfectly at ease with JS, and I don't need any "dumb down" > > layers. I need to eventually find good JS programmers to help me out, > not > > CF. So I'd need to learn it JUST to use someone else's project, even if > the > > project is in... JS! I know that this applies with any other languages > > (using SOLR? Learn Java...), but at least learning a bit of Java makes > > sense.
> > We're going to have to learn a lot more JS in the next couple of years > (EC6, > > anyone?), writing compatibility layers, addressing browser issues... do > we > > really need to get our life even more complicated with a level of (fake) > > abstraction, with a new syntax, written by same random guy? I don't > think > > so.
> > Sorry for the rant.
> > On Monday, July 30, 2012 3:03:08 AM UTC+2, Nelson Silva wrote:
> >> CF? > >> I still struggle to understand why people are reluctant to embrace > >> polyglot programming... is it because you invest in lots of meaningless > Java > >> / .net certifications? Are you afraid to end up with unmantainable > code? Do > >> you still believe in code reuse? I can understand the complexity of a > big > >> codebase written in a dynamic language but ShareJS is simple, concise > and > >> well tested so CS fits it like a glove. I did a quick port of the text > OT > >> stuff to Dart in a couple of days and will try to get the JSON stuff as > well > >> so if you have a team available you can probably port it to whatever > >> language you need in no time. > >> You have OT code from etherpad, apache wave, collide, etc... all freely > >> available as well so just pick whatever you want and get it working. I > have > >> ShareJS working on rhinojs on vert.x so i can dev modules in any > language... > >> just stop with the CS vs JS debate... i would pick CS any day over JS > just > >> because it looks and feels better to me but hell, some people even like > php > >> so it's really a mater of opinion. > >> Joseph did a great job with ShareJS i think it is better because of CS. > If > >> you'd rather use JS look at Etherpad Lite, they even have attributes. > If > >> you're into GWT you have Apache Wave and collide.
I guess what's missing in your analysis is the fun factor. When you invest
your free time on an open source project you need it to be fun. Learning a
new language increases the fun factor and the simplicity of CS and its
overall look and feel really adds to that. I understand Joseph and i
believe he won't be working much more on ShareJS. When you start growing
your project and community you have to start worrying about stability,
performance, etc... you have to please users and make a commitment and
that's no longer fun! It's like Zed put it... there are
innovators/entrepeneurs who love playing with new ideas but after a while
they get bored and start looking for new toys... it is up to implementers
to take care of the boring stuff and turn the prototype into a product.
If you feel that a JS port is the way to go do it! That's a very simple
task and like you said there are lots of JS developers (although i'd rather
have one Joseph than a dozen others :p).
I've been feeding this discussion cause i'm on holidays but i think that if
all the time we've "lost" here was put to good use you'd already have you
JS "port" up and running.
I'm working on a Dart port and will get back to it asap. It's a great
learning experience which i recommend to anyone interested in ShareJS.
No dia 02/08/2012 01:37, "spasquali" <spasqu...@embarkcorp.com> escreveu:
> Not sure what is being implied re: Zed. I hope it isn't that "CS
> developers are inventors" and "JS developers are implementors".
> As always, I am thankful for this project (even in its current form) and
> am actively using it.
> This conversation is about how to get more collaborators. My minor point,
> distilled, is simple: regardless of how easy it is to learn CS, that is
> still a cost to be borne by someone, at least in time, possibly in
> interest, possibly in actual monetary cost to a company, which would not be
> borne if the project was written in JS. All costs are brakes on innovation.
> There are simply many more developers for ShareJS to attract without that
> cost. CS automatically, dramatically, lowers the project's chances of
> attracting contributions. I don't see how this particular analysis can be
> argued against on its own (and not for other reasons).
> That being said, *of course* I am not making demands, implying that Gentle
> is some kind of jerk for wasting my time with this stinking CS. *Of
> course* the project existing, at all, in CS or in FooBarScript or something
> else is more important than it not existing. *Of course* it is so good
> that some (but not as many as the fanboys may think...) will learn CS
> *solely* to use it. If it needs to be in CS for the core team to stay
> interested, of course that is the winning strategy.
> Porting to JS is an excellent idea, especially for the pedagogical
> implications.
> On Tuesday, July 31, 2012 12:33:51 AM UTC-4, Joseph Gentle wrote:
>> If you already know javascript, it takes about 2 hours to learn
>> coffeescript. Coffeescript introduces (almost) no semantic changes to
>> javascript. It takes longer to read & understand Javascript: The Good
>> Parts than it does to learn coffeescript. Its much easier to teach a
>> good javascript developer coffeescript than it is to teach a fresh
>> javascript & coffeescript programmer how to write good JS/CS.
>> But that isn't really why we're arguing here. Zed Shaw says it better
>> than I can:
>> """
>> Imagine I break software development clients into two camps:
>> Collaborators and Customers. Now imagine I then break projects into
>> two categories of Implementation and Invention.
>> Collaborators will participate daily and know what's going on because
>> they are there and will usually pay variable price because of a higher
>> tolerance of risk. Customers just want something packaged, want it now,
>> and will only pay a fixed price and if it isn't perfect they'll bitch.
>> Implementations are things you've done a billion times or that you can
>> manufacture with a consistent process and have low risk and low
>> variability. Inventions are done different every time, require creative
>> thinking, adaptation to randomness and chaos, and generally are riskier
>> and variable.
>> In an ideal world, you pair Collaborators with Inventions, and
>> Customers with Implementations. The other combinations end in
>> disasters and you really only find them in the corporate world where
>> the force of tons of cash can make those bad mixes work anyway. In the
>> open source world where Darwin rules, the good projects gravitate
>> toward Collaborators+Inventions or Customers+Implementations, with the
>> former more common than the latter.
>> ShareJS needs to balance the needs of these two camps. There's a lot
>> of creative design in ShareJS. But also, it needs to be stable so you
>> can actually use in your products. If its too planned, contributors
>> get bored and leave (like me!). But if its too unstable, the project
>> isn't actually useful.
>> I feel this struggle constantly in the code. The use of coffeescript
>> is a concession to creativity and learning - coffeescript is a fun
>> language to program in, and it makes me feel like a monster stomping
>> through tokyo. But I also want ShareJS to be stable and not break
>> between versions. Hence ShareJS has a bajillion lines of unit tests
>> and CI and whatnot. Unit tests mean ShareJS should never break. But
>> they're seriously annoying when I want to change the APIs (even
>> internal ones) because I have >2x as much code to change.
>> So yes, using coffeescript is a conceit to make the project more fun
>> to work on. If your developers don't like learning, fork the project,
>> compile out the coffeescript to javascript then clean it up. The
>> golden rule of coffeescript is that it maps 1-1 to javascript anyway,
>> so the JS is surprisingly readable (eg:
>> https://github.com/josephg/**ShareJS/blob/master/webclient/**textarea.js<https://github.com/josephg/ShareJS/blob/master/webclient/textarea.js>
>> ). Its a bit of work maintaining your own fork, but if you've got a
>> staff I'm sure you can manage it. As a byproduct, you'll learn ShareJS
>> works internally, which will make hacking on it way easier. I ported a
>> physics engine (Chipmunk) to javascript at the start of the year and I
>> understand it _sooo_ much better now than I would have from just
>> reading the docs or something.
>> -J
>> On Mon, Jul 30, 2012 at 6:33 PM, Claudio Cicali
>> <claudio.cic...@gmail.com> wrote:
>> > The problem is that for me, now, CS is not a language worth learning.
>> I'll
>> > never use (at least in a foresable future) CF as the language for ANY
>> of my
>> > project; I'm perfectly at ease with JS, and I don't need any "dumb
>> down"
>> > layers. I need to eventually find good JS programmers to help me out,
>> not
>> > CF. So I'd need to learn it JUST to use someone else's project, even if
>> the
>> > project is in... JS! I know that this applies with any other languages
>> > (using SOLR? Learn Java...), but at least learning a bit of Java makes
>> > sense.
>> > We're going to have to learn a lot more JS in the next couple of years
>> (EC6,
>> > anyone?), writing compatibility layers, addressing browser issues... do
>> we
>> > really need to get our life even more complicated with a level of
>> (fake)
>> > abstraction, with a new syntax, written by same random guy? I don't
>> think
>> > so.
>> > Sorry for the rant.
>> > On Monday, July 30, 2012 3:03:08 AM UTC+2, Nelson Silva wrote:
>> >> CF?
>> >> I still struggle to understand why people are reluctant to embrace
>> >> polyglot programming... is it because you invest in lots of
>> meaningless Java
>> >> / .net certifications? Are you afraid to end up with unmantainable
>> code? Do
>> >> you still believe in code reuse? I can understand the complexity of a
>> big
>> >> codebase written in a dynamic language but ShareJS is simple, concise
>> and
>> >> well tested so CS fits it like a glove. I did a quick port of the text
>> OT
>> >> stuff to Dart in a couple of days and will try to get the JSON stuff
>> as well
>> >> so if you have a team available you can probably port it to whatever
>> >> language you need in no time.
>> >> You have OT code from etherpad, apache wave, collide, etc... all
>> freely
>> >> available as well so just pick whatever you want and get it working. I
>> have
>> >> ShareJS working on rhinojs on vert.x so i can dev modules in any
>> language...
>> >> just stop with the CS vs JS debate... i would pick CS any day over JS
>> just
>> >> because it looks and feels better to me but hell, some people even
>> like php
>> >> so it's really a mater of opinion.
>> >> Joseph did a great job with ShareJS i think it is better because of
>> CS. If
>> >> you'd rather use JS look at Etherpad Lite, they even have attributes.
>> If
>> >> you're into GWT you have Apache Wave and collide.
