To read all comments associated with this story, please click here.
That's true for dmd which you have to download yourself but there's no licensing issue for gdc.
Well, these are not true filesystem, so I tend to agree that this is not really a bug that normal commands fails: after all a 'ls -l /proc/sys/kernel/osrelease' is lying to you by reporting a size 0, in fact it's silently failing..
But sure for a system programming language this is an issue, in my opinion the correct way to fix this is either to add an option to read so that it doesn't try to access the length of the file or to provide another function read_svfs (read special virtual fs) which does the same thing.
Well, new system, new issues, this is true whatever the system (I remember having a bug in Java's GC back in the data), I'm not sure you really tried very hard to have this issue fixed, did you enter a bug into bugzilla?
There are very real problems with D:
-the incompatible split Phobos/Tango (worked on but has been an issue for a long time)
-the not very efficient GC (I'm not sure that this is solvable: this is a price to pay for C compatibility..)
-the syntax: it's better than C++ or Java sure (not hard!), but when you compare it to Scala, it's not that good..
You do make a valid point. However, there was no physical way of doing it from what I could see. I cant remember how I did it at the time, but knowing me, I would have tried opening the file as a stream too and waiting for EOF, and that wouldn't have worked (or I wouldn't have posted this). And I tested it on C and perl, and other languages, and all provided a means of reading them.
So evidently, they weren't reading the files properly (or they were doing it in a really advanced way).
Either way, I got put off by only 1 response, that acknowledged why the problem existed, but didn't even attempt to rectify it and making the functionality possible. Its no good telling a developer you cant do it because its a 0 size, but not trying to fix the problem by working around it (or offering new functions). And I was in no way inclined to help a project, whose only compiler at the time was totally closed.
Its interesting to hear about more problems though you are having. I think that ultimately, by the time they get their act together, they will also have to compete against C++ 0x and new generations of C# and Java.
That is just my personal opinion though anyway






Member since:
2008-01-20
Sorry, but I don't think D has much of a chance. I had bad experience with Digital Mars earlier on. Firstly, no distributions wanted to include the compiler in their repositories because of licensing issues. So that was one big problem for me.
Secondly, seriously, they told me that being unable in read files in /proc, /dev or other such linux filesystems is normal behavior (and even worse, they explain why, and it never seemed to click with them why its incorrect). http://www.digitalmars.com/d/archives/digitalmars/D/bugs/594.html is the bug. Because of it, I needed to run the "cat" linux command to read some files. In fact, D was the only language that behaved this way, and I wasn't going to waste my time arguing either. Because to me, it seemed like it was being developed by a bunch of university students.
Sorry, its a great language, but there's too many issues. Mine was a very basic straightforward problem and nobody considered it a problem (and it was my first problem too), imagine having to work around these small behaviours on MAJOR projects. At the end, it really just makes more sense to use C# and mono. The licensing may be a bit iffy, but at least the behaviour makes sense, its works in more places, and more people can code it in.