5 ms·

Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need

Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.

sanxiyn 8y ago
> Need is relative. If you can get the extra speed, why waste it? Because you can be a lot more productive if you are not extremely constrained by speed.
- adamnemecek 8y ago
  That’s a false dichotomy. A language can be both productive and fast.
  - sanxiyn 8y ago
    In theory, yes. In practice, Rust at the moment is less productive than GC languages. I am hoping for autoclone mode in the future (sort of like Swift ARC).
fulafel 8y ago
I think the article didn't say anything about performance requirements. The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes. Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.
- gmueckl 8y ago
  3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.
  - fulafel 8y ago
    Having worked in 3D, including tools, it's my experience that features and productivity (=program is delivered on time) are the most important features :) The code needs to be "fast enough"¹. Though this often means more attention to speed than in other kinds of software. To rephrase, speed is often necessary but not sufficient to make good tools. ¹ I try to avoid using "execution speed" and "performance" interchangeably, since a crashing, late or incorrect fast program is not a well performing program!
    - gmueckl 8y ago
      Fair point. Let me rephrase my point of view a little: you haven't made the users truely productive unless the tools are able to provide responsive and accurate interactive feedback. Anything that causes feedback to be non-immediate makes it harder for the user to dial in the exact results they want. They have to spend more time and give up when they have reached an inferior result that meets basic quality standards. Smooth and direct interaction makes them go the extra mile while enjoying the process.

Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.

sanxiyn 8y ago

> Need is relative. If you can get the extra speed, why waste it? Because you can be a lot more productive if you are not extremely constrained by speed.

adamnemecek 8y ago
That’s a false dichotomy. A language can be both productive and fast.
- sanxiyn 8y ago
  In theory, yes. In practice, Rust at the moment is less productive than GC languages. I am hoping for autoclone mode in the future (sort of like Swift ARC).

fulafel 8y ago

I think the article didn't say anything about performance requirements. The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes. Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.

gmueckl 8y ago
3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.
- fulafel 8y ago
  Having worked in 3D, including tools, it's my experience that features and productivity (=program is delivered on time) are the most important features :) The code needs to be "fast enough"¹. Though this often means more attention to speed than in other kinds of software. To rephrase, speed is often necessary but not sufficient to make good tools. ¹ I try to avoid using "execution speed" and "performance" interchangeably, since a crashing, late or incorrect fast program is not a well performing program!
  - gmueckl 8y ago
    Fair point. Let me rephrase my point of view a little: you haven't made the users truely productive unless the tools are able to provide responsive and accurate interactive feedback. Anything that causes feedback to be non-immediate makes it harder for the user to dial in the exact results they want. They have to spend more time and give up when they have reached an inferior result that meets basic quality standards. Smooth and direct interaction makes them go the extra mile while enjoying the process.