3 ms·

This is just due to the ridiculous way the development ecosystem for the web has grown. Nobody seems to care about fast languages anymore. Check out this websi

This is just due to the ridiculous way the development ecosystem for the web has grown. Nobody seems to care about fast languages anymore. Check out this website. http://forum.dlang.org/ http://forum.dlang.org/ Notice how amazingly fast it is. It's written in D. Oh, but I forgot, the bottleneck is in the database so feel free to waste millions of cycles every request chasing pointers around and around the vast quantities of memory that your dynamic language consumes. People don't even know what speed is anymore.

gleenn 12y ago
Perhaps its because some people are more productive with dynamic languages and they value productivity over speed.
- gtirloni 12y ago
  That's exactly it (and it's a message we've been hearing over and over for the past decade at least -- "worry about being productive, if it's slow, Moore's law will fix it for you in a few years"). The thing is, in some cases, all the productivity ends up costing a lot more. For small shops it will not be evident, but for bigger ones trying to scale, it'll be a major area of improvement (to use less cycles). And that's OK... comes down to using the right tool for the right job, matching the skills of your developers with the challenge, how fast you want things delivered, etc, etc, etc. I think the major issue people see is that when all of that slow programs are looked from a 10,000 feet view as a single thing, it looks like a damn waste of resources. Thus comments like "computing (as a whole) in the last X years has been terrible", etc. We can delve into programmer culture, lack of skills, people not caring about wasting resources, etc, etc, etc. I think the solution is better tooling. Let the programmer be productive, deliver things fast, etc, but build something more intelligent that will strip it down to only the necessary bits and deploy.
- army 12y ago
  The danger with the "speed doesn't matter" attitude is that you end up with a 10x slowdown due to language choice, and then another 10x slowdown due to inefficient implementation, and you end up with a 100x slowdown, which might actually be significant even in situations where speed doesn't matter that match.
  - bhauer 12y ago
    The sentiment you just wrote is one of the chief inspirations for the TechEmpower Framework Benchmarks project that I'm part of. Today, we routinely see huge amounts of computational horsepower evaporated in the name of developer efficiency. Yet the modern web development ecosystem is so plentiful and diverse that there are myriad high-productivity platforms and frameworks that exploit computational horsepower rather than squander it. My opinion is that investing the modest effort to select a high-performance platform and framework gives you the freedom to write inefficient application code first and to optimize later. It is the process that allows you to avoid the most expensive kind of premature optimization I've seen by postponing optimization until well after an application's concept has been vetted by its first several thousand users.
- zenbowman 12y ago
  I find this hard to believe. Any time people write systems in a dynamic language, they inevitably run into issues as they scale, ending up wasting money (computers, electricity) and a lot of user time. This usually results in rewriting things over and over. Performance is always important. If you can solve a problem in 10% more time using a performant language, then it makes sense to do so, and I've seen few problems that I can express in Python or Ruby (painfully slow) that I cannot express in C++ (highly performant) or Scala (moderately performant) in roughly that amount of extra time.
  - hyperpape 12y ago
    Time is not perfectly fungible. The only way to save time early on (prototyping and delivering products early on) may result in spending a lot of time later on.
  - deleted 12y ago
    [deleted]
  - galvanist 12y ago
    Do you have any actual data to back your wild assertions? Entire domains of computer science are dedicated to productivity languages and many are widely used with great success and little or no overhead relative to C. (edit: for example scipy)
    - zenbowman 12y ago
      I was stating an opinion based on my experience. I don't deny that tools like SciPy are very useful for experimental programming. However SciPy and Matlab are exceptions, where the end-user of the program is also the programmer, so the developer experience IS the user experience. In most cases, when you are a professional developer, you are not the end-user of your product. In these cases, deliberately choosing a less performant language for the sake of developer productivity can mean you end up penalizing the end user.
  - enjoy-your-stay 12y ago
    Good point, and I think that that's why languages like Java and C# are very popular these days - they hit a good balance between performance and developer productivity.
X-Istence 12y ago
Just because it is written in D doesn't automatically make it fast. If you were to run that program on an underpowered host with a database system that has to constantly swap, with not enough CPU time available it would be slow too. And that is the bigger problem, people are running their websites on underpowered hardware in the first place. The limit should be the network connection, not the page rendering time... but unfortunately that isn't always the case.

gleenn 12y ago

Perhaps its because some people are more productive with dynamic languages and they value productivity over speed.

gtirloni 12y ago
That's exactly it (and it's a message we've been hearing over and over for the past decade at least -- "worry about being productive, if it's slow, Moore's law will fix it for you in a few years"). The thing is, in some cases, all the productivity ends up costing a lot more. For small shops it will not be evident, but for bigger ones trying to scale, it'll be a major area of improvement (to use less cycles). And that's OK... comes down to using the right tool for the right job, matching the skills of your developers with the challenge, how fast you want things delivered, etc, etc, etc. I think the major issue people see is that when all of that slow programs are looked from a 10,000 feet view as a single thing, it looks like a damn waste of resources. Thus comments like "computing (as a whole) in the last X years has been terrible", etc. We can delve into programmer culture, lack of skills, people not caring about wasting resources, etc, etc, etc. I think the solution is better tooling. Let the programmer be productive, deliver things fast, etc, but build something more intelligent that will strip it down to only the necessary bits and deploy.
army 12y ago
The danger with the "speed doesn't matter" attitude is that you end up with a 10x slowdown due to language choice, and then another 10x slowdown due to inefficient implementation, and you end up with a 100x slowdown, which might actually be significant even in situations where speed doesn't matter that match.
- bhauer 12y ago
  The sentiment you just wrote is one of the chief inspirations for the TechEmpower Framework Benchmarks project that I'm part of. Today, we routinely see huge amounts of computational horsepower evaporated in the name of developer efficiency. Yet the modern web development ecosystem is so plentiful and diverse that there are myriad high-productivity platforms and frameworks that exploit computational horsepower rather than squander it. My opinion is that investing the modest effort to select a high-performance platform and framework gives you the freedom to write inefficient application code first and to optimize later. It is the process that allows you to avoid the most expensive kind of premature optimization I've seen by postponing optimization until well after an application's concept has been vetted by its first several thousand users.
zenbowman 12y ago
I find this hard to believe. Any time people write systems in a dynamic language, they inevitably run into issues as they scale, ending up wasting money (computers, electricity) and a lot of user time. This usually results in rewriting things over and over. Performance is always important. If you can solve a problem in 10% more time using a performant language, then it makes sense to do so, and I've seen few problems that I can express in Python or Ruby (painfully slow) that I cannot express in C++ (highly performant) or Scala (moderately performant) in roughly that amount of extra time.
- hyperpape 12y ago
  Time is not perfectly fungible. The only way to save time early on (prototyping and delivering products early on) may result in spending a lot of time later on.
- deleted 12y ago
  [deleted]
- galvanist 12y ago
  Do you have any actual data to back your wild assertions? Entire domains of computer science are dedicated to productivity languages and many are widely used with great success and little or no overhead relative to C. (edit: for example scipy)
  - zenbowman 12y ago
    I was stating an opinion based on my experience. I don't deny that tools like SciPy are very useful for experimental programming. However SciPy and Matlab are exceptions, where the end-user of the program is also the programmer, so the developer experience IS the user experience. In most cases, when you are a professional developer, you are not the end-user of your product. In these cases, deliberately choosing a less performant language for the sake of developer productivity can mean you end up penalizing the end user.
- enjoy-your-stay 12y ago
  Good point, and I think that that's why languages like Java and C# are very popular these days - they hit a good balance between performance and developer productivity.

X-Istence 12y ago

Just because it is written in D doesn't automatically make it fast. If you were to run that program on an underpowered host with a database system that has to constantly swap, with not enough CPU time available it would be slow too. And that is the bigger problem, people are running their websites on underpowered hardware in the first place. The limit should be the network connection, not the page rendering time... but unfortunately that isn't always the case.