I read an interesting article [0] with a weird title. It got me thinking about Ds marketing [1]. Are we too focused on the C++ programmers? Most of them are very unlikely to switch. In comparison, D should be much easier to sell to people, who are already considering Go/Scala/Clojure/Node.js/etc. I restructured [2] the tutorial to target them more specifically.

[0] http://braythwayt.com/2013/11/27/herd-thither-me-hither.html#revised
[1] https://news.ycombinator.com/item?id=6814922
[2] http://qznc.github.io/d-tut/basics.html

On Thu, Nov 28, 2013 at 09:27:03PM +0100, qznc wrote:
> I read an interesting article [0] with a weird title. It got me thinking about Ds marketing [1]. Are we too focused on the C++ programmers? Most of them are very unlikely to switch. In comparison, D should be much easier to sell to people, who are already considering Go/Scala/Clojure/Node.js/etc. I restructured [2] the tutorial to target them more specifically.
> 
> [0] http://braythwayt.com/2013/11/27/herd-thither-me-hither.html#revised
> [1] https://news.ycombinator.com/item?id=6814922
> [2] http://qznc.github.io/d-tut/basics.html

Under the section "For Go Programmers", the wording of the 2nd paragraph is a bit unfortunate:

	Why would you prefer D? D supports generic programming, which
	means less code and type safety. ...
	      ^^^^^^^^^^^^^^^^^^^^^^^^^

That could be misinterpreted to mean "less code and less type safety". (I know it sounds silly, but you never know... first impressions can mean a lot to a newcomer.) Maybe a better wording might be:

	"... less code and better type safety." ?


T

-- 
Любишь кататься - люби и саночки возить.

On Thursday, 28 November 2013 at 20:57:39 UTC, H. S. Teoh wrote:
> On Thu, Nov 28, 2013 at 09:27:03PM +0100, qznc wrote:
>> I read an interesting article [0] with a weird title. It got me
>> thinking about Ds marketing [1]. Are we too focused on the C++
>> programmers? Most of them are very unlikely to switch. In
>> comparison, D should be much easier to sell to people, who are
>> already considering Go/Scala/Clojure/Node.js/etc. I restructured [2]
>> the tutorial to target them more specifically.
>> 
>> [0] http://braythwayt.com/2013/11/27/herd-thither-me-hither.html#revised
>> [1] https://news.ycombinator.com/item?id=6814922
>> [2] http://qznc.github.io/d-tut/basics.html
>
> Under the section "For Go Programmers", the wording of the 2nd paragraph
> is a bit unfortunate:
>
> 	Why would you prefer D? D supports generic programming, which
> 	means less code and type safety. ...
> 	      ^^^^^^^^^^^^^^^^^^^^^^^^^
>
> That could be misinterpreted to mean "less code and less type safety".
> (I know it sounds silly, but you never know... first impressions can
> mean a lot to a newcomer.) Maybe a better wording might be:
>
> 	"... less code and better type safety." ?

I believe I had written "better" at some point, but was not happy with it.
How can type safety be "better"? Type safety is binary. A type cannot be 50% safe. I changed it to "more type safety", in the sense that you need less casts.  Short form of "more pervasive type safety". More suggestions welcome.

Thanks for the feedback :)

qznc:

> How can type safety be "better"? Type safety is binary. A type cannot be 50% safe.

You can have many different levels of type safety :-) While the D type system gives only a binary answer regarding the correctness of the types of a program, there are many different ways to write your D code, with various amounts of static typing.

Bye,
bearophile

On Thursday, 28 November 2013 at 22:36:59 UTC, qznc wrote:
> On Thursday, 28 November 2013 at 20:57:39 UTC, H. S. Teoh wrote:
>> On Thu, Nov 28, 2013 at 09:27:03PM +0100, qznc wrote:
>>> I read an interesting article [0] with a weird title. It got me

clip

>>
>> 	Why would you prefer D? D supports generic programming, which
>> 	means less code and type safety. ...
>> 	      ^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> That could be misinterpreted to mean "less code and less type safety".
>> (I know it sounds silly, but you never know... first impressions can
>> mean a lot to a newcomer.) Maybe a better wording might be:
>>
>> 	"... less code and better type safety." ?
>
> I believe I had written "better" at some point, but was not happy with it.
> How can type safety be "better"? Type safety is binary. A type cannot be 50% safe. I changed it to "more type safety", in the sense that you need less casts.  Short form of "more pervasive type safety". More suggestions welcome.
>
> Thanks for the feedback :)

perhaps try " ...generic programming, which gives you type safety with less code." or some variation on that.

On 2013-11-28 15:27, qznc wrote:
> I read an interesting article [0] with a weird title. It got me thinking
> about Ds marketing [1]. Are we too focused on the C++ programmers? Most
> of them are very unlikely to switch. In comparison, D should be much
> easier to sell to people, who are already considering
> Go/Scala/Clojure/Node.js/etc. I restructured [2] the tutorial to target
> them more specifically.
>
> [0] http://braythwayt.com/2013/11/27/herd-thither-me-hither.html#revised
> [1] https://news.ycombinator.com/item?id=6814922
> [2] http://qznc.github.io/d-tut/basics.html

I started reading seriously about D about 3 months ago so maybe I can comment a bit on this while my newcomer experience is fresh.

My background is PHP (turned away when searching for speed with benchmarks), I was reading about C++ since 6 months trying to develop a compiled application that has enough libraries to let me choose from. I ended up choosing Qt for my desktop app but I wanted type-genericity so I needed templates or tuples, and there was no way to make a templated QObject, I was a bit disappointed by that, and the lack of comprehensible errors in templated c++.

I found D multiple times when searching for C++ libraries, and when I decided to just "fuck it and read the unrelated stuff" got thrilled when I saw how well D has integrated tuples. It was a promising way to keep my old PHP ways while improving my abilities.

I think D seized me because it introduced the Ranges concept in a compiled language. Of course, I had to do some research about the libraries depending on what I needed, but as soon as I saw how easy D bindings to C libraries were it was obvious I'd find what I need. Also what helped were the tools like pegged, vibe.d, and knowing any application can just wrap around a C library and turn into something intuitive and fast thanks to the introspective capabilities of D.

So I would assume, from PHP to C++ to D, I wanted to see this within 20 seconds in this order:
1) Tuples, Ranges & Templates (with intuitive error examples)
2) C Bindings easily extended with D introspective wrappers (for quick metaprogramming support)
3) Open Networking / DB libraries with static compilation
4) GTKd, because you have to admit there's no other stable way of making a GUI

Maybe an example of signals and slots with associative arrays or tuples would be a quick example of most of the features in D, with a __traits static if / foreach loop.

Also, I wish I had learned about Dub, Mono-D & Visual-D sooner with an easier tutorial. Maybe an installer with Visual Integrated Shell and Visual-D combined would help newcomers, and instrudctions for Mono-D's handling of package.json files as project solutions. I had to try too many out-of-date or not-good-yet tools.

Hope it helps, this is also my first post on these forums ;)

Etienne

On 2013-12-02 08:12, Etienne wrote:
> On 2013-11-28 15:27, qznc wrote:
>> I read an interesting article [0] with a weird title. It got me thinking
>> about Ds marketing [1]. Are we too focused on the C++ programmers? Most
>> of them are very unlikely to switch. In comparison, D should be much
>> easier to sell to people, who are already considering
>> Go/Scala/Clojure/Node.js/etc. I restructured [2] the tutorial to target
>> them more specifically.
>>
>> [0] http://braythwayt.com/2013/11/27/herd-thither-me-hither.html#revised
>> [1] https://news.ycombinator.com/item?id=6814922
>> [2] http://qznc.github.io/d-tut/basics.html
>
> I started reading seriously about D about 3 months ago so maybe I can
> comment a bit on this while my newcomer experience is fresh.
>
> My background is PHP (turned away when searching for speed with
> benchmarks), I was reading about C++ since 6 months trying to develop a
> compiled application that has enough libraries to let me choose from. I
> ended up choosing Qt for my desktop app but I wanted type-genericity so
> I needed templates or tuples, and there was no way to make a templated
> QObject, I was a bit disappointed by that, and the lack of
> comprehensible errors in templated c++.
>
> I found D multiple times when searching for C++ libraries, and when I
> decided to just "fuck it and read the unrelated stuff" got thrilled when
> I saw how well D has integrated tuples. It was a promising way to keep
> my old PHP ways while improving my abilities.
>
> I think D seized me because it introduced the Ranges concept in a
> compiled language. Of course, I had to do some research about the
> libraries depending on what I needed, but as soon as I saw how easy D
> bindings to C libraries were it was obvious I'd find what I need. Also
> what helped were the tools like pegged, vibe.d, and knowing any
> application can just wrap around a C library and turn into something
> intuitive and fast thanks to the introspective capabilities of D.
>
> So I would assume, from PHP to C++ to D, I wanted to see this within 20
> seconds in this order:
> 1) Tuples, Ranges & Templates (with intuitive error examples)
> 2) C Bindings easily extended with D introspective wrappers (for quick
> metaprogramming support)
> 3) Open Networking / DB libraries with static compilation
> 4) GTKd, because you have to admit there's no other stable way of making
> a GUI
>
> Maybe an example of signals and slots with associative arrays or tuples
> would be a quick example of most of the features in D, with a __traits
> static if / foreach loop.
>
> Also, I wish I had learned about Dub, Mono-D & Visual-D sooner with an
> easier tutorial. Maybe an installer with Visual Integrated Shell and
> Visual-D combined would help newcomers, and instrudctions for Mono-D's
> handling of package.json files as project solutions. I had to try too
> many out-of-date or not-good-yet tools.
>
> Hope it helps, this is also my first post on these forums ;)
>
> Etienne


Also, you should include a dmd-d (debug build) in the installer. You'd be surprised how it can save time with ICE errors to have it handy, it would be useful to suggest using it within these ICE error reports. I'm sure everyone in the D community was puzzled by an internal compiler error at least once and found there was a simple easy to fix bug in their code behind it.