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.
Why not C-splat?
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.
BCPL begat B which begat C.
So it follows the next character should be P.
"What headers do I need?"
"Fuck it! Include them all!"
This goes way back to C++ vs Assembly. If you code Java by hand, it will definitely be faster than not (if you know what you're doing). For example, most Java programmers (and IDEs) tend to waste a whole lot of Strings and StringBuffers passing various information around. If you can stop wasting new Object's (of any kind), your programs will run *much* faster. I know, from experience.
"..language with 750 pages of specification cannot do basic things like resizing arrays."
"String manipulation is so common, and so clumsy in C and C++, that it needs direct support in the language"
Apparently this so-called expert has never seen the STL.
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.
C# = C Sharp
Yah, I tried to use jbuilder too but on my Athlon 750 with 768 Megs of RAM and a RAID array it was still way to slow to even begin to use. Comparing it with delphi I would say that I need a 20 Ghz machine to match the speed. The Java geeks say that it can be as fast but I slammed a quick little application together that wasn't even very GUI dependent and the speed diffrences were on the order of 10x slower vs the delphi application doing the same thing. I'm not a Java expert but I shouldn't have to be to get decent performace.
Good UI can't be done by just anybody. You really need to throw your best and brightest at it.
# == splat?
I always thought * was 'splat'...
i don't think it's a quibble or pedantic to point out that the x86 architecture itself is nothing but a VM. The reason you can run "native" code on all the different chips available is because the myriad all implement the same virtual machine. Everyone agrees that code for that virtual machine is executed "quickly".
If there is something about Java that means it conflicts with this (or some other important) VM, that would be interesting to hear. But it can't be said that VMs are "slow" in general.
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.
..
posted via satellite
and once again I'm schooled by my roommate. Today's lesson: never ever listen to a word I say, I have no idea what I'm talking about.
[o]_O
D does not have the features that people expect in modern languages.
No closures. OK, I can see a complier writer not wanting to implement them, but they really do come in handy.
but...
No currying - heck, I could almost do this with C macros - why should a compiler writer be concerned with this?
No type inference - to get 90% of cases, all you need is one pass through the IR - it's not hard to implement, and it saves a lot of (no pun intended) typing.
And don't even get me started about the inability to continue after up-stack exceptions. Keep the stack frame around! It's not that hard.
"My compiler's basic_string class is less than 350 lines of code and includes only ."
."
should read:
"My compiler's basic_string class is less than 350 lines of code and includes only
That's weird.
On my P100/48Mb linux box, ImageJ, the only Java program I need to run, runs pretty fast. Startup is a bit slower, and it consumes relatively much memory, but once it runs, it runs as fast as a native program. I use the Sun SDK, but I also used Kaffe and the IBM JRE, with comparable results.
Just my personal experience.
Like science? Comics? Wicked...
Funny By Nature
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
What, exactly, does the lack of unsigned prevent you from doing? Note that you can specify numbers in hex (0xFFFFEEEE). You can shift them without sign extension (a >>> 3). Bitwise & and | work. What is missing?
It's written by the guy who invented Zortech C++ and Zortech C++ (now Watcom) SUCKED!!!!
Did you mean to say "[...] wait for your 13th bithday before you start [...]", or did you mean "[...] wait until you're 13 before you start [...]"
I like correcting people in a positive, affirming way.
Fucktards like you however, are another story.
I know you're just trying to be funny, but a number of languages make it easy to write crappy code. Among them is Perl, the local favorite here. Not trying to be flame bait, but I don't see how everyone can get all smug about VB's deficiencies (which do exist I readily admit) without looking to their own favorite languages first.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Speaking of templates...
peace.
I'm sorry i've used JBuilder and it still has that sluggish you typically feel with java. As well as CPU time they also consume huge amounts of memory. When i have iPlanet App Builder(sun/netscape product) and Jbuilder(borland) open they are using nearly 200 mb of ram (with a 100 of that is swapped out by the OS).
is the build routine which is often so much more complicated than writing the code itself.
I *love* writing java when after I've changed a few files and maybe even added some files, all I have to do is
javac *.java
and everything is sorted out for me. It makes me cringe when I think about working in C++ again. automake/autoconf are not the answer.. when I have to go find a FAQ just to remember how to get it to compile after I add a new file, and the scripts they generate are bigger than my project.
Is there anything that makes compiling C/C++ as easy as java?
This might have been mentioned already, but... it wouldn't be called "D". C++ is D. The successor to C++, which is to say (C++)++ should be E.
For those of you keeping score, I think the progression goes: CPL, BCPL, B, C, C++.
-Travis
Excuse me? There most certainly is not unanimous support for dropping multiple inheritance.
First up, pretty much all OO languages support multiple inheritance of interface anyway.
Secondly, most serious OO languages support multiple inheritance of implementation as well. The fact that Java and C# aren't clever enough to find a way around it, and instead forbid it, just removes a useful tool from the toolbox of Java and C# programmers. But hey, these people also think classes all belong to the same hierarchy with an artificial common root, so they're pretty much beyond hope as far as OO theory goes anyway.
As for the "problem" you mention, that's just symptomatic of poor use of MI, and is also symptomatic of poor use of any other language feature. MI of implementation should only be used rarely in most programs, if at all. However, it does allow some programming techniques that are very useful under the right circumstances, and when it's appropriate, there really is no sensible alternative within an OO framework.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
- Compiled to native code, not byte-code (although you can compile Java to native code these days too)
- Built-in function contracts! Pre-and post conditions are built into the language! This is a great boon for coding stability (and you can compile them out in the final product for speed)
- Built-in unit testing! All the classes have their unit tests run on them before the main() executes! Sweet! (again, can be compiled out)
- Built-in debug mode! There's a programming construct for debugging! In the language! You can also have support for multiple levels of debugging in the language. (can also be compiled out for speed)
Overall, I think this is a job well done. To be honest, I'm dissapointed about the removal of templates, because they are the most powerful feature of C++ (I like LISP"Free beer tends to lead to free speech"
A lot of people I meet can't really cope with C++ so some simplification would not be a bad thing. Losing the C baxkwards compatibility should've happened in C years ago. I like the "no headers as well and macros are a tool of the devil.
However, there are times when I do want to manage my own memory - generally for performance. If I know I'm going to be allocating a ton of SmallObjs then I write my own new & delete and manage in blocks. Obvious.
Similarly as someone said earlier, I like operator overloading. If you're doing matrices etc. then it's cool. I also like templates - ugly, but type-safe.
The good points could've been done by a compiler switch
Maybe -noshit
Turns off macros, global functions (apart from main), global variables, C style casts, use of void * and all the other crap which we inherited from Brian and Dennis. Oh, and get a proper auto_ptr class and then we're done. Oh yeah, and get some decent programmers. You can write shit code in any language (try not writing shit code in VB).
This sig made only from recycled ASCII
And he should know - I was unlucky enough to have to use his Zortech C++ compiler, and it was absolutely terrible. Loads of code generation errors, a debugger that couldn't cope with large programs, and generally a royal pain.
- Alan
Ruby is using mix-in instead of multiple inheritance and they claim that it is able to do 90% of what multiple inheritance provide..
It may or may not be interesting for compiled language though.
I disagree about the macro point: the problem with macros is that they more or less "hide" the real program..
I agree that one of the weak point of GC is that you don't really control when the object are deleted. But it isn't very easy to mix "scoped object" and GC-able object: what if you assign a reference to a "scoped object" inside a GC-able object?
Ocaml is nice because it is nearly as efficient as C which is a VERY impressive feat, but it "looks" really,really bad IMHO.
I would prefer a Ruby-like language with the same performances as Ocaml..
ocaml
My biggest peeve about Java is its religious insistence that "objects are always passed by reference, primitives are always passed by value". What crap. Yes, I know that for objects the reference itself is also being passed by value, but who cares about the reference itself? The result is: I can return values in object parameters but not primitive parameters. This means there are all kinds of useful methods I can't write without (1) creating extra "return" classes, or (2) using ugly wrapper classes. And please don't tell me that "I'm not doing OO right". I'm just trying to write direct, elegant programs. Another great D feature: the ability to use assignment syntax to call GET/SET methods. So if your class has a property that you later decide requires GET/SET methods, the only thing that changes is the class definition. Support for true multidimentional arrays is another big plus for D. This guy has addressed almost all my major complaints about C++, in a way that Java does not. I would love to program in D. One thing I couldn't find was an explanation of how he does away with assignment/copy constructors. Anyone see it?
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?
I can't say that I would blame single inheritance for MFC being an abortion... I've written a bunch of Java and Smalltalk code and never missed not having multiple inheritance. Heck, even the C++ code that I wrote didn't use multiple inheritance.
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.
Name clashes can occur even if my own code isn't sloppy. Consider java.util.Date vs. java.sql.Date. One is a subclass of the other, but they behave differently causing potentially subtle bugs. It isn't obvious that "import java.util.*" and "import java.sql.*" can import a class with the same name, unless a person has good experience with both packages. Without the wildcards, it is obvious--even to an inexperienced person--thus making a bug less likely to occur in the first place.
Healthcare article at Kuro5hin
E is taken too. Its one on Wouter's languages.
See here
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)
I used misused because as far I understood exceptions where invented orignally with error handling in mind.
Well you donnot need to rethrow excpetions explicitly, however I recoqnize the problem in C++ if a function raises an exceptoin you didn't thought about, every function at least should tell the compiler it is aware of all exceptions that can be thrown, java solves this in example in a brilant way.
Okay let's the SETI@home say you know that network errors can occur, and guess you're reaction will be always the same, no matter where it occured, here a multidrop is something very beneftical. The way why it is expensive since all the destructors have to be called and memory has to be tidied up while jumping upward. However taking a stop at every fragment and rethrow is even more slower.
The second reason why multidrops are convinient since it allows the programmer to concentrate on the problem, not to concentrate what everything could go wrong.
Tradionally people often write C code in the first attempt that just solves a given problem, if some unexpected exeption occurs it simply crashes, then they add crash handlers to the code, which at the end can be even overlay the orignal code completly, one code line for solving the problem, 2 for error checking.
With well done exceptions you've at least an exceptable error handling from start on, no need to discuss the programmer can inhance it, put if the application exists with a description what went wrong is already far better than a core dump.
--
Karma 50, and all I got was this lousy T-Shirt.
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
I think I like "D". "Java" was way too long for me.
As I recall the ultimate ancestor of C was a language called CPL (Computer Programming Language), developed by Martin Richards et al at Cambridge (England) in the 60's. This was thought to be too hard to implement at the time, so a subset (Basic CPL or BCPL) had some popularity for a time into the 70's
There was a short lived lanuage called "B", which ultimately gave rise to "C" (B*C*P*L) as developed by Kernighan and Ritchie in the 70's at Bell labs.
So should we whould be calling any successor to "C" by the name "P"?
Wasn't his entire point that there are no 'other ideas' in this new language.
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
Well, I don't believe Java will ever reach the speed of c/c++, but then again 'good enough' will usually do: Just look at Windows ;-)
From what I heard one reason for Swing being so slow is becuase of Sun, who really hasn't optimized the Swing libs much yet, hopefully it'll be better in the future...
if (!signature) { throw std::runtime_error("No sig!"); }
And, of course, native compiled Java isn't slow at all! See GCJ/GCC 3.0.
If you know how to program then you don't write code with buffer overruns.
The irony is that buffer overruns are easier to prevent in Basic or Java than in C, thanks to lbound()/ubound() or .length.
How many people know that C was a successor to B which was a successor to BCPL? Based upon that analysis the successor language to C (or C++) should be P (I have no idea what the successor to L should be).
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Maybe we should just go back to BCPL...
Just junk food for thought...
My machine is hand assembled and tweaked for high perfomance :)
Theres nothing wrong with my PC, every person in the office has the same problem.
Before you email me, remember: "There is no god!"
Exception handling should be a "normal" part of the programmers toolkit, not just something used solely for error conditions. For example, a function like "strchr" (search a string for a character) should be available which "throws" the not-found result, rather than returning an exceptional or "distinguished" value such as the nullpointer. Same with eof on a read.
To give the programmer this ability,
- catch-throw need to be fast and efficient,
yes, but they also- need to have a simple syntax.
Calling such a "strchr" should not require several or even one extra layers of squigglies, nor should it require declaring an "extra" variable. The whole point is to eliminate the awkwardness of the temporary variable that distinguished values impose. The (relatively obsolete) language CLU provides a good attempt at this. (I can go into it if this thread provokes some interest.)The programmer also needs
- the standard library to provide a rich but orthogonal set of functions that signal return conditions
This is the biggest failing I found with Java. Java classes return all sorts of varying and kooky conditions embedded in values. Then, when I tried to implement my own exception-based class wrappers, I discovered that Symantec Visual Cafe had created a nightmare in their debugger:- debuggers should not automatically put a breakpoint everywhere an exception is thrown
because when it's in a tight loop" It is an error to declare a local variable that is never referred to. Dead variables, like anachronistic dead code, is just a source of confusion for maintenance programmers. "
I know the linux kernel is full of unreferenced variable warnings. Most likely, it's due to conditional programming. Without preprocessor, will the problem go away?
I don't know; however I see one case where this is going to be annoying: when debugging, you often comment out chunks of code. Here you'll get an error. Ok, you have to comment out the variable definition, too.
Don't click here if you use Linux.
What I think is necessary is the ability to make programmes portable to parallel processors. C is sequential by nature and matlab doesn't really qualify as a programming language.
I've seen big problems at a dsp-house where making the compiler was the biggest business. You see, no compiler meant no clients. When you know this is multi-million dollar figures...
nosig today
If there is something about Java that means it conflicts with this (or some other important) VM, that would be interesting to hear.
I'm not familiar with chip design and construction but I see a conflict; please educate me if I'm wrong: I don't see anything "virtual" about machine code being executed by a processor, specially one that can't be flashed. And the fact that a Pentium MMX instruction set is a superset of that of an 80386 does not mean that a Pentium has to use its "native" instructions to mimick those of the 80386.
You seem to like Java. I'm trying it right now and I think it has its place. I've heard about benchmarks showing Java to be slower than C++ (my favourite) by a factor of less than 2, but the litmus test, for me, is to write some stuff and run it, and my experience has been that it is much slower, maybe by a factor of 5 or more. I must point out, though, that I'm using JBuilder 4, a gift from Borland when I bought C++Builder5.0, maybe Sun tools are better.
yes, and there's are a lot more literate programming tools around.
Personnly I'm charmed by Donald Knuth 's WEB, it uses TeX as a nice bonus.
> First their was BCPL, then B, then C. Logically the next language in this family would be P. No, no, no. First there was CPL. And logically the next language will be PL. PL/1, to be precise. Boy, I do feel old, too.
Anyone who really knows the origins of the language "C" knows that its successor should be called "P"
First, there was B. Then there was C. Then there was P, the first letter of the "plus" in C++. Then there was L, but it was really a backward J for Java.
Will I retire or break 10K?
"Dynamic array ...to make it prettier
Fixing some inconsistency issues of C's syntax
Unicode character support "
Why didnt he call it Visual Basic?
I did read the spec. I was refering to the purpose/reason for new design, not the implementation.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
As are .p and .l, unfortunately. :-/
Mooney Guy N4074H
Easier to write vaporware.
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
Simple answer: because anything that is VB-like is not C-like and anything that is C-like is not VB-like.
¦ ©® ±
A Descent into Limboc en t.html
b o. html
Brian W. Kernighan
http://cgi.www.vitanuova.com/inferno/papers/des
The Limbo Programming Language
Dennis M. Ritchie
http://cgi.www.vitanuova.com/inferno/papers/lim
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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
What the Baltimore County Public Library? I used to work there for a little while.
"This is a joke and not to be taken seriously"
You obviously don't understand what a template is. Smalltalk and Java and a whole lot of other languages (excepting Haskell, Eiffel and the likes)have generic programming in the same vein as C has: through the use of void*. Whether you call them void* or Object doesn't really matter, the only thing Smalltalk adds is the ability to do a runtime check for the actual type. This is not generic programming where the types are correct and known at all times.
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
o Single inheritance only
o All memory access through references
o Garbage collected
o No templates
o No operator overloading
o No preprocessor
Differences between D and Java:
o Unicode supported in source code
o No religion (ROFL)
Walter seems to be confused about some things. First, Java doesn't require a VM. See gcj for instance (there are also other traditional Java compilers, such as Transvirtual).
Also, Walter seems to not understand the value of operator overloading in a very large problem domain - mathematics. This is especially sad given Unicode source code, meaning real math symbols could be used.
Overall, if I had to grade this language design, I'd have to give it a "D". ;-) It is a very minor knockoff of Java.
I seriously doubt this language will become popular. If you like it, learn Java...the "Java is slow" mantra is just plain wrong these days.
186,282 mi/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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.
NeXT/Apple's InterfaceBuilder does just that, but using Objective-C (a small set of extensions to C) instead of a specialized language. You literally draw lines between controls and instance variables, or between buttons and methods.
I just wanted to reply becuase you wentthrough so much trouble writing what you wrote and nobdy seemed to care.
"C-Pound"? I thought it was "C-Sharp". Actually, I've been calling it "D-Flat" which is the same note, and the word "flat" matches my expectations of Microsoft's language so much better than "sharp".
It's been done... once in 83, and revised in 95.... it's called Ada. Check it out.
: years 10 ; ;
: pain SysBeep(10)
i Forth like
Forth years used->i
Forth good_qualities =
readability dup rot pop pop
work_at_it if readable then
something_you_wrote a_long_time_ago = if pain then
someone_else_code
nifty_return_stack_tricks
if pain pain pain
else pain
then
Okay, so the vast majority of programmers are close-minded zealots who make ultimatums on the languages they like to use: "It must have operator overloading!", "Templates are the one and true way!", "It must have the power of assembly language." Granted, for what they're doing these statements make sense; but perhaps they're improperly implemented. There are hundreds of languages out there which were introduced to replace the inconsistancies of C and C++. Some have failed because they never got off the drawing board; others were ignored by the industry; and still others just don't work in practice. But these issues can be resolved. The answer to the "Quest for the Ultimate Programming Language"? Empiricism! You know "Human Interface Testing"? Why can't these ideas be applied to programming languages? Compare two languages with similar features except one difference, say "Templates." Have a team of programmers write a simple program, a medium program and a large project with the aid of templates. Have another team write the same programs without them. Compare and analyze. I understand that this idealism can never be put into practice as is; the resources required would be incredible. But surely we can make some small steps. Let's add a list of papers in the spirit of "Goto Statement Considered Harmful." In the future we might see headlines on slashdot like "Multiple inheritance not worth the trouble." Remember, back yourself up with statistics, peer-review and examples; not sophistry!
Anything you can do with switch statement you can do with if...elses.
And in some cases, if your values are packed closely enough, you can use an array of funcion pointers. (Or better yet, just a simple jump table, but I don't know how that'd work in C. What's the type of a label?)
If anyone does any improvements to switch, it needs ranges more than strings. I mean really:
case 7: case 8: case 9: case 10: case 11: -- or something like: -- case (7,11):I'll stick to good ol' C-cross-cross
Reference counting is the worst of all garbage collection algorithms, IMO. It can leave cyclic data structures left behind (not to mention costs of incrementing/decrementing a counter.. and the storage of the counter in each object/block of memory used). Anyone considering doing GC should definately look at all the work which has been done w/ Lisp, Scheme, and the various other languages which have garbage collection built into the language design. Generational collectors (using something like mark-and-sweep or stop-and-copy methods) are probably some of the best as of now. There are also incremental (real-time) garbage collectors. On top of that are the differences of conservative and exact collectors (where conservative misses a few objects here and there and exact gets every object).
;-)
Ideally the programmer would never have to think about memory (and generally resource) usage, but just program design. Which is probably why Lisp is looking much nicer to me these days.
Dijkstra Considered Dead
Sun made new one (Java)
Microsoft too (c$ oups, sorry c#)
Why not using existing ones like Objective-C which is, like C++, based on C with OO but, unlike C++, have real dynamic capacities.
It support Garbage collector, it has several (good) libraries like GNUstep ones, it is more flexible (for exemple, you don't have to recompile all your projects and librairies when adding a "Virtual" method).There's multiple implementation (gcc support it, for exemple). It's possible to make an interpretor if you dislike compilation (NeXT did this kind of thing for WebObjects).
So, why "inventing" a new language ?From the same dictionary:
1) "!", ASCII code 33.
Common names: bang; pling; excl; shriek; exclamation mark; factorial; not; exclam; smash; cuss; boing; yell; wow; hey; wham; eureka; soldier; spark-spot.
pling pling, you're dead!
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
- Branch prediction: Modern CPUs (UltraSparc II, etc.) have two types of branch instruction. First one is attributed that in most cases the code continues after the instruction, and the other one is attributed that in most cases the code jumps
to a different address. The GNU C has __attribute__(branch) or something like
that. I think there should be two variants
of the if statement.
- Memory barrier: The ability to finish the
previous store instructions, and serialize WRT write reordering and other CPUs.
And one more thing: IMHO the ability to use the preprocessor is worth the additional complexity. And it even allows to extend the language somewhat (conditional compiles, etc).-Yenya
--
While Linux is larger than Emacs, at least Linux has the excuse that it has to be. --Linus
I have become extremely interested in ocaml for numerical analysis lately.
However, I thought I read someplace that ocaml doesn't have generics. Is this true? I really don't know (and couldn't find the answer after a quick read of the site).
The G'Caml web site is http://pauillac.inria.fr/~furuse/generics/
Actually, there was a successor to Forth called Fifth. Forth with OO extensions, IIRC.
Fith is a spoken language with a stack grammar. It's reported to be very hard for humans to speak in real time because humans seem to have a register architecture.
The true successor to forth is PostScript.
Will I retire or break 10K?
I suspect you haven't actually done much programing. It would be interesting for you to name some of these 'redundant funtions' you are talking about.
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
- no templates
- no fixed size for int, double, etc (a.k.a., non-portable code will result).
- no deterministic finalization (a.k.a. scoped object destruction)
- no pre-processor (although it is easy enough to roll your own on top of it, as I do with javac)
- no first class callback mechanism like C#'s delegates (don't get me started with interfaces - they do not have one quarter the flexibility of function pointers).
It's a good start however.
I'm tired of new OO languages that don't let me ask SomeClass.respondsToMethod("SomeMethod", someArgTypes).
And also still suffers fragile base class issues in spades.
In D, all non-static member functions are virtual. This may sound inefficient, but since the D compiler knows all of the class heirarchy when generating code, all functions that are not overridden can be optimized to be non-virtual. In fact, since C++ programmers tend to "when in doubt, make it virtual", the D way of "make it virtual unless we can prove it can be made non-virtual" results on average much more direct function calls. It also results in fewer bugs caused by not declaring a function virtual that gets overridden.
This is great if you're compiling an entire system, but if you're shipping or using someone else's library, it's less good. Even worse if you plan on loading anything dynamically. Java does a great job of this - but people haven't figured out how to use it yet. ObjC and the Foundation&AppKit Frameworks are great examples.
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.
No word as to whether or not it would be a good idea to be able to link to c++ modules, just a quick brush off that the c++ object spec is too complicated.
So it's just a compiled Java?
I'm not a great fan of OO languages (just how much syntax do you really need?), but it would be wonderful if somebody would get rid of the pointless `new' keyword for object construction, add algebraic datatypes and pattern matching, and add closures as first class objects.
But when you use genuinely modern declarative languages (Mercury, OCaml, Haskell, ...) there's no real incentive to go back. It's like good hi-fi.
Java isn't an option because it requires a VM (usually) and can't using the standard C APIs. On Windows you need the real APIs or you are in a "play" language. So D looks drop-i ready to replace C++ and that's fine with me.
Maybe you should wait for you're 13 to start commenting on Slashdot, you illiterate piece of shit.
I'm not a Java zealot at all, au contraire:
- I hate the speed of Java and the number of bugs in the API.
- I liked Swing API but its slowness was unbearable.
But you're overlooking simple explanation why the Java UI is so slow:
1) Java can be as fast as C++: I doubt it very much (except for two linersw) but anyway this require "clever" programming IMHO.
So maybe there haven't been enough effort spent on trying to speed Java's UI..
2) the native compiled code can use the hardware acceleration of the video card: a big help!
Of course Java cannot (could not?) use hardware acceleration..
I heard that the future release Java 1.4 will be able to use some hardware acceleration, maybe it'll help..
For those who ask, no I haven't tested the beta of Java 1.4, "stable" Java librairies are (were?) buggy enough that I won't bother trying a beta.
Why can we not do this in C or C++.... Think of what we might be able to do if embedding could happen..
I guess also think of the virii that would spread due to this ability.
"ooo, ooooh... visit my site for great pron..." and then Wham!
I guess there's two sides to every coin!
Linuxrunner
www.slightlycrewed.com - Because aren't we all?
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/
There is already a ridiculous number of programming languages out there to do just about anything imaginable.
Before I can be convinced to adopt another language, what I really want to know is why we absolutely need this language, and what it has to offer that other languages do not, and if it will be an openly-specified language accepted by academia and all major standards bodies.
Yeah, the new syntax breaks legacy C code. Your existing libraries won't compile. If the compiler allows dual mode, it will be even more confusing. How productive is that?
Java took almost five years to get more or less a complete framework and library functions. OK, this D language is more C-like, but you'll still need to wait at least one year.
¦ ©® ±
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.
We have a language that automatically documents itself! It's called COBOL! Write a thesis essay while trying to make a simple file sort. Woo!
--
Promoting critical thinking since 1994.
Of course it's too much to ask for. You're asking the impossible.
The thing is, you can focus on certain areas of a language, make them better (by whatever definition), but you sacrifice elsewhere to do it. Java sacrifices performance for safety and ease of use. C++ does the opposite. Neither will ever equal the other on its greatest strengths.
For example, you want a program that's easy to port across platforms, with just a recompile. However, to do that, you need to use features that are in the least common denominator only. You can't take advantage of any extra power offered by a given platform, because it wouldn't compile just like that on another. This is one of the biggest stumbling blocks a language such as Java must face.
The alternative is to write an emulation of every feature from every platform on every other platform that does not support it. Aside from the fact that this may be far from the most efficient solution to a given problem on the second platform -- perhaps, given different strong points, another algorithm is simply more appropriate -- it's also impossible in practice.
As another example, you want predictable behaviour, yet also high performance. You can't have both. Predictable behaviour => many tests to keep things safe. High performance => minimal tests to keep things safe, because tests take time. Are you going to check the result of every floating point calculation to make sure you're not about to divide by zero? Oops, there goes your "high performance" maths app.
There can never be a single, ultimate language. As I've noted here before, you simply need more than one tool in the box. There may be a best tool for any given job done by any given person, but that's a different matter.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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
If Forth is so great, why didn't you write your Pure FTP daemon in Forth instead of C?
cpeterso
Aaaaagh! Mine eyes! I cannot see! It burns us!
"I'm an old-fashioned type of guy. I worship the Sun and Moon as gods. And fear them."
I am not very familiar with Java, but is this not the same:
// try
// do something
// catch
// finally
try {
try {
} catch(A a) {
throw;
}
} catch(...) {
throw;
}
I think the neatness and power of java (when not used to create applets) is the standard class library.
It will be interesting to see what develops of this language and hopefully standard (cross platform?) class library.
Oops, this should be:
short b = 0xa000;
long a = b;
Sometimes it's best to just let stupid people be stupid.
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.
You're obviously not one of the ones that has had to write components and are speaking on behalf of a group that you have no information on.
:P
I didn't say it was impossible to do anything with objects descended from the VCL, it's just hard to do certain things that can be very important. That makes something sucky.
Also, I haven't seen too many good 3rd party components that have been derived from the standard VCL components.
I was very disappointed to find out that Visual BASIC was just a fancy colorful editor for a very syntax and typing intensive code.
Wouldn't it be great to just layout the program on a giant whiteboard with drag'n'drop objects? Connect them with lines, right click on the line and set parameters, etc.
Disclaimer: I'm a civil engineer. I've never written code in C. I know FORTRAN and I currently write Visual BASIC code for relatively simple MS Access databases. My wife programs in C and Perl.
> an industrious C++ programmer could... > use Object types instead of templating People have already tried to do this. However, there is a serious problem with this approach: Other people's classes wont extend your Object. Of course, you could easily get around that by misuse of multiple inheritance, so that class Foo; class Bar : public Foo; are supplemented by class FooObj : public Object, public Foo; class BarObj : public FooObj, public Bar; With an alternative like this, no wonder templates are so popular in C++! They are somewhat redundant in a language with a singly-rooted hierarchy, but I'd like to see them added to Java anyway, mainly because I hate writing code like int n = ((Number) myList.remove(0)).intValue();
Java machine
Nitpicky, but java, lacking namespaces and having packages, doesn't really need the scope operator. It has ".". This language, also lacking namespaces, would presumably also not have the scope operator. Java could use typedefs though. Have y'ever seen Jasmin (write asm to java vm, generate valid byte code output), good for your point.
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
The Java specification allowed the single case of operator overloading for + to concatenate two Strings for simplicity, especially for debugging purposes. It isn't that the + operator is inefficient, it is that the String object on which it operates are immutable.
Concatenating two Strings actually constructs StringBuffer objects out of the original String, appends the second String, and then (finally) calls the toString() method on the resultant StringBuffer object.
In order to handle this more efficiently, it is not the + operator that needs modifying; the String object would have to be modified so that it were no longer immutable, and this would have serious efficiency issues.
If you need to make efficient use of String concatenation in an algorithm then you should have *always* used a StringBuffer from the start - Strings just aren't designed for it.
alternatively, etching the code for a Java VM into hardware in this same way would not make it any faster so the whole discussion of virtual machine vs machine would still not be meaningful.
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/
Syntax error in 'Why would we need another language?.cobol' : lowercase letters detected.
[alk]
Are you forgetting that Java code *is* compiled natively? (in memory when the app* is executed) This is why Java can be performant on the server-side -- there are start-up costs associated with this, but a good JIT compiler (Sun's Server HotSpot compiler is good) can identify optimizations *at run time* and compile even faster code on the fly....
A lot of programmers never experienced lisp. That's why!
Some of us are looking for Java--. Not compiling to bytecode is a _good_ thing, because the program will run faster. I got the impression from the spec that D is supposed to be as fast (at least) as C++, something that java will never do.
Also, while java's "extensive standard API" does do just about everything for you, which is nice, it is also bloated, confusing, sometimes self-contradictory (ie try iterating over the keys vs values of a Hashtable... last I checked they use completely different APIs), and annoying to use.
But if it can be done, why hasn't it been done already, hmm?
There are thinkers and doers, and very few who are both.
The principle ideas behind designing/developing D are good. They represent years of experience programming and implementing compilers. I don't doubt that Walter Bright will release D one day. He has the obvious technical expertise to do so.
But if you build it, will they come?
As good as those ideas are, we must remember: the design goals for D represents Mr Bright's many years of experience developing compilers, and discipline/opinions/bias formulated from working in those languages.
Experience and discipline.
Exactly. You don't build better software by using a better language. You build better software by using better programmers. Building robust software with maintainable code isn't achieved by constraining the features of the language and adding features which make the programmer's life easier. There are plenty of coders out there with half-assed ideas about what "good" code is, coupled with half-hearted attempts to write it.
Like a Dead Sea Scroll...
D is doomed to become yet another one of those obscure languages. Certainly, as others have pointed out, there's no marketing muscle or drool-factor behind D. There will also be management resistance to a new language (i.e., for medium-to-large scale applications, on the order of a million lines of code, you don't introduce additional risk into a project by using a new language). And from what I've read, there's a lack of compelling technical reasons to switch, since much is either found in C++, or can be added to it (e.g., STL).
My thoughts exactly. Do we want a guy who doesn't even know the history of the language designing the next level?
Although if he was worried they'd run out of names, he could have called it "--P."
The problem with this idea is that the software becomes too much of a black box. Since it was created using mutations and natural selection, we might not understand how it works. That is acceptable if the code was 100% bug free, but what if it's not? What if a patch is needed? How would you insert that into the code when you don't even know how it works?
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?
Once you've implemented it in hardware (such as an x86 processor), wouldn't it just be a "machine", rather than a "virtual machine"?
Alan
IIRC i used "D" as the name for an object persistency layer C++ compiler front end i wrote around 1994 for diploma thesis. Honouring the basic fundamentals of our great human society, I should find a lawyer and sue the hell out of them ;-)
Excess verbiage not only takes more time to type in, but more importantly, it opens more possibility for bugs.
So does barely readable "line-noise" such as sed code and uncommented Perl code. So does any code that doesn't have comments briefly describing what it does. Good code is largely self-documenting.
The goal is to write in the most abstract, most succinct possible way.
You mean like Mel[?]? You have to leave an opening for seq^H^H^Hrevisions to your code.
Will I retire or break 10K?
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 what is meant by 'orthogonality'. If you did not understand the concept from your computer language course, think of it as the same concept from your linear algebra course.
Hmm...
C pound? i thought it was C sharp :)
Every year, javamonkies whine: "Java was slow last year, but its fast today!" and then point to some dubious claim on the MARKETING section of sun's web page about how Java(TM) Platform Technology is 130x faster than Legacy C++ Technology.
And the real world laughs. People use Java because it does a decent job keeping morons out of trouble, meaning you can hire cheaper programmers with less skills. They don't use it because its fast.
# = "she"
! = "bang"
Q.E.D.
"Even if you're on the right track, you'll get run over if you just sit there" - Will Rogers
I was reading about an experimental IBM JVM that turned off bounds-checking and got a huge performance increase.
Having read the link, I am surprised he does not call it Delphi; after all a lot of what he is on about is already implemented in Delphi/Kylix plus readability :-)
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.
Someone posted earlier that the C language specification is 500 pages, and C++'s is 750. In addition to all the syntax of C, there are numerous reqired library functions for hosted environments. There is a macro processor. You eventually have to link the code, too. I guess you are right that a C compiler would be easier to implement than a java or C++ compiler, but I would hardly call it "fairly easy." Note that a cross compiler is not a program wich translates source code from one programming language to another. A cross compiler is a program or group of programs which converts source code into an executable for a platform different from the one the program is running on. For example, gcc can be built on linux as a cross compiler for DOS. To make it work you have to use the djgpp libraries. Gcc can cross-compile to many platforms. The above is the only one I have personally done. K & R 2 lists 32 reserved words in C. I think C99 may have added one or more additional key words. I doubt that any ANSI compliant C++ compiler ever was made that used C as an intermediate step. If there was such a beast, it must have been an abomination. Are you sure you are a programmer? MM --
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
> 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
A search on Google reveals that you can find a copy of this paper online via ResearchIndex.
rmathew.com
Maybe Vampire Hunter-D should have called it 'G'
then we could have a Gi-Had optimizer.
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
I agree with you about enums, but there are many C++ features I miss more. (Stack allocated objects and destructors, templates, the STL...)
Still, Java is a great tool for some problems.
I think he meant this, which is something I've thought about off and on since starting Java programming a year ago - What if a processor, and entire hardware platform, were developed whose "native code" was Java byte code.
That is, instead of JIT compiling, microcode translations, or other tricks, the CPU operated directly on Java byte code with no translation of any kind.
"This is Zombo Com, and welcome to you who have come to Zombo Com" - www.zombo.com
The real reason? He couldn't get it to work in his compiler..
Java runs slow when its not executed with a JIT. When it is, the performance is far from slow.
Because : 1) a good language will separate the algorithms from the implementations; such a language is C++ (only), due to template support 2) truly component-ware programming comes from multiple-inheritance and combining classes together. 3) operator overloading is a major plus for programs; I am in a development house that develops a military application which uses a lot of 3d calculations; we have made special classes which use operator overloading, so adding two CVector classes is vector1 + vector2 and not some other function. And what is operator overloading really? it is another way to express a function by putting the function name in a different position: for example, instead of writing +(a, b) we write a + b... 4) garbage collection is not good for any application where timings are critical It has some good points though, namely the extraction of an interface from the sources...
I'm sorry. I don't understand what you mean. Sure, there are quite a few green programmers. Are they inferior because they have not learned to take the great intellectual leaps a seasoned coder does on a daily basis? Experience starts somewhere, even if you have to take a class.
As far as languages being too easy, hey, I'm all for it! Tools should not be complicated in order to exclude non-experts. The more a language stays out of my way and lets me concentrate on the problem or algorithm at hand, the better. I believe languages still have a way to go. They definitely have not passed a point at which they are too easy. Show me the language, I'll contrive a hideous example of bad code. I'll can also strive to code beauty, itself, independent of the simplicity of the language.
It would probably shock you to know I prefer Perl and Python to C anyday. And before you label me as ignorant and unwashed, yes, I do understand assembly and C. In fact I code for microcontroller projects as a hobby.
-- Posted from my parent's basement
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.
C, in roman numerals, is 100. # is an abbreviation for pound. Thus the proper name for C# is the 100 pound language.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
http://home.earthlink.net/~descubes/C--
-- v --
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 ...
(begin rant)
... why doesn't Java have them? Yeah, I know you can make a class filled with "static final", but it just isn't the same, or is it?
Is it just me, or is JAVA simply too verbose to do simple things like open a file and read lines of text?
Also, I love enums
Then I tried a Swing GUI on my old P166. Completely unusable! Yet QT, GTK+, etc. worked just fine on that machine.
(disclaimer: I'm a professional C programmer who casually dabbles in Java and C++)
(end rant)
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.
I thought that was the *problem*. :)
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
Elizabeth Rather (of Forth Inc.) mentioned once on comp.lang.forth that she encountered two groups, both of which used Forth, but for radically different things. It was something like this:
One claimed "It's great for controlling telescopes and other small obscure things, but we'd wouldn't dream on it for anything big."
The other group claimed, "It's wonderful for our large project, but no way we'd ever use this for anything like a machinery control system."
Forth is what one makes it, and what one believes it to be.
I suspect the real reason Forth is not popular is that it is not popular. Other languages are taught in schools or have a certain 'coolness' to them (C, Java, Perl). As for the practicality, Forth was not originally a corporate development nor was it was it a university project. It was just Chuck Moore getting a real-world problem solved.
The RPN scares some people (who should know better, really), and there is the false idea that there are no variables, just stack. Well, anyone who has done assembly (or uses an HP calculator..) has dealt with RPN. And the stack is a nice quick tool, but variables are there for the big work. The one real issue is that with Forth there is the assumption that the Programmer is God, and God knows WTH he is doing. So the compiler doesn't whine about every little thing, but lets you shoot yourself in the foot. The assumption is that you meant to do that, or you would not have done that.
Sure badly written and undocumented Forth is 'write-only' and takes a great effort to decipher. Other languages can be jsut as bad, if one writes poorly. But a development group can agree on a few coding conventions and get along and generate readable Forth.
A 100,000 line project would need to be well planned and agreed upon... but is that not true for any 100,000 line project in any language?
One interesting comment I've seen (likely in Starting Forth) is something to the effect of "You don't solve the problem with Forth. You find out what language would make the solution trivial, and write that language with Forth."
An admission: I do Forth for a living, for now. It has been decreed by those who do not actually program that new development will be in C. Why? Because "it's easy to find a C programmer." So I'll end up working in C soon. (And they have as much trouble finding _good_ C programmers as finding _good_ Forth programmers.)
I don't subscribe to RMS's GNUtopian vision.
what you're looking for is called jython
there's no place like ~
And so, I think a worthwhile avenue, in terms of programming language development, would be to get rid of C++ templates, and the C preprocessor, and replace them both with a suitably-powerful Lisp-style macro system.
Easier said than done, of course!
A development which is somewhat in the spirit of a powerful Lisp-sytle macro system is Open C++. I haven't tried to use it for anything, though. As compared to Lisp, the problem is that it is very obtuse (due to the messy nature of C++ syntax compared with Lisp). But it does let you do symbolic-level macro programming in C++.
Exactly. In other words, Lisp macros let you program with fewer keystrokes (ultimately). That makes them a Good Thing.S**t, you are old!
Besides everyone knows triple ROT13 (aka 3ROT13) is way more secure than ROT13.
Lee
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.)
There is no contradiction, only ignorance. Why do people directly relate: "Java code run just as fast as native compiled C or C++" to "Java UI performance?" Granted, the speed of code can be limiting factory if it is too slow. But remember Amadhal's law, that system performance can be limited by more than one factors. In reality, the speed of the Java code is not the bottlenck here, its Swing's interaction with the graphics card. Swing does not utilize much hardware acceleration, which is desperately needed. Take a look at Swing's implementation on MacOSX for Swing "done right." They layer Swing over a hardware accelerated 2D layer. JDK 1.4 is also supposed to fix many Swing performance problems, but we will have to wait and see. Its one of the reasons why Java's performance is ok on server's but not on the client. The JIT compiler has matured enough, but the UI libraries have not - and "cross platform" has a lot to do with this.
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.
The author does a good job of getting rid of a lot of unnecessary crap characteristic to that big POS that is C++. Just about anything that contributes to the demise of this white elephant is welcome.
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.
rofl, you wouldn't use "templates," or "other OOP" features.
rofl
Parametric polymorphism is more efficient and type safe than runtime type manipulation. It's also not considered an OO concept, though C++ plodges it into their object system.
I can't say I give two shits what you'd use it for, since you were clearly meant to be a liberal arts fudgepacker, and not a computer scientist.
Like some toothless mechanic trying to tell a group of mechanical engineers how to build cars.
The real reason we call it square is: "Most of the public don't understand what hash (#) means."
Seriously. Straight up. That's the reason. If you don't believe me, try explaining it to some poor old lady who just can't follow you. It looks like this:
"So then you press the hash key."
"The Hash key?"
"Yeah, the one that looks like a gate."
"I don't know which one you mean"
"It looks like a noughts & crosses board."
"Eh?"
"Don't worry about it, just press the square key instead"
Nice people, it's just either they sound like that, or they sound like: "Heehee, the phone guy said hash, y'know - HASH, like, wow dude".
I don't think I'm very happy. I always fall asleep to the sound of my own screams.
Way to miss the joke, dumbass. Did you have fun putting in all those links?
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?
Because he's not a moron like yourself. AYUK AYUK!
Langauge X is better, it runs on average about 3 times faster than slow-ass langauge Y.
Langauge X sucks, it's not incredibly portable or as easy to use as Langauge Y, and speed is becoming less important as time marches on.
But what about LNOU (Langauge No One Uses) it's got both the speed of Langauge X and the ease and portability of Langauge Y.
bicker
whine
Seriously, I'm mostly playing arround with C++ right now (and I love it) but Java, Python, Perl, and most of the other langauges out there ALL have their uses. Yes, all of them. D will be no different, it will have a few great features that supporters will throw in the oppositions face and a few downsides that the opposition will exaggerate. I gave the specification a look over and it seems to me that D is basically what C++ would be if the designers hadn't given a damn about backwards compatability with C, except they are removing a few usefull (in my opinion) features of C++ and either replacing them or dropping them completely. The specification is still rough, but overall D looks like a decent langauge, one made to work well rather than confor to some ideal (kinda like C++, again IMO). The guy is very straight forward about what D should not be used for and gives examples of some things it would be good at.
I guess what the whole thing comes down to is "How Good Will It Be". If the answer doesn't end up being "Wow, I Can't Live Without It" then D will fail even if it's much better than other, older solutions, simply because no one wants to port old code or learn a newer langauge when the old one still works fine. That's the reason why many of the newer langauges don't have the following their creators think they should (and they may be right), they're simply not worth the time or effort it would take to learn them and port them. Unless D is absolutely incredible I know I'll be sticking with C++. Why? Because C++ simply WORKS for what I'm doing right now, and there is no reason to all of my code or learn yet another langauge when the one I'm using is fast and easy enough to get the job done, and C++ is already a proven langauge (as is C), as widely used as it is....it's not going anywhere.
"
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.)
That's why I made a distinction between Java-the-language and Java-the-environment. My point is that even if you natively compile Java and fix some of the runtime environment issues, it still wouldn't be appropriate as a general-purpose language, particularly for system programming.
Sometimes it's best to just let stupid people be stupid.
If we listened to people like you than your favorite beloved Java would not exist. Nor would perl, python, Tcl, Eiffel. There is nothing wrong with new ideas, even if the language is not embraced by the community. So please continue beating off to your Java magazines.
- First of all, it has a completely different syntax than the traditional C-like languages. People just don't have time to glean the idiosyncracies from the language, they are too busy deciphering chip specs.
- Secondly, it is much less structured than C. So what? Well, when you have 10 very individualistic ppl working on a C program, you get an obfuscated mess. That's our reality. When those ppl program in Forth, it ends up twice as obfuscated!
- Last, the RPL notation really bothers most ppl, b/c ppl hate to truly think about what they are doing. They want the compiler to complain at them about their mistakes. So you change a line, compile, change a line, compile, repeat. That doesn't work in Forth, it's much closer to assembly in that way. It pretty much crunches everything down to byte-codes no matter what you do.
Forth love if honk thenWhen we have COBOL, the only language you would ever need to know.
Identifcation Division.
Environment Division.
Data Division.
Working-Storage Section.
01 TheOnlyLanguageYoullEverNeed pic x(30) value spaces.
01 ArgumentSettled pic x(01).
Procedure Division.
Move 'COBOL' to TheOnlyLanguageYoullEverNeed
Move 'Y' to ArgumentSettled.
Stop Run.
I like that someone (besides microsoft) is trying to write a be all end all language. I keep hearing about how java is the right tool for this job and c++ is the right tool for that job and objective-c is the right tool for that one (objC is my favorite tool by the way, to be fair though I don't know java or c++). I realize that these statements are true but it seems to me that they shouldn't be that way.
I think C is an example of a really well designed language that can perform a variety of functions, I mean its a language that is used for both kernels, word processors, games, whatever. Now that C is getting kind of old and is missing a lot of feature we want a bunch of language like c++, java, C#, and objective C have come up. Those languages are all object oriented to a certain extent and all offer features that make them very useful in some situations and useless in others. I only can code in one of the listed languages so I wont list the pros and cons as I would get some wrong and inspire flames from programmers who use those languages.
My point is that a language (maybe not D) that could implement all the features that a programmer would need for any kind of serious large scale program is needed. Further more that language needs to have compilers for both machine language and bytecode. Lastly the machine code, at least when compiled, needs to be almost as fast as C (which was designed to be almost as fast as assembler). I could list a million things that I think the language would need but you get the idea.
We need a language that is general purpose yet can be used for any specific problem. A language which is featuresk yet very simple. We need a language that is all these impossible things the way C is.
I don't think D is all of the things we need, not yet anyway, but it is a good expression of what as a community programmers need, a common language.
Whoever these guys are, they don't understand C++ programming very well.
I see this all the time, programmers who don't know all of the cool C++ tricks that could save them development/debugging time go on rants about how useless all of the features of C++ are.
For instance they got rid of operator overloading saying:
"The main applications for operator overloading seem to be implementing a complex floating point type, a string class, and smart pointers."
Uhm, how unimaginative. Some other uses for operator overloading I've implemented:
1. Objects that act like primitive types, but use the interlocked instructions that are necessary for multi-processor communication.
2. Debug-build only types (replaced by primitive types in the release build) that act like numbers, pointers or arrays, but do arbitrarily complex contract testing for algorithm.
For example, a numeric variable that in a range from a to b, who's value mod c must always be d. Of course flexible types like are best implemented with templates which they also left out.
3. All kinds of mathematical analysis. Just because these guys are mathematical ignorami who never use mathematical objects more advanced than complex numbers doesn't mean the rest of us are so limited. For example when I was doing some sound/filter design I wanted to analyze the effect that a numerical algorithm had on a symbolic representation of my problem, so I wrote a class of objects that formed a numeric ring (you can add, subtract and multiply) but were actually polynomials in hundreds of varibles. I plugged them into my numerical code instead of using the regular "double" type and got an instant symbolic answer. Do that in "D"!
4. Objects that act like normal primitive numeric types but automatically update the gui display when they change valuue. "Score += 100;" Dah!
I could go on and on and on about the very important tricks that the various omissions from "D" make impossible, but the main point would be lost. The main point is that C++, for all it's problems omissions has some very very powerful general purpose tools that "D" omits. "D"'s language designers seem to be inexperienced and unimaginative. Sorry. No one is going to replace an incomplete language with another one that's even more incomplete just because it claims to be a successor.
I predict (and hope) that "D" will sink without a trace.
Rocky J. Squirrel
Code-within HTML documenation is a good idea, and not a new one either. It is called Literate Programming. except usually the code is within TeX with a system called CWEB.
I believe your idea of sticking the code and documentation into XML is best however. Then, your code can live in a real database (instead of a CVS repository) and you could do much more powerful manipulations and queries of your code and versions. I use CVS all the time, but it is limited because it really does not know a language's structure.
It is the year 2001. Why do we still write code in plain text files?
ipv6 is my vpn
There's easy way to do templates.
// compile time use of 1st variable
// etc..
:: :-)
Instead of
template<class T, class K>
class A { };
template<class T>
class A<T,int> { };
A<float,int> aobj;
can always do like this:
class A_T_K { class T; class K; };
class A_T_int { class T; type int; };
A_float_int aobj;
Templates are all about dividing names into symbols and doing pattern matching over them.
Thus template syntax should be part of names. A few special characters like "_" to divide names into separate symbols could be used for all polymorphism.
Templated variable names would be neat too:
int a_int; <-- collection of integer variables
a_0 = 12;
a_1 = 10;
a_2 = 20;
a_3 = 30;
Everything that has a name can be grouped together
and it is possible to handle group of them in one declaration; like templates do.
Think of gtk+'s naming for runtime polymorphism:
gtk_widget_show();
gtk_widget_hide();
gtk_dialog_show();
gtk_dialog_hide();
etc..
Similar thing could be used for all polymorphism,
templates included.
(Renaming features like C++ typedefs are essential for polymorphism. Who would want to use std::string if its name was std::basic_string<foo,bar,zoo>...) (notice how authors of C++ noticed the proper naming for namespaces and
x86 has been around for so long that i don't fear my code could be outdated in short term. Anyway I quite agree with you. I think that asm is *absolutely* necessary to fix your bugs and optimize your code. Not only to use inline asm (which is really interesting) but also to learn how your high level language source is assembled. ASM lets u understand the inner workings of an OS and can't be compared to something like java or even ansi c: They offer a variety of APIs which hide the truth of the platform you're developing on. But that's why people use them of course...
The point is, it's not perceptible for most applications. We just switched from using J++ (native C/C++) to NetBeans (100% Java), and on a decent machine (I've just got an 850MHz P///) there's really no difference. On some of the slower machines here (400MHz PIIs), there's a sub-second delay on some operations, but it's not enough to be distracting. I wouldn't use it for real-time stuff, but then I wouldn't use C++ for real time either (unless I didn't use any templates or any of the other nice OOP features, and then it's basically just C anyway).
Just junk food for thought...
D = Java + structures - (class library+remote code)
The overview talks about how C/C++ has become overloaded and needs to be simplified. Isn't that the same reasoning that lead to Java. how different will this be from just using Java? (syntax aside, just object orientation and capable architecture).
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
First their was BCPL, then B, then C. Logically the next language in this family would be P.
My 2 cents is this - everyone up to know has been talking about Swing, which albeit much more complete and useful than AWT, has the problem of speed due to being written entirely in Java.
An AWT UI uses native peer components - it's basically Java wrappers around native GUI objects. Personally, I'm an advocated of using pure AWT in my applications and I've developed quite a library of my own AWT components which fill in some of the functionality that's missing.
A complex PURE AWT gui is no slower than a native gui, minus startup overhead.
Oh yeah, a comment on that, too. Restart your machine. Start up a Java app. It takes a few seconds. Quit it and restart it. It's almost as fast as native equivalent the second time around as the VM and related stuffs are already cached. If you do alot of Java devel and run alot of Java apps, the startup overhead is negligable at best.
"This is Zombo Com, and welcome to you who have come to Zombo Com" - www.zombo.com
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
So what you're saying is that it's undeniably slower. It may not be noticeably slower to the user, but it will be slower in cpu cycles.
Everybody listen up: When saying that Java is slow, qualify that statement thus:
"Java is slow, when compared to natively compiled software."
Is that fair to say, mister Convince Me ?
BTW, PHB likes that. Now he goes around saying: "Java is slow, java is slow". He never qualifies his statement (or he wouldn't be a PBH).
"Piter, too, is dead."
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.
This comment struck me as interesting... It's frustrating that a language with 750 pages of specification [referring to C++] cannot do basic things like resizing arrays. He shows his ignorance of the STL here... hasn't he ever heard of vector? It's been part of the draft standard for a number of years now.
Additionally, about the features of C++ he wants to drop... Not that I necessarily think that C++ is the perfect language (far from it, but at least the D&E of C++ explains a lot about why it is the way it is), but the guy's rationale for excluding certain features is just plain ridiculous. Let's look at a couple of them:
Multiple inheritance. It's a complex feature of dubious value. It's very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it. Translation: it's too hard for me to write, and I never had much of a use for it anyways, so I can't imagine why anyone else would really need it. Heck, even Java supports a form of multiple inheritance by using interfaces.
Operator overloading. The main applications for operator overloading seem to be implementing a complex floating point type, a string class, and smart pointers. Translation: I've never heard of matrices, radicals, rational numbers, or symbolic algebra, all of which are completely _valid_ reasons to implement operator overloading [there are probably at least a dozen others, but you get the idea]. Didn't he say that his language was good for numerical programmers? How can that be if you are overlooking something like this?
Then there's his so-called "features" section of the page where goes on about such things like natived string support, briefly commenting about C++, he shows his ignorance of the fact that C++ has had full fledged string support as a _standard library_ for a number of years now.
What kind of programming language considers it an _error_ to have unreferenced variables in a local frame? It's only a maintenance nightmare if the people who wrote the code didn't choose intuitive names for the variables. Second of all, sometimes portions of code, not necessarily whole functions, are temporarily commented out so that specific features can be tested more easily. Having to also comment out the now unused variable declarations as well would be a far bigger maintenance hassle than trying to identify whether or not a variable is used. Besides, in maintenance, the concentration is on the variables that _are_ being used in the code fragments that you are maintaining... why should you worry about variables that _aren't_ used?
What's up with this? defined behavior for NaN's and infinities. Is he out of his mind? The whole point of those values is that they _ARE_ undefined. If one imposes a uniform mechanisms for handling these "values", then invariably, well meaning programmers will exploit it, and depend on those mechanisms. The result will be code that is obfuscated by depending on the results of something which should, by mathematical definition, be _UN_defined.
One final thing: I believe that it is a mistake to make one language look too much like another that one has no intent of being compatible with. The problem with having syntax being too similar is that when looking at a printout of the code, one cannot necessarily tell at a glance exactly which programming language is being used. This ambiguity can be the source of some confusion when the project specification included portions written in several different programming languages (since we should know that no single programming language will be the best one to use for all types of tasks). Printouts of code are almost invariably needed during code reviews, so one will not be able to rely on conveniences such as filename extension to convey that information.
</flame>
I did find one thing I liked about the language, btw: the bit datatype. Too bad the rest of the language sucks.
As any real musician knows, C# and Db are only tonally equivalent; they have expressly different meanings in music theory. On top of that, players of stringed instruments (such as violas and 'cellos) usually will play the Db a few cents higher than a C# as a stylistic device. So no, they aren't equivalent, once you go beyond your elementary-school-level music training.
Double oops!! Too much talk about C++ today. How about "System.out.println()".
Sometimes it's best to just let stupid people be stupid.
I so strongly agree with the first comment. The whole point of programming is to embody a solution to a problem in a language the computer can understand. Writing a language to conform to "ease of compilation" is regressive. If we did that we'd all still be coding assembler, OS's would all be command line based, and computers would only be used in scientific institutions by a select few people who can master them.
As for your complaint about windows. I have the misfortune of writing windows code occasionally, and it's not that bad. If you use the ClassWizzard and Resource Designer of MSDev, then all the skeleton code is written for you. I downloaded a Resize-Manager library that allowed me to make my dialogs/windows fully resize-friendly in another 15 lines of code.
The problem is that you use API calls. Use MFC classes, MUCH EASIER. If you are coding for windows, you might as well take advantage of every ease of use feature you can (given you know your code is not going to be cross-platform).
Otherwise, use QT. It's really no better other than being cross platform.
five fingers make a fist amalgamate and resist
>This is probably what everybody said about C++
/new/ language (without a working standard library besided the POSIX C API) there's just way to much time and development overhead in turning your projects to a new language.
> when they were using C.
Probably, but remember that C++ is as close to 100% backwards compatible with C as you can possibly get while it added a lot of useful features to the core C languages such as classes, inheritance, templates and inline functions.
Considering that this is a
Besides, if people make the transition to D, I guess most of them will come from C++ and not from C, thus rendering the C backwards compatibility layer useless to those developers and projects.
is also the author of "Empire". For those of you old enough to remember, this was a great game. I remember playing on the VAX all weekend during college. It wasn't graphical or real-time, but it was addictive. I keep watching his site hoping someone will port it to the Palm platform, but no one has yet.
Maybe I'm alone in this, but I don't consider the abandonment of the preprocessor good news at all. How exactly should one go about making code that conditionally compiles on different architectures?
Also, D seems complete to snub the idea of seperating interface from implementation. Its specifically tauted that you needed only declare once. Well, I'll say this much, I'd rather *look* at a header file for interface than to dig through the C++ to find the name of a method I need. .h files may be unnecissary but they make good coding much easier and I'm pretty sure they make my programs easier to read.
D's reliance on modules seems also to imply that all of the symbol information is going to be available at compile time. Maybe I'm confused about the Compile-Link interaction, but it sounds as though to get any reasonable error messages at compile time about missing functions/classes the complier will have to look into system libraries!
Just moving through the overview, I don't see why he's surprised that C array's can't be resized. He's right about needing a more complex base class for a stack (Well, sort of ... you can make a fixed size stack in an array without any difficulties) but thats besides the point. In order to make an array resizeable you have construct a more complicated base class anyway! The dynamic array might end up being a linked list or hash table, but even then you probably don't want to base your Stack implementation off of something that heavy. C Array's are simple and fast, but if you want something heavier, then by all means include one of the many excellent Classes already designed for exactly that purpose.
When the author says "Arrays are not first class objects" its not clear why he finds this troubling. Yes, you can deal with an array as a pointer, but you don't have to. Tell your function to expect an array of ints, and magically, thats what they are.
I agree about the need for String support in the language...see String class and C99
What is so clumsy about operator overloading in C++? And are we really so sure that "There really appear to be only three significant uses for operator overloading: string manipulation, complex floating point numbers, and smart pointers" I know that I've overloaded operations for more different reasons than this, and I sort of suspect I'm not alone in this.
Not to even begin to address templates, how can this designer hate them so much that he'll do without, even without a better solution?
Somehow I begin to feel that D is just what this language would get as a grade.
Doesn't FWEB already do this? In arbitrary languages?
See what I've been reading.
There's behavioral inheritance and structural inheritance. Structural inheritance just isn't very necessary, and needing it generally indicates that you did something wrong.
Lack of templates or some equivalent is a real problem. I'd sent Walter some email, but his address seems to be well hidden on that website.
I'd suggest he take a look at Ada Generics, which is part of where C++ templates came from. That might show a way to include the important functionality without too many funny interactions or complexities.
Show me one complex mathmatical program where performance is a consideration that has been implemented in Java. Java is interpreted and will never be able to compete directly with the speed of a C program. Why are there no video games or simulations written in Java? Speed bro.. it ain't there in Java
The great thing about C was the syntax was simple and small; the power was in the standard libs. Smalltalk has a very simple and regular syntax; the power is in the class library. C++ grotesquely expanded the C syntax, making it much harder to read. The problem isn't that the language designers are too focussed on previous languages. It's that they're too focussed on C. They keep making mistakes that were solved 20+ years ago in languages like Smalltalk. For example, constructors in Java. Constructors should be simply another class method. You call a method on the class to get an instance. Instead of: Foobar aFooBar = new Foobar(); it should be: Foobar aFooBar = Foobar.new(); The syntax would be more regular. And this fellow completely misses the point with his insistence that built-in types are not objects. That's what makes Smalltalk so easy to read. Everything is an object that you send messages to. Java's attempt at being half-pregnant when it comes to built-in types makes the language more complex. But the biggest problem with Java is that the classes are not first class objects. The whole reflection-api abortion is a tape-and-baling wire attempt to clean up the mess they made. And inheritance on the class side is basically broken in Java (and C++).
Ciao
----
FB
In fact it also smells a little bit like Oberon.
Agreed.
"Never bullshit a bullshitter" All That Jazz
> Im not sure that Java is a long term sucsessor but it certanly can do anything C can but better.
Riiiight. And what language is Java's VM written in?
Now quite trolling.
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.
As soon as I saw that he got rid of automatic objects, operator overloading, templates and multiple inheritance, I knew that he does not have much knowledge about the use of these features in large projects. Most complaints I hear about C++ usually focus on these items and are made by people who do not fully understand the power and flexibility they provide. They are stuck in the 2-D world of simple datatypes and containers of X.
Automatic objects are absolutely essential for the "resource initialization is acquisition" paradigm. Mutex locks, for example, are trivial to use with this technique. And they work automatically when exceptions are thrown. This is why automatic variables are a pain to implement with exceptions, but with D the programmer will have to clean up manually, writing the code that C++ compilers generate automatically.
Operator overloading is used for a lot more than complex, string and smart pointer objects. The [] operator is used on anything that acts like an array or map. The () operator is essential for nice functors, callbacks and generative programming. Operator overloading and templates has been used to create parsers that allow users to write BNF-style grammars directly in C++. I once used them to easily build ASTs for C expressions.
Which brings us to templates. Templates are a crucial element of C++. So much so that most experts now advise less inheritance and more template specialization. They are used for much more than "container of X." The whole C++ generative programming movement is based upon them. They in turn require things like operator overloading because templates are a weaker form of binding. Rather than conforming to the "isa" relationship, a template argument need only implement the syntactic interface of the operations used in the template.
Templates are so important that even Java is going to get them.
Multiple inheritance does have a performance penalty and certainly is complicated for implementors, but it is incredibly useful. Again, generative programming along with advanced generic programming with design patterns uses MI mixins to add features to objects. See books by Andrei Alexandrescu and Krzysztof Czarnecki and Ulrich Eisenecker for what I'm talking about. This is very cool stuff.
Be very suspicious of languages developed by and for compiler writers.
ahem.. yes, java can be faster doing an fft. http://www.aceshardware.com/Spades/read.php?articl e_id=153
also another article comparing speeds:
http://www.javaworld.com/javaworld/jw-02-1998/jw-0 2-jperf.html
too many people have preconceptions back from the days when the only runtime was a byte code interpretor. Try the latest JIT and you may be surprised..
Windows Forms? Or perhaps you would prefer Delphi's VCL?
[o]_O
Chris Kuivenhoven is a thief, beware
Mooney Guy N4074H
Perhaps when all the "popular" implementations adhere to a same standard that allows code portability?
Or when some good Forth references (not some lost web pages here and there) are published?
IANAL but write like a drunk one.
Burris
Didn't Sun or someone do this already? I remember reading something about it once.
Dijkstra Considered Dead
See, before this morning, I would have derided you as a complete moron. But here I am, writing MFC code trying to do something as simple as providing multiple extension filters for an SDI app, and MFC doesn't let you do it! You can't derive from existing classes to do it, you have to cut and paste and point to your own stuff... Ridiculous
Since you've clearly already 'been there, done that', have you heard of anything that sounds even remotely better (whether you've had a chance to check out yet or not)?
[o]_O
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.
Startup time is almost negligible if you do it frequently? I'm afraid that's a load of hogwash. Yes, it's faster than the first time, but it's still unbelievably slow. Check out the Hello World benchmark in Bagley's language shootout. It just runs a hello world program in each language from a shell script to measure the relative startup times of languages. Java comes in dead last because it's startup time is pathetic.
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
the threaded interpreter. It makes for tight (space-wise) code but is flexible enough to be extended to do amazing stuff. Unfortunately, everyone gets bogged down in all the rpn stuff - I think it mostly sucks to. But you're free to write a completely new forth compiler and call it D or fifth or whatever. In conclusion: The Threaded Interpreter is what makes forth a cool environment.
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.
Many of the "shortcomings" of C++ noted in this spec have already been overcome through the use of features which the author claims are too complicated to be useful. Templates and operator overloading make dynamically sized, first class array types fairly straightforward to implement, and the standard library even provides one. Many programmers have been using various forms of garbage collection for years using the same features. And the vague assertion that C++ is bad at string proessing is completely absurd; C++ not only provides basic string classes (which are easily user-extendable to allow for any locale or character set), but also offers all the features necessary to code your own string library which is as efficient as the hardware allows. There is no perfect string implementation- all have strengths and weaknesses and the ability to pick the right one for the job at hand is crucial. The whole criticism of C++ seems to have ignored that fact that while C++ *is* a fairly large language, the vast majority of the spec is talking about the standard library- a library which can be completely ignored or completely reimplemented by the user.
Certainly there are features that I think would make sense in C++, try-catch-finally and (if a convincing case were made for their usefulness) nonaliased typdef-style constructs, but throwing out the features that have been scrupulously analyzed, optimized, refined, and finally only included when they were deemed absolutely necessary is just absurd.
Multiple inheritance can cause huge maintainability problems, but used judiciously it makes it much easier to customize class interfaces and reduces code duplication. In many cases a design can increase a magnitude in complexity if multiple inheritance is not available.
Templates and stack-based objects are not strictly necessary in many cases in C++, but they provide the primary mechanisms to write high-level, well structured, and maintainable code that runs at near-optimal efficiency. With these features you can write extremely robust and flexibly interfaces that compile down to only a few instructions. Removing them would mean requiring writing any code which needs to run efficiently in the old monolithic C style which has proven so expensive to debug, maintain, and extend. And if you can come up with a type safe zero overhead way to write container classes with no code duplication at all, it's probably more complex than the (admittedly new and not-well-understood, but inherently straightforward) template system in C++.
Operator overloading is the only way to write user-defined types with interfaces similar to those of built-in types. To disallow this feature would be to put up a wall between what the language provides and what libraries can offer.
Overall, I just don't see anything which even comes close to outweighing the huge costs and problems that come with moving to a new language. C++ was a major step forward from C; D is at best a step sideways.
The improvements, beside simplification of teh specification brought by D aren't stellar.
Garbage keeping is nice. And so far it feels like this was one of the only real attemps at making D a higher level language than C++.
Nothing bold in there really. I am however curious about typing. Well, they still use non-object types for comon data types. They use only single inheritance. I only browsed through the specification so far but I am still asking myself about a couple of things that don't seem to be menmtionned anywhere.
Object Delegation, since we only have single inheritance and a couple of constraints from C++ and Java, does the language offers delegation mechanisms? Of course it can be programmed but it's stupid that everyone has to roll out his own using interfaces (in java at least). Delegation, in case some people don't know, is when you can asing a delegate to an object, when an object can't answer to a message (method call) it sends it over to it's delegate.
Which brings me to this quote from teh spec overview:
"Runtime Type Identification. This is partially implemented in C++; in D it is taken to its next logical step. "
Alright, what do they mean? It is not clear so far according to what I have read. But if the language uses dynamic typing, that would be awesome. It would in part contribute to make up fr the loss of templates.
Dynamic binding would also be great. But I haven't seen anything hinting it is coming...
Ok, sinoce some of these ideas are some of the nice things in Objective-C, I aadd just one comment about one thing that is extremely usefull but is always overlooked for some reason: Categories.
Categories allow you to define something that is a bit like a subclass but that only introduces new methods (including their implementations). The good thing is that if you define a categopry on a class, any object of that class can be considered as part of this category... it is great when extending frameworks and the like without having to play with subclassing and object types problems.
D seems a good idea, but for it to be really relevant they should be pushing teh high level language aspect. NOt just C++ made easy in a couple of spots like dynamic arrays.
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's not as far-fetched as you may think. "Portable assembly" refers to mnemonic languages that represent a bytecode that can be recompiled into a CPU's native bytecode. For example, Jasmin is an assembler for JVM bytecode. The new Amiga OS comes with a virtual machine and an assembler for its bytecode. Heck, even x86 bytecode is beginning to be thought of as somewhat high-level; Transmeta's Crusoe processor dynamically recompiles ("Code-Morphs") x86 code into its own asm.
Will I retire or break 10K?
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?
It has been done already. The language is called C++. It's a big language, but it's considerably more powerful than Java (multiple inheritance, templates), while also being faster.
Unfortunately, it doesn' t have Sun's marketing engine behind it.
I also think the VCL is gross -- its use of global variables, all the obscure Windows API stuff it is doing, all the house keeping it needs to do for features you may not even use.
> 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!
Unfortunately there are few programmers that take advantage of even half of the capabilities of C++ because of the complexity that is present in the language. Most revert to functional C programming instead of actually implmenting a well designed OO program.
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
Some of the features dropped from C++:
Multiple Inheritance
Templates
Operator Overloading
Some of the features added/retained:
Garbage Collection
Exception handling
I've seen criticism of Java because of these choices from certain quarters at various times. It is interesting to see the same decisions being made again 6 years on, which I believe vindicates Mr. Gosling.
${YEAR+1} is going to be the year of Linux on the desktop!
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.
>> Maybe its time for a new language born out of practical experience implementing compilers." <<
That is like letting ONLY engineers design cars and not drivers.
Table-ized A.I.
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.
> 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.
Goodness me. Its not enough that comes up
with the idea of a new language and writes
a compiler - he has to write killer apps too!
Does he have to kiss your ass too?
and here i thought ! was the generally accepted 'splat'.
Nah, that one's called "bang".
If a job's not worth doing, it's not worth doing right.
Hell, my compilers class had us implement an Oberon compiler in 20 weeks (most of it spent learning how to write a compiler in general).
;)
If D is that easy to implement, then why not add templates
> 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.
Common lisp has already all the features of D. and a lot of more! Where are the macros?? Why re-inventing the wheel again and again? Then we will learn "D in 21 days". How about learning our existing languages in 10 years?
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?
What environment were you running the Java/C programs from?
Also, what C compiler are you using?
If you were running them from a command prompt, let's not forget that running 32-bit programs from a 16-bit command prompt is rather slow; it takes 1-2 seconds just for the program to start.
Also, the C compiler used is important (as it determines the type of EXE produced); DJGPP produces 16-bit executables (which use a 32-bit extender, or just switch to 32-bit if they detect Windows running), which runs very quickly from an MS-DOS prompt; if you use a Win32 compiler like VC++, you'll get 32-bit programs which exhibit the startup delay mentioned above.
I'd be interested to see a *true* benchmark, i.e. one that does actual computations and which takes atleast several minutes in either language; that'd get rid of any delays from overhead.
* Q
P.S. If you don't get this note, let me know and I'll write you another.
If I'm not mistaken, Java's Object superclass makes any template system redundant. Of course, an industrious C++ programmer could just declare all of her classes inherited from an Object class, and have any libraries just use Object types instead of templating. (I never liked wrapper files)
This doesn't use a vm like java does. Read the spec.
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.
D's object oriented nature comes from classes. The inheritance model is single inheritance enhanced with interfaces. The class Object sits at the root of the inheritance heirarchy, so all classes implement a common set of functionality. Classes are instantiated by reference, and so complex code to clean up after exceptions is not required.
Also, synchonization is pretty much exactly the way java's works... at least in the vague way they describe it in the overview.
kmj
The only reason I keep my ms-dos partition is so I can mount it like the b*tch it is.
sweet.
Nothing for 6-digit uids?
Languages should respect orthogonality. Well, at least programming languages should. C and its derivatives do not. Just look at the difference between function parameter declarations and variable definitions. E.g. char a,b; int c; /* legal definition */ /* both a and b are of type char */
int f(char a,b, int c){} /* legal function definition */ /* but b is of type int! */
My suggestion: borrow ';' from Modula [Wirth] to seperate function parameter declarations! E.g.
int f(char a,b; int c){}
C# = Db Do Sostenido = Re Bemol C,C#,D,D#,E,F,F#,G,G#,A,A#,B Then D modern than C#
Yeah Forth is nice. But the only company I have seen pushing it is IBM.
Mmmh... well... and I remember that some Macs based on the first generations of PowerPC chips used Forth in OpenFirmware, it actually allowed a couple of cool things. I beleive it was also the case fopr Prep boxes.
The thing is though, as he says in the overview, these "nothing special" things save time. Sure, they're not necessary, and we live with C's little oddities without problem at the moment. But, if we don't have to worry about those then we can be more productive, and hopefully less coding mistakes are made.
It looks nice enough in my opinion (main thing I'm sceptical about is the documentation in HTML thing). Whether it'll turn out to be successful who knows - let's see.
Because Forth is bollocks, thats why.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
That was it! That software was the WORST!
I am very small, utmostly microscopic.
IIRC, sizeof is the only C operator that uses English alphabets == inconsistency!
Also, as dynamic arrays and strings have a length property, having foo.size makes the syntax more consistent and makes foo look like a first-class variable, similar to other OOP languages (not C++).
¦ ©® ±
>Java GUI apps _are_ slower, because Swing is basically all written in Java and it can't really take advantage of platform-specific tricks to run faster.
Except on MacOS X where Swing is hardware accellerated.
"Nathan Hale"??
"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.
Apparently it was named octothorpe because it looked like the street pattern of an English village. Can't remember where I read that.
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
Don't get me wrong, I love coding in assembly too. The control you get is like a powertrip. The problem with assembly, obviously, is that it's architecture specific. While that isn't necessarily a bad thing, it is nice to have the broadest possible user-base, which means cross-platform. That's why everyone's been infected with this Java disease. Of course, if you're not worried about that, more power to ya. I personally think programmers should be required to know some kind of assembly, so they have a concept of what their code actually gets turned into. "Look, this vector search only takes one line of code! That's way faster than trying to use this array that would take at least 5 lines." I'm not exaggerating here.
--
Promoting critical thinking since 1994.
There has been a FORTH developed that places the code between code /code tags in HTML pages see:
coldforth.teegra.net/
The web pages are the source. You code can include
nice HTML comments, images etc.
The FORTH in question has also done a decent job of implementing local variables so there is no need to do return stack manipulation.
"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.
It is "See Sharp". As a musician, you should know that it is equivlant to "Dee Flat."
Oooh. I made a funny...
--
You sure got a purty mouth...
One of the reasons C++ was C++ and not D, was that it was supposed to be a superset of C, such that any C that compiled using a C++ compiler should work and do exactly what it should have done if compiled using a C compiler. The idea being that C++ programmers would have a good place to start from (i.e. C). However since the early days of C++, C++ has grown such that the subset of C++ which is C is a rather small subset. The problem is that C++ suffers many limitations which stem from its C heritage. It might be a good time to write a *new* language which is similar to C++ but where in cases where backwards compatibility with C conflist with clarity, that clarity should win-over. If D does this, then it is a welcome addition to the tool set of programmers.
return 0; }
So your contention is that a program can run just as fast on a virtual machine as one that is compiled natively?
your kidding, right?seriously...why dont we all go back to using machein code - its faster than C, C++ and Visual Basic, it can do webstuff (all webservers on the planet talk to the cpu) and all the current compatibility issues we have will look like tiny ants.
Im joking (no realyl I am) but come on C++ has its uses sure but its definately go onefoto in the grave, Im not sure that Java is a long term sucsessor but it certanly can do anything C can but better.
Do Unto Others As You Would Have Others Do Unto You - ONLY HARDER!
Practical experience designing compilers? No way! The programming language is the human interface. The compiler's job is to translate that into what a computer can recognize. If 10 people spend 1 year crafting a compiler for a language that is especially difficult to translate to assembly so that a million people can save a day coding a project. Tailor the language to the humans, make the compiler as large and nasty as is necessary. I'm one of those people that would rather spend 1 hour compiling a small program if it would run 10% faster than if I spent 10 mins compiling it.
I was wondering the same thing. If you are experienced in Eiffel, it would be great it you would read some of the spec and try to get more insight on the D vs Eiffel and make some additional comments.
Or anybody else who has used eiffel...
I suppose I'm not too threatening, presently, but wait till I start Nautilus
I should think as compilers go a C compiler would be fairly easy to implement, aren't there just like 14 reserved words, and aren't several of them obsolete/never used? And weren't c++ "compilers" really cross-compilers that converted c++ to plain old c? Giving us that delightful "name mangling"?
I wish people would stop dreaming up new languages and concentrate on enhancing existing languages, Java in particular. As a programmer, I'm not going to keep more than 2 or 3 languages handy on the top of my head and I doubt many other programmers are so inclined either. Java at the moment does the most for me, even if it does compute a FFT slower than asm, perl is nice when you don't have a plan and don't want to think too much, and C is the common tounge of *nix. What's in it for me to learn C#, D, Python, etc. that isn't already covered by perl, C or Java? (That's rhetorical, the answer is nothing.)
AC's cheerfully ignored
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!
And I can still type a lot faster in JBuilder than it can display the text.
Even on a 1GHZ Athlon with 400 megs of ram.
Before you email me, remember: "There is no god!"
I don't think we can reasonably expect every large scale change that Microsoft makes will result in little or no change for developers. And I see this as a good thing in the software design sense. In the software maintainability sense, yeah, it's bad (if not horrible). But at least Microsoft doesn't make us wait forever for these kinds of improvements. To use the original example: I personally have done Winsock code using VB. And it sucked. Big time. So much of the work I did should have been completely unnecessary.
But the new API? I'll take that with a shake please! I'd gladly dump all of that old code to be replaced with a few lines the new stuff; it's not a one to one translation anymore. VS.NET will help developers function with the OS at a much higher level semantically than was possible before. That increases productivity. Hell, I'll take two!
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
congradulations! you completely missed the point!
It's unfair to compare a Java UI directly with a native UI.
No it isn't, that's the discussion. Java is slower than c unless it is compiled specifically for the platform. For anyone arguing the JIT bullshit: Benchmark it using 1000 of the same program executing in parallel. What's that? The native programs kicked the crap out of the java ones? No shit!
???
yeah, it's not like any code can ever be added after you realease a version or anything...
I think you are making my point with "almost", "generally" and "practical."
I think interface can be made to work but fairly frequently at a the cost of introducing complexity with inner classes that is worse, in terms of code maintainability, than the problems with MI. I think the problems with MI are daunting in theory but trivial in practice.
I know about the dreaded diamond inheritance tree, bane of students and compiler writers, but I have never met it in the wild.
People really just want to use mixins and for that MI is more straightforward than using interface.
So I categorize languages like this:
Support for Mixins
Forwarding -- best
MI -- good
Interface -- acceptable
None -- not acceptable
It was really the last line that motivated my rejection of D.
BTW I do think the C++ committee made a mistake. They should have just banned diamond inheritance outright rather than making arcane rules for it. If you see it, it means your design is flawed.
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
Does anybody else find it pathetic that almost every
language that comes out is some varient of C? We've
got C, C++, objective-C, C#, D, Java and a whole
bunch of others I can't think of at the moment.
Where's the imagination folks? Things like Sather,
Scheme, ML and other interesting progressive
ideas. Very sad.
Well this guy definetely seems to have the right idea. C is lean and mean, C++ is OO but way to complex. Didn't one of the K&R guys say that in any decent C program 90% of the C syntax could be used, while in a C++ program its only 10%?
:)
;p
Speaking from personal experience, I find it much easier to write good, clean, portable & efficient code in C. I find that coding in C++ tends to produce worse performance (guess the compilers have more to worry about which effects optimization). Also each C++ compiler tends to implement the C++ language in its own unique way and I spend more time working around those quirks aand the C++ syntax than actually writing useful code!
Just picking the really useful stuff from C++ and improving on the missing features from C would produce a language that I could see myself using all the time. A bit more higher level functionality to C can hardly be a bad thing.
So when can we expect the Linux Kernel in D then?
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.
A good IDE like Visual C++ or {dare I say it} Multi will do the sorting for you. You just add files to the project and write code... --Richard
I agree. For example, if one avoids the temptation of using "*" in Java "import" statments, one can look at the code and immediately see a class' dependencies. All of them. Additionally, well laid out declarations in the methods, etc., can give an immediate idea of what sort of data is present and can give insight into what sort of algorithms to expect.
Declarations are good. Wildcards in declarations are bad, and no declarations are even worse.
Healthcare article at Kuro5hin
I just recently started looking at Ada95, and I am impressed. I don't like the klunky syntax much, but the language is fundamentally sound and powerful. It is widely used in safety-critical systems such as ICBMs, air traffic control systems, and airplanes. Some have claimed that it cuts development time in half compared to C/C++. I don't understand why Ada gets so little attention.
Incidentally, I proposed on comp.lang.ada that the syntax could be cleaned up, without breaking backwards compatibility, with a relatively simple preprocessor. This would essentially create a new, cleaner dialect of Ada. It got a lot of resistance, but I think it has potential.
I watch Brit Hume on Fox News
I don't understand what your problem with using import java.util.* or similar is...Only the used classes get loaded. You could potentially cause some name clashes, but only if your programming is relatively sloppy.
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.
It's really quite simple.
JAVA IS SLOOOOOOOOOOOOOOOOWWWWWWWWW
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
After 1/2 an hour reading his specs, D looks a bit raw but quite cool. C++ is the foundation, Java is an influenece & I am sure there are others. Object properties work rather like in Delphi or C#, enums remind me of Pascal.
D will probably be good fun to use when it's ready.
My Karma: ran over your Dogma
StrawberryFrog
It's not cee pound for crying out loud! It's See Sharp!!! Get it straight!!
You can use garbage-collecting class libraries -- which only work with those classes.
Or you can use D, which doesn't have any classes yet.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
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
and here i thought ! was the generally accepted 'splat'.
But now that this discussion is down to mainly language vs other language, I was wondering why nobody had mentioned Eiffel.
In terms of a pure object-oriented language, Eiffel is right up there. It supports polymorphism(while still being strongly typed), multiple inheritance(through a very thorough mechanism which can even allow you to undefine a feature if you don't want to inherit it), all types are objects(even primitive such as INTEGER and REAL), garbage collection(I know it isn't necessarily an object-oriented concept) and the list could go on.
It also provides operator overloading in the form of infix or prefix feature definitions.
Now I realize that there are other languages that support feature A or feature B that I listed but what other ones support all of them?
No,
....
Walter Bright worked long for Symantec and the former Zortech Compiler was then known as Symantec C++.
I worked with the 6.x and 7.X versions.
Walters C++ compilers where the only ones ever implementing templates right.
I found about 100 compiler bugs in Borland and Microsofts compilers by porting my code from Symantec C++ back to Micosoft C++ and gave up check compiling with Borland. (Most bugs where in MS, I only discontiued using Borland because it got to time consuming and I had to clutter to many vendor specific #ifdefs into the code)
Some yielded Syntax Errors and a lot yielded simply bad object code (found out in nights of debugging).
IMHO, Symantec C++ was the FASTEST compiler and the one creating fastest code (in benchmarks Borland often yielded faster code but my real world application, a geodesic CAD System, was faster with Symantec)
Microsoft compiled the same code in about 4 times the time (over 2 hours on an 66MHz 486).
Od is: on my actual Pentium Visual C++ 5.0 still needs 45 minutes while Symantec C++ 7.2 needs some 15 minutes.
Basicly I went over to Java because of fiddeling with so many C++ compilers which costed me so much time, I went mad over it
Templates I miss but if you search on java.sun.com you find under jsr14 the asctual Java implementation with templates.
It is sceduled for JAVA 1.5 AFAIK.
Regards,
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
One thing i want to add: multiple inheritance.
Take a look why.
> 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.
Hey, it's twice as many pluses as C++, so it has to be good! :-)
We're sorry, the phone number you have reached is imaginary. Please rotate your phone 90 degrees and try your call again
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.
I can't help thinking that too many languages spoils the broth. Focus should be on ease and speed of development, error handling, development tools that enable the 'simple' problems to be auto detected as far as possible, that assist in testing loops, that FORCE you to document, and produce readable documentation on the fly. Get all that working WELL and I'll write in bloody VB if I have to.
Fundamentalism is for church or TV shows - lets just all agree to compromise - stick to C++ and develop better TOOLS for C++. Yeah it sucks in areas, yeah we all have things we hate about it - but NO we aren't going to be rid of it any time soon - so lets make life with C++ easier.
D looks like a stripped down version of C++, limited to the features that an application programmer who grew up in the Windows environment might find useful. But we already have simplified, limited, easy-to-use languages: Java and C#. C++ is a complex language, and it isn't a particularly well designed language, but the complex features that it has are useful and powerful. Language design should go more in the direction of figuring out how to simplify providing those features, not in stripping C++ down to something from the 1960s again. Two thumbs down.
The montly programming language holy war is about to begin!
That's why I program in Java ASM, portable ASM.. Eat that!
A universal object type is *not* a substitute for a proper parametric type system. (Not that templates are a proper parametric type system - template are, pretty much, the most bone-headed, brain-dead way that I've ever seen of implementing parametrics.)
To give a real-world example... I'm working on a software configuration management system, implemented in Java. (webpage). In our system, switching from Java to GJ (java with parametric types) literally took about 25% off the size of the code, made it easier to read, and eliminated several bugs.
What bothered me most about this guys proposal is that he doesn't seem to have a clue about much of anything outside of the C/C++/Java language family. His argument for leaving out templates is correct, but he follows it with "I'm looking for a solution". Wake up pal, the solution is out there, and it's been there for over twenty years. It's just not in any of the C++ family languages.
I've read the D spec and I like a lot of it. It certainly would not be difficult for a C programmer to start developing in D as specified.
However, I have to wonder about the string concatenation code. Specifically, I've noticed that it does the same thing as java - namely a + b = c for strings. In Java, this is mindblowingly inefficient - a StringBuffer does the job with far less memory wasteage and so on - BUT, as the + operator is easier to use, it tends to be the chosen solution. I wonder if these string concatenations are efficient...
http://www.themeparks.ie
it is pronounced 'see-sharp'
I think you missed the subtley that your parent post was going for. Try reading it again, keeping in mind who produced it.
--
Promoting critical thinking since 1994.
Boes someboby alreaby have copyright on the letter [CENSORED]? Bamn. Coulb make it bifficult....
;-) use yer brains, matey
Being partial to the dirtiest part of programming (that isn't just bits or hex...), the more control, the better!
This sig isn't original enough, it's time to come up with something witty...
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
There is no:
-
C source code compatibility. Extensions to C that maintain source compatiblity have already been done (C++ and ObjectiveC). Further work in this area is hampered by so much legacy code it is unlikely that significant improvements can be made.
-
Link compatibility with C++. The C++ object model is just too complicated - properly supporting it would essentially imply making D a full C++ compiler too.
-
Multiple inheritance. It's a complex feature of dubious value. It's very difficult to implement in an efficient manner, and compilers are prone to many bugs in implementing it.
-
Templates. Templates are a way to implement generic programming. Other ways are using macros, or having a variant data type. Using macros is out. Variants are straightforward, but the loss of type checking is a problem. The difficulties with C++ templates are their complexity, they don't fit well into the syntax of the language, all the various rules for conversions and overloading fitted on top of it, etc. What's needed is a smoother way to integrate them into the language, so they have a much more natural and obvious feel to them. I am searching for this solution.
-
Namespaces. An attempt to deal with the problems resulting from linking together independently developed pieces of code that have conflicting names. The idea of modules is simpler and works much better.
-
Include files. A major cause of slow compiles as each compilation unit must reparse enormous quantities of header files. Include files should be done as importing a symbol table.
Creating object instances on the stack. In D, all objects are by reference. This eliminates the need for copy constructors, assignment operators, complex destructor semantics, and interactions with exception handling stack unwinding.
Trigraphs and digraphs. Unicode is the modern solution to international character sets.
Preprocessor. Modern languages should not be text processing, they should be symbolic processing.
-
Operator overloading. The main applications for operator overloading seem to be implementing a complex floating point type, a string class, and smart pointers. D provides the first two natively, smart pointers are irrelevant in a garbage collected language. When using operator overloading for non-trivial purposes with multiple non-trivial classes, the interaction complexity of the overloading coupled with user-defined conversions, overloading in general, leads the person maintaining the code wondering whether it was all worth it.
-
Object oriented gradualism. Class instances in D are object oriented, the other data types are not.
-
Bit fields of arbitrary size. Bit fields are a complex, inefficient feature rarely used.
Support for 16 bit computers. No consideration is given in D for mixed near/far pointers and all the machinations necessary to generate good 16 bit code. The D language design assumes at least a 32 bit flat memory space. D will fit smoothly into 64 bit architectures.
After using C++ how can someone want to use this???I've had the (mis-)fortune of working with 'D' scripts on a project some years ago. The product is (was?) TeleUSE. I don't recall the company name.
goddam ! what's your problem with assembler ?
it simply rocks !
Maybe Joe Coder prefers using his good old VB6 but i can do much more than what he does (and pretty fast) using TASM or MASM and a resource editor (to create user interface..)
And it can be PRETTY fast too !!!
Linux asm can be really interesting too !
Regards.
but if you like Foxtrot, take a look at this
Salut!
See sharp. See sharp code. See sharp compile. See sharp run. Oh! Access Violation.
- Decent typing
- C++ features minus full multiple inheritance/templates
- No more includefile system (Delphi/FPC import symbol tree like structures from
- Good numeric support. (like Pascal)
The only reason for templates is to make up for the fact that C++ is strongly typed. With a weakly typed language like Smalltalk, there's no need for templates.
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.
I'm not interested in a statically bound language without multiple inheritance. Experience shows that it just leads to abortions like MFC. Every language needs either MI like C++ or forwarding like ObjC.
Everyone : When I was doing desktop database programming back in the mid 80's, there was already a language named "D". It was sort of DBase clone that ran on the PC, VAX, UNIX, etc. Hope Mr. Bright doesn't have any copyright problems with his choice of name.
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
The E programming language :
http://citeseer.nj.nec.com/richardson89design.h
And another for the Amiga :
http://wouter.fov120.com/e/index.html
Think I'll rather stick to Java as that provides me with a robust framework for creating scalable
server side applications.
He discusses at length the 80 digit precision of Intel x86 architecture and how he intends to speed this up. Last I checked, the S-Float floating point representation used by most PCs is still only valid (accurate) to the 6th decimal place, and other floating types are not much better, if at all. Perhaps I am confused, and if so, please illuminate.
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 :-)
At this stage, languages are meant to make thing easier for the programmer.
/easy/ languages are letting in too many Joe Schmoes, ya know the type. Mr. Hey-I-took-a-class-once comes in and look hes got your job now. I for one am tired of people that just haven't the ability to write or think outside of the box and I'm also tired of floating on a fluffy cloud of tangled pasta code. I want streamlined, fast-as-hell code and people that can write it.
.ph0x
Keep up _this_ thinking and we'll all be de-spaghettifying _your_ code.
Languages are already way too easy and bloated - I think it's time for more hardcore languages to come out. All these
---
ps -aux | grep mind
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.
Consider:
void f()
}{
If DoSomething throws an exception, CloseResource won't be called and we'll have a leak. From what I understand of Java, you'd solve this problem with a finally block. C++ doesn't have finally. However, in C++ you can have objects on the stack, so you can do:
class Resource
};{
public:
void f()
{ }
Now the resource is opened when the object is constructed, and closed when it is destructed (whether this happens because an exception is thrown or because the function returns normally). So the problem is solved. You could argue that this kind of scheme is over-complicated compared to a "finally" block, but it gives you the good habit of encapsulating resources into objects, and makes it impossible to forget to close the resource. Also, using templates, you don't have to go to the trouble of writing a whole new class declaration every time, so it isn't as painful as it looks.
Send mail here if you want to reach me.
Academics love OCaml because it's closer to a mathematical expression of functionality. But for big programming, forget it. Obscure syntax and wildly unhelpful compilers will make your life a misery until you give up and adopt a real language. Any real language. Anything but FP.
D memory allocation is fully garbage collected. Empirical experience suggests that a lot of the complicated features of C++ are necessary in order to manage memory deallocation. With garbage collection, the language gets much simpler.
and ...
The superior try-catch-finally model is used rather than just try-catch. There's no need to create dummy objects just to have the destructor implement the finally semantics.
No VM though, so languages Java, Smalltalk et al would still have portability advantages I'd imagine.
ahem... here, here, and here say different.
Or just look here.
In the spoon, there is no Soviet Russia!
I write this at the risk of "posting 'me too', like some brain-dead AOLer", but I must say I couldn't agree more.
People who can write "streamlined, fast-as-hell code" are a dying breed. I'm not saying that the new solve-any-problem-in-under-45-seconds languages don't have their place. There are certainly lots of situations where getting the program done fast is a lot more important than making the program run fast, but colleges are teaching students these languages as a substitute for low level programming, and that is just sad.
There are certainly plenty of situations where I need to have a pretty tight reign over what the processor is doing. In those situations, I don't WANT a language with garbage collection. I don't WANT a language that stores bound information with my arrays (and certainly not one that checks those bounds every time I access an element). What I want is a language that puts me just a few levels of abstraction away from the machine for the general purpose code, and lets me snuggle right up next to the hardware when I need to. Nearly everything I want is embodied in C (and to a lesser extent, C++).
That being said, I'm certainly open to many of his ideas. Importing symbol tables rather than making header files, for example, sounds to me as if it could be a significant improvement to my favorite language. I also like the strong type checking on the typedef'ed types.
Anyhow.. D, Java, C#, Visual Basic, they have their place, that place just isn't anywhere near the type of programming I do.
Alan
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.
I don't see how sizeof (and it's sizeof, not sizeof(); sizeof is an operator, not a function or macro) is inconsistent or unpretty. Personally I think "sizeof foo" is prettier than "foo.size", and more consistent since I would expect "foo.size" to refer to a member. I can see the switch() thing, though.
How is C# pronounced? As a musician I've always thought it was "See Sharp"
Verbing wierds language --Calvin
Is this wise? I can think of many uses - Vector arithmetic, area intersections and combinations, list concatenation. All of these can be achieved without operators, but matematical syntax is considerably faster.
I see the synchronize keyword but not see an explaination of threading. Getting the syntax for threading sorted out has been a big plus for Java.
One of the big benefits of Java over C, is the reliable presence of a standard library that includes so much useful stuff (Hashtable, BigDecimal, etc.). Where does D stand in this respect?
I like the garbage collection in Java. A lot of the time this is fine, but sometimes it would be useful to be able to explicitly delete objects just as the D spec suggests. However, I would also like an optional method to be called when the reference count hits zero, so I can close files or shut down servers etc.. I see D has destructors, but like the finalize method on Java objects it becomes next to useless as there is no guarantee that it will be called any time soon (if at all). When building publish and subscribe objects it would be useful to have access to the reference count, or even have an optional method that is called when it changes.
I have yet to use a language that supports delegation without the programmer putting a load of stubs into the delegating class. D, it seems, will be no exception.
I wish Walter luck. It's a great idea. Java is still pretty slow and C++ is still pretty ugly, but he has got a lot to catch up.
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
those compulsively thinking and programming Gurus from themselves and us from their creations.
You're both wrong. Cee Hash, pronounced Cash.
Don't confuse me now - isn't C# read cee sharp. Not my area, but that's what I thought leastwise...
MikeI'm pretty sure its pronounced "C Sharp" not "Cee Pound"
In the UK, we call # "hash".
And bizarrely, the phone company (BT) calls it "square"
Sea Square or Sea Hash. The UK's gonna LOVE MS.
Actually, I think you'll find it's "Cee sharp" (as in opposite of flat)
In the spoon, there is no Soviet Russia!
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.
A complex datatype is becoming one of the reasons many people are considering C# over java these days. C++ doesn't as of right now have such a type but you can write the class. Supporting it natively in the language could probably yield many improvements.
I think the language still needs templates like or better than C++. I have been dabbling in generative programming and template metaprogramming in C++ is one way to get the job done.
Essentially a meta language telling the compiler how to write code for you is really useful in some cases. Loops get unrolled some computation gets done at compile time and it incurs no run-time cost.
If this guy can improve on the templates in C++ and make them better for generative programming practices I'd be sold on using it.
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
You are not only mistaken, you are woefully ill-informed. Sorry, but it's true; what you wrote is pure FUD.
Templates are used for way more than just typesafe containers. Here a few examples of well-established template techniques...
A broken object hierarchy where you insist that everything implements some artificial interface allows precisely one of these, and it doesn't even do that very well.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Rather than a new language, I'd like to see a good implementation of Sather really take off.
Sather is a wonderful language that provides a simple inheritance model, constrained genericity, good support for preconditions and postconditions and class invariants (I didn't appreciate these immediately, but once I figured them out my debugging time dropped by two thirds), and support for iterators (a rather different model than the C++ one), and some other features that would take a while to describe.
There is a GNU sather, but I'm not sure that its really active and I'm not enough of a compiler wonk to do much on it myself.
"Maybe its time for a new language born out of practical experience implementing compilers"
http://www.blitzbasic.com/
[o]_O
Great, just what I need.. another D in programming.
In the RT spec, memory allocation is guaranteed to have linear allocation time (in terms of the size of the object).
Embedded systems programmers have been dreaming of a safer and more productive means of developing systems... Java RT is very promising.
-Stu
Considering my job description has "programmer" in it, and I got paid on schedule last week, I'd say there's strong circumstantial evidence pointing in that direction. I should probably qualify "programmer" with "mostly Java," and then perhaps you'd feel even better about trying to make me sound foolish.
Anyway, at&t I believe had a product called cfront which according to my about 1989 C class was "a practical tool for coding in C++ because it actually generates C code" and I believe back in the day g++ did something similar except that it did two passes of preprocessing (preprocessing to something the C preprocessor would understand) instead of using C as an itermediary language. It's possible both were abominable to some degree, I never used either.
About that time, there were a few ANSI C compilers (and one interpreter) floating around the math department on floppies, all of which were copyright one guy (not the same guy), which leads me to the conclusion that writing an ANSI C compiler, at least for DOS, must be fairly easy, as I would define fairly easy. Not trivial, not really easy, but fairly easy. Getting bent out of shape about subjective statements is a little silly anyway.
Congratulations on cross-compiling something to DOS from a linux install of gcc, I guess that makes you a "programmer."
AC's cheerfully ignored
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!
Preach it, brother.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Yes, but who hasn't attacked that which they do not understand?
4. Objects that act like normal primitive numeric types but automatically update the gui display when they change valuue. "Score += 100;"
Given a third-party library, you hope there would be time to savor all the nuances, but you hint at operator overloads that could mask some 'interesting' surprises...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear