http://wiki.dlang.org/Coming_From

These sections are empty/close to empty:

Ruby / Java / Eiffel / C# / and Basic

I made a small start on the Python section.  It needs more concrete side-by-side examples of translating Python idioms into D, but that is all I can do for now.

On 3/29/15 4:21 PM, Laeeth Isharc wrote:
> http://wiki.dlang.org/Coming_From
>
> These sections are empty/close to empty:
>
> Ruby / Java / Eiffel / C# / and Basic
>
> I made a small start on the Python section.  It needs more concrete
> side-by-side examples of translating Python idioms into D, but that is
> all I can do for now.

Thanks for this initiative. It would be indeed awesome if this got a bit more attention. Once we get the portal fleshed out, we can promote the link to the homepage.

One note about Walter's older C/C++ transition articles. They have good information on transition technicalities (e.g. "how do I do this thing in D that I used to do in C++?") but not a lot about the changes in coding style - making object copying not arbitrarily expensive, choosing struct vs. class, preferring pipelines and lazy to eager computation, etc. From what I see some folks come from C++, write their first D program in a stilted C++ idiom, and are left with the impression that the work is not worth the trouble.


Andrei

On 2015-03-31 04:18, Andrei Alexandrescu wrote:

> Thanks for this initiative. It would be indeed awesome if this got a bit
> more attention. Once we get the portal fleshed out, we can promote the
> link to the homepage.
>
> One note about Walter's older C/C++ transition articles. They have good
> information on transition technicalities (e.g. "how do I do this thing
> in D that I used to do in C++?") but not a lot about the changes in
> coding style - making object copying not arbitrarily expensive, choosing
> struct vs. class, preferring pipelines and lazy to eager computation,
> etc. From what I see some folks come from C++, write their first D
> program in a stilted C++ idiom, and are left with the impression that
> the work is not worth the trouble.

I could add something for Ruby but I'm not really sure what to add. The the content for the existing languages is quite different compared with each other.

-- 
/Jacob Carlborg

On Tuesday, 31 March 2015 at 08:36:00 UTC, Jacob Carlborg wrote:
> On 2015-03-31 04:18, Andrei Alexandrescu wrote:
>
>> Thanks for this initiative. It would be indeed awesome if this got a bit
>> more attention. Once we get the portal fleshed out, we can promote the
>> link to the homepage.
>>
>> One note about Walter's older C/C++ transition articles. They have good
>> information on transition technicalities (e.g. "how do I do this thing
>> in D that I used to do in C++?") but not a lot about the changes in
>> coding style - making object copying not arbitrarily expensive, choosing
>> struct vs. class, preferring pipelines and lazy to eager computation,
>> etc. From what I see some folks come from C++, write their first D
>> program in a stilted C++ idiom, and are left with the impression that
>> the work is not worth the trouble.
>
> I could add something for Ruby but I'm not really sure what to add. The the content for the existing languages is quite different compared with each other.

This is a wiki, so do it the way you want.

Personnaly for the Delphi/Pascal section i haven't followed any previous model (except for the `pascal way` or the D way`) but i've rather choosen to focus on ambiguities and similarities...

Just do it and if someone comes with a better solution he can delete everything. It'a wiki.

> I could add something for Ruby but I'm not really sure what to add. The the content for the existing languages is quite different compared with each other.

Often one doesn't know what one wants to write till one starts.  I guess the focus will be different coming from Ruby than coming from Basic, because people think in different ways and tend to be solving different sorts of problems - so I should think there is no need to strive for uniformity at this stage.  Just making a start is a big improvement on a blank page - it doesn't need to be excellent on day one.

Maybe just try to remember what you struggled with (or would struggle with) when learning D as a Ruby guy.  What are the cool futures in Ruby that you can do, or do better in D?  What are the traps and 'faux amis' (things in D that don't do what one might think if coming from a Ruby background)?

Go has not just a wiki entry, but a whole book on "Go for Python programmers".  D is different from Go, but maybe we should make the whole experience for newcomers just a little bit easier.

> Personnaly for the Delphi/Pascal section i haven't followed any previous model (except for the `pascal way` or the D way`) but i've rather choosen to focus on ambiguities and similarities...

BTW - respect for doing this.  Will try to learn from what you have done.

When these pages are mature, maybe they should be linked from the front page sidebar.

Laeeth.

On 2015-03-31 12:48, Laeeth Isharc wrote:

> Often one doesn't know what one wants to write till one starts. I guess
> the focus will be different coming from Ruby than coming from Basic,
> because people think in different ways and tend to be solving different
> sorts of problems - so I should think there is no need to strive for
> uniformity at this stage.  Just making a start is a big improvement on a
> blank page - it doesn't need to be excellent on day one.
>
> Maybe just try to remember what you struggled with (or would struggle
> with) when learning D as a Ruby guy.  What are the cool futures in Ruby
> that you can do, or do better in D?  What are the traps and 'faux amis'
> (things in D that don't do what one might think if coming from a Ruby
> background)?
>
> Go has not just a wiki entry, but a whole book on "Go for Python
> programmers".  D is different from Go, but maybe we should make the
> whole experience for newcomers just a little bit easier.

I was more think of what level to write, i.e. something like "this is how you write a class in D" or "this is how you join an array in D". Or more advanced topics like "this is how you do method_missing in D" or reflection.

-- 
/Jacob Carlborg

On Sunday, 29 March 2015 at 23:21:20 UTC, Laeeth Isharc wrote:
> http://wiki.dlang.org/Coming_From
>
> These sections are empty/close to empty:
>
> Ruby / Java / Eiffel / C# / and Basic
>
> I made a small start on the Python section.  It needs more concrete side-by-side examples of translating Python idioms into D, but that is all I can do for now.

I started some C# to D stuff here: https://github.com/rumbu13/sharp/blob/master/cstod.md

Unfortunately, I cannot edit directly on wiki.dlang.org since my account is not confirmed (confirmation e-mail is not sent despite several attempts).

Anyway, I'm already asking for help from experienced D users to translate the following concepts in D:

- decimal type
- dynamic types
- volatile
- boxing/unboxing
- multicast delegates
- events
- yield return
- P/Invoke
- async/await
- linq
- runtime reflection
- serialization
- inlining
- weak references
- implicit casting overload
- COM imports
- templated functions override

I'm not asking for solutions (because I know how to implement them in D), I'm asking for guidance about the best D semantics to be used instead.

On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote:
> On Sunday, 29 March 2015 at 23:21:20 UTC, Laeeth Isharc wrote:
>> http://wiki.dlang.org/Coming_From
>>
>> These sections are empty/close to empty:
>>
>> Ruby / Java / Eiffel / C# / and Basic
>>
>> I made a small start on the Python section.  It needs more concrete side-by-side examples of translating Python idioms into D, but that is all I can do for now.
>
> I started some C# to D stuff here: https://github.com/rumbu13/sharp/blob/master/cstod.md
>
> Unfortunately, I cannot edit directly on wiki.dlang.org since my account is not confirmed (confirmation e-mail is not sent despite several attempts).

Great - let me know if you want me to add something when ready.  There must be a markup to wiki converter somewhere.


> Anyway, I'm already asking for help from experienced D users to translate the following concepts in D:
>
> I'm not asking for solutions (because I know how to implement them in D), I'm asking for guidance about the best D semantics to be used instead.

I will let someone else who knows better help.

On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote:
> I started some C# to D stuff here: https://github.com/rumbu13/sharp/blob/master/cstod.md

Forgot semicolon in hello world example.

> Anyway, I'm already asking for help from experienced D users to translate the following concepts in D:
>
> - decimal type
I heard, there was an implementation of a scaled integer and a rational type.
> - dynamic types
No exact equivalent, opDispatch is similar, but is compile-time.
> - volatile
atomicLoad, atomicStore
> - boxing/unboxing
Variant
> - multicast delegates
> - events
std.signals (needs rewrite)
> - yield return
input/output ranges
> - P/Invoke
Not really needed for native languages, because they interface with the platform directly. Well, there are utilities like tempCString.
> - async/await
vibe addresses the same problem http://code.dlang.org/packages/vibe-d
> - linq
std.algorithm, std.range, std.array
> - runtime reflection
Nothing builtin, D relies more on compile-time reflection.
> - serialization
http://wiki.dlang.org/Libraries_and_Frameworks#Serialization
> - inlining
only http://wiki.dlang.org/DIP56
> - weak references
To be implemented in druntime
> - implicit casting overload
Not supported deliberately, as I understand it
> - COM imports
There was some attempt at COM integration, not sure how far it has gone. AFAIK, COM can expose interface as IDispatch, that would save one from parsing the type library manually.
> - templated functions override
Done by redirecting templated function to non-templated one.
> I'm not asking for solutions (because I know how to implement them in D), I'm asking for guidance about the best D semantics to be used instead.
Do things at compile time, allocate as little as possible, in other words, be efficient.