Thread: deliverance from complicated programing languages?

I have to agree with you CornedBee. The statement was overly simplistic. An attempt at addressing my POV that I could have developed better.

The point was - is - to address the importance hardware has on apparent software performance when all else is equal.

Originally Posted by Mario F.

The point was - is - to address the importance hardware has on apparent software performance when all else is equal.

Don't you mean actual software performance? Because apparent (subjective) performance has really nothing to do with hardware at all. It's about how good the programmer is at hiding delays from the end user.

Originally Posted by CornedBee

Don't you mean actual software performance? Because apparent (subjective) performance has really nothing to do with hardware at all. It's about how good the programmer is at hiding delays from the end user.

Hmm... Let's see.

I measure actual performance only when comparing to other software of the same kind. In that context, I would say actual performance will be dictated by good programming practices, code optimization, choice of language and even within the same language, choice of compiler.

By apparent performance, I mean what is perceivable to the user. Some performance differences are so minimum that they are never perceived by the user. Conversely, some may be larger, but in the context of the application usage they have little to no impact.

And this is the cornerstone of my reasoning. It brushes Bubba's rightful concerns. But it is not really what I'm defending here. What I'm saying is that the choice of programming language should only rarely be a matter of performance because a great part of the software being developed can be developed in "slower" programming languages with little to not impact on the user's experience. Naturally, some software types can't be so lenient.

I do go one step further though... I also defend that some speed loss choices can be taken (the 2 seconds example) based on the fact they will have little impact on the user experience, assuming that if the choice was to move to a "faster" programming language that would complicate the life of the programmer (he doesn't know that language so well, or foresees a longer/unacceptable period of development, for instance).

Well I decided to chime in as well now.

I completely agree with CornedBee's statement. Some elements of speed do belong to the hardware, and others do belong to the programming language, but a lot of it relies on the programmer. If the programmer chooses a good algorithm versus a bad algorithm, then in the end the program will perform much better.

I have sat through many interviews with various software companies, and this is what I have noticed - they want to know if you really understand how to program well, despite what language you are using! If you know how to program well, and program efficiently, then you can get the job.

About a month or so ago I started a thread that linked to an article which primarily talked about the merits of C or C++ vs. Java. The author of that article talked about how in today's world we are producing more and more people who have Computer Science degrees, but simply don't know how to program. It is because they have not learned the essential concepts of good algorithm design, good coding techniques, and good performance optimization. This is an essential part of any programmer's education.


Now, I noticed that Mario F. said something along the lines of "a program taking 5 seconds to start up is not slow." I completely disagree. Users want things to happen fast and instantaneous, and therefore, a good response time to a user is usually no longer than 3 seconds. Any longer than 3 seconds and the user will begin to lose concentration. This is how "splash screens" came about initially. Some programs took much longer to load, and users would lose concentration and get frustrated. In order to keep the user happy, a "splash screen" was instantaneously displayed on the screen so it looks like something is happening, and therefore the user's concentration doesn't go away as fast. For some highly intensive programs a splash screen wasn't enough, and they even put in a loading bar to keep users happy.

The bottom line is, however, that after about 3 seconds a user's concentration begins to stray, and so anything slower than that could be considered as "slow". Of course this is different for different tasks that need to be performed. Here is a table that I saw recently:

Attachment 7877


Now, a programmer should do all he can to make sure his program is efficient and runs well, and does not bloat. In some cases, however, it could also be the fault of the scheduler in the OS. Maybe the scheduler needs some work.

In the case of Firefox which was discussed earlier, I have had no problems with it. I have not actually looked at Firefox's code, but I assume (purely an assumption) that they are using multithreading, and have a seperate thread for each tab. I think having a separate process for each tab would be going overboard, especially since communication between threads is much faster and easier than communication between processes.

I'm still not convinced David

5 seconds is really a long time? Firefox can take that long on a fast machine. All you have to do is to make sure it needs to be paged. Microsoft Office software takes that long. Much software does.

The argument of user losing interest works well for websites, not just for software. I used to listen to that back in the 80s. Not much anymore. It takes certainly more than a 5 second difference between two programs loading times for it to make a difference. Especially when one of them offers a richer set of features and that has a natural impact on loading times.

However we seem to be wanting to turn the discussion towards the quality of software development, again.

The only thing I was - and still am - trying to comment on is the choosing of a programming language over another based on "speed". Ruby is definitely slower than C. But is that going to stop a Ruby programmer developing, for instance, a measurements converter, or a MD5 calculator, or a tile based client for a web turn based wargame?

These type of applications have little requirements in terms of speed. It's not to say one should be sloppy coding them. I feel I have to say this again, in case we get to it again. That is simply to say I should choose a tool for programming those application based on other considerations than speed.

I believe speed is overrated in this context. Especially because a large part of the application we develop do not have very high speed requirements.

(I don't know if I'm on the ignore list still, but I'll just say it anyway.)
For small applications, of course it doesn't matter what language because the speed impact will be small. But for larger applications, it does indeed matter.
And for that matter, load time is also bad and why the .NET Framework destroys so many applications. Who is to say how much faster Visual Studio wouldn't be if it wasn't built on top of the .NET Framework?

I do have to agree that I too don't see much point in developing non web based applications for the .Net framework. However this framework is not going to go away. So we might as well get used to it as yet another solution that is bound to improve with time.

Yes, this is true, but we can avoid it unless we must use it, or the advantages outweigh the disadvantages.

It's possible, it's just not worth the effort, because the generated machine language isn't very efficient.

Originally Posted by sept

There ARE people who care if it takes 1 or 5 seconds. Even if it does not matter for you, it matters.

So Mario F., if I understand right your answer is 'there "is" already deliverance from complicated programming languages because we have easy programming languages'. Or in other words 'there will be never deliverance from complicated programming languages because speed is not an issues for 99% of people".

Well, this is an interesting way to avoid my basic question. The basic question was something like "will we get an compiler (to machine language, not just byte) for easy dynamic scripting languages such as ruby?".

Currently compiling (to machine language) dynamic languages isn`t possible due to it`s design. Will some expert found a way anyway?

The problem, when designing a computer language, is that things that become real easy in an interpreted language (such as Byte-code) can be REALLY difficult in a machine-language compiled language. The way that a language is designed will often determine if it's going to compile directly to machine language or not - the key here is to "make it machine language friendly". One of the keys here is "polymorphic variables" - that is, variables that are integer, string or float depending on their input value and usage. That essentially requires some sort of overhead in the compiled form. In an interpreted form, the digging out of a variable value is not machine-language directly, so it will have some overhead anyways. I picked the topic of polymorphic variables because that's usually one of the key points that people bring out that they "need" in C or C++, that other languages (such as PHP and python) allows them to use.

The other factor is of course that you can make your own high level language in C or C++ - that is, once you have a sufficient library of functions, you can re-use those functions as part of a high level functionality.

--
Mats

So Mario F., if I understand right your answer is 'there "is" already deliverance from complicated programming languages because we have easy programming languages'. Or in other words 'there will be never deliverance from complicated programming languages because speed is not an issues for 99% of people".

Nope. Nothing like that. "Deliverance" is conditioned by many variables like tools (programming languages, if you will) availability and functionality, programmer's knowledge or development times constraints, to name a few. Performance is also one of those variables. It's the programmer task to analyze his project constraints and requirements as well as his capacity to handle those at the light of his knowledge.

What seems to happen sometimes is that performance requirements are not well measured and we tend to give them an importance they don't have for that particular project.

Well, this is an interesting way to avoid my basic question. The basic question was something like "will we get an compiler (to machine language, not just byte) for easy dynamic scripting languages such as ruby?".

Currently compiling (to machine language) dynamic languages isn`t possible due to it`s design. Will some expert found a way anyway?

And I answered someday someone may. I also theorized the solution may not be solely based on managed to machine code translations, but may as well come from a different programming paradigm yet to be developed that allows to combine speed with easy of use.

As such, I wasn't avoiding the question. I introduced the speed issue at the end of my reply because you did mention it in your initial post as one of the requirements and I wanted to have a say on that. Unfortunately, it became the only thing people decided to comment on.

Quiet frankly I would have rather preferred if any comments on my post had been directed to the programming paradigm portion.

Originally Posted by Thantos

Since I have never worked with Ruby I have to disagree with this. It is easier to use a language that you are familiar with then to use a language you are not familiar with. Suppose there is a language with a much simpler syntax then English, it would still be harder for me to communicate in that language instead of English.

C can be very easy to read if you purposefully work towards that goal. Meaningful variable names, good indention, and useful comments can do much more then pretty syntax.

Nevertheless, some things such as GUI is very difficult to do in C/C++.
This in turn makes C/C++ a very difficult language on that regard.
Also compared to other languages, C/C++ is also very difficult due to the low level, such as pointers, arrays, bounds, etc, etc. Some may have trouble grasping it, but I agree with you that once you get to know it, it's not a difficult language itself.