4 ms·

Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Java 7? meh. If you like chasing new shiny thi

by axod 16y ago

Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Java 7? meh. If you like chasing new shiny things all day, sure. Javascript is a great language, no doubt, but for me, it lacks a lot of the things Java does so well to ensure that things don't break, finding bugs easy, etc etc Why are so programmers so fashion conscious though? Do we write programs to solve problems, or do we write programs to be fashionable. If we write to solve problems, then use Java5. Use BASIC. Who cares if it solves the problem well. If you write to be fashionable, then sure, use <NEW SHINY THING THAT REINVENTS THE WHEEL BUT ISN'T UP TO MUCH YET>. People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? The amount of man hours wasted on reinventing the wheel in programming languages is staggering. So much time spent making a saw with a more comfortable handle that doesn't cut as well.

bad_user 16y ago
> Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Even on "backend server stuff" I pretty much prefer the FastCGI model, with multiple processes handling requests, as I don't have to worry about memory-leaks or about a rogue thread that can take out my whole server. With the JVM, this is impossible ... you need a monolithic process that takes care of everything (no support for forking, long startup time, high resource usage). And having multiple apps running in their own JVM (so they don't interfere with one another) is no panacea. You can also look at the problems Google's App Engine has with Java apps ... as resources are elastic, extra servers / VMs are loaded on demand, and the first requests hitting such a cold VM almost always ends up with a timeout error (although they are working to fix this, the magnitude of this issue is not the same with Python on GAE). And this is solely because of the slow warm-up time. > People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? I have ideas that I can prototype over a single weekend, which wouldn't be possible without the help of those people with "great fashion sense". > The amount of man hours wasted on reinventing the wheel in programming languages is staggering Why don't you teach people then how to spend their time better with constructive arguments? The easiest thing in the world is to dismiss / critique.
- axod 16y ago
  > "Why don't you teach people then how to spend their time better with constructive arguments?" Yeah but it's like trying to tell people "Hey don't buy that prada coat for £500 that doesn't actually cover you properly from the rain, buy this old fashioned raincoat instead that actually functions well as a raincoat." I just wish people would spend more time becoming good programmers than chasing the new shiny things. I'm not sure the argument about rapid prototyping is a good one. Maybe it's just you can get it done in a weekend because you enjoy playing with new shiny thing, so are more productive. The old-established-stuff has a multitude of libraries that have been war tested to ultimate reliability though... I'm just getting old. Ignore me. Every generation has to reinvent the wheel for some reason anyway :)
  - sanderjd 16y ago
    I thought this thread might benefit from my response as a self-admitted shiny-thing-chaser. Your Prada coat analogy is fairly silly, as I'm sure you are aware. First of all, when it comes to programming languages/frameworks, both the new-hawtness Prada and the "old fashioned" raincoat tend to be free, so there is no financial rationality argument to be made. Even if you (correctly) account time-to-learn as a type of cost, that cost is roughly equivalent to the time it took to learn the alternative you already know. I think a better analogy would be an old raincoat versus a new, similarly priced raincoat. Perhaps the new raincoat doesn't actually cover you properly from the rain though; unfortunately programming languages and tools are a lot more difficult to analyze than raincoats. Do we agree, at least, that some chasing of shiny things has been very beneficial to our field? That our current crop of languages are better raincoats than architecture specific assembly language? That assembly language was itself a better raincoat than machine language? If you will stipulate this, then is it your position that we have reached the pinnacle? That no more advances in productivity or correctness can be made? If this is your belief, then OK, that's fine, you are entitled to it, but I do not believe such a pinnacle even exists, much less that we have made it there. And if we indeed have not reached the pinnacle, then we need people who are early adopters, who are willing to try out and write for technologies that are immature and untested. Maybe most or all of them fail to be even as good as what we already have, and the whole thrust turns out to be fruitless, but with no thrust at all, success is not even a possibility. Everything old was once new, and all the old-fashioned technology once had early adopters being made fun of for their impracticality. Plus, learning new things is a great way to improve as a programmer and it's a lot more fun; all that other stuff is just incidental.

by axod 16y ago

bad_user 16y ago

> Why is startup time relevant if you're doing backend server stuff? It's pretty much the ideal use case for Java. Even on "backend server stuff" I pretty much prefer the FastCGI model, with multiple processes handling requests, as I don't have to worry about memory-leaks or about a rogue thread that can take out my whole server. With the JVM, this is impossible ... you need a monolithic process that takes care of everything (no support for forking, long startup time, high resource usage). And having multiple apps running in their own JVM (so they don't interfere with one another) is no panacea. You can also look at the problems Google's App Engine has with Java apps ... as resources are elastic, extra servers / VMs are loaded on demand, and the first requests hitting such a cold VM almost always ends up with a timeout error (although they are working to fix this, the magnitude of this issue is not the same with Python on GAE). And this is solely because of the slow warm-up time. > People will marvel over your great fashion sense, but will it solve the problem even as well as a less fashionable approach? I have ideas that I can prototype over a single weekend, which wouldn't be possible without the help of those people with "great fashion sense". > The amount of man hours wasted on reinventing the wheel in programming languages is staggering Why don't you teach people then how to spend their time better with constructive arguments? The easiest thing in the world is to dismiss / critique.

axod 16y ago
> "Why don't you teach people then how to spend their time better with constructive arguments?" Yeah but it's like trying to tell people "Hey don't buy that prada coat for £500 that doesn't actually cover you properly from the rain, buy this old fashioned raincoat instead that actually functions well as a raincoat." I just wish people would spend more time becoming good programmers than chasing the new shiny things. I'm not sure the argument about rapid prototyping is a good one. Maybe it's just you can get it done in a weekend because you enjoy playing with new shiny thing, so are more productive. The old-established-stuff has a multitude of libraries that have been war tested to ultimate reliability though... I'm just getting old. Ignore me. Every generation has to reinvent the wheel for some reason anyway :)
- sanderjd 16y ago
  I thought this thread might benefit from my response as a self-admitted shiny-thing-chaser. Your Prada coat analogy is fairly silly, as I'm sure you are aware. First of all, when it comes to programming languages/frameworks, both the new-hawtness Prada and the "old fashioned" raincoat tend to be free, so there is no financial rationality argument to be made. Even if you (correctly) account time-to-learn as a type of cost, that cost is roughly equivalent to the time it took to learn the alternative you already know. I think a better analogy would be an old raincoat versus a new, similarly priced raincoat. Perhaps the new raincoat doesn't actually cover you properly from the rain though; unfortunately programming languages and tools are a lot more difficult to analyze than raincoats. Do we agree, at least, that some chasing of shiny things has been very beneficial to our field? That our current crop of languages are better raincoats than architecture specific assembly language? That assembly language was itself a better raincoat than machine language? If you will stipulate this, then is it your position that we have reached the pinnacle? That no more advances in productivity or correctness can be made? If this is your belief, then OK, that's fine, you are entitled to it, but I do not believe such a pinnacle even exists, much less that we have made it there. And if we indeed have not reached the pinnacle, then we need people who are early adopters, who are willing to try out and write for technologies that are immature and untested. Maybe most or all of them fail to be even as good as what we already have, and the whole thrust turns out to be fruitless, but with no thrust at all, success is not even a possibility. Everything old was once new, and all the old-fashioned technology once had early adopters being made fun of for their impracticality. Plus, learning new things is a great way to improve as a programmer and it's a lot more fun; all that other stuff is just incidental.