On 1 September 2013 17:37, Manu <turkey...@gmail.com> wrote: > On 2 September 2013 01:02, Iain Buclaw <ibuc...@ubuntu.com> wrote: >> >> On 1 September 2013 03:05, Manu <turkey...@gmail.com> wrote: >> > IDE integration absolutely needs to be considered a first class feature >> > of >> > D. >> >> An IDE is not a feature of a language. Unless you are a RAD language >> that removes the ability of developers to write a single line of code >> (and do it awfully). > > > It certainly is in the case of C#. I think it's also central to C#'s > success. People got in, and feel productive within seconds of firing it up. > I've never had such a great language adoption experience. I clicked create > project, and started writing code. > The IDE is super helpful, and you can basically code by using the '.' key > and consequent auto-completion popups as a documentation replacement. >
Yeah... I'm still not buying it. :o) >> > Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the >> > only >> > realistic choices available. The OSX user would have preferred an XCode >> > integration. >> > >> >> Why not VIM? > > > Ummm, because I'm not a masochist? :) > But each to their own. No reason VIM shouldn't have a nice integration > too... > Well my perspective doesn't help that whenever I think of IDE, the image of clippy comes into my head. http://vigor.sourceforge.net/screenshots/fullscreen.png >> > I think continuous code compilation for auto-completion and syntax >> > highlighting purposes should be a service offered and maintained by DMD. >> > That way it will evolve with the language, and anyone can use it without >> > reinventing the wheel. >> > >> >> WAT. > > > The D frontend, whatever... it should be recycled to do the work, since it's > already the best at it. I'm just repeating myself... > Ah, I just didn't understand what you were referring to first time round (the "as a service" was confusing also. :o) I assume you mean using *enter IDE name here* to run syntax checks on your code as you type to highlight errors before you build using the compiler proper? >> > >> > Debugging: >> > >> > Poor debugging experience wastes your time every 5 minutes. >> > I can only speak for the Windows experience (since we failed to get OSX >> > working); there are lots of problems with the debugging experience under >> > visual studio... >> > I haven't logged bugs yet, but I intend to. >> > There were many instances of people wasting their time chasing bugs in >> > random places when it was simply a case of the debugger lying about the >> > value of variables to them, and many more cases where the debugger >> > simply >> > refused to produce values for some variables at all. >> > This is an unacceptable waste of programmers time, and again, really >> > burned >> > us in a 48hour context. >> > >> > >> >> This is why GDC rox. > > > O_o ... GDC produces DWARF info, which isn't so useful in windows. > We used to roll with dwarf->pdb conversion, but I think there's quite a loss > in translation, and it didn't work too well. > This is why using a free system rox. >> > Bugs: >> > Yes, we hit DMD bugs, like the one with opaque structs which required >> > extensive work-arounds. >> > struct MyStruct; >> > MyStruct*[] = new MyStruct*[n]; >> > >> >> I'm not sure if that should work / don't see the advantage over just >> using a void*. > > > struct Mesh; > struct Material; > > Mesh* mesh; > Material* material; > > material = mesh; // ? > The only used case I can think is in C++ bindings where you don't want to define the contents, but want to have the correct mangling (this I've had a partial need for in a project I'm working on behind the scenes that will come out at around the 2.064 release :-) The language implementation would have to be changed to not produce TypeInfo for opaque types, but this might be undesirable in restrictions to the use of such types, but I guess you are asking for it if you want it. >> > One more thing: >> > I'll just pick one language complaint from the weekend. >> > It is how quickly classes became disorganised and difficult to navigate >> > (like Java and C#). >> > We all wanted to ability to define class member functions outside the >> > class >> > definition: >> > class MyClass >> > { >> > void method(); >> > } >> > >> > void MyClass.method() >> > { >> > //... >> > } >> > >> > It definitely cost us time simply trying to understand the class layout >> > visually (ie, when IDE support is barely available). >> > You don't need to see the function bodies in the class definition, you >> > want >> > to quickly see what a class has and does. >> > >> > >> >> That does seem more of the point of D interface files (.di). > > > I'm amazed at the resistance to this (a few no's, any yes's at all?). Do > people here actually write D code, or rather, non-trivial D code? O_o Yes... though not outside the boundaries of implementing languages / interpreters / bytecode compilers. ;-) > Perhaps the dev's here use relatively few, or very simple classes? K.I.S.S. > Seriously, how do you quickly read and understand the API through the noise? Depends how well the author was at documenting his API. > I really can't get my head around it... Why wouldn't you want to be able to > read a convenient summary of what a class is and does? Document the class as you write it. > And why would you want to indent every line of function code by a few tabs? > I use GNU style myself... (that probably *does* make me a masochist). http://en.wikipedia.org/wiki/Indent_style#GNU_style -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
