Jump to page: 1 24  
Page
Thread overview
Opinion of February 2012
Feb 03, 2012
Zachary Lund
Feb 04, 2012
bearophile
Feb 04, 2012
Nick Sabalausky
Feb 04, 2012
Walter Bright
Feb 04, 2012
Bernard Helyer
Feb 04, 2012
Nick Sabalausky
Feb 04, 2012
q66
Feb 04, 2012
Nick Sabalausky
Feb 05, 2012
Daniel Murphy
Feb 05, 2012
Gour
Feb 04, 2012
H. S. Teoh
Feb 04, 2012
Daniel Murphy
Feb 04, 2012
James Miller
Feb 04, 2012
Jesse Phillips
Feb 04, 2012
Zachary Lund
Feb 04, 2012
H. S. Teoh
Feb 04, 2012
Walter Bright
Feb 04, 2012
H. S. Teoh
Feb 05, 2012
Walter Bright
Feb 05, 2012
H. S. Teoh
Feb 05, 2012
Zachary Lund
Feb 04, 2012
Martin Nowak
Feb 04, 2012
Artur Skawina
Feb 04, 2012
Nick Sabalausky
Feb 04, 2012
Nick Sabalausky
Feb 04, 2012
Zachary Lund
Feb 04, 2012
Nick Sabalausky
Feb 04, 2012
Zachary Lund
Feb 04, 2012
Jesse Phillips
Feb 04, 2012
Zachary Lund
Feb 04, 2012
Walter Bright
Feb 04, 2012
Jacob Carlborg
Feb 04, 2012
Walter Bright
Feb 05, 2012
Don
Feb 05, 2012
Zachary Lund
Feb 05, 2012
Walter Bright
Feb 05, 2012
H. S. Teoh
February 03, 2012
Here are some things I'm unhappy with currently.

1. Documentation

I find certain things, of which I will start writing down and writing patches for, in the documentation that are unsatisfactory. Two in particular is the current situation with memory management and CTFE. "delete" is planned for deprecation and alternative methods for custom de/allocators are already in place, yet most people don't even know about them or how to use them. I see talk on IRC about things that completely confuse me as to the state of things and I can generally find no obvious or reliable source of information. It's completely frustrating.

Documentation is much more important than feature implementation.

2. Milestones and Organization

Despite the initiative Andrei took to get the community organized and most people completely shutting his attitude down, D is still left in a a rather unorganized state. I don't mind DMD using bugzilla but extensive use of the simple milestone feature should be made and posted somewhere on the site to be made clearly visible as a semi-roadmap to the next release. Currently, there's no milestone for 2.058 (although there is one for 2.059 which makes no sense) so it seems that the 2.058 release will be, once again, completely random. At this point, I'd say the state of organization is still pathetic and/or scary.

3. FAQ

I think there was a discussion somewhere (of which I can't find now through Thunderbird search) but the FAQ is important. When people wonder about a feature of D, the first thing they should do is check the FAQ to find the answer.

I think that each time a solution is provided that might or might not be obvious, the reasoning behind that solution should be posted on the FAQ. Nothing should be left with abstract reasoning (outside of perhaps philisophy-based reasoning).

The FAQ is incomplete.

4. Microsoft

Windows. I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was never updated, and people had to move to MacOS or Linux, I would be the happiest man alive. Unfortunately, this will seemingly never be the case and it stands that Microsoft has the highest share of all the OS users. Thus, it should be given higher priority to attract more users. When people complain about D not having large Windows support (or COFF support in particular and the shitty optlink), it kills me a little on the inside.

5. Naming

This is probably a lost cause but I've recently seen various complaints about the name "D". It's not distinct nor is D old enough to be known like C or C++ is. I remember a comment about the name "Mars" which I think would have been much more distinct and clearcut, and would have caused less issues.

It also drives me insane that dmd for D2 is not named dmd2. There's no reason to not have it be dmd2 and you just stupidly caused incompatibility with the D1 executable. Not that it matters anymore but the fact that that's what happened looks incredibly dumb. Software like DVM popped up and while I appreciate such software, I don't think such software should be needed in the first place. Although, I do realize DVM has other uses.

The .c extensions on C++ files... need I say more? That itself is a joke and seems to have been ignored when complaints about it came up. I've just recently been told that DMD was mostly implemented in C which is false. This situation is needlessly frustrating.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I'm not really affected by the in-language subtleties so much nor do they bother me. I'll post a bug if I find one, it will eventually get fixed, and I continue to use D. However, I can't help but complain about things when they're going unnoticed or unattended. I'd like to place my own personal emphasis on things I think need more thought put into them each month. Most of these complaints should have greater reasoning behind them which I will state. However, please comment on where I'm wrong or your own opinion against mine.

I like the D language. Not so much the projects that surround D.
February 04, 2012
Zachary Lund:

> The .c extensions on C++ files... need I say more? That itself is a joke and seems to have been ignored when complaints about it came up. I've just recently been told that DMD was mostly implemented in C which is false. This situation is needlessly frustrating.

Aren't less than 10 minutes enough to fix this simple problem?
I don't know why Walter likes to use ".c" as suffix for those files, I don't remember his answers on this topic, I have never appreciated this naming decision.

Bye,
bearophile
February 04, 2012
On Fri, Feb 03, 2012 at 05:12:08PM -0600, Zachary Lund wrote:
> Here are some things I'm unhappy with currently.
> 
> 1. Documentation
> 
> I find certain things, of which I will start writing down and writing patches for, in the documentation that are unsatisfactory. Two in particular is the current situation with memory management and CTFE. "delete" is planned for deprecation and alternative methods for custom de/allocators are already in place, yet most people don't even know about them or how to use them. I see talk on IRC about things that completely confuse me as to the state of things and I can generally find no obvious or reliable source of information. It's completely frustrating.
> 
> Documentation is much more important than feature implementation.

I agree with this. Based on current documentation, I didn't even know the GC can be replaced at compile-time until someone mentioned it. And up to now I still don't know how exactly to do this, since I couldn't find any docs for it.

Some of the docs on the website are also deficient, for example std.uni (which I already filed a bug for), due to missing doc comments in the code.

I'd like to help. My D coding skills are still not up to snuff for fixing the hard stuff, since I only just started learning D. But doc comments I can do. However, there's no documentation that I can find that describes the procedure for sending contributions. Such as where to upload patches, what format they should be in, how to get diffs in the right format, etc.. All this should be documented so that willing contributors can jump in immediately, instead of being put off by having to jump through unnecessary hoops (like hunting for possibly non-existent documentation on how to contribute).

Another big missing with the documentation is a timestamp. The problem is that some of the docs are out-of-date, but it looks identical to the up-to-date pages, so it's very confusing for someone who doesn't already know the answer. If you try something the docs say but it doesn't work, then instead of pulling your hair out, you can look at the timestamp that says "last updated 2005" and know that perhaps the info is out of date and it isn't some bug in your code.

Timestamps will also tell potential contributors which pages to work on, if they notice the info is wrong and/outdated.

Of course, this doesn't replace keeping the docs up-to-date, but it's better than nothing.


[...]
> 3. FAQ
> 
> I think there was a discussion somewhere (of which I can't find now through Thunderbird search) but the FAQ is important. When people wonder about a feature of D, the first thing they should do is check the FAQ to find the answer.
> 
> I think that each time a solution is provided that might or might not be obvious, the reasoning behind that solution should be posted on the FAQ. Nothing should be left with abstract reasoning (outside of perhaps philisophy-based reasoning).
> 
> The FAQ is incomplete.

Agreed. I'm thinking the FAQ should include common newbie mistakes / surprises, so that newcomers won't get overly frustrated with bugs that are actually very simple but they have no idea how to fix it.


> 4. Microsoft
> 
> Windows. I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was never updated, and people had to move to MacOS or Linux, I would be the happiest man alive.

Ahhhahahaha... I wish this were true too. ;-)


> Unfortunately, this will seemingly never be the case and it stands that Microsoft has the highest share of all the OS users. Thus, it should be given higher priority to attract more users. When people complain about D not having large Windows support (or COFF support in particular and the shitty optlink), it kills me a little on the inside.

I agree, though I can't do very much to help on this front 'cos I haven't done any serious work on windows for the last 10 years. (I almost fell out of my chair (for joy) at my interview for my current job when I found out that they used the gcc toolchain for development -- there was no indication of this on the job posting.)


> This is probably a lost cause but I've recently seen various complaints about the name "D". It's not distinct nor is D old enough to be known like C or C++ is. I remember a comment about the name "Mars" which I think would have been much more distinct and clearcut, and would have caused less issues.

I tend to agree too. The name "D" never fails to raise an eyebrow with my friends when I mention that I'm learning it -- they regard it as the next joke in the sequence C, C+, C++. (I know there is no such thing as C+, but that's what your average layperson thinks.) It's also very hard to search for online, since there are too many irrelevant matches.

But yeah, it's a lost cause. Especially now that Andrei's book bears that name in print. It will be almost impossible to reverse the effects of that.


[...]
> The .c extensions on C++ files... need I say more? That itself is a joke and seems to have been ignored when complaints about it came up. I've just recently been told that DMD was mostly implemented in C which is false. This situation is needlessly frustrating.

Now *that* is evil.


[...]
> I like the D language. Not so much the projects that surround D.

I like D too. I'd like to help in whatever way I can to make it a successful language. I hope I will never have to go back to that creeping horror known as C++.


T

-- 
Guns don't kill people. Bullets do.
February 04, 2012
> Documentation is much more important than feature implementation.
>
Contribution highly welcome at:
https://github.com/D-Programming-Language/d-programming-language.org
February 04, 2012
On 02/04/12 01:28, H. S. Teoh wrote:
> I agree with this. Based on current documentation, I didn't even know the GC can be replaced at compile-time until someone mentioned it. And up to now I still don't know how exactly to do this, since I couldn't find any docs for it.

There's nothing special about the GC, you just need to link to your implementation. Or take the one from druntime, modify it and make sure the object containing the necessary symbols is found before the std library, eg by compiling MyGCImpl.d together with the other D source files. That's all.

artur
February 04, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.347.1328315188.25230.digitalmars-d@puremagic.com...
> I'd like to help. My D coding skills are still not up to snuff for fixing the hard stuff, since I only just started learning D. But doc comments I can do. However, there's no documentation that I can find that describes the procedure for sending contributions. Such as where to upload patches, what format they should be in, how to get diffs in the right format, etc.. All this should be documented so that willing contributors can jump in immediately, instead of being put off by having to jump through unnecessary hoops (like hunting for possibly non-existent documentation on how to contribute).

Everything is on github these days.  Eg for the website , https://github.com/D-Programming-Language/d-programming-language.org

> However, there's no documentation

We should have this, but like everything else, it requires somebody take the time to do it.


February 04, 2012
"bearophile" <bearophileHUGS@lycos.com> wrote in message news:jght4f$2co0$1@digitalmars.com...
>
> I don't know why Walter likes to use ".c" as suffix for those files, I don't remember his answers on this topic,
>

In the most recent discussion he just dodged the question and joked about the "platform nobody uses" bit.


February 04, 2012
"Zachary Lund" <admin@computerquip.com> wrote in message news:jghpk4$26uk$1@digitalmars.com...
>
> 2. Milestones and Organization

This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.

> I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was never updated, and people had to move to MacOS or Linux, I would be the happiest man alive.

Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)


> It also drives me insane that dmd for D2 is not named dmd2. There's no reason to not have it be dmd2 and you just stupidly caused incompatibility with the D1 executable.

https://bitbucket.org/doob/dvm

$dvm use 1.069
$dvm use 2.057
etc...

Trivial problem trivially solved.

> The .c extensions on C++ files... need I say more? That itself is a joke and seems to have been ignored when complaints about it came up.

Everyone already knows and agrees.


February 04, 2012
>> However, there's no documentation
>
>We should have this, but like everything else, it requires somebody take the time to do it.

So true, I spent literally 5 hours writing documentation for a project I was releasing. It wasn't even that big. And I didn't write any reference documentation. I maybe could have done it faster, cut it down to 3-3.5 hrs, but it takes so long to do properly.

Not only do you need reference materials, you need example usage, explanations of what to use when (and ideally why). Each example needs to be tested, made sure that it is concise without being opaque and documented itself. You paradoxically need somebody who knows exactly what the code does, but knows what is unobvious and what is "advanced use" only.

> I like the D language. Not so much the projects that surround D.

Same, having essentially 2 incompatible languages and 2 incompatible "standard" libraries has been devastating. My personal opinion is that Phobos, being maintained by the creators of the language, should be the defacto library and everybody should be encouraged to use it for most purposes. Tango shouldn't be a replacement for Phobos but work alongside it, (a goal that the Tango-D2 team seem to be aiming for) because having to change libraries to compile different programs is a nightmare. And all new development should be in D2, no point sticking to D1 now that support has been officially dropped.

So many projects simply don't work. Some have had underlying libraries do breaking changes from under them, others rely on Tango D1 which makes trying to port them to D2 effectively impossible (though it should be easier now that most of Tango-D2 is done), and some haven't had any development for years and just aren't useful.

The community needs some organisation. Currently DSource is not actually that useful, Trac is all about SVN, but D and most other libraries use git/GitHub which makes for a clunky experience. If D-Programming-Language.org had a projects section, it would make it much easier to manage and make more sense, there is no direct link from the official website to any centralized project repository, which makes discovery a nightmare. Many people do not want to join a mailing list or ask in IRC just to find if a library or program exists.

--
James Miller
February 04, 2012
"Nick Sabalausky" <a@a.a> wrote in message news:jgij59$hc2$1@digitalmars.com...
> "Zachary Lund" <admin@computerquip.com> wrote in message news:jghpk4$26uk$1@digitalmars.com...
>>
>> 2. Milestones and Organization
>
> This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.
>
>> I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was never updated, and people had to move to MacOS or Linux, I would be the happiest man alive.
>
> Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)
>
>
>> It also drives me insane that dmd for D2 is not named dmd2. There's no reason to not have it be dmd2 and you just stupidly caused incompatibility with the D1 executable.
>
> https://bitbucket.org/doob/dvm
>
> $dvm use 1.069
> $dvm use 2.057
> etc...
>
> Trivial problem trivially solved.
>
>> The .c extensions on C++ files... need I say more? That itself is a joke and seems to have been ignored when complaints about it came up.
>
> Everyone already knows and agrees.
>

I don't mean to be an ass about it, I know how infuriating it is to come into a group and get immediately lynched. It's just that every couple months we inevitably get yet another first-time (or nearly-first-time) poster who gives us a big essay on everything we're doing wrong and how they're going to swoop in and save us from ourselves with their basic observations, all of which inevitably fall into:

A. Things everyone already knows, agrees on, and is being worked on.

B. Things they can easily contribute to themselves.

C. Things that are already taken care of.

D. Things that have already been brought up, discussed, and are never going to happen (and have *then* been discussed a couple more times).

E. Things that are just plain false.

It's a pattern that just gets very old very quickly.



« First   ‹ Prev
1 2 3 4