www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D and IDEs

reply Ant <Ant_member pathlink.com> writes:
Shouldn't new languages be aware of IDEs?
features and sintax should be designed having in mind
that IDEs are here to help on the development cycle.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant
Jul 02 2004
next sibling parent reply kinghajj <kinghajj_member pathlink.com> writes:
In article <cc4c1g$bui$1 digitaldaemon.com>, Ant says...
Shouldn't new languages be aware of IDEs?
features and sintax should be designed having in mind
that IDEs are here to help on the development cycle.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant

yourself instead of having an IDE find members of a class or structure for you.
Jul 02 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
kinghajj wrote:

 DIDE is a good IDE. It doesn't "auto-complete", so don't be lazy! Type it in
all
 yourself instead of having an IDE find members of a class or structure for you.

Why on Earth is letting an editor help out lazy? It's not like you can type the identifier better or faster, or that the code will somehow be better because every character was the result of a human pressing a key. Typing is effectively manual labour. I don't like manual labour. (especially with all the RSI that goes on where keyboards are concerned) -- andy
Jul 02 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cc4fo2$h39$1 digitaldaemon.com>, kinghajj says...
In article <cc4c1g$bui$1 digitaldaemon.com>, Ant says...
Shouldn't new languages be aware of IDEs?
features and sintax should be designed having in mind
that IDEs are here to help on the development cycle.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant

yourself instead of having an IDE find members of a class or structure for you.

Sorry, my fault, I should have added: Ant, Author of leds, arguably the best IDE for D ever! grab the excelent and free leds at: http://leds.sourceforge.net :) leds does do "auto-complete" but auto-complete has nothing to do with laziness or how fast you type. Auto complete, at least on leds, exposes (or reminds) the public interface of any class on your application and libs. If you are working on a small example/test applications that you build yourself that's probably a small help. When working on a large application intellisence is just a smart and convinient way IDEs have to quickly show you the API documentation. leds intellisense is more then that, leds is free check it for yourself. To me calling intellisence a tool for lazy people shows that you didn't really understand it's usefullness, can you agree that it is more then a typing help? but I insiste on the original issue. Coding with notepad it's old and new languages should be tools friendly. Having a reasonable development environment can be an important feature to make or break a language. Ant
Jul 02 2004
parent "Blandger" <zeroman aport.ru> writes:
 Ant, Author of leds, arguably the best IDE for D ever!
 grab the excelent and free leds at:
 http://leds.sourceforge.net
 :)

As for me I looking forward to try it on window for the couple of months. ;)
 leds does do "auto-complete"

Especially this.
 leds intellisense is more then that, leds is free check it for yourself.

I can't because I don't have a Linux on my desktop. :(
 Having a reasonable
 development environment can be an important feature to make
 or break a language.

Totally agree. Yuriy.
Jul 03 2004
prev sibling parent "Phill" <phill pacific.net.au> writes:
"kinghajj" <kinghajj_member pathlink.com> wrote in message
news:cc4fo2$h39$1 digitaldaemon.com...
 In article <cc4c1g$bui$1 digitaldaemon.com>, Ant says...
Shouldn't new languages be aware of IDEs?
features and sintax should be designed having in mind
that IDEs are here to help on the development cycle.

D already has a problem with the properties,
it's goind to be very difficult for an IDE
to figure out when a method should or not be presented as
a property.

maybe there are other examples but I just wanted to raise
this issue (4 years too late unfortunatly).

Ant


 yourself instead of having an IDE find members of a class or structure for


Maybe you meant to say that it does auto-complete instead of what you actually said. I think that auto-complete is more to do with productivity than lazyiness, although somtimes it annoys me when it completes somthing when I dont want it to, then I have to erase, and try to type the word again. BTW ant also has a great editor. Phill.
Jul 02 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.
 
 D already has a problem with the properties,
 it's goind to be very difficult for an IDE
 to figure out when a method should or not be presented as
 a property.
 
 maybe there are other examples but I just wanted to raise
 this issue (4 years too late unfortunatly).

I agree completely. Properties are, strictly speaking, necessarily "evil" because they can never be first class types in a language. (the whole point, after all, is that getting or setting their value doesn't really do that at all) Despite all that, the darned things are just too useful to let go of. I would be happier if they were "magical" class members which could not be interacted with in any way other than 'get' and 'set'. Without any other symbol using up the name, the ambiguities dissappear. Now that I've typed all that out, though, it seems to me that figuring out what's going on should be easy to work out: 'obj.function' is a property read 'obj.function=' is a property write '&obj.function' is a delegate constructor 'obj.function(' is a method call So maybe it's not such a big deal. :) -- andy
Jul 02 2004
next sibling parent reply Trejkaz Xaoza <trejkaz xaoza.net> writes:
Andy Friesen wrote:
 Ant wrote:
 
 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.
 
 D already has a problem with the properties,
 it's goind to be very difficult for an IDE
 to figure out when a method should or not be presented as
 a property.
 
 maybe there are other examples but I just wanted to raise
 this issue (4 years too late unfortunatly).

I agree completely. Properties are, strictly speaking, necessarily "evil" because they can never be first class types in a language. (the whole point, after all, is that getting or setting their value doesn't really do that at all) Despite all that, the darned things are just too useful to let go of. I would be happier if they were "magical" class members which could not be interacted with in any way other than 'get' and 'set'.

Well, there are the cases where you have something like this... public int getValue() { return foo; } But I would argue that in this case, it shouldn't be treated as a property, since it isn't returning the actual property. Properties in most cases are really just a dirty workaround for making read-only properties. It would be neat if a language would get this feature natively. Then we wouldn't have to use one dirty hack (using property syntax to call a method) to implement another hack (using methods to implement read-only properties.) It seems somewhat dirty that we have to go through methods when we're dealing with properties the whole time. I don't know what the syntax would look like though in any case. I suppose the most common case would be something like public(read) int value; Default for variables would be private as always, but public(read) would allow you to open the ability to read the value, without permitting it to be written. If you wanted some wacky access like public read, protected write, you would have to use public(read) protected(write) int value; Anyway this is just a nice-to-have, I don't honestly expect any usable language to do this kind of thing soon, without using the method-style properties. TX -- 'Every sufficiently advanced technology is indistinguishable from magic' - Arthur C Clarke 'Every sufficiently advanced magic is indistinguishable from technology' - Tom Graves Email: Trejkaz Xaoza <trejkaz xaoza.net> Web site: http://xaoza.net/trejkaz/ Jabber ID: trejkaz jabber.xaoza.net GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F A62C B8C7 BC8B 037E EA73
Jul 02 2004
parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 Properties in most cases are really just a dirty workaround for making
 read-only properties.  It would be neat if a language would get this
 feature natively.  Then we wouldn't have to use one dirty hack (using

Eiffel does.* It is not possible to do object.field = value, unless object = this. This is quite nice. But having both get and set be transparent allows you to move transparently between a field and a computation without affecting external code. * afaik
Jul 02 2004
prev sibling parent "C. Sauls" <ibisbasenji yahoo.com> writes:
This is where an old proposal for a 'property' keyword would have helped 
quite nicely.  Plus its just good to make this sort of thing explicit, 
IMHO.  For those who don't remember the version I was supporting, here's 
a brief recap... ;)

property TYPE IDENT {
   IDENT = DEFAULT_VALUE; // optional
   get(out TYPE IDENT2) {
     // code for gettor.  can have 0, 1, or several of these.
   }
   set(in TYPE IDENT2) {
     // code for settor.  can have 0, 1, or several of these.
   }
}

Actually I think it was slightly different, but its been a while.  If 
settors are absent, then its read-only.  If gettors are absent, then the 
value is directly readable, as if it were a normal data field / member 
variable.  I really don't know why this didn't fly.  Such is the way of 
things, I guess.

As it is, I'm with Walter on the intellisense issue, assuming I 
understand him right.  Just show fields as fields and methods as 
methods.  Let the coder decide whether or not to treat them as 
properties.  This should work fine unless you're wanting to issue 
edit-time warnings of passing invalid types to settors or the like.

-Chris S.
-Invironz
Jul 06 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:cc4c1g$bui$1 digitaldaemon.com...
 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

D is pretty friendly to IDEs, it's far, far easier to parse than C++.
 D already has a problem with the properties,
 it's goind to be very difficult for an IDE
 to figure out when a method should or not be presented as
 a property.

I'd take the straightforward approach and represent it as a property if it is a data member, and a function if it is a method member.
 maybe there are other examples but I just wanted to raise
 this issue (4 years too late unfortunatly).

 Ant

Jul 02 2004
prev sibling next sibling parent reply Mista <stoop hotpop.com> writes:
Ant wrote:

 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

No ofcourse not. The goal should be a good language for the user, not for other programs. IDE's can be made to overcome problems, that's not the problem for 'new' languages to solve.
Jul 03 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Mista wrote:

 Ant wrote:
 
 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

No ofcourse not. The goal should be a good language for the user, not for other programs. IDE's can be made to overcome problems, that's not the problem for 'new' languages to solve.

I disagree. If computers can easily understand the source code, then those computers can help us feeble humans out better. Besides, simplicity usually benefits both humans and computers at the same time. It's not a case of having to sacrifice one for the other. The best example of this is in the difference between Microsoft's Visual C++ and C# editors. The latter of which is amazing: the Visual C# editor highlights classes, namespaces, and other symbols with different colours, always provides *correct* drop-down auto-completion, and even underlines syntax errors on the fly. The C++ editor can do none of these things, presumably because of the sheer complexity of C++. At any rate, ease of implementation was and is an overt goal guiding the design of D, and I think it has achieved that admirably. Now we just need something as good as Visual Studio for it. :) -- andy
Jul 03 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...
The best example of this is in the difference between Microsoft's Visual 
C++ and C# editors.  The latter of which is amazing: the Visual C# 
editor highlights classes, namespaces, and other symbols with different 
colours, always provides *correct* drop-down auto-completion, and even 
underlines syntax errors on the fly.  The C++ editor can do none of 
these things, presumably because of the sheer complexity of C++.

More likely because Visual Studio .NET shipped incomplete :) The Visual Studio 2003 editor is a vast improvement over the 2002 editor if you're interested in things like intellisense. For D I've been using emacs and found it superior in some ways to Visual Studio, though it still has a few kinks to work out. But then I don't much care about intellisense and the other new editor features.
Now we just need something as good as Visual Studio for it. :)

When I see "IDE" I think debugger. If Visual Studio could debug D apps as well as it can C++ apps I would dance for joy. Sean
Jul 03 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...
Mista wrote:

 Ant wrote:
 
 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

No ofcourse not. The goal should be a good language for the user, not for other programs. IDE's can be made to overcome problems, that's not the problem for 'new' languages to solve.

I disagree. If computers can easily understand the source code, then those computers can help us feeble humans out better. Besides, simplicity usually benefits both humans and computers at the same time. It's not a case of having to sacrifice one for the other. The best example of this is in the difference between Microsoft's Visual C++ and C# editors. The latter of which is amazing: the Visual C# editor highlights classes, namespaces, and other symbols with different colours, always provides *correct* drop-down auto-completion, and even underlines syntax errors on the fly. The C++ editor can do none of these things, presumably because of the sheer complexity of C++. At any rate, ease of implementation was and is an overt goal guiding the design of D, and I think it has achieved that admirably.

that's what I mean.
Now we just need something as good as Visual Studio for it. :)

(can I plug leds here? better not...) Ant
Jul 03 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sat, 3 Jul 2004 21:31:51 +0000 (UTC), Ant <Ant_member pathlink.com> 
wrote:
 In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...
 Mista wrote:

 Ant wrote:

 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

No ofcourse not. The goal should be a good language for the user, not for other programs. IDE's can be made to overcome problems, that's not the problem for 'new' languages to solve.

I disagree. If computers can easily understand the source code, then those computers can help us feeble humans out better. Besides, simplicity usually benefits both humans and computers at the same time. It's not a case of having to sacrifice one for the other. The best example of this is in the difference between Microsoft's Visual C++ and C# editors. The latter of which is amazing: the Visual C# editor highlights classes, namespaces, and other symbols with different colours, always provides *correct* drop-down auto-completion, and even underlines syntax errors on the fly. The C++ editor can do none of these things, presumably because of the sheer complexity of C++. At any rate, ease of implementation was and is an overt goal guiding the design of D, and I think it has achieved that admirably.

that's what I mean.
 Now we just need something as good as Visual Studio for it. :)

(can I plug leds here? better not...)

I have not used it yet, I'm on windows... does it have a keyboard mapping which is identical to Visual Studio? I find it really irritating to have to learn a new keyboard mapping for every editor I might want to use. If leds has a Visual Studio keyboard mapping, and runs on windows, then I will switch to it. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 03 2004
next sibling parent reply Andrew Edwards <ridimz_at yahoo.dot.com> writes:
Regan Heath wrote:
 On Sat, 3 Jul 2004 21:31:51 +0000 (UTC), Ant <Ant_member pathlink.com> 
 wrote:
 
 In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...

 Mista wrote:

 Ant wrote:

 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

No ofcourse not. The goal should be a good language for the user, not for other programs. IDE's can be made to overcome problems, that's not the problem for 'new' languages to solve.

I disagree. If computers can easily understand the source code, then those computers can help us feeble humans out better. Besides, simplicity usually benefits both humans and computers at the same time. It's not a case of having to sacrifice one for the other. The best example of this is in the difference between Microsoft's Visual C++ and C# editors. The latter of which is amazing: the Visual C# editor highlights classes, namespaces, and other symbols with different colours, always provides *correct* drop-down auto-completion, and even underlines syntax errors on the fly. The C++ editor can do none of these things, presumably because of the sheer complexity of C++. At any rate, ease of implementation was and is an overt goal guiding the design of D, and I think it has achieved that admirably.

that's what I mean.
 Now we just need something as good as Visual Studio for it. :)

(can I plug leds here? better not...)

I have not used it yet, I'm on windows... does it have a keyboard mapping which is identical to Visual Studio? I find it really irritating to have to learn a new keyboard mapping for every editor I might want to use. If leds has a Visual Studio keyboard mapping, and runs on windows, then I will switch to it.

Sorry old chap, it isn't available for windows: though I eagerly anticipate it's arival. Better yet "DMD" on OpenBSD! Oh well. If I'm not mistaken, it does allow you to customize the kbd_mapping, which is just as effective.
 Regan.
 

Jul 03 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Sat, 03 Jul 2004 21:15:33 -0400, Andrew Edwards 
<ridimz_at yahoo.dot.com> wrote:
 Regan Heath wrote:
 On Sat, 3 Jul 2004 21:31:51 +0000 (UTC), Ant <Ant_member pathlink.com> 
 wrote:

 In article <cc75gv$1gn9$1 digitaldaemon.com>, Andy Friesen says...

 Mista wrote:

 Ant wrote:

 Shouldn't new languages be aware of IDEs?
 features and sintax should be designed having in mind
 that IDEs are here to help on the development cycle.

No ofcourse not. The goal should be a good language for the user, not for other programs. IDE's can be made to overcome problems, that's not the problem for 'new' languages to solve.

I disagree. If computers can easily understand the source code, then those computers can help us feeble humans out better. Besides, simplicity usually benefits both humans and computers at the same time. It's not a case of having to sacrifice one for the other. The best example of this is in the difference between Microsoft's Visual C++ and C# editors. The latter of which is amazing: the Visual C# editor highlights classes, namespaces, and other symbols with different colours, always provides *correct* drop-down auto-completion, and even underlines syntax errors on the fly. The C++ editor can do none of these things, presumably because of the sheer complexity of C++. At any rate, ease of implementation was and is an overt goal guiding the design of D, and I think it has achieved that admirably.

that's what I mean.
 Now we just need something as good as Visual Studio for it. :)

(can I plug leds here? better not...)

I have not used it yet, I'm on windows... does it have a keyboard mapping which is identical to Visual Studio? I find it really irritating to have to learn a new keyboard mapping for every editor I might want to use. If leds has a Visual Studio keyboard mapping, and runs on windows, then I will switch to it.

Sorry old chap, it isn't available for windows: though I eagerly anticipate it's arival. Better yet "DMD" on OpenBSD! Oh well. If I'm not mistaken, it does allow you to customize the kbd_mapping, which is just as effective.

If this is the case, great, but could it ship with some pre defined keyboard mappings, like Visual Studio's. It would make it easier to convert users of other IDE's :) Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 03 2004
prev sibling parent reply Ant <duitoolkit yahoo.ca> writes:
On Sat, 03 Jul 2004 21:15:33 -0400, Andrew Edwards wrote:

 Regan Heath wrote:
 
 Sorry old chap, it isn't available for windows: though I eagerly
 anticipate it's arival. Better yet "DMD" on OpenBSD! Oh well.
 If I'm not mistaken, it does allow you to customize the kbd_mapping, 
 which is just as effective.
 

I'm a eclipse user (at work-windows) that never saw Visual Studio. I started leds after trying jext and admire it's simplicity and effectiveness and after rejecting eclipse on linux just because it's so slow. leds still doesn't compile since dmd 0.91 see the Walter explanations on the "import bug - severe" thread I started on the the D.bugs group. so after that here is the keys configuration screenshot: http://leds.sourceforge.net/prefEditorKeys.html leds is being developed with leds and only recently I'm trying to make it user friendly. This issue was broght up before and I kinda of promissed that I would included several preconfigured keyboard mapping. Please email me your preferred (default for some IDE not customized) keyboard mapping but be prepared to wait :(. Ant
Jul 03 2004
parent reply Andrew Edwards <ridimz_at yahoo.dot.com> writes:
Ant wrote:
 On Sat, 03 Jul 2004 21:15:33 -0400, Andrew Edwards wrote:
 
 
Regan Heath wrote:

Sorry old chap, it isn't available for windows: though I eagerly
anticipate it's arival. Better yet "DMD" on OpenBSD! Oh well.
If I'm not mistaken, it does allow you to customize the kbd_mapping, 
which is just as effective.

I'm a eclipse user (at work-windows) that never saw Visual Studio. I started leds after trying jext and admire it's simplicity and effectiveness and after rejecting eclipse on linux just because it's so slow. leds still doesn't compile since dmd 0.91 see the Walter explanations on the "import bug - severe" thread I started on the the D.bugs group.

I don't see why this is such a big show stopper Ant. I just compiled dui_00.13_97 on WinXP Pro with DMD v0.94 simply by inserting the following alias on line 101 of src/dui/ObjectG.d alias Object.toString toString; No problems encountered whatsoever!
 so after that here is the keys configuration screenshot:
 
 http://leds.sourceforge.net/prefEditorKeys.html
 
 leds is being developed with leds and only recently I'm trying to
 make it user friendly.
 This issue was broght up before and I kinda of promissed that
 I would included several preconfigured keyboard mapping.
 
 Please email me your preferred (default for some IDE not customized)
 keyboard mapping but be prepared to wait :(.
 
 Ant
 

Jul 04 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Sun, 04 Jul 2004 04:43:07 -0400, Andrew Edwards wrote:

 Ant wrote:
 
 leds still doesn't compile since dmd 0.91
 see the Walter explanations on the "import bug - severe"
 thread I started on the the D.bugs group.

I don't see why this is such a big show stopper Ant. I just compiled dui_00.13_97 on WinXP Pro with DMD v0.94 simply by inserting the following alias on line 101 of src/dui/ObjectG.d alias Object.toString toString;

It's ridiculous! Do I have to look for all name colisions? no way! getSize(out int, out int) on duiWindows colides with getSize(char[]) std.file! :( When Walter fixes the multiple std import conflicts and the overload bug all this will go away. Ant
Jul 04 2004
parent reply Andrew Edwards <ridimz_at yahoo.dot.com> writes:
Ant wrote:
 On Sun, 04 Jul 2004 04:43:07 -0400, Andrew Edwards wrote:
 
 
Ant wrote:

leds still doesn't compile since dmd 0.91
see the Walter explanations on the "import bug - severe"
thread I started on the the D.bugs group.

I don't see why this is such a big show stopper Ant. I just compiled dui_00.13_97 on WinXP Pro with DMD v0.94 simply by inserting the following alias on line 101 of src/dui/ObjectG.d alias Object.toString toString;

It's ridiculous! Do I have to look for all name colisions? no way! getSize(out int, out int) on duiWindows colides with getSize(char[]) std.file!

Probably a feature added after dui_00.13_97 (windows version). I had no such problem. I did however, spent quite some time removing deprecated features from the source. To alleviate the name collision problem, I (usually) explicitly qualify all imported functions. std.file.getSize("test.d"); duiWindows.getSize(ivar1, ivar2); It does require a bit more typing, but as long as the import structure remains the same, there is virtually no way my code will become ambiguous. On another note, can I grab a copy of your windows makefile for leds? I've been at it since last eve and I still haven't figured out how to build one yet. Thanks, Andrew
 
 :(
 
 When Walter fixes the multiple std import conflicts
 and the overload bug all this will go away.
 
 Ant
 

Jul 04 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Sun, 04 Jul 2004 13:22:30 -0400, Andrew Edwards wrote:

 
 To alleviate the name collision problem, I (usually) explicitly qualify
 all imported functions.
 
    std.file.getSize("test.d");
    duiWindows.getSize(ivar1, ivar2);

but how do you know all function and methods? you have to inspect all imports and your class hierarchy! it's not possible.
 
 On another note, can I grab a copy of your windows makefile for leds?
 I've been at it since last eve and I still haven't figured out how to
 build one yet.
 

sure. (please follow the discussion at http://groups.yahoo.com/group/duitoolkit/ ) Ant
Jul 04 2004
prev sibling parent Billy Zelsnack <billy_zelsnack yahoo.com> writes:
 I have not used it yet, I'm on windows... does it have a keyboard 
 mapping which is identical to Visual Studio?
 I find it really irritating to have to learn a new keyboard mapping for 
 every editor I might want to use.
 If leds has a Visual Studio keyboard mapping, and runs on windows, then 
 I will switch to it.

The ide deal breaker for me is the lack of workspace whiz (wwhiz.com) file globber equivalent. omg. Any editor without it feels like my hands are wrapped in duct tape.
Jul 03 2004
prev sibling parent "Bent Rasmussen" <exo bent-rasmussen.info> writes:
 At any rate, ease of implementation was and is an overt goal guiding the
 design of D, and I think it has achieved that admirably.

 Now we just need something as good as Visual Studio for it. :)

You hear that Ant -- we're counting on you! :-)
   -- andy

Jul 03 2004
prev sibling parent Benji Smith <dlanguage xxagg.com> writes:
On Fri, 2 Jul 2004 19:11:44 +0000 (UTC), Ant <Ant_member pathlink.com>
wrote:

Shouldn't new languages be aware of IDEs?
features and sintax should be designed having in mind
that IDEs are here to help on the development cycle.

Well, it's waaaay too late for D to include this kind of feature, but... I've always thought it would be beneficial to create a logical tie between a comment and the line (or block) of code to which that comment belongs. Rather than a comment just being a line of text appearing before or after (or to the right of) a given line of code, the comment would be an ATTRIBUTE of an expression. To give a quick example of what I'm talking about, pretend that the # symbol is a comment marker. In the following line of code, there are four different comments: MyObject #instance = (new Object(#parent, #child)).#getInstance(); ...so, one line of code might contain four different comments. Or a single comment might be logically tied to multiple lines (or an entire block) of code. Of course, a really great IDE wouldn't display the # characters like I have. Instead, it might use a pale yellow background (or a dotted underline...or whatever) for each component of the expression for which a comment was attached. Hovering the mouse over the appropriate part of the expression would reveal the comment. (...or something like that...) Of course, it would be very difficult to implement comments like this in an ordinary source file. For it to work, the comments would have to be a part of a separate metadata file with links back to the lines and blocks in the source file. If comments were implemented this way, it would be possible, using a diff of the source file, to determine which comments might be out-dated (since the expressions to which those comments were linked had undergone changes). It would also be possible to include, as comments, a diverse array of different types of media, like graphics, sound files, and presentations. It would also be possible to create, in a comment, a hyperlink to another location in the source code, even if the line number of the hyperlink target changed over time. In short, I think there's a vast arena of unexplored possibilities that become possible when you include source metadata files as part of the source code for an application. Incidentally, I'm aware of the metadata used by the .NET framework, but that's different. MSIL metadata is used in the execution of the program. The source metadata that I'm talking about would only be used used as a tool to aid programmers in documentation and code navigation. But it would be nearly impossible to use language features like this unless direct support for them was built into the IDE. And it would prevent anyone from using plain vanilla text editors to edit the source. In fact, the only way that such a language/IDE would ever be developed would be if they were developed in parallel, allowing the IDE ideas to feed into the brainstorming of the language development (and vice versa). So, I'm somewhat skeptical that these types of tools will ever become commonplace. But those are some ideas that I've been thinking about for a long time.
Jul 05 2004