Slashdot Mirror
The D Programming Language, Version 1.0
penguinblotter writes in a journal article: "Soon, Walter Bright is scheduled to release version 1.0 of the D Programming Language. D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D has appeared on Slashdot a few times before, and Walter has continued to add more and more features. Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives. It has been here over the past seven years where extremely gifted and experienced programmers hashed out discussions and arrived at excellent implementations of all the ideas discussed." Read on for the rest of penguinblotter's writeup.
For those with a C/C++ background, D offers:
From D's creator:
For me, it's hard to pinpoint any particular feature or two. It's the combination of features that makes the cake, not the sugar, flour or baking powder. So,
For those with a C/C++ background, D offers:
- native code speed
- extremely fast compilation times
- garbage collection (although you can manage your own memory if you want)
- OOP - by reference only, easy initialization, always virtual
- cleaner template metaprogramming syntax, more powerful templates, as well
- built-in dynamic and associative arrays, array slicing
- versioning (no preprocessor madness)
- link-compatibility with C
- nested functions
- class delegates / function pointers
- module system
- similar syntax
- No virtual machine or interpreter
- built-in unit testing and design-by-contract
From D's creator:
For me, it's hard to pinpoint any particular feature or two. It's the combination of features that makes the cake, not the sugar, flour or baking powder. So,
- My programs come together faster and have fewer bugs.
- Once written, the programs are easier to modify.
- I can do (1) and (2) without giving up performance.
...it's just another version race. D may have won for now, but someone out there is already working on the E programming language. ;-)
I'm looking at using it via GDC for my next project. For people who use C/C++ regularly, this is something you ought to look into.
It's not a toy language. If you're a C++ programmer, you'll be almost immediately functional in the language. And you can call C and C++ libraries seamlessly. It's pretty sweet.
"You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
Someone is making sweet love to the bandwidth. I'm downloading at less than 6KBps.
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
From the compared to C/C++ list:
* native code speed
As opposed to C/C++.
* extremely fast compilation times
Point granted (compared with most C++ compilers).
* garbage collection (although you can manage your own memory if you want)
Point granted, even though C and C++ arguably have optional garbage collection as well (if you link to the right library).
* OOP - by reference only, easy initialization, always virtual
Only value semantic? Meyer had to accept that value semantic was useful, and add it to Eiffel eventually, and C# added it over Java.
And no way to specify that a function will always be the one specific. Good luck doing any kind of reasoning there.
Bragging about missing features, that are essential to many tasks.
* cleaner template metaprogramming syntax, more powerful templates, as well
*More* powerful templates? The usual complaint is that C++ templates are too powerful (a Turing-equivalent compile time language).
* built-in dynamic and associative arrays, array slicing
Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.
* versioning (no preprocessor madness)
I'm guessing he meant variants here, the preprocessor is often used for variants, rarely for versioning.
* link-compatibility with C
Which C and C++ of course lacks?
* nested functions
Point.
* class delegates / function pointers
Obviously both C and C++ have function pointers.
* module system
More preprecessor replacement here.
The C#/Java list:
* similar syntax
But totally different from C++?
* No virtual machine or interpreter
You can compile Java and C# to native code as well, so this is just another case of bragging about a missing feature.
* built-in unit testing and design-by-contract
I'm a C++ programmer, and this is by far the most interesting aspect of the D language (and of Eiffel before that). Don't know why it should be in the Java/C# list.
All other considerations aside, runtime speed really should be a justification as a bonus to Java. Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat ion can greatly increase the speed of your code and put it close in line with C++. I would certainly consider D if both 1 and 2 were better than Java.
Hold your horses, E is already used in a quite good Amiga Language.
Shh.
Try using .NET for systems programming. Or projects (I've made several thousand dollars from one so far) that must be portable to NT4, 2K/XP without requiring your clients to install extra junk on every computer, etc. Contrary to what Microsoft may want you to believe, .NET is not the solution to all the world's problems.
LOAD "SIG",8,1
Cheers for D, and happy new year to Walter and all the rest! As much as the D community is often derided for their sometimes aggressive marketing, D is actually a programming language that can run with the best of them.
Please correct me if I got my facts wrong.
I am hoping that D is or soon will be a good alternative to C#.net and Mono. What is the preferred GUI environment for D? I was watching the D forums during the first half of 2006 but I could never post any questions to the D forums so I gave up. It looks like I gave up too soon. Does anybody know why I could not post to the D forums?
I don't see D as an advancement in programming languages. I give it a "F"
What, exactly, is the benefit of the .Net VM? There is only one full implementation of .Net (the MS one), and it runs on a single platform (Windows on x86). You might as well build native x86 code linked against Windows libraries for all the portability you have. And even if you're going to bother implementing the VM across a bunch of platforms, why not implement a standard library across a bunch of platforms and link native executables against that?
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives
You must be new here.
C/C++ are primitive languages barely above the level of Assembler macros.
Java is a bit nicer than C++ but it just can't perform at the level of C (how many OS'es are written in Java?)
perl/ruby/python are closer to being good languages, but they still don't perform like a compiled language.
I don't know if D gives the features of Perl with the speed of C, but it's certainly a step in the right direction.
-- To dream a dream is grand, but to live it is divine. -- Leto ][
Me too, PHP is da bomb!
I took it upon myself to learn D not more than a few weeks ago. A classmate introduced me to the language last spring.
While I'm still learning D, it has some notable features:
Of course one may argue that none of this is necessary and could be made independent of the language itself. My belief is that would increase the complexity of coding in D.
If you're interested in D you should visit http://www.dsource.org/. There are some interesting projects such as Derelict (collection of C game bindings) and Bud (make and SCons replacement).
This slashdot-related signature is a stub. You can help kihjin by expanding it.
After working so hard to get from C to C++, I don't see why I would settle for D. My next programming language is going to be B- or better.
This language is simply not worth noting. It's a simple evolutionary step over c/c++ but still suffers in many ways from their flaws.
Seriously, how is a language like this newsworthy? It does nothing for taking us forward in the world of development languages. There are numerous languages already far more sophisticated and closer to the future that D could ever hope to be. D is simply a sad attempt at holding onto the past.
*snore*
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
I'm sure D is a lovely language, but it just seems like another incremental change over C++, like Java and C# before it, and like both of those languages what it's lost and the opportunities it misses are as telling as the little tweaks it makes to improve things.
No-one has yet been successful, IMHO, in developing a really good industrial programming language. Those that make it tend to be pragmatic, practical tools like C and Perl and FORTRAN and COBOL. To be sure, each of these has many widely-acknowledged weaknesses, but the overall balance between those weaknesses and what you could get done using the language was right.
I can increasingly see why some well-known programming language designers shy away from feature comparison ticklists. I think it's because as soon as you go down this route, you bias the comparison so much that it's meaningless. For example, consider the first checklist cited in the Slashdot write-up. (I note in passing that this is a wiki, and may change before you read this.) Here are some of the "yes or no" (almost) categories:
Templates or executable macros No difference in expressive power is acknowledged between LISP macros and C++ templates. Thread synchronization primitives With no reference to how expressive they are, and how powerful the idioms supported by them? This one is really telling, IMHO, because I don't believe the future lies in classical thread sync and locking primitives. The whole approach is just too prone to deadlocks and race conditions to withstand the heavily parallel future that multicore chips are starting to bring into the mainstream. When you have ideas like pure function programming languages, operating in a world without side-effects where explicit locking isn't necessary, or interesting ideas for inter-thread communication such as those in Erlang, another variation on built-in pthreads just isn't worth much. Enumeration So again, we acknowledge no difference between simple and low-level enumerations such as those in C, and concepts such as disjunctive types and pattern-matching that are very powerful, remarkably elegant, and mainstream in certain families of programming language. Again, this is just papering over a gap, where other languages operate on an entirely different level. Long double floating point (80bit) This is just desperation. Pretty much no-one uses 80-bit floating point arithmetic IME (and yes, I do work in the field). The portability hazards and lack of true support from almost every mainstream architecture make them almost irrelevant, except perhaps for a few very small niches. Lexical Closures Another telling omission: the power of all those neat functional programming features is dramatically reduced when you can't construct functions on-the-fly.On top of all of this, the feature lists invariably gloss over some less concrete things that are nevertheless very important to systems programming languages. How portable is D? How many production-quality implementations are available? Is the language standardised or under the control of a single, commercial body? How much backing is there behind the language in the commercial development space; do others write libraries specifically for this language, or is it reduced to using C-style interfaces at the lowest levels anyway, and what impact does this have on the usefulness of features like DBC, exceptions, and so on? Does the language have an active hobbyist/volunteer community supporting it?
I could go on, but I don't want this post to disappear into the oblivion any more than it already will. Although I'm deliberately focussing on criticising in this post, as I often do with D, I keep an open mind and will happily engage in debate with others, or even be proved wrong by people who have found D to have compelling advantages. So go ahead, D advocates, start your counter-arguments here...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
> You might as well build native x86 code linked against
> Windows libraries for all the portability you have.
That's a good point. Still, the VM does serve as an insulating layer against OS changes. But Microsoft is pretty good about not breaking backwards compatibility, so that's not a great advantage. Any idea if there's a C# to native compiler out there? Googling around, I came up with this thing.
The app I work on uses Ruby and Flash to be crossplatform; working out pretty well so far...
The Army reading list
"Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python."
This may be half of it, but I would say a core part of its focus is something with enough curly-braces to be palatable to stubborn C and C++ programmers.
I really hate banging this drum, but Lisp (the language that everybody who doesn't know loves to hate) has had for many years the high performance of C and C++ (through optimizing native compilers and profilers), and at least as much power and productivity as Ruby and Python (through even higher-level features, not the least of which are macros).
I'm not saying this to be disrespectful to D. Apparently that's a big feature. A powerful homoiconic language that uses parentheses is a hard sell, because people will associate it with things they think are true about other languages that look like that. For example, they might think that it's interpreted (even though I've never seen a Common Lisp that wasn't compiled, and only one that doesn't compile to native code). OTOH, when they see braces, they might associate it with C/C++.
It's 2007, and cargo cults are alive and well.
What language is the VM written in?
Your kidding right?
Right?
At least two platforms, X86 32 bit and X86 64 bit, and I think, Itanium (not so sure).
.Net framework will use MMX registers sometimes if they're available, for example.)
The reason why not shared library is the whole 'machine code generation' being different for different platforms. Sure, MacOS has universal binaries, but it does mean double the exe size and can't cope with new platforms coming out, or processor specific optimisations. (I belive the
Looking at the comparison lists, D looks pretty nice. It has a lot of features that I'd consider switching languages for (from C++), but any such language would have to have a few particular properties (due to the kinds of things I program):
1. Must be able to disable garbage collection and manage allocation explicitly
2. Must be able to allocate classes on the stack
3. Must minimize use of exceptions in the standard library (in other words, exceptions must only be used for exceptional cases)
Java fails all of them, if I recall correctly (I don't know that much about Java, actually). C# fails 2 and 3. It looks like you can disable garbage collection in D, but in the comparison list I didn't see mention of 2 or 3. Does anybody know, off the top of their head?
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
garbage collection ... No virtual machine
How do they square that particular circle?
native code speed
Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made. That's not the slow part. GC has a lot to do with the perceived slowness. Isn't it disingenuous to tout both "native code speed" and "garbage collection"?
My Karma: ran over your Dogma
StrawberryFrog
I don't think that portability's a feature of .NET... I think that its great runtime safety checks & logical std library are the major thing it brings to the table.
The portability thanks to Mono's just an added benefit for some of us
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
I thought for sure that the D language was at least 25 years old and built way back when. Then about 2 years ago Solaris 10 came out with dtrace and all of the "scripts" have .d extensions. Yeah I know it is unix and the extensions are meaningless.
Dtrace user guide
But the disambiguation page on wikipedia seems to bear out that calling a programming language D will only be interesting. Anyone know if it is trademarked yet?
I really like D, but it has a one huge shortcoming: no decent XML parser or generator library. Nowadays parsing and generating XML is a very commong task. It makes hard for D to compete against Java or #C.
"No Virtual machine"... -that is a HUUGE downside not upside .Net is fairly well performing for example
"Fairly well". Me, I'd rather have good. Or exceptional. What you're describing there is "marginal", and that's an excellent reason to steer clear of .NET.
Weaselmancer
rediculous.
My feeling is that languages shouldn't try to satisfy all possible needs. Rather, we should have small and clean languages, use the right tool for each job, and combine code libraries from different languages when needed. (I regularly use 3-6 languages in a single project and my life is much happier for it.)
(Legacy support is critically important too, but it is vastly better to provide legacy support by providing ways to call older languages, especially the lingua franca of C, rather than demanding that the new language be a superset of the old. I still call numerical libraries written in pre-1970 Fortran, but that doesn't mean I have to write my code in a Fortran derivative.)
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
One area I see D being useful in is integration with Python. Writing to the raw Python/C API is cumbersome. (Managing reference counts is tedious.) Boost.Python is difficult to build and slow to compile. I've written a library for D called Pyd, whose purpose is not entirely unlike Boost.Python's.
Pyd is easy to use. It provides its own extension to Python's distutils. Usually, you just need to make sure the D compiler is on your PATH, write a setup.py file, and run python setup.py build.
"Hello world" in Pyd looks something like this (and I apologize for the lack of indentation):
Not quite correct. The
In .NET it's called a Common Runtime Library, running MSLI code. (That sentence is analogous to "the Java Virtual Machine runs Bytecode"
.NET is that there is built-in administrator controllable security (even pub/priv key security) between the CRL (or vm to you) and the internal .NET framework. In fact, there are several administrative controllable hooks built into the .NET framework that we just do not see in Java and Ruby and the others. This is the feature that separates .NET from the rest, and the rest of these frameworks are working to catch up. All modern languages are or should be moving into this direction. I predict that in 5 years the ONLY way you will be able to code to the WinOS is via the secure API that is .NET. (Assuming your programmers and admin teams understand .NET very well!)
.NET is horrible at scaling (less you got a big hardware budget), so I see .NET all over the DoD and internal sites, but not so much for full-in internet sites where Java is winning in the top 10 (example, MySpace is a Java app).
The big win in
Horns are really just a broken halo.
... actually going to use this? I think I'll wait for D++
I just can't see why I'd want to switch to a language that has no IDE support and is evolutionary to C# or C++. I hardly have to look at documentation for APIs anymore because I can just use Visual Studio's autocompletion to figure things out.
Am I really the only one who has yet to find a good reason to switch from Algol?
Suitable I should think, for "I.T" projects, cobbled together by cable-pullers, thinking they are actually programmers.
I'll stick to languages that have at least a professional following, in use by real software engineers (that is, engineers who can legally call themselves engineers), not the run of the mill code monkeys. what do you mean toy programming languages? java is almost identical to c#, give or take some rather small things. would you classify visual basic as a toy, i certainly do? or even pascal, but look a little deeper and pascal executes and compiles faster than c. how can you call a language a toy, it's a tool. if you cant work out what tool is best for a job then you probably do not have good enough experience with that job to know.
Why UNIX?
You can't claim the productivity of dynamic languages without being one. "with the programmer productivity of modern languages like Ruby and Python."
This is a lie.
The productivity of those languages come from:
1. Duck typing, ie no time spent (by the programmer) coming up with class and type hierchies that will support all future behavior of the product. You can make it up as you go along without ever hitting an, oops it isn't possible-and-I-have-to-refactor wall.
2. Dynamic meta-programming - at least in Ruby (I'm not familiar with Python), you can change classes, add/change function etc. at run time.
Some things more complete dynamic languages have, (but I'm not sure about current versions of the mentioned ones) is dynamic debugging where you can change the code (completely - including class definitions) while debugging, save the state of the whole program to continue from later (or debug from later), etc. etc. - advance debugging that C like languages don't have. Related advances, persistant data and the ability to make processes persistant (not just data).
I skimmed it, and some of this stuff is a PiTA. For example, they make a lot of good points about the pre-processor, but I can't justify re-working all my code into D just from that alone. Some of this stuff is bells and whistles--e.g., the built in unit testing? You don't need a language construct for that. If your programmers are so lazy or stupid that they can't write unit tests in C or C++, having the language give them a little hand-holding, standard way of doing that is probably not going to help.
If I need classes (and usually I don't), I'd reach for C++
The real reason C and C++ are becoming less the language of choice? It's the libraries, stupid. Most of the new languages have extensive "standard libraries" that keep up with the modern world. C gives you the choice of linking anything, and I think the standard bodies refuse to endorse a wider ranging standard library because they don't want people to get the idea that you can only use a particular set of libs. The other reason of course is that they have better sandboxing and/or exception handling (Java still crashes, but it throws an exception instead of just dumping core or doing something else that's compiler dependant).
While D makes some valid points, they might be better off adding these features to C++ and C compilers, and ultimately converging the two standards. It'd take a long time, but it was 9 years between the revisions of C (the last major one being C99). These language standards move at a glacial pace, and we like it that way!
Something like D seems to offer neither the RAD approach of PHP, Ruby, etc. It doesn't seem to offer the backwards compatable standards track offered by a revision to the C or C++ standards either. It doesn't satisfy the "roll a script fast" crowd, or the "write code that will still be used 30 years from now" crowd, in any particular way. It looks lost in the middle. Unless it gets endorsed by a huge corporation, and I end up working for that corporation, or until it gains industry traction, I don't see any compelling reason to pay the early-adopter price and use it.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
And for the record:
I see no Java here.
--S
-- sigs cause cancer.
"If it doesn't interest you, don't use it."
Good thing Geeks aren't applying your advice to procreation, else we'd die off.
The .net Compact Framework also runs on the Xbox 360 (PowerPC) and plenty of other devices (ARM, etc).
http://brandonbloom.name
- Load-time safety checking. Java bytecode is a lot easier to reason about that x86 machine code. This means that the loader can relatively cheaply check that loaded code conforms to the security model.
- Optimisation. It is possible for the JVM to inline function (well, methods) at run-time that are commonly called. If you have a loop in a C program that calls printf (For example), you can't ever inline it, because you need to dynamically link against libc (well, you don't have to, but a modern libc is several MBs, and you would get some very bloated apps if they all included libc). The JVM, however, could inline the equivalent when it did the JIT compilation to native code.
Of course, Java is let down a lot performance-wise by having some very bad abstractions. My favourite example is arrays; a low-level concept shoe-horned into a high-level language. Lists, tuples and sets are much better abstractions, both from the point of view of generating fast and safe code and from the point of view of a developer.I am TheRaven on Soylent News
Okay, it's a new C-like and Java-like language. But WTF is this:
What, writing an array of bytes to a file is difficult in Java?
I'm not sure about the whole hoo-hah about "is-expressions"/conditional compilation. Personally, I've always hated the infinitely regressive #ifdefs in C. Operator overloading -- you can keep it. Causes more trouble than goto.
In the end, what I'm looking for in a language is increased productivity, increased ability to architect changes, and increased understandability. I want to be able to pick up a printout of program X in this hypothetical language, understand what it does without a manual, help from the original developer, or reverse-engineering sessions (the code is the description is the code, and not in the RTFS sense), and be able to add stuff or modify it easily, and recompile without having to set up crazy environments.
I wish language researchers would pick up today's programs, and try to figure out what they could do to make things easier.
Yeah, I know, I'm probably dreaming.
--Rob
Towards the Singularity.
I agree, particularly with your recommendations for "small and clean languages" and "the right tool for each job". IMHO, the world has more than enough 3rd Generation Languages already, and 4th too... It's time to move forwards not sideways.
Tools that help me are not new languages... an IDE, perhaps like Eclipse (and all it's plugins) that helps to manage complexity by supporting projects that span multiple programming languages, provide revision control, continuous integration etc. So much of my work involves maintenance, I would like to see a tool that can make a million lines of code easier for me to understand, perhaps the source code navigation history of previous developers. But why work on something hard like that when you can do something easier and more fun like a new front-end to a compiler?
The benefit of a VM over compiling to native is that it enables cross-platform closed source.
it has some IDE support, like Code::Blocks SVN
http://codeblocks.org/
Bloody hell.Good designers make things both simpler and more powerful. They improve the product as much through subtraction as addition. Instead we get this...
BCPL was one of the sources of inspiration for the programming language 'B', and its successor 'C'. Next in the series ought to be 'P'.
I mean, like, I try to write this program, and like, the language does ONLY what I tell it to, not what I really want. That really sucks.
Can't someone write up some stuff that understands proper english? Geez.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
Intel Hex. Anything less is for quiche-eaters.
Red to red, black to black. Switch it on, but stand well back.
It might be possible to write OS in those loanguages. MS is trying to do it in C#. The project name is Singularity. But I agree that OS in not the target domain :)
Why do they always insist on this bad syntax? Why can't they write
CmdLin cl = CmdLin.new(argc, argv);
This way you can think of CmdLin as an object, new is just a method that returns a new instance. Voila, one keyword removed, and much cleaner syntax. This would not even offend the Java people because they can have the same syntax with a static method.
Open Source Alternatives
C# is D flat.
From my friend harmony7.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Is this a funny troll?
D has always been a better (higher performance; less legal risk; easier to develop; more stable; more complete) alternative than Mono.
And on non-windows platform's it's always been a better alternative to C#.net.
IMHO, though Ruby + C extensions is the most productive environment.
Duck typing is a retarded name for something that does not exist. Its just plain old strong dynamic typing. And that does not lead to productivity gains. It just leads to runtime type errors and long term maintainance headaches. This ridiculous notion seems to be because people compare static typing as implimented in java to dynamic typing as implimented in ruby or python. Try haskell or ML before blindly repeating nonsense.
Most of the productivity gains of high level languages come from having advanced data types available, and extensive libraries to do things you have to do by hand in lower level languages. It has nothing to do with static vs dynamic typing, or smalltalk style dynamicism vs compile time metaprogramming. Either can be used in a productive language, just because ruby uses dynamic smalltalk inspired design and is a productive language, doesn't mean only dynamic smalltalk inspired languages can be productive. You'll notice that smalltalk obviously has the same smalltalk dynamicism ruby does, yet ruby is more productive. Why? Because ruby provides more high level abstractions to save you time.
Picture this scene... Darth MasterProgrammer standing over Luke RookieProgrammer... [If only you knew the power of the STL!!!]
I see this time and time again. Programmers bad mouthing C++ because they don't understand the power of the language and really don't understand the STL.
As for compilers being slow, it really shouldn't matter that much unless you truly are a rookie and need to compile after every line of code and run a test just to make sure it compiles much less runs. I would much rather have a compiler that's been working in the field for years on all types of projects not just sample, simple test case projects.
The primary reason for stack class allocation is that you may need to do your instancing at interrupt time or in a trap handler.
Consider the case where you have a memory shortage (but interrupt stacks are preallocated, per interrupt), and therefore you cannot do an allocation, but want to run the current operation to completion.
Consider also the case where you might be using a zone allocator, and you cannot expand the zone of zones, because in order to do so, you' need to handle a trap at ring 0 in a trap handler (i.e. a user page fault followed by a kernel page fault).
The reason that these things wuld not be allocable at interrupt/trap time is that the allocations may block, and, if they do so, you could effectively end up blocked with interrupts disabled and no way to get back from it.
The alterantive to this is that you would have to fail the request and back out your state all the way back (fail gracefully out). The problem with that approach is that now you have to put error checking around all of your function call graph hat could eventually result in potentially failing allocations, and deal with the performance degradation that might result (speculative execution on a PPC would make this effectively free, but on an x86, you would pay a fairly seiors penalty).
There are three approaches commonly used in handling memory stavation situations:
(1) Block until the memory is available
(2) Fail the allocation request, and be prepared to deal with the failure, and then hope that by backing off, you don't lose unrecoverable state (e.g. if I read a hardware register, that might signal something to the hardware that would preclude me restarting the operation - for example, the AMD Lance Ethernet hardware), and that it's possible to redrive the operation
(3) Djikstra's Banker's Algorithm: allocate all resources that you might need up front, before attempting the operation (this is typically what's done with, e.g. the ring buffers associate with ethernet devices, rather than allocating mbufs at interrupt level).
The instancing of classes on the stack falls under a variant of #3: because you already have the stack preallocated, you are guaranteed that, so long as you do not exceed your stack depth, instancing the objects you need to instance for the lifetime of the transaction you are about to perform will always be successful.
I'm not sure if that's the argument the poster to whom you were replying was referring, but I hope that clarifies things for you.
-- Terry
A VM doesn't give any advantages, and no VM languages are as fast as C/C++/D. C# is 2x to 10x slower depending on the task. And being forced into a VM removes a languages ability to be used for systems programming, which if you bothered to read is what D is for.
Neither runtime safety checks nor a logical standard library have anything to do with a VM though. A native compiler can insert safety checks just fine when producing machine code.
Have any of you actually used the language yet? It's not a hack. By merging all these useful features to begin with a very useable result was attained. In the time you spent with that post you could have actually read the language specification.
Enjoy!
"Prepare for the worst - hope for the best."
real software engineers (that is, engineers who can legally call themselves engineers)
Where exactly is this possible?
By going to the site, you can clear see that they are using cold fusion (cfm extension). Cold fusion is based on Java. They seem to be using IIS for some presentation (main page) but the heart of the system is clearly Java based if you read the links. GP was correct.
Well. They're running IIS at MySpace. Somebody, please, for the love of good web design and stopping pedophiles, bring that thing down.
Haec merda tauri est. Ceterum censeo Carthaginem esse delendam.
I have a problem with GC in a systems language... specifically, using GC means that your functions will not necessarily run in bounded time.
For a lot of uses, particularly in user space, this is not a problem, but if you were to kick of GC in an interrupt handler or trap handler, or a number of other places, this would make it impossible for you to implement code that was guaranteed to take at most a maximum number of CPU cycles.
The upshot of this is that so long as it's possible for someone to write a driver that ends up running in your kernel, and which depends on GC functionality to not leak memory, it will be impossible for an OS written in that language to support hard real time.
I have to say that GC is marginally useful for systems work only if you can run it on a system that doesn't need GC -- so that you can get a read out of where and how you are leaking memory, fix the problem, and then disable GC before you ship. In other words, it's a great diagnostic, but only if you can run both GC and non-GC at the same time, and only if you explicitly scope your allocations (i.e. act like you are not running in a GC'e lanuage in the first place).
In other words, the intent of GC is to make programmers not have to know where their scope boundaries are, and you _must_ know this for systems programming tasks. So it doesn't deliver on its promise in a systems context, though it could be a helpful diagnostic for developers.
-- Terry
I noticed that a comparison to Objective-C is quite conspicuously absent from the list of languages compared to D. Why is it missing? Granted D seems to be a much greater change to C than Objective-C is but I can't help but thinking that one of the main attractions to D seems to be its heap-based garbage-collected object system. You can already get the object runtime with Objective-C. If you use GNU you can even have Boehm GC (which is apparently the GC that D uses). If you use Apple you will have to wait for Leopard to get GC. Another new Objective-C feature is the ability to use full C++ objects as instance variables in your Objective-C classes and do the right thing with initializing (calling the default no-argument constructor upon alloc).
On top of that, Objective-C actually includes tons of reflection information. Although Objective-C has protocols which are roughly equivalent to Java/C# interfaces they are almost completely unnecessary. In Objective-C one can query at runtime whether a method is implemented or not and if so call it. So whereas in Java you'd do this:
in Objective-C you can do this:
The difference being that in the Java case you have to declare MyInterface as containing the one doSomething() method and inform java that your object extends MyInterface whereas in Objective-C you merely need to provide a doSomething method on your object.
Basically that means that in Objective-C every single method effectively becomes an interface. You would not believe how useful this is once you realize it. Note that at runtime there is ZERO difference. In both the Java and Objective-C cases the object is being checked to see if it implements something. Same with C++ if you use dynamic_cast<>()
Granted every language has its niche and I'm sure D will find its. Objective-C's niche is definitely GUI programming. The ample reflection information allows for easy implementations of archiving (serialization) and most importantly key-value coding and the related action methods pattern. It's a pretty damn cool thing when your RAD tool simply outputs archived objects that refer to methods to be called upon certain actions simply by name.
malloc (and friends) don't run in bounded time, either.
For a lot of uses, particularly in user space, this is not a problem, but if you were to kick of GC in an interrupt handler or trap handler, or a number of other places, this would make it impossible for you to implement code that was guaranteed to take at most a maximum number of CPU cycles.
You cannot use malloc or new in those circumstances either. The correct way to do it is to preallocate all data needed for the interrupt service routine or real time critical section.
The upshot of this is that so long as it's possible for someone to write a driver that ends up running in your kernel, and which depends on GC functionality to not leak memory, it will be impossible for an OS written in that language to support hard real time.
Hard real time programming uses preallocated or static allocated data, not malloc or new (or GC).
I have to say that GC is marginally useful for systems work only if you can run it on a system that doesn't need GC -- so that you can get a read out of where and how you are leaking memory, fix the problem, and then disable GC before you ship. In other words, it's a great diagnostic, but only if you can run both GC and non-GC at the same time, and only if you explicitly scope your allocations (i.e. act like you are not running in a GC'e lanuage in the first place).
I used to think that, too, until I was forced into working with a GC. I've changed my mind.
In other words, the intent of GC is to make programmers not have to know where their scope boundaries are, and you _must_ know this for systems programming tasks. So it doesn't deliver on its promise in a systems context, though it could be a helpful diagnostic for developers.
All I can suggest is try using a GC for a project. My jawboning won't change your mind, but experience might.
0XA1_2_C35_4_5_6_5P6_Li
Give up? Why, it's an imaginary real. Yes, you read that right. Oh, and I specified it in hexadecimal, just to prove I can. And I threw in some underscores because you're allowed to do that too. Have you guessed what an imaginary real is yet? This is supposed to be the "simpler C/C++ replacement."
A good language strives to find a few constructs that solve multiple problems. A bad language takes the kitchen sink approach. C and C++ are not good languages, but wide deployment and support make them useful anyways. D does not have that, but the designers do have the luxury of learning from the mistakes of the past. So what the hell is their excuse?
algol doesn't support recursion.
CPUs put a lot of stock in branch prediction; due to the nature of OOP languages like C++, Objective-C (I like this one), and D, this doesn't work. The way virtuals and class inheritence works, functions are necessarily dealt with as pointers; the function is pointed to by pointing to a master class object, basically. Here's a C reconstruction:
struct myClass_members { // constructor // destructor // member function
// Data // Pointer to a list of members as above // an integer value
struct myClass_members *(*alloc)();
void (*destroy)(struct myClass *);
int (*my_member)();
};
struct myClass {
struct myClass_members *call;
int my_value;
};
What you do is initialize a constant myClass_members (called myClass_Object here) with a bunch of pointers to static functions in one source file; then call myClass_Object->alloc to create a new one (we'll call it my_inst). Then do my_inst->call->my_member() to call the member, and similarly my_inst->call->destroy(my_inst) to deallocate the class.
Basically, OOP languages like C++ and Java use this methodology, but it's obscured through friendly syntax. What we can expose from the above is:
The whole "native execution speed" thing is bunk. Script languages are executed on a native bytecode interpreter, or JIT'd to native. The amount of work that goes into the execution is what you care about; as well as the utilization of the CPU's most powerful facilities. You can only justify OOP languages by saying that either A) the majority of the work doesn't involve making calls to other class members, and thus won't be hurt by this; or B) CPU speed doesn't matter. I hate argument (B); (A) I can accept, barely enough to tip my hat to you for having good software engineering sense.
Support my political activism on Patreon.
To me, languages like these (C# is a bit similar in some cases, even moreso the upcoming C# 3.0) offer you the tools for special circumstances, but it doesn't mean you have to use its entire toolbox in every application you develop. For example, you don't have to nest your functions as soon as you'll be able to, or even learn how to do it. However, chances are that when you run into a language problem you think "it would be damn nice if you could design a program like this" -- then some basic research of D's feature set would give you an "aha" moment and then, in that case, perhaps let you try use one of its more obscure features.
When I think of language complexity, I think of needlessly much code to do quite little or strange design from e.g. mixing up an object-oriented design with one that isn't, which feels much more like C++'s territory than D's.
Beware: In C++, your friends can see your privates!
I wasn't happy about that either. Garbage collection in a language with destructors leads to wierd semantics, which is why Microsoft's "Managed C++" is a nightmare. I corresponded a bit with Walter Bright in the early days of D, but didn't press the issue.
What seems to work in practice is reference counting. GC gets most of the academic attention, but Perl and Python are both basically reference counted, and the result seems to be that programmers in those languages can ignore memory allocation. Java programmers have to pay a bit more attention, worrying about when GC will run and when finalizers will be called. Reference counting is deterministic; the same thing will happen every time, so timing is repeatable. That's not true of GC.
There are two basic problems with reference counts - overhead and cycles. Overhead can be dealt with by hoisting reference count updates out of loops at compile time, so that you're not frantically updating reference counts within an inner loop. Hoisting (along with common subexpression elimination), by the way, is also the answer to subscript checking overhead.
Cycles are a more serious problem. Conceptually, the answer is strong and weak pointers (in the Perl sense, not the Java sense), which allows the programmer to express things like trees. (Links towards the leaves should be strong pointers; back pointers towards the head should be weak pointers.)
In practice, cycles aren't a serious problem, because they're generated by design errors and tend to happen in normal program operation, so they show up early in testing as memory leaks. Dangling pointers, on the other hand, tend to show up in error cases, which is why they survive testing to become delivered bugs.
Ideally, you'd like to detect cycles at the moment they're created, at least for debug purposes. This is quite possible, although there's substantial overhead.
Attempts to retrofit reference counting to C++ via templates have been made, but they are never airtight. To get anything done, raw pointers have to leak out, which makes the reference counting scheme very brittle.
Sodding lot of good that does if the vendor of the VM is only going to build for Windows.
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
I was meaning more of a "do no evil" sandboxing safety check: allowing you to restrict file IO, etc. on a per-method basis
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
I have mod points and considered modding you up to 0 with underrated but
your argument is centered more around Microsoft's Ersatzjava than the
point you're superficially trying to make about the language lacking a
vm implementation. Hence the verdict of the original moderators is more
than fair.
Why don't you post that same argument without making any reference to any
vendors implementation?
Perhaps accidentally, you've just hit on one feature of programming language designs that I think does justify a new compiler front-end: ease of parsing for use with tools. Parsing the current monsters like C++ and Perl is so awkward and error-prone that few tools even get simple things like syntax highlighting 100% right (and the performance of those that do is... less than stellar). I imagine most of us are more interested in the underlying semantics of programming languages than in the specific syntax anyway, so can't we use a grammar that is easy to parse effectively, and then have tools from syntax highlighters to source code navigation to refactoring working quickly and reliably for a change?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
That still has nothing to do with a VM though. What is wrong with a compiler generating the same runtime checks in the machine code it outputs? Just because languages that do this are typically bytecode compiled languages, doesn't mean it can't be done in machine code compiled languages too.
Except you have to trust the compiler to emit that code; the security is essentially for the benefit of the program, not the user. Having all that extra information (and the ability to selectively deny some bytecode from being executed) is what really sets the VM above a natively compiled app. Doing the same with x86 would be very complex (and as a result probably very easy to bypass)
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
You already have to trust the compiler and the VM. What user is getting what benefit? The programmer already relies on the compiler and VM and libs, relying on just the compiler and libs is no different. The person running the code gets no guarentees either way, a VM doesn't protect him at all, unless he compiles the VM and the bytecode himself. He would get the same protection from the theoretical machine code compiler.
I'd have to disagree -- I see your point that technically there's no reason to trust the VM (you don't need to trust the compiler since your VM verifies the code anyway, and you make the decision [at least theoretically] to trust an app to access certain parts of your system), there is however, I think, reason to trust the VM: the vendor's reputation lies with the security and integrety of their vm (and their trusted libs).
A good example of this is Microsoft's XNA system: it lets programmers run .NET bytecode on the xbox 360. They have restrictions in place in the vm (such as denying ethernet and dvd access). They don't trust the programmer or the compiler, but the VM ensures that nothing bad happens. They don't allow PowerPC code -- I assume this is because it'd be very difficult (to impossible) to prevent native code from doing what it wants (the .NET bytecode is jitted, so I don't think they went the .net route to degrade homebrew performance). If their VM was compromised they'd be screwed, because the first native instructions would probably be lilo
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
so in canada we can. This is were I graduate this summer:
http://www.etsmtl.ca/english/index.html
the software engineering degree is acknowledged by the BCAPI.
http://www.ccpe.ca/e/ccpe_boards_2.cfm
more info there about the differences between comp sci, IT eng, software eng, electrical eng, etc:
www.computer.org
We should have been
So much more by now
Too dead inside
To even know the guilt
No, GP was not correct, and neither are you. Yes, CF was originally Java based, and they used to use CF. No, they are not using CF on Java. I'll leave the rest for you to research and figure out, but I do know what I'm talking about here.
Aside from that, "Java app" != "CF app", whether or not CF runs on Java.
--S
-- sigs cause cancer.
Lots of people have made the same argument about C++. The problem is that every programmer uses a different subset of the language, so you end up having to deal with the whole mess in a program of any real size.
It's a bad sign if you have a language that is so large, you have to start imposing artificial constraints like intentionally subsetting the language or following "design patterns" in order to manage the complexity.
If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared. S. Augustine
You bloody moron, MySpace is way more than just www.myspace.com.
Horns are really just a broken halo.
I remember seeing Usenet messages about D many years back, but I was always put off by the tone of the messages, always one of superiority. Those aren't the kind of people I want to deal with when asking questions about a new language or discussions about the technical advantages and disadvantages of constructs. Every time I brush up to something about D, I always encounter this tone and turn away.
Microsoft is not a user, your xbox example is about preventing users from using their own system. And while I am sure they didn't go the .net route specifically to degrade performance, the choice does degrade performance, jit compilation does not make it as fast as native. For what its worth, you can do the same thing with native code if you want, using the OS to restrict access. You could make an OS that will only execute "trusted" executables normally, and everything else gets limited access where many syscalls are denied. You could do this with selinux or any other similar system. None of this requires a VM at all, its just things that have been implimented in existing VMs. That does not preclude them from being implimented without a VM.
While D strings are mostly implemented as character arrays, it works quite differently than C. Here are some notable differences:
- D arrays are bounds checked. No accidental buffer overflows here.
- D arrays are dynamic, you can resize them and concatenate them together.
- D strings are D arrays, so they get the above bonuses.
- D has distinct 'char', 'byte', and 'ubyte' types. char[] != ubyte[]. When you use foreach to iterate over a char[]/string, it will expand each codepoint (or whatever they are called) to a dchar (which is a 32 bit character) for you. ubyte and byte are used for plain-old-data, instead of the unfortunate C char.
- Garbage collection frees you from worrying about where the strings go. No accidental memory leaks here.
There is also a nice alternative to the plain old strings called dstring, which gives you even more benefits of d's arrays like indexing and slicing (you can safely leave foreach alone with it). http://www.dprogramming.com/dstring.php
I've used both D strings and C strings, and D's strings just felt so much better.
CPUs put a lot of stock in branch prediction; due to the nature of OOP languages like C++, Objective-C (I like this one), and D, this doesn't work. The way virtuals and class inheritence works, functions are necessarily dealt with as pointers; the function is pointed to by pointing to a master class object, basically.
Well sorta but not quite...
But I think it is often not so bad... Moderns CPUs also can do "branch target prediction" which allows them to predict *where* an indirect branch will go (and not just *if* it will be taken). These predictions are be based upon the address of the branch... (So "class X" calling virtual methods on an List on Java *could* actually be done pretty well since the same code is always calling the same "List" methods). (Disclaimer: I deeply hate Java and try to avoid it)
And in C++ there is only need for a method to be virtual if it will be overridden... High performance code can just use templated objects instead of virtual functions. (such as the STL library in C++ with its flexibliity in iterators, allocators, and comparators). Object-oriented techniques are often not really needed at *runtime* and serve to make coding easier... (One could write a C++ program involving inheritance, base classes, and several different objects without ever using a virtual function... The compiler would know exactly what should happen... The OO techniques would server to make coding simpler, more readable, etc, etc)
I think you wrote your "#2" thinking about a function that processes different objects at runtime... I agree that this cannot be done efficiently, but I think this really represents a program design flaw rather than a programming language design flaw... If a program should be processing a large number of objects whose exact types are unknown at runtime, wouldn't it be better to first group them and them process them by type? (This would allow branch prediction to be done effficiently). Of course, this might be more difficult to implement depending on the application...
First off, which came first, the language or the IDE? (Answer: language. I'm pretty sure no one had an IDE to write Assembly or COBOL in, back in the day.) Secondly, here's a list of known Editors that may be used with D: http://www.wikiservice.at/d/wiki.cgi?EditorSupport
I've been personally using EditPlus2 to write D source for a few years no with no issue. I haven't even missed auto-completion or tips. Building has also been straight-forward, thanks to the written in D for D make utility "Build" (now commonly referred to as "bud"). And of course, traditional make works as well, if you feel so inclined.
It's always seemed to me that in DRM, the end-user isn't really the user in the system's spec. Although terminologically, the "user" is still setting the vm restrictions... just for a different value of user :-)
Well that's certainly true, but VMs do have the nice side-effect of having to compromise VM and OS security (as well as allowing heterogeneous real environments). I still maintain it'd be incredibly difficult to implement a native code security policy compared to a VM security policy
Global symbol "$deity" requires explicit package name at line 2. - If only $scripture started "use strict;"
Right, back in the day, we used to write assembly in hex and use BSAVE it to floppy. I'd like to imagine we've gotten somewhere since 1982. It was long before we had enormous APIs that we code around like we do today. We used to do sound by toggling $C030. Comparing those development processes to today's is absurd.
Given that C# and C++ serve our needs pretty well, I'd like to start looking at new languages as a whole development package rather than some syntactical sugar that might shave off 5 minutes on "Hello World". We live in an era where the languages matter far less than the development process -- at least on the level I'm talking about. When you're writing in EditPlus, it's no easier to write and manage 1m lines of code in D than it is in C++ or Python. I'd love to see someone to prove otherwise.
::Garbage collection in a language with destructors leads to wierd semantics, which is why Microsoft's "Managed C++" is a nightmare.
.NET project some time ago. Basically we used ISDN low level programming, and without an interpreting SDK the bytestreams of the messages are a pain in the ass to work with, and all SDK's are for C++, so we created a nice object model in Managed C++ that the C# main application could then use.
::What seems to work in practice is reference counting
Really? I had to use Managed C++ for a part of a
I found the managed C++ syntax tio be pretty nice, given the constraints of C++ to start with. Damn nice, to be exact.
What does NOT work, is reference counting, except in the eyes of some programmer without a clue. Reference counting can not be used for any caching that should release items under memory pressure (which I happen to write a lot), and reference counting is deadls in case you have systems like a pointing to b pointing to c pointing to - a. Circular references get never collected.
Happens a lot to me. I often build trees of objects (A contains a list of childs, contains a list o childs) and any object has a pointer up to it's parent. Normal GC will release the whole tree the moment it is not reachable anymore, a "oh so working" reference counting GC will happily keep htat crap in memory, as there are always references.
SOmehow your programs seme to be simplistic - I run weak references and circular references basically in every project I do. But then, I work on database middleware, not exactly primitive web pages.
I agree that the entire development process is the big picture. I think D needs an installer that takes care of the compiler, ide, and creates a templated project for you so that there is no barrier to getting a problem to work. Make no mistake that D is good technology, though I agree that this is where effort needs to be put right now.
This Wiki Feeds You TV and Anime - vidwiki.org
I've never heard anyone complain that a language feature is too powerful. But C++ templates got so powerful by accident rather than by design, and any nontrivial metaprogramming with them requires fiendishly ugly code.
Actually MySpace runs on .NET - Handling 1.5 Billion Page Views Per Day Using ASP.NET 2.0
Apparently the move to ASP.NET went quite well with CPU usage dropping from 85% to 27% according to that post.
MySpace is in the process of developing Java5/Hibernate3.2/Wicket applications.
Horns are really just a broken halo.
would be popular in Japan, I'm sure.
Especially among teenagers and otaku. (And geeks who think that otaku is equivalent to geek.)
are the only problem you mention of substance.
They are a problem of substance, however.
Unicode is not the solution it should have been, and surrogate pairs is the evidence of why.
Another feature which wasn't mentioned is that similarly to Java, types in D are generally sized in a standard way. It's not like C where an "int" might be 2 bytes on one platform, 4 on another and 8 on yet another. And unlike Java, they don't sacrifice the unsigned types.
Karma: It's all a bunch of tree-huggin' hippy crap!
Agreed. The main problem with GC is that it almost solves the wrong problem.
The problem GC attempts to solve is memory leaks. Memory leaks occur when there is a divorce between the semantics of two operations, one of which consumes a memory dynamically (the allocation), and the other which is required to clean up the consumption (the deallocation). This is a subset of another issue--handling resources (e.g., open a file, you must close it; lock a mutex, you must unlock it).
The problem is bigger than "new" and "delete" type semantics, which garbage collection addresses. If you consider a linked list in java, for example, you have the potential for memory leaks (allocation in the list, removal from the list). So java will "probably" clean up your news--big deal. You have the same exact problem popping up again in any data structure. If you can forget to delete, you can forget to erase.
The proper way to address this issue is to use RAII. The RAII approach requires the language to support resource cleanup semantics. This is why java sucks so bad--you can't do RAII. But you can in C++. And you can in D.
Now if only it had the Visual Basic syntax... I've worked with so many languages, but I have to admit that I find the VB syntax the most 'clean'(readable) syntax there is.. But I wish the creators of 'D' a lot of luck with their 'new' language.. ;)
I've been messing around for a couple hours now trying to compile gdc against gcc-4.0.3 in Gentoo amd64 and it's just not happening. I ran into an issue where it had a int and size_t mismatch, an undefined cpu symbols macro, and after hacking these the build died complaining it thought that I was cross-compiling gcc.
I've given up for now. Maybe if D hits the 1.0 magic number somebody will fix it for 64-bit systems and add it to portage. Oh well, I would have liked to start playing with D but I guess I'll just have to wait.
Clickety Click
Deciding how to allocate an object you create would better be left to the compiler. It's not a hard analysis to do to make sure the reference to an object never escapes a particular (possibly recursive) function call, and in that case the object can be allocated on the stack. Leaving this decision to the compiler makes sure that if someone changes the code you're calling so it suddenly starts to keep references to the objects that you've allocated on the stack and are passing in, it won't break. In big C/C++ programs, this kind of error is quite common since it takes a lot of time to track down all callers to a function you're modifying and understand their allocation patterns. Tracking down errors like this can be extremely time consuming and programming languages that allow these errors are in my opinion wasting valuable programmer time that could be spent optimising code instead.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
I disagree that ease of parsing has a big impact otherwise we would all use Lisp..
OTOH, there is probably a good middle ground between Lisp and overly complicated syntax like C++ or Perl.
D or Scala fits in this description.
No shit, Sherlock.
c fm/ArticleID:4477
http://www.fusionauthority.com/Community/Article.
You're fighting a losing battle on this one. You might be surprised at what they run (and don't run) over there, in spite of appearances.
--S
-- sigs cause cancer.
I would *love* to know where you got that from. Care to provide a source?
--S
-- sigs cause cancer.
P-code was a popular VM a few decades before anyone thought of JVM as a new revolutionary concept.
I rather like your link a lot better than the one I posted. :-) Thanks for that...
--S
-- sigs cause cancer.
That's Common Language Runtime and MSIL (Microsoft Intermediate Language). Also, MySpace was never front-ended by Java; they were ColdFusion 5 and opted to convert to BlueDragon.net running on ASP.NET 2.0 instead of moving to CF6/Java. I can't believe you bothered to post that crap.
Although it may be that 1m lines of D code can do more than 1m lines of C++ code:
http://www.digitalmars.com/d/lisp-java-d.html
"For C++, the shortest development time was 3 hours and the shortest program had 107 lines of code."
The D implementation "took me 1 hour and 15 minutes, from reading the statement to finishing the program. The program was just 55 lines long"
Of course, that is just one example, but I think it reveals something about the D language - it was designed to have clearer syntax and to be harder to write common bugs than C++ code.
YMMV.
MS provides a rather neat extension of the C# language: Spec#.
Spec# adds the method contracts and class invariants of Eiffel, the checked exceptions of Java, and introduces non-null types. But the thing that at least I find the most interesting, is the idea of static program verification.
looking at the comparison:
.NET or Java - having to program the same sets multiple times due to a lack of multiple inheritance - basically once for each combination of a set of features that can occure together or separately.
C/C++ do have try-catch-throw stuff now I thought (it says they don't)
D doesn't have multiple inheritance, that is my biggest problem when programming
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
So, what will we see next? D#? E++? Or some other F*** language? :)
You crack me up. :)
:)
Look up dirac beep. If you already know it give yourself a thousand scifi geek points.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
- Allocating objects on the interrupt handler's stack.
- Allocating objects in a zone that is reserved for the interrupt handler.
It seems that the first is just a special case of the second, where the zone is also used for other things, such as the return address[1]. With Objective-C, at least in the GNU implementation (not in the Apple implementation any longer, sadly), you can define a zone which is a simple wrapper around alloca, so that you are allocating objects on the stack. This is a library feature, however, not a language feature, which is what I was saying to the original poster; it's better to have a small language that allows you to easily extend it to do things that the designers might not have thought of than a big inflexible one.The one feature I see in D that Objective-C lacks is a good template mechanism; being a dynamic, late-bound language, the assumption with Objective-C is that anything you would do with templates, you would do at run-time. While this is very flexible, it looses something in terms of speed, and means you can't do a lot of the nice meta-programming things at compile time that you can with a language like Lisp. This is not a problem for a language like Smalltalk, because Smalltalk is designed to run in a VM, so JIT compilation blurs the boundaries between compile time and run time a lot, but Objective-C does not have this luxury.
[1] As an aside, I consider having unified control and data stacks a design flaw in a language, but that's a different issue.
I am TheRaven on Soylent News
I remember when Delphi 1.0 came out in the mid 90s - people refered to it as "D" - it had the power of C++ in terms of being fully object oriented, allow for pointers (unlike VB) etc. yet was easier to use, especially for RAD. In short - been there, done that.
I don't like the links in this post, they are D-links...
Smalltalk is /famously/ productive - I don't know why it fell out of favor but, if you're making the claim that Ruby is more productive casually, I think you're mistaken. Ruby may be easier to learn for someone who knows another language and be in /that/ sense more productive, but I'd be careful of going around saying Ruby is more productive.
Well, Canada is a good example: Before being able to legally call yourself and engineer (yes, this includes a software engineer), you need to have graduated from an engineering program accredited by the Canadian Engineering Accreditation Board. Once you graduate, you need to pass an exam and an interview from the engineering regulatory body in your province (for instance, in Ontario, it would be the Professional Engineers of Ontario). Only once all of this has been achieved, you can legally call yourself an engineer.
This appears to be what happens when you take the ASCII-puke aspect of Perl out, and then combine it with a bunch of weird stuff. I understand C, C++, Java, PHP, and I can't follow that at all.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
What, no Macintosh version? Boooring.
Other I remember include:
"S" from Bell Labs for statistic analysis package.
"W" at Stanford for UNIX bitmap graphics window software circa 1985.
"X" at Stanford for client-server graphics "extended" software from same Stanford research group.
"X" and "W" were combined into XWindows and managed at MIT for many years.
All three of these were plays on UNIX's "B" and "C" language naming.
It was never in favor, pretty hard to fall out. Its fairly obvious that ruby is more productive, go try it. Its a higher level language with more high level abstractions. This isn't taking anything away from smalltalk, which has better development tools and unlike ruby is actually fast enough to be used for non-trivial tasks. But ruby is more productive.
Good Luck lobbying the new language.
Piece of advice - especially since D boasts linking compatibility with C/C++ - is to start using it in existing C/C++ projects (along with C/C++) to pilot it in real world applications.
C is fine as it is - it fits its designers' purpose. But C++ really annoys me. I am all for C compatibility, but in the end, some C++ projects start looking like written in C and vice versa: some C projects build completely on OO paradigms. (Just recall GTK & GNOME.) Ojective-C often fits the bill but few know about it.
Also, as Perl programmer, I welcome inclusion of primitive data structures ("associative arrays, array slicing") into language itself. C++' STL really does good job obfuscating programs up to the point of complete unreadability. Also its syntax makes any kind of serious programming really hard: you cannot make STL using code both readable and optimal. Overloaded operators is curse.
All hope abandon ye who enter here.
I mean, when do you ever hear of a tape-recored language? The processing, storage, and transmission of a language is somewhat independent of the language's grammar.
Sorry, but this is written in an email language. You'll have to render it to a pixel language to display on a CRT, and then illuminate it as a light emitting visual language for eye processing.
There's all the stuff about making sure the superclass constructors are called, in the right order. Getting members initialised, in the right order. Coping with exceptions (and knowing when the object is 'live' and will need to be garbage-collected). In a language like Java with inner classes, it'll mean keeping track of the enclosing instance. And so on. A constructor may look superficially like another method, but it's not, and trying to pretend it is has more at stake than a 3-letter keyword.
What you're describing looks more to me like a factory method. This can do things no constructor can: in particular, it may return a subtype of the advertised type. It may also return a reference to an existing instance, rather than creating a new one, to allow for object sharing or reuse.
Both constructors and factory methods have their uses, but I wouldn't want to see them confused.
Ceterum censeo subscriptionem esse delendam.
D may have many qualities, but orthogonality is not one of them.
The combination of a MMU with memory protection and a CPU with >1 rings is a VM. All new x86 and x86_64 CPU's even use a different instruction set (RISCish) internally than they expose to the programmer.
I will *not* code in P.
I won't code in poop either.
Well, you might like 2e then, esp. once I add some object oriented capabilities to it. I designed it to be super simple (it is mostly just an expression evaluator), yet flexible enough. Currently only interpreted, but I may eventually code up a compiler for it (most likely using C as the intermediary language).
What is the licensing for this language? I've found lots of copyright notices, but no licensing information.
What's easy for a computer to parse isn't necessarily easy for a human to parse. Languages that have a very simple syntax, such as Lisp, can be difficult for people to read because of their homogeneity.
Now, this doesn't apply in all cases, of course. A lot of languages have syntactical cruft they've picked up from their ancestors (those that can trace their lineage back to C tend to be the worst offenders). However, I think there's an advantage to some complexity, if used correctly, and if this makes it a little difficult to create syntax highlighting, then perhaps that's a reasonable trade off.
Oops, bad example be be. BUT there are still large sections of MySpace "under the hood" that are pure Java, your shit for brains A-hole.
Horns are really just a broken halo.
There are major problems in terms of COST to run .NET for such a large website, which is why the JAVA faction inside of MySpace is gaining ground. Already, there are major portions of MySpace coded in Java AND .NET. (CF stuff is long gone). Look, calling you an A-hole aside, I'm not joking around. MySpace is a hybrid of .NET and JAVA, with the JAVA camp gaining ground.
Horns are really just a broken halo.
We can resolve this by effectively eliminating the control aspect of the unified stack by translating everything into a continuation passing style and ignoring any control mess (no funcall return information will ever be used) on the unified stack.
If we can precisely discriminate between control data and object data in the stack, we do not even have to waste time proving the deadness of any control pointers, should we wish to do garbage collection.
(An easy approach would be to copy all the live (or probably live if we have to use an imprecise discriminator) data from the stack to the heap at intervals and flush the stack (i.e., reset the stack pointer)).
A number of PUSH-y implementations of languages amenable to being (re)written in CPS have been made for experimental and academic reasons, in part because they can easily share stacks with other languages, which makes it easy to compile into a variety of intermediate languages (like those supported by gcc, for example),
and there are one or two examples with extensive and useful libraries.
Finally, for my part I think it's unfortunate that hardware support for stacks is almost always a pointer to the end of a linear array, rather than a pointer to the head of a singly linked list.
>Both constructors and factory methods have their uses, but I wouldn't want to see them confused.
//in D it is auto not var, but auto isn't a good keyword.
Why not?
You say that constructors are different than normal methods because they do lots of stuff, but factory methods usually also call a constructor behind the scene to build the object which is returned so while normal class methods they do the same thing usually, so why make an artificial difference?
I really like the syntax
var cl = CmdLin.new(argc, argv);
Simple, consistent, and still with 'new' which can be easily seen/searched.
Oh, I agree entirely that parsability by machine is not the first priority for languages -- far from it, in fact.
However, I think there is a strong correlation between easily machine-parsable languages and languages that don't have special cases and traps for the unwary all over them, probably because simplifying the formal grammar tends to help both goals.
Consider Perl, for example: it's often criticised for being "write-only" on account of the complexity of its syntax, and often for having quirks and only a reference implementation to define it rather than a formal standard. It's also a nightmare for other tools to parse for exactly the same reasons, and consequently it has relatively poor support from tools other than those that come with it by default.
Consider C++: it's often been criticised in recent years for the cumbersome syntax of its templates, and to give credit where it's due, the D language does seem to do this rather more neatly. C and C++ are also often criticised for their frankly bizarre declaration syntax, particularly where pointers, arrays and functions are present in combination. The classic is the difference between
which defines an object c of type MyClass and default-constructs it, and
which defines a function c that takes no parameters and returns an object of type MyClass. This sort of nonsense is just as much a pain for the human reader as for the language tools that need to disambiguate.
Other languages have similar issues. Thus I don't see that simplifying the formal structure of language to make tool development easier is necessarily in conflict with making the language easier for humans to use. If anything, the opposite is true.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Hear, hear!
The E language has a very interesting and powerful approach to concurrency that avoids many of the trickiest problems with threads. Have a look at the paper Concurrency Among Strangers: Programming as Plan Coordination by Miller, Tribble, and Shapiro.
Not sure about the language itself, but there are interpreters with various licenses available including one on Sourceforge with unknown license: http://sourceforge.net/projects/openapl (feeling too lazy to make a link, sorry)
BTW, J is the descendant of APL which doesn't require some kind of wacky keyboard to use. It's probably the one to look into if you are looking to pick up APL on a standard PC.
Information doesn't want to be anthropomorphized anymore.
The difference between 1 & 2 as you've posited them:
1. Allocating objects on the interrupt handler's stack.
2. Allocating objects in a zone that is reserved for the interrupt handler.
is that in the second case you could suffer from zone exhaustion, and be unable to refill the zone at interrupt time. This may occur because there are no pages available, or because refilling the zone would block, or because the zone of zones is exhausted.
If you could override the allocation with an alloca() to force it back onto the stack, then this would not be an issue; however, the general reason for using zones is to obtain type-stable memory.
[Aside:]
You do this to prevent someone else's double frees or use after free from shooting you in the foot: you are guaranteed that the damage will be scoped to the zone, and therefore limited to the object type in the zone. So as long as you are not talking about generic sized zones (i.e. zone allocators typically implement a set of "powers of two" zones for random, temporary allocations), then any problem you have can be located relatively easily, since it's scoped to a fairly small amount of code.
[/Aside]
I don't think, therefore, that it's really going to end up very useful to map a zone to an alloca() in the general case, since you might as well use stack declaration or alloca() directly; the exception to this would be object scoped languages (e.g. like the one we are discussing here), to permit abusing the override for a subclass of the object acting as the object type (this would probably be considered "bad form", from my reading about the language).
Hope that clarifies what I said a bit...
-- Terry
Bounded time, malloc, new, using GC in a project..
Actually, you can run a malloc or a new in bounded time; the issue is whether or not you have an allocator that's capable of doing it or not. If you preallocate objects to your zone, you can perform the operation in O(1) - the amount of time to take something off the free list - and you can do it without locking, so long as you utilize per-CPU pools for your object freelists. If you want to grab one and the freelist is empty, you can fail the operation and force it to retry later (or you can decide not to reenable interrupts until the top end has completed processing and returned the free work item to the interrupt handler one-item-pre-cache).
My personal preference would be to preallocate as much as I will need to run the operation to completion - and no more. It's OK to have a data source that's noisy and generates a lot of work items, but only if it happens at soft interrupt.
For things like network drivers, the delyed reenabling of interrupts is the best bet. First of all, you likely want to take one interrupt and poll like hell until there's no more data; an 8MHz PC can keep up with 115K baud serial data (barely) if you do that, whereas direct interrupt processing will cause it to lose it. Second, you don't want to reenable the interrupt to let it reinterrupt you if you can't drive the data all the way to the application anyway; reenabling the interrupts prematurely leads to problems like receiver livelock, which has been known about for years (google for "livelock" "networking" "DEC" "WRL" "Jeff Mogul").
As far as using GC in a project, I've done it, and I've seen it done (Objective C supports GC in the next release of Mac OS X, as reported on Apple's web pages, so I'm not letting any cats out of any bags). My personal opinion is that once one framework you need becomes "GC-only", there will be no way to make code that correctly operates as both GC and non-GC code. The problem is that programmers are human, and they make mistakes, and if the mistake happens to be that you forget to release some memory, but it's OK because GC catches it, then you will never be able to go to a non-GC world and depend on that code again. For me, that means I can never take that code, or a part of it, and put it into an environment where GC isn't possible because I need to run in bounded time, without debugging it, or doing a full branch path analysis on it and generating test cases to exercise all the code paths; at that level of cost, I might as well just rewrite it from scratch.
A real world example of this was the use of the TSM (Tivoli Storage Manager) Java edition on the Whistle/IBM InterJet (I worked at Whistle, which was acquired by IBM). The TSM had an insane memory footprint, and we never shipped it as a product. While the GC in the Kaffe JVM kept the footprint to about 1/3 of the memory that the Sun JVM's GC did at the time, that was still twice the amount of physical RAM we had budgeted for the box. This was all user space code, but driving up the COGS of a product by 11% on the off chance that we would be able to later sell a service add-on for TSM to a percentage of the people who bought the product on its own merits was just bad business.
-- Terry
The non-determinism is orthogonal to GC versus malloc(). Neither of those mechanisms are deterministic. In order to write a time-critical handler in a GC'ed language, you do the same thing you do to write a time-critical handler in C: allocate from a fixed reserve pool of memory. Note that this should almost always be an applicable technique, for the simple reason that its rare to have a function with fixed time-bounds but variable space-bounds.
Take something like an interrupt handler. In the Linux kernel, you can't sleep in a bottom-half. All the memory allocation primitives sleep by default, so you have to call kmalloc() with GFP_ATOMIC. GFP_ATOMIC services the request from a pool of reserved memory, and fails if that memory is exhausted. In a kernel written in a GC'ed language, you could do the same thing. Grab some objects from the GC at startup, and grab one of those objects in the trap handler instead of calling the GC and potentially invoking a collection.
A deep unwavering belief is a sure sign you're missing something...
Visual Basic 3
RAII only solves the resource management problem for a small class of resources: those with dynamic extent. However, many objects need to have indefinite extent. Consider a C compiler. RAII is appropriate for a file handle in a function that opens a file, reads in the source code, and immediately closes the file. However, its completely inappropriate for the nodes of the abstract syntax tree that it creates from that source code, and passes to the rest of the compiler.
That's why C++ has smart pointers --- it handles the resource allocation problem for objects with indefinite extent (at a substantial cost in performance, btw). It's also why every non-trivial piece of C code has one (or more!) reference-counting mechanisms in place. In practice, GC is much simpler, and usually faster, than these ad-hoc mechanisms.
A deep unwavering belief is a sure sign you're missing something...
I agree with you in general. A lot of languages have complexity that they don't necessarily need. One of the pieces of syntax that really annoys me is the 'new' operator in Java and C#, but I digress.
Whilst simplifying the formal structure of language is a good goal in general, I think that sometimes simplification can reduce ease of use. For instance, most languages use a combination of prefix and infix forms, whilst it would arguably make for a simpler grammar by just sticking to prefix notation. Similarly, some languages mark whitespace as significant (notably Python, but also languages like Haskell), which adds to readability (or at least, doesn't detract from it), whilst possibly being more difficult for a machine to parse.
Or, to put it another way, simplify a language too far and you get Lisp, which can be rather homogeneous and difficult for a human to read. So some complexity in a language's grammar would seem to be beneficial. Too much complexity, though, and you get the problems you illustrate.
You keep on believing that, bro. Me, I know better, and I prefer to live in reality rather than inventing my own ideal world. Even if you *could* manage to provide respectable sources indicating that Java is "gaining ground" at MySpace, I guarantee you beyond the shadow of a doubt that I can canonically prove you (and said sources) completely wrong.
You can stand on your Java soapbox all you want, but claiming things that simply aren't true isn't going to help your case.
Care to try to come up with some sources? I'm game for shooting them down. Hell, at least say what part of MySpace it is that you think is written in Java!
--S (The thing I hate most about Java tends to be the closed-mindedness of the developers that come with it. Talk about drinking the kool-aid...)
-- sigs cause cancer.
No, not the language. The features sound nice. But I really really hate the name. Same as 'C'. Why? Search for 'D' in Google (or anywhere else). 'C' was pre-internet and pre-search engines, so the name is excused, but today I'd make sure that any program I write or I am responsible for would have at least four letters.
The key success factor that D needs to succeed, is to have what c++ lacks: a multi-platform GUI library that comes as standard with the language.
This way, D can move away from being a simple "language" (like c++) towards being a complete "platform" (like java/sharp). C++ comes with a good standard library, but that's it. D must come with a good standard library that also covers graphics! Just wrap any multiplatform GUI toolkit (like WXWindow) with D classes, and ship that with every D compiler.
Of course, an IDE would also be needed to ensure success, but let's start with having a standard GUI library first.
Congratulations for inventing Eiffel, 20 years later, without good MI.
OK, the note above is a bit of a troll. But objectively, most of the interesting and cool features of D were in Eiffel (DbC, well implemented generics, garbage collection, fast); and I don't miss most of the features that D has "over" Eiffel (like static overloading instead of just dynamic one; I think static overloading is more a liability than an asset).
However, if D catches on and gets a larger community than Eiffel (which implies more tools and libraries) I may seriously consider using it.
Not much else to add, ah yes: thanks Walter for building a *sane* language which may eventually replace C++ for many tasks..
I think we're in pretty close agreement (even on the digression about new :-)).
In general, I tend to think that in practice, very uniform or punctuation-free languages actually become harder to read, just as those with too much clutter do. I also think the places you need punctuation differ depending on the programming style: a lot of functional programming languages don't use () in a mathematical way to denote function calls, for example, while it's common to do so in procedural languages.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Libraries, compilers, etc... You know like that fancy Microsoft compiler which has a license that specifically states you can't write software using their languages/compilers the competes with any of their own products. For instance, gems like this ... You cannot "distribute Distributable Code, other than code listed in OTHER-DIST.TXT files, to run on a platform other than the Windows platform" and "The software contains code that you are permitted to distribute in programs you develop if you comply with the terms below." ...oh don't get me started.
I can't believe you don't know this
Just because he didn't mention it, that doesn't meant that he doesn't "know this". Even if he doesn't, why is it so difficult for you to believe it that you find yourself incapable of doing so?
They combined CJK but failed to combine Latin, Greek, and Cyrillic.
Glyphs were originally intended to not combine, but of course that wasn't practical. Eventually they added a set of composition rules for the CJK radicals, and a set of radicals.
Lots of tradeoffs where the first guess was wrong. But we needed the "univeral" character set sooner, rather than later.
Speaking of Eclipse... how come it lacks a "compile this file" feature?