deliverance from complicated programing languages?

The goal is to create even greater applications then we have today. Therefore we need more easy programming languages. Logical, if it`s more easy and it needs less time to program we can create better programs.

For example I looked into ruby. It`s really great. Very easy to learn and foreign code is easy to understand some somewhat "logical". But it`s to slow and not possible to create "professional" big apps, for example I doub`t Firefox could be programmed in it with reasonable speed.

C is MUCH harder (I hope no one argues which this opinion?), but it`s fast.

Why not get all advantages together?

The only thing we would need is a ruby to machine (not byte) code compiler. Will we get such a thing at some time? Or would it be really impossible to create such a compiler? Or do we need to wait until computers are so fast so the speed of the programming language does no longer matter?

It's possible to write a Ruby byte code compiler. Look at IronRuby. It's a project that creates MS DLR bytecode from Ruby code. I don't know how complete the project is (or how complete the DLR project is, even), but presumably, IronRuby should execute considerably faster than Ruby.

The language itself plays a very small part in the speed of programs. It's all about the implementation. The original Ruby implementation is pretty simple, pretty extensible, and was pretty quick to program - the author wanted his new language to play with - but it's dog slow. Doesn't mean it's not possible to write a fast runtime for it.
Similarly, there's CInt - a C interpreter. Guess what: compared to natively compiled C, it's very slow.

On the other hand, the language does have some influence. Dynamically typed languages always have a speed penalty, because their variables must be capable of holding an object of any type. Sometimes you can determine, through static analysis, that a specific variable won't ever hold anything but a specific type, and you can optimize for that, but such static analysis is an enormous computation overhead and not practically feasible - even theoretically impossible in some cases, because dynamic languages like Ruby allow dynamic creation of code.
A more realistic approach lies in tracing execution and just-in-time compilation. A piece of code is interpreted the first time it's executed, and the interpreter records information about it. On the second execution, this information is used to create machine code optimized for the same situation as the first execution, but if the situation is not the same, it will again be partially interpreted. Such deviation is noted, and better native code is created, and so on. The more often a piece of code is executed, the better the code becomes. This approach is used in virtual machines, of course, mostly with byte code.

But this technology is young.

Usually, the easier the language is, the slower it runs due to the overhead it hides from the programmer. This is simply the way things work.
Yes, it will probably be possible to create big applications like Firefox in a RAD language someday, but perhaps not today.
There will always be a need for C/C++ I think, as there will always be a demand for RAD tools such as Visual Basic.

Quote:

---

Originally Posted by sept

Why not get all advantages together?

---

One day someone may. This is not the end of programming languages design. The world is still turning. The fact we have different programming paradigms is also, as I see it, a proof that better programming methods are still being researched.

However, software development is still in its infancy. I can only guess (hope, is a better word) the needs become increasingly complex, forcing software development in the same direction. In the light of this, there will always be a race between programming languages and market needs in terms of software complexity. What I'm trying to establish here is that complexity is not only a measure of the programming language syntax and semantics. It also relates to the problem the programming language is trying to solve at that time; something that seems obvious, but we overlook sometimes. So you can have an easy language to learn and program with. But if the problem is complex, the code needed to solve it will too become complex.

---

As for speed (performance)... well, I'm very critic of this word. I think we overrate its importance. It is natural that, while discussing this topic lines like "this programming language is slow" or "performance is important" are commonplace. But let us be honest about it. Is it really that important?

I say that for a very large percentage of what we do everyday, it isn't. This is not to say we shouldn't try and squeeze every cpu cycle out of our code when we can. This is to say instead we shouldn't do it when we don't have to if that presents us with new problems. If you take a critic unbiased look at whatever software you are developing at that time, you will see this is a big % of your total code.

This, after all, goes hand in hand with the same principles behind early optimization, which I should recall you is generally considered something one should avoid.

So is ruby really that slow? Is C# really that slow? What about Java? No, they aren't for a large part of the world of problem solving. The exceptions to what I'm saying are there for everybody to see and are well known. However, just because I shouldn't develop a 3D game in Java, doesn't mean Java is slow. Same goes for C# or Ruby. It means they aren't the right languages for the task. Meanwhile, there are highly complex scientific programs developed in Java, for instance. So, are these languages really that slow?

I suggest you put your hand over your conscious and give this a real thought. How slow is slow? This is the question, I guess. One that we seldom really ask.

And for the last nail on the coffin of performance concerns...

What will be faster? The same software developed not in Ruby, but C++. Or the same software developed in Ruby, but running on a better processor?

You know the answer to this. Naturally, this is a generalization (this question would fail, for instance, the above 3D games). But you do know the question doesn't fail for a large part of the software domain.

Well, if we define slow as overhead per time period, then C# & co would be slow compared to C++, as they would take more cpu cycles to do the same as a C++ app.
The whole reason we have C, for example, is that there is need for time critical code, especially on slow processors such as embedded.

Many today do not heed the word "speed," but I really think they should. I think C# is bloated, for example, because it takes forever for a program compiled with it to start. And when it comes to complex tasks, these languages overhead adds to the time it takes, which, IMHO, is totally unacceptable since there are so many things on the computer that can take hours. If the code was just a little more optimized, imagine how many minutes could be cut off.

Anyway, in the future when processors approach 128 x 1 THz, this may become irrelevant, but for today, I think it holds true.

Quote:

---

Originally Posted by Elysia

The whole reason we have C, for example, is that there is need for time critical code, especially on slow processors such as embedded.

---

That is not the reason we have C. No programming language I know of was ever designed because "we needed performance". Check C history on wikipedia or other sources for the reason C exists.

It is instead a characteristic of C. But other languages there are that outperform C in specific tasks.

However you did use the word. Critical. That was my point all the time.

Quote:

---

I think C# is bloated, for example, because it takes forever for a program compiled with it to start.

---

I have to confess I'm still to see a C# program "that takes forever to start". I have .net installed too on this aged PIII 1MHz with 500Mb RAM. And have been using software developed in C# (and have tried it myself) and I don't see what you see anywhere.

Quote:

---

Originally Posted by Mario F.

That is not the reason we have C. No programming language I know of was ever designed because "we needed performance". Check C history on wikipedia or other sources for the reason C exists.

It is instead a characteristic of C. But other languages there are that outperform C in specific tasks.

However you did use the word. Critical. That was my point all the time.

---

Not why C was invented, but why C still lives today, is what I meant. If we had no need for fast code, then we would see shifts towards more RAD, but C/C++ is still very popular, even today.

Quote:

---

I have to confess I'm still to see a C# program "that takes forever to start". I have .net installed too on this aged PIII 1MHz with 500Mb RAM. And have been using software developed in C# (and have tried it myself) and I don't see what you see anywhere.

---

I'm thinking that's because you are "used" to "loading times." If something takes more than a second to start, I call it bloat because that's what most of applications, at least mine, take to start. It takes one second to start an MFC app and it takes 5 to start a .NET or C# one. Then I'd call it bloat, but it's all suggestive.

Quote:

---

Originally Posted by Elysia

Not why C was invented, but why C still lives today, is what I meant. If we had no need for fast code, then we would see shifts towards more RAD, but C/C++ is still very popular, even today.

---

No. That's not the reason either was C is still a popular language. Please check the same sources for the real reason why C is still popular.

Quote:

---

If something takes more than a second to start, I call it bloat because that's what most of applications, at least mine, take to start. It takes one second to start an MFC app and it takes 5 to start a .NET or C# one. Then I'd call it bloat, but it's all suggestive.

---

I believe you mean subjective. Yes, it is. Even more so, because I insist I don't see that happening here.

Anyways yes, it's subjective. That was my point all the way. So it's not bloated. It's just slower. So, I'll ask again, how slow is slow?

5 seconds to start an application on your machine is not slow. It's not worth a demerit of the programming language. That's just it.

Quote:

---

I believe you mean subjective. Yes, it is. Even more so, because I insist I don't see that happening here.

---

Yes, of course... subjective. Silly dictionary.

Quote:

---

Originally Posted by Mario F.

As for speed (performance)... well, I'm very critic of this word. I think we overrate its importance. It is natural that, while discussing this topic lines like "this programming language is slow" or "performance is important" are commonplace. But let us be honest about it. Is it really that important?

I say that for a very large percentage of what we do everyday, it isn't. This is not to say we shouldn't try and squeeze every cpu cycle out of our code when we can. This is to say instead we shouldn't do it when we don't have to if that presents us with new problems. If you take a critic unbiased look at whatever software you are developing at that time, you will see this is a big % of your total code.

This, after all, goes hand in hand with the same principles behind early optimization, which I should recall you is generally considered something one should avoid.

So is ruby really that slow? Is C# really that slow? What about Java? No, they aren't for a large part of the world of problem solving. The exceptions to what I'm saying are there for everybody to see and are well known. However, just because I shouldn't develop a 3D game in Java, doesn't mean Java is slow. Same goes for C# or Ruby. It means they aren't the right languages for the task. Meanwhile, there are highly complex scientific programs developed in Java, for instance. So, are these languages really that slow?

I suggest you put your hand over your conscious and give this a real thought. How slow is slow? This is the question, I guess. One that we seldom really ask.

---

Well, I am mostly interested in applications for end users. Example...

Imagine you are Mozilla. Could you switch programming language to ruby? I don`t think so. It would be to slow on most average computers. Less people would use it and the less people use it the less money you earn. Therefore from commercial view the speed is REALLY needed in some cases (sure not all).

I also don`t like it myself if apps needs loads of time to load or it lags while using it. Most programs I use are written in C or C++. Not because I am a fan, just because of felt speed.

Indeed, I think this was my own point.
Not to say C# is "slow," but C/C++ will always be faster than C#.

Quote:

---

Originally Posted by sept

Imagine you are Mozilla. Could you switch programming language to ruby?

---

Well, I wouldn't if I were Mozilla because C++ has a larger user base and I could count on more people contributing to the code. Not to mention the fact Mozilla background and history is based on C and C++. It would be silly of me to pretend that much.

However, say, a browser fully developed in Ruby capable of rivaling Firefox wouldn't shock me. The gecko engine is not a sublime piece of engineering. Far from that. I would wager Presto to be a superior engine (not to mention it's the only of the current 4 big ones that passes the Acid2 tests). And even if a browser/engine developed in Ruby was slower than Mozilla, but far more standards complaint and offering a richer functionality, wouldn't that be better?

Again, ask yourself: How slow is slow? Say, 2 seconds extra, average, taking to load a page is unacceptable? Maybe for some. But it's not a reason to dismiss this language as a potential tool for just that if it happens I'm more proficient at it.

Count two seconds in your head. Does that time span shock you? What if I told you the next computer processor would reduce that to just 1 second? And the next one to half a second?

Quote:

---

Well, I am mostly interested in applications for end users.

---

Well, you should always learn more than one programming language. It's a matter of common sense. Even C or C++ aren't the best choices for some programming tasks. It will also give you more power over problem solving since you'll be the proud owner of more than one programming tool.

As you well put it, it annoys you the fact C++ seems to overly complicate certain programming tasks, like that of developing for a GUI. It's not its fault really... it's the GUI API that complicates your life. But aside from that, what you should look at is spreading your knowledge through a few different tools and use the one that suits you best at the time.

If you are developing a universal measurements converter, does it really matter if Ruby is slower than C++? Other things will instead come to your mind, like how fast can I do this in C++ or in Ruby? What language do I feel more comfortable programming with? Which one offers the least maintenance cost?

Quote:

---

Originally Posted by sept

Well, I am mostly interested in applications for end users. Example...

Imagine you are Mozilla. Could you switch programming language to ruby? I don`t think so. It would be to slow on most average computers. Less people would use it and the less people use it the less money you earn. Therefore from commercial view the speed is REALLY needed in some cases (sure not all).

I also don`t like it myself if apps needs loads of time to load or it lags while using it. Most programs I use are written in C or C++. Not because I am a fan, just because of felt speed.

---

In my experience, software developers such as Mozilla don't really put performance on a pedistal as long as the demographics of the market make them capable of releasing something ever so slower (how many people are using PIV's now?). Instead I think the largest reason might be that Mozilla a) doesn't want to force people to install a third party graphics library that works with Ruby, b) likes the fact that C and C++ have decent exposure on 100% of the market's platforms, or c) the industry is thinking that C and C++ are the only tools available that do socket programming well. Since web browsing applications need socket programming to work to some extent, and Mozilla has a desire to maintain its' own company code base (with which to base patch development, future versions, or new applications off of), I'm sure that has factored into their language decisions.

What a language can do and how it's done often matters a great deal more.

Changing from C++ to ruby could work. Because someone who can C++ will be able to do ruby of course. It`s just much to slow. Wouldn`t take 5 seconds to render a page, but 30.

For me two seconds matter. I use a special version of firefox, compiled special for my platform and rendering websites goes faster and with less lag.

My interest is enormous but my time is limited. When I open a new windows i expect it to be open instant (felt for me) and not in 10 seconds. So for me it really matters. There are even people who complain about Firefox and prefer Opera because it renders still a bit faster and needs less ram.

I also wrote before I started with C++ a little program with C# for me. The startup time and the feeling was really slow. I did send it to a friend and he asked me why it`s so slow.

Of course there are times where the speed of C++ isn`t needed. For example for web programming just a few people use C++. Interpreted languages fit better here because there is already enough lag because of the connection.

Quote:

---

Originally Posted by sept

There are even people who complain about Firefox and prefer Opera because it renders still a bit faster and needs less ram.

---

Yes. Some people clearly don't get it.

I really like Opera over Firefox due to the fact that it doesn't freeze when loading 36 pages (or more) at once. It doesn't even freeze when loading a page.
This is compared to Firefox when you can't browse a page until it's finished loading because the page will freeze. And loading 36 pages at once will lock the entire browser until all pages are finished loading.
It's just... bad practice. I hate it.

Oh yes, I also think the speed problem happens only for "power users" which surf with more then one tab.

Btw, it really wasn`t my goal to start a Firefox vs Opera debate here. :)

But if them get it or not.... This just shows that slow speed (even if only seconds) will decide if costumers use your product or not (if there is a faster alternative).

What's bad practice? Loading 36 pages at the same time. YOu can't read them at the same time. Why bother?

Because it has to load them all when starting the browser or when reloading all tabs, that's why.
I want to be able to browse and use the browser while such is in progress.
To make matters worse, if your connection is slow, it takes even longer before you can use the browser. And you can't start a new process, because it will only open a new window.

Now this is what I might expect from overhead from C#, but never C++...
The point is, I'd change to Opera in a fly if all the functionality and plugins was there.
Speed matters. As well as interactivity.

>> Because it has to load them all when starting the browser or when reloading all tabs, that's why.

But that's not necessary, simply a bad design in my opinion. I expect all tabs to close when the window closes, and fortunately some tabbed browsers do it this way.

You never considered that 36 tabs is perhaps excessive to the point that developers decided not to optimize for a stack that large? I'm shocked at how much people needlessly multitask.

Quote:

---

Originally Posted by citizen

But that's not necessary, simply a bad design in my opinion. I expect all tabs to close when the window closes, and fortunately some tabbed browsers do it this way.

---

No, they should absolutely not.
Generally, I always keep the browser open, but Firefox's performance starts to degrade after a certain while, so you have to close it and re-open it, and therefore all tabs must remain open.

Quote:

---

You never considered that 36 tabs is perhaps excessive to the point that developers decided not to optimize for a stack that large? I'm shocked at how much people needlessly multitask.

---

Not so. If it's too much, then we can we have 36 tabs open (and of it is too much, then why the heck would they prevent more processes from spawning!?)?
It doesn't matter how many tabs there are, even if it's just 5-6 it happens.

We keep getting faster processors and graphics card because speed matters.

Heh. I agree with you, citizen. Meh.
How much better is Opera than FF in terms of 36 tabs?

The last time I checked with lots of tabs, it was flawless.

Flawless implies an instantaneous load time...
Rather what I meant (can't you read my mind!?), was how long does it take to load in both cases?

Quote:

---

Originally Posted by Elysia

I really like Opera over Firefox due to the fact that it doesn't freeze when loading 36 pages (or more) at once. It doesn't even freeze when loading a page.
This is compared to Firefox when you can't browse a page until it's finished loading because the page will freeze. And loading 36 pages at once will lock the entire browser until all pages are finished loading.
It's just... bad practice. I hate it.

---

Sometimes in some forums I open about 20 topic tabs and then start reading them one by one. I use Firefox and I have no freezes nor lag. Opera actually is a little faster, yes, but that's not an advantage that would make me like it more than Firefox.

In the beginning of this thread people discussed about the difficulty of languages. I think that totally depends on people. For example, any kind of graphics or text parsing is a headache for me, but I feel that assembly, drivers and other low-level stuff in C is ridiculously easy.

Probably the weirdest thing about me is that I absolutely can't stand complicated and funky themes. As I see them they drive me mad because in my subconscious I know that they make the thing slower. That's one reason why I can't stand Vista. On my XP machine I have all design elements turned off, I'm using the classic theme, I have turned off all unneeded services and I have no applications running in the background (even no firewall nor virus protection). By the way I have a quite new computer.

>> We keep getting faster processors and graphics card because speed matters.

Well, that doesn't mean that programmer's needlessly optimize on faster hardware. In fact, that seems to be the way people prefer to solve some performance problems. Windows XP required hardware upgrades initially, as (abismally) Vista does now. Same with a number of PC games, (Crysis). But people obviously aren't throwing in the hardware for web browsing. It just happens to be that the benefits of faster hardware are consistently applied to the whole machine. :) All that "go faster" stuff happens to benefit interpreted languages as well because their interpreters have the latest greatest to work with.

>> Not so. If it's too much, then we can we have 36 tabs open?

Hard limits tend to be a bad idea. But imagine your frustration if I assumed that users of Citizen Explorer used like 10 tabs. Quality Assurance couldn't think of 36 things to do, so freezing occurs only sparingly. I do the best I can to fix it, shipment proceeded. I'm not saying that happened or even that that's what breaks it, but it doesn't seem to be the decision developers are hinging on.

Good software is still chiefly decided on how fast it goes, I see.

Quote:

---

Originally Posted by twomers

can't you read my mind!?

---

No :)

Quote:

---

Originally Posted by twomers

...was how long does it take to load in both cases?

---

To make the test as fair as possible, I timed from when the window first appeared.
Loading 39 tabs in Firefox took 45.5 seconds.
Opera took a fraction of the time (< 10 seconds).
This may be an unfair test due to the bloated plugins in Firefox and because I couldn't see 100% when all pages had finished loading in Opera, but anyway...
Opera was still very responsive when loading.

Of course, I just loaded 39 tabs of the same page in Opera and different ones in Firefox, but porting 39 tabs to Opera would be overkill for a small test...

I dunno how fair that test is, Elysia. One could consider Opera caching the page which might lead to quicker load times. Set the 39 pages temporarily as your home page. Close all windows and press the 'home' button. That should get over the fact of FF's plugins loading etc. Can Opera do the same thing? If you feel like a real test load the same pages in FF and Opera.

Quote:

---

As for speed (performance)... well, I'm very critic of this word. I think we overrate its importance. It is natural that, while discussing this topic lines like "this programming language is slow" or "performance is important" are commonplace. But let us be honest about it. Is it really that important?

---

I tire quickly of this attitude that with the current crop of hardware software speed does not matter. It is attitudes like this that create the bloatware that permeates the industry. We have more power and more horsepower than ever before and yet we continually try to move backwards to improve things that do not need improving all for the sake of making it easier. I'm convinced that with this type of attitude we will always have slower and slower software regardless of the hardware because we find new and interesting ways to make it slower.

So some company raises the bar on hardware and some other company finds a newfangled way of making it run slower. Nice.

Quote:

---

The goal is to create even greater applications then we have today. Therefore we need more easy programming languages.

---

And as for programming. It is hard, complicated, and technical. I find the easier the language the more the language gets in the way of the more complicated stuff you want to do with it. We don't need easier programming languages - we need programmers who understand how to use the languages we have. I don't always equate 'new' with 'better'.

In terms of the languages that they are programmed in, how does Firefox differ from Opera?

Quote:

---

Originally Posted by citizen

>> Not so. If it's too much, then we can we have 36 tabs open?

Hard limits tend to be a bad idea. But imagine your frustration if I assumed that users of Citizen Explorer used like 10 tabs. Quality Assurance couldn't think of 36 things to do, so freezing occurs only sparingly. I do the best I can to fix it, shipment proceeded. I'm not saying that happened or even that that's what breaks it, but it doesn't seem to be the decision developers are hinging on.

---

You'd at least think they would allow to open more instances of the process. It would go lengths around the little problem, and they'd have to work less on the whole matter, as well...

Quote:

---

Originally Posted by twomers

I dunno how fair that test is, Elysia. One could consider Opera caching the page which might lead to quicker load times. Set the 39 pages temporarily as your home page. Close all windows and press the 'home' button. That should get over the fact of FF's plugins loading etc. Can Opera do the same thing? If you feel like a real test load the same pages in FF and Opera.

---

How does that work? Close all tabs, set homepage and load it?

Btw, Bubba raises an interesting point. I'm inclined to agree.

Well, in FF you can set your homepage to an array of tabs. For example for me I have gmail and google reader set as it, so if I press the 'home' button in FF it'll open gmail on the tab I press home in, and reader in a new tab. If you set your homepage as 39 different pages (tools -> options -> main -> Use Current Pages), then press home it should open 39 different tabs, without you worrying about plugin load times etc.

39 tabs opened in a browser is no way to test that browser speed/performance/quality/whatever. It's, at best, a way to measure an user insanity. The more tabs, the more insane and the least I'll be open to reason with them. I advice strong medication and 6 months rest away from any computer. And I'll stop with the superlatives here. I could go on forever.

39 tabs is not what any decent browser maker aims at. It's not useful to a user to. And the time one could gain from better code to optimize the load of such tabs will be wasted by the user on the time it takes for him to find the tab he wants. I can't believe this argument was brought up to justify one browser over another.

Quote:

---

It just happens to be that the benefits of faster hardware are consistently applied to the whole machine.

---

This is exactly the cornerstone of my reasoning. Software performance is more tied to hardware improvements than it is to language design. Naturally there are differences; CornedBee brushed it on his post. However, we cannot negate a language capacity based on the fact it comparatively under-performs. I gave an example of one such application where speed is not a concern. Like that, there are many other type of applications.

Speed is the realm of Hardware. Programming languages have to knock to come in.

I think we have different versions.
I use 9.50 Alpha, which only has Tools -> Preferences -> General -> Set current.

Quote:

---

Originally Posted by Elysia

You'd at least think they would allow to open more instances of the process.

---

I don't see why that's useful...

About Firefox, I usually browse for 2 hours without restarting it. And I usually finish what I was doing before it. I don't see any direct performance hit when it has been running for a very long time. I just know it starts using more memory due to caching. In fact, I usually prefer closing the browser just to close all the tabs. So it would be very annoying if it would keep everything open. What I really like is that Firefox is capable of loading the whole previous session when something caused an unexpected shutdown. Like a power failure, which happens quite often for me.

Quote:

---

Originally Posted by Mario F.

Speed is the realm of Hardware. Programming languages have to knock to come in.

---

I don't think so. With my current XP settings even a Pentium III 450Mhz worked quite quickly. I just had to choose the right applications to use. I bought a new computer only because Photoshop, Flash and some games didn't work well on it.

My dream is to make a huge application that does gazillion things but runs veery quickly on an old machine...

GRR... I wanted to use the Edit button. :(

Quote:

---

Originally Posted by Bubba

I tire quickly of this attitude that with the current crop of hardware software speed does not matter. It is attitudes like this that create the bloatware that permeates the industry.

---

Actually it is not. The attitude that creates the bloatware that permeates the industry is poor quality control, deadlines being set based on marketing and not on software analysis and inadequate team management. Probably also what you say, I would have to agree. But not only and probably not the most.

Meanwhile, the discussion was about about programming languages. Not about the quality of the software that comes out of those programming languages, Bubba.

Quote:

---

Meanwhile, the discussion was about about programming languages. Not about the quality of the software that comes out of those programming languages, Bubba.

---

Lest I remind you your posts began this portion of the discussion.

Quote:

---

Originally Posted by Bubba

Lest I remind you your posts began this portion of the discussion.

---

No they didn't. Read better.

Quote:

---

Originally Posted by maxorator

I don't see why that's useful...

About Firefox, I usually browse for 2 hours without restarting it. And I usually finish what I was doing before it. I don't see any direct performance hit when it has been running for a very long time. I just know it starts using more memory due to caching. In fact, I usually prefer closing the browser just to close all the tabs. So it would be very annoying if it would keep everything open. What I really like is that Firefox is capable of loading the whole previous session when something caused an unexpected shutdown. Like a power failure, which happens quite often for me.

---

When using Firefox for a while you'll start notice how tabs takes longer to load, how it takes longer to load pages and even doing normal tasks such as clicking on a link starts taking a lot longer.
Restarting Firefox fixes this.
So when having lots of tabs, performance quickly degrades. It becomes slow.
Opening new processes would allow you to split tabs among processes, thus fixing the whole "it wasn't designed for 39 tabs" argument.

Quote:

---

Originally Posted by Mario F.

39 tabs opened in a browser is no way to test that browser speed/performance/quality/whatever. It's, at best, a way to measure an user insanity. The more tabs, the more insane and the least I'll be open to reason with them. I advice strong medication and 6 months rest away from any computer. And I'll stop with the superlatives here. I could go on forever.

---

On the contrary. A good browser does not freeze when opening tabs. And it does not take forever to open them either.
And you seem to believe that everyone is like you. In fact, people like to have many windows open at once, which is the reason we use tabs in the first place.

Quote:

---

Originally Posted by Mario F.

It's not useful to a user to.

---

Stop guessing for yourself. Just because it isn't useful to you, doesn't mean it isn't useful for someone else.

Quote:

---

And the time one could gain from better code to optimize the load of such tabs will be wasted by the user on the time it takes for him to find the tab he wants.

---

But if the user wants to open a lot of tabs and they never load then the whole switching between tabs is useless.
Plus your argument fails in that it's harder to find one tab among many and that applies to many tabs. So in order to make it easy to find one tab among many, you have to have many tabs open and that means that they must make sure the browser works fine with many tabs.

Quote:

---

Opening new processes would allow you to split tabs among processes, thus fixing the whole "it wasn't designed for 39 tabs" argument.

---

Excellent. I suggest that you suggest this to the Firefox developers.

Now, what's with "deliverance from complicated programing languages" again?

I think I already did? At least the whole more threaded bit. No freezing. But they wanted to sped time elsewhere I think? Meh, long ago.
But as for the original topic, at least one thing that can be said for certain is that there will always be a need for different languages.
Maybe not for speed, but for the approach and functionality and to what market it's aimed.

Quote:

---

Originally Posted by Elysia

Stop guessing for yourself. Just because it isn't useful to you, doesn't mean it isn't useful for someone else.

---

Software the likes of browsers are developed to the masses. And I can guess my left arm, the average user doesn't care about 39 tabs on their browser.

Meanwhile, because I don't want to guess anymore I just opened 39 tabs on my browser. All pointing to different places. My Mozilla Firefox 2.0.0.12 didn't crash or halt on my , I'll remind you again, aged PIII 1GHz 5000Mb Ram laptop. So, I'm really unsure as to who is guessing here. Me or You. I was also able to open tabs while others were being loaded. Only exception was if the page contained Flash.

And since we are on the guessing frame of mind, I then tried to go to a specific tab (1&1 Webhost Control panel). Cycling through them is not doable. Too slow. The left and right buttons don't help either since I can only see a minimal portion of the window title and the tab menu was crowded with items, but the only viable choice.

Do I find this useful? No. The time it took me to go to that tab was way more than the time it would take me to click on the bookmarks toollbar button for that page and load it on a new tab. No more guessing, ok?

EDIT: Just read laserlight's post. This is the last I'll have to say about this off-topic issue.

Quote:

---

Originally Posted by Mario F.

Software the likes of browsers are developed to the masses. And I can guess my left arm, the average user doesn't care about 39 tabs on their browser.

Meanwhile, because I don't want to guess anymore...

---

You are guessing that the 10+ million users of Firefox are like you and don't like many tabs.
Right. So that explains why FF2 had the option to save sessions, and why Tab Mix Plus, which further can control tabs, and allow them to be split onto multiple rows rather than scrolling, appears on the top 50 popular extensions.

Quote:

---

Originally Posted by Mario F.

And since we are on the guessing frame of mind, I then tried to go to a specific tab (1&1 Webhost Control panel). Cycling through them is not doable. Too slow. The left and right buttons don't help either since I can only see a minimal portion of the window title and the tab menu was crowded with items, but the only viable choice.

---

I can put tabs on multiple rows and quickly find the tab I want, as well.

Quote:

---

Originally Posted by Mario F.

No more guessing, ok?

---

Uhuh, let's stop assuming everyone is like you.

And that should clear up a few things.

I wanted to comment on this stuff, but the tone of this thread discouraged me. I think it's better if we let it rest. No more Firefox and Opera speed comparisons, please.

Quote:

---

Speed is the realm of Hardware. Programming languages have to knock to come in.

---

I partially disagree. Speed is not just the hardware's business. It's not the language's business, though. It's the programmer's business. Poorly chosen algorithms and data structures hurt more programs than any language effect could ever do. They hurt more than any hardware upgrade can ever make up for, because hardware improves linearly, while poor algorithms hurt performance quadratically and exponentially.
You can mostly ignore performance when making your language choice, but to ignore performance when actually writing applications "because hardware is getting better anyway" is irresponsible and ignorant.

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.

Quote:

---

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.

Quote:

---

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.

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?

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

Quote:

---

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

Quote:

---

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&#37; 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.

Quote:

---

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.

Quote:

---

Originally Posted by sept

C is MUCH harder (I hope no one argues which this opinion?), but it`s fast.

---

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.


On algorithms:
Knowing how to create and measure good algorithms is definitely key. But most important, IMO, is knowing how to practically apply them to your environment. For example, in my computer architecture class we took a look at two different sorting algorithms (IIRC quicksort and mergesort), now from a purely algorithm stand point one overtook the other at some N value; however, when ran on an actual machine it actually did worse because the cache wasn't able to predict what should be cached as well. There are also things like knowing what hardware is available; for instance running a lot of floating point calculations on a processor without a floating point unit is going to take you awhile.


Last thought:
While desktops are getting faster, beefier, and able to mask poorer programming they are far outnumbered by the amount of embedded processors (cellphone, ipod, calculators, cars, etc), which aren’t nearly as powerful. I have a project now to build an autonomous robot that can explore and navigate a maze that is using a 16 MHz processor with 4 Kb of RAM and 128 Kb of flash. You better believe that the choice of language and algorithm will be playing a big part in its performance.

Quote:

---

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.

Quote:

---

Originally Posted by CornedBee

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

---

Ok, I see. Again wrong question from my side.

Isn`t the goal to create machine code. My goal would be to create cod fast as code compared with C.

And... This isn`t possible? Right... I think matsp explained the issue well.

Also an interesting point in this topic was that our hardware becomes better and better and at some day we are no longer forced to use fast programming languages.

Quote:

---

Originally Posted by sept

Also an interesting point in this topic was that our hardware becomes better and better and at some day we are no longer forced to use fast programming languages.

---

I would be careful with that. As hardware becomes better and better, it also becomes a good platform for solving ever more complex problems.

Besides,... we aren't forced to use fast programming languages today already. As we weren't 20 years ago or 30 years ago.

One thing that is often forgotten is that 90% of the time is spent in 10% of the code. This isn't ALWAYS true, but I've seen LOTS of code, and it holds true for a large share of the code I've looked at.

This doesn't necessarily mean that the other 90% isn't worth optimizing, but it's also likely that if the 90% takes twice as long, it won't really make a whole lot of difference.

Of course, 10% of 1 million lines of code is still 100000 lines of code, so may not be so easy to optimize. But in such a large project, it's likely that within those 100000 lines, 10% are responsible for 90% of the execution time, and those 10000 lines shouldn't be too difficult to make run faster if they are written in a RAD language, simply by rewriting those to a more optimized language, such as C or Assembler.

--
Mats

80/20 are the typically cited numbers. The famous 80/20 rule: 80&#37; of the time spent in 20% of the code, 80% of the bugs in 20% of the code, 80% of the time taken by 20% of the project, and so on.
Or this variant.

Quote:

---

Originally Posted by CornedBee

Or this variant.

---

priceless!

Quote:

---

Originally Posted by Elysia

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.

---

That is less about the difficulty of the language and more about using the right tool for the job.

Quote:

---

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.

---

Hard concepts don't make for a hard language IMO. Some of the concepts I had to learn for Prolog and Lisp were difficult to put my head around, but that doesn't mean either language was difficult. Heck I know (and tutored) people who thought that the concepts in basic algebra was hard, that doesn't make the math language hard (at least at that level).

Quote:

---

Originally Posted by CornedBee

Or this variant.

---

OMG that was great. Reminded me of:

Quote:

---

Kirk: "How long to re-fit?"
Scotty: "Eight weeks. But you don't have eight weeks, so I'll do it for you in two."
Kirk: "Do you always multiply your repair estimates by a factor of four?"
Scotty: "How else to maintain my reputation as a miracle worker?"
Kirk: "Your reputation is safe with me."

---

Quote:

---

Originally Posted by Thantos

That is less about the difficulty of the language and more about using the right tool for the job.

---

But however you look at it, it would seem that all tools for C/C++ is hard to use for GUI programming (unless you count frameworks such as .NET which is technically made from C++). So whatever you do, when using C/C++ to make GUI, you're going to have a hard time, which makes the language difficult to use.
But then again, it's not he language's fault, but the approach that is difficult.
It doesn't really matter what we do, if we do create GUI with C or C++, it will be hard. Which is kindof my point. I don't know how to explain it better... When doing GUI, perhaps another tool is a better choice for the job, as you say.

Quote:

---

Hard concepts don't make for a hard language IMO. Some of the concepts I had to learn for Prolog and Lisp were difficult to put my head around, but that doesn't mean either language was difficult. Heck I know (and tutored) people who thought that the concepts in basic algebra was hard, that doesn't make the math language hard (at least at that level).

---

Absolutely. If, for one, do not find C++ difficult. But to newbies, the language can be seen as difficult. And RAD tools are easier, though that doesn't mean C/C++ is hard.

Of course the percentage of processors running a GUI is really low so IMO the GUI arguement is junk.

Heh. There are a few other things that can be a pain, but just basic language isn't difficult.

Never saw a good GUI that wasn't hard to create, no matter the language. I despise GUI programming.

C++ is not that hard really. It's the const qualifier that is.

Anyways, the complexity of developing for a GUI under C++ is only noticeable when doing straight Win32 programming. But this is not because of the language. It's because the Win32 API is, at the lack of a better word... complicated.

MFC helped but still not that much. 3rd party vendors like Borland and Open Source projects like wxWidgets did IMO a much better job at encapsulating that nightmarish API. My experience with Borland's VCL is limited so I may be disputed on this, which will be fine.

Regardless, apart from the const qualifier, I find C++ concepts easy to grasp, its logic makes sense and it's actually easy to learn. If anything, just an hard language to master.

EDIT: hmm... guess I misunderstood the earlier posts. Seems you fine people are talking of coding a GUI, not coding for a GUI

You mean you find the concept of a volatile static const variable difficult to understand? pfft ;)

Actually, I find it kind of hard to understand why you would make a variable (as opposed to a pointee type) const and volatile, yeah.

Quote:

---

Originally Posted by Mario F.

EDIT: hmm... guess I misunderstood the earlier posts. Seems you fine people are talking of coding a GUI, not coding for a GUI

---

Ehm, well, that's not really true. I don't know if I should separate them, though. Coding a GUI and coding for a GUI can both be a pain in C/C++ since there really is no excellent and terrific GUI to do it for you.

Quote:

---

Originally Posted by CornedBee

Actually, I find it kind of hard to understand why you would make a variable (as opposed to a pointee type) const and volatile, yeah.

---

You have a signal that is coming from an outside source that can change. So you need volatile so that the compiler doesn't optimize it into registers. However, your section of the program must not change the value. So you make it const.

That is just scary.

But really, const could really run circles around my mind. It was, for me, the hardest concept to understand in C++. Not so much the principle, which is rather - as with all complicated things - simple. It was the implications and the whole new world of const correctness.

Ironically, I only started understanding const and const correctness when I started using const everywhere. I followed the advise of Prelude, I think (can't recall exactly) which went something like this; Fight the beast and const everything. Said and done. Shortly after my sig was born.

Quote:

---

Originally Posted by Elysia

Anyway, in the future when processors approach 128 x 1 THz, this may become irrelevant, but for today, I think it holds true.

---

Maybe but people also wondered how in the world we would ever find the data to fill a cd-rom. Optimization is especially relevant today. Take Will Wright's spore (omg) for example. I heard him say that they had compressed the model files to something like 20 kb(not exactly sure on the number). We are use to having lots of overhead. If everyone made efforts like Will to keep everything compact and efficient then companies wouldn't have to wait a few years to release their ultra shiny graphics. I guess every team isn't as brilliant as Will's though. I believe he hand picked them.

Thus the word "may" ;)
We never know what the future holds...

Part of the problem is that high level languages have overhead due to their nature. Good compilers and good runtimes can mitigate this to a high degree, but, with a language as dynamic as Ruby or Io, things can get really, really hard to get down to the machine level if you want to keep that amount of expressiveness. Unless you compile down to a common denominator, like ISO C or something. Feasibly you could say that you could have a very dynamic language that compiles to C and is more efficient than C - the compiler has more knowledge and can generate code that would be impossible to create by hand. This would require a Sufficiently Smart Compiler however, so the overall goal is a bit of a ways off.
Of course, you could cite Lisp Machines or something or another, but we're just talking commodity hardware, here.

Another problem is no matter how awesome our compilers are, sometimes they just are not good enough for things like embedded devices. C is a big player in this market because it's brutally low level (relatively, I don't want to step on toes here) and a relatively simple language. I can't imagine getting Ruby or Haskell (compiled) to run on a microprocessor with 16kb of RAM, unless certain things were severely trimmed which would just dilute the greatness of your language of choice. C doesn't really have this problem, either.

And of course, another part of it has to due with what we do in the development process: premature optimization is bad, but we may not always maturely optimize; likewise, we may not choose the proper data structure to represent the logic of this program, so we may be performing suboptimally, due to perhaps the structure being too complicated and convoluted for such a pure need, but this might be because we don't know the structure has existed already.

The overall problem is pretty classic, though: we don't choose the right option. Yes, we don't get the niceties, but then again, we normally don't get all the niceties in life, either. The fact is the niceties were nice but they didn't help us as much as another, perhaps little-less nice solution (perhaps less concise or expressive, but it may have a well-hardened library that cuts our development time 50&#37; or more.) This is why professionals don't just stumble into a project, they must weigh pros and cons to get a good choice in the same way you probably make basic economic decisions (which is all language choice is, really.)

Ok, again a good point. Maybe our desktop and server computers are at one day so fast that it does not matter if we use ruby or C. But there will be always new embedded devices with very limited resources, one of the most extreme example are Smart Cards (yes, it`s a small micro computer). So there will be always need for fast and low level languages, for kernel/driver development and also for end user applications.

Quote:

---

Also an interesting point in this topic was that our hardware becomes better and better and at some day we are no longer forced to use fast programming languages.

---

Slow software can make even the fastest hardware crawl. So if the software becomes better and better or at least stays in its current state and the hardware gets better then yes this is true. But if the software gets worse and the hardware gets better you still have a fundamental problem. I don't believe that hardware can solve all of our woes or ever give us a good excuse to be ignorant programmers. You can still write code today that will bring the CPU to its knees even with the amazing speeds we have. You can still write graphics code that will send the most recent top notch video card right to the mat and maybe even out of the ring. The language of choice has something to do with overall performance but what affects it more is the use of that language. So if you get easier languages it may also be that those languages are equally as easy to misuse. I guess you could argue that the easier the language the harder it is to abuse and misuse. However I'm of the mindset that even if you get smarter languages, easier languages, etc, you will just get a new brand of idiot who will figure out how to use them incorrectly.

Quote:

---

Never saw a good GUI that wasn't hard to create, no matter the language. I despise GUI programming.

---

Even after coding GUIs in C# I must agree with this statement wholeheartedly. GUI programming just stinks.