4 ms·

> Now take half rustc devs and move them to another redundant compiler implementation. You've slowed down progress far too much, criminally even I would say.

> Now take half rustc devs and move them to another redundant compiler implementation. You've slowed down progress far too much, criminally even I would say. This assumes most of development time is spent writing the actual code. The counter argument is, that most of the time spent on such advanced projects is figuring out which path to take. Perhaps writing four or five different implementing of weighting the discovered pros and cons. Having multiple javascript engines arguably allows exploring the design space much more efficiently than having all devs working on the same codebase.

The_rationalist 6y ago
that most of the time spent on such advanced projects is figuring out which path to take. nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it. I've actively followed the development of the Servo engine for two years. I followed almost every issue, every commit, every designs documents and clearly most of the time was spent writing/updating code. Having multiple javascript engines arguably allows exploring the design space much more efficiently than having all devs working on the same codebase. not at all, I'm betting they work in isolation and that they reimplemented many times designs that mostly overlapped with one already explored and implemented in V8 (and conversely) Mozilla has not the resources to try a disjonction of cases of all possible promising implementation for a given feature/optimization. They are playing catch-up and must rush the features, as a consequence I doubt they can often afford many attempts on the design space. But if they worked on V8 there would be zero hurry, they could have 100% of their time allocated on reimplementing what is already implemented by exploring more the design space (how ironic!) and they would bring the reimplementation to V8 once found to be superior.
- wtetzner 6y ago
  > nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it. But writing a design document may not be enough to determine if it's a good idea. Sometimes you need to try something to find out.
  - The_rationalist 6y ago
    The observation that the design become much clearer by doing actually strengthen my argumentation.
    - wtetzner 6y ago
      I think you're missing my point. If you have multiple implementations, you can be trying out implementations of different paths concurrently. If you only have one implementation, that's very hard to do. I'm not saying that's what will happen, just that the point about multiple paths works better with different teams on different code bases.
      - The_rationalist 6y ago
        . If you have multiple implementations, you can be trying out implementations of different paths concurrently. and so can you with git branches. The difference is that with multiple implementations, the team will most of the time not be aware of what is tried by the team from the other implementation (and conversely) leading to an inefficient overlap of what has been tried on the design space as I explained in another comment. If both teams worked on the same project, through the same documentation and communication channel, they would-be far more aware of what has been tried and I don't see the issue with git branches.
        wtetzner 6y ago
        Different git branches don't allow the features to be vetted by users. At least not by many users. It's going to be much harder to get users to use different builds of Chrome than it is to have different (or even the same) people using Chrome and Firefox. Also, what management team is going to ask their developers to work on two conflicting features in parallel? It's a people matter as much as it is a technical one.
dfee 6y ago
Just wanted to say this > This assumes most of development time is spent writing the actual code. The counter argument is, that most of the time spent on such advanced projects is figuring out which path to take. is a great wording of the problem. Added to my favorite comments.

The_rationalist 6y ago

that most of the time spent on such advanced projects is figuring out which path to take. nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it. I've actively followed the development of the Servo engine for two years. I followed almost every issue, every commit, every designs documents and clearly most of the time was spent writing/updating code. Having multiple javascript engines arguably allows exploring the design space much more efficiently than having all devs working on the same codebase. not at all, I'm betting they work in isolation and that they reimplemented many times designs that mostly overlapped with one already explored and implemented in V8 (and conversely) Mozilla has not the resources to try a disjonction of cases of all possible promising implementation for a given feature/optimization. They are playing catch-up and must rush the features, as a consequence I doubt they can often afford many attempts on the design space. But if they worked on V8 there would be zero hurry, they could have 100% of their time allocated on reimplementing what is already implemented by exploring more the design space (how ironic!) and they would bring the reimplementation to V8 once found to be superior.

wtetzner 6y ago
> nonsense, writing a design document and a list of the possible competing implementations take time but order of magnitude less than writing and maintaining it. But writing a design document may not be enough to determine if it's a good idea. Sometimes you need to try something to find out.
- The_rationalist 6y ago
  The observation that the design become much clearer by doing actually strengthen my argumentation.
  - wtetzner 6y ago
    I think you're missing my point. If you have multiple implementations, you can be trying out implementations of different paths concurrently. If you only have one implementation, that's very hard to do. I'm not saying that's what will happen, just that the point about multiple paths works better with different teams on different code bases.
    - The_rationalist 6y ago
      . If you have multiple implementations, you can be trying out implementations of different paths concurrently. and so can you with git branches. The difference is that with multiple implementations, the team will most of the time not be aware of what is tried by the team from the other implementation (and conversely) leading to an inefficient overlap of what has been tried on the design space as I explained in another comment. If both teams worked on the same project, through the same documentation and communication channel, they would-be far more aware of what has been tried and I don't see the issue with git branches.
      - wtetzner 6y ago
        Different git branches don't allow the features to be vetted by users. At least not by many users. It's going to be much harder to get users to use different builds of Chrome than it is to have different (or even the same) people using Chrome and Firefox. Also, what management team is going to ask their developers to work on two conflicting features in parallel? It's a people matter as much as it is a technical one.

dfee 6y ago

Just wanted to say this > This assumes most of development time is spent writing the actual code. The counter argument is, that most of the time spent on such advanced projects is figuring out which path to take. is a great wording of the problem. Added to my favorite comments.