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: 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: 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?)
"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?)
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?)
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?)
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.
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.D&article_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.
Re: Advocacy (Was: Who here actually uses D?)
Ulrik Mikaelsson wrote: "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. 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.
Re: Advocacy (Was: Who here actually uses D?)
"spir" wrote in message news:mailman.359.1293969777.4748.digitalmar...@puremagic.com... On Sun, 2 Jan 2011 10:19:48 +0100 Gour 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?)
> 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?)
On Sun, 02 Jan 2011 17:17:55 +0200, Ulrik Mikaelsson 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?)
"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 : > On Sun, Jan 2, 2011 at 12:38 AM, Caligo 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?)
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 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?)
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?)
> 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 Sun, 02 Jan 2011 13:08:08 +0200, spir 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?)
On Sun, 2 Jan 2011 10:19:48 +0100 Gour 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?)
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?)
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.D&article_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?)
On Sun, 2 Jan 2011 06:27:41 +0100 Ulrik Mikaelsson wrote: > 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. I am very much for helping and develop an independant, community-driven, site dedicated to D. At my first contact with the language, just discovering it _apparently_ was a (private, for profit) company's product was enough to let me turn back, and ciao! Whatever the language's qualities. (That it was free as in free beer did not make any difference.) 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. The first contact is very important. If we take this as an opportunity to improve presentation and above all documentation: superb! (*) If we honestly present the language including its present drawbacks, defaults, and issues in general: bravo! (*) 2011: the year of D? Denis (*) Possibly an even greater entry barrier than the present unfinished state of D2. (EDIT: Also target non-C++ programmers. And do this _seriously_. The statemtent in TDPL that programmers knowing a C++-like language will enjoy a _slight_ advantage is quite an understatement, imo: the whole book silently refers to loads of notions perticular to this language family.) (**) The page at http://d-programming-language.org/comparison.html should also list all D2 issues, imo. Let us take example on Nimrod's doc that fears not telling about (present and lasting, accidental and designed) shortcomings of the language. This adult attitude would be far more appealing than possibly deceiving statements, imo, and even more than non-told facts. -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
Re: Advocacy (Was: Who here actually uses D?)
bearophile wrote: 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). This is a red herring. In practice, not only does every C++ compiler I've ever heard of do it the same way, but Linus certainly has enough pull to get g++ to do it his way. (10 years ago g++ did do it differently than other C++ compilers, but they since changed it to match.)
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?)
Nick Sabalausky wrote: Yea, it's not as if Linus is all there is to kernel development. Frankly, I'd love to sit down and talk about it with Linus over beers.
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?)
Nick Sabalausky: > 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. The Coccinelle tool helps a lot, it allows to perform Semantic Patching, http://coccinelle.lip6.fr/ See slides: http://coccinelle.lip6.fr/workshop/slides.pdf (I think coccinelle is usable with D too, maybe with small changes. It may be good for the development of the D compiler too). Bye, bearophile
Re: Advocacy (Was: Who here actually uses D?)
"bearophile" 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?)
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" 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?)
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?)
2011/1/2 so > 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?)
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?)
"bearophile" 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?)
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?)
"so" wrote in message news:op.voocpmy97dt...@so-pc... >> 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. > Yea, it's not as if Linus is all there is to kernel development.
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 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?)
On Sun, 2 Jan 2011 02:38:02 -0600 >> "Caligo" == 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?)
> (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?)
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?)
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?)
> 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?)
On Sun, Jan 2, 2011 at 2:24 AM, Walter Bright wrote: > 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. > 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.
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?)
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?)
"Caligo" wrote in message news:mailman.348.1293955294.4748.digitalmar...@puremagic.com... > On Sun, Jan 2, 2011 at 1:42 AM, Nick Sabalausky 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?)
On Sun, Jan 2, 2011 at 1:42 AM, Nick Sabalausky 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?)
"Jimmy Cao" wrote in message news:mailman.347.1293951472.4748.digitalmar...@puremagic.com... > On Sun, Jan 2, 2011 at 12:38 AM, Caligo 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.
Re: Advocacy (Was: Who here actually uses D?)
On Sun, Jan 2, 2011 at 12:38 AM, Caligo 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 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.
