>
> I didn't say an IDE was bad for D, I only said that if you need an IDE to generate boilerplate for you, then there's something wrong with the language.
>
> IDE's have lots of other valuable uses.

There is one case of generating boilerplate code which can hardly be avoided and would at least partially solve a problem that keeps coming up in one form or another:

For every new language feature that uses some form of attributes (ie. almost all of them) there is the problem of how automatically the attributes are applied, generally with these possibilities:

- The attribute is a purely internal concept used and deduced by the compiler. This has the problem that unless these attributes are in some way stored in the .di file the compiler has now way to determine them when it cannot see the code. It also leaks implementation details into the interface.

- The attribute is explicitly defined but inferred in some cases by the compiler.
This has the problem that it's now not obvious whether the attribute can be inferred or not, there are more rules to know about when automatic deduction is done, and there will still be many cases where the attributes cannot be safely inferred without leaking implementation detail, but the programmer forgets to add them.

- The attribute is explicitly defined but is inferred when "auto" is present.
This has the problem that there's no good way to finely tune which attributes "auto" should infer, and no way to un-set attributes. When "auto" is used on methods for use by external code it is again leaking implementation detail.

None of these are very satisfactory. A good solution should make it clear to the programmer which attributes are applied, make it easy to apply all the attributes which can be inferred but also easy to then change them, and not change when the implementation changes.

An IDE command which automatically infers all the attributes would seem to be the only way to solve this well. Unfortunately it doesn't exist yet... Anyway it would be worthwhile deciding on a consistent way to handle attributes as the number of them increase, and it would be worth making sure that whatever way is chosen is compatible with such a potential IDE feature.

Another option would be to add an attribute called "default" or something like that, and have the compiler issue a message if it finds a function with no attributes that tells the programmer what attributes the function COULD have so it's a reminder to either add them, or put "default" after it.

On Fri, 10 May 2013 18:59:23 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
[...snip Java vs D samples...]
> Talk about signal-to-noise ratio.
> 
> And don't get me started on all those BlahBlahBlahClassWrapper's and BlahBlahBlahClassWrapperFactoryWrapper's. Ugh. And Integer vs. int, and other such atrocities. What, built-in atomic types are defective so we need to wrap them in classes now? Flawed language design, anybody?
> 
> I find D superior to Java in just about every possible way. Except
[..snip..]
> 
> > Sometimes C++ give me hives, it's so error prone and an under-productive language for the actual industry needs, that certainly why Google created the Go.
> 
> Surprisingly enough, before I found D, I actually considered ditching C++ for C. I only stayed with C++ because it has certain niceties, like exceptions, (and no need to keep typing 'struct' everywhere on a type that's blatantly obviously a struct) that in C is a royal pain in the neck. C++ is just over-complex, and its complexity in different areas interact badly with each other, making it an utter nightmare to work with beyond trivial textbook examples. OO programming in C++ is so nasty, it's laughable -- if I wanted OO, Java would be far superior.
> 

Yea. Somewhere close to 10 years ago, it was precisely the nightmarish combination of C++ and Java that pushed me to do some language searching which led me to (an early) D.

Learning Java taught me all the reasons to hate C++, but then Java also
went and threw away the *good* things about C/C++, too. As those
were the languages I needed to use the most, the constant "Which hell
do I want? Hell A or Hell B?" damn near soured me on programming in
general.

Then C# and D came along and made programmer life tolerable again ;) I've since gotten tired of C# too, though. The limitations of its generics, and MS's continued disinterest in fixing them, finally drove me to ditch it forever. D by contrast has only gotten better with age.

> I found that C++ is only tolerable when I
> use it as "C with classes".

That's always been my strategy with C++. Originally because I didn't know any of its fancier stuff, and now because I just don't want to deal with any of its "frills".

Funny thing: I absolutely can't stand highly dynamic languages, period, but after re-introducing myself to C/C++ on a project last year, I'm understanding much better why so many game devs are so big on Lua.

On Fri, 10 May 2013 21:45:06 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> 
> Yes, which is why I love D so much. All I need is a text editor and the compiler, and I can do everything. Even unittesting and coverage are all integrated. No need for external tools, no need to install a whole bunch of support software, all the essentials are bundled with the compiler. How much more compelling can it get?
> 

The nicest thing of all, IMO, about not strictly needing all that support software is that basic things like editing/navigating/opening/closing code is always and forever 100% unobstructed by things like startup delays and keyboard input lag which have no business existing on the rocket-engined supercomputers we now call "a PC".

On Fri, 10 May 2013 19:04:31 -0400
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> On Friday, May 10, 2013 14:31:00 H. S. Teoh wrote:
> > As they say in information theory: it is the stuff that stands out, that is different from the rest, that carries the most information. The stuff that's pretty much repeated every single time conveys very little information.
> 
> This is an excellent way of looking at language design (and program
> design for that matter).
> 

Not to mention data compression ;)

On Saturday, May 11, 2013 23:59:44 Nick Sabalausky wrote:
> On Fri, 10 May 2013 19:04:31 -0400
> 
> "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:
> > On Friday, May 10, 2013 14:31:00 H. S. Teoh wrote:
> > > As they say in information theory: it is the stuff that stands out, that is different from the rest, that carries the most information. The stuff that's pretty much repeated every single time conveys very little information.
> > 
> > This is an excellent way of looking at language design (and program
> > design for that matter).
> 
> Not to mention data compression ;)

LOL. Yes. That's pretty much what you have to look at in data compression by definition - that and finding ways to make more of the data which is different the same without losing too much information or quality (at least with lossy compression).

- Jonathan M Davis

On Saturday, 11 May 2013 at 21:06:28 UTC, Walter Bright wrote:
> On 5/11/2013 1:07 PM, Jeff Nowakowski wrote:
>> I can get by with a hammer and nails too, but if I was a professional roofer I'd
>> be an idiot not to use a nail gun. That's the problem with all this focus on
>> boilerplate. An IDE does so much more to make you productive in any language,
>> especially one that has static types.
>
> I didn't say an IDE was bad for D, I only said that if you need an IDE to generate boilerplate for you, then there's something wrong with the language.
>

I keep repeating myself, but this is true, unless the boilerplate is here for the very reason of IDE integration.

Stupid inexpressive language are easier to write tools for, this is the very reason why java have such a great tooling.

> IDE's have lots of other valuable uses.

On 5/11/2013 10:57 PM, deadalnix wrote:
> Stupid inexpressive language are easier to write tools for, this is the very
> reason why java have such a great tooling.

You run the risk of having a write-only language if the expressivity is in the tools rather than the language.

On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:
> On 5/11/2013 10:57 PM, deadalnix wrote:
>> Stupid inexpressive language are easier to write tools for, this is the very
>> reason why java have such a great tooling.
>
> You run the risk of having a write-only language if the expressivity is in the tools rather than the language.

Tools don't have to show you what is in the text file. That is the beauty of it. IntelliJ for instance, don't show java source code as it is in the source.

On 5/12/2013 1:42 AM, deadalnix wrote:
> On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:
>> On 5/11/2013 10:57 PM, deadalnix wrote:
>>> Stupid inexpressive language are easier to write tools for, this is the very
>>> reason why java have such a great tooling.
>>
>> You run the risk of having a write-only language if the expressivity is in the
>> tools rather than the language.
>
> Tools don't have to show you what is in the text file. That is the beauty of it.
> IntelliJ for instance, don't show java source code as it is in the source.

I.e. you've invented another language that has Java as its output so the user never sees Java because Java is not presentable to users.

On Saturday, 11 May 2013 at 22:11:25 UTC, Diggory wrote:
>> ...

That provokes another argument about attribute inference, off-topic one :) Must resist!