Slashdot Mirror

Eiffel is, or are you concerned about possible IP problems with the language spec per se?

take the best aspects of java, objective-c, eiffel and maybe some smalltalk like elements and roll them up into one language.

The D programming language looks somehow interesting...

Difficult? I think it's a no brainer. Java should not support macros.

Macros and various other types of pre-processing your code are one of the major reasons C/C++ needs to be replaced with a better syntax, like, say.... D.

I personally like programming in Java simply *because* of the lack of Macros. I hate the fact that Java requires a VM to run: I'd rather write native code, but I'd rather write in Java than C/C++ any day.

I'm a study in contrasts, however: I wouldn't mind operator overloading in Java. ;)

Looks like Java is trying hard to catch up with D.

is the true successor to C and C++. See digital mars.

In other words, C# is an inferior version of D

I work for a company that develops console games - and our codebase is shared across several platforms. Recognising that the article is questioning the use of C# in games (not .NET, Visual Studio .NET does C++ with no problems), C# is useless to us until a compiler is available on all of the platforms we want to develop games for. I don't see the mortal enemies of Microsoft on the console battlefield - Sony and Nintendo - supporting C# in the near future (if ever).

This is an area where something like the D language could do well, as it's a modern language free of Microsoft's stranglehold. :)

This is a idiosynchonism (is that even a word?) of a particular set of languages, and it's a holdover from a past where RAM and cpu time were much more limited. More moden (OO) languages don't use seperate header & source files, using modular or namespace based scoping instead. C# and D (here) are examples.

By extension you can compile C, C++, BASIC and Java to assembler as well - but that doesn't mean that assember is "better" than any of the higher level languages.

Being "pretty" is subjective as well, I don't think that hold much weight. I quite like being able to call methods on objects. Function pointers in structures, while fun, don't quite have the same neatness to it.

Personally I'm quite interested in the D programming language - at least in it's philosophy of cleaning up the bits of C++ that get in the way and simplifying the grey areas that nobody admitted to using (I'm less sold on it's garbage collection though). I'd be quite happy with a language that was perhaps "C+" - a language defined as being "C with objects" - indeed, this is what I use in most of my day-to-day work.

is already way ahead of C# and Java, it even has templates! See comparison.

How about Python? D?

Time to switch to the D Programming Language, from Digital Mars which doesn't suffer from any of these problems.

Try the 'bit' type.
A list of C and D primative types is here.

After reading about a quarter of the spec for D at digitalmars.com D feels like a chance to write efficient, compiled C-like code but with some of the conveniences of Perl.

I like that the size is part of an array for example. It's also interesting that the compiler is supposed to error on ambiguous expressions that depend on the order of operation... this could be a pain, but these are examples of how D is intended to reduce programming errors.

Point 1:
I was wrong, ok.
But I still believe using
IfStatement:
if ( Expression ) BlockStatement
if ( Expression ) BlockStatement else BlockStatement
as a rule for IfStatements would avoid a lot of error cases. Not even mentioning the fact it would solve the "which else?" ambiguity.

Point 2:
Where is it written ?
Right now, the Expression rule directly allows AssignExpression as a way to build a valid expression. And Expression is the required type going after a "if". But my point here was that "=" is way too often confused with "==", and using the assignment operator ":=" (as defigned in algol 67, and used in Pascal and Ada since) solves this problem gracefully, and with minimal effort.
But using ConditionalExpression instead of Expression would be a good start...

Point 3:
What does make using "0o" as a prefix for octal notation a bad way to handle a real problem in C ? I thought about it, and since we don't care about code compatibility with C and C++, I didn't see any reason to reject it. But I may have missed something.

Point 4:
What features to drop, point 1. You want D to be as good as it can get, isn't it. And yet, at the same time, it seems to me you're saying "it may not be too syntaxly different from C".
But at some times, C syntax is wrong. Even if it suffers from a verbose syntax, and an appaling lack of good libraries, Ada solved most of the syntaxic pitfalls that plague C. But since you're trying to replace C and C++, I belive it would be great if you had the courage to correct them, even if some of the latest languages (as Java and C#) have it wrong.

I'm not going to advocate how this feature is put together; I've never used it.

• C source code compatibility - Yes. Wow, gosh.
• Link compatibility with C++ - No, can be linked to C++ Builder modules
• The C preprocessor - Yes
• Multiple inheritance (ie Full not Java-style) - Yes
• Namespaces (use modules instead) - Yup
• Tag name space - Yup
• Forward declarations (compiler searches whole module for name definition) - Nope
• Include files - Mostly 'Yes' but a little bit 'No'. Delphi does allow includes, but it doesn't use them in the C/C++ sense; it imports binary symbol tables like D. Score 1/2.
• Creating object instances on the stack as opposed to the heap - Yes, dropped when Turbo Pascal became Delphi
• Trigraphs and digraphs - Yes
• Preprocessor - Yes
• Non-virtual member functions - No, but the Delphi syntax copes better than C++ with the cited problem (no error messages when you fail to supply a virtual base class) by using an extra keyword - override - to signal programmer intent. Score 1/2.
• Bit fields of arbitrary size - Yes
• Support for 16 bit computers - I suppose 'No' since Delphi 1 was 16-bit.
• Mutual dependence of compiler passes - I think 'Yes', but I am out of my depth
• Compiler complexity - Probably Yes - deduced from Object Pascal's fast compilation. Besides everything is less complex than C++.
• Distinction between . and ->. Yes - uses only '.' operator.

• C source code compatibility - Yes. Wow, gosh.
• Link compatibility with C++ - No, can be linked to C++ Builder modules
• The C preprocessor - Yes
• Multiple inheritance (ie Full not Java-style) - Yes
• Namespaces (use modules instead) - Yup
• Tag name space - Yup
• Forward declarations (compiler searches whole module for name definition) - Nope
• Include files - Mostly 'Yes' but a little bit 'No'. Delphi does allow includes, but it doesn't use them in the C/C++ sense; it imports binary symbol tables like D. Score 1/2.
• Creating object instances on the stack as opposed to the heap - Yes, dropped when Turbo Pascal became Delphi
• Trigraphs and digraphs - Yes
• Preprocessor - Yes
• Non-virtual member functions - No, but the Delphi syntax copes better than C++ with the cited problem (no error messages when you fail to supply a virtual base class) by using an extra keyword - override - to signal programmer intent. Score 1/2.
• Bit fields of arbitrary size - Yes
• Support for 16 bit computers - I suppose 'No' since Delphi 1 was 16-bit.
• Mutual dependence of compiler passes - I think 'Yes', but I am out of my depth
• Compiler complexity - Probably Yes - deduced from Object Pascal's fast compilation. Besides everything is less complex than C++.
• Distinction between . and ->. Yes - uses only '.' operator.

And of course, generics.

Now all it needs is some community support and ECMA goodness. I think it has a good chance of being widely used.

And of course, generics.

Now all it needs is some community support and ECMA goodness. I think it has a good chance of being widely used.

The effort has gone into improving the languages and techniques so debuggers aren't needed as much. For example, adding unit tests and Design by Contract (see D) greatly reduces the number of bugs for which a debugger might be needed.

Thats great, what about the bytecode?

Yes, the bytecode is standardized.

Actually there were two different submissions into ECMA for .NET. One concerned C# as a language, syntax only with no consideration to a runtime (could make a native implementation if you wanted, would be very similar to D.) The second dealt with the CLI, or Common Language Infrastructure. Included is the bytecode (CIL, or Common Intermediate Language) and the base classes of the CLI. Here are the ECMA project pages that contain the specifications available for download:

Enjoy. The CIL standard is located within partition III of ECMA-335.

As a java developer, I prefer to call it D flat.

Music Player Sakura
Programming Language D
File Princess Ren

The D compiler will take html and compile what is between the code tags. So you can put both documentation and code in the same file. You can literally use a WYSIWYG html editor to code with.

It's called D

How about C## or we could call it D or E flat flat.

2 things - First off, to point out to all the non-musical types out there - in music notation, C##, D, and E flat flat are all tonally equivalent (ie, the same note.) Very funny :)

Second, that's a moot point anyway because as reported on slashdot the D programming language is already on its way. :)

If you're interested in DOS and Windows development, you can also try the free (as in beer) Digital Mars compiler.

No -- Symantec bought Zortech, turned it into Symantec C++, back when Symantec was into development tools; it had the coolest Windows IDE at the time, but like many other Symantec products throughout the years it died a silent death.

Walter Bright probably did a deal with Symantec to acquire the rights to the compiler and development tools; essentially this the free C++ compiler available on the Digital Mars site.

Zortech may have been the first native C++ compiler, but TopSpeed had the better one, known as the fastest compiler around. TopSpeed had a common IDE/back end for C/C++, Pascal and probably some other languages. TopSpeed merged with Clarion and Clarion/TopSpeed was acquired by SoftVelocity. Clarion isn't C++, but its compiler is probably still based on TopSpeed technology.

from the overview page...

• compile/link/debug development model
• Exception handling
• Runtime Type Identification
• link compatibility with the C calling conventions

All except the last is contained in Java.

• C source code compatibility
• Link compatibility with C++
• Multiple inheritance
• Templates
• Namespaces
• Include files
• Creating object instances on the stack. In D, all objects are by reference.
• Trigraphs and digraphs
• Preprocessor
• Operator overloading
• Object oriented gradualism
• Bit fields of arbitrary size
• Support for 16 bit computers

This seems to be precisely the parts of C++ that Java also does away with. Furthermore, the C preprocessor is not strictly part of the C language and in fact many other programming projects use cpp for simple cut and paste includes of their favorite language. When I first read about trigraphs, I couldn't wait to try them out to make some extra obfuscated code, but alas the C compiler I was using didn't support them. In fact the lack of standards compliance is one of the main drawbacks to programming in C++ and C. If my Java code compiles on sun's compiler, then I can be assured that it will also compile on any other compiler claiming to compile Java code.

The author also mentions that D will not have any bytecodes. From a strict perspective, the Java programming language and the Java VM are two different standards and just because you typically compile Java code into (confusingly named) Java byte codes, doesn't mean you can't use one without the other. For example, anyone (who is insane) can pick up a copy of the Java Virtual Machine Specification and a hex editor and make some syntactiacally correct class files. More realistically though, java bytecodes are often targets for compiler construction classes. Also, if you use the GNU Java Compiler you can compile programs written in the Java programming language directly into machine code.

While 90% of the description of this language screams Java, there seem to be some of the more useful features of C++ thrown in (typedefs, scope operator, etc.). The only way for this to be successful, is to finish standardizing the language as soon as possible and get a reference compiler for it so it leaves the realm of theoretical vaporware. Perhaps Java might have looked more like this if the language design was revisited. However, Java has lots compilers which are much much more likely to conform to the standard than the C++ equivalents.

I like the fact that you can embedd code in html and still compile it

Apparently this means "The code and the documentation for it can be maintained simultaneously, with no duplication of effort"

Unfortunately until its "the documentation is automatically created and maintened with no effort" it still won't prevent the junk I'm often buried in