I was just sitting here and i was looking at my book collection and i realized that there aren't as many low level languages as high level (probably for obvious reasons) and there are alot more interpreted languages now then compiled. I think besides c/c++/asm i have no other compiled languages. What i mean is theres Java, Python, Perl, C# which are technically interpreted. And also i was looking at the new language or whatever it is for windows long horn looks like html for windows.

So my question is do you think programming will all become interpreted and require run time environments for each language? And that languages like c++ will die out eventually? Or is there maybe a new type of language that we haven't seen that will pop up soon?

Example: i can write a program in c++ for windows and it will run on most windows machines but if i write it in java i have to install a run time environment(same for python, c# etc)

Just curious

Please note that this post opinion, though hopefully substantiated opinion. Please do not attack me =).

I think the shift you have noticed is inline with the realisation of efficient ( in relative terms ) sandboxing. However, requiring specific runtime environments is irritating for many reasons. It is not trivial, but can be done to transfer these languages to native code -- see `gcj', which looks like a promising project. I think the real determinant of this movement is the advances made by the different levels of environment control. For example, as Operating System sandboxing abilities ( also look at things like UML ) become better, will it become less worthwhile performing these tasks inside their own protected virtual environment?

I do not think that C/C++ will die out for a long time, although it will play a diminuished role. There are many low-level tasks that C/C++ are ideal for, and I think they will continue to enjoy success in kernel development and initial development on new platforms ( especially in the embedded market ). Also, as somebody stated in another thread about COBOL, there is far too much legacy C code for it to just disappear.

With advances in software engineering as they are, I do not doubt that there may be something new just around the corner. This is the reason I would not stake everything on any one language ( or group of languages ) becoming the next thing or another language ( or group of languages ) suddenly being considered pointless.

True, good points. Do you think though that the c's will pretty much stay on top as far as kernel development? And why haven't companies like Sun released a version of native code compilable java and maybe added some extra features(support for inline assembly, better memory access) in order to let people use it for kernel development. Don't get me wrong I love c but im just wondering why it seems to be the only language out there for that kind of stuff besides asm/ml.

[1] A kernel is a truly huge project ( we are talking hundreds of years of programming altogether, to be competitive -- and that assumes that you are following a predetermined method for kernel design ), it will be a long time before a kernel written from scratch appears. As far as I know, there have been numerous attempts to start writing kernels in languages such as Perl and Java, and all the projects have died -- this is probably due to realisation of the commitment, not the language choice especially, the point was that alternatives are not arriving fast.

[2] This is where I was leading with my answer to section 1. Eventually a kernel ( unless run inside another kernel =/, as an alternative ) will need to use assembly, no two ways about it. C has one of the strongest relationships to the machine code it outputs, and thus can work very well integrated with assembly -- this is not to say it is impossible from other languages. To directly answer the first part of your question, Sun will not do that as it directly contradicts one of the aims of Java -- they would have to provide some higher-level pseudo-assembly and translate it for you, or something similar ( but, this would probably lead to less optimal assembly ).

[3] It is because the schools of thought that have spawned different languages have different ideas relating to abstraction. For example, it does not tie in with Java that you program specifically for one real architecture, you program for a fake common architecture, that is then is translated by people having programmed for the real architecture. Whether abstracting away the machine is good or bad is largely a matter of opinion, though there are factual arguments for and against it.

Compiled languages wont die out, but with how easy interpreted ones are more people will you them. But you cant program a gride network with just an interpreter. there will always be a need for compiled languages for such things as OS's, research into AI, and graphics. So they wont die just fade into the background. Of course they could find a new way to code that doesnt require compiling or interpreting, who realy know. absurd? well thats what they thought about our technology today 60 years ago.

Interpreted languages have positives:
- one code works in different environments,
- small change doesn't require to compile the whole program,
- it's usually easier to write programs in such a language (more lines to do the same).

But:
efficiency - if you're writing a program that will run under very high load and 'buy better hardware' is not the right answer, the code should be compiled
flexibility - interpreted language doesn't give you full control over your code
existing apps - you can rewrite a small app in another language, but think about something as large as KDE or GNOME

Compiled languages won't die out. They're needed. The same with scripting ones.
I'm more concerned about those 'click click' languages (environments). They're easy to use, but usually produce ugly, slow code.

0.0 Wow! Bravo Mara! Short yet too the point, and very true.

I think it is all about the right tool for the job, and they each (Interpreted and Compiled) have their place. One of the biggest tradeoffs is the ability to catch errors at compile time. generally speaking writing code in a weakly typed or dynamicly typed interpreted language goes quicker because you don't have to worry about types and the development cycle also tends to be quicker because there is no compilation step, you may even gain the ability to make modifications to objects @ runtime, however you may pay very dearly for these benifits when it comes to debugging. Compilers catch errors that interpreters won't until you actually load the code and try an execute it. This becomes much more of an issue when the size of the software project increases.

This is a bit off topic but, I believe that this is one of the reasons that unit and regression testing has become so popular, when unit testing becomes part of the build cycle it acts like an extension of your compiler, by (hopefully) catching the mistakes in code logic.

xx

mistaken post

I don't think C/C++ will leave us for a long time. It good for what its for, low-level programming; the reason it is fast is not solely because of the language, but because it converted (compiled) into machine code. GCC, MS compilers do a very good job at this. Another advantage of compiling it to machine code is that you can take advantage of the processors optimizations, e.g. 3DNow! - Hyperthreading - MMX - SSE2 - etc.

It wouldn't be impossible for people to create a kernel in Java or C# if you could compile it natively. With Java you can, but compiling Java to machine code kindof defeats the purpose of Java, same thing with C#. Both were designed to run on all platforms with a Runtime installed. When you compile a C# (or any .NET language for that matter) or Java program, it converts the code into its own special 'machine code.' So that it can run on any platform without having to recompile the source [for its specific processor]. And thats what the JVM or CLI does, simply converts its 'code' to what the machine can understand.

C/C++ has the advantage of not needing a runtime! And thats why you see Linux on a Mac!!! and other platforms But each have to be recompiled in order to run on that system

Just my

It's worth mentioning that with JIT compilation bytecode VMs for Java/C#/whatever can potentially be faster than traditional compiled languages. Also, there are a lot of new compiled languages (e.g. Haskell, O'Caml) so it's not the case that all the interesting new languages are interpreted.

Alex

So no one thinks that in a few years that programming languages might get simpler and more powerful? Or maybe in a few decades we wont even have programming languages anymore you'll just be able to tell the computer what you want it to do verbally and it will do it in a star trekish way. Not "computer, tea earl grey" but like make "make window, add button at one hundred one hundred with text 'push here'" It might sound kinda far fetched but hey anything is possible right?

the supply is generaly equal to the demand. if people demand simpler languages companies like Microsoft will pump them out like raw sewage. though i must say the voice command programming will be nice, but i'm hoping in 20 years there will be man/machine interfaces. no need to talk, just think

The thing is that natural language isn't actually very good at describing things precisely - that's why mathematicians use their own system of symbols, for example. Also it's very very difficult to get computers to interpret natural language. It will probably be several hundred years before that kind of technology is feasible.

Alex

you have a point with the first part but i disagree with the second in a matter of time. yes it is hard for computers to interpret natural language, but thats why we have interpreters and compilers. also there is software for the blind that allows them to talk to the computer and get it to do things <open window, open program, shutdown, etc> this type of technology can be applied to programming. you would have to make some adjustments and shortcuts so you wouldnt have to say "colon", "open bracket" all the time.

now my idea of man/machine interfaces, yeah that could take a while, a loooong while.