Re: Haxe Digest, Vol 52, Issue 21

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Haxe Digest, Vol 52, Issue 21

James W. Hofmann
Quoting [hidden email]:

> Message: 2
> Date: Thu, 04 Feb 2010 15:15:12 +0000
> From: Lee McColl Sylvester <[hidden email]>
> Subject: Re: [haXe] How to destroy an open source project community
> To: [hidden email]
> Cc: [hidden email]
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> So, my feelings, therefore, are that you need to understand the
> relationships before tackling the implementation. I had the same issues
> when learning C/C++ all those years ago and not fully understanding
> pointers. It was, therefore, quite counter-productive using them until I
> had this knowledge not just onboard, but fully disected, analysed and
> understood on a per-chip / memory stack -esque basis.
>
> Best,
> Lee

A general formula that I've turned towards for writing my own  
documentation recently is address each feature in two parts:  
"concepts" and "ceremony." The first is the "how do these things  
relate" high-level guide, including the detailed pitfalls, and the  
second is the "how do I do... what is the command for... what does  
this error mean..." type of FAQ/guided-tutorial docs.

Just a suggestion of how we might try to go forward with the haXe  
documentation process. haXe coders have to implicitly understand the  
concepts of the target platforms as well as the language so it is  
harder to reason about than a typical language/runtime combo or  
user-facing application.

James

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Haxe Digest, Vol 52, Issue 21

jlm@justinfront.net
James do you have a link online to your documentation?

Cheers

;j

On 4 Feb 2010, at 19:19, James Hofmann wrote:

> Quoting [hidden email]:
>
>> Message: 2
>> Date: Thu, 04 Feb 2010 15:15:12 +0000
>> From: Lee McColl Sylvester <[hidden email]>
>> Subject: Re: [haXe] How to destroy an open source project community
>> To: [hidden email]
>> Cc: [hidden email]
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> So, my feelings, therefore, are that you need to understand the
>> relationships before tackling the implementation. I had the same  
>> issues
>> when learning C/C++ all those years ago and not fully understanding
>> pointers. It was, therefore, quite counter-productive using them  
>> until I
>> had this knowledge not just onboard, but fully disected, analysed and
>> understood on a per-chip / memory stack -esque basis.
>>
>> Best,
>> Lee
>
> A general formula that I've turned towards for writing my own  
> documentation recently is address each feature in two parts:  
> "concepts" and "ceremony." The first is the "how do these things  
> relate" high-level guide, including the detailed pitfalls, and the  
> second is the "how do I do... what is the command for... what does  
> this error mean..." type of FAQ/guided-tutorial docs.
>
> Just a suggestion of how we might try to go forward with the haXe  
> documentation process. haXe coders have to implicitly understand the  
> concepts of the target platforms as well as the language so it is  
> harder to reason about than a typical language/runtime combo or user-
> facing application.
>
> James
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
haXe - an open source web programming language
http://haxe.org