Home » forums » LtU Forum

How to make a *truly* better alternative to C++

Here, care to discuss.

By snk_kid at 2006-08-13 16:40 | LtU Forum | previous forum topic | next forum topic | other blogs | 7336 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Is C++ relevant any more?

I truly doubt C++ is of any relevance in the programming world. Of course there is a percentage of software still done in C++, but with the release of even faster CPUs and memory systems, the importance of being close to the metal will fade away. Most business apps are coded in C#, VB and Java, most drivers in plain C, a good percentange of soft-real time software is quickly migrating to Java (defense apps, my domain), and hard real-time apps in Ada.

But, let's suppose, for the sake of discussion, that the world needs a compiled close-to-the-metal programming language with high-level constructs. But there are so many things that could be corrected in C++, I don't even know where to start:

1) no headers. Use import files.
2) standardize the ABI where it should be standard.
3) have garbage collection.
4) simplify syntax.
5) put type inference, first-class functions, closures.

The above is enough to turn C++ to another language already...so, if we are to make a new language, why not forget about C++ altogether and make something fresh, something innovative, which incorporates the latest developments of the PL world?

By Achilleas Margaritis at Mon, 2006-08-14 15:01 | login or register to post comments

I have mixed feelings about

I have mixed feelings about that. C++ gives you sheer power, including the one inherited from C that lets you map structs onto areas in memory.

But, let's suppose, for the sake of discussion, that the world needs a compiled close-to-the-metal programming language with high-level constructs

This is not a "let's suppose", this is a reality. A hell of a lot of software is written for microcontrollers where you need to address memory mapped GPIO and the like. C++ is far from dead in these application domains.
Granted, ADA would do nicely, but it shares the same problem as C++, that I would add as item #6 in your list:
It takes very long to become proficient in C++, and as a result, there is not much talent out there.

When programming in the large ("enterprise systems") in C++, you have to solve the problem at hand plus the problems inherent to C++ that you mentioned.

The solution probably lies in a language with the properties you described with no-fuss linkage to C or C++, a language that is not a showcase of concepts but designed for a broad application range.
I am no language designer. My current favorites are ADA and OCaml.

By Serge Zloto at Mon, 2006-08-14 15:30 | login or register to post comments

For some domains (low-level

For some domains (low-level programming like os-kernels, drivers or certain embedded apps) it's still neccessary to manage memory by hand and don't use a general memory manager with gc. Any replacement language must have the abilitiy to do manual memory management.

Same for typing: Too strict typing won't work for a low-level language, because sometimes you have to type data depending on the runtime context.

Maybe C/C++ are enough for all time to solve those (fewer and fewer) low-level problems, but I think too that it's a good idea to clean up those languages.

But maybe the Microsofts way to put unsecure features (like Pointers) into otherwise secure languages like C# is the way to go? What about for example a 'bare-metal' ocaml with optional 'by-hand' memory-management and unchecked type-casts? A programmer could use safe language-features for most of his program then and use unsecure features only where needed without getting impedance mismatch when interfacing the 'app' and the 'low-level' part of the program.

By Karsten Wagner at Mon, 2006-08-14 16:30 | login or register to post comments

[Admin Warning]

Discussions on topics of this type often fail to meet the standards of discussion we strive for. Please check the policies document and try to keep the discussion here focused, substantiated, and not a collection of personal likes and dislikes.

By Ehud Lamm at Mon, 2006-08-14 15:57 | login or register to post comments