10 ms·

The thing I find depressing and frustrating about this kind of discussion is the fatalism and non-constructiveness. I really wish it was: "I set up a server t

by sams99 12y ago

The thing I find depressing and frustrating about this kind of discussion is the fatalism and non-constructiveness. I really wish it was: "I set up a server that runs ruby spec on ruby-head daily and automatically reports spec failures to ruby-bugs" So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better.

zem 12y ago
it's unreasonable to expect the dev who has already put a ton of work into developing and maintaining rubyspec and making it work nicely with all the ruby implementations and versions he could to have to put in the additional work to do this as well. I don't blame him for getting discouraged at having to chase a moving target on top of all that - I agree with him that having the MRI devs contribute to rubyspec was a reasonable thing to expect.
- sams99 12y ago
  Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest? It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.
  - mahmoudimus 12y ago
    The Ruby devs attitudes in the discussions linked FTA makes me question the longevity of Ruby as a serious Enterprise language.
    - manyxcxi 12y ago
      When did it become a serious Enterprise™ language? Not being flippant or denigrating Ruby, but when I do work for established enterprises, it's never in Ruby. Java, .NET, PHP, and occasionally Python. Just because startups use it to get off the ground quickly, or to build the front end of their website doesn't make it enterprise.
      - imajes 12y ago
        How do you define enterprise? I've been using ruby in projects I wouldn't call 'startup' for the last several years... including with teams up to 80 people (i.e. real enterprise)
      - fat0wl 12y ago
        yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enormously widespread acceptance of Spring (JavaEE is even re-gaining some traction). Long story short (and hope my facts are right! not swearing by this, was just some googling...), I had to optimize some old code for an RoR client I freelance for and wanted to add in some more advanced ORM (still fairly simple though, mapping entity results from a stored procedure query). All the solutions I saw for this involved kindof hacking the db connector to execute some raw queries. I was curious as to why such a basic feature wouldn't be natively supported, so eventually I found some forum posts asking why it isnt (it may be by now) and all the responses were in the vein of: "That is not the Rails way and therefore the core team chooses not to support those types of features". I know people think Java is too bulky & sprawling but after 6 months with JPA, SpringData, Spring JDBC etc. I was kindof left with the feeling "Man, there is a bit of a learning curve to pick up the overarching concepts of the Java ecosystem and its design paradigms at first, but once you are over that hump you can do more, easier with any ORM lib than with ActiveRecord". I know there is another Ruby ORM gaining traction (DataMapper) but it just seems that the opinionated nature of Ruby/Rails core dev teams makes it doomed & dangerous for enterprise use (and indeed maybe its not even their goal). The Java approach is bulky and design-by-committee for sure but their userbase seems to demand that the fullest possible spectrum of features be supported, and then the library developers try to provide their recommended approach for new projects. Also the specs expand pretty quickly... had to use JPA 2.0 for some projects and found myself constantly frustrated because in the advancement to 2.1 there seemed to be a landslide of awesomeness added to support missing advanced database features. I guess its one of those things where now it feels like a breath of fresh air thinking "I have more power in my pinky than....". It's a shame too cuz I still get calls from companies in a lurch desperate for RoR devs but philosophically I just can't bring myself to go back in that direction after seeing how unscary & mind-bogglingly powerful the enterprise langs have become. In part thanks to RoR, I'm sure! Wouldn't mind using it for front-end but all that stuff is so interchangeable, the syntax diffs are barely noticed in the development process. I think really the only front-end techs with noticeable differences in feel are the ones with advanced data-binding/component libraries. Maybe there are some mind-blowing gems out there now though? Who knows....
    - bmj 12y ago
      I suspect this isn't a goal of those Ruby devs. It almost seems that "Ruby" is more like an ideology rather than a language, at least from comments like "Continuous changes is Ruby." Note that I'm not trying to criticize this position, rather, I'm pointing out that the core Ruby team seems to have different goals than, say, the community around Java or C#.
  - imajes 12y ago
    The point is that it's not sufficient to run the current 20k tests against head daily; there are so many unplanned variations and 'emergent' design that there's a full time job just in keeping up with the changes to MRI ruby. And even if there wasn't, @brixen has repeatedly pointed out how the MRI authors have chosen to ignore the RubySpec project entirely. That's really sad.
  - thinkbohemian 12y ago
    > can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system Heroku does sponsor Matz, Nobu, and Koichi. We hired them and give them a full time salary to work on Ruby.We don't tell them what to work on (i.e. we don't dictate what features or projects get shipped in what versions) it's more like corporate sponsorship. GitHub hired tmm1. Beyond that CRuby has a host of other non-sponsored contributors that contribute code and doc patches as well as set up tooling. You don't need corporate sponsorship for that, you need a passion and some time. You, in fact, could be the very person that sets up this automated system. I find the attitude of '<company x> should sponsor <thing y>' a bit misguided. While I agree that companies who profit from a OSS should give forwards to OSS, individual contributors are ultimately they only way progress gets made. If you or someone reading this works for a company making money off of Ruby do that thing! Tell your boss you can't deploy on friday afternoon and have to fix a bug in the Ruby codebase. Ship the project on company time, and then boom...your company just sponsored that thing. It's like magic! Anywhoo, yes finding out what things are blocking the MRI team from adopting a tool/technology and working around them can be extremely valuable. For example Matz has agreed to move the codebase development to github. This would make contributions a bit easier, however there is a blocker. There are a ton of SVN bots and tooling written around the current workflow. Right now the Ruby core team wants to spend time focusing on pumping out C code to fix bugs, improve performance, and progress the language forwards. They don't want to go off into the woods on tooling. These types of projects could be hugely impactful to the team and don't require C knowledge so most Ruby devs may be able to help. I encourage you and others to reach out to the core team to ask them what tooling projects they need and how we can help them. Understanding why someone isn't using a tool/technology is a really good start. tldr; Good idea, let's talk to the core team about ways to help with tooling.
- kej 12y ago
  Why is it unreasonable to expect the RubySpec dev to do additional work, but reasonable to expect additional work from the MRI devs to comply with RubySpec? I get that "the implementation is the standard" is frustrating for people who want to make an alternate implementation, but why should that obligate the original developers to accept some third party's definition of what their project should be?
  - vinceguidry 12y ago
    It's not a third-party definition, it's their definition, should they want to contribute to it. By writing Ruby specs you're defining Ruby.
    - kej 12y ago
      > By writing Ruby specs you're defining Ruby. And presumably the MRI devs would say that by coding MRI you're defining Ruby. What gives RubySpecs the authority to say they are the canonical definition of Ruby and everyone should follow it, when the people who created Ruby disagree?
      - vinceguidry 12y ago
        You can't call code a spec. Saying you're defining Ruby by coding it just means you don't have a spec.
        sanderjd 12y ago
        In my experience, executable specs are much more useful than their non-executable brethren. They prove their own correctness, and can't gloss over important details.
        vinceguidry 12y ago
        > They prove their own correctness, and can't gloss over important details. They most certainly don't, do either of those things. You can still have incorrect, incomplete specs even with an executable test suite. You only get those properties through constant work. The idea behind TDD is to do that as you develop the application, but even then you're not automatically saved from incorrectness and incompleteness. The only way to really do it is the way RubySpecs intended, create a third place for the specification of the language to live, that any implementation can use to measure its compliance against. If anyone running any implementation on any platform finds a problem and traces it to the implementation, then a new test case can get written and all implementations can then fix the bug assuming it's present. Code quality goes up for everyone. Most other applications don't need to do it this way, they're intended for an install base of one. But since Ruby has multiple implementations intended to be able to run under multiple platforms on multiple architectures, a living collection of specs that ensures that each combination still has the same behavior would seem to be absolutely essential for one's sanity if one cares about the quality of the language. Each implementation then only has to maintain platform-specific test suites. It's ultimately less work. But just like TDD/BDD, it requires organizational buy-in to really get the benefits. Everyone working on Ruby needs to be involved in maintaining the test suite or there's no way you can consider the suite canonical. If you can't consider the suite canonical, there's no point in having it. I develop on MRI at present, but at some point I'm going to switch to either JRuby or Rubinius. If Brian actually follows through on his goals to implement even better ways of specifying Ruby than a test suite, I'll probably switch to Rubinius.
- rab_oof 12y ago
  RS needs work contribution from each Ruby to make it sustainable. It would also show leadership from MRI to encourage a semi-independent Ruby self-test framework that can run on any Rubyish interpreter. (Granted RS has RBX bias, but it would show leadership to coordinate common infrastructure.) Since RS exists, seems like a good idea to go with that for full up integration testing, but each Ruby should still unit test it's own, low-level bits. (Is MRI doing that at least?)
MBCook 12y ago
> reports spec failures to ruby-bugs But why should the Ruby developers work to fix 'bugs' against an unsupported 3rd party specification?
- nfm 12y ago
  It's essentially regression testing. Rubyspec specs out the behaviour of Ruby according to what MRI implements, so any failure is a change in behaviour from the initial implementation. Most of the time this is undesirable/unintentional.
Iftheshoefits 12y ago
> So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better. < And why would/should they when there are quite literally dozens (or possibly hundreds or even thousands) of developers who will happily work on "making Ruby better" for no cost to said companies? A large percentage of software developers will quite happily hack away at projects for nothing in return simply because they enjoy it (and would, quite incorrectly, claim that as compensation itself), in order to gain notoriety, boost their own ego, or any of a number of related reasons.

by sams99 12y ago

zem 12y ago

it's unreasonable to expect the dev who has already put a ton of work into developing and maintaining rubyspec and making it work nicely with all the ruby implementations and versions he could to have to put in the additional work to do this as well. I don't blame him for getting discouraged at having to chase a moving target on top of all that - I agree with him that having the MRI devs contribute to rubyspec was a reasonable thing to expect.

sams99 12y ago
Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest? It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.
- mahmoudimus 12y ago
  The Ruby devs attitudes in the discussions linked FTA makes me question the longevity of Ruby as a serious Enterprise language.
  - manyxcxi 12y ago
    When did it become a serious Enterprise™ language? Not being flippant or denigrating Ruby, but when I do work for established enterprises, it's never in Ruby. Java, .NET, PHP, and occasionally Python. Just because startups use it to get off the ground quickly, or to build the front end of their website doesn't make it enterprise.
    - imajes 12y ago
      How do you define enterprise? I've been using ruby in projects I wouldn't call 'startup' for the last several years... including with teams up to 80 people (i.e. real enterprise)
    - fat0wl 12y ago
      yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enormously widespread acceptance of Spring (JavaEE is even re-gaining some traction). Long story short (and hope my facts are right! not swearing by this, was just some googling...), I had to optimize some old code for an RoR client I freelance for and wanted to add in some more advanced ORM (still fairly simple though, mapping entity results from a stored procedure query). All the solutions I saw for this involved kindof hacking the db connector to execute some raw queries. I was curious as to why such a basic feature wouldn't be natively supported, so eventually I found some forum posts asking why it isnt (it may be by now) and all the responses were in the vein of: "That is not the Rails way and therefore the core team chooses not to support those types of features". I know people think Java is too bulky & sprawling but after 6 months with JPA, SpringData, Spring JDBC etc. I was kindof left with the feeling "Man, there is a bit of a learning curve to pick up the overarching concepts of the Java ecosystem and its design paradigms at first, but once you are over that hump you can do more, easier with any ORM lib than with ActiveRecord". I know there is another Ruby ORM gaining traction (DataMapper) but it just seems that the opinionated nature of Ruby/Rails core dev teams makes it doomed & dangerous for enterprise use (and indeed maybe its not even their goal). The Java approach is bulky and design-by-committee for sure but their userbase seems to demand that the fullest possible spectrum of features be supported, and then the library developers try to provide their recommended approach for new projects. Also the specs expand pretty quickly... had to use JPA 2.0 for some projects and found myself constantly frustrated because in the advancement to 2.1 there seemed to be a landslide of awesomeness added to support missing advanced database features. I guess its one of those things where now it feels like a breath of fresh air thinking "I have more power in my pinky than....". It's a shame too cuz I still get calls from companies in a lurch desperate for RoR devs but philosophically I just can't bring myself to go back in that direction after seeing how unscary & mind-bogglingly powerful the enterprise langs have become. In part thanks to RoR, I'm sure! Wouldn't mind using it for front-end but all that stuff is so interchangeable, the syntax diffs are barely noticed in the development process. I think really the only front-end techs with noticeable differences in feel are the ones with advanced data-binding/component libraries. Maybe there are some mind-blowing gems out there now though? Who knows....
  - bmj 12y ago
    I suspect this isn't a goal of those Ruby devs. It almost seems that "Ruby" is more like an ideology rather than a language, at least from comments like "Continuous changes is Ruby." Note that I'm not trying to criticize this position, rather, I'm pointing out that the core Ruby team seems to have different goals than, say, the community around Java or C#.
- imajes 12y ago
  The point is that it's not sufficient to run the current 20k tests against head daily; there are so many unplanned variations and 'emergent' design that there's a full time job just in keeping up with the changes to MRI ruby. And even if there wasn't, @brixen has repeatedly pointed out how the MRI authors have chosen to ignore the RubySpec project entirely. That's really sad.
- thinkbohemian 12y ago
  > can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system Heroku does sponsor Matz, Nobu, and Koichi. We hired them and give them a full time salary to work on Ruby.We don't tell them what to work on (i.e. we don't dictate what features or projects get shipped in what versions) it's more like corporate sponsorship. GitHub hired tmm1. Beyond that CRuby has a host of other non-sponsored contributors that contribute code and doc patches as well as set up tooling. You don't need corporate sponsorship for that, you need a passion and some time. You, in fact, could be the very person that sets up this automated system. I find the attitude of '<company x> should sponsor <thing y>' a bit misguided. While I agree that companies who profit from a OSS should give forwards to OSS, individual contributors are ultimately they only way progress gets made. If you or someone reading this works for a company making money off of Ruby do that thing! Tell your boss you can't deploy on friday afternoon and have to fix a bug in the Ruby codebase. Ship the project on company time, and then boom...your company just sponsored that thing. It's like magic! Anywhoo, yes finding out what things are blocking the MRI team from adopting a tool/technology and working around them can be extremely valuable. For example Matz has agreed to move the codebase development to github. This would make contributions a bit easier, however there is a blocker. There are a ton of SVN bots and tooling written around the current workflow. Right now the Ruby core team wants to spend time focusing on pumping out C code to fix bugs, improve performance, and progress the language forwards. They don't want to go off into the woods on tooling. These types of projects could be hugely impactful to the team and don't require C knowledge so most Ruby devs may be able to help. I encourage you and others to reach out to the core team to ask them what tooling projects they need and how we can help them. Understanding why someone isn't using a tool/technology is a really good start. tldr; Good idea, let's talk to the core team about ways to help with tooling.
kej 12y ago
Why is it unreasonable to expect the RubySpec dev to do additional work, but reasonable to expect additional work from the MRI devs to comply with RubySpec? I get that "the implementation is the standard" is frustrating for people who want to make an alternate implementation, but why should that obligate the original developers to accept some third party's definition of what their project should be?
- vinceguidry 12y ago
  It's not a third-party definition, it's their definition, should they want to contribute to it. By writing Ruby specs you're defining Ruby.
  - kej 12y ago
    > By writing Ruby specs you're defining Ruby. And presumably the MRI devs would say that by coding MRI you're defining Ruby. What gives RubySpecs the authority to say they are the canonical definition of Ruby and everyone should follow it, when the people who created Ruby disagree?
    - vinceguidry 12y ago
      You can't call code a spec. Saying you're defining Ruby by coding it just means you don't have a spec.
      - sanderjd 12y ago
        In my experience, executable specs are much more useful than their non-executable brethren. They prove their own correctness, and can't gloss over important details.
        vinceguidry 12y ago
        > They prove their own correctness, and can't gloss over important details. They most certainly don't, do either of those things. You can still have incorrect, incomplete specs even with an executable test suite. You only get those properties through constant work. The idea behind TDD is to do that as you develop the application, but even then you're not automatically saved from incorrectness and incompleteness. The only way to really do it is the way RubySpecs intended, create a third place for the specification of the language to live, that any implementation can use to measure its compliance against. If anyone running any implementation on any platform finds a problem and traces it to the implementation, then a new test case can get written and all implementations can then fix the bug assuming it's present. Code quality goes up for everyone. Most other applications don't need to do it this way, they're intended for an install base of one. But since Ruby has multiple implementations intended to be able to run under multiple platforms on multiple architectures, a living collection of specs that ensures that each combination still has the same behavior would seem to be absolutely essential for one's sanity if one cares about the quality of the language. Each implementation then only has to maintain platform-specific test suites. It's ultimately less work. But just like TDD/BDD, it requires organizational buy-in to really get the benefits. Everyone working on Ruby needs to be involved in maintaining the test suite or there's no way you can consider the suite canonical. If you can't consider the suite canonical, there's no point in having it. I develop on MRI at present, but at some point I'm going to switch to either JRuby or Rubinius. If Brian actually follows through on his goals to implement even better ways of specifying Ruby than a test suite, I'll probably switch to Rubinius.
rab_oof 12y ago
RS needs work contribution from each Ruby to make it sustainable. It would also show leadership from MRI to encourage a semi-independent Ruby self-test framework that can run on any Rubyish interpreter. (Granted RS has RBX bias, but it would show leadership to coordinate common infrastructure.) Since RS exists, seems like a good idea to go with that for full up integration testing, but each Ruby should still unit test it's own, low-level bits. (Is MRI doing that at least?)

MBCook 12y ago

> reports spec failures to ruby-bugs But why should the Ruby developers work to fix 'bugs' against an unsupported 3rd party specification?

nfm 12y ago
It's essentially regression testing. Rubyspec specs out the behaviour of Ruby according to what MRI implements, so any failure is a change in behaviour from the initial implementation. Most of the time this is undesirable/unintentional.

Iftheshoefits 12y ago

> So many companies are making big bucks off Ruby, yet so little are willing to fork out a bit of money and time to make Ruby better. < And why would/should they when there are quite literally dozens (or possibly hundreds or even thousands) of developers who will happily work on "making Ruby better" for no cost to said companies? A large percentage of software developers will quite happily hack away at projects for nothing in return simply because they enjoy it (and would, quite incorrectly, claim that as compensation itself), in order to gain notoriety, boost their own ego, or any of a number of related reasons.