🚀 go-pugleaf

これがレスです。

# なんかへんだな。
# やっぱりさっきレス込みで投稿すべきだったか。

# それからこいつの元記事ですが敬称を略していました。
# とても失礼な事です。
# Kasugai @ 窓の TAPI & ATcommand 屋 さんごめんなさい。

Kasugai @ 窓の TAPI & ATcommand 屋 wrote
>>その意味で勉強するなら（どのチップ用でも良いから）アセンブラを薦めます。
>
>ここは、反対！！
>
>  プログラミングやアルゴリズムの勉強をする*だけ*なら、
>アセンブラで良いでしょう。

付け加えて「コンピュータの動き」ですか。
一応、そういう意味で書いたつもりです。

まず何を置いてもコンピュータの動作を頭に叩き込んで
おくべきだと思っています。
それが分かっていれば手続き型言語は全て理解可能だと
確信しております。

アセンブラの机上デバッグって自分がチップになりきらないと
できないでしょ。
だから自然とアーキテクチャの概念が身につくかと・・・。

# 甘いかな？

>ユーザー（or メンテする人）に対するプレゼンの勉強も含めた意味で、
>
>「日本語箇条書きによる擬似プログラミング」
>
>の方が有効だと思います。


カーニハンも（「プログラム書法」か「ソフトウェア作法」で）言ってましたね。
あれは、わかりやすいアルゴリズムの話だけど。

# 私的には疑似コードプログラミングって好きじゃないんです。
# つい、「自分で考えた言語」でコーディングしちゃって・・・。
# そのままコメントに使えるような疑似コードなら歓迎なんですが。

「伝えるべき事を」、「簡潔に」、「わかりやすく」、「曖昧にならずに」伝える
訓練にはなるでしょう。
でも、会議とか研修と言った人間の集まりでしか養われない能力もあるんで
あまり、書類での訓練は過信しすぎないほうがよろしいかと思います。

# Kasugai @ 窓の TAPI & ATcommand 屋さんが過信してない事は分かってます。

書類書きの訓練という意味では仕様書を書く時に役立つかもしれないな。
それとやっぱりコメント

# 私、実はコメント下手なんです。
# 趣味で書いたプログラムにはファイルヘッダと関数ヘッダ以外に
# コメント書かないし。
# 仕事でも他人の書いたコメントってまず信用してないし。
# その代わり変数名は長いよ。
# ワークのループカウンタでもrecordCount,itemCountだもん。
# sharedMemoryTableCoutnerByByteってのには負けたけど<-実話。

>#  でも、最初からは止めておいた方が・・・・。
>##  特にSparcは・・・・。シーケンシャルに追いかけられないので
>##  ほぼ確実に混乱するでしょう・・・・。（慣れれば平気(^^;;）


ははは・・・。
RISCのアセンブラは止めたほうがいいですね。
ごめんなさい。
「チップは何でもいい」はウソです。

では。

中山豊実@SoftwareSmith

toysmith @ mail.interq.or.jp <-ここから出しています。
toysmith @ coo.net           <-メールはこっちへお願いします。
　　　　　　　　　　　　　　　　　　　容量でかいっす