www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Filling out the wiki - D as a second language

reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
http://wiki.dlang.org/Coming_From

These sections are empty/close to empty:



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.
Mar 29 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/29/15 4:21 PM, Laeeth Isharc wrote:
 http://wiki.dlang.org/Coming_From

 These sections are empty/close to empty:



 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
Mar 30 2015
parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 31 2015
next sibling parent reply "Baz" <bb.temp gmx.com> writes:
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.
Mar 31 2015
parent "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
 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.
Mar 31 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
 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.
Mar 31 2015
parent Jacob Carlborg <doob me.com> writes:
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
Mar 31 2015
prev sibling parent reply "rumbu" <rumbu rumbu.ro> writes:
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:



 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.
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.
Mar 31 2015
next sibling parent "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
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:



 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.
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.
Mar 31 2015
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote:

 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.
Apr 01 2015
prev sibling next sibling parent reply "Freddy" <Hexagonalstar64 gmail.com> writes:
On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote:
 Unfortunately, I cannot edit directly on wiki.dlang.org since 
 my account is not confirmed (confirmation e-mail is not sent 
 despite several attempts).
By any chance, do you use gmail? The email sent by the wiki appeared in my gmail's spam.
Apr 02 2015
parent "rumbu" <rumbu rumbu.ro> writes:
On Friday, 3 April 2015 at 01:59:15 UTC, Freddy wrote:
 On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote:
 Unfortunately, I cannot edit directly on wiki.dlang.org since 
 my account is not confirmed (confirmation e-mail is not sent 
 despite several attempts).
By any chance, do you use gmail? The email sent by the wiki appeared in my gmail's spam.
Yes, I use gmail, but the domain name is the same as my current username here. I requested again to send confirmation e-mail, no success so far.
Apr 02 2015
prev sibling parent "Orfeo" <orfeo.davia gmail.com> writes:
On Tuesday, 31 March 2015 at 22:25:29 UTC, rumbu wrote:

 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).
Thank you for your great contribution, I started porting from github to wiki here http://wiki.dlang.org/Programming_in_D_for_CSharp_Programmers
Apr 16 2015