digitalmars.D - Re: Adding D Editor Support
- Brian Price <blprice61 yahoo.com> Jun 14 2008
- John A. De Goes <john.withoutspam. n-brain.net> Jun 14 2008
- janderson <askme me.com> Jun 14 2008
- Georg Wrede <georg nospam.org> Jun 19 2008
- Ty Tower <tytower hotmail.com> Jun 19 2008
- Georg Wrede <georg nospam.org> Jun 20 2008
- "Nick Sabalausky" <a a.a> Jun 20 2008
- Mike Parker <aldacron gmail.com> Jun 20 2008
- Sean Kelly <sean invisibleduck.org> Jun 20 2008
- Sean Kelly <sean invisibleduck.org> Jun 20 2008
John A. De Goes Wrote:Hi, We're adding support for the D language to UNA (http://www.n-brain.net). The Personal Edition has been released free of charge (down from $100). However, none of us have used D so we'd like a bit of help. We've added support (in dev version) to matching messages of the form: foo.d(5): Warning: silly variable name foo.d(5): Error: spelling error in variable name "foobir" Assuming this is correct, we'd like to proceed with adding commonly used source code constructs, D idioms, and so forth. We call this 'source snippets'. Each source snippet has a few letter textual key. Typing that key and invoking the source snippet button inserts the snippet. So I'm soliciting for everyone's favorite source snippet.
Unsure how common this is but I find myself using the following handy construct (assume module name can be inserted by {module}: version({module}_test) { import std.stdio; unittest { } int main() { return 0; } } This allows me to use the command line: dmd file1.d file2.d file3.d somelib.lib -unittest -version=file1_test. This results in only the tests from the requested file being generated in the resulting executable. Is it possible for custom snippets to be added by the user? I look forward to trying out your IDE. Thanks, Brian
Jun 14 2008
Brian Price Wrote:This allows me to use the command line: dmd file1.d file2.d file3.d somelib.lib -unittest -version=file1_test.
Looks great! I'll add it to the templates. All the examples so far have used block-aligned styling: a { } In Java, for example, the most popular convention by far is to place the opening brace at the end of the preceding line. Are the examples I've seen representative of the more popular conventions within the D community?Is it possible for custom snippets to be added by the user?
Yes, indeed. I'd just like to ship with some decent snippets already built in.I look forward to trying out your IDE.
That's great. Send us some feedback after you've used it for a while. Regards, John
Jun 14 2008
John A. De Goes wrote:Brian Price Wrote:This allows me to use the command line: dmd file1.d file2.d file3.d somelib.lib -unittest -version=file1_test.
Looks great! I'll add it to the templates. All the examples so far have used block-aligned styling: a { } In Java, for example, the most popular convention by far is to place the opening brace at the end of the preceding line. Are the examples I've seen representative of the more popular conventions within the D community?
I would say yes. Looking though the newsgroup, barely anyone uses the end of line syntax.Is it possible for custom snippets to be added by the user?
Yes, indeed. I'd just like to ship with some decent snippets already built in.I look forward to trying out your IDE.
That's great. Send us some feedback after you've used it for a while. Regards, John
Jun 14 2008
John A. De Goes wrote:Looks great! I'll add it to the templates. All the examples so far have used block-aligned styling: a { } In Java, for example, the most popular convention by far is to place the opening brace at the end of the preceding line. Are the examples I've seen representative of the more popular conventions within the D community?
Most of programming examples you can see in textbooks (and of course on many web sites) use the brace-at-end-of-line. People who've learnt to program from them get used to the "look", and then of course perceive it as prettier. Now, there are a couple of (rational) reasons for this custom. One is, in short examples it is nice to have the entire code snippet as short as possible, so that you can view some of the explaining text both before and after the code snippet at a glance. The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it. In an environment where yuou aren't constrained by space, it soon becomes practice to use the braces-on-own-lines convention. It uses more space, but if your screen has a resolution that allows it, then you don't care. Code with braces on their own lines is more manageable. One can grep for opening/closing braces, programs get clearer to grasp at a glance, etc. (Yes I know, now 500 people are going to contest my position. All I can say is, what one is used to looks clearer and more natural. But I'm talking a bigger perspective here.) On a 25-line monitor I'd use the brace-at-end convention, too. Oh, and the end result: I see no significan difference between C, C++, Java, and a few other languages, versus D, in the choice of bracing. It's mostly just a programmer preference. And both are used.
Jun 19 2008
Georg Wrede Wrote:John A. De Goes wrote:Looks great! I'll add it to the templates. All the examples so far have used block-aligned styling: a { } In Java, for example, the most popular convention by far is to place the opening brace at the end of the preceding line. Are the examples I've seen representative of the more popular conventions within the D community?
Most of programming examples you can see in textbooks (and of course on many web sites) use the brace-at-end-of-line. People who've learnt to program from them get used to the "look", and then of course perceive it as prettier. Now, there are a couple of (rational) reasons for this custom. One is, in short examples it is nice to have the entire code snippet as short as possible, so that you can view some of the explaining text both before and after the code snippet at a glance. The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it. In an environment where yuou aren't constrained by space, it soon becomes practice to use the braces-on-own-lines convention. It uses more space, but if your screen has a resolution that allows it, then you don't care. Code with braces on their own lines is more manageable. One can grep for opening/closing braces, programs get clearer to grasp at a glance, etc. (Yes I know, now 500 people are going to contest my position. All I can say is, what one is used to looks clearer and more natural. But I'm talking a bigger perspective here.) On a 25-line monitor I'd use the brace-at-end convention, too. Oh, and the end result: I see no significan difference between C, C++, Java, and a few other languages, versus D, in the choice of bracing. It's mostly just a programmer preference. And both are used.
Quote from George "The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it." Well George if this is good and valid info I will eat my hat. Puts the credibility of the rest of your writing in doubt. Pick up most programming texts and they are crammed with "Here is what this chapter will teach you" "Here is a load of unnecessary garbage" "Here is the guts of it" "Here is what you have learnt in this chapter" "Here's what we will cover in the next chapter" and so on , so there is not much care about brevity that I have seen!
Jun 19 2008
Ty Tower wrote:Quote from George "The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it." Well George if this is good and valid info I will eat my hat. Puts the credibility of the rest of your writing in doubt.
Next time you try to publish a book, you'll see. He absolutely hates any space usage that he doesn't understand the value of.Pick up most programming texts and they are crammed with "Here is what this chapter will teach you" "Here is a load of unnecessary garbage" "Here is the guts of it" "Here is what you have learnt in this chapter" "Here's what we will cover in the next chapter" and so on , so there is not much care about brevity that I have seen!
I know. Those books are written for (I don't seem to find the word). I was talking about serious books.
Jun 20 2008
"Ty Tower" <tytower hotmail.com> wrote in message news:g3fg35$1t3l$1 digitalmars.com...Georg Wrede Wrote:John A. De Goes wrote:Looks great! I'll add it to the templates. All the examples so far have used block-aligned styling: a { } In Java, for example, the most popular convention by far is to place the opening brace at the end of the preceding line. Are the examples I've seen representative of the more popular conventions within the D community?
Most of programming examples you can see in textbooks (and of course on many web sites) use the brace-at-end-of-line. People who've learnt to program from them get used to the "look", and then of course perceive it as prettier. Now, there are a couple of (rational) reasons for this custom. One is, in short examples it is nice to have the entire code snippet as short as possible, so that you can view some of the explaining text both before and after the code snippet at a glance. The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it. In an environment where yuou aren't constrained by space, it soon becomes practice to use the braces-on-own-lines convention. It uses more space, but if your screen has a resolution that allows it, then you don't care. Code with braces on their own lines is more manageable. One can grep for opening/closing braces, programs get clearer to grasp at a glance, etc. (Yes I know, now 500 people are going to contest my position. All I can say is, what one is used to looks clearer and more natural. But I'm talking a bigger perspective here.) On a 25-line monitor I'd use the brace-at-end convention, too. Oh, and the end result: I see no significan difference between C, C++, Java, and a few other languages, versus D, in the choice of bracing. It's mostly just a programmer preference. And both are used.
Quote from George "The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it." Well George if this is good and valid info I will eat my hat. Puts the credibility of the rest of your writing in doubt. Pick up most programming texts and they are crammed with "Here is what this chapter will teach you" "Here is a load of unnecessary garbage" "Here is the guts of it" "Here is what you have learnt in this chapter" "Here's what we will cover in the next chapter" and so on , so there is not much care about brevity that I have seen!
You know, that's actually an interesting point. I wouldn't put it quite so harshly, but I have seen a lot of programming books that do have a lot of what I would consider to be fluff (and I don't mean sidebar text (that can be interesting), but rather some of the things Ty points out. For instance, you can see what a chapter covers just by skimming through it). So in a way, it does seem a little odd that there tends to be fuss over code length (I can understand limited horizontal space though) when there's all of that other, IMHO, redundant/superfluous stuff.
Jun 20 2008
Nick Sabalausky wrote:"Ty Tower" <tytower hotmail.com> wrote in message news:g3fg35$1t3l$1 digitalmars.com...Georg Wrede Wrote:John A. De Goes wrote:Looks great! I'll add it to the templates. All the examples so far have used block-aligned styling: a { } In Java, for example, the most popular convention by far is to place the opening brace at the end of the preceding line. Are the examples I've seen representative of the more popular conventions within the D community?
many web sites) use the brace-at-end-of-line. People who've learnt to program from them get used to the "look", and then of course perceive it as prettier. Now, there are a couple of (rational) reasons for this custom. One is, in short examples it is nice to have the entire code snippet as short as possible, so that you can view some of the explaining text both before and after the code snippet at a glance. The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it. In an environment where yuou aren't constrained by space, it soon becomes practice to use the braces-on-own-lines convention. It uses more space, but if your screen has a resolution that allows it, then you don't care. Code with braces on their own lines is more manageable. One can grep for opening/closing braces, programs get clearer to grasp at a glance, etc. (Yes I know, now 500 people are going to contest my position. All I can say is, what one is used to looks clearer and more natural. But I'm talking a bigger perspective here.) On a 25-line monitor I'd use the brace-at-end convention, too. Oh, and the end result: I see no significan difference between C, C++, Java, and a few other languages, versus D, in the choice of bracing. It's mostly just a programmer preference. And both are used.
Quote from George "The other reason is, in textbooks there's a scarcity of dead wood. The publisher has to enforce brevity, and this is (from his POV) an unobtrusive way to achieve much of it." Well George if this is good and valid info I will eat my hat. Puts the credibility of the rest of your writing in doubt. Pick up most programming texts and they are crammed with "Here is what this chapter will teach you" "Here is a load of unnecessary garbage" "Here is the guts of it" "Here is what you have learnt in this chapter" "Here's what we will cover in the next chapter" and so on , so there is not much care about brevity that I have seen!
You know, that's actually an interesting point. I wouldn't put it quite so harshly, but I have seen a lot of programming books that do have a lot of what I would consider to be fluff (and I don't mean sidebar text (that can be interesting), but rather some of the things Ty points out. For instance, you can see what a chapter covers just by skimming through it). So in a way, it does seem a little odd that there tends to be fuss over code length (I can understand limited horizontal space though) when there's all of that other, IMHO, redundant/superfluous stuff.
For 'Learn to Tango with D', we didn't have anyone telling to shorten example code. We /were/ working within pretty tight constraints as far as page limit (the First Press series of books are intended to be short). But code size was never an issue. The only guideline for code was for formatting. Each line needed to be within a fixed-width. Frequently, they asked us to add more info to a chapter. They generally wanted the opening paragraphs to summarize the contents. I expected them to ask for a summary at the end of each chapter as well, since that format is so common in tech books, but they never did.
Jun 20 2008
== Quote from Mike Parker (aldacron gmail.com)'s articleFor 'Learn to Tango with D', we didn't have anyone telling to shorten example code. We /were/ working within pretty tight constraints as far as page limit (the First Press series of books are intended to be short). But code size was never an issue. The only guideline for code was for formatting. Each line needed to be within a fixed-width.
For my chapters, I found myself trying to produce compact examples because doing so increased the likelihood that the example wouldn't wrap to the following page... or push trailing description off to the following page. The rest is just personal preference however. I very much prefer example code that illustrates the point being discussed with a minimum of unrelated stuff. Sean
Jun 20 2008
== Quote from Ty Tower (tytower hotmail.com)'s articlePick up most programming texts and they are crammed with "Here is what this chapter will teach you" "Here is a load of unnecessary garbage" "Here is the guts of it" "Here is what you have learnt in this chapter" "Here's what we will cover in the next chapter" and so on , so there is not much care about brevity that I have seen!
This format is actually pulled from Public Speaking, where it has been shown that listeners retain the material better if you basically do: 1. "This is what I'm going to tell you" 2. Tell them 3. "In summary, here is what I've just told you" It's also good practice to limit an instructional lecture to no more than 3-4 main points. Done right, I think this is actually a very good format, even in a book. "The Pragmatic Programmer," for example, follows this format and it's one of the best programming books I've ever read, and also one of the most concise. Sean
Jun 20 2008