Slashdot Mirror

I think digitalmars D is the next big language.

See it here http://www.digitalmars.com/d/

I believe that Symantec's C++ compiler is based on the one developed by Zortech (known to people who programmed C in the age of DOS). Presently this is Digital Mars and one of their FAQ pages talks briefly about the compiler's heritage.

I once read in Dr. Dobb's Journal mentioning about Walter Bright acquiring back the rights of the Zortech's compiler after Symantec lost interest in its development.

I believe that Symantec's C++ compiler is based on the one developed by Zortech (known to people who programmed C in the age of DOS). Presently this is Digital Mars and one of their FAQ pages talks briefly about the compiler's heritage.

I once read in Dr. Dobb's Journal mentioning about Walter Bright acquiring back the rights of the Zortech's compiler after Symantec lost interest in its development.

When C++ is finally a thing of the past, to be replaced by something like D. I consider myself a rather adept programmer, proficient in both C and Java. Recently I've been learning C++ from a book many consider to be C++'s "Bible": C++ Primer 4th Edition by Lippman, Lajoie and Moo. I have discovered that C++ is thoroughly flawed conceptually, and that it is impossible to actually make a good book about it due to all the nuances.

Coming from a Java background, I find it difficult to understand the reason for all the const parameters, how C++ uses iterators and how *iter is something completely different from what I'm used to it meaning in C. You can somehow pass C-strings to C++ string parameters and they will be automatically converted. Initialization lists are horrible, a function can be declared virtual and const (seemingly pointless "features" when in Java all methods are virtual). Multiple-inheritance, the fact that you store the class interface in a separate file to reimplement it using disgusting syntax in another file: Class::method_name(int face = 3) const { /* blech! */ }. No garbage collection makes programming a pain and error-prone. I/O streams use variables instead of exceptions for error handling. Because there's no reference counting mechanism (as in Obj-C) and no garbage collection, one's often forced to copy the contents of parameters to ensure they aren't deallocated prematurely.

Java has the right idea, but unfortunately it's too slow. That's where D steps in and tries to resolve all the issues. C++ is too bloated, it has too many nuances, too many unnecessary "features", and there is far too much ambiguity in the code itself. C++ allows things that shouldn't be allowed. Operator overloading (while some may claim to be useful), is a horribly confusing feature that hides the actual action deep within the class implementation, forcing one to constantly jump back and forth from reference manual to code. Don't get me started on C++'s horrible class naming-scheme. Why do all standard library classes have lowercase first letters? Why is it "string" instead of "String" as it should be to differentiate it from primitives and object names?

- Posting anon. because there are too many hardcore C++ zealots out there.

Probably this : http://www.digitalmars.com/d/property.html which is incomparably more elegant than the C way.

I got tired of complaining about C++, and decided to do something about it. The result is the D programming language.

I think C++ wants to be a low level language that can also do high level constructs.

And I do think this is a great goal, a goal that not many languages are able to do well.
Actually I don't know of any other language that allows you to type raw assembler and at the same time use higher order functions like boost::bind (http://www.boost.org/libs/bind/bind.html).
(Please not that C# and D delegates don't have all the features of bind, that is binding any argument to a precomputed value, not just the first argument).

But while the low level programming in C++ is good, writing high level functionnality is still very complicated. Just have a look at the code at the previously mentionned boos::bind and you'll probably run away (http://cvs.sourceforge.net/viewcvs.py/boost/boost /boost/bind/mem_fn_template.hpp?rev=1.7&view=auto) .

After reading the article, I understand that they are willing to fix this issue, at least partially.

But there are many other issues that preclude it to be really "comfortable" to use as a high level language :

Some of them are old issues, already solved many years ago by a lot of languages like parent post said (introspection (compile-time and run-time), modules, lambdas...).

Some other issues are old but require some carefull thinking to integrate well with C++: multi-methods, garbage collection, mixing functional and imperative programming...

An finaly there are new needs arising like compile-time code generation, aspect-oriented programming, multi-process programming, interfaces (as in the Heron language or the boost interface library, not Java interfaces)...

Of all these features, very few will be added in C++0x.

Other C++-like languages do offer these features or a subset of them.
Here is a short list for reference :
D : http://www.digitalmars.com/d/index.html
Heron : http://www.heron-language.com/
Boo : http://boo.codehaus.org/Language+Features
Nice : http://nice.sourceforge.net/
etc.

But to my knowledge none of them has fully succedeed in offering both a good low and a good high level programming, while keeping the zero-overhead principle of C++ (that is: if you don't use a feature of the language, you don't pay for it).

Seeing this situation, I'm afraid we have only 2 options :
1- split programs into 2 parts: high level and low level, and use 2 different languages for these parts.
2- create a new language

Actually, this is already happening:
I see more and more programmers using high level languages like Python and doing some system or high performance routines in C (with Pyrex for example) and then glue them together.

The languages I mentionned before (D, Heron, etc) are an attempt at creating a successor of C++ but IMHO they are not mature enough and/or feature complete.

So... I forsee option 1 will become more and more comomon for years to come, until we hit option 2, because I think C++ will not be fixed.

it would do assembler, C, C++, and higher than C++ level

IMHO those four languages are better unified - that gives the programmer the most control.
Have you heard of the D language? It's not C or C++ precisely but is pretty close, has provision for using C APIs, has assembly, more function/object features and is easier to make more reliable code - see features kept and features dropped from C++:
D Programming overview

I personally have more hope in this alternative.

To me, D has surfaced to become what I always thought C++ should have been. I hope (and believe) that it will be giving C++ more competition in the comming years. It might not be ready for full production yet (due to lack of big supporters and libraries, mostly), but I have tried it out on several of my own projects, and I love it.

just use D.

http://www.digitalmars.com/d/

What parts do what should be clear from the names of function calls and variables, but whenever a function becomes longer than something really short, yes, it needs comments describing what happens where. If a function does something complicated, it's worth starting with a comment describing pre- and post conditions.

Now there is an excellent idea! It doesn't take a lot of effort - you should be able to come up with some basic constraints on inputs and outputs if you have any decent idea of what the function does - but it is very helpful documentation to anyone else, particularly for people who have to call the function (as it clerly delimits exactly what they need to provide, and exactly what they can expect to get back). Better yet, as long as you use a system that supports it you can get a whole lot of benefits in terms of automated checking and debugging of your code, saving you a lot of effort later.

Eiffel and D support pre and post conditions directly in the code (instead of in comments). Java has JML which is a syntax for writing pre and post conditions in comments, as well as some tools to do extra checking, add runtime checks to your code (or not) based on the conditions, write the conditions into JavaDoc properly, and automatically generate JUnit tests based on the conditions. If you program in Ada there's SPARK which supports pre and post conditions as comments as well as a range of other annotations, and provides extremely powerful tools to do extensive static checking and analysis and even generate automatically simplied proof obligations based on your annotations. If you program in Python there's PyContract which allows you to write pre and post conditions into docstrings and switch on or off runtime checking of those contracts. I expect there are plenty more, so hopefully other people can mention those.

Jedidiah.

Garbage collection does not equal poor performance. In some instances, it actually speeds things up--when done properly. Take, for example, the D Programming language. It's just as fast as C (faster in some cases) yet it has a garbage collector. The reason is that most programmers tend to not realize that the free() operation actually takes up a decent amount of CPU cycles, and when you're freeing a bunch of little things all over the place, the overhead tends to add up. With a well-designed garbage collector, however, memory is freed all in one big chunk in a single go, and thereby decreasing that overhead. The myth that garbage collection = poor performance is just that, a myth, and most likely started by people who associate Java's performance issues with garbage collection.

Perhaps. It isn't clear to me why one would necessarily want to write a "traditional" application (i.e. desktop style application) in a "managed" language. I've been a big Java fan, mainly from the standpoint of someone who came from C++ and could see that Java was much more productive. I even wanted to write high-performance code (and games) in Java. However, the numbers have never really been in Java's favor. Look at the benchmarks at the Great Computer Language Shootout. They're microbenchmarks, where Java should do quite well if it can really stand up to "traditional" languages in efficiency. The short story is, it doesn't. Further, I don't see the JVM/JIT ever catching up with a highly optimizing ahead-of-time compiler, especially in terms of memory efficiency.

In short, I'm planning on using Java for web-oriented programming, but for 'real' desktop apps it'll either be D or Dylan for me. Both are far more expressive, just as safe, just as productive (if not moreso) and both are significantly faster. Oh, one final point...both are available as FOSS.

C/C++ will only be used where bit-banging stuff is needed AND NO ONE will care about except a few grumpy old man...

Both will be around for a *long* time due to legacy code, but I agree for new development a more modern language is desirable. D and Dylan both fit the bill...Java really doesn't hit the same target. Also, both languages have language constructs like operator overloading that're more suitable for HPC/simulation/game programming, and feature very performant C calling interfaces.

This wouldn't be C++ anymore.

But there is a D frontend for GCC

http://digitalmars.com/d/

The D programming language is shaping up to be a nice alternative.

This is just a research OS written in C#.

No, it's written in Sing# which is an extension of Spec# which is an extension of C#. People really ought to pay more attention to Spec# - it's a nice extension of C# that allows for more formality if and when you require it. It's in the same class of language as SPARK which is an extension of Ada, JML which extends Java with specification semantics, BitC, Extended ML, HasCASL, and I guess to a lesser extent things like Eiffel and D.

Think of it this way: static types and type signatures for functions allow you to specify things about the software that the compiler can statically check and make sure there aren't any silly errors. The languages listed above (to varying degrees) allow for more exacting specification about the software, and hence you can (with the right tools) do far more comprehensive static checking and ensure various properties of the software. The difference is that, with most of these languages, the amount of specification is optional - you can be as exacting as you want where you need it, and not bother where you don't. It's like a dynamically typed language that lets you declare and use static types (and check them)just for those areas of code where it matters (except you start with static types and can provide more exacting specification where it matters). It's well worth checking out.

Jedidiah.

I am curious as to why you might think that Python and Ruby aren't suitable for a big business application though. They may be uncommon in enterprise environments, but that doesn't necessarily mean that they aren't suitable for the job.

Imagine if you took everything you knew about C, C++ and Java and fixed it. What would you have? You would have 'D'. A completely underrated language that follows on in the tradition of C/C++ non-vendor specific languages.

If you want to work like a sharecropper, keep expressing your algorithms and developing your projects in Microsoft proprietary language. If you want portability and something better than C++, check out D here.

For better or worse. Java will never have direct memory control, period. It's the very antithesis of everything that Java stands for. You will have to do with JNI calls to C/C++ code.

I'd love to help you out, but you haven't actually told us what you want improved in C++. Not garbage collection, so D (http://www.digitalmars.com/d/) is probably not interesting to you.

But seriously, I find modern C++ a pretty amazing language, and you can get enormous benefits from libraries such as boost (http://www.boost.org/

There are a LOT of things better in D than C++. D is far better language (not library) enhancement over C++ than Java/C#. Take a look at language comparison at http://www.digitalmars.com/d/index.html I do not use D however. I don't do much of systems programming and I fancy IDEs but language wise, D is perhaps the best imperative, native compiling language out there at the moment.

D is a refactoring of C++ to make it easier, more powerful, and more robust to use. -Walter

Have you ever tried D? There is a better wheel.

http://www.digitalmars.com/d

C# is what C++ always wanted to be. It was written by people who had learned from the mistakes of C++ and Java. It's not perfect, but it's better than either of the others for the majority of desktop and server applications. Anyone who tells you otherwise is a Microsoft hater, or isn't working in that problem realm.

You might also want to have a look at the D programming language, which is a ruthlessly pragmatic alternative.

I think you'd better ask these question on the D forum.

http://www.digitalmars.com/d/

ask, and ye shall receive.

And when you're done with that you could move on to E and F....

What you really need is a new language.

Before modding me down, think about it. Any programming language is about solving problems, and problems you solve today are different from the ones someone had back in the days of C creation. Moreover, the ways you deal with programming changed as well. IT industry needs new languages, including low-level and compiled ones.

your await has completed!

Wait no more

Symantec C++ was an amazing compiler and development environment for the Mac, DOS and Windows during the 1990s. Now it lives on as DMC++ from http://www.digitalmars.com/ .

It was one of the products from Symantec's golden age, when they provided useful services and software. I remember those days fondly: one could even be proud to say he or she was using Symantec software. These days the Symantec name has become a joke, associated with half assed "security" software that often fails miserably. How things change in a short decade!

C++ is old school yes, but if you don't want to rely on a VM and want object oriented programming with templates, it is the only way to go.

Unless, of course, you are adventerous and willing to give the D programming language a shot.

D is the answer. It's meant to take the good ideas from C++, Java, and C# and make a modernized C-type language which is suitable for systems programming and (relatively) easy to implement.

There's a a GCC frontend) in the works as well. In general, it seems like once this language gets a bit more mindshare it will really take off.

(D is currently #1 on the Great Computer Language Shootout- and while it does help a little that it's the only one with all the tests implemented, its ranking is due to very impressive performance.)

D is the answer. It's meant to take the good ideas from C++, Java, and C# and make a modernized C-type language which is suitable for systems programming and (relatively) easy to implement.

There's a a GCC frontend) in the works as well. In general, it seems like once this language gets a bit more mindshare it will really take off.

(D is currently #1 on the Great Computer Language Shootout- and while it does help a little that it's the only one with all the tests implemented, its ranking is due to very impressive performance.)

After reading about the language D http://www.digitalmars.com/d/index.html I'm thinking C++ really is hosed.

takes the features of C++, and reengineers them so that one has the power and efficiency of C++, but with fast compilation, true modules, automatic memory management, cleaned up syntax, etc. http://www.digitalmars.com/d/

For performance of D, see http://shootout.alioth.debian.org/great/benchmark. php?test=all&lang=all&sort=fullcpu

On the D programing newsgroup we have been talking
about implementing a vectorization syntax, so
we can have portable vector code which
approach the speed of hand coded vectorization.

Here is something from the list.

What is a vectorized expression? Basically, loops that does not specify any
order of execution. If there is no order specified, of course the compiler
can choose any one that is efficient or maybe even distribute the code and
execute it in parallel.

Here is some examples.

Adding a scalar to a vector.
[i in 0..l](a[i]+=0.5)

Finding size of a vector.
size=sqrt(sum([i in 0..l](a[i]*a[i])));

Finding dot-product;
dot=sum([i in 0..l](a[i]*b[i]));

Matrix vector multiplication.
[i in 0..l](r[i]=sum([j in 0..m](a[i,j]*v[j])));

Calculating the trace of a matrix
res=sum([i in 0..l](a[i,i]));

Taylor expansion on every element in a vector
[i in 0..l](r[i]=sum([j in 0..m](a[j]*pow(v[i],j))));

Calculating Fourier series.
f=sum([j in 0..m](a[j]*cos(j*pi*x/2)+b[j]*sin(j*pi*x/2)))+c;

Calculating (A+I)*v using the Kronecker delta-tensor : delta(i,j)={i=j ? 1 : 0}
[i in 0..l](r[i]=sum([j in 0..m]((a[i,j]+delta(i,j))*v[j])));

Calculating cross product of two 3d vectors using the
antisymmetric tensor/Permutation Tensor/Levi-Civita tensor
[i in 0..3](r[i]=sum([j in 0..3,k in 0..3](anti(i,j,k)*a[i]*b[k])));

Calculating determinant of a 4x4 matrix using the antisymmetric tensor
det=sum([i in 0..4,j in 0..4,k in 0..4,l in 0..4]
(anti(i,j,k,l)*a[0,i]*a[1,j]*a[2,k]*a[3,l]) );

1. The power of assembler.
2. The speed to at least match C.
3. Greater grammatical simplicity than C.
4. Better memory management than C.
5. Much better security than C or C++.

Well, outside of Microsoft the evolution of C has proceeded in a different way, namely to D.

In the begining (1954, according to my O'Reilly poster) was Cobol.

Check yer poster, it says Fortran in 1954 (which actually seems to have come from A-O), COBOL "flowed" from B-O and Flow-Matic.
And I have to agree with the poster that Postscript emerged fairly directly from Forth. What is an amazing language (it is interesting to see that relatively many languages are basically one person's vision - Forth, Pascal, Perl, Ruby, Python, APL, D, SmallTalk, C (two people), SNOBOL (3 people), etc

More here

If people want pragmatic design of languages, I like the author of D he designed and wrote C/C++ compilers and realizes that programmers often just want to get things done w/out the language getting in the way.

Another thing to contemplate is how few organizations the most useful languages emerged from - Bell Labs, IBM, the US Military, US Universities...

Well, supposedly C code will compile straight in Cyclone, unless it's not typesafe. Whatever that means. So whereas Eiffel means you have to learn a new language, Cyclone means you only have to learn the new markup characters. NOTE! I only sat through the presentation on this once last year, it was the first thing that sprang (?) to mind, so I'm probably wrong.

Have you looked at D? Supposedly it's like C++ but w/ Design by Contract? (It also has an as ridiculous-to-google-for name as .NET...)

Heron seems to be aiming at the same market as the D programming language, but IMHO Heron is too much C++-like with all its ugliness.

D is a lot more like Java/C#, but compiled to native code and is low-level enough for it to be used for things like where only C and C++ are feasable now (low-level libraries, toolkits, even kernel drivers).. And besides, there is already a (beta) D Frontend for GCC.

With all the positive attention that D has had recently I find it unlikely that Heron will be chosen over D by anyone, but only time will tell... And the competition is good for both languages. :)

I agree with the sentiment, but not the conclusion.

There are still times when we need the low-level, fine granularity of something like C. On those occasions, we also frequently need some high-level features as well, which is where C++ came from.

Unfortunately, the design of C++ has meandered around the design state space so much that many of us consider it to have become quite a mess. Whole *series* of books have been written on the vast number of pitfalls of working in C++.

Dropping back to plain C to get some simplicity and clarity isn't very attractive, for ordinary application work, though. It lacks too many useful things.

Instead, we are told to "use a subset of C++" in some special way that changes over time. That's supposed to bring back the simplicity without sacrificing power. So now every developer uses a different subset a different way, meaning all "good C++ developers" need to have an encyclopedic knowledge of arcane trivia to work with other developers. Where did the simplicity go?

I think the best approach is a language that is as low level and simple as C, but has most of the most popular high-level features of C++ and even many Python-like conveniences, and that's the "D" programming language.

It's still in beta, but it has progressed far enough and is out in the open enough that it looks as though it will become a reality, unlike Paul Graham's Arc.

Sticking as close to C as they have means that it should be relatively easy to slip it into the massive existing infrastructure of libraries and OS calls that exist for C and C++.

It's like C with many of the conveniences of Python built-in but overridable.

It's not as easy to work in as Python, but when you need to use either C or C++, you might be able to get away with using D. Despite the many Pythonesque features, it's still so close to C that a D compiler can statically link compiled D with compiled C into a standalone executable.

I hope to be able to switch from my current "subset of C++" to using D in the not too distant future.

def foo(cls):
pass
foo = synchronized(lock)(foo)
foo = classmethod(foo)

@classmethod
@synchronized(lock)
def foo(cls):
pass

The "isnot" operator was proposed for the D Programming Language as a replacement for the !== operator already in use in D. The !== operator determines if two references are at the same address or not. Both the "isnot" reference and the !== operator well predate the patent application.
isnot proposal
earlier D specification

Welcome to acronym-palooza? Anybody heard of D Programming Language? It's around since 1999 and has been covered here on ./ Some research (read as "Query") if that name is taken already you can expect from some database guys?!

1. Generics: They couldn't make it worse here. You cannot use reflection effectively because the type parameter information is not stored in the compiled class file. There are many ways to circumvent the type "safety" provided by the templates, especially if you are mixing code from older versions. This is one of the worse implementations of generics I have seen. I hate Microsoft with a vengeance, but they are implementing generics in a sensible way in the next version of C#. See this for an interesting discussion comparing Java, C# and C++ generics.
   
   With java generics you can compile this:

   class MyClass<T> {
   T[] anArrayOfT()
   {
   Object[] arr = new Object[10];
   //add whatever you want to arr.
   return (T[]) arr;
   }
   }

   Of course, you cannot assign the return value to a T[] because it is really an Object[], so, where is the type safety? All this is without mentioning that Java generics don't provide any performance benefit (which you would naively expect because you believe that you do not have to cast anymore).
   Java generics are just compiler sugar for automatically generating casts.
2. Autoboxing: this feature removes clarity from the language. You do not know what is really going on. And you never know when you are going to be surprised.
3. Enums: They coud have made a very good typesafe implementation using internal integer values orsomething simple like that. Instead they make them as clases. At first they look like they work fine, but if you start workking in contexts where several classloaders are used (e.g. application servers) then the enum is going to be loaded in both classloaders and comparison of apparently equal values will fail.
4. Annotations: I really don't see the point of this. It's just more complexity. It seems it is only useful to help some complicated and probably not very well desinged tools.
5. New for: This simply makes the code harder to read. The original, C like "for" construct was very clear and was very understandable both for arrays and collections. Now in order to use a fundamental construct (a "for") your code has to implement some new interfaces. This is pure crap.
6. Static imports and variable length parameter lists: I think these are well done. I have nothing against these.
7. It looks like they wanted to add novelty features, but in order to avoid make the appropriate JVM specification changes, they implemented everything as compiler sugar. It just doesn't work.
8. 
   
   Maybe the fact that Java is now managed by a comittee instead of a few people who do know about language/compiler design has something to do with this.
   
   Maybe they are just trying to make it "easier"for those who don't know how to program. Again, it doesn't work.
   
   Something more or less like this happened when C++ was standarized. They came up with an overly complicated monster language, but at least the specification was not a broken one, just complex.
   
   They could have added pass of parameters by reference (at least for primitives), which would have been very useful in real world situations. But instead they decided to add a ton of crap.
   
   Java is doomed now. Too bad it was my favorite language. Now I have to look for another language. Maybe D?

The most sweetest of spots has got to be D! http://www.digitalmars.com/d/