On Monday, 26 June 2017 at 12:59:56 UTC, bachmeier wrote:
> On Monday, 26 June 2017 at 11:09:47 UTC, Mike Parker wrote:
>> On Monday, 26 June 2017 at 10:13:13 UTC, bachmeier wrote:
>>
>>> Now we have one, and by my count, the number of posts from Walter and Andrei are zero.
>>
>> Actually, they have one each: Walter's "Snowflake Strings" [1] and Andrei's "Introspection, Introspection Everywhere" [2]
>>
>> There are more in the pipeline, so we'll hear from them again a little ways down the road.
>>
>> https://dlang.org/blog/2017/02/22/snowflake-strings/
>> https://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/
>
> Sorry, I was a bit sloppy. I meant posts from the perspective of leaders saying "this is the plan going forward". These are more of what I would consider technical posts rather than big picture plans for the future posts.

They publish a high-level vision every six months (e.g. https://wiki.dlang.org/Vision/2017H1) -maybe we should shoot out a short blog post about it in the future, so that it receives more publicity?

On Monday, 26 June 2017 at 16:14:32 UTC, Seb wrote:

> They publish a high-level vision every six months (e.g. https://wiki.dlang.org/Vision/2017H1) -maybe we should shoot out a short blog post about it in the future, so that it receives more publicity?

As I recall, the hope was for communication more often than every six months, and with more detail. Personally, I don't know if it would help. They're not involved with much outside of the language itself, and for the most part, the language is not D's problem.

On Monday, 26 June 2017 at 17:15:50 UTC, bachmeier wrote:
> On Monday, 26 June 2017 at 16:14:32 UTC, Seb wrote:
>
>> They publish a high-level vision every six months (e.g. https://wiki.dlang.org/Vision/2017H1) -maybe we should shoot out a short blog post about it in the future, so that it receives more publicity?
>
> As I recall, the hope was for communication more often than every six months, and with more detail. Personally, I don't know if it would help. They're not involved with much outside of the language itself, and for the most part, the language is not D's problem.

My sense is that communication is moving in the right direction. Not everything needs to come from Walter and Andrei.

I agree that a blog post on the next Vision document would be reasonable.

On Thursday, 22 June 2017 at 19:19:20 UTC, Ecstatic Coder wrote:
> class TOTO
>
>...I think that trying to
> make the website very appealing to inexperienced programmers as well could significantly broaden its user base.

Although I am admittedly an LOB kind of person who cares little for games or gamification, I do see the benefit of using "fun" use-case examples, like a tic-tac-toe game, or a soda machine simulation.  Such recognizable zero-overhead/zero-noise metaphors simplify the tasks of understanding a program and learning its language.

By contrast, being asked to decipher a mysterious and unintuitive program like the fatuous tutu example would leave me resenting the distraction and cognitive overhead.  Dammit Jim, I'm a programmer, not a damned word puzzle competitor!

But that's just me!

So... instead of showcasing just one or another program type on the website's landing page, why not provide a tabbed dialog or menu that lets users select the kind of program that most interests them, e.g., LOB, web, games, STEM, etc.  This would avoid alienating those readers who believe that effective technical and instructional communication require the maximization of signal-to-noise ratio ABOVE ALL ELSE.

Some other ideas for introductory illustrative examples for the website would be to include for each program:

1) A description of the program's function so readers know what to look for.
2) The expected output.
3) A walk-through, when needed.
4) The same program in other languages, with call-outs to identify the unique features and benefits of Dlang.

On Tuesday, 27 June 2017 at 01:53:20 UTC, dlangPupil wrote:
> On Thursday, 22 June 2017 at 19:19:20 UTC, Ecstatic Coder wrote:
>> class TOTO
>>
>>...I think that trying to
>> make the website very appealing to inexperienced programmers as well could significantly broaden its user base.
>
> Although I am admittedly an LOB kind of person who cares little for games or gamification, I do see the benefit of using "fun" use-case examples, like a tic-tac-toe game, or a soda machine simulation.  Such recognizable zero-overhead/zero-noise metaphors simplify the tasks of understanding a program and learning its language.
>
> By contrast, being asked to decipher a mysterious and unintuitive program like the fatuous tutu example would leave me resenting the distraction and cognitive overhead.  Dammit Jim, I'm a programmer, not a damned word puzzle competitor!
>
> But that's just me!
>
> So... instead of showcasing just one or another program type on the website's landing page, why not provide a tabbed dialog or menu that lets users select the kind of program that most interests them, e.g., LOB, web, games, STEM, etc.  This would avoid alienating those readers who believe that effective technical and instructional communication require the maximization of signal-to-noise ratio ABOVE ALL ELSE.
>
> Some other ideas for introductory illustrative examples for the website would be to include for each program:
>
> 1) A description of the program's function so readers know what to look for.
> 2) The expected output.
> 3) A walk-through, when needed.
> 4) The same program in other languages, with call-outs to identify the unique features and benefits of Dlang.

I agree with you.

Let me first say that the tutu code was there just to illustrate to show which features should be shown in examples. Simple D features, not complicated ones.

D code is easy to make and read.

That is what people should know about the D language.

I'm in favor of bein able to select an example among a list on the left side of the screen, and on the right side the example appears with an explanation below.

The default example is the classic hello word, then we show how to declare and use integers, strings, arrays, maps, then how to declare classes, then we have interesting "use-case" examples : process a text file line by line, using regular expressions, guess-a-number game, sort lines in alphabetical order, etc.

Kotlin uses a quite similar approach if I remember well.

> The default example is the classic hello word, then we show how to declare and use integers, strings, arrays, maps, then how to declare classes, then we have interesting "use-case" examples : process a text file line by line, using regular expressions, guess-a-number game, sort lines in alphabetical order, etc.

Within the next few months I'll try to find some free time to write all these examples and put them in a D_TUTORIAL project on my senselogic github account.

The ui/game examples will be based on a small Nuklear-inspired std.ui library, and the web examples based on a small Vibe-inspired std.web library.

I guess that as usual this will remain unused, but that doesn't matter actually, as they will be useful to my kids as a reference examples for their personal use, which is already fine by me.

Am 25.06.2017 um 01:12 schrieb Timon Gehr:
> On 25.06.2017 01:09, Adam D. Ruppe wrote:
>> On Saturday, 24 June 2017 at 23:00:59 UTC, Timon Gehr wrote:
>>> Failed to listen on :::80
>>
>> Listening on port 80 requires root anyway. That's why like my cgi.d uses 8085 - anything over 1024 can be listened by any user (and is less likely to have an existing program on it)
>>
> 
> Thanks! I guessed as much, but I don't have a setup where root can build the code. (And I don't see why it should.)

Usually I'd use 8080 for examples, but the original example used port 80, so I just followed along. HTTPServerSettings has a .port field that can be used to change the default.