2010/5/25 刘松 <[email protected]> > people have right to choose what they like, while a framework SHOULD have > clear goal and position to survive. > since merb and rails are duplicated on both goal and position, and this > subject is "What is the future of Merb ?" > > so, comparation with rails can't be avoid. > > as I know, DM provides contract/interface like ARel, so DM == AR + ARel. > Am I wrong? >
All good on the language mate :) There's people from all over the world that participate, and we'll try to understand what you're saying :) DM != AR + ARel... DM can make use of mutltiple repositories, composite keys etc. It's also designed to map many different kinds of data stores not just RDMS. I don't think you can say that DM == AR + ARel but the syntaxes are now simliar sure, and AR has come around to using a query object which is great, but they're still not equivalent. Julian, as I said mate, I'm not going to criticize my friends hard work, and I'm not about to go into laborious detail about why I personally don't find rails pleasurable to use. If you like it, go for it, but for me it's still the same rails and I don't like it for the same reasons I left to start writing merb in the first place. IMHO there is no point starting a project with merb now. Rails is at least close to the modularity if not ahead, that merb had 18 months ago. It's however much more advanced in it's integration with Rack which moving forward is very important. Rails engines, whilst not portable outisde of rails, are better than merb slices, and the router is more solidly based on rack which at least gives it the ability to move forward. There's little advantage in the controller now that rails has incorporated the respond_with, and made controllers rack applications in their own right. Views are likewise more portable and advanced in rails. Considering the target merb was aiming for, it's now playing second fiddle to rails which was the plan when the 'merger' occurred. Now that it's nearly complete, with input from 2 of the core members, what is the point of starting anything with merb. The important thing moving forward for ruby web frameworks is how they work with rack. Merb is very far behind in this respect and so I don't think it's worth building anything with it. This is not to detract from the work that people have done on merb since the core team abandoned it, it's just the way it is. It is of course a sad thing for me to say it. I've put a lot into merb and had an awesome time doing it with the other guys. To see it become irrelevant is not an easy thing, but the reality is that rails is doing it better than Merb now, and the momentum doesn't seem to be there now to change that fact. I don't think the effort to change it will happen either, merb and rails were effectively chasing the same goal, so let rails chase that and use it where appropriate. For me though, to experiment and play, I'll use something a little more modern and nimble. > On Tue, May 25, 2010 at 1:58 PM, 刘松 <[email protected]> wrote: > >> hi, Julian, I am not good at English, that's why I rarely post. sorry for >> that[?] >> >> my opinion is: >> abandon merb and concentrate on DM, since resources are always lack and >> they should be used more effective. >> >> >> On Tue, May 25, 2010 at 1:50 PM, Julian Leviston <[email protected]>wrote: >> >>> Hey man, >>> >>> Feel free to use what you want, and don't use what you don't want. Whole >>> frameworks included. Some people like Merb, others Sinatra, others Rails, >>> (some even prefer PHP which is odd to me, but they do). Others like Camping >>> or even Smalltalk on Seaside (smalltalk is brillo). >>> >>> I have a bit of a problem with your (human) language... >>> >>> Your point about datamapper is a *little* unfounded. ARel wrappers >>> ActiveRecord in an abstraction layer in a similar method to Datamapper's >>> mapping of any arbitrary store... in that... so long as one implements the >>> core api of ARel, it can wrap anything... why not datamapper for example >>> (more than part of the original intention I think). The point of Rails 3 is >>> pretty much that you can use whatever you like... Write a whole app in metal >>> if you like... shim a layer just over Rack... I'm not entirely sure how it's >>> less flexible than Merb at the moment. Happy to be educated on that. >>> >>> It's *really* hard to understand exactly what you're trying to say. >>> You're not using English in a very normal way. You could be saying several >>> different (even opposing) things. If you could be more precise, I'd be able >>> to understand you a bit better. >>> >>> Julian. >>> >>> On 25/05/2010, at 3:24 PM, 刘松 wrote: >>> >>> since rails3 is coming, and most merb features are copied to rails3, so I >>> do think merb is dead. >>> If merb keeps live and active, I may think it's just a experimental >>> field, to play around and push more things to rails later. >>> is there any reason to use merb instead of rails3 for a new project? >>> I do think NO. >>> >>> It's a one choice between: >>> 1. *invent* a new project(merb) to try the best solution. >>> 2. *push* the existing project(rails) to be the best solution. >>> >>> merb chose 1 before, and when it was merged with rails, it chose 2, and >>> for now is there any reason to change back to 1? >>> I do think the answer is NO. >>> >>> the most difficulty of choice 2 is "push", right? so, "PUSH" hard please, >>> and the key is "SHOW" :) >>> very appreciate to your effort, especially to yehuda. >>> >>> DM is another thing that is quite advanced than AR, and DM >>> adapters/plugins is a great fortune. >>> It's a pity that recent 1-2 year few people and resources are >>> using/working on DM(though Dan did a lot), and I can't believe DM1.0 will be >>> released with full features that was in 1.0 roadmap on railsconf. >>> AR is catching up quickly, and is there any reason to embrace DM for a AR >>> user? >>> I do think YES. >>> >>> DM gives benefit on: >>> 1. adapters for even non-relational DBMS. >>> 2. types declaration is good. >>> and its architecture is still clean than AR >>> >>> my suggestion is: move resources/concern from merb to DM, and make DM the >>> first choice for ruby. >>> It needs lots of work on: >>> 1. tools/guidelines/support that helps migrate from AR, especially load >>> field information from DB. >>> 2. maturity, like >>> 2.1 true `before_save` hook with controlled execution order instead of >>> Object#before. >>> 2.2 SQL generation >>> 2.3 dependency cleanup, like activesupport integration, reload on dev >>> mode. >>> 3. more features that exists in AR, like Model.order(:field.desc) >>> 4. clean up dm-core, dm-more and the fortune of adapters >>> 5. call up people to participate >>> ... >>> >>> DM has more bright feature if AR keeps following MartinFowler's >>> ActiveRecord pattern. It just has no much resources. >>> I really appreciate their maintainers and contributors, it's your honor. >>> >>> I bet on DM. >>> >>> On Tue, May 25, 2010 at 12:55 PM, Nicholas Orr >>> <[email protected]>wrote: >>> >>>> You probably can do that, the point was, Merb *works* as is, its stable, >>>> != dead :) >>>> >>>> >>>> On Tue, May 25, 2010 at 1:50 PM, Patrick Aljord <[email protected]>wrote: >>>> >>>>> On Mon, May 24, 2010 at 8:41 PM, Nicholas Orr >>>>> <[email protected]>wrote: >>>>> >>>>>> Merb is alive, it works... >>>>>> Its not like it is in a proof of concept stage, you can go DM+Merb and >>>>>> have a functioning app >>>>>> >>>>> >>>>> What's the advantage over using rail-core+DM from rails3? I can >>>>> understand using merb for legacy apps that work just fine, but for new >>>>> ones? >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "merb" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]<merb%[email protected]> >>>>> . >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/merb?hl=en. >>>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "merb" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected] <merb%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/merb?hl=en. >>>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "merb" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/merb?hl=en. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "merb" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected] <merb%[email protected]>. >>> For more options, visit this group at >>> http://groups.google.com/group/merb?hl=en. >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "merb" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected] <merb%[email protected]>. > For more options, visit this group at > http://groups.google.com/group/merb?hl=en. > -- You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/merb?hl=en.
<<330.gif>>
