  |
はてなキーワード: Lispとは
Lispに残された唯一の問題はLispを書けないプログラマが大勢いることだ。
そいつらが死に絶えれば全ての問題は解決される。
例えばHTMLだってLisp風味に書いたほうが読みやすいに決っているのだ。
(html
(head
(body
(p "text")
Lispってラテン語みたいな物？歴史的だの言語学的にだの、いろんな価値は認めるけど、今から勉強して理解しよう、ましてや使おうって人は少ないみたいな。
あの書きにくいＳ式記法で得られるメリットはコードがデータとして扱えるということだけど
コードをデータとして扱いたいと思う場面が実際に日常のコーディングでどれだけあるのかと
むしろなぜLispがあるのにjavaScriptだのRubyだのが人気あるのかが分からん。
括弧が前にあるか後ろにあるかの違いだけじゃないか。
なんか偉そうに書いてみた。
SFCには頭がおかしいプログラミング言語使いがたくさんいる。特に研究室に入ると、バイトでバリバリ書いている人間や、研究や趣味でライブラリを量産する人間に出会うこともあるだろう。彼らに惑わされてはいけない。最初は彼らの言っていることは一つも理解できないだろう、理解する必要は無い。彼らはプロダクションで安定するかどうかという縛りから自由だ。流行り廃りに敏感で、昨日言ってることと今日言ってることが違う。
これは実際に手を動かして使ってみて好感触かどうかささっと確かめられる人間だからできることで、プログラミングできない人がこれについていこうとしたら間違いなくプログラミングが嫌いになる。
こういう言葉に惑わされるな、コードを書くための勉強をするな、コードを書け。
できる人は概ね、できない人の気持ちがわからない。受動的になるな。積極的に書け。
「プログラミングなんて特殊技能で、少なくとも教養じゃないでしょ..」という認識が横行している今だけのチャンスとも言える。
webプログラミングができると「技術的には簡単だがアイデア一発で作ってみた」もので、ほんのちょっとだけ有名になれる可能性がある。論文を書いて学会に投稿したりニュースになったりするよりも、よっぽどお手軽に(一部での)社会的ステータスを高めることができる(かもしれない)。
↓ こういうのでいい（失礼だが）。
こう言っている人間を見て何を思うだろうか。
「いや少しずつでいいから今やれよ」とか「英語できたらもっと世界ひろがるのに..」とか「大学生なのにそれで恥ずかしくないの」とか思うかもしれない。
知らない世界を知らずにいることは大いなる機会損失である。プログラミングに金はいらない。金はないけど時間はある、時間を大量投入できる最後の機会、大学生である内に学んでおいた方が望ましい。
基本的なスタンスとして、講義ではプログラミングを教えてはくれない。講義に期待するな。プログラミングに限らず、全ての講義は自習への足がかりであり、興味のとっかかりである。実際に意思を持って積極的にコードを書かない限りプログラミングのことは好きになれない。自分で考えながら手を動かしてコードを書かなければ覚えないし、初学者が配られたプリントを写経しても血肉にならない。
「今日から俺は！」という感じでプログラミング講義を受けると爆死は約束された未来である。「腕試ししよう」「これなら楽勝じゃろ」という意気込みで講義を受けると、意外に学ぶことが多い。完全な初学者の域は脱しておいた方が講義は有効的に活用できる。少なくとも、最初の2週間をインストールと環境構築のみで終わらせるスジの悪い講義を取得してはいけない。
また、講師によってはJavaScriptのことをJavaと呼称したり、JavaScriptはLispに比べて読解が平易であるためハッキングを受けやすいと言ったことを平然と言ってのける。選別にあたっては「講義名」と「講師名」を明言した上で「先輩に聞く」「Twitterを活用する」等の手段をとるべきである。十二分に注意されたし。
道具を選ばないのはプロだけである。初学者は多少高くても自分をサポートしてくれる良いマシンを入手すべきである。1行のコードを書くだけでも恐ろしい手数が必要なアーキテクチャを選択するのは愚行だ。
モデルは何でもいい、無理して上位機種を買う必要は無い。お金が余ってるならMacBookProを買えばいいし、勿論一番安いMacBookAirでも全く問題ない。特にweb系のコードを書く際、インターネットで検索して出てくる記事はだいたい「OSがUNIX系であること」を前提としたサンプルである。これをWindowsの開発環境に読み替えるのは、初学者に取ってつらいだろう。
また、Macならばパフォーマンスは多少犠牲になるがwindowsも起動できる。どうしても光学機器が必要になればCNSコンサルタントで外部接続式の光学機器を貸し出してくれる。Macが気に入らなくてもどうせ研究が射程に入る3年生に上がったぐらいのタイミングでPCを買い替えるだろう。バイトして稼いだ金で「俺の考えた最強のマシン」に買い替えればいい。それまではMacを使え。
OSに固有の使い方なんて学ぶ価値はない、覚える価値も無い、操作時間が短縮されるだけだ。「普通の会社はWindowsなんでしょう？」というくだらない理由でWindowsPCを選択肢の第一候補にするな。Windowsを買うなら積極的選択としてWindowsを買え。
SFCにおいて、PCは毎日抱えて通学し、毎日開いて講義を受け、苦楽を共にする相棒だ。消極的に選択するな。
SFCには「共同購入PC」という制度がある、これを利用してはいけない。
もし要件が変更され、Macがラインナップに入れば積極的に利用するべきである。
条件を示す。
見た目に変化が無いと楽しくないだろう、こんなのを実行しても何も楽しくないはずだ。
#include <stdio.h> int main() { int a; a = 1 + 1; printf("%d", a); }
マイナーな言語を選択してはいけない。「ライトウェイト言語」と呼ばれるくくりから選択肢するのがいいだろう、以下のようなものがある。
中でもjavascriptとrubyは推薦できる、SFCでも書いている人間は多い。
phpとperlはおすすめできない。ドキュメントは多いが、不慣れであればロジック以外に割かれる労力が非常に多い。pythonは日本語のドキュメントが少ないため最初はつらいだろう。
最初にjavascriptをやるのは理に適っている。index.htmlというファイルを作り、scriptタグの中にコードを書き、ブラウザでindex.htmlを開けばもう実行されている。web上のドキュメント量も豊富だ。
rubyも推薦できるが、少なくとも「自分でHTTPサーバを立てる」という言葉にピンと来るようになってから使い始めた方がいいだろう。きっと何をしていいかわからないはずだ。
他にもProcessing(http://processing.org)などが推薦できる。ダウンロードに時間がかかるだけでインストール作業は必要ない。こちらに関しては旧プロダクト名である「proce55ing」をキーワードに検索すると記事が引っかかりやすいという暗黙のルールがあった、今はどうだか知らない。
最近ではnode.jsの採用事例も増えてきた（他に比べれば圧倒的少数、増加傾向にあるという意味）。クライアントでもサーバでも活躍できるjsは学習コストパフォーマンスが高いと思われる。
書ける言語は一つにしぼってはいけない。なるべくたくさんの言語を使ってみよ。ブログ記事を読みあさり、「その言語は何が得意なのか」調査しろ。不得意なことをその言語にやらせるな。
下記のような上達ストーリーが考えられる。
例えばpythonは音響処理や数学計算が得意だったりする。そういった特徴を徐々につかみながら書ける言語の種類を増やし、好きな言語を見つけて好きな言語のことをもっと好きになればいい。
自分が好きな言語のことを胸を張って自慢できるようになったなら、あなたは既に初学者ではない。
人に聞くとvimやemacsを推薦されるかもしれない。もしそれを使ったことが無いなら、あるいは「プラグインの導入方法がわからない」なら、やめろ。Terminalを開かなくても書けるGUIアプリのテキストエディタを使え。
具体的にはSublimeText(http://www.sublimetext.com/3)を使うのがよい、無料である。
ライセンスが必要だが、起動時に「買ってね！」というダイアログが出続けるだけで無料で使用し続けられる。信頼できるエディタだと思ったら買えばいい。
SublimeText3にPackageControlというものを導入すると、標準で備わっていない機能を拡張できるようになる。こちらのブログ(http://p.tl/Ev7b)の「インストール手順」セクションのみを実行する。たとえば「Jadeという言語を、文法に従って色付けしてほしい(SyntaxColoring)が、その機能が無い」という時に、「Jade用プラグイン」をSublimeText内で検索し、インストールすることができる。
もし使い方がわからないければ、回りにいる「プログラミングができる優しい人」に上の記事を見せ「インストールしてくれませんか？」と頼んでみろ。きっと戸惑いながらも正しい操作をしてくれるだろう、一挙手一投足を見逃さず学べ。
エロ画像を集め続けるツールが欲しいとする。どうやったらいいか考える。クライアントjsだけでは限界が来る。rubyなど別の言語を試すステップを踏む。
http://www.slideshare.net/shokai/ss-26387303
プログラマ同士じゃないと伝わりにくい用語が頻発すると思う。逐一人に聞いていてはラチが開かない。人に聞くな、適当に読み飛ばせ。
ブログ記事は本ではない、それを読解しなければならない理由はない。適当にはてブでもつけといて、次の記事を読め。たくさん読めば共通項が見えるだろう、コードが書けるようになるに従い読めるようになるだろう。
みんなが息をするようにコード書いてさ、みんなでしあわせになろうよ。
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
元増田は著者について貶されるように取れる表現があったのが気に食わないだけだろ。
"野田くん"みたいなこと言ってるし、大学関係者かな。程度が知れる。
関係ないが、著者名でぐぐったら、On Lispを訳出したきっかけは下記にあったよ。
http://d.hatena.ne.jp/oneshotlife_tom/
GNU Maximaの中身を知りたいからLispを勉強始めたって行動力はすごいな。
EmacsLispあたりの話かと思ったら斜め上だった。
ちょっとよくわからないんだが、LispにしろPrologにしろ199X年代には少なくとも大学で授業として教えるような”古典”だったわけだが
2005年だったか、2006年だったかに出版の話があったようでその後2007年に発売されたわけだが、当時Lispの情報ってあんまりなくて、翻訳苦労してるみたいなことをはてダに書いていた（ような気がする）。
すくなくともLISPの情報が少ないということはなかったと思うぞ。
Perlが198X年代だがLISPは195X年代で、超がつくほどの古典言語で、日本語でも山ほど文献があるはずなんだが、最近は進化していないので、ネット上に文献があるか？という話では難しいが、古い図書館に行けば古い本がいっぱいあるだろ。
http://d.hatena.ne.jp/oneshotlife_tom/20130418/1366264835
"on lisp"でぐぐるとトップに出てくる草稿置き場を見ずに
Download 無料で手に入るものにお金を払うってどうよ？！ ポール・グレアム氏の知に対して対価を支払うのではなく、質の悪い翻訳に対して対価を支払っているのかと思うと悲しくなってきた
（注 現在この文は変更されている模様）
とか言っちゃってるのがなんというかかんというか。
なおon Lispの日本語版は決して質の低い翻訳ではありません。野田くんは、2005年の時点ではすでに翻訳を開始していた(と思う)。で、2005年だったか、2006年だったかに出版の話があったようでその後2007年に発売されたわけだが、当時Lispの情報ってあんまりなくて、翻訳苦労してるみたいなことをはてダに書いていた（ような気がする）。
あと学術関係の書籍は逐語訳をすれば出来上がるものではなく、まだ存在していない語を新たに作ったりとか、日本人が正しく元の言語と同じイメージを描けるように訳語を変える(数学系か物理系か情報系かでまたイメージするところが変わるので難しいが）とかいろいろ工夫が必要。また、実践系の書籍、特にWebに挙がってるタイプや、著者がつらつらと書いたタイプ（レガシーコード改善ガイドみたいな）とかは元の文章が読みにくかったり、例に間違いがある場合もあり、それをわかりやすく整理するのも訳者（編者）の仕事になっていて、日本語のほうがよっぽどわかりやすい場合もある。そういう編集作業に対価は発生しているのだ、となんで考えないんだろう。
というか良い物をただで貰えるというのは単に著者が良い人なだけで、基本的にはよいものを手に入れたらそれに対価は払うべき。なにただのりしてんだよ、というのもある。
しかも2007年発売で未だ発売されてる本だぞ。評判とか前もって検索しなかったのか？今買っときゃなくなる本でもあるまいに本屋で見かけてから家に帰って調べる時間くらいあるだろう。ネットで買うならその前にググれば草稿版も原文もでてくるのに。
というわけで表題に戻るわけだが、世の中には著しく情報検索能力もしくは試行錯誤能力が劣る人々がいるらしいということは、僕もそろそろ大人になったので理解している。情報検索能力（もしくはその情報の精査能力）というのがなければ対価を払って上げ膳据え膳で情報をもらうしかないんですよ。そこらへんはビジネスチャンスになるので、頭の良い人はみんな情報検索能力をもっとあげるべき！とは言わない。むしろ知らなくていいよ、日本語だけ出来ればいいのよというだろう。そんで文句をいってもちゃんとはいはいって言って聞いてくれる。それはビジネスだから。
ググりはするけど試行錯誤能力が異様に低い人間というのもいる。まぁいってしまえばググって上の３つの候補しかみない、みたいな。３つの候補で目的を達成することのできる検索能力があればそれはそれで構わないとは思うが、大抵の場合そういうわけにはいかないわけで、候補からキーワードを抽出してそれでググり直して、もしくは不要な語を覗いて再検索をかけて目的の情報に到達するためにはやはり試行錯誤能力が必要だ。もちろんできなくてもたぶん問題ない。それもビジネスチャンスになるから、代わりに調べてくれて代わりにやってくれる人もいる。それで文句を言ってもやっぱりはいはい聞いてくれる。ビジネスだから。
俺は面倒くさがりなのと自分を棚上げして文句いう奴嫌いなのでとっととググれクソが、と思うけどな。ていうか金がもったいないならググれよ！ケチならケチなりにただで提供していただいている検索エンジンをおもいっきり活用して、必要なところに必要なだけ金を使えよ。対価を支払うべき相手にきちんと自分が得た価値の分だけ対価を払えよ。それができないなら頭下げて金でも払ってろうんこうんこ。
そもそも、よくよくLinkedListクラスのインターフェースを眺めてみると、これは連結リストのノードを表現するクラスではなく、連結リストそのものを表現するクラスのようですね。こんなものをいくらネストしたところで多次元配列の構造しか作ることができないのは自明でした。現段階では、元記事の文章は不適切であると言わざるを得ません。
ところで、Lispの真似事をC/C++でさせたいのであれば、タプルを定義するのが先だと思いますが、いずれにしても教育カリキュラムや人材の選別過程でこのようなコードを組ませる方針は私はあまり感心しません。あれは一種のハックであって、木構造のアルゴリズムをコードで表現する際に必須の、本質的な概念ではないからです。仮に知らなくとも、それは「その人が育ってきた文化が違う」だけの話です。例えばB木を実装するにもRadix Treeの実装にしても知らないままで全く困らないでしょう。
ほかにも、計算量の評価に触れていないなど、気がかりな点はありますが、元増田氏からのコメントもないようですので、ひとまずこのへんで。
あいにくLispはよく知りませんが、Lispの場合はタプルに実データだろうが他のタプルへのポインタだろうが何でも入れられるので、連結リストの自然な拡張で二分木などの木構造も表現できる、という話であれば理解できます。
一方、Cのような変数の方に型のある言語の場合、連結リストの自然な実装では
struct Node { int data; struct Node *next; };
という感じになると思います。上記のdataにはポインタは入らない(キャストすりゃ別ですが)ので、どうしても型を修正しなければ木構造は表現できないですよね。
元の記事では「LinkedListの入れ子でTree構造をつくり」とあるので、もしかして私の知らないテクニックがあるのか、何か別の前提条件があるのか(テンプレート使えとかね)、あるいはどこかに見落としがあるならご教授を頂きたいと思った次第です。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 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"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
オープン系のデスクトップアプリ開発、Webプログラミング、システムプログラミングを仕事にする人向けとして考えてみた。
学習環境はUbuntu Linuxで、デスクトップ上のターミナルか、WindowsからTeraTermでsshログインして行うことを想定。
なので前提知識としてLinuxのabcくらいは教えておくとして、もし来年度やるならこんなもんかな。
結構分量多めだけど、これでも基礎の基礎に絞った感じ。
おまけ：Pythonで学ぶ関数型プログラミング
なお、上述のカリキュラムでやらない言語(VB、javascript、C++、Objective-C、C#、PHP、Rubyなど)やWebフレームワーク(Django、Ruby on Railsなど)は、全てこれらの応用で覚えられると思うので、基礎教育終了後に各現場にてOJTで習得してもらう。
IDEも使わないけど、はじめの一歩で軽量エディタ+コマンドラインをやり込んでいれば正直どうにでもなるので省略。
あと最後がおまけ扱いな上にLISPで学ばないのは、要するに「リストすげー！超すげー!!」という感動を胸に今後も頑張ってもらうのが狙いなので(だって現状使う機会殆ど無いし)、最初にやって一番手に馴染んでいるツールで、理解のコアになる部分にサクッと触れて欲しいということ。
臓疾患持ち、身長170cmどまりの超低スペック高校１ 年生です。
プログラミングに興味を持ったのは今から３年前の 1２歳のときだった。
まだ、世の中がプログラミングは教育に必要だとか あまり叫ばれていないときの話だ。自分は勉強も運 動もできない。いや、何もかも人以下だ。
だから、プログラミングという物ができれば、他の 人と同等、それ以上になれると思いJAVAの教本をアマ ゾンで買った。 がんばってサンプルコードを打って 動かした
しかし、なかなか身に付かない。
構造体？とかよく理解できないのだ。
僕は教本が悪いと思い評判のいい教本をアマゾンで 買った。 しかし、理解できない。次第にサンプ ルコードを打ち込むことが嫌になってきた。
まだ、僕は懲りていない。
今度は言語が悪いと思い始めたのである C言語の 教本を買った。
結局、続かず２ヶ月で挫折した。
父親は僕の本棚にいろいろな言語の書籍が増えてい くのを見かねてPHPを僕に直接教え始めた。
PHPはなんとか理解する事はできた。
プログラミングで何か作りたいなんてなかった。
取り柄が欲しかった。
そしてプログラミングを学ぶのを一時的に辞めた。
その間にもなぜかプログラミング言語の教本を買い 物中毒のように購入して行った。 python、javascript、lisp入門。
去年の１月にiPhoneアプリを作ろうかなとふと思っ た。mac book airと書籍をお年玉で購入した。
結局、挫折した。
自分はプログラミングの本を購入する事しかできな い。金を使う事しかできない。プログラミングで何か したい訳でもなくただプログラミングが出来るという 取り柄が欲しかった。
読んだけどそれが何か？
gotoもインラインアセンブラもある、実行速度最適型および、メモリ最適型のC言語に対して何か？
それこそ、美しい言語が書きたいならC/C++ではなく JavaでもRubyでも、LISPでもPASCALでも好きな言語を使えばいいよ。
道具は選べるんだから。そして、C/C++でも美しく書くこともそれは出きるだろうが、そもそも生まれとして、そう言うふうに生まれていない
用途が違う言語に対して、美しくない。というコメントは間違ってるよ。
あとvtableは歴史的表現で古くからあるから、読みやすいよ。
つかvtable知らずに、ポリモルフィズムは語れないわけだし。
いや、CS系って、ソフトウェア作るのにハードの仕組み習ったりするし、自分で回路設計したりするんだが？
たとえば、MP3とかだとフーリエ級数展開とか、文系のやつがやるのか？
やって出来なくはないが、そういうのはたいてい 理系の仕事だろ。
数学的知識に基づかないプログラムなら、そら組めるだろうが、速度が指数的だ、対数的だってついて来られるの？
あとは、単なる一般の専門知識としてCGの理論も、コンパイラの理論も習うし LISPとかまで講義普通にあるんだぞ？
ソフトウェア業界のマネージメントでよくある話なんてもの、習うんだぞ？
別に、そりゃぁ、理系でもできない奴もいれば、文系でもできるやつもいるだろ。だが、平均を取るなら
CS系のプログラマはその時点で、初任給が高いんだよ。いま、平均の給料の話をしてるんだから
医者の話でいうと資格の話になっちゃうが、文系のピアニストと、音大出のピアニスト そりゃぁ、イレギュラーもあるだろうが
なんで、ピアニストなら音大に行かなかったの？ って話と全く同じで
プログラマ志望なら、なんでCS系にいかなかったの？って普通は言われるだろ。
そして、最初に就職する企業の推薦とかも同じ。そして、最初の企業が違うんだから、平均年収が高いってのは理がかなってるだろ。
支えてくれる家族または友人がいない場合、社会的な制度が整っていない以上、今の環境を逃げようが結果的には死にたいであるから、さっさと今の辛い環境を受けいれろ
が理解できないからその帰結の理由を教えてほしいといっただけなのですが...論点がずれているようですね？
プログラマーとしてはどうなんだろう。
ぜひ上を
プログラマーとしては彼の著書を二冊ANSI Common Lisp、On Lisp、後半は2回読み直すと考え方が変わると思います
またLispでWebサービスを作る意義は当時はあったのだと思いますが、今ではメタ言語でプログラムを生成することが一般的になって
きておりマクロの有用性、Slimeの素晴しさ、最適化ヒントのための機構が言語に内包されている点以上に特別な認識はしておりません
ただリーダマクロを利用すると構文自体を拡張することが出来るためLispを書く人はすべからく言語設計者としての腕が試されるのだと思います
(といっても私は本物のLispプログラマーではなく初〜中級者の域程度のものと認識しているため上級者以上の方はまた違う見解なのだと思います)
正直なところ、一時期自分もLuaに感動して、Luaで(mod_lua？)Webアプリを書こうとしたときもあったけど、RailsやCake、Nodeのexpressみたいなのでさえ、多くのユーザーが書いている方法の方が同じ悩みにぶつかり、googleすれば誰かがstackoverflowで解決しているので、コピペで取り敢えず乗り切る可能性が高くなる。
が、mod_luaに関してはガチレスしますと、Apache のpre post filter, mod_rewriteの煩雑さ軽減、Access,Auth,UserCheckのpre post、CustomLog置き換えくらいに試作品として個人だったら利用すると思います(プロダクションレベルならば実際利用する前に検証すると思います) mod_luaでもいいですが文章は何が目的かをはっきりさせて書いてください
後半のRails、Cake、Nodeでも同じで、「形にすることが目的」であれば、コピペ出来るものを御自分でえらべばいいのじゃないのでしょうか？なにが主張したいのかよくわかりません
# ゲームなどのアプリケーション内で使う言語はシンプルが一番だ。それはBASICやTclのように、美的には醜いものでも正解になることが多々ある。
# lispを選ぶのは正解だと思う。
TclをVHDLのシミュレーションツールとして数年利用しましたが、美的に醜いものではありません そしてなによりもゲームと一括りにしておりますが近年のゲームプロダクションを「舐めないでください」？？？Lispを触りもしないのに正解だと思うなども？？？
そんなことを最近のApple製品やGoogle製品の苛立ちとともに感じ、自分の人生の終焉や世界の終わりに思いを馳せながら今日もコードを書くか、身辺整理をするか、絶望感を眠ることでかわす毎日を送るだろう。
現実ではなく煽り文章だと理解しているつもりなのですが、中身がよくわからず何を伝えたい文章で帰結はなんなのかが大変よくわかりませんでした
酷い会社に就職するとブール演算さえまともに理解していない人たちが、銀行や年金のコードを書いている日本の恐ろしさに驚かされる。
金に困って、私もときどきバイトを探すのだが、バイトで地方銀行のプログラミングとか書いてあるのが普通の日本はちょっとおかしい。
多分、証券会社とかの方がまともなコードを書いているのだと思うが、精神的にはキツい気がして門を叩いたことはない。
もう、年齢的にも限界なんでね。
テクノロジーや数字に対して無知な文章と思えるようなことを主張しているようにしか理解できないことがひっかかります。他人は他人ですし変えることは出来ません。ですが自分の考え方はいくらでも受けとめかたは変えられるのではないでしょうか？
別にPerlでなくても、シェルスクリプト、Cでも構わないけど、所詮CGIだし、正規表現とか文字列に明るいから、打算的な面もあったんだろうと思う。
考えてみれば、あの頃は負荷についてあまり考えてなかったよな。
根本的なコンピュータの仕組みの理解が食い違っている認識なのですが、当時負荷を考えたときスケールアップをしていた理由は、「1台」のマシンと「2台以上」のマシンを管理する方法がまったく別のスキル(コスト)を要求するからです 現在ではフェールオーバだけでなく、冗長化の考え方が広くオープンソースの世界でプロダクションレベルに適用されたためであって、当時から負荷自体については考えている所では考えていました
また所詮CGIという意味では標準入出力さえあればどの言語でも出来るのは事実かと思いますが一方Lispだから打算というのは異なるのではというのは上の文章を読んでいただければ
エッセイのどのことを示唆しているかは不明ですが「成功している理由」を考察していることはあっても(時系列でいう後ろから前への考察)、「こうすれば成功する」という考察(時系列でいう前から後ろへの考察)について伝えてる文章は知りません よろしければその文献情報はどこにあるのでしょうか？
あの頃に成功しなかった人(つまり、私)はもう浮かばれることはないだろうし、今、彼らが言うようにやったとしても、あまり夢がないというか、生きてくのもどうだろうという気がしてならない。
誰も失敗した人の発言には耳を傾けないからね。
人生というのは、確かに一定の年齢を過ぎると選択の幅が狭まるというのは事実ですが「なくなる」というのは嘘です そしてそもそもその歩いてきた道だけは変えることは出来なく、これからの道は落とし穴かもしれませんが90度直角に歩くことさえ出来るものだと思います
また失敗した人の発言に耳を傾けないわけではないと思いますよ？むしろ否定的な感情を表に出しすぎるために難しくなってるのではないでしょうか？
この考察はその通りだと思いますが合理的ではないでしょうか？前回もお伝えしたように株式会社なのであれば株辺りの利益を最大限にすることが目的です また会社というのは民主主義ではなく株主主義です それさえ理解すれば組織の維持=経営者が優先されるのは当然なのではないでしょうか？従いまして「人間的に正しい」の意味を理解していませんが、あなたのいうその「人間的に正しい」と「組織の目的」との間で落とし所をつけ提案することが本来の従業員の仕事に含まれると理解しています。
支えてくれる家族または友人がいない場合、社会的な制度が整っていない以上、今の環境を逃げようが結果的には死にたいであるから、さっさと今の辛い環境を受けいれろ
長々と書きましたが、上の内容を簡潔に聞きたいだけでして、ブール演算やらLuaなどの話は聞いていません ブール演算などは高校生に3時間でも教えれば理解する人はいるでしょう
煽られたのか？判断が難しいですが元々考え方が違うように思えるので反論と補足を こちらからは煽るつもりはありませんが少しキツい表現になってるかもしれません
自分の相方とか、親とか、誰かが健在じゃなければ生きられないんだけどね。
この国の社会保障は皆無に等しいし。
そして、受け止めた所で、何も変わらないことを受け入れるしかない。
生きられないというのがよくわらないのですが、仮に受け入れたとして自分の寿命が縮まる可能性や後遺症が残る可能性が高くなる選択する意図がよくわかりません
そういえば、会社を辞めるときに不満をタラタラ言った奴と、それを煽ったレスをした奴が昨日ここで言い争ってたけど、会社相手に訴訟したって絶対に勝てない。
何かに勝つことではなく生きることが目的とすると、そのために会社に勝つ必要性は得にないと思いますが如何でしょうか？また万が一と修飾した理由は相手と穏便にするための方法の一つにもなりえ防衛手段の役目もありえます
本当に会社に問題があったとしても、その人を雇うことで自分の会社が訴えられるんじゃないか、と思うと人事はそんな人を雇わない。
競争と記述しておりますが経営でもしてらっしゃるのでしょうか？ 従業員は誰かと競争をしているわけではなく、会社から賃金を支払われた対価としてその条件に従って労働力を提供しているだけかと？ ただし、もし国境を跨いだことや同一業種での企業間なのでありあなたが従業員の立ち位置でありながら経営のことを考えるのであれば、ご指摘の部分もあるかと思いますが、それは従業員が気にすべきことではない＝責任者ではない、と考えております。また別の意図で、従業員は他の従業員と競争し働くことを示唆しているのであれば、本来は会社とは「協力」しあって貢献する類のものであり、その主張をすることが理解できない状態です
なぜ個人は会社に意見する権利がないのかはわからないのですが、株式会社というのは文字通り株式の利益を一定期間の中で最大限大きくすることが目的です。従いまして、この目的に合致する意見なのであれば、「よほど馬鹿な会社以外」は受け入れることも(経験上酷いブラックな会社でも)吝かではないですし直属の上司が難しいのであれば、その一つ、二つ上に直訴する程度のことは辞職を決意している程度なのであれば余裕で可能かと思いますし、そう自分は行動してきました。このようなことはスキルに依る所もあると思いますが重力といいきるよりも、自分や回りを信用するといったことを駄目元で構わないので繰り返すことだと思います(可能ならば動ける内に)。
まぁ、耐えられないなら、逃げるしかない。
未来に対して逃げたら「死ぬしかない」というのが帰結がやはりよくわからないのですが、どう考えるとそうなるのか、もしよかったらその論理を教えていただけないでしょうか？
追記
Lispがでる以上PaulGrahamをご存知だと思います。
建築とデザインにおいては、建物や品物は人々が使いたいように使えるべきである ということになる。例えば良いビルディングは、そこに住む人々が自分の生きたいように 生活を送る背景となるべきであり、建築家の書いたプログラムを実行しているように生きる ためであってはならない。
あなたが主張していることは上のエッセイのモノズクリの主張の考え方から真逆だと思われるのでやはり理解に苦しみます と「どうでもいいですが」lisp的再帰は末尾再帰のことを言ってるのでしょうか？？？
