On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:
> However, my stance at the moment is that the intro examples should just be really short. The message is that you can do something useful or cool in just a couple lines of code. That means outright rejection of anything longer than, say, 20 lines, or maybe even just 15.

Understand. But IMO the main objective should be to demonstrate expressiveness and productivity to newcomers, and therefore it is crucial that the examples are understandable in its entirety by every newbie. Someone unfamiliar to D's UFCS and template instantiation syntax are likely unable to parse these examples in their heads without explanatory comments. Without the comments this example reduces to an incomprehensible blob of code without structure (in the eyes of a first-time visitor, who may not have a degree in CS) and is likely to repel instead of attract. This looks pretty frightening if the objective is just to round floating point numbers (as explained by the only remaining comment) -- of course we know that this does a lot more, but a newbie doesn't.

A competition for writing the most concise code does not necessarily produce the most illustrative introductions into a language.

Bastiaan.

On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:
> Yeah, I also stripped some of its functionality (processing args instead of stdin),

I sometimes use this box to quickly test something. Although I have never had a use for args, I might in the future. I found it was nice to see that it could do that.

On Wednesday, 6 January 2016 at 11:35:12 UTC, anonymous wrote:
> Also check out http://d-ag0aep6g.rhcloud.com/ where I'm currently working on the implementation. It's a little different from the mockup, precisely because I'm trying not to drop features/content.

So I meditated and came to conclusion that there is too much text and I didnt find any way of laying it in this new design that would be a nice sales pitch. D is big (thats what she said) and there is a lots to talk about, but people want TL;DR version.

On the other hand changing "why D" section requires more work and we lack spare hands.

in http://d-ag0aep6g.rhcloud.com/

comunity, learn, documentation and packages are redundant. They either should be in meniu or not on front page. And if there are redundant links they should be in footer.

Now documentation.

anonymous:http://d-ag0aep6g.rhcloud.com/phobos/std_algorithm_iteration.html

Me playing around: https://drive.google.com/file/d/0B6ofJyypw1tGa29aTGNVQVJQcVk/view?usp=sharing

Open them both and just look at them for 10 sec. Dont scroll because I put 0 work after License:. Just look at them and write which one has bigger strain on you eyes.

IMHO everyone who is working on improving website should get on skype or hangouts and make a plan. Now Ivan made new design for documentation, anonymous also put some work, Adam is cooking something up. I smell lots of redundant work ahead

On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:
> However, my stance at the moment is that the intro examples should just be really short. The message is that you can do something useful or cool in just a couple lines of code. That means outright rejection of anything longer than, say, 20 lines, or maybe even just 15.

Or put longer examples behind "Learn more" button.

On Thursday, 7 January 2016 at 08:16:45 UTC, Yazan D wrote:
> On Thu, 07 Jan 2016 02:46:30 +0000, welkam wrote:
>
>> How left one is more readable than right? http://i.imgur.com/7KiehRI.png
>
> Tip: you can use Jade syntax highlighting for diet templates.

http://i.imgur.com/oaUkjGe.png am I doing something wrong?

For straight html I dont need to do anything and with auto complete there is no pain in writing html.

People arguing with me probably dont understand why iPhone became so popular also.

On 2016-01-07 16:33, welkam wrote:

> in http://d-ag0aep6g.rhcloud.com/

I noticed that the buttons for the example cover the drop down menu for Resources, if it's open.

-- 
/Jacob Carlborg

On 07.01.2016 16:33, welkam wrote:
> in http://d-ag0aep6g.rhcloud.com/
>
> comunity, learn, documentation and packages are redundant. They either
> should be in meniu or not on front page. And if there are redundant
> links they should be in footer.

I'm not sure if redundancy is to be avoided here. I think the redesign took a lot of inspiration from <http://ocaml.org> which has the same preview snippets of the different site sections. Personally I could do without them, and I wouldn't mind if we decide against them, but a little tour around the site and direct links to the interesting parts may help people find what they're looking for.

> Now documentation.
>
> anonymous:http://d-ag0aep6g.rhcloud.com/phobos/std_algorithm_iteration.html
>
> Me playing around:
> https://drive.google.com/file/d/0B6ofJyypw1tGa29aTGNVQVJQcVk/view?usp=sharing
>
>
> Open them both and just look at them for 10 sec. Dont scroll because I
> put 0 work after License:. Just look at them and write which one has
> bigger strain on you eyes.

I'm not sure what you want me to notice. Differences I see:

* different shade of red throughout,
* heading is red,
* no "Jump to" links,
* links are not underlined,
* less horizontal lines on the table.

Regarding the specific shade of red: I don't really care about any exact colors. I'm not usually doing visual design, and my monitor is not properly calibrated.

Re the red heading: I'm against coloring unclickable stuff the same as clickable stuff. I'm guilty of doing this with the signature boxes: the red border on the left and the documented symbol are red but not clickable. I took that from the mockup, but I don't like it. If the point of the red heading is to lessen the contrast, I'd suggest a color other than red, maybe just some grey that's less dark than #333.

Re link underlines: I made a pull request for un-underlined links before. The argument that made me abandon the idea was that it makes things harder for color blind people. Note that already links are not underlined in navigation areas where it's supposedly obvious that they're clickable.

Re the jump links: I'm not sure if this is a deliberate change of yours, or maybe it's just a problem with the JS. If it's deliberate, the paragraph below applies.

Re the table lines: I didn't touch those. They're the same in my version as on the current dlang.org. Generally, I'd like to leave improvements that are independent of the redesign out of it.

If I'm missing anything you'll have to spell it out for me.

> IMHO everyone who is working on improving website should get on skype or
> hangouts and make a plan. Now Ivan made new design for documentation,
> anonymous also put some work, Adam is cooking something up. I smell lots
> of redundant work ahead

Aside from general visuals, I'm deliberately leaving Ivan's ideas for the phobos docs out for now. Exactly because there's some turmoil in the area. And because I want to wrap this up sometime soon. I think Adam's work is pretty much independent from mine here.

On 07.01.2016 16:55, Jacob Carlborg wrote:
> I noticed that the buttons for the example cover the drop down menu for
> Resources, if it's open.

Fixed, thanks.

I am not sure.. But you can install this for jade syntax highlighting (https://packagecontrol.io/packages/Jade)

On 07.01.2016 12:36, Bastiaan Veelo wrote:
> Understand. But IMO the main objective should be to demonstrate
> expressiveness and productivity to newcomers, and therefore it is
> crucial that the examples are understandable in its entirety by every
> newbie. Someone unfamiliar to D's UFCS and template instantiation syntax
> are likely unable to parse these examples in their heads without
> explanatory comments. Without the comments this example reduces to an
> incomprehensible blob of code without structure (in the eyes of a
> first-time visitor, who may not have a degree in CS) and is likely to
> repel instead of attract.

I don't agree that examples need to be fully understandable to newbies. We'd have to explain every single line. Rather, I think the examples should answer the question "How familiar or outlandish will D be for me?"

That said, I'm not against comments, and I may have gone overboard when cutting that example down. But I still think it's too long with all comments intact.

> This looks pretty frightening if the objective
> is just to round floating point numbers (as explained by the only
> remaining comment) -- of course we know that this does a lot more, but a
> newbie doesn't.

Maybe the example should focus on command line arguments instead of stdin. No "replace anything that looks like a number", which is hard to match properly anyway, but instead just assume numbers in args. No regex necessary, just a `.map!(arg => arg.to!real.round.to!string)`.

Unfortunately, it looks like the handling of command line args is broken on dpaste: https://issues.dlang.org/show_bug.cgi?id=15050

> A competition for writing the most concise code does not necessarily
> produce the most illustrative introductions into a language.

It's not a competition to write the shortest, but a competition to come up with something that's short enough. While being short it should actually be properly formatted, idiomatic D code.