4 ms·

Arg, more crazy thoughts. But, a (rhetorical) real world question: Once pasta chef Katz is done turning the rails spaghetti into merb-style ravioli and all the

Arg, more crazy thoughts. But, a (rhetorical) real world question: Once pasta chef Katz is done turning the rails spaghetti into merb-style ravioli and all the rails monkey patching is self contained in an extlib style gem, how many projects will begin including that monkey patching as a dependency? If someone wants an array#sum there's a good chance they'll just depend on rails' array#sum. With its massive influence the rails project has the, perhaps small, potential of becoming an autocratic second-level Matz with a default set of widely used ruby extensions. What Facets wants to be but isn't. Given that scenario, is it better to let rails be the guardians of a defacto "standard" extlib or to have a more fine-grained system that allows the marketplace of popularity to decide what gets to be considered standard?

davidmathers 18y ago
Ok, my last crazy thought for the day: With rails recipes the division of labor between programmers and "editors" has already begun. The granularity of the web framework has changed from the single monolithic option handed down by the programmers to the gem level. Now we get a default framework from the programmers and dozens or hundreds of remixed frameworks provided by people with specific configuration needs. These people are doing the same job that the creators of linux distributions are doing. It's up to them to resolve compatibility issues and create any patches needed to make their distribution work. You find the custom framework that does exactly what you need or if it doesn't exist you create it and become an editor yourself. Now take the component granularity down to the level of a single language extension or monkey patch. Gems might have gem recipes. The authors of the classifier gem would require array#sum and identify a default version, but an editor could change that. Right now you can create a recipe that replaces prototype with jquery. Maybe someone thinks that rails' #try sucks so they create a recipe that replaces it with raganwald's #try. It's then the job of the editor to make sure all the components of their recipe play nice with each other. Just like there are more mutual funds than there are stocks you get an explosion of recipes, but that's exactly what you want. Mass customization. You look through the directory and find the package/distribution that does exactly what you need. The software that gets used gets used. The key here is that no one needs to agree on anything. Coders code and editors edit. The producer->editor->consumer relationship is natural. The producer->consumer relationship is artificial. It's a bug in the system.

davidmathers 18y ago

Ok, my last crazy thought for the day: With rails recipes the division of labor between programmers and "editors" has already begun. The granularity of the web framework has changed from the single monolithic option handed down by the programmers to the gem level. Now we get a default framework from the programmers and dozens or hundreds of remixed frameworks provided by people with specific configuration needs. These people are doing the same job that the creators of linux distributions are doing. It's up to them to resolve compatibility issues and create any patches needed to make their distribution work. You find the custom framework that does exactly what you need or if it doesn't exist you create it and become an editor yourself. Now take the component granularity down to the level of a single language extension or monkey patch. Gems might have gem recipes. The authors of the classifier gem would require array#sum and identify a default version, but an editor could change that. Right now you can create a recipe that replaces prototype with jquery. Maybe someone thinks that rails' #try sucks so they create a recipe that replaces it with raganwald's #try. It's then the job of the editor to make sure all the components of their recipe play nice with each other. Just like there are more mutual funds than there are stocks you get an explosion of recipes, but that's exactly what you want. Mass customization. You look through the directory and find the package/distribution that does exactly what you need. The software that gets used gets used. The key here is that no one needs to agree on anything. Coders code and editors edit. The producer->editor->consumer relationship is natural. The producer->consumer relationship is artificial. It's a bug in the system.