Slashdot Mirror
The D Programming Language
dereferenced writes: "Walter Bright, author of the
original Zortech C++ Compiler and the free (as in beer) Digital Mars C/C++ Compiler, has posted a draft
specification for a new programming language that he describes as "a successor to C and C++". It seems to me that most of the "new" programming languages fall into one of two categories: Those from academia with radical new paradigms and those from large corporations with a focus on RAD and the web. Maybe its time for a new language born out of practical experience implementing compilers."
Remember: threads are hard. And locking will fill an exponential resource space. If you're just going to throw faster hardware at it, you should switch back to process based arch.
That's why your Perl,Python, and PHP services deal with heavy loads better - no thread contention. OTOH, they have all that process creation overhead (which is linear rather than exponential like lock contention), so if you can fix your thread bugs you can beat them.
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.
o Multiple inheritance is absolutely necessary. The main way it is useful is for Java-style interfaces.
o Getting rid of macros (preprocessor) is a very bad idea. What is needed is even more powerful macros (see Lisp).
o Generic programming with templates is the greatest thing about C++ -- the one feature that puts C++ above other programming languages. I'd rate generic programming capability as being a "must" of any modern programming language.
o Operator overloading is a Good Thing, in that it helps you set up a well-designed library as a "mini-language". Good programming practice involves reducing the number of keystrokes required to achieve a given result (ultimately). Generic programming, macros, and operator overloading all go in this direction. Eliminating them is a step backward.
o You say "smart pointers are irrelevant in a garbage collected language". Not true. There are many types of resources which a destructor might free besides memory. One weakness of Java vs C++ is that it is hard to control Java's "destructors".
The "best" programming language (for general-purpose "big" programming projects) I've encountered may be Ocaml. It can compile into native code as efficient as C++'s. It can also be interpreted. It is stronly typed. It supports a powerful "functional" programming idiom. It looks pretty good to me, although I haven't used it for anything "real" yet. But if you're looking for the "be-all, end-all" modern programming langauge, I think Ocaml's worth taking a look at.
Didn't Borland end up buying the Zortech compiler and turning it into Turbo C? There were a lot of C compilers back then.
Which reminds me, back in 1987 I was working with the Computer Innovations CI86 compiler. The documentation was a few hundred pages of photocopies in a 3-ring binder, no tools, just the debugger and linker, but it came with the source. Find a commericial compiler these days that includes the source.
www.lucernesys.comHorizon: Calendar-based personal finance
80 bits, not 80 digits. The x87 supports three formats: 32 bits, 64 bits, and 80 bits. All internal processing is done with 80 bits, but it's rounded when it's stored out as a float or double.
Some operations always give an 80 bit result (eg. adds & muls) but some (eg. divides) can be limited by the current precision setting.
floats have 23 bits of mantissa, 7 digits precision.
doubles have 52 bits of mantissa, 15 digits precision.
80 bit "long doubles" have 64 bits of mantissa, 19 digits precision.
I guess few remember the great debates (in good humor) about whether the successor to C would be called D or P. Bjarne Stroustrup managed to appease (and probably get a good chuckle out of) both sides by calling his newly developed language C++... An obvious software engineering in-joke.
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
It is not very nice thing to say, but the guy stuck
in the time few years ago:
1. Java is already invented.
2. Nobody cares about 16 bit code anymore.
If you like Java, use it. If you dislike java,
stick to good old C++. No need to invent a new language.
It would be really nice to have an open alternative to Java that is also compiled. Glancing through the spec there is lots to like there. For instance the idea of building unit tests into the language spec seems like a pretty good one to me and would help popularise unit testing among developers. Native support for unicode is nothing new but it's nice that unlike Java he still retians the ascii type for those who don't need i18n. I hope the guy pulls it off. I'd like to play with a new C++ like language. If he only reconsidered his views on templates though...
Your pizza just the way you ought to have it.
I'd be interested to see a *true* benchmark
I've done that - kinda. Wrote several mickey-mouse comparisons (moving memory, calculating pi, etc), in C, C-machine-translated-to-Java and in regular Java.
The biggest problem was that, for the tasks we were interested in (memory-management, for example) C and Java do it so differently there is no easy way to compare. (Java's habit of creating multiple references to single objects instead of multiple copies of the same object really helps it here).
In general, Java was 3-4 times slower than C on string manipulation with built-in classes/library functions, but was damn-near identical on heavy maths (Java dropped ~1 second for every 30 secs of calculations.)
(Visual C++ 6 compiler against Sun's latest JRE for Windows NT. These timings were only ever meant to be rule-of-thumb.)
Contracts are a new idea to me, and it looks pretty good. It's a sort of super-assert statement (and assert is now built-in, not a library). Using contracts properly should help both in communicating with other programmers writing related code, and in catching bugs. I don't know about you, but I hate debugging and I'd much rather write bug-free to begin with; this is going to help a little.
One quibble: his square-root function example shows he's never programmed anything mathematical. The "out" contract specifies that squaring the result gives you back the input. In long integers. That is, x = 20, result = sqrt(x) = 4, result * result = 16, the program fails. In floating point, you can get pretty close, but it's never exact so you can't just assert result * result == x. You assert abs(result * result - x) 10.0E-6 * result, for example.
And calling it Fifth fits more so than Further- Forth comes from the word "Fourth," as in the cardinal number. The mythology goes, the filesystem where Forth was first implemented couldn't handle a filename as long as Fourth. ;) Hence, forth.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Looks like he took C++, removed all the nastiness, and added all the niceness of Java in. The syntax, and spec is surprisingly Java-like. Sounds like a wonderful language...I was waiting for somebody to makea native Java-like language.
It's 10 PM. Do you know if you're un-American?
Overall, it looks like a pretty good job, if what you wanted is a language for large projects on modern desktop & server computers. It doesn't entirely take away C's capability of letting you screw up enormously, but it does make screwups a little less likely. For instance, C and C++ programmers tend to manipulate strings with pointers; this results in very efficient code, but combined with sloppy programming (always by management decree, I'm sure) it also results in hundreds of security exploits involving buffer overruns. D gives you dynamic arrays, which handle strings the way they ought to be handled, and I think makes a program that allows buffer overruns harder to write than one that doesn't.
On the other hand, I do some embedded programing with 8-bit CPU's. I rather suspect that over half the people who frequently code on-the-job are doing the same, although most of them are not "programmers" but rather are EE's, design engineers programming their own designs. Certainly you'll find a few dozen of those 8-bitters in the average american home, even though they own nothing they recognize as a computer.
D doesn't even define how to compile to a CPU with less than 32 address bits. That doesn't mean it's a bad language -- in fact, it make's it a better language for the 386 and up -- but it does mean that it's widening the gap between embedded programmers and the rest.
Likewise garbage collection is acceptable in an embedded system of any size only if you can control when it happens, and there is no mechanism in place for this. (The docs do mention that interrupt-handlers probably can't be written in D because of the garbage collection.
But for desktop and server applications, I like 99% of what I've seen and have just one complaint: operator overloading is _important_, it lets you write extensions to the language.
Oof... believe me, I know about strong versus weak typing. (I posted the parent, but posted it anonymously by accident.) I learned real programming (i.e. not Applesoft Basic) with Scheme, and learned SML last year. SML is just about as strongly-typed as you can get, and Scheme is weakly typed.
Weak typing does have some advantages. I use Perl, which is weakly typed, and the convenience is worth it. But weakly typed languages are slower than strongly typed ones (and this is a fundamental limitation that can't be removed, weakly typed languages have to have runtime checks for types). Also, type errors can catch a lot of common mistakes at compile time rather than runtime (for example, putting arguments to a function in the wrong order will often trigger a type error.)
Overall, I definitely agree that weak typing has some purpose, but for general applications development, strong typing makes for significantly more maintainable code - at a cost to developers, to be sure, but in my opinion a worthwhile one.
I metamoderate all Redundant and Offtopic moderations as Unfair.
Have you ever tried Visual Basic? I know it gets a bad rap sometimes, because it is VERY forgiving. It is extremely easy to write very crappy code that still works.
.NET runtime is about: moving away from Win32. What is easier for using sockets to listed on Port 80? Fooling with the separate WinSock2 API, or doing "Dim mySocket as New System.Sockets.TcpListener(80)" ?
.NET is a very large umbrella. But what it is bringing to the programming side of things is very impressive indeed. An entirely new programming paradigm where everything you ever wanted to do is neatly arranged within the various Class libraries. I know that in and of itself isn't new, but having that kind of support on the OS level IS new.
However, for those who bother to do the job right, VB can be a very powerful tool, used to create shipping application. (As I personally have done.)
With VB, you don't care about all the "stuff" underneath (which can be a problem when you try to do something that isn't built-in, but there are creative solutions). You just drag controls onto your window, and write the code behind them. Very easy.
VisualStudio.NET is bringing this in two different directions: First, VB gets full access to everything, and is no longer the "bastard" child of the VS family. Secondly, the other VisualStudio languages get a new Forms system similar to VB's -- just drag controls onto the Window, set properties, then write the code to handle the events. Easy and clean.
That's really what the entire
This message sometimes gets lost because
Microsoft has already stated that when the Win9x code line is pretty much dead, and everyone is writing to the CLR instead of Win32, they are going to make a move to port the CLR to the WinNT Executive (that is NT's native kernel API). Win32 will finally be relegated to "legacy" tech just like DOS interrupts and Win16.
Natural != (nontoxic || beneficial)
Rereading the site, I think these are a mismash of ideas, not completely thought out, or at least not peer-reviewed (a.k.a., "Hey, lemmie bounce an idea off you"). Some of them are good, depending on your localized value of good in the context of a programming language. Some I don't like, but then there are things in all languages that I (or any given programmer) don't like.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Reading the document, I felt that old shuddering horror I felt when I learned Modula-2. M-2 looks great on paper until you try to build a major project with it.
It sounds like he took Java's design aims and added Nicholas Wirth's bugbears (being an academic) and tried to marry them, but the problem I have is: what's the compelling reason to use this over Java? I didn't see anything in there that gives it a clear advantage over Java, and he doesn't give an alternative to templates. Templates, especially as implemented by C++ and Ada, can create type safe structures that a pure OO design can't (A Stack of Objects cannot distinguish what's being pushed onto it at compile time).
Sounds like he's enjoying the ego trip of making his own language. Personally, I'd rather wait and see what Stroustroup's C++ Redux effort generates.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
While I think you have some valid points, you are far too eager to suckle at Microsoft's teat and call the watered down skim soya milk it gives 10% m.f. homogenized.
I too like VB (quit staring at me like that!), and I agree with you that poor programmers give VB a bad man, but I big to differ on the idea that VB somehow protected you from Microsoft's shifting API's. You've read the reviews for VB.Net? Everyone VB programmer out there is screaming blue murder because the object model in VB has so radically changed that it requires re-learning VB. Yes, I said re-learning VB. MFC has changed their official "ways to do things" with each major release that it's necessary to re-learn MFC every major release. Sure, MS can provide some insulation from their API's, but even their insulation can't protect you from the pointy spikes that poke through everytime MS changes its architecture.
One other thing:
As an embittered and disgruntled fan of NextStep, I vehemently disagree with your opinion. :-) You want a seriously kick-ass distributed networking object-based API? Try NextStep's Distributed Objects. Can you say, "Sweeeeeeet!"
Other than that, I think you made some good points for people to think about.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
PostScript and Forth may be based on some of the same ideas (stack-based), but they're far different in purpose, so I wouldn't say PS is Forth's successor.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
But you know, just yesterday I re-read 80% of Kahan's site, and he does in fact recommend that non-expert numerical analysists (i.e. just about everyone) should use the maximum precision possible, as a sort of band-aid. Not that a guru like him thinks it's a cure-all, just that it'll help people a bit.
So Walter isn't that far wrong there, after all.
Professional Wild-Eyed Visionary
I'm no Forth bigot, but give bigForth a try- it's fun! I say, I'm impressed!
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I am aware (slightly) of literate programming.
Literate programming, Code-in-html and what I am suggesting have in common that they intersperse code with documentation in markup language. What I am suggesting is different, in that I believe the markup should be semantic, not stylistic in nature. I don't care about the point size of typeface of the comment, but I do care about the nature of the information each comment carries.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I think Walter Bright should be encouraged to keep doing what he is doing. Your comments about TopSpeed (I remember that one, too) are an illustration of how the software industry is going today; a small number of big companies buying a large number of small companies, with deminishing choices for the consumer. Let's encourage all the innovtion we can, even if we dont' think the idea is particularly sound.
www.lucernesys.comHorizon: Calendar-based personal finance
I like VB.NET.
:) They both compile to CLR, and VB and C# can use eachothers classes interchangably. Each has its own specific quirks and strengths, but in general, if you can do it with C#, you can do it with VB.NET, and if you cant, then just do that part in C# (or Managed C++) and then consume it from VB.NET.
.NET runtime, and vb simply compiles to it. You'll also be happy to know that theres now a standalone commandline vb compiler. Best of all, theres a standard VB project type called "Console Application". No silly forms ever get involved - at all.
Given that I converted several hundred program from VB to VB.NET, I can speak on how different the two are.
Essentially, if you "just got by" with VB6 because of how simple a world view it could present, you may be in for a small learning curve with VB.NET
Now the good part:
If you can program in any C-family language, perl, or anything moderately more complex than VB, you're going to love VB.NET because you get to keep the simplicy of VB 95% of the time, but you get 99% of the power of C whenever you want it. These percentages are of course made up, but for those of you that are following C# and like it - VB.NET is almost the same language, what-you-can-do-wise
You'll be happy to know that there is no longer a VB runtime - now theres a
On the other end of the spectrum, theres a VB project template for creating Windows NT services. This was not even necessarily possible with VB6 - and to do many interesting things in VB6 you needed to import Win32 functions.
So in general, i think people that are programmers will love VB.NET - it gives all the long-time vb haters and complainers many things they've been asking for - and then some.
On the other hand, people that can barely grasp VB6 may be in trouble - the new power and flexibility of VB.NET does come at a price in terms of complexity of auto-generated code. If you're already in trouble when you accidentally go into the code window instead of the design window, expect problems with VB.NET.
My opinions are my own, and do not necessarily represent those of my employer.
Some Java code can run as fast as the native compiled code. Some can't. It's the curse of having that VM- it eats extra cycles, even if it's JIT compiling huge swaths of code (It DOES take time to transcode the bytecodes to native machine code...).
In the case of the UI's, it's partly a problem that Java just isn't QUITE as fast as either C or C++ and that you've got the sandbox in the way- amongst other things.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Here, you can see the Right Thing is to write code naturally and functionally:
float factorial (float x) {
return x * factorial(x-1)
catch overflow throw overflow;
}
that is a billion times better (I put infinitely first, but got an overflow :) than this:
bool, float factorial(float x) { :)
// and by now if you can't see what
// is so fscked up about this approach
// you shouldn't be writing code
// forget about compilers...
}
Now, you're probably thinking "yeah, but overflow is an exception already" but my point is that looping over an array of strings and looking them up in a dictionary and doing something with the result should be treated just the same way: functionally till there is a not found, and it is so much more natural to write it as an exception rather than put that ugly if in there every time.
This was my whole point in the beginning: stop thinking of exceptions as "errors" and think of them as normal control flow and build compilers that can handle it.
There has already been a "D" language. It was written and used in an early phase of the Xanadu project, when C was still young. It compiled into C (essentially a preprocessor) to give it a number of features that were missing at the time. (One that sticks in my mind is long names, though there were several others of significance.)
(It led to an interesting confrontation at one point. Roger Gregory was accosted by a member of one of a cult, who gave him a flower and started on the cult's conversion spiel. When the cultist got to the first question (your occupation) he said "I'm a 'D' programmer.". Of course the cultist heard it as "deprogrammer" and ran.)
I hear that the language "BCPL" was part of the inspiration first for a language called "B" and then for "C". By that precedent the first non-superset successor to "C" should be "P".
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
After using C++ how can someone still want to use it???
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
> righteous that you think Java and C++ are the answer
> to all programming problems? Get real. They both
> have their place, and there's nothing to say
> that D might not have its place too.
If he would invent something really new I would not argue. What he offers is another facelift to C++ which was extention of C. He offers it in a way very similar to Java.
For fresh approach to OO languages take a look at
OZ. I wish I had more time to play with it. Looks quite interesting.
I really get disappointed when people invent pet language for their project when there are thousands of other lanugages which you could use. For my projects I am using
GUILE.
This language looks to be the same as everyone else's attempt to make a modern C-like language (ie, Java, C#). What is the point?
For a fast (as fast as C, maybe faster), safe language with some really neat (and probably unfamilar) features, try O'Caml. This will cure your doldroms, and you may never want to go back...
http://caml.inria.fr/
Here's my 2 cents: D Sounds ok. I DO like the idea that a typedef actually creates a new type. But as a C++ programmer of 9+ years who is not "terrified" of managing his own memory, and who thinks that operator overloading and templates are cool, I have some issues with the draft standard as it stands:
1) Templates: I hope that Mr. Bright does find an answer. I agree that C++ template syntax is tough, but the power of generic programming is far too great a feature to drop for large applications!
2) Operator overloading: I like it, many people don't. Used properly you can make some very cool looking type safe code. I don't think a very powerful feature should be dropped from a language just because some people are idiots. C++ is not a toy; and neither should it's successor be.
3) Interfaces: Hello out there? The world has gone distributed. How about direct language support for CORBA interfaces? Now THAT would be a slick feature to add to an extended C++ language!
4) Standardize the name mangling! Name mangling issues are what make different C++ compilers incompatible; let's fix this oversight...
5) Garbage Collection: I'm ok with garbage collection but DO give me a way to override the collector! There will always be situations where I know I can get rid of something but the garbage collector wouldn't see it that way. DO give me a way to manually kick off a garbage collection cycle and DO give me a way to manually delete things.
6) I'm working on a million line+ surface ship combat system right now. One thing that the old Ada programmers keep screaming about is the inability to get very fine grained control over numbers; and for this application I can see why they are complaining. What's needed is a way to enforce the domain of a numeric type, ala low bound high bound with an exception thrown for invalid values. Very fine grained control over coordinate and range values is key to a large class of military applications.
I've been pondering my own new language too. Maybe I should go for it. My language would look alot like C++/D - with the items listed above - plus some other ideas that I've been pondering...
--Richard
By "Java can be as fast as C++," do you mean that "C++ can be as slow as Java?" It takes some doing, but I'm been able to code that badly.
It's unfair to compare a Java UI directly with a native UI.
Why? Users don't care about wether your application has a slow user interface, all they'll do is complain that "This program is slow"
Java has a place, and by extension Java UI's have their place. But saying "Oh well it's O.K for the user interface to be slow, because it will run equally slow across all platforms" is a load of rubbish. If Java code can run just as fast as native compiled C or C++, just why are the Java User Interfaces slow?
Any Java zealots want to clear up the aparent contradiction there?
Syllable : It's an Operating System
I find it humorous, because two of the 'advantages' of java were simplicity through lack of support of templates and operator overloading.
But, now that the language is mature, and the people using it want a more mature language, they are probably going to add genericity back in :).
Which kind of leads me to the thought that, in general, the whole idea of 'leaving features out because they aren't used' is flawed. Leaving features out for other reasons is good. But perceptions of lack of use are not.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
I read the specs. 20 years ago it would have been impressive, but now...
.Net for a very good reason: it adds a great deal of flexibility. Java has already shown that VMs can efficiently execute numerical code. HP has shown that interpreting bytecode can actually be faster than compiling it. There is no sound reason to dismiss the concept of a VM anymore. Java vms are even available on embedded machines now so size is not an issue either.
.Net, the JVM or some other vm (unix currently lacks one) so that you can at least take advantage of the features and libraries offered by such environments.
Lets summarize:
- no generics, yet (he was 'thinking' about it)
- I haven't spotted an interface construct like in Java, very useful and no performance penalty -> include it!!
- no dynamic classloading, another useful Java feature
- no reflective features, another useful Java feature.
- no new features worth mentioning
I would propose this language were called Java--. It removes features the author of the spec deems irrelevant and doesn't add any new ones. Java has its flaws but these flaws are tolerated because it also adds useful features.
Incidently, the VM approach has been adopted by MS now in
If the author of the spec still wants to go ahead with implementing D (aka Java--), I'd strongly suggest to make it compile to
And finally, there is no market for this language. C/C++ programmers are generally so much in love with the language that they are virtually blind for its disadvantages and ignore/dismiss competing languages (of which there are many). Based on this it is safe to assume that most of them will also dismiss D, no matter how good it is. And since I already argued that the language really doesn't add anything new, programmers of other languages will also not be inclined to swap language.
It is funny that all attempts to make a new language that looks like C++ but doesn't have its advantages end up looking like Java. Maybe the Sun guys got it right after all. It certainly is a nice language to program in.
Jilles
Even better- I was browsing the Simtel archives, and was quite amused to find a language called B-flat. :)
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
of my project! However there are some differences.... I do plan to allow templates and operator overloads, however currently these two feature a vapor, since they are not yet supported
:o)
/. but:
I called it Dtone, since I thought calling it just D would be arrogant, claming a single letter name. However it seems others didn't disturb that
Well it's not nice to link to ones own page, and advertise on
http://w ww.dtone.org
--
Karma 50, and all I got was this lousy T-Shirt.
There used to be a guy called Stewart something on Fidonet programming board, who would argue that ASM was the most portable of any language, and he could cross-compile his project (with millions of lines of code) onto any new CPU. It was great fun
I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter
Ah...the good ole days. I think in around 1991 I was dealing with a Watcom? C compiler under VM/CMS and was having trouble with something. I posted to a BITNET mailing list - nothing too major, and someone from Watcom actually called me like 10 minutes later after reading the post.
Back when customer service was good!
Many of the features look pretty sensisble. There is now pretty unanimous support for dropping Multiple inheritance. The problem with multiple inheritance being that it leads to programs only the original authors understand.
It is disapointing that the syntax was not changed more radically. I for one am pretty bored with typing semicolons at the end of lines. Using braces for block structure is equally tedious.
The garbage collector is of the 'stop everything and collect' type, this is not a good scheme as anyone who has seen a PET running Microsoft Basic GC will agree. The incremental GC in .NET is a better scheme, even if it is slower overall. But that is an implementation detail.
It would be good if people would start to look at adding support for parallel program execution. The threads programming model is very clunky and hard to use, in part because there is no means for the program to perform checks on access conflicts.
Also a persistence model should be part of any new language. The current division between programming language and database is a lot of wasted overhead.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Doesn't seem to me that D doesn't anything which can't be done perfectly well in C++ or Java, both of which are massively supported by contemporary technology. Inventing a language like this is fun and is a useful mental exercise, but is about on the same level of utility as trying to learn Klingon.
Got Rhinos?
No kididing. Anything you can do with switch statement you can do with if...elses. Even better, if...elses have way more flexibility (you can do strings, floats, objects, not just int/char). So that feature is not so important.
Also, I like sizeof() since it's a feature of the language, not a class's function, so it shouldn't pretend to be a member function.
Got friends?
This is not a Windows specific problem. Any modern GUI (e.g. KDE) has the same difficulties. Even when all of the crap is hidden behind an OOP veneer, it is still a mess to work with. Arguably, OOP has made things worse. What we really need are system libraries that are designed to get the job done as easily as possible and not the result of someone trying to made the world fit his own pet OO model.
Walter Bright wrote the Zortech C++ compiler. He's good.
Can you imagine the flop they would make marketting 'Visual D' - VB and VC worked ok
Why would anyone need OO? They don't. Why does anyone need C? They don't. Maybe we should just all be using hexeditors and doin raw binary. Don't really need assembly, or the OO macros for assembly (yes, they exist).
There are actually quite a few Forth object systems. MOPS and bigForth come to mind. Come to think of it, Forth plus an object system is probably about the fastest OO you can get.
On the other hand, you could propose that "Forth" be followed by "Further". After that, you need to *think* before finding a new name.
Ignoring the obvious fact that choosing a name like "Further" for no reason but that would be stupid, one could just as easily say "Farthest," and "Damn, we're serious about being Far now (DWSABFW)".
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
The real reason? He couldn't get it to work in his compiler..
The Java try-catch-finally construct is not the same as nesting a try-catch within another try-catch because the finally block is always executed. In your scenario the finally is only executed if an exception is thrown. Adding a throw at the end of the inner try will make it behave like try-catch-finally, but then you have to have code in the outer catch to distinguish between the various cases. try-catch-finally is a simpler way to do it.
Well multiple return values is an old problem, and excpetion throwing is just the latest solution that can be misused for this purporse.
Well actually you can handle non errors also as exceptions, why not? But becare that exception catching is an expensive job. It requires some time to do multidrops (jump several functions call backward at once, not just one like the normal return), since the complete stack so far has to be cleared and destructed cleanly by that process.
I'm not saying that exceptions this way is the last answer to the multi-return problem, however they can be misused in this condition.
to declare a function with multi returns could be done rather easy:
take this as dummy example:
int32 , bool positivize(int32 a)
{
if (a 0) {
return -a, true;
} else {
return a, false;
}
}
This could be done easily with parsers/compilers however the problem arises how to call the function...
positivize(4)
Now how should this be treated furhter? So far there is no public solution to it.
function(
--
Karma 50, and all I got was this lousy T-Shirt.
Oolite: Elite-like game. For Mac, Linux and Windows
And the reason that I think that Java's mechanism is only a small step in the right direction is that it's simple a convention. There's very little behind it. I don't have to name my classes with a package, nor to I have to pick a package name that is reasonable. Package names actually take up a considerable amount of space in a Java file - I wrote a commercial obfuscator package and it turned out that something like 5 - 10% of a Java class file's size is just package names embedded in every reference to other classes - and it seems silly to drag all of these strings around when a more concise, robust system could be used instead ...
This is probably what everybody said about C++ when they were using C.
The first version of C++ was a preprocessor which converted C++ into C. Thus you still had all the compiler optimizations and even the code for the compiler itself. Then you could further optimize the binary by shortcutting some of the C++ -> C -> machine code into C++ -> machine code.
Garbage collection has already been implemented into C++, it seems silly to make a new language for it unless you can obtain some serious optimizations.
The only real advantage of java over C++ that you can't build into C++ is the security manager. That can't be done without either hooks into the OS or an interpreted language.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
Well, compilers don't really amount to system-level software. They're just extraordinarily complex text filters, mapping source code to assembly. They have total control over their choice of internal data structures and so on, so the issue of converting pointers to/from non-pointers rarely arises. There's lots of low-level software where this is not the case.
I'm not saying this guy doesn't know what he's doing; just that if he is trying to solve all the world's problems, then he may have missed the mark in this particular area. (Although in his defence, he has not yet removed unions from his language, so apparently he is aware that they may be too useful.)
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I'm afraid I have to disagree. I'm a pretty strong Java advocate, but I still don't feel that it's ready for desktop use because of Swing performance issues. I spoke with several of the engineers that worked on JBuilder while I was at JavaOne this year. They spent a *LOT* of time writing custom classloaders, etc. to make their GUI so snappy. JBuilder is a spectacular example of a well written Java GUI, but I don't know if it would be reasonable to say that just anybody could write something like it in 1/10 the time of some other language.
Now on the server...that's a totally different story. I write server apps all day in Java --- my development times are SLASHED from what they would be in C/C++, or even CGI's. Maintenance and documentation are a breeze, and performance is fabulous. Java really has done great things on the server.
Nathan Hale
1) American Revolutionary soldier hanged by the British as a spy. According to tradition, his last words were "I only regret that I have but one life to lose for my country."
2) An asterisk ("*") Notionally, from the misquote "I regret that I have only one asterisk for my country!" of the famous remark uttered by Nathan Hale just before he was hanged ("life to give" -> "ass to risk" -> "asterisk").
Weird, wild stuff there, Ed.
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
This isn't irony at all, it's exactly my point: to maintain array bounds and check bounds is slow. It's good to be able to whack stars and square brackets in my C code and have it run fast, since I know what I'm doing.
// bounds checked so doesnt crash
You can use a template-based array class in C++, which (at a guess) will be no slower than Basic or Java arrays:
Array Karma(1000);
Karma[1001] = 50;
etc. , and just not use the * and [] syntax. If you were feeling really leet, you could make some macros and typedefs to make your arrays look pretty Basic-like or C-like.
Anyone who really knows the origins of the language "C" knows that its successor should be called "P" and not "D".
.pl is already taken. :)
BCPL. But
(credits to Larry Wall, I think.)
Nope. Modern garbage collectors certainly don't walk around memory collecting things (and neither do modern heap allocators). All the tabular stuff that indexes memory and structures is usually contained in a small set of pages. Those refer to blocks elsewhere. No page swapping is required.
Actually, that's not quite true. But generational collectors are set-up so you don't have to run through entire sections of memory except in rare circumstances. And you can use virtual memory hardware to alert the collector when an old generation is being written to (so you don't have to look yourself).
Meaning that, since the garbage collector has to periodically walk all of the heap of a process, it would seem to me that it would thus periodically force any pages that are paged to disk to be brought back in by the VM even if they didn't need to be otherwise.
I used to do alot of Java programming, and I got the uncanny feeling that every time my program grew very large (which was very often - Java programs use *soooo* much memory, don't know if it's just a general tendency of GC or if it's Java's implementation) the system would thrash quite a bit more than if I wasn't running any Java programs ... and I came to believe that it might have something to do with the garbage collector forcing the OS to load every page of the process into memory as the GC swept through, so everything that modern OS's do in terms of trying to streamline VM kind of gets thrown out the window when garbage collectors are forcing every page of their process to be loaded in periodically.
Just wondering why no one has ever made the point (to my knowledge, anyway) that garbage collectors may be very bad for virtual memory performance. It seems quite likely to me, anyway.
Otherwise, I like just about every idea in the D language, especially his Name Space notion - although I didn't read too much detail of his spec, at least he's thinking about it. I hate the fact that modern languages are based on string identifiers during linking; there's no formal mechanism whatsoever of avoiding clashes in the namespace (Java's class package name idea is a small step in the right direction), and it really seems stupid to me that shared libraries should be carrying around all this string baggage, and doing all these string compares during linking ...
Anyway, that's how I see it.
If you get different answers on different computers due to different roundoff errors, your software becomes unreliable. It's true!
People get confused by Intel's 80-bit FP arithmetic. Yes, the FPU expends some effort in rounding the 80-bit result back to 64 bits, but the result is not more accurate than a 64-bit FPU. In fact the answers will be exactly the same--this is mandated by the standard.
Anyone using floating-point arithmetic for anything serious needs to know exactly what the arithmetic model is. If Walter pursues this philosophy with his new language, he will make it unusable for numerical applications.
Walter needs to read:
David Goldberg, "What Every Computer Scientist Needs To Know About Floating Point Arithmetic," ACM Computing Surveys, vol. 23, pp. 5-48, 1991.
I could not find a copy online, but here is an interview with William Kahan, the Turing award winner who co-developed the IEEE 754 floating-point standard. Language designers should notice that Kahan implicates of Java and Fortran at the end of the article.
Seems like every language is an excercise in How Things Should Be Done.
As a programmer that's worked with about 15 languages over 18 years what I really want is a language that:
1> Is as quick to program in as php/perl/python.
2> Is still managable for large projects.
3> Is as fast as C/C++.
4> Is easy to port across platforms(porting Quake V from Linux to Windows should just be a recompile).
5> Performs in a predictable manner(no wierd behavior out of the basic operations every language has in common).
6> Memory management should be handled automatically.
7> Integrates seemlessly over networks.
Is this too much to ask for?
First their was BCPL, then B, then C. Logically the next language in this family would be P.
from the overview page...
features to keep:All except the last is contained in Java.
features to drop: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.
From the dictionary:
1. "#", ASCII code 35.
Common names: number sign; pound; pound sign; hash; sharp; crunch; hex; mesh; grid; crosshatch; octothorpe; flash; square; pig-pen; tictactoe; scratchmark; thud; thump; splat.
Personally, I like "C-octothorpe"
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
Silly rabbit, if you want to do a fourier transform as fast as possible, you find a FORTRAN nut and lock them in a room with a card punch.
Doesn't FWEB already do this? In arbitrary languages?
See what I've been reading.
Ciao
----
FB
No need to invent a new language.
This sort of staement really amazes me. Are you so righteous that you think Java and C++ are the answer to all programming problems? Get real. They both have their place, and there's nothing to say that D might not have its place too.
This guy's trying something new. If you see a particular problem with his approach, by all means let him know. We all value constructive criticism and suggestions. But don't just say it's no good before its even been given a chance. I for one think he has some good ideas in there, and I look forward to being able to try it out some time.
It's called "Visual Basic" (seriously, no joke here).
Builtin security = slower runtime. If you know how to program then you don't write code with buffer overruns. If you don't, then you can use a bounds-checking coddle langauge like VB.
Mooney Guy N4074H
Burris
Sorry, but as a long-time C++ programmer, I find this only a marginal improvement in the language. Granted, it is an improvement, but how many people are going to rewrite legacy code for a marginal improvement?
Personally, I think we need a radically different way of programming. I don't know what it is, but we need it. We're really in the bronze-age of programming. We've got a long way to go. Right now, writing software is more art than engineering. The few groups that do it like engineering pay a heavy premium to do it (i.e. the Shuttle Software group)
There was a guy a while back that wrote a program that emulated a bunch of CPUs. He then wrote a language for those CPUs and had a "goal" for the program. He then introduced the idea of mutations and spawning child programs. He would start off writing a program to acheive the goal, and then feed it into the "CPUs". After several generations and mutations, and a "natural selection" type process, the computer ended up generating better code than he originally did.
I've had it in the back of my mind that that's what we really need to do in software. Come up with a way for computers to put our software through some sort of "mutation" and "natural selection" process and in the end we get better code. Obviously in the real world, this is a much more complex problem than the simulation this guy wrote. Wish I could remember where it was and what the link was. Very cool stuff.
Those who are suffeciently annoyed with the cornecopia of evil known as C++ will use another language. Then there are those that think the many gotchas that make up C and C++ are fun. Those are the people that are still C++ programmers today, and have no use for this D language.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
While I generally agree that you need macros in some form, I'll observe that once you have macros with the same expressive power that lisp macros have, you don't need templates anymore. On the other hand, it may be that LISP style macros would prevent the compiler from handling the sort of type matching that C++ templates have (which both lend power, and make them the very devil to implement correctly).
LISP style symbolic manipulation of code permits the construction of special purpose syntax that is closer to the problem at hand, making the code easier to write and understand, provided that the macros are written to make things more clear rather than less. It is certainly true that you can take things too far with LISP-style macro expansion, but you can also go much much farther than you can with any text-preprocessor scheme.
> What you've learned is that shitty programming can run slow anywhere
... until I realized that it wasn't using any widgets on the main screen. The "flat" looking interface was a big canvas object and they wrote their own code to deal with user clicks on the canvas. Probably didn't even deal with the event model beyond the initial mouse events. Certainly no widget tree to have to traverse.
Yes, such as properly written swing. I saw a scheduling applet using a swing GUI that was running damn fast
Moral of the story: if you want decent performance, do it yourself, because the stuff you get out of the box will produce crap. Meanwhile, every whipped-up VB and Delphi app I've seen has at least had a responsive interface.
I've finally had it: until slashdot gets article moderation, I am not coming back.
D'oh, I really am a lamer. I never thought about that. Thanks. And it does seem to make sense to not allow an object to be constucted twice (bad things may happen). In fact, when I think about it, even though D says that calling a constuctor from a constructor is a good thing, it puts more responsibility on the programmer (you have to make sure the two constructors don't walk over each other).
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
One thing in this new programming language that needs to be designed in from the ground floor is SECURITY BY DEFAULT. Make buffer overruns impossiable for starters. I'm very weak as a C programmer and just a student of computer security but it woluld go a long way to solve most of the security problems in appliacations if the programming language enforced proper security codeing practices. Maybe everything would be as secure as OpenBSD. Theo should help design D language to be SECURE BY DEFAULT rather than doing a security review after the software is written. Just my opion, I might be wrong.
zenray
Forth is a very good language for small embedded systems -- it's portable, and the object code is sometimes more compact than assembly. But it's designed for easy and compact compiles, not for readability. I would not recommend doing a 100,000 line project with it.
I've got an idea... let's hybridize a postfix language like Forth and natural language processing. We can call the new programming language "Yoda." Here's some sample code:
Variable x to 10 be setting.
1 to x you add.
This times 10 you be repeating.
> Why aren't new languages based on Forth?
You just don't hear about them. Check out Joy and Chaos. (the link for chaos points to Coldstore, Chaos is a toy that comes with coldstore and is used to test it). Chaos has perhaps more in common with postscript than forth. The cold fact is, people don't like to program everything in rpn.
Personally, I like the idea of Intentional Programming, where you code to an AST, creating higher levels of abstract AST nodes called "intentions". In IP, the language is merely an intermediate tool to reach that end, and the runtime is a particular implementation of it, both expressed in terms of transformations on the tree (simonyi's colorful term for such transformation functions is "enzymes").
I've finally had it: until slashdot gets article moderation, I am not coming back.
Lets rephrase that:
;-)
Well, I don't believe C++ will ever reach the speed of assembly, but then again 'good enough' will usually do: Just look at Windows
Now will you people give up this silly argument?
I really don't like his ".html" file idea: code inside a html file is compiled by ignoring everything but tagged bits. The concept is to use html to document and compile the code right in the documentation. Personally, I prefer to generate documentation from the code.
I read the ".html" thing slightly differently from you. Rather than compiling code into the html file, source is included in the HTML file. If the volume of source is high relative to the volume of text, then it looks a lot like generating documentation from code.
It looks to me a lot like being able to use HTML markup for your comments, which seems pretty harmless. What I'd really like to see is an XML schema which is custom crafted for helping with programming problems -- in essence adding semantic distinctions to various kinds of comments:
[section name=init_foo]
[remarks] Our foo unit must be instantiated and helper objects initialized [/remarks]
[modification by="Alice" date="1/1/01"]Created[/modification]
[modification by="Bob" date="7/4/01"]Added code for foo-2 hardware[/modification]
[modification by="Alice" date="7/15/01"]Fixed GPF in new foo-2 code, still problems in Win95[/modification]
[TBD assigned-by="Alice" assigned-to="Charlie" for-release="2.1" due-by="9/1/01" applies-to="WIN32"] Fix random GPFs under Win95 OSR2 [/TBD]
[code]
foo my_unit = new foo(something);
init_bar(foo);
etc.;
[/code]
[/section]
The point would be to take just plain old comments and structure them so tools could do useful things with them (e.g. find out what Charlie was supposed do for release 2.0 on Win32). Of course you wouldn't want to see all this detail all the time; perhaps the default editor view could be just the code and the remarks, with little glyphs to indicate change history or pending tasks.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
"Maybe its time for a new language born out of practical experience implementing compilers."
Maybe it's time for a new language to be born out of practical experience writing software.
I don't know how it is in Linux, but I really hate having to write several hundred lines of code for a single window w/controls in Window API calls. Personally, I'd like to see MS get rid of those API calls (and don't replace it with ActiveX until ActiveX works). Between the ones that don't work as documented and the rest of them being overly cumbersome, it's just a hassle. Especially when you have to create your own encapsulation objects for those things. I like Delphi because of its encapsulation of the visual components, but their base library sucks in itself in that it doesn't expose all the functionality. And since they saw that it was so important to declare everything as PRIVATE methods, you can't get descendent object to do everything you want either because you don't have access to all the base functionality.
Simplicity shouldn't be taken to the extreme either, and gear a new language towards the non-programmer crowd like MS tries to do.
Of course MS is just making things worse right now by implementing these new Luna APIs for XP. I'm sorry, but I don't know of anybody thats been really dying for the ability to use API calls to put a gradient on a button. In my opinion, this is just MS's attempt at trying to get developers to waste time, so they don't work that hard on developing new products that may compete with MS.
Improving languages? More power to the people doing it. C++ is daunting as hell even to experienced programmers coming from other languages, and has some pretty odd legacies.
However, to play Devil's Advocate, why base a language on anything pre-existing? Is anyone creating languages completely (or mostly) from scratch?
Admittedly a from-scratch language would be up against a higher learning curve, but I wonder if the benefits would outweigh this.
Just a thought from a person who's had to learn a lot of languages.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
"Declaration" is an overloaded term in this context.
.class files in the CLASSPATH and poking around in them, and presumably the byte compiled files. So you don't need access to source code to use a class. If you wanted to do something like this in C++, you couldn't, because the necessary information probably isn't in the object file format. You would need a new format that performs some of the functions of the ".class" files, or perhaps the compiler could generate the header files for the programmer as his classes are compiled.
If you look at the source files, you see that you still have to declare variables (e.g. "int i;").
What you don't have to do is to declare classes in a separate header file, when all the information about the class's public interface could have been gleaned from source file in which the class is actually defined.
The purpose of this, I guess, in C++ is to allow the compiler to layout an object in memory prior to the constructors being called, and generate assembly for class member access, without necessarily knowing where the class is defined or even having access to source at all. Secondarily the class's interface can be determined for compile time checking. I say secondarily, because clearly that isn't the main purpose of class definition headers since they also reveal information about private members and methods, which are of no interest to the client modules.
D is more like Java in that the compiler can do all this without any special help (in the form of header files) from the programmer.
Perhaps somebody who knows java better than I can comment, but I expect that the Java compiler does all its checking by looking for
In any case, I've never found the C++ way of doing things much of a problem, but if you think about it, it is rather unnecessarily complicated. Every little bit counts.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Well, on my measely little P3 450 with 256meg of RAM, I can't, except when CodeInsight pops up for the first time on a class. Then, it's slow. (And yes, I can type fast :) )
If you're really having problems with typing in JBuilder on your machine, I'd say it demonstrates an underlying problem with your machine, not with JBuilder or Java.
Cheers,
Tim
It's official. Most of you are morons.
C and Perl are often hard to read, too. And OO languages are an horror when you have to walk through dozens of classes to find a function.
{{.sig}}
for instance, there are no headers, as declarations are lifted from the source.
That sounds like a step backwards; declarations were put there on purpose. It helps other people figure out what the code does, including you six months later when you forget.
From what the draft specs says, D doesn't look like a very good language. It ditches (arguably) useful features like multiple inheritance, templates, and operator overloading; and then it adds features like resizable, bounds checked arrays...in the language. In C++, there is a very nice resizable (optionally bounds checked using vector::at()) that is implemented in the Standard Library.
What D will implement in the core language is really meant for the standard library. Not everyone needs resizable and bounds checked arrays (the bounds checking is the one with the real overhead). If you are coding a kernel or something low level, the overhead isn't neccesary. If I don't need to resize my arrays, I just don't #include <vector>. Simple as that.
Also, there are no prototypes. Now, tell me, how does one get the source for a 3rd party proprietary library and read the source for the documentation? Often times, I document my code by putting a 3 or 4 line description of what the class [member|function|data type] does below its declaration in the header. If I forget what a function does, I just open the header in another frame in emacs and read its description (which has such useful information as what it uses its arguments for, what exceptions it may throw, what it returns, and whether or not it will modify an argument). It is also much easier to see what members are in a class when you can look at a simple declaration with the outline of class, instead of having to wade through 50 line members to see the next member. That just makes the class look messy, unless each function was only 1 line long.
The lack of operator overloading also makes it harder to implement something like, say, a complex number in a library. With C++, you have the standard complex type in the standard library. If there was no operator overloading, using complex would be more difficult (which is easier: complex foo, bar; foo.i = 1; bar.r = 2; foo.add(bar); OR complex foo, bar; foo.i = 1; bar.r = 2; foo += bar;).
I do see some good qualities. One is the ability to call a constuctor from a constructor. This results in less duplicated code, and makes it easier to keep two constructors of a class synced. Say you had a class with two constuctors: one that takes no arguments (default) and one that takes an int argument. The int argument one can't call the default constructor (this creates a temporary, contructs it, and then deletes the temporary). D allows you to do that. Maybe the next C++ specification will fix that.
D does seem to have a lot of flaws. It doesn't seem very useful. Maybe some people will find it useful. But it seems to me to be yet another language written for someone's personal usage. It makes sense to that person, but not to anyone else. C is a good language because its creators made it useful for other people as well as themselves, same for C++, lisp, Objective-C, and countless other languages.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
Why, oh, why must people propogate the myth that Java is slow?
.so library.
First, I do a lot of coding in Java. Also in C and C++. Right tool for the job and all that.
But Java -- even compiled Java -- is slower than C/C++ code, it just tends to be more correct and less likely to fail in mysterious or security-threatening ways. There are reasons for this.
The startup time is one of the obvious "slow" areas of Java -- particularly so to folks just doing a quick "Hello World" to try the language out, rather than for apps that once running keep going for days or weeks at a time. This is because Java defers linking until run time -- and links every class separately. The equivalent in C++ would be for every class to be in its own
Contributing to relative run-time slowness is the fact that Java bounds-checks every array access and every memory reference (and may have more indirection on those references depending on the implementation). C/C++ doesn't. Now, a good C/C++ program should do a heck of a lot more such bounds checking than most programs do (we'd have a lot fewer buffer-overflow exploits), but there are cases -- such as in an array initialization loop -- where a C/C++ programmer can get away without checking every access because of the limits imposed by the loop code, whereas Java will bounds check regardless.
Note that one of the features of the gjc Java compiler is an option to omit a lot of this runtime checking. As this compiler matures (gets better optimization) I'd expect gjc compiled-to-native Java to be just as fast as C++ code.
Of course, considering the state of today's typical hardware (1.5 GHz CPU, 133 MHz memory, etc), even an interpreted Java program running on that will be faster than a compiled C++ program running on the hardware available at Java's introduction (1995-ish, 100 MHz CPU, 16 MHz memory). If C++ programs were fast enough on that hardware (some were, some weren't), then the equivalent program in Java on today's hardware will also be fast enough -- and likely more quickly developed and less prone to mysterious bugs.
-- Alastair
Java is completely useless as a systems programming language anyway. So is any other language that depends on heap-allocated data structures. (Assumig compiled code. "Systems programming" with a virtual machine is a contradiction in terms.)
Systems programming depends on having deterministic runtime. "new" and "free" type operations are simply not deterministic. Their execution time depends on what else is going on at the time.
A bit of definition -- device drivers are "systems programs". Mailer daemons are not "systems programs", they're background applications.
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
And my pet peeve: No unsigned data types. Java is completely useless as a system programming language without them.
Don't get me wrong -- I like Java-the-language (while detesting Java-the-environment), and it's very useful in specific applications. I should also say that I dislike the "weight" of the C++ language. But there's a lot that Java would need before it could be a replacement for C++, even natively compiled.
Sometimes it's best to just let stupid people be stupid.
Since Bright wants to make the same kind of break with the past, he should be asking himself why segmented architecture (8086, 80286) persisted long after better alternatives were available.
I long for a better C++ but I don't think this is it.
But maybe he will accept feedback and improve his proposal?
It's a very heartwarming idea - he's attempting to conjugate C's performance, speed, and low "levelness" with Java's "oh-my-god-did-I-just-finish-writing-that,-boy-it- only-took-me-3 minutes... but-it-runs-slow" beauty.
But if it can be done, why hasn't it been done already, hmm?
: Variable ; IMMEDIATE
: to SWAP ;
: be ; IMMEDIATE
: setting ! ;
"Variable" and "be" do nothing and compile to nothing; they are just syntactic sugar. "to" does a SWAP so you can say "x to 10 !" rather than "10 x !". "setting" just does a ! (store) operation.
Actually, you could make "to" and "setting" IMMEDIATE words; you would just need to make them compile in the words they implement. I'm very rusty on my FORTH, but I think you can do it this way:
: to COMPILE SWAP ; IMMEDIATE
Then "to" compiles a reference to SWAP, instead of creating a subroutine that calls SWAP and then returns. The IMMEDIATE version saves one subroutine call and one return.
This would make a nice short article to publish in Dr. Dobb's or some similar magazine, right around April Fool's Day.
I have fond memories of an April-Fools article on FORTH, describing how to add GOSUB to FORTH. He went through several versions, before finally arriving at this very efficient solution:
: GOSUB ; IMMEDIATE
In other words, GOSUB does nothing and compiles to nothing. FORTH is all subroutine calls anyway; it never really needed GOSUB in the first place.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
From the dictionary:
:)
1) "*", ASCII code 42.
Common names include: star; splat; asterisk; wild card; gear; dingle; mult; spider; aster; times; twinkle; glob; Nathan Hale; multiplication operator; Kleene star.
Intrigued, I looked up "splat":
1. A smacking or splashing noise.
2. Name used in many companies (DEC, IBM, and others) for the asterisk ("*") character.
3. Name used by some Massachusetts Institute of Technology people for the pound ("#") character.
3. Name used by some Rochester Institute of Technology people for the feature (alt) key on a Mac.
4. Name used by some Stanford/ITS people for the extended ASCII circle-x character, or an obsolete name for the semi-mythical Stanford extended ASCII circle-plus character.
Pretty wacky, huh? I think the first definition must have come from a party college.
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
> Garbage collection has already been implemented into C++
If it ain't in the spec, it ain't in C++. You can use garbage-collecting class libraries -- which only work with those classes. You can use a conservative gc, which usually makes running finalizers a rather laborious process. And none of them have a standard library API or predictable behavior. Just because you can grovel the stack looking for pointers, that doesn't make the runtime garbage collected. Just because you can glue gc on does not make C++ garbage collected. Take Ada95 on the other hand, which does have standard garbage collection that you can turn off when you don't want it.
I've finally had it: until slashdot gets article moderation, I am not coming back.
It seems this guy really dosen't like c++. Now, being that he is a compiler implementor, I can certainly understand that! *grin*
Templates and stack instantiation of of objects with semantics [i.e. constructors/destructors] is a royal pain in the a** for compiler writers. In fact, only somewhat more recently is g++ even able to handle templates in a decent way; it took a long time to get it right. C++ was a very ambitious language, hard as hell to implement, but that's what makes it so usefull. Give up templates and multiple inheirantance? He suggests this is a good thing?! D is clearly not a language innovation, he should have called it C--.
Besides, you don't actually have to use such features extensively [or at all, really] in a C++ program. You could always avoid iostream and just #include old stdio.h, for example, only choosing to use classes with constructors for some usefull/neccessariy/labor-saving part of the code, while all the rest of it is essentially no different then C [aside from stricter compile-time type checking, which ANSI C has been moving towards anyway, lately]
This is no innovation.
A few other random points:
Ohh! Garbage collection, you can link to a garbage collecting malloc in a C++ program anyway. [If you really care to look into it, C++ allows a whole range of complex underlying storage classes for custom memory management of different parts of a project.]
Arrays are not first class objects?!
Well, this is true, sort of. But you can choose to use vectors, [or other more efficient representations [such as maps, etc] depending on your data type, and with inlining, they will be as efficient as if they were 'native language syntax' features. You don't even have to use the STL, you can write a custom implementation of dynamicly resizable vectors of your own [with automatic bounds checking and resizing, for example] quite trivially. I did it once, and it took, what, 2 pages of source. That's the power of C++, it's so expressive for implementing custom manipulations of low level data, packaged nicely into classes.
No on stack variables? All data as dynamic references?
Yech. Generally too inefficient. I still suspect that he just dosen't want to tackle the hairness of writing such a complex compiler. Remember, you can use only dynamic memory in C++ easily enough, with garbage collection too.
Overall, I think D is too lenient. I give him an F.
Still, I strongly respect the desire to attempt to implement a novel language. Not that there aren't hundreds out there, but it's a noble effort. Still, publishing without even demo code? Yeesh.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
The montly programming language holy war is about to begin!
Yes, but it just occured to me that "dc" is already taken:
dc (1) - an arbitrary precision calculator
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
D == (C++)++
Because:
you take all the backward compatibility junk out.
but retain the old libs and development model.
D == (Java)--
Because:
Java also removed all the compatibility junk.
Java, like D, also added GC as a major development booster.
Java added advanced programming paradigms, extensive standard API and bytecode, and D didn't.
D == C#
Because:
D is Yet Another C++ Successor.
it was developed by another i-want-a-better-c++ that didn't like Java.
it didn't introduce any innovations over existing languages
Besides, the name "D" is completely unoriginal (just like language concept itself). Dozens of next-worldwide-languages-wannabes had that name.
-Omer
Must'a clicked Submit twice or something, but I just got this back from /.
Oops... :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Not to mention the whole c++ i/o system with cout and cin, etc.
I couldn't help but chuckle when I saw the example code using printf.
Also I don't think c++ should be put down for lack of a high level string type or safe associative arrays. One needs only look so far as the Standard Template Library for these things.
This seems to almost parallel UNIX/Windows. UNIX consists of lots of little tools, and each does its job well. Users can choose the best tool for the job. Windows includes all-in-one, where every application has every feature the way the developer wanted, and the user doesn't have to worry about knowing how to make the pieces work together. C++ lets the user (of the language) decide which string class to use, and whether or not to include garbage collection. D appears to provide these as decided by the developer (of the language), removing the burden from the user, and aiding in consistancy across different projects.
I'm not saying one way is better than the other, but I like UNIX and c++ myself. Most people like Windows, maybe they'll like D too.
In addition to studying the Reiser source code, which was very clever in a bunch of different ways, I also once timed it as actually being *faster* than "cat file1 file2 file3 > junk". Admittedly this was under Xenix on a 286 with a badly implemented stdio package, but still...
As for operator overloading, it's pretty monstrous, however it's indispensible for new numeric types. A lot of programmers don't ever seem to need new numeric types, but it depends on your work. I've created easily a dozen unusual numeric types over the years (e.g. floating point with a floating point exponent). Don't assume that you can ever provide 100% of all numeric types that anyone will ever need; can't be done. Therefore, support overloading for numeric types only, somehow; *that* would fix the C++ problem without crippling the language.
Other data types are not object oriented? It's already a major pain in C++ that e.g. int and char* etc aren't classes. Make everything a class.
Delete bit fields? Give me a break. Promote them to first class, and then they'd really be useful. A large part of the reason they're not used heavily is that they not fleshed out in the language.
(I realize I'm simply replying to someone who quoted the D author, but it was a handy springboard.)
Professional Wild-Eyed Visionary
If, on the other hand, all he wants to do is sell compilers, and therefore he needs to convince the rest of the world of the language's benefit, then fooey.
And for the record, damn, I feel old -- I remember trying to make the Zortech compiler work for an old project of mine circa maybe 1989 or so(?) and having problems. I think at one point or another I might have actually gotten email from Walter. Wow, names from the past. In a conference call yesterday I needed to come up with a secure hashing algorithm and I said "ROT13. If we need extra security we can do it twice." and absolutely no one got it.
Anyway, back on topic: No templates? Oooooo, I have a C++ friend who is gonna be pissed....
duane
"In C++, you can look at your friend's privates."
www.HearMySoulSpeak.com
¦ ©® ±
Well, I like Forth - I used it for years. It has _many_ good qualities; readability is unfortunately not one of them. You can write readable Forth, but you have to really work at it, and it's still a pain to understand something you wrote months previously. Understanding someone elses code is even worse (especially once people start doing nifty things to the return stack :-P)
/Janne
Trust the Computer. The Computer is your friend.
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
Get the EULA T-shirt
He's making a more important point, and it's not the wrong way around - he says the specs for C or C++, for example, are so big that the compilers that implement those specs will contain bugs. And the programmers will have problems writing code that's bug free and uses the best features of the language. If he can find the right set of features to include in "D" then it'll be easier to learn, easier to write code in, and very importantly, easier to produce compilers for.
"we demand rigidly defined areas of doubt and uncertainty!"
With manual allocation or reference counts, you can have destructors that are called at some well-defined time. With garbage collection, you have Java-like finalizers that are called at some random time, maybe even from a separate thread. So, while you can use destructors to release various resources such as files and windows, finalizers can only be used to release memory.
Finalizers thus have very different semantics from destructors. And finalizers don't fit well with C++, although Microsoft, with their new "Managed Objects" system, is trying. ("Managed Objects for C++" have very wierd semantics, involving "resurrection" and multiple finalization. That's an indication of where finalization in C++ leads.)
Still, there's a growing consensus that memory management has to be automated. C and C++ program designs obsess on memory allocation, and usually get it wrong. Almost every new language announced in the last ten years has automated memory management. So there's a clear trend.
My own proposal in this area is Strict mode for C++. The idea is to retrofit C++ with safe reference-counted objects, and offer a mode that limits you to the safe subset. (The model here is "strict mode" in Perl.)
and given that hash is another name for cannabis - it can be interpreted as C on drugs :-)
I opened up the link, read as far as the section on "things to leave out", saw "templates", and closed the link. Now, this might seem a bit hasty, but hear me out. Templates are the single greatest feature of C++, and the reason that I like the language at all. Yes, they are complicated to implement, and compilers initially failed on them, but they've gotten a lot better now. Yes, they can be tricky to use, and you can get trapped with them. But for writing libraries, there's just nothing like templates. As a matter of fact, lack of templates is probably the one thing that annoys me most about Java (excessive verbosity being the other). There are people trying to fix this, with Generic Java. (Didn't want to unfairly malign an area of Java that is obviously being worked on.) Anyway, this comment has gotten rather far afield of D, so I'll just say what you all know to be true: there are hundreds of C or C++ like languages out there. Few of them attain widespread use for a simple reason: lack of backing from large entities, be they commercial or open-source supporting (or both!). D will likely be the same.
Send mail here if you want to reach me.
It's a nice name. I like "D" as a name better than C#. But that's all. From the description of the language, it's just Java without bytecodes -- but with "the option" of bytecodes. The major things it does is throw away legacy C compatibility -- making for faster compilers that are easier to write, but not a whole lot of gain for the programmer. However, maybe it would be good to have C++ updated and throw away unnecessary features, and more structured ways of defining things (like the try-catch-finally structure instead of try-catch, which I like the idea of).
It is a scripting language for a X Window based RAD tool called Telesys(? - maybe that was the name of the company that made the software).
I am very small, utmostly microscopic.
Go ahead and flame me, but I really think this is silly.
I think this is the work from someone who has worked so long with C and C++ that he thinks Java is useless, and now he's going about trying to write a language that looks so much like Java that it's just ridiculous.
Plus, Java can be compiled without a VM with GJC.
Besides, it's going to be a really hard time implementing a full suite of standard libraries for this kind of language when the C APIs are available because legacy D code will probably have just the same problems as older C++ code has (i.e. not using the std::string etc.).
But hey, if he can pull it off and it works out then why not. But I can't see large organizations adopting this anytime soon.
In the types section, he states:
Ok, fine, I guess I could live with that. But later, in the declarations section, he states: Now, I'm not sure what this guy's background is, but it looks like he may have forgotton about system-level programming. For instance, I'd like to see him write an efficient JVM without the ability to interchange pointers and integers. Besides, if the garbage collector is conservative, it doesn't matter much whether the program thinks a pointer is an integer, since the GC will have to assume it's a pointer anyway. (Of course, this rules out compacting collection, which seems to be a goal of his.)Why use a C-type language if not to get bit-level control over the machine? For any other purpose, there are better languages out there. I'm afraid that if a descendant of C loses C's bit-twiddling ability, it won't be very useful.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
He's talking about making the compiler do all the work - for instance, there are no headers, as declarations are lifted from the source. For that matter, modules and libararies and source are treated the same. I think that he *might* be talking about features that would require a new object format, and thus a new linker.
I really don't like his ".html" file idea: code inside a html file is compiled by ignoring everything but tagged bits. The concept is to use html to document and compile the code right in the documentation. Personally, I prefer to generate documentation from the code. A language that implements context sensitive comments that can be compiled into various types of documentation would be, IMHO, a very good thing. As it is, systems like doxygen seem to work okay, but if it were built into the language, you could even dump documentation out of modules on the fly. Nifty in an IDE environment, or makefile driven dev when you want to check that version 2.2 of openfoo() does the same thing that 2.1 openfoo() did.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
You're both wrong. Cee Hash, pronounced Cash.
I love the way there's a reserved word "imaginary" heh...
He doesn't have any post-code gen optimization? I know you can perform elementary optimization onthe intermediate rep, (such as folding, etc), but he'll really need another phase if he wants to optimize for pipelines, which will vary from architecture to architecture? Tut tut. Maybe it's just an omission on his part.
Why aren't new languages based on Forth ? Forth is very fast, because you can work at very low level with it. Forth applications can be portable, while staying extremely optimized. Forth can be easily extended to fit any sort of application, and you can have the feeling of a very high level language, while keeping the control of things that needs special optimizations.
{{.sig}}
Born out of practical experience implementing compilers?
Seems to be the wrong way 'round...keep up this thinking and we'll all be coding in assembler language! At this stage, languages are meant to make thing easier for the programmer.
Of course, being a programmer I might be somewhat biased...
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
Then C#, now "D"?
Could we get languages that actually have some semblance to a name, please?
I must say, though, that D is actually pronouncable instead of "Cee Pound" which sounds like you are putting sand up where the SUN don't shine (errr, maybe that's the reason it's called that?)
Or maybe it's "Look at me I'm language Dee" from Grease...
Okay, coffee time.
DanH
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
Tuplets and exceptions are still two completly different things.
// now how do you do this with exceptions?
Think about a function that inverts in example complex numbers, using two integer types
int32, int32 invert(int32 real, int32 imaginary)
{
}
or a function that searches for a specific string and returns the count of the strings, and the first occurnce?
In c it would be:
int32 count(const char *text, int32 &first);
Could be written nicer with duplets:
int32, int32 count(const char *text);
Now how do you do this with Exceptions?
--
Karma 50, and all I got was this lousy T-Shirt.
A simple little 3D engine I was working on abstracted vectors and matrices. I overloaded the +, -, *, and % operators and their assignment kin to perform addition, subtraction, and two flavors of multiplication on 3D vectors, and did something similar with matrices. Updating the position vector of an object was a simple matter of "Position += Motion;".
Not quite as l33t as your mega-polynomials, but yes, operator overloading is cool, and I missed it in Java.
I have become a big fan of Smalltalk recently, where everything is an object and every operator is a method.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!