Re: Advocacy (Was: Who here actually uses D?)
On 11-01-02 03:35 AM, Walter Bright wrote: bearophile wrote: But D is not currently the best fit to write a kernel Based on what? Currently the issues I see with D in kernel land is a fat runtime and type system. Although you can reduce the runtime requirements, you end up losing alot of features and might as well be writing in C at that point anyway. I don't think D as a language is a bad fit for a kernel (conceptually I think I'd be a great fit for a kernel). I think the bigger issues are the current state of the D+druntime implementations that are problematic.
D without a GC (Was: Advocacy (Was: Who here actually uses D?))
On Sun, 02 Jan 2011 21:57:50 +0200, Walter Bright newshou...@digitalmars.com wrote: Sure, but D has *optional* gc. If you want to, you can use D as simply a better C and it will compile to the same code as C does. The usual comeback to that is that Phobos depends on the GC, so a great part of the standard library was unusable without memory leaks. I think this is an interesting problem, and solving it could both prove that D *is* practically usable for nontrivial tasks without a GC, and provide a solution for those who can't or don't want to use a GC (you may have noticed how many upvotes the stackoverflow comment about people just not wanting to use a GC got). How much of D can you really use without Phobos? I imagine there'd be no problem in using it as a better C, but there isn't much appeal to that, compared to C++/STL/Boost. A practical No-GC D solution would probably have to include a standard library that works without a GC. Some ideas: * A while ago, it was suggested that there be a version(NO_GC) or something like that, and the standard library could be modified to work differently depending on that version flag. It's probably not practically possible, though, because some functions would not make sense in a GC-less context (lack of GC would require changing their signature/documentation), and the code would quickly become a jungle. * Forking Phobos into a new standard library based on STL-like RAII/refcount constructs (std::string, std::vector) instead of built-in arrays, etc. ** The biggest problem with the above idea is that we're back to typing long type names instead of having the luxury of built-in dynamic arrays/AAs. There could be a language mode (controlled by a compiler switch) which maps the syntax for built-in arrays/AAs to RAII/refcounting library types. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Advocacy (Was: Who here actually uses D?)
Travis Boucher wrote: Currently the issues I see with D in kernel land is a fat runtime and type system. Although you can reduce the runtime requirements, you end up losing alot of features and might as well be writing in C at that point anyway. If you're doing kernel dev, you'll most likely write your own runtime anyway. That's what one does with C.
Re: Advocacy (Was: Who here actually uses D?)
Walter: I'm afraid that's baloney, as I pointed out in the other thread. What you have said was about application code. It's not true for kernel code, where you need strict control on what, how, and if the compiler performs certain optimizations. I think that is a serious misinterpretation of the complaint. The complaint was actually that the high level abstractions that one can choose to use in C++ can be impenetrable in what they do. In D, if you want low level control, write low level code. It's that simple. This is true for C++ too. But he doesn't want high level abstractions in kernel code. So he has not much use for C++ and D too. But he wants more static analysis. Typed assembler is a waste of effort in a language like D, as you only need a few drops of assembler here and there. This talk says: http://www.linuxjournal.com/article/7272 The problem is that being the kernel has to do a lot of things that break typechecking. Which you see more in the kernel than in a lot of other programs. You end up having a lot of inline assembly which is obviously completely opaque. In the Nucleus of the experimental operating system Verve I have seen a good amount of assembly code. They are able to use so much assembly because it's not normal assembly, it's typed its assertions are often verified statically. So it's not completely opaque. In the D runtime I have counted 2100 lines of asm just for the array operations implementation, (that's unfinished still). asm code is uncommon in application programs, but it's clearly more than few drops. Those languages are failures at what they propose to do; they need years and perhaps decades to fulfill that. C#4 has contracts too, as a library: http://research.microsoft.com/en-us/projects/contracts/ But this page says something interesting: http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx Code Contracts Premium Edition: This version installs only if you have one of the following: Visual Studio 2008 Team System, Visual Studio 2010 Premium Edition, or Visual Studio 2010 Ultimate Edition. It includes the static checker in addition to all of the features in the Code Contracts Standard Edition. It means that if today you have better versions of Visual Studio, then you have a static checker for contracts. I have not used them yet, I will try to try them. As you see Microsoft is pushing some of its research in the Real World today. And regardless the usefulness of Verve today, they contain some quite interesting ideas. I'm not just an engineer, I like ideas too. Shutting the brain closed is stupid. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Code Contracts Premium Edition That's just hillarious. What's next, will the customers be forced to buy a dozen pointers in a bundle? If you try using more than 10 pointers in your app you'll get a pop-up saying you're can't do that in the trial version, upgrade now!. LOL!
Re: Advocacy (Was: Who here actually uses D?)
Limited offer: Increase your stack size, for only 49.99$!
Re: Advocacy (Was: Who here actually uses D?)
On 03.01.2011 16:19, Andrej Mitrovic wrote: Limited offer: Increase your stack size, for only 49.99$! LOL, BTW vendors should also like it: reselling already sold hardware to developers :) -- Dmitry Olshansky
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
Vladimir Panteleev wrote: How much of D can you really use without Phobos? I imagine there'd be no problem in using it as a better C, but there isn't much appeal to that, I don't agree there's not much appeal to that. D has quite a bit that makes C-style code much easier and more robust, such as the module system. C doesn't even have thread local storage! compared to C++/STL/Boost. A practical No-GC D solution would probably have to include a standard library that works without a GC. D can use the minimal library used by C in kernel dev.
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: It means that if today you have better versions of Visual Studio, then you have a static checker for contracts. I have not used them yet, I will try to try them. As you see Microsoft is pushing some of its research in the Real World today. And as I pointed out to you, their contract support is *fundamentally* broken. Furthermore, their static checker for contracts only works in *trivial* cases, as I also showed to you. This is not a technology that is ready for real world use. And regardless the usefulness of Verve today, they contain some quite interesting ideas. I'm not just an engineer, I like ideas too. Shutting the brain closed is stupid. Interesting ideas is not the same thing as usable/better for kernel dev. Interesting ideas are a dime a dozen. Getting them to work in a professionally useful tool is an entirely different matter.
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
On Mon, 03 Jan 2011 21:41:37 +0200, Walter Bright newshou...@digitalmars.com wrote: Vladimir Panteleev wrote: How much of D can you really use without Phobos? I imagine there'd be no problem in using it as a better C, but there isn't much appeal to that, I don't agree there's not much appeal to that. D has quite a bit that makes C-style code much easier and more robust, such as the module system. C doesn't even have thread local storage! You took my line out of context :) Of course D is better than C and can be used as a better C, but I was making the comparison to C++/STL/Boost. Well, it depends on which features you're after - if you're Linus Torvalds and hate abstractions, D minus Phobos would indeed be a better deal than C++/STL/Boost :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
Vladimir Panteleev wrote: You took my line out of context :) Of course D is better than C and can be used as a better C, but I was making the comparison to C++/STL/Boost. Well, it depends on which features you're after - if you're Linus Torvalds and hate abstractions, D minus Phobos would indeed be a better deal than C++/STL/Boost :) I should also point out that anyone who has the chops to build a kernel can certainly build a customized D runtime.
Re: Advocacy (Was: Who here actually uses D?)
On Sun, Jan 2, 2011 at 1:42 AM, Nick Sabalausky a...@a.a wrote: I don't have a link, but I read a post he made somewhere that explained the reason Linux kernal is plain-C-only is because, IIRC, they frequently need a very, very tight mapping between the source and the generated instructions. Partly for tight control over the instruction generation, and partly becase they often needed be be able to look at the source and know what got generated. I don't know, but I suspect D may be even further from C++ in than regard. Linus also doesn't want C++ to be used for Git. On Wed, 5 Sep 2007, Dmitry Kakurin wrote: When I first looked at Git source code two things struck me as odd: 1. Pure C as opposed to C++. No idea why. Please don't talk about portability, it's BS. **YOU** are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do **nothing** but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said to piss you off, but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really **would** prefer to piss off, so that he doesn't come and screw up any project I'm involved with. C++ leads to really really bad design choices. You invariably start using the nice library features of the language like STL and Boost and other total and utter crap, that may help you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic object model crap. So I'm sorry, but for something like git, where efficiency was a primary objective, the advantages of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage. If you want a VCS that is written in C++, go play with Monotone. Really. They use a real database. They use nice object-oriented libraries. They use nice C++ abstractions. And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess. But I'm sure you'd like it more than git. Linus Source: http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918
Re: Advocacy (Was: Who here actually uses D?)
Caligo iteronve...@gmail.com wrote in message news:mailman.348.1293955294.4748.digitalmar...@puremagic.com... On Sun, Jan 2, 2011 at 1:42 AM, Nick Sabalausky a...@a.a wrote: I don't have a link, but I read a post he made somewhere that explained the reason Linux kernal is plain-C-only is because, IIRC, they frequently need a very, very tight mapping between the source and the generated instructions. Partly for tight control over the instruction generation, and partly becase they often needed be be able to look at the source and know what got generated. I don't know, but I suspect D may be even further from C++ in than regard. Linus also doesn't want C++ to be used for Git. On Wed, 5 Sep 2007, Dmitry Kakurin wrote: When I first looked at Git source code two things struck me as odd: 1. Pure C as opposed to C++. No idea why. Please don't talk about portability, it's BS. **YOU** are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do **nothing** but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said to piss you off, but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really **would** prefer to piss off, so that he doesn't come and screw up any project I'm involved with. C++ leads to really really bad design choices. You invariably start using the nice library features of the language like STL and Boost and other total and utter crap, that may help you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic object model crap. So I'm sorry, but for something like git, where efficiency was a primary objective, the advantages of C++ is just a huge mistake. The fact that we also piss off people who cannot see that is just a big additional advantage. If you want a VCS that is written in C++, go play with Monotone. Really. They use a real database. They use nice object-oriented libraries. They use nice C++ abstractions. And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess. But I'm sure you'd like it more than git. Linus Source: http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918 Hmm, from that I get the impression that Linus is basically just like the old Java-evangelists except instead of OO being his silver bullet, it's zero-abstraction. I'm almost suprised he allows things like functions, or anything other than Asm for that matter, or cares about portability. I really doubt he'd like D. Maybe he'd dislike parts of it less than C++, but that's probably about it.
Re: Advocacy (Was: Who here actually uses D?)
Nick Sabalausky wrote: Hmm, from that I get the impression that Linus is basically just like the old Java-evangelists except instead of OO being his silver bullet, it's zero-abstraction. I'm almost suprised he allows things like functions, or anything other than Asm for that matter, or cares about portability. I really doubt he'd like D. Maybe he'd dislike parts of it less than C++, but that's probably about it. Yeah, I don't think Linus would find D appealing.
Re: Advocacy (Was: Who here actually uses D?)
Nick Sabalausky: Hmm, from that I get the impression that Linus is basically just like the old Java-evangelists except instead of OO being his silver bullet, it's zero-abstraction. I'm almost suprised he allows things like functions, or anything other than Asm for that matter, or cares about portability. I really doubt he'd like D. Maybe he'd dislike parts of it less than C++, but that's probably about it. Why do you think he doesn't care about Linux portability? I've seen Linux broken by compiler optimizations present in new GCC versions. If you write very important C code that breaks if you optimize it in new ways (see pointer aliasing troubles), you grow dislike for compilers. He needs a dumb C compiler that doesn't do what it likes. If you write the code he writes, then probably you learn to appreciate the same things he likes. He's not the only person that's writing Linux, the other people after so many years keep doing the same things he is doing, so probably his choices are not so dumb for their job. See also the C type system extensions he has created for Linux: http://en.wikipedia.org/wiki/Sparse So he wants a compiler that performs less smart optimizations, but he also wants a higher level type system to catch bugs. Don't you see a pattern emerging here? :-) I am able to see that he needs something different from the usual application C programmer. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Don't you see a pattern emerging here? :-) I am able to see that he needs something different from the usual application C programmer. One more point: Some Microsoft researchers are trying to create a kernel using something higher level than C, using Sing# (but they too use twenty modules written in a kind of typed and proved assembly). Here they accept the little loss of control caused by leaving low level C programming because Spec# gives something back to balance, it gives several static guarantees that normal C code doesn't give. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Walter: Yeah, I don't think Linus would find D appealing. Even if this is true, some Microsoft researchers are trying to show that even a-bit-higher level (well, middle level) languages may be fit for kernel development. Compared to C they are worse because they lead to some loss of low-level control on the produced assembly. But if they are well designed (for this purpose) they give something else back: more safety thanks to stronger static guarantees. This higher safety in turn is useful to statically disable/avoid some run-time tests that a kernel written in C must perform (this among other things helps regain some or all the performance lost in not using C). Is D fit for this? I don't think so. But an extension of D language may become good enough. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Caligo: Walter: Yeah, I don't think Linus would find D appealing. So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. I think D is an almost-system-language :-) There are various levels of how much system level a language is. D will be fit for high performance numerical computing, parallelism, game engine development, and more. You may even write device drivers in D. But D is not currently the best fit to write a kernel (despite some people have tried twice and it's probably possible). Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
(but they too use twenty modules written in a kind of typed and proved
assembly).
This is from a conference by Linus and friends:
http://www.linuxjournal.com/article/7272
I am a huge believer in static typechecking that doesn't add any runtime
overhead. So you basically get perfect performance, assuming your compilers
are perfect--whatever--with reasonably good safety. The problem is that being
the kernel has to do a lot of things that break typechecking. Which you see
more in the kernel than in a lot of other programs. You end up having a lot of
inline assembly which is obviously completely opaque.
The interesting experimental Verve operating system contains some typed
assembly too, so I've taken a better look at this idea. This is a site about
typed assembly:
http://www.cs.cornell.edu/talc/
Some papers:
http://www.cs.cornell.edu/talc/papers.html
Typed Assembly Language (TAL) is different from High Level Assembly (HLA,
http://webster.cs.ucr.edu/AsmTools/HLA/ ) because TAL is mostly a way to add
type annotations to normal assembly code.
I have written some X86 assembly code and some other kind of assembly code, and
I have seen how much bug-prone it is. I know that compared to C the asm is so
bug-prone also because there is no type system to catch bugs. So the idea of
type annotations for asm code is interesting for me.
So a D compiler may perform normal type tests of the inlined asm code that uses
type annotations (in theory this doesn't even require to modify the D
front-end, an external tool may be used to test the type annotations).
As reference I use two papers:
Dan Grossman, Greg Morrisett, Scalable Certification for Typed Assembly
Language:
http://www.cs.cornell.edu/talc/papers/tal_scale.pdf
Greg Morrisett et al., TALx86: A Realistic Typed Assembly Language:
http://www.cs.cornell.edu/talc/papers/talx86-wcsss.pdf
Quotations:
As in a conventional assembly language, the instructions and data are organized
into labeled sequences. Unlike conventional assembly language, some labels are
equipped with a type annotation. The type annotations on the labels of
instruction sequences, called code types, specify a pre-condition that must be
satisfied before control may be transferred to the label. The pre-condition
specifies, among other things, the types of registers and stack slots.
For example, if the code type annotating a label L is
{eax:int4, ebx:S(3), ecx: ^*[int4,int4]},
then control may be transferred to the address L only when the register eax
contains a 4-byte integer, the register ebx contains the integer value 3, and
the register ecx contains a pointer (^) to a record (*[...]) of two 4-byte
integers.
Bye,
bearophile
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 2 Jan 2011 02:38:02 -0600 Caligo == iteronve...@gmail.com wrote: Caligo So why is D being advertised as a systems programming Caligo language? By saying Linus would not find D appealing you are Caligo basically saying kernel developers would not find it appealing. Do Linus co. have to put label on something to qualify as system-programming language? Here is something interesting: http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ Otoh, I also do not believe that every VCS written in C must be ala (whatever means) Git - Fossil (http://fossil-scm.org) is one nice example. For me, D looks as the most-promising general programming language having good-enough performance and being safe-enough - iow. sweet spot: C(++) --- D --- Haskell. And yes, I believe there is still space for desktop (aka non-web) apps. ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Advocacy (Was: Who here actually uses D?)
I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. If someone using the word love for C and at the same time hate C++... He might be a god to some people but at the same time this makes him a dumbass language lawyer.
Re: Advocacy (Was: Who here actually uses D?)
By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Nope by saying Linus would not find D appealing he basically said Linus would not find D appealing. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
I have seen this before. **YOU** are full of bullshit. C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do **nothing** but keep the C++ programmers out, that in itself would be a huge reason to use C. In other words: the choice of C is the only sane choice. I know Miles Bader jokingly said to piss you off, but it's actually true. I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really **would** prefer to piss off, so that he doesn't come and screw up any project I'm involved with. C++ leads to really really bad design choices. You invariably start using the nice library features of the language like STL and Boost and other total and utter crap, that may help you program, but causes: - infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny) - inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app. This whole thing contains not a single evidence but hate. In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic object model crap. Object model is crap to an extent. Mostly it is the implementations that are crap. --- struct context; context* new(...); void this(context*); void that(context*); void delete(context*); context2* c2 = (context2*)c; Isn't this an example to object model crap? It is everywhere, so he codes without this? There are tons of open source C code, which re-invents C++ virtual, i wouldn't be surprised if he did this too. Even the official C++ book itself says Don't abuse class. C has this macro model, we know how safe how useful it is. Do you have to use it? Sometimes yes, here you don't even have to use object model crap. I am not saying C++ is awesome and all, but it is a big step after C. If you don't like it, don't use it. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
bearophile bearophileh...@lycos.com wrote in message news:ifpdbd$dr...@digitalmars.com... Nick Sabalausky: Hmm, from that I get the impression that Linus is basically just like the old Java-evangelists except instead of OO being his silver bullet, it's zero-abstraction. I'm almost suprised he allows things like functions, or anything other than Asm for that matter, or cares about portability. I really doubt he'd like D. Maybe he'd dislike parts of it less than C++, but that's probably about it. Why do you think he doesn't care about Linux portability? I didn't say that I don't think he cares about portability, I just meant that from that one post it seemed like he was opposed to abstractions. With portability, I was just pointing out the silliness and self-contradiction of that stance. I've seen Linux broken by compiler optimizations present in new GCC versions. If you write very important C code that breaks if you optimize it in new ways (see pointer aliasing troubles), you grow dislike for compilers. He needs a dumb C compiler that doesn't do what it likes. If you write the code he writes, then probably you learn to appreciate the same things he likes. He's not the only person that's writing Linux, the other people after so many years keep doing the same things he is doing, so probably his choices are not so dumb for their job. Right. And I have no doubt about that. It just sounded like he was insisting that such measures were every bit as necessary and appropriate for application software, too. Of course, I'm usually one of the first people to get annoyed by slow code and techniques being considered good enough in application development, but he seems to be taking it a bit far.
Re: Advocacy (Was: Who here actually uses D?)
so: There are tons of open source C code, which re-invents C++ virtual, i wouldn't be surprised if he did this too. I think Linux devices are used through some kind of virtual table. But he needs control on how things are implemented (I think C++ Standard doesn't specify how virtual calls are implemented). Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
2011/1/2 so s...@so.do I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. If someone using the word love for C and at the same time hate C++... He might be a god to some people but at the same time this makes him a dumbass language lawyer. When you insult people like that, what does that make you?
Re: Advocacy (Was: Who here actually uses D?)
Nick Sabalausky: Right. And I have no doubt about that. It just sounded like he was insisting that such measures were every bit as necessary and appropriate for application software, too. What he said years ago about C++ is relative to Linux Kernel development of several years ago :-) It's not relative to application software development today, it's not relative to not-Linux-like kernels, and it's not relative to new kernels written 5-15 years from now. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
bearophile bearophileh...@lycos.com wrote in message news:ifpiv8$lt...@digitalmars.com... so: There are tons of open source C code, which re-invents C++ virtual, i wouldn't be surprised if he did this too. I think Linux devices are used through some kind of virtual table. But he needs control on how things are implemented (I think C++ Standard doesn't specify how virtual calls are implemented). That does bring up one thing I think he might like about D versus C++: C++ tends to leave a *lot* as undefined, whereas D tries to avoid doing that. I have no idea if that applies to virual table implementations, though. Although, if he suddenly decided he wanted to change something about the implementation of virtual tables, with C he'd probably have to rewrite a lot of code. Not so with a depends on the implementation form of virtual tables. But maybe he does have it abstracted away with macros of something, I dunno. Heck, I might not even be making any sense anyway, it's bedtime and I'm about half asleep already...
Re: Advocacy (Was: Who here actually uses D?)
When you insult people like that, what does that make you? Objective, since i bring evidence or ask for evidence. It was you that linked his nerd rage in the other thread, if mine is insult what about his? Please go read it. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
bearophile bearophileh...@lycos.com wrote in message news:ifpj7e$mg...@digitalmars.com... Nick Sabalausky: Right. And I have no doubt about that. It just sounded like he was insisting that such measures were every bit as necessary and appropriate for application software, too. What he said years ago about C++ is relative to Linux Kernel development of several years ago :-) It's not relative to application software development today, it's not relative to not-Linux-like kernels, and it's not relative to new kernels written 5-15 years from now. Well, he was talking about git, too.
Re: Advocacy (Was: Who here actually uses D?)
Caligo wrote: Yeah, I don't think Linus would find D appealing. So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Not at all. He's hardly the only systems programmer. I'd expect the number of different opinions about what makes a good systems language to be about equal to the number of systems developers.
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: But D is not currently the best fit to write a kernel Based on what?
Re: Advocacy (Was: Who here actually uses D?)
Walter: Based on what? It's just a lump of opinions of mine, I have not written a microkernel yet :-) But I am reading a lot, I am learning and I will be able to write this kind of code too. Some people have tried to write a kernel with Python. D2 is a nice language to use, it allows some low level control, inline asm, and it compilation model comes from C with things added. So I am sure it's possible to write a good enough kernel with D2. So it's a matter of how much the language is fit for this purpose, it's not a binary thing. Is D2 the best conceivable language to write a kernel? I don't think so (but I am often wrong). For a kernel writer D2 doesn't offer a lot of control on low level matters, like how the compiler compiles and optimizes code (see the thread about guaranteed optimizations. This is a case where you don't want to Let the compiler implementors do their job because you lose low-level control on the code produced and this introduces bugs). This was one of the main complaints of Linus against C++ for Linux kernel development. D2 type system is refined and much more powerful than the C one. And people have written many kernels with C (C plus with few nonstandard extensions). But if you want to write a modern kernel you may want a type system more powerful than the C and D ones, that give stronger static guarantees. Linus has written a tool to strengthen the C type system: http://en.wikipedia.org/wiki/Sparse In another thread I have written something about typed assembly, useful to make less wild parts written in assembly: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=125815 In some situations linear types too help: http://en.wikipedia.org/wiki/Linear_types The Spec# language and the experimental Verve kernel we have discussed a bit in past show possible directions for future kernels, they require a pretty strong static analysis. The Sparse tool shows that some of those type system feature may be added later to D with an external tool. But Verve shows that sometimes you need something more built-in. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
Frankly, I'd love to sit down and talk about it with Linus over beers. Now i have read the entire thread. He and that community made me sick, they just lynched the OP. Your posts also didn't get the most objective responses either. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 2 Jan 2011 10:19:48 +0100 Gour g...@atmarama.net wrote: Caligo So why is D being advertised as a systems programming Caligo language? By saying Linus would not find D appealing you are Caligo basically saying kernel developers would not find it appealing. Do Linus co. have to put label on something to qualify as system-programming language? Here is something interesting: http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ Oberon is both a system programming lang very different from C and a system written in it that is/was rather innovating. For me, D looks as the most-promising general programming language having good-enough performance and being safe-enough - iow. sweet spot: C(++) --- D --- Haskell. Yes. I find simply wrong presentations starting with D is a system programming language... D is more than that. (And is/will certainly be more used in other domains that in system programming) Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 02 Jan 2011 13:08:08 +0200, spir denis.s...@gmail.com wrote: I thank Walter / Digital Mars heartfully for such a present to the programming community. Still, I would advocate for an independant reference site dedicated to the language properly speaking, without a Digital Mars logo on top of the front page (why is it currently there?); but instead as many references and pointers to Walter and the Digital Mars site as you like. This could have an adverse effect. Commercial users of D will most likely find it more satisfying to know that there is a company backing D, from which they could get commercial support if required. Similarly, if the main reference website of a language is not affiliated with the company behind the language, it puts into serious doubt the competence of said company. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: Advocacy (Was: Who here actually uses D?)
Linus has written a tool to strengthen the C type system: http://en.wikipedia.org/wiki/Sparse Studying Sparse a bit more I've seen it's not that complex system. It does simple things. Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
On 1/2/11 4:35 AM, Walter Bright wrote: Caligo wrote: Yeah, I don't think Linus would find D appealing. So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Not at all. He's hardly the only systems programmer. I'd expect the number of different opinions about what makes a good systems language to be about equal to the number of systems developers. If not greater than :o). Andrei
Re: Advocacy (Was: Who here actually uses D?)
While we're on topic of advocacy, I've just noticed these two topics on reddit: http://www.reddit.com/r/programming/comments/eup9a/creating_database_schemas_with_go/ http://www.reddit.com/r/programming/comments/euuuw/creating_database_schemas_with_c/ Someone came up with a hackish way to do database schemas in Go, but it left Reddit unimpressed (ha!). Another guy created the same thing in C. Now would be a perfect time to show how it's done in D and gain a little rep. I'm sure this would be piece of cake to do in D since there's not a lot of code, any volunteers? (me, I wouldn't know the first thing about databases so I'd likely screw something up :p). On 1/2/11, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 1/2/11 4:35 AM, Walter Bright wrote: Caligo wrote: Yeah, I don't think Linus would find D appealing. So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Not at all. He's hardly the only systems programmer. I'd expect the number of different opinions about what makes a good systems language to be about equal to the number of systems developers. If not greater than :o). Andrei
Re: Advocacy (Was: Who here actually uses D?)
Messier is a matter of perspective. C is a beautifully clear and mature language, but some of the missing features (delegates for one) often leads to unnecessarily convoluted code. Hejlsberg describes it quite well as Simplexity, roughly speaking, when the tools are too crude, the produced result might not look as refined as with better tools. http://www.artima.com/intv/simplexity.html 2011/1/2 Jimmy Cao jcao...@gmail.com: On Sun, Jan 2, 2011 at 12:38 AM, Caligo iteronve...@gmail.com wrote: I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. I think he hates C++ because it's messier than C. Many things are messier than C, including D.
Re: Advocacy (Was: Who here actually uses D?)
On Sun, 02 Jan 2011 17:17:55 +0200, Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote: Messier is a matter of perspective. C is a beautifully clear and mature language, but some of the missing features (delegates for one) often leads to unnecessarily convoluted code. Exactly, and there are too many of these simple but necessary tools, which eventually makes the language complex. People has strange beliefs, rediscovering a feature in every five lines of code and believing the said language is simple, elegant, modern... is one of them. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Advocacy (Was: Who here actually uses D?)
So why is D being advertised as a systems programming language? By saying Linus would not find D appealing you are basically saying kernel developers would not find it appealing. Systems programming in my vocabulary is not limited to JUST kernel programming. To be honest, I think D has a pretty long way to go to be good for kernel development (irregardless of Linus/Linux). For kernel development I suspect stop-the-world GC, or any non-deterministic GC for that matter is a big no-no. Also, imagine the current frustration over compiler/stdlib-bugs if you're operating in kernel-space, with no GDB to help you track it down. That's not to say I don't think D COULD be used for kernel development, but at the current state of things, I don't think it's really a promising cost/benefit. But systems development in my world doesn't end with the kernel, system-development is everything up to the applications the users really want, all libraries, codecs, file-format implementations etc. I.E. i would be really interested to see what kind of systems-API could be developed directly against the kernel ABI of *BSD or Linux, if you ignore the libc-layer. I.E. what would a completely event-driven (twisted) close-to-os stdlib look like, and how would that improve the simplicity of writing performant I/O-driven applications? Currently, however, I think the D community (which I'm increasingly being pulled into by common interests) should really focus on low-hanging fruit, and proving to the larger developer-community why D is worthwhile. In this area, I think the timing of D is perfect, given the current trend of cheaper hardware, rather than more powerful hardware. For instance are there currently any good database-implementations in D, suitable for beating the Tracker/Beagle/Strigi Desktop-search mess of the open source desktops? Integrating such database with the upcoming Linux fanotify API and libextractor should be an achievable goal, and could perhaps even be a compatible drop-in replacement for I.E. Tracker, but with lower footprint? I also have a stripped binding for FUSE as part of BitHorde, so implementing a fuse-based metadata-browser should be doable for integrating metadata directly into the Linux VFS. Definitely good for showing off.
Re: Advocacy (Was: Who here actually uses D?)
spir denis.s...@gmail.com wrote in message news:mailman.359.1293969777.4748.digitalmar...@puremagic.com... On Sun, 2 Jan 2011 10:19:48 +0100 Gour g...@atmarama.net wrote: Caligo So why is D being advertised as a systems programming Caligo language? By saying Linus would not find D appealing you are Caligo basically saying kernel developers would not find it appealing. Do Linus co. have to put label on something to qualify as system-programming language? Here is something interesting: http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/ Oberon is both a system programming lang very different from C and a system written in it that is/was rather innovating. For me, D looks as the most-promising general programming language having good-enough performance and being safe-enough - iow. sweet spot: C(++) --- D --- Haskell. Yes. I find simply wrong presentations starting with D is a system programming language... D is more than that. (And is/will certainly be more used in other domains that in system programming) Borland did the same miss-selling - they marketed Delphi as a database language... :-) -=mike=-
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: Walter: Based on what? It's just a lump of opinions of mine, I have not written a microkernel yet :-) But I am reading a lot, I am learning and I will be able to write this kind of code too. Some people have tried to write a kernel with Python. D2 is a nice language to use, it allows some low level control, inline asm, and it compilation model comes from C with things added. So I am sure it's possible to write a good enough kernel with D2. So it's a matter of how much the language is fit for this purpose, it's not a binary thing. Is D2 the best conceivable language to write a kernel? I don't think so (but I am often wrong). It's not perfect, but it is better than any other existing language. For a kernel writer D2 doesn't offer a lot of control on low level matters, like how the compiler compiles and optimizes code (see the thread about guaranteed optimizations. I'm afraid that's baloney, as I pointed out in the other thread. This is a case where you don't want to Let the compiler implementors do their job because you lose low-level control on the code produced and this introduces bugs). This was one of the main complaints of Linus against C++ for Linux kernel development. I think that is a serious misinterpretation of the complaint. The complaint was actually that the high level abstractions that one can choose to use in C++ can be impenetrable in what they do. In D, if you want low level control, write low level code. It's that simple. D2 type system is refined and much more powerful than the C one. And people have written many kernels with C (C plus with few nonstandard extensions). But if you want to write a modern kernel you may want a type system more powerful than the C and D ones, that give stronger static guarantees. Linus has written a tool to strengthen the C type system: http://en.wikipedia.org/wiki/Sparse Yes, I know about Sparse. You can do the same thing in D without needing annotations. In another thread I have written something about typed assembly, useful to make less wild parts written in assembly: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=125815 In some situations linear types too help: http://en.wikipedia.org/wiki/Linear_types Typed assembler is a waste of effort in a language like D, as you only need a few drops of assembler here and there. The Spec# language and the experimental Verve kernel we have discussed a bit in past show possible directions for future kernels, they require a pretty strong static analysis. Those languages are failures at what they propose to do; they need years and perhaps decades to fulfill that. The Sparse tool shows that some of those type system feature may be added later to D with an external tool. Like I said, you can already do that with D. But Verve shows that sometimes you need something more built-in. I don't buy that.
Advocacy (Was: Who here actually uses D?)
2011/1/2 Robert Clipsham rob...@octarineparrot.com: Unfortunately, it's impossible to create such a system without people being paid to work on dmd and the runtime - people will fix the bugs they want to, you can't make them fix anything. Obviously you can influence what gets fixed, not to a huge extent though. Ideally the voting system would outline what needs the most effort, but people don't idle on bugzilla enough for it to work so well. I wonder if changing the 'vote' button to a 'like' button would make any difference, if facebook's any indication, people like to like things ;p Personally, I think the community is a key focus area. D cannot survive without a thriving community, both in the core projects (language design, compilers, stdlibs, druntime etc.), and in applications (especially highly visible killer-apps). I think it's absolutely critical to work on advocating the language, especially I feel D is currently missing killer-apps demonstrating why learning D is worthwhile. Let's be honest, coming into the market of C-style imperative languages in the second half of this past decade isn't exactly easy. There are already C/C++ for the performance-crazed, and Java/C# for the convenience-minded. The only complaint I ever hear in that landscape, is that C/C++ is just too much hazzle to work with, and C#/Java is ridiculously resource-hungry, partly in CPU but even more so regarding RAM consumption. Of course most users don't care, but the few passionate developers feeling this, THEY are the audience D appeals to. I think it's important to intentionally target them in advocacy. D cannot succeed in doing everything. It certainly cannot compete with Ada on writing secure stable code, and it cannot compete with C in low-level programming simply due to the sheer established mass. The one area where there is currently an unexploited opportunity is in the corner between productive yet efficient, and this is where D shines, which most developers currently do not know. On a side-note (and I'm clearly biased here so I hardly even take myself very seriously), I think the non-windows os:es, especially Linux, should also be an intentional focus-area. It is VERY difficult to compete with .NET on Windows, and somehow I don't think we'll find most of the efficiency-focused audience there, but if D can demonstrate it's usefulness in key systems components in Linux, it's likely to attract more curious right-minded developers. I'm not sure exactly how to realize this, but there may be two opportunities in quickly providing a lightwheight attractive desktop environment for the upcoming Wayland system, as well as someone finally writing a disk-indexing system that doesn't eat all your disk-bandwidth and ram during the first week. In any case, I think it's also very important to remember developers should only make up a small part of a good community, even a software development community. We need webdesigners, advocates, testers, people doing bugzilla maintenance, documentation experts, writers, artists, and just about anyone who can spare a couple of hours of the week since they want more efficient software (even if they don't know how to do it themselves). Just discovering http://d-programming-language.org/ with much nicer presentation of the docs I've already seen, raised my motivation for D just as much as any random dozen solved bugs from bugzilla. Attracting people to D is IMHO MUCH more important than any particular bug or especially new feature. If I got my wish, I would very much like to see some of the core devs allocating 75% of their time of for the next months on not doing core work, but ONLY doing things to attract new developers; I.E. * Try to get D into the Debian Language Shootout Again? * A simple web-server beating apache performance (maybe even nginx?) would be a reasonable goal, which would make great headlines, and in short time. If you can also show it's source-code is comprehensible to any medium-skilled Java dev, you've probably got yourself many new prospective developers. * Follow up new developers with top-notch support for the more promising ones to make sure they don't bounce back out. * Brush up the documentation aimed at beginners, and try to get a few articles and tutorials published (at least slashdotted) Given these above, which to my knowledge isn't done as of now, I think it's not unreasonable to expect a sizable growth in both active community and external visibility. Now, time for me to go to bed. (It's 06:00 here) when I wake up later today, I'm hoping to have the list full of further ideas, suggestions and thoughts on how to grow the community, except for implementing D3/4/5 100% bugfree. :)
Re: Advocacy (Was: Who here actually uses D?)
On Sat, Jan 1, 2011 at 11:27 PM, Ulrik Mikaelsson ulrik.mikaels...@gmail.com wrote: On a side-note (and I'm clearly biased here so I hardly even take myself very seriously), I think the non-windows os:es, especially Linux, should also be an intentional focus-area. It is VERY difficult to compete with .NET on Windows, and somehow I don't think we'll find most of the efficiency-focused audience there, but if D can demonstrate it's usefulness in key systems components in Linux, it's likely to attract more curious right-minded developers. I'm not sure exactly how to realize this, but there may be two opportunities in quickly providing a lightwheight attractive desktop environment for the upcoming Wayland system, as well as someone finally writing a disk-indexing system that doesn't eat all your disk-bandwidth and ram during the first week. I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. Imagine if Linus tries D and thinks it's a good language and begins to use it in kernel development. I don't think I need to describe what would happen to D then. Sadly, GDC is not in a good state right now.
Re: Advocacy (Was: Who here actually uses D?)
On Sun, Jan 2, 2011 at 12:38 AM, Caligo iteronve...@gmail.com wrote: I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. I think he hates C++ because it's messier than C. Many things are messier than C, including D.
Re: Advocacy (Was: Who here actually uses D?)
Jimmy Cao jcao...@gmail.com wrote in message news:mailman.347.1293951472.4748.digitalmar...@puremagic.com... On Sun, Jan 2, 2011 at 12:38 AM, Caligo iteronve...@gmail.com wrote: I agree with you on this. For example, Linus Torvald hates C++ and probably for good reasons. I think he hates C++ because it's messier than C. Many things are messier than C, including D. I don't have a link, but I read a post he made somewhere that explained the reason Linux kernal is plain-C-only is because, IIRC, they frequently need a very, very tight mapping between the source and the generated instructions. Partly for tight control over the instruction generation, and partly becase they often needed be be able to look at the source and know what got generated. I don't know, but I suspect D may be even further from C++ in than regard.
