October 13, 2020
On Tuesday, 13 October 2020 at 03:28:38 UTC, Adam D. Ruppe wrote:
> Gotta disagree with this too. D's module system handles the name beautifully and `to` has been a smashing success with few problems in use. The response most people have with it is "wow that's the easiest thing I've ever seen in any language".

+1
October 13, 2020
On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
>
> The unfortunate thing in the video was 'to' is not searchable on the internet and it took them a long time to figure out how to use a to!string expression. :/
>
> Ali

I'm far from being the sharpest tool in the shed but a little common sense could have helped them quite a bit. Like knowing I'm searching for a particular construct in the D Language, I'd prefix my searches with dlang. In this particular case "dlang to!string" pulled up the solution as the first hit of the returned results.

But to be honest, given a website with a search bar, I would never return to Google to search for anything I'd expect to find on that site. Or if I did, at the very least, I'd prefix my searches with site:dlang.org.

Which reminds me, we need to include a search bar on tutor.dlang.org. It should point to the library by default and have the option to change to other sections of the site similar to the search feature on other pages on the site.

Also, there are code samples throughout the site that provide a run button but does not import the appropriate modules to ensure successful compilation. I think that hurts more than watching those two guys pretending to be newbies to programming.

Listening to the conversation those two were having, it is clear that they've been programming for a while. Maybe not in D, but they are actual programmers. This presentation caused some frustration since they were trying to act like they knew absolutely nothing about programming and did things I don't think even the most novice of programmers would do.
October 13, 2020
On Monday, 12 October 2020 at 17:33:04 UTC, Q. Schroll wrote:
> On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
>> The unfortunate thing in the video was 'to' is not searchable on the internet
>
> It's not even searchable on the DLang site (e.g. using site:dlang.org on DuckDuckGo); we should avoid these names. Renaming `to` to `convertTo` would solve that using
>
>     import std.conv : to = convertTo;
>
> when using it. It costs a few keystrokes tho.

I don't even understand the issue here. If I am having an issue with something written to!string, why on earth would I search for to? I would simply search for to!string because that's where my problem lies. Which, by the way, provides the solution to my problem in the first hit of the returned results.
October 13, 2020
On Tuesday, 13 October 2020 at 05:22:52 UTC, Andrew Edwards wrote:
> On Monday, 12 October 2020 at 17:33:04 UTC, Q. Schroll wrote:
>> On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
>>> The unfortunate thing in the video was 'to' is not searchable on the internet
>>
>> It's not even searchable on the DLang site (e.g. using site:dlang.org on DuckDuckGo); we should avoid these names. Renaming `to` to `convertTo` would solve that using
>>
>>     import std.conv : to = convertTo;
>>
>> when using it. It costs a few keystrokes tho.
>
> I don't even understand the issue here. If I am having an issue with something written to!string, why on earth would I search for to? I would simply search for to!string because that's where my problem lies. Which, by the way, provides the solution to my problem in the first hit of the returned results.

There will never be a place in code where to is used without being instantiated.

to!
to!(
to!string
to!int
to!double
to!float
to!char
to!long

In every std.conv is the first result returned.
October 13, 2020
On Monday, 12 October 2020 at 20:11:51 UTC, Walter Bright wrote:
> On 10/12/2020 11:17 AM, Steven Schveighoffer wrote:
>> As I understand it, these functions to import mappings are hard coded in the compiler.
> https://github.com/dlang/dmd/blob/master/src/dmd/imphint.d
>
> Of course, this won't work for "to" since there are multiple declarations of "to" in Phobos (shoot me now).

I think making that list dynamic rather than hard coded might be it. But for add "to" -> "std.conv.to"
October 13, 2020
On Tuesday, 13 October 2020 at 05:11:08 UTC, Andrew Edwards wrote:
> On Monday, 12 October 2020 at 17:04:01 UTC, Ali Çehreli wrote:
>>
>> The unfortunate thing in the video was 'to' is not searchable on the internet and it took them a long time to figure out how to use a to!string expression. :/
>>
>> Ali
>
> I'm far from being the sharpest tool in the shed but a little common sense could have helped them quite a bit. Like knowing I'm searching for a particular construct in the D Language, I'd prefix my searches with dlang. In this particular case "dlang to!string" pulled up the solution as the first hit of the returned results.
>
> But to be honest, given a website with a search bar, I would never return to Google to search for anything I'd expect to find on that site. Or if I did, at the very least, I'd prefix my searches with site:dlang.org.
>
> Which reminds me, we need to include a search bar on tutor.dlang.org. It should point to the library by default and have the option to change to other sections of the site similar to the search feature on other pages on the site.
>
> Also, there are code samples throughout the site that provide a run button but does not import the appropriate modules to ensure successful compilation. I think that hurts more than watching those two guys pretending to be newbies to programming.
>
> Listening to the conversation those two were having, it is clear that they've been programming for a while. Maybe not in D, but they are actual programmers. This presentation caused some frustration since they were trying to act like they knew absolutely nothing about programming and did things I don't think even the most novice of programmers would do.

Indeed it was infuriating to see these clowns even finding the right pages to their problems but not noticing because they didn't bother to actually read the pages they consulted. RTFM! (how to download the compiler? maybe by clicking on the "download" menu entry, you fool. What are these 3 compilers? Maybe read the description in front on them, you dummy)
Clicking and copy pasting randomly without even trying to read stuff is not good process. It was a wonder that they even came as far as they did when seeing their broken methodology.
We should also be wary to not cater too much on making the pages fool proof, it will only breed better fools.
Sorry if it is a bit inflammatory but it was annoying to see these two guys fumbling around like idiots where 30 seconds of reading would have solved their issues. If that is the new normal of post millenial programmers then may God (and I'm an atheist) have mercy on us when all boomers have retired.
October 13, 2020
On Monday, 12 October 2020 at 20:06:31 UTC, Walter Bright wrote:
> The general rule is, the more global a name is, the longer it should be. The more local, the shorter.

According to Clean Code, that's true for variable names. But for functions, it's the opposite. Because, the more global a function is, the more general it is (or ought to be). The more local a function is, the more specialized it is.

--
/Jacob Carlborg
October 13, 2020
On Monday, 12 October 2020 at 13:24:17 UTC, Steven Schveighoffer wrote:
> Try this in a D file:
>
> foo[] foos;
>
> And you get an error like:
>
> Error: undefined identifier foo, did you mean variable foos?
>
> I know why this happens, is there a way to get it not to happen? Some of these can actually be really puzzling. I've seen stuff like "no identifier foo.bar, did you mean foo.bar?"
>
> -Steve

I suspect this old bug report is related, and there's an explanation for what would have to change in order to fix it.

https://issues.dlang.org/show_bug.cgi?id=5621
October 13, 2020
On Monday, 12 October 2020 at 19:35:37 UTC, Walter Bright wrote:

> "Yes" and "No" are also poor names, the latter is hopelessly ungreppable.

I agree that `Yes` and `No` are bad names.

> Furthermore, they are just redundant to "true" and "false". They never should have been put in Phobos.

But the problem with `true` and `false` is that it's difficult to know the meaning at the call site. That can be solved with a custom enum for each function, that allows for better names. Or with named arguments (which D doesn't support yet). But unless you're using Swift or Objective-C, there's nothing that force you do use named arguments on the call site.

--
/Jacob Carlborg
October 13, 2020
On Monday, 12 October 2020 at 20:46:07 UTC, Steven Schveighoffer wrote:

> What do you mean? Just add "to" : "std.conv". Is there a problem with it?

It's already in the list [1], it's been there for two years. Unfortunately it's not that simple. The current implementation is a very simple mapping of a name to an import. What if there are multiple module level symbols with the same name in Phobos or druntime? Then the compiler will be wrong in some of those cases. Also, take this for example:

auto too(T, U)(U value)
{
    return value;
}

void main()
{
    auto a = 3.to!string;
}

This will result in a compile error:

Error: no property `to` for type `int`, perhaps `import std.conv;` is needed?

Obviously I meant to call the function `too` in the same module. Not `std.conv.to`.

[1] https://github.com/dlang/dmd/blob/aef4ac2a0901e4f2bf6cefe4c69a9c4c22cce76d/src/dmd/imphint.d#L78

--
/Jacob Carlborg