Slashdot Log In
The D Programming Language
Posted by
michael
on Thu Aug 16, 2001 06:57 AM
from the whiter-whites-and-brighter-colors dept.
from the whiter-whites-and-brighter-colors dept.
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."
Related Stories
[+]
The D Programming Language, Version 1.0 570 comments
penguinblotter writes in a journal article: "Soon, Walter Bright is scheduled to release version 1.0 of the D Programming Language. D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D has appeared on Slashdot a few times before, and Walter has continued to add more and more features. Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives. It has been here over the past seven years where extremely gifted and experienced programmers hashed out discussions and arrived at excellent implementations of all the ideas discussed." Read on for the rest of penguinblotter's writeup.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
A critique (and take a look at Ocaml) (Score:3, Interesting)
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.
Re:A critique (and take a look at Ocaml) (Score:2, Insightful)
Still, overloading, and macros, add a great deal to the language, increasing the possibilities for creating powerful libraries, with simple, intuitive interfaces. If you want a language which protects you from yourself, use Java. But don't expect to be as productive! (he says as he ducks for cover...)
As an example (of overloading), consider the C++ streams library. Imagine having to do:
It's horrible! Instead, we can write: Nice! It's much faster to type, and much more clear (hence more maintainable and less prone to bugs).In my experience, in general, reducing the number of keystrokes (increasing the conciseness of code) leads, simultaneously, to faster-written, less-buggy, and more-maintainable code.
In general.
Not nice thing to say (Score:2)
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.
I hope he gets it finished (Score:2)
C++ and Java (Score:2)
Did anyone RTFA before posting? (Score:2)
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.
It's like Nick Wirth and Java had a child (Score:2)
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.
D versus C# (Score:3, Informative)
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.
Garbage Collection vs. Virtual Memory (Score:3, Interesting)
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.
Re:Garbage Collection vs. Virtual Memory (Score:3, Informative)
Java's class packaging is considerably more than a small step in the right direction. It supports a universal naming convention, based on the internet's naming systems, that can underlie local and remote code. D's modules are a primitive mechanism at best, similar to Delphi's. They're OK for a single organization, but problematic for integrating code on a wider basis.
D's floating-point model is dangerous (Score:4, Informative)
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 [berkeley.edu], 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.
Here's the link (Score:2)
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.
After C comes P! (Score:4, Informative)
Re:After C comes P! (Score:2)
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.
Re:After C comes P! (Score:3, Informative)
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.
Re:No, "Fith" is a spoken language (Score:2)
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.
Re:After C comes P! (Score:2)
I'm no Forth bigot, but give bigForth a try- it's fun! I say, I'm impressed!
can you say "Java?" (Score:5, Insightful)
from the overview page [digitalmars.com]...
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 [ioccc.org] 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 [sun.com] 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 [gnu.org] 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 [geocities.com] which are much much more likely to conform to the standard [sun.com] than the C++ equivalents [cplusplus.com].
Maybe? (Score:3, Interesting)
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.
Re:Maybe? (Score:4, Insightful)
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.
Parent
Re:Maybe? (Score:3, Informative)
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.
Re:Maybe? (Score:2)
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.
Useful? Not Really. (Score:3, Interesting)
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.
templates and operator overloading are good things (Score:5, Interesting)
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.
Sounds like... (Score:5, Interesting)
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."
Re:Sounds like... (Score:2)
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.
Re:Sounds like... (Score:2)
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 [digitalmars.com] 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 [softvelocity.com]. Clarion isn't C++, but its compiler is probably still based on TopSpeed technology.
Re:Sounds like... (Score:2)
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.
Nothing special... (Score:3, Informative)
The only thing new is the name (Score:4, Insightful)
D already exists.. (Score:4, Informative)
weirdness (Score:3, Interesting)
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.
Re:Convince me (Score:3, Insightful)
It's unfair to compare a Java UI directly with a native UI. How well does that native UI run on other platforms? Oh yeah, it can't. How well does it run from a web page? It doesn't.
Properly written Java code can approach the speed of pure C, be done in a tenth the time, and be significantly more maintainable and portable.
Re:Convince me (Score:3, Insightful)
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?
Price for everything... (Score:2)
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.
Re:Convince me (Score:5, Insightful)
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.
Parent
Re:Convince me (Score:2)
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.
Re:Convince me (Score:3, Informative)
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.)
Re:Convince me (Score:4, Informative)
Read again. Nowhere do I compare the speed of a VM executed program to a native compiled one. Java is not the end all, be all of languages, but it is much more than the applet creation toolkit it was in 1995. Will fourier transforms ever run as fast in a VM as they do in optimized native code? Probably not. But, then again, how many of your programs are doing fourier transforms
It's simply a right tool for the right job issue. Plain and simple
Parent
Re:Floating Point (Score:2, Informative)
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.
Re:practical experience implementing compilers?? (Score:2)
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.
Re:practical experience implementing compilers?? (Score:5, Insightful)
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
Parent
Re:practical experience implementing compilers?? (Score:2)
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
Re:practical experience implementing compilers?? (Score:3, Insightful)
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.
Re:practical experience implementing compilers?? (Score:2)
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.
Re:ASM ROCKS !!! :) (Score:3, Funny)
Re:No templates? (Score:2, Insightful)
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.
Re:First Parrot (Score:4, Funny)
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
Parent
Re:Forth !!!! (Score:5, Funny)
Variable x to 10 be setting.
1 to x you add.
This times 10 you be repeating.
Parent
Re:Forth !!!! (Score:4, Informative)
: 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
Parent