views:

37

answers:

2

Usually if you write a program using a well-known interpreter/script language or framework, there's usually a thing the developer can't control - how long it will take for program to start. But due to innovative nature such languages are easier to develop and reflects the infamous RAD concept. On the other side a user usually don't care how the program is developed, even if they know, they just want the software to work reliably and fast. An example of this difference is existing admins for sqlite databases. There are ones that made with such languages and they usually take significantly more to start than the ones made with general compiling languages (Ironically it breaks the "lightness" of sqlite)

I know that computers becomes faster every day and we can be sure there will be no noticeable difference soon, but the reality is here.

So what you think? Should a developer that knows that developing with a language A is fun and "highway" to develop remember that future users won't notice "fun", but will notice "slowness"

+1  A: 

In the "good old days" (which weren't that great at the time), programmers would do everything by themselves. We would tell the graphics chips how the display should look like, we'd poke colors in color registers, we would draw lines by flipping bits in memory.

Startup was instant.

Today, the software needs to figure out all these things by itself. Since code isn't really that smart (yet), they do it in the most general way. So often things get initialized which you'll never need. On the positive side, you can use the frameworks and scripting languages today. If everything was optimized, they'd still be working on it in the labs.

But I still have hope. Java upto 1.1 was slow as hell. Then came 1.2 and things got better with every version. Today, Java is easy on par with any compiled language.

So while they are slow today, the next version can be much faster if that is necessary (which means: someone feels the need to work on this area). Which means all people using that piece of code can benefit.

In the old days, everyone would have to change their start up code. Today, you just update the version and build again.

So is it a problem? Not really; if it was, someone would fix it. On top of that, a lot of software today is started once and then runs for days, weeks or even years. In this case, startup times really don't matter.

Eclipse takes three minutes to start on my machine. That's three minutes where I have leisure to plan my day. After the start, I have eight hours of uninterrupted work. And I feel that this is much more important.

Aaron Digulla
So for any such language user should hear "Please, wait a little, it will be much faster soon"? )
Maksee
No. Users will complain when the overall performance is bad (i.e. when it's slow to start *and* execute). If it just takes a couple of moments to start, that's usually OK. If you want to sell something and users complain "start up is too slow", then you have an incentive to fix it. If that doesn't happen, there is no problem, right?
Aaron Digulla
A: 

I think we need to keep in mind why "Fun" is good. A "fun" language is usually good because it is easy and powerful. In the end it usually makes it easier to write clean, maintainable code.

I believe maintainable code is more important that blindingly fast, but confusing code.

So in the end I believe that even though there might be some slowness, the resulting product may be of higher quality and have a longer lifespan.

willem
Remember, sqlite is made in plain c, it is now most widely deployed sql database. It's questionable, but many thinks that the developer is matter, not language. On the other side, a bad developer can ruin the best concepts of a good language
Maksee