  |
はてなキーワード:Mozartとは
Frankfurt Radio SymphonyLive: John Storgårds & Martin Helmchen withBach/Webern,Mozart &Bruckner
https://www.youtube.com/watch?v=w4L1FGyiFVQ
2024/05/25 に公開予定
Johann Sebastian Bach/Anton Webern:
Ricercar a 6
Klavierkonzert D-Dur KV 451
AntonBruckner:
6. Sinfonie
hr-Sinfonieorchester – Frankfurt Radio Symphony
Martin Helmchen, Klavier
John Storgårds, Dirigent
Alte Oper Frankfurt,24.Mai 2024
John Storgårds und Martin Helmchen zu Gast beimhr-Sinfonieorchestermit einer bekanntenBach-Bearbeitung Anton Weberns, einem eher wenig beachteten,mit feinsinnigen Überraschungen aufwartendenMozart-Klavierkonzert undBruckners ebenfalls nicht eben häufig zu hörender 6. Sinfonie.
____________________________
John Storgårds and Martin Helmchen are guests of the Frankfurt Radio Symphony with a well-knownBach arrangementby Anton Webern, apiano concertobyMozart thathas receivedlittle attention but offers subtle surprises, andBruckner's Symphony No. 6, whichis also not often heard.
SUPERMARIOTHEME, in the Styles of 6 Classical Composers
https://www.youtube.com/watch?v=O0FsrzxElrE
➡ Thankyou for supporting meon Patreon!https://www.patreon.com/nahresol
➡Elements ofMusicBOOK:https://www.nahresol.com/elementsofmusic
➡ Sheetmusic formusic from my videos:https://www.nahresol.com/shop
Timestamps:
00:00OriginalThemebyNintendo (Koji Kondo)
00:31 In the style of J.S.Bach
01:00 In the style ofMozart
01:31 In the style ofBeethoven
01:55 In the style of Liszt
02:23 In the style of Rachmaninoff
03:05 In the style of Gershwin
Note: I played slightly differentchromaticnotes and rhythms than inthe originalversion when I play themaintheme.
Instagram @nahresol
Twitter @nahresol
https://www.youtube.com/watch?v=ckZBkz_XC6E
Peter Eötvös : Concerto pour harpe
以下概要欄
Cette oeuvre (création mondiale)estune commande deRadioFrance - Rundfunkorchesterund ChöreGmbH Berlin - Orchestre dela Suisse Romande - Musikverein de Vienne -Casada Música de Porto - Orchestre Symphonique delaNHK deTokyo, dédiéeau harpiste Xavier deMaistre.
Seven,premier concerto pour violon, rendait hommageaux cosmonautes dela navetteColumbia ; DoReMi,le deuxième, étaitun retour à l’enfanceetauxpremiers apprentissagesmusicaux ; Alhambra,le troisième,unepromenade architecturale en compagnie deses interprètes : chaque concerto de Peter Eötvös possède son mondepropre. Certains titres annoncentune réinvention dudialogue entrelesolisteet l’orchestre : Replica pour alto,le bartokienCAP-KO, acronyme de Concerto for AcousticPiano,Keyboard and Orchestra,Focus poursaxophone suggérant l’usage d’unecaméra sonoreetune miseaupoint entredifférents plans. De fait,legenreest appropriéaux plus folles explorationsdanslethéâtre instrumental. C’estainsi quelapièce de jeunesse Kosmos a 9 offert àun cymbalum très hongrois de jouerun nouveau rôle en compagnie de l’orchestredans Psychokosmos. En 2023,le compositeur renoue avec l’essence même dugenre enproposant à Xavier deMaistreunsimple Concerto pour harpe.
En trois mouvements vif-lent-vif, ce concerto s’inscriraitdansle schémale plus classique,siseulementla harpe bénéficiait d’un répertoire symphoniqueaussi riche quelesautres instrumentssolistes.Si Haendel lui a offert quelquespages,Mozart asentile besoin de lui adjoindrelaflûte pour l’associer à l’orchestre.Etles effortsdes Krumpholz, Boieldieu,Piernéet Glière n’y ont rien changé :les concertos pour harpe ontleprivilège delarareté. « Allegro e felice », indique Péter Eötvös en tête dupremier mouvement.Seraitce làune joie inspiréepar son interprète Xavier deMaistre ? « Xavierest sportifetsaitdanser, voilàunaspect du portrait que j’ai fait de lui », confie Péter Eötvös, avant depréciser : « Je trouvela plupartdes concertos existants très bien écrits pour harpe,maisilsne s’aventurentguèredansles modernitésdes dernières décennies. C’est pourquoi j’aiessayé de nourrir l’écriture de harpe d’éléments plus actuels,et de l’associer àun petit orchestre. » Sur plusieurs cordes,les glissandos de harpe influencentainsi l’écriture orchestrale.
Jeuprès delatable, frappe surle bois, arrachéset harmoniques dressentun inventaire quasiillimitédes possibilités techniqueset timbres de l’instrument. De l’usage dela scordatura surunepartie du registre naissentdes couleurs inédites : abaissées d’un quart de ton, certaines cordesproduisent de délicieux frottements lorsqu’elles sonnent en mouvementsparallèles avecles cordes à « hauteur normale ».Au centre delapièce,un « hommage àRavel »rappelle quele compositeurfrançais amagnifié l’écriture dela harpe. Nonseulement avec son Introductionet Allegro, qui a inspiré Péter Eötvös,maisaussi avecla féerie deMa mère l’Oye ou encorelepremier mouvement du Concerto ensolet son extraordinairesolo d’harmoniqueset de glissandos. Peut-être Péter Eötvös,danssapropre pensée concertante,se souvient-ilaussi commentRaveldistribuaitlessoliausein de son orchestre,capable d’offrirunmagnifique contrepoint de bois àlapartie dupiano.
Au côté d’un instrument commela harpe, l’orchestre doitse réinventer.Il n’en demeurepas moins quelesoliste joue encorelepremier rôle. Dès l’introduction, Péter Eötvös l’invite àse livrerau cours d’unegrande cadence dontles courbes de plus en plus amplesse transformerontdans l’Allegro en lignes tournoyantes.Il lui offrirauneautre cadence à l’issue du troisième mouvement, requérant l’improvisationsans vraiment suivreles vieuxpréceptes dugenre. En effet, l’interprètene devra y recourir àaucune mélodie,aucun accordni motifantérieur.Le va-et-vient plus ou moins vifetlargedesmains surles cordesdessinerades formes fascinantes.Des mouvementsbrowniens imprévisibleset pourtantmystérieusement ordonnés, comparablesau balletdes oiseauxse resserrantetsedispersantdansles nuées d’étourneaux.
Pensez à vous abonner pour découvrir d’autres vidéosFrance Musique !
この記事見てニセコに行きたくなった人たちに全力でプレゼンしてみる
まず、滑りたい人たちへ。といっても自分はヒラフしか詳しくないけど
ニセコは雪がいいとは言う。パウダーの軽さなら道北や道央の方が軽いのだけど、軽すぎると失速したときに立て直しが出来ないのである程度の腕前がない限りは軽すぎると却って楽しみを損なってしまうものだ。
その点ニセコの良さは、軽すぎないというところ。
コースレイアウトも一箇所を除いて、すばらしく長いコースをビギナーの腕前でもなんとか降りてこられるし、最高に広くて速くて風にも強いゴンドラ（これは愛知万博で使用されていたものを買い取ってカスタマイズしたもの）で快適に周回できる。
滑り終えたどの地点にも広いヒュッテが配置されており、休憩のタイミングがバラついても全く問題にならない。ゲレンデが広すぎて集合に苦戦するかもしれないので事前の打ち合わせは必要だとは思うが、スマートフォンをなくさないように数名（できれば全員）持っていれば済む。
コースレイアウトで例外的に不可避な難所は「第二の壁」という地点なのだけど、ここも相当変則的に避ける方法が一つあるのと、スノーボードでなければそこまで難しい斜面というわけではないので無理せず木の葉落としで降りてもらうしかない。
スノーボード初心者の人たちだとむしろニセコ連山のアンヌプリがおすすめになるのかもしれない。しかし初級者以降の腕前か体力がある、スキーヤーが多いなどといった場合はヒラフ&花園をおすすめしたい。あのゲレンデには雪山の魅力のほぼ全てがある。地形、圧雪非圧雪モーグルのバーン、近年どんどん良くなっているパークレイアウト。
もっと気軽に観光メインでという人々に耳よりなのは、ヒラフエリアはオシャレなカフェレストランがとても多いと言う事だ。
簡単に行ける範囲でおすすめを列挙する。定番のjojo'scafeとグラウビュンデンの両雄はどちらも素晴らしい軽食とスイーツが楽しめるカフェで、老舗故にアメニティすらもひたすら良い。もし天気が悪く宿泊先からこの二店舗に行っただけで一日を終えてしまったとしても、全然すばらしい休日になることを賭けてもいいくらいだ。食事はどちらも王道のメニューで、このエリアでは例外的なコスパがある。jojoカフェのブラウニーとフレンチプレスのコーヒー、グラウビュンデンのチーズケーキと紅茶は滞在中の滑る時間を削ってでも試しておくべき。
滑り志向の方々にはゲレンデ内の食事も、割高にはなるがスキーブームの頃を知っているならば隔世の感があるのではないかと思う。エースヒル、タンタアン、HANAZONO308はもう一つのヒュッテキングベルに比べればカフェ飯志向（やや割高）。ウェルカムセンターのホテルアルペンの食堂か食彩比羅夫もある。
ラーメンでベストは風花だ。ひらふ坂の店が目に入るとは思うが、空腹が過ぎるのでなければ5分ほど無料シャトルバス乗り場で待ち、でひっきりなしに周回しているハイエースのようなバスの「泉郷」を経由するものに乗りましょう。（因みにこのバスは完全無料で4パターンの行き先があり、使いこなすと飛躍的にひらふの満足度が高まります。）
風花もメニューは王道のニセコラーメンがおすすめ。ちぢれ中太麺に絡む味噌のクラシカルな味わいの上に、じゃがいもポタージュのエスプーマとバターの香りが合わさる濃密な味わい。超達者な英語でテキパキとホールをさばく店長さんの美しさも行くたび感動する。
風花が泉郷に移転してしまったが、ここには前述したグラウビュンデンともう一個、スープカレーのつばらつばらという3つの良店が固まるエリアになったので却って紹介するぶんにはわかりやすくなった。
泉郷から更に先にはそばのいちむら、格調高いカフェMozart、絶品シュークリームとイタリアンディナーのL'ocanda、更に少し離れてジェラートのルヒエルがある。ルヒエルは特に車がないと行けないレベルだが、サイクリストでもある方がおられたら羊蹄山周遊の折、地元パン屋の雄ホワイトロックの直営カフェと並んで居心地の良い休憩スポットになるだろう。
ついでに倶知安の店も少し。中華はベーシックな広華、点心の籠堂がおすすめ。和食な日本料理 佐藤が酒も肴も握りも良い。素材は北海道、腕は都会の洗練がある最高のやつ。しかし一番のおすすめは成吉思汗の廣松。ここはあえて説明をしないが、タイムスリップしたかのようにかつての倶知安も味わえる名店。おっちゃんおばちゃん元気でね。
ひらふから反対に行けばまた色々あって、東山でソフトクリームの高橋ミルク工房、ベジビュッフェのプラティーボ、エリア最高のジンギスカンが楽しめるロフト倶楽部、紅茶専門店ルピシア直営カフェ
ニセコ町エリアはほんとに詳しくないけど本格ナポリピッツェリアのデルソーレ、そばの楽一、SEEDベーグル、高野珈琲店はどれも名店。
車があるなら更に進んで真狩エリアの温泉＆高級フレンチマッカリーナ、ブーランジェリーJinで買ったパンにトゥルモンのコンフィチュールとニセコチーズ工房のフレッシュチーズを併せるなんていう世界一の朝食を取ることだってできる。
京極町のうどん野乃傘も忘れ難い、夏前の輪行で食べた天ぷらにはアスパラの概念を覆される衝撃を受けた。
なんか食い気に走りすぎたけど、滑り以外の人が多いかと思ってひとまずこんな感じで
本当はまだまだまだまだ語り尽くせぬ思い出とそれ以上の魅力がこのエリアには満ちています。
今年はちょっと久々に雪も足りてるそうだし、行かない手はないんじゃないでしょうか。
元記事でもありましたけど、この貧しくなったと言われている日本でも尚、世界と比べればウィンタースポーツを楽しむために必要なハードルはとてつもなく低く、かつ得られるクオリティは世界有数です。
この優位さをぜひ一度は享受してみて欲しいです。因みにレンタルギアはニセコ、ルスツともにクオリティが高いものも使用できるようになっていたりします。が、繁忙期は予約が必要なほどなのでひらふの場合はグランヒラフレンタルかニセコBOOMSPORTを利用するのがベストです。レンタル最大手のRYTHEMはジャパニーズスピーカーが少ないので英語ならば細かい対応を受けられるはずです
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざLisp やMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp やMozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1.エラーをたくさん出す
2.デバックの仕方を覚える
3. 小さく動かして確かめる
4.Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことはgoogle などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法はprintfデバックである。これをまず出来るようにする。
怪しい変数をとにかくprintf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったらfirebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名なunix （というOS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
Permalink |記事への反応(32) | 03:13
第1章プログラミング概念入門1.1計算器1.2変数1.3関数1.4リスト1.5リストについての関数1.6プログラムの正しさ1.7計算量1.8 遅延計算1.9 高階プログラミング1.10 並列性1.11データフロー1.12 明示的状態1.13オブジェクト1.14クラス1.15 非決定性と時間1.16原子性1.17 ここからどこへ行くのか？1.18 練習問題第1部 一般的計算モデル第2章 宣言的計算モデル2.1実用的プログラミング言語の定義2.1.1言語の構文2.1.2言語の意味2.2 単一代入格納域2.2.1 宣言的変数2.2.2 値格納域2.2.3 値生成2.2.4変数識別子2.2.5 識別子を使う値生成2.2.6 部分値2.2.7変数の，変数への束縛2.2.8データフロー変数2.3 核言語2.3.1 構文2.3.2 値と型2.3.3 基本型2.3.4レコードと手続き2.3.5 基本操作2.4 核言語の意味2.4.1 基本概念2.4.2抽象マシン2.4.3 待機不能な文2.4.4 待機可能な文2.4.5 基本概念再訪2.5メモリ管理2.5.1 末尾呼び出し最適化2.5.2メモリライフサイクル2.5.3ガーベッジコレクション2.5.4ガーベッジコレクションは魔術ではない2.5.5Mozartのガーベッジコレクタ2.6 核言語から実用的言語へ2.6.1 構文上の便宜2.6.2関数(fun文)2.6.3 対話的インターフェース(declare文)2.7 例外2.7.1 動機と基本概念2.7.2 例外を持つ宣言的モデル2.7.3 親言語の構文2.7.4システム例外2.8 進んだ話題2.8.1関数型プログラミング言語2.8.2 単一化と内含(entailment)2.8.3 動的型付けと静的型付け2.9 練習問題第3章 宣言的プログラミング技法3.1 宣言的とはどういうことか？3.1.1 宣言的プログラムの分類3.1.2仕様記述言語3.1.3 宣言的モデルにおいてコンポーネントを実装すること3.2 反復計算3.2.1 一般的図式3.2.2 数についての反復3.2.3 局所的手続きを使うこと3.2.4 一般的図式から制御抽象へ3.3再帰計算3.3.1スタックの大きさの増加3.3.2 代入ベースの抽象マシン3.3.3再帰計算を反復計算に変換すること3.4再帰を用いるプログラミング3.4.1 型の記法3.4.2リストについてのプログラミング3.4.3 アキュムレータ3.4.4 差分リスト3.4.5キュー3.4.6 木3.4.7 木を描画すること3.4.8構文解析3.5時間効率と空間効率3.5.1 実行時間3.5.2メモリ使用量3.5.3 償却的計算量3.5.4 性能についての考察3.6 高階プログラミング3.6.1 基本操作3.6.2ループ抽象3.6.3ループの言語的支援3.6.4データ駆動技法3.6.5 明示的遅延計算3.6.6カリー化3.7抽象データ型3.7.1 宣言的スタック3.7.2 宣言的辞書3.7.3単語出現頻度アプリケーション3.7.4安全な抽象データ型3.7.5安全な型を備えた宣言的モデル3.7.6安全な宣言的辞書3.7.7資格とセキュリティ3.8 宣言的でない必要物3.8.1ファイルを伴うテキスト入出力3.8.2グラフィカルユーザインタフェースを伴うテキスト入出力3.8.3ファイルとの状態なしデータI/O3.9 小規模プログラム設計3.9.1設計方法3.9.2プログラム設計の例3.9.3ソフトウェアコンポーネント3.9.4スタンドアロンプログラムの例3.10 練習問題第4章 宣言的並列性4.1データ駆動並列モデル4.1.1 基本概念4.1.2スレッドの意味4.1.3 実行列4.1.4 宣言的並列性とは何か？4.2スレッドプログラミングの基本的技法4.2.1スレッドを生成すること4.2.2スレッドとブラウザ4.2.3スレッドを使うデータフロー計算4.2.4スレッドのスケジューリング4.2.5協調的並列性と競合的並列性4.2.6スレッド操作4.3ストリーム4.3.1 基本的生産者／消費者4.3.2 変換器とパイプライン4.3.3資源を管理し，処理能力を改善すること4.3.4ストリームオブジェクト4.3.5ディジタル論理のシミュレーション4.4 宣言的並列モデルを直接使うこと4.4.1 順序決定並列性4.4.2 コルーチン4.4.3 並列的合成4.5 遅延実行4.5.1 要求駆動並列モデル4.5.2 宣言的計算モデル4.5.3 遅延ストリーム4.5.4有界バッファ4.5.5ファイルを遅延的に読み込むこと4.5.6ハミング問題4.5.7 遅延リスト操作4.5.8 永続的キューとアルゴリズム設計4.5.9リスト内包表記4.6 甘いリアルタイムプログラミング4.6.1 基本操作4.6.2 ティッキング(ticking)4.7Haskell言語4.7.1計算モデル4.7.2 遅延計算4.7.3カリー化4.7.4 多態型4.7.5 型クラス4.8 宣言的プログラムの限界と拡張4.8.1効率性4.8.2 モジュラ性4.8.3 非決定性4.8.4現実世界4.8.5 正しいモデルを選ぶこと4.8.6拡張されたモデル4.8.7 異なるモデルを一緒に使うこと4.9 進んだ話題4.9.1 例外を持つ宣言的並列モデル4.9.2 さらに遅延実行について4.9.3 通信チャンネルとしてのデータフロー変数4.9.4 さらに同期について4.9.5データフロー変数の有用性4.10歴史に関する注記4.11 練習問題第5章メッセージ伝達並列性5.1メッセージ伝達並列モデル5.1.1ポート5.1.2ポートの意味5.2ポートオブジェクト5.2.1 NewPortObject抽象5.2.2 例5.2.3ポートオブジェクトに関する議論5.3 簡単なメッセージプロトコル5.3.1RMI(遠隔メソッド起動)5.3.2 非同期RMI5.3.3 コールバックのあるRMI(スレッド使用)5.3.4 コールバックのあるRMI(継続のためのレコード使用)5.3.5 コールバックのあるRMI(継続のための手続き使用)5.3.6エラー報告5.3.7 コールバックのある非同期RMI5.3.8 二重コールバック5.4 並列性のためのプログラム設計5.4.1 並列コンポーネントを使うプログラミング5.4.2設計方法5.4.3 並列性パターンとしての機能的構成要素5.5 リフト制御システム5.5.1 状態遷移図5.5.2 実装5.5.3 リフト制御システムの改良5.6メソッド伝達モデルを直接使用すること5.6.1 1つのスレッドを共有する複数のポートオブジェクト5.6.2ポートを使う並列キュー5.6.3 終点検出を行うスレッド抽象5.6.4 直列依存関係の除去5.7Erlang言語5.7.1計算モデル5.7.2Erlangプログラミング入門5.7.3 receive操作5.8 進んだ話題5.8.1 非決定性並列モデル5.9 練習問題第6章 明示的状態6.1 状態とは何か？6.1.1 暗黙的(宣言的)状態6.1.2 明示的状態6.2 状態とシステム構築6.2.1システムの性質6.2.2コンポーネントベースプログラミング6.2.3オブジェクト指向プログラミング6.3 明示的状態を持つ宣言的モデル6.3.1セル6.3.2セルの意味6.3.3 宣言的プログラミングとの関係6.3.4 共有と同等6.4データ抽象6.4.1データ抽象を組織する8つの方法6.4.2スタックの変種6.4.3多態性6.4.4引数受け渡し6.4.5 取り消し可能資格6.5 状態ありコレクション6.5.1インデックス付きコレクション6.5.2インデックス付きコレクションを選ぶこと6.5.3 その他のコレクション6.6 状態に関する推論6.6.1 不変表明6.6.2 例6.6.3 表明6.6.4証明規則6.6.5 正常終了6.7 大規模プログラムの設計6.7.1設計方法6.7.2階層的システム構造6.7.3保守性6.7.4 将来の発展6.7.5 さらに深く知るために6.8ケーススタディ6.8.1 遷移的閉包6.8.2単語出現頻度(状態あり辞書を使用する)6.8.3乱数を生成すること6.8.4口コミシミュレーション6.9 進んだ話題6.9.1 状態ありプログラミングの限界6.9.2メモリ管理と外部参照6.10 練習問題第7章オブジェクト指向プログラミング7.1継承7.2 完全なデータ抽象としてのクラス7.2.1 例7.2.2 この例の意味7.2.3クラスとオブジェクトを定義すること7.2.4クラスメンバ7.2.5属性を初期化すること7.2.6 第1級メッセージ7.2.7 第1級の属性7.2.8プログラミング技法7.3 漸増的データ抽象としてのクラス7.3.1継承グラフ7.3.2メソッドアクセス制御(静的束縛と動的束縛)7.3.3カプセル化制御7.3.4転嫁と委任7.3.5内省7.4継承を使うプログラミング7.4.1継承の正しい使い方7.4.2 型に従って階層を構成すること7.4.3 汎用クラス7.4.4 多重継承7.4.5 多重継承に関するおおざっぱな指針7.4.6クラス図の目的7.4.7デザインパターン7.5 他の計算モデルとの関係7.5.1オブジェクトベースプログラミングとコンポーネントベースプログラミング7.5.2 高階プログラミング7.5.3関数分解と型分解7.5.4 すべてをオブジェクトにすべきか？7.6オブジェクトシステムを実装すること7.6.1抽象図7.6.2クラスを実装すること7.6.3オブジェクトの実装7.6.4継承の実装7.7Java言語(直列部分)7.7.1計算モデル7.7.2Javaプログラミング入門7.8能動的オブジェクト7.8.1 例7.8.2 NewActive抽象7.8.3 フラウィウス・ヨセフスの問題7.8.4 その他の能動的オブジェクト抽象7.8.5能動的オブジェクトを使うイベントマネージャ7.9 練習問題第8章 状態共有並列性8.1 状態共有並列モデル8.2 並列性を持つプログラミング8.2.1 さまざまな手法の概観8.2.2 状態共有並列モデルを直接使うこと8.2.3原子的アクションを使うプログラミング8.2.4 さらに読むべき本8.3ロック8.3.1 状態あり並列データ抽象を構築すること8.3.2 タプル空間(Linda)8.3.3ロックを実装すること8.4モニタ8.4.1定義8.4.2有界バッファ8.4.3モニタを使うプログラミング8.4.4モニタを実装すること8.4.5モニタの別の意味8.5トランザクション8.5.1 並列性制御8.5.2 簡易トランザクションマネージャ8.5.3セルについてのトランザクション8.5.4セルについてのトランザクションを実装すること8.5.5トランザクションについてさらに8.6Java言語(並列部分)8.6.1ロック8.6.2モニタ8.7 練習問題第9章 関係プログラミング9.1 関係計算モデル9.1.1 choice文とfail文9.1.2 探索木9.1.3カプセル化された9.1.4 Solve関数9.2 別の例9.2.1 数値例9.2.2パズルとnクイーン問題9.3論理型プログラミングとの関係9.3.1論理と論理型プログラミング9.3.2操作的意味と論理的意味9.3.3 非決定性論理型プログラミング9.3.4純粋Prologとの関係9.3.5 他のモデルにおける論理型プログラミング9.4自然言語構文解析9.4.1 簡単な文法9.4.2 この文法に従う構文解析9.4.3構文木を生成すること9.4.4 限定記号を生成すること9.4.5 パーサを走らせること9.4.6 パーサを「逆向きに(backward)」走らせること9.4.7 単一化文法9.5 文法インタプリタ9.5.1 簡単な文法9.5.2 文法のコード化9.5.3 文法インタプリタを走らせること9.5.4 文法インタプリタを実装すること9.6データベース9.6.1 関係を定義すること9.6.2 関係を使って計算すること9.6.3 関係を実装すること9.7Prolog言語9.7.1計算モデル9.7.2Prologプログラミング入門9.7.3Prologプログラムを関係プログラムに翻訳すること9.8 練習問題第2部 特殊化された計算モデル第10章グラフィカルユーザインタフェースプログラミング10.1 宣言的／手続き的方法10.2 宣言的／手続き的方法を使うこと10.2.1 基本的ユーザインタフェースの要素10.2.2GUIを構築すること10.2.3 宣言的座標10.2.4リサイズ時の宣言的振る舞い10.2.5ウィジェットの動的振る舞い10.3 対話的学習ツールPrototyper10.4ケーススタディ10.4.1 簡単なプログレスモニタ10.4.2 簡単なカレンダウィジェット10.4.3ユーザインタフェースの動的生成10.4.4 状況順応時計10.5GUIツールを実装すること10.6 練習問題第11章 分散プログラミング11.1 分散システムの分類11.2 分散モデル11.3 宣言的データの分散11.3.1オープン分散と大域的ネーミング11.3.2 宣言的データを共有すること11.3.3チケット配布11.3.4ストリーム通信11.4 状態の分散11.4.1 単純状態共有11.4.2 分散字句的スコープ11.5ネットワークアウェアネス11.6 共通分散プログラミングパターン11.6.1 静的オブジェクトとモバイルオブジェクト11.6.2 非同期的オブジェクトとデータフロー11.6.3サーバ11.6.4クローズド分散11.7 分散プロトコル11.7.1言語実体11.7.2モバイル状態プロトコル11.7.3 分散束縛プロトコル11.7.4メモリ管理11.8 部分的失敗11.8.1 失敗モデル11.8.2 失敗処理の簡単な場合11.8.3 回復可能サーバ11.8.4アクティブフォールトトレランス11.9セキュリティ11.10アプリケーションを構築すること11.10.1 まずは集中，後に分散11.10.2 部分的失敗に対処すること11.10.3 分散コンポーネント11.11 練習問題第12章 制約プログラミング12.1 伝播・探索法12.1.1 基本的考え方12.1.2 部分情報を使って計算すること12.1.3 例12.1.4 この例を実行すること12.1.5 まとめ12.2プログラミング技法12.2.1 覆面算12.2.2回文積再訪12.3 制約ベース計算モデル12.3.1 基本的制約と伝播子12.3.2計算空間の探索をプログラムすること12.4計算空間を定義し，使うこと12.4.1深さ優先探索エンジン12.4.2検索エンジンの実行例12.4.3計算空間の生成12.4.4空間の実行12.4.5 制約の登録12.4.6 並列的伝播12.4.7 分配(探索準備)12.4.8空間の状態12.4.9空間のクローン12.4.10選択肢を先に任せること12.4.11空間をマージすること12.4.12空間失敗12.4.13空間に計算を注入すること12.5 関係計算モデルを実装すること12.5.1 choice文12.5.2 Solve関数12.6 練習問題第3部意味第13章言語意味13.1 一般的計算モデル13.1.1 格納域13.1.2 単一代入(制約)格納域13.1.3抽象構文13.1.4構造的規則13.1.5 直列実行と並列実行13.1.6抽象マシンの意味との比較13.1.7変数導入13.1.8 同等性の強制(tell)13.1.9 条件文(ask)13.1.10名前13.1.11手続き抽象13.1.12 明示的状態13.1.13by-need同期13.1.14 読み出し専用変数13.1.15例外処理13.1.16 失敗値13.1.17変数置き換え13.2 宣言的並列性13.2.1 部分停止と全体停止13.2.2論理的同値13.2.3 宣言的並列性の形式的定義13.2.4 合流性13.3 8つの計算モデル13.4 よくある抽象の意味13.5歴史に関する注記13.6 練習問題
