Programming 10 years from now

This topic is 4977 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I was just thinking. In 10 years are we going to still be using C/C++? Or will we have moved on to higher level languages such as C# or Java or D. Or will we even be using some new language such as ... Z++, or (insert cool sounding name here)? Will we be using Visual Studio? Will it still be a desktop app? Or will we be able to open it up from a browser, and code and compile from anywhere? Will Gaming companies still use assembly, or will computer processor speed and ram be sufficient for them to use higher level functions. Will we be able to have people simultaneously program the same file? Will we have new standard libraries, such as high level mathematics, AI, English, French, Spanish, etc? Just want your comments on this. Thanks - Sagar Indurkhya

Share on other sites
C/C++ will always exist, at least for hardware interfacing and suchlike, and open-source die-hards (hell, most OSS programs are still old-fashioned C). After all, what do you write the C# interpreter in?

C# might be temporary. Something will come along and take its place in 10 years.

Share on other sites
Z/Z++

LOL.

Probally like baby language

Share on other sites
I personally see myself still coding in Python using emacs, on a huge flatscreen combination monitor tv; still getting distracted by GDNet. Maybe I'd decide to take a walk, in which case I would transfer a copy of what I might be working on over to my computer-watch dealy. I can see wireless internet hotspots becoming the norm--even in the country. Could anybody tell what OS I would be using? That's right, I'd still probably be using Gentoo Linux, or, I might be using FreeBSD or Slackware Linux.
That's pretty much what I think I'll be coding with in 10 years.
Quote:
 After all, what do you write the C# interpreter in?

After you write the initial interpreter in some other language you can bootstrap and write the next C# interpreter in C#.

Share on other sites
for the record - c++ is a higher level language, the same as java. sorry, i'm picky about such things. anyway,
Quote:
 Will we be using Visual Studio?

lets hope not, thats not a pretty picture to contempulate - the winapi in 10 years.
Quote:
 Will Gaming companies still use assembly, or will computer processor speed and ram be sufficient for them to use higher level functions.

i'm confused - i thought that on some level you have to use assembly, otherwise the computer won't understand "higher level" functions. don't you have to convert to machine code ?

Share on other sites
[skip if you dont want to be brainwashed]
we will have intelligent programms that code stuff for us, you will have so many developers (every single computer user) and so many mmorpg's that noone will ever again play with another human player. The internet will also contain more porn, computer generated porn in a quality you cant say if it is real or not, this will fill 90% of the internet and 99% of a normal users hd. The hd itself will be an interface connected to your brain that uses your nerve system to store the unbelievable huge ammount of 1zillion petabyte... you will also need to carry a car battery with you, connected to your brain, to prevent datalose...
but hey, thats only what will be in 10 years, in 20 years all humans will be enslaved in one gigantic donut machine, controlled by the biggest moronic AI ever made...
[/skip if you dont want to be brainwashed]

me checks if this is the lounge... hmm no ok, here is what i really think:
we will still use c++, java, c#, the computers will be slightly faster but thats it, stuff like coding simultaneusly a file is already possible (i think emacs has it) but no one is and will use it, because its not fun waiting for another pal to finish his stuff just to let the compiler check your errors and stuff like this...

T2k

Share on other sites
Quote:
 Original post by Anonymous Posterfor the record - c++ is a higher level language, the same as java. sorry, i'm picky about such things.

It's a higher level language, but not as high as C# or Java. Mainly because of the garbage collection, etc. that those two do.

Quote:

anyway,
Quote:
 Will we be using Visual Studio?

lets hope not, thats not a pretty picture to contempulate - the winapi in 10 years.

Visual Studio has nothing to do with the Win32 API, and last I checked, the most recent Visual Studuio (VC++ Express and such) doesn't even include the windows headers by default.

Share on other sites
Quote:
 Original post by PxtlC/C++ will always exist, at least for hardware interfacing and suchlike, and open-source die-hards (hell, most OSS programs are still old-fashioned C). After all, what do you write the C# interpreter in?C# might be temporary. Something will come along and take its place in 10 years.

In something else? Bootstrap with another language.

Share on other sites
Quote:
Original post by Promit
Quote:
 Original post by Anonymous Posterfor the record - c++ is a higher level language, the same as java. sorry, i'm picky about such things.

It's a higher level language, but not as high as C# or Java. Mainly because of the garbage collection, etc. that those two do.

Does that mean LISP is a higher level language than C++ because it has garbage collection?

Personally I would consider something like Visual Basic to be a "higher level" language because of the fact that it is even more abstract and even farther from implementation details than C# or Java. The whole reason C, etc were "high level languages" is because it abstracts the hardware details out of the language. Java/C# do this in a sense by removing pointers, but I think Visual Basic is even higher level because it abstracts even more "low-level" functionality out of the language.

Keep in mind that going "up" in height in language is a tradeoff between control over the hardware and ease of programming.

Personally, I prefer C++ to the above, and VB code makes me cringe--which is to say that just because a language is higher level doesn't mean it's better.

Each language has its strengths and weaknesses, one language isn't going to completely abolish the other unless it can do the same exact thing the other one does, plus some additional features that don't get in the way.

What I think you might see in 10 years is more defined "realms" for languages, and a specialization of languages. We're already kind of seeing this, where certain languages are preferred for certain circumstances. For example, in areas where hardware independence is important, Java is being used.

that's my 2 cents...

Share on other sites
In response to what we will use in 10 years, you can read an interesting article written by Paul Graham called The Hundred-Year Language

Share on other sites
Quote:
 Original post by PxtlC/C++ will always exist, at least for hardware interfacing and suchlike, and open-source die-hards (hell, most OSS programs are still old-fashioned C). After all, what do you write the C# interpreter in?C# might be temporary. Something will come along and take its place in 10 years.

Err... the C# interpreter? WTF are you talking about? C#'s compiler can be written in C#, the JITter can be written in C#. The compiler produces MSIL code. The MSIL code is then JIT compiled to native machine code when the program is run. There is no interpreter.

Share on other sites
Sorry, I meant the JIT compiler. I doubt the whole damn thing is assembler. How could the JIT compiler be written in C#? Its the thing that runs the C#. It would have to run itself. There has to be some raw machine code on the computer, and that's made with C++. C# is for making MSIL, C++ is for making machine code. So, C++ is used to JIT the MSIL.

The JIT runtime can't run itself. Just like the Java VM and JIT compiler isn't written in Java - they run Java. Yes, the bytecode compiler itself could be Java, just like the MSIL compiler could be C#, or hell, vice versa if you so felt - but underneat there must be something that converts it into machine code, and that thing would have to be stored in machine code form, as it can't run itself without itself pre-existing.

Chicken-egg problem.

Share on other sites
10 years from now, the Sentient.Machines™ will rule teh world!

Now, joking aside, Probably the biggest thing that will be happening in the next 10 years(and I'm surprised no one has mentioned this) is that 64 bit computers will become mainstream. Programmers will start getting used to using huge datasets that consume the massive new ammounts of ram available.

The hardware is advancing faster than the software. I think some of those things you are predicting like the natural language libs are more like 20 years away than 10.

Share on other sites
Quote:
 Original post by PxtlSorry, I meant the JIT compiler. I doubt the whole damn thing is assembler. How could the JIT compiler be written in C#? Its the thing that runs the C#. It would have to run itself. There has to be some raw machine code on the computer, and that's made with C++. C# is for making MSIL, C++ is for making machine code. So, C++ is used to JIT the MSIL.The JIT runtime can't run itself. Just like the Java VM and JIT compiler isn't written in Java - they run Java. Yes, the bytecode compiler itself could be Java, just like the MSIL compiler could be C#, or hell, vice versa if you so felt - but underneat there must be something that converts it into machine code, and that thing would have to be stored in machine code form, as it can't run itself without itself pre-existing.Chicken-egg problem.

Let me ask you, why couldn't they write the initial version in Ada or Lisp or Befunge or whatever?

Also, Squeak (the Smalltalk implementation) is written in... Smalltalk. That's right, they used a basic language called Slang (which is a very minimal version of Smalltalk) to build larger and larger chunks. They never coded a single line of C themselves (they have a program to generate VMs for new architectures)

Share on other sites
you're right, the interpreter can't be distributed as interpreted code, it needs to exist as machine code.

ANYWAY, 10 years from now.. well, the direction in CS right now is moving away from performance-intensive stuff, and towards languages with higher security & stability. Like garbage collection, you give up some performance to have garbage collection, but it makes it really difficult to have memory leaks. I think we'll come up with several other inventions that make it harder for the coder to fuck up.

One such invention that might be nice would be to have a built-in way to break out of infinite loops, that might look like this:

while(keepgoing){  // blah blah blah, somewhere in this code, 'keepgoing' should get set to false}ifstuck{  return}

or maybe:
while(keepgoing)  throws InfiniteLoopException{ // ...}

and if the loop was executed some ridiculous number of times, like 10 million, then it would do something to break out. Maybe you wouldn't even have to say "throws InfiniteLoopException", and it would automatically throw it. Of course this would obviously cause problems if you really did want to loop 10 million times.

Another thing that I think will be introduced in the near future is automatic optimization. As you execute the app, the compiler will attempt different optimization algorithms, and based on the actual performance, it'll pick the best result.

Like, there are lots of different kinds of containers, there are linked lists, arrays, etc. It would be cool if the coder could just say that he wants a "container" of some kind of object, without saying how it should be implemented. Then when the program is run, the compiler would monitor the usage pattern of that container, and it would pick whatever storage type would give the best performance.

Share on other sites
It is indeed a classic chicken-egg problem; but it can be solved as follows : Suppose you build a crude C# compiler in C++, or assembly, or FORTRAN, or whatever you feel like working in. This first iteration is just sharp enough that it lets C# define its own compiler. Now you can build a better C# compiler in C#. Iterate as needed.

Of course, you had best hope that the world population of computers doesn't suddenly crash, blasting all the binaries of your fiftieth-generation C# compiler.

Share on other sites
The Sun Java compiler is written in Java, as is the IBM Java Virtual Machine. Once you have an intial compiler or (possibly JIT) VM, you can use it to write out machine code directly, and there's no need to build a "stack" of more and more complex versions of the language.

Share on other sites
Quote:
 [Of course, you had best hope that the world population of computers doesn't suddenly crash, blasting all the binaries of your fiftieth-generation C# compiler.
If Microsoft has their way, the only computer that would have to crash would be theirs, because you'd just be renting the C# compiler from them.

Quote:
 Like, there are lots of different kinds of containers, there are linked lists, arrays, etc. It would be cool if the coder could just say that he wants a "container" of some kind of object, without saying how it should be implemented. Then when the program is run, the compiler would monitor the usage pattern of that container, and it would pick whatever storage type would give the best performance.
That is why it is common to offer multiple interfaces to data (i.e. iterators). Programmers should know at the time they write the code HOW they will be accessing the data, and be able to choose the most efficient interface. I don't see how the overhead of having an uber-JIT compiler/runtime system would make things more efficient.

Share on other sites
Yeah...I wouldn't appreciate a system simply spitting out random containers at me. That'd be kinda dumb.

Share on other sites
i know this is probably pretty dumb, but say in 10 years some one created a spider AI to search the web for pr0n would'nt it eventuly figure out that it could enslave humans to create pr0n? that sounds like the start of a cheesy pr0n movie.

Share on other sites
10 years from now C++ will go the way of assembly. We'll have programming enviroments that go strait from UML (or a descendant of...) to compiled code with with library plug-ins that easily install.
Or not.

Share on other sites
we will be using new version of C++ , there will be some other languages too
And we will have
\brackets/ and /brackets\ and maybe even non-ascii brackets (in addition to today' <unparseable brackets> )it will be extremely hard to parse... compilers will work on same speed as today,or slower.
Or maybe not.

Share on other sites
I think that in 10 years time, programming will be as diverse as ever.

C++ will still exist, C# will still exist (after they've added another trillion features to it, at the rate they're going...), Java will still exist (As they are now adding features to it after a 9-year almost feature freeze - not that that was an especially bad thing)

What will improve a lot is the tools, which have continously got better historically.

People's niggles about C++ being lame will go away if you use the right tools, when your IDE points out potential problems before you finish typing the statement. It's starting now, but what Eclipse does now for Java, will be done by all IDEs for C++ within 3-4 years, and extended a lot by 10 years time.

I don't think Microsoft are going to go away any time soon (Unless Bush gets thrown out of office and the US gets a reasonable government, but that's not likely as he'll just rig another election). They will continue to try to persuade programmers not to program with increasingly complex "RAD" tools to try to tempt the newbies. Visual basic (.NET) will unfortunately still exist :)

I've no idea what the X-Box 5 will look like, or the Playstation 7, but I think they will exist (although they might of course be marketed under different names)

Mark

Share on other sites
For an idea, you might try looking *back* ten years...