「gdb」を含む日記 RSS

はてなキーワード: gdbとは

2014-08-12

真面目な話 Cだと

if(a) b();

gdbで追いかけている時につらい。

せめて

if(a)
 b();

にしてくれせめて。 でも こう書くなら

if(a){
 b();
}

でももう大差ねぇ

http://anond.hatelabo.jp/20140812115420

結論から言うと そのコードは どっちでもいい。

昔は1画面20-25行しか無いVGA環境だったが

今は1画面に100行ぐらい入るから

 if( a ){
    if( b ){
       f();
    }
  }
 if( a && b ){
    f();
 }

でも 視認速度に大差はない。 どっちも書く奴はたくさんいて なれる。

そんなことより、アルゴリズムを綺麗に書いてくれたほうが嬉しい。

 

大量に他人コードを読んでいると、その程度はなれて気にならない。

こう言っちゃなんだが、他人コードを読むのは(C言語で)デバッガで追いかけている時が大抵だからgdbラインエディタあたりでトレースやすければなんでもいい。

2013-06-18

http://anond.hatelabo.jp/20130618191249

Rubyエンジンコンテキストガード入れればいいだろ。

中間言語エンジン自体に手を入れてメモリーを欠損した部位を発見したり、ガードしたりできるが、Cの場合ハード装置を当てないとデバッガ以上のことは出来ないって話だよ。

CPUの上に直接アプリが乗ってGDB発見する構造

CPUの上にRubyを載せてRuby自体に改造を入れた上でGDBもいれて、アプリ検査する構造では強度が違いすぎるという話だ。

エンジンというクッションができる分、動的言語は開発プロジェクトから見たら強いんだよ。

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。

例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。

このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)

目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。

もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。

今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。


そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。


できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。

それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである

正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。

プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。

1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ

ただし以下のことは出来ない。

・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない

2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している

ただし以下に当てはまる。

自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない

3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる

全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。

前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。


初心者レベルの人に向けて

完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。

検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経

上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである

プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。

それなのに、なぜいつまで経っても書けないのか?

それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである

特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。

プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。

もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。

それには以下の点を意識してプログラミングすればよい。

・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること

このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。

1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す

まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである


これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。


関数メソッドをたくさん覚えなければいけない

無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事

エラーがいっぱい出てつらい

全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要

写経をしなければならない

教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。

なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。

写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。

また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである

とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。

さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。

1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである

初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。

しかし、それでよいのだ。

エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。

おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。

プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。

自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。

それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。

そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。

2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である

僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである

初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである

ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。

からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。

例を挙げると、

C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug

言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。


3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。

そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。

そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。

一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。

ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。

"Small is Beautiful"

これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。

まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。


4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。

おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。




現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。

でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。

そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。





2012-01-18

Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1

 

42 : デフォルト名無しさん : 2011/11/12(土) 23:53:51.20

Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ

端末からテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに

PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか?

けどまぁ、情弱文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか

45 : デフォルト名無しさん : 2011/11/13(日) 01:41:24.25

数値計算や端末からテキスト処理なんてWeb系じゃ大して使わないからなあ…

43 : デフォルト名無しさん : 2011/11/13(日) 00:04:23.30

PHPが未だに現役なのは、単に歴史的な経緯でしかないだろ

Pythonに関しては、ZopeさえコケていなければWebサーバLLとして大成功していたはずなのに、

Railsなんかが登場したおかげで、すっかり影が薄くなってしまますた....

44 : デフォルト名無しさん : 2011/11/13(日) 00:49:55.28

zopeってコケてたんだ

ってか、railsインスパイアされたフレームワークって今じゃ幾らでもあるよね

djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、

pythonPHPの方がユーザー数は圧倒的に多いと思うんだけど

本家railsって、他を遥かに越えるほど良いものなんだっけ?

48 : デフォルト名無しさん : 2011/11/13(日) 08:30:25.68

44

Zopeが登場した当時、RDB+PHPはもう古い、これからOODB+ZopeWebの中軸になる!」

さかんに宣伝され、雑誌でもZope特集が組まれていた

 

少なくとも自分ZopeからPythonという言語を知ったし、その時点でRubyは知らなかった

そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう

今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい

 

djangoCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう

しかしRailsはRailsコミュニティの活動が活発だし、その進化は異常に早い

 

Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoCakePHPから

何かのイノベーションが提示されでもされない限り、後発のdjangoCakePHPRailsに追いつくのは無理

Railsは決して技術的に完璧Webフレームワークではないんだけどね....(たとえばSeaSideのような.... )

 

からこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている

51 : デフォルト名無しさん : 2011/11/13(日) 12:55:40.83

 C a k e P H P は う ん こ   

遅い、設計が古い、動作がおかしいの3重苦

日本では流行ってないけど海外だとYiiが流行ってきてる

55 : デフォルト名無しさん : 2011/11/13(日) 17:31:12.14

CakePHP使ってんの?

可哀そうにw

53 : デフォルト名無しさん : 2011/11/13(日) 14:44:48.55

求人PHPばかりだからPHPやるしかないだろ。

57 : デフォルト名無しさん : 2011/11/13(日) 19:34:04.95

でもやっぱりいつもの使い慣れたLL(Python/Ruby)で

Webサービスを書きたいってのがある

73 : デフォルト名無しさん : 2011/11/15(火) 17:32:46.07

アメリカ言語ユーザー数は

Python>>>>>>>>Ruby

求人数は

Ruby on Rails>>>>>>>>Django

http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=

どういうことなの?

74 : デフォルト名無しさん : 2011/11/15(火) 17:48:15.59

RubyRails以外に使い道がないか

75 : デフォルト名無しさん : 2011/11/15(火) 17:54:35.50

海外ではRubyは昨今のRailsバブルのお陰で

もはやWebスタートアップ共通語になってるらしいからね

求人数が多いのはそのためだと思うよ

76 : デフォルト名無しさん : 2011/11/15(火) 18:03:23.05

なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・

Pythonのほうが使いやすいと思うのだがフレームワークRailsが優位なんだろうか

77 : デフォルト名無しさん : 2011/11/15(火) 18:23:14.33

Djangoは周辺ライブラリ微妙だし本体も鈍くさい感じがする。

でも、FlaskはSinatraより好きだからPythonが嫌いってわけではない。むしろ好き。

 

ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。

78 : デフォルト名無しさん : 2011/11/15(火) 18:38:46.28

同感だ

同じように思っている人が他にもいて安心した

79 : デフォルト名無しさん : 2011/11/15(火) 18:54:37.13

PHPJavaScalaには

Railsみたいなフレームワークあるのに

Pythonはいいのないんだよな

80 : デフォルト名無しさん : 2011/11/15(火) 21:19:09.89

PHPフレームワークが乱立しすぎているから、RailsPHPで実装してみようというやつが出てきた。

Scalaも注目されだしたのはつい最近のことだしな。

それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、

つの間にかフェードアウト

ただ、どうやってもRailsもどきRailsを超えることはできないのは間違いない。

83 : デフォルト名無しさん : 2011/11/15(火) 21:25:38.55

パクリオリジナルを超えられない(キリッ って定型句だけど、

これってキリッって言いたいだけだと思う。

後発品が先に出たものを超えたものなんていくらでもあるから

84 : デフォルト名無しさん : 2011/11/15(火) 21:30:04.39

D言語って超えたって?

85 : デフォルト名無しさん : 2011/11/15(火) 21:31:12.00

B言語って超えたって?

86 : デフォルト名無しさん : 2011/11/15(火) 21:53:33.76

でもRailsRubyの黒魔術を使いまくりから

PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない

90 : デフォルト名無しさん : 2011/11/15(火) 22:50:07.81

スタートアップなんて根無し草の集まりにとって、

googleが囲った言語coolさを見出せないんだろ

123 : デフォルト名無しさん : 2011/11/20(日) 11:32:16.79

まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ

91 : デフォルト名無しさん : 2011/11/15(火) 22:52:42.98

そういう理由じゃなくてRailsのほうが単純に情報プラグインも多いからでしょ

3 : デフォルト名無しさん : 2011/11/15(火) 23:07:07.67

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

わざわざ不合理で不完全な言語を使うなんて

社会からハミ出た奴らの精神的な作用によるものじゃないの?

95 : デフォルト名無しさん : 2011/11/15(火) 23:20:20.21

django情報プラグインが増えないという、

現実に対する鬱憤を吐いてるようにしか聞こえないな

もしも

linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん

真実であるのなら、今頃はdjango情報プラグインが溢れかえっているはず

104 : デフォルト名無しさん : 2011/11/16(水) 01:20:49.05

Python信者乙。

yumや、gdbgnome拡張pythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。

ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。

94 : デフォルト名無しさん : 2011/11/15(火) 23:15:11.93

というか、世界中Pythonプログラマが Remeber Zope!! を合い言葉

打倒RailsたるWebフレームワークを開発しているはずだけど、

いまだにRailsを超えるプロダクトが登場しないのはナゼ?

Railsも登場してから、かなりの年月が経過しているんだけどなぁ....

その間にもRailsRails 3が登場して、REST/AJAXの強化等の進化継続しているよ

347 : デフォルト名無しさん : 2011/12/09(金) 10:16:35.22

Ruby では

ary.map {|x| x**2}

となるものが、Python では

map(lambda x: x**2, ary)

となり、lambda の本体が1つの式では表現しきれなくなると

def mapper(x):

.....

map(mapper, ary)

書き換える必要があります

348 : デフォルト名無しさん : 2011/12/09(金) 10:24:20.94

Pythonのlambdaを用いた階乗計算

f = lambda x:(x and f(x-1)*x)or 1

RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから

andやorを使った不自然記述をしなくても

f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}

または

f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}

と書けます。lambda内でreturnが使えますから、書きたければ

f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}

でもOKです。

390 : デフォルト名無しさん : 2011/12/10(土) 15:35:41.62

348

これはPythondisっているように見せかけてRubydisっているのか? と一瞬思ってしまったw

だってRubyのほうが長くない?CLのfuncallみたいなcall()がちょっとうざいし…

そしてどっちもlambda式の中で束縛変数名前再帰可能、と

350 : デフォルト名無しさん : 2011/12/09(金) 11:12:13.28

要素に対する関数適用と、抽出を組み合わせる場合

Python

print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]

暗号のように見える。

Ruby

puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}

思考の流れと、コードの流れが一致しているので書きやすい。

351 : デフォルト名無しさん : 2011/12/09(金) 11:22:55.04

だれだPythonなら書き方はひとつとか言ってるのは

map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))

354 : デフォルト名無しさん : 2011/12/09(金) 12:22:07.37

pythonて可読性が高いのをうたってる割にはそこいまいちだよね

353 : デフォルト名無しさん : 2011/12/09(金) 12:10:08.46

Ruby場合には、左から右へと無名関数データフローあるいは

パイプラインのように並ぶからコードが読みやすい

 

関数型プログラミングに不慣れな初心者でも、参照透明性のあるコード自然に書ける

プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby

 

それと比較すると、Pythonコードは、関数型プログラミングというもの

いかに高度で難解なものであるかという事をもったいぶってプログラマ押し付け

 

もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう

356 : デフォルト名無しさん : 2011/12/09(金) 12:53:45.66

階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す

result_list = source_list.map { |elem|

  x = foo(elem.x)  # ここが局所宣言を書く部分

  y = bar(elem.y)  # ここも局所宣言の続き

  x + y       # 最後に評価された式の値が、無名関数のリターン値になる

}

Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから

x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける

このポイントは、実用的なプログラム関数型風で書こうとした時に、威力を発揮する

357 : デフォルト名無しさん : 2011/12/09(金) 12:59:21.07

余計分かりづらくなった

358 : デフォルト名無しさん : 2011/12/09(金) 13:17:26.54

リスト内包表記が暗号みたいと言ってる奴は

高卒ドカタなんだろうなぁと可哀想になる

大学数学に触れる機会があれば

集合の表記に似せてることが分かるから

386 : デフォルト名無しさん : 2011/12/10(土) 01:41:34.46

数学とかで慣れてるし区切りが関数のがわかりやすい

359 : デフォルト名無しさん : 2011/12/09(金) 13:46:31.97

355

map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。

関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね

Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ

360 : デフォルト名無しさん : 2011/12/09(金) 13:53:28.85

Rubyだと直感的に書けるコード

[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')

Pythonだと読みにくい。

'-'.join(map(str, reversed(sorted([1,4,3,2]))))

361 : デフォルト名無しさん : 2011/12/09(金) 14:07:17.88

360

Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....

364 : デフォルト名無しさん : 2011/12/09(金) 14:28:55.99

カッコだらけのコードを分かりやすくする基本的な方法静的単一代入じゃないか

Rubyのやり方は基本ではなく玄人のやり方だろ

372 : 369 : 2011/12/09(金) 16:21:03.82

Pythonでは組み込みの型でメソッドチェインはやって欲しくないな

listにmap,filterメソッドができたとしても、

似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。

シーケンスプロトコルの利点が活かせない。

383 : デフォルト名無しさん : 2011/12/10(土) 01:17:28.39

372

外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてます

Rubyユーザーは列挙可能なものmapselectできて当然だろって思ってる気がしま

377 : デフォルト名無しさん : 2011/12/09(金) 18:41:51.79

Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる

得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない

Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い

379 : デフォルト名無しさん : 2011/12/09(金) 18:48:52.27

Pythonユーザー調教っぷりは異常

「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く

387 : デフォルト名無しさん : 2011/12/10(土) 13:40:40.74

リストの内包表記はシンプルに書けるときは使うけど

基本その場でdefするのがPython風なんだと思う。

389 : デフォルト名無しさん : 2011/12/10(土) 14:40:31.04

無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像

384 : デフォルト名無しさん : 2011/12/10(土) 01:23:49.48

outer(center(inter( arg )))

これを読みづらいと感じるのは、左から右に流れる

日本語文に慣れているからだと思うが、

もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか?

385 : デフォルト名無しさん : 2011/12/10(土) 01:34:57.89

なるほど、ということは右から左、左から右どっちでも行ける言語が最高ですね

F#パイプライン演算子最高ということで

2011-07-20

RubyKangi #3 / Final RubyKaigi, Final Day

週末に行ってきたイベントだが、ちょっとインパクトが強すぎて、あとたぶん昼から通しで追っかけてるのは自分だけなので、この話誰かに伝えたい!と柄にもなく思ってしまった。

というわけで自宅Wikiから一部編集して張ってみる。

parse.yで構文いじり

  • 冒頭は yacc/C レベルでの正統的なid*追加して・・・の話かな(遅刻で聞けずだが)
  • 途中で Ruby レベルでできるだけする、という話に
  • 最後の end 羅列省略のための ennnnd は爆笑(Lisp cdddrのパロ)

Art with Glitch

活動報告:るびま分だけ

  • あの充実サイトの企画・運営話と聞いて!
  • 本当に毎回出し切ってる。書き溜めなし、揃った分は全力で出す
    • 「次号はないから」と毎回思いながら出している #なんという一期一会
  • 数年間は石の上だったが、遂に7年目。会議と違い、まだまだ終わらないよ!
  • 執筆企画いつでも募集してます
  • 記事の質とかインタビューで人を見せる企画とか、ホント魅力的だよなぁ

Hacking Ruby

GIS with Ruby

sinsai.info

  • どこらへんがRubyかと思ったら、やっぱりPHPだった。
  • PHP(Usahidi)でのスピーディーな立ち上げ話をしつつ、ugly codeをdisるTL
  • Ruby?Hack4Japanで書いてる人いるよー位(w
  • でも、来日した人に、日本はまだまだ復旧途上だという事は判ってもらえたか

Rails @ NotRubyKaigi

Fabio Akitaさん話

なぜRubyか、なぜRails

***みんながするから、は自分コモディティ化!***

世界に出るために:英語

ここまで、日本語でウケを取り、アメリカ人しか聞こえない英語をしゃべりつつの話。まじありえないレベルの覚悟と実践なんだが・・・!

ブラジルを変える

この人のセッションブラジル事情の紹介みたいな話で大ホール側のセッションも覗いてみようかなと思っていた所にこれで、ただちに絶対参加すべきレベルセッション格上げされた。こんな人がいるとは。

Ruby and Rails in Brazil

で、昼休み後の問題のセッション。結局ツイートどころじゃなかったが、こんな感じ:

プログラマが学ぶべきはプログラミングだけではない。全てだ。

心理学経済学物理マーケティング、、、全てだ。

この言語をみんながしてるからなんて最低だ。自分コモディティ化だ。

そんなのはキャリアじゃない。僕はこんな風潮と戦う。

Javaはあれが酷いとかPHPがとかいう態度でRubyを使うのも無駄だ。

自分がすべき事を良くできるから選ぶ。それ以外の姿勢は間違いだ。

自分が何を成せるのかだけが問題なんだ。プログラミングだけの話ではない

なんという激熱トーク。本当に小さかった南米Rubyコミュニティを仲間と共に成長させ、いまやRubyConf Brazilとか南米で何個もイベントが立ち上がるまでに育てた。この伝道のため、ここ数年で80箇所は回って普及に努めたとかとか。ブラジル事情への関心と関係なく、この熱量を体験できてよかった。

最後時間オーバー後の「あと一言だけ(本当はあと1分だけと本人は言っていたのだが、わざと誤訳してタイマー役の人に会場から叫んだ自分w)」でどんなにダメだとされていても、諦めずに進めという、過去偉人が貶められたり失意にあった時代の動画もよかった(もっとも、この話は知っていたのでインパクト自体は薄めだった)。

DeepConnect話

ORMインプリ

この後はLTとクロージング

クロージング:今北三行

インパクト強すぎw

これ漫画系展開をバックボーンにしたエンタテイニングなスタイルだと理解せずに真に受けると大変だなと心配になったり。なにしろ上は三行だけど全部通しで書くと

***I will crush you***

  • みんな、大人気ない大人になって競ってハックしようぜ!

真面目に受け取ったらヤバイ発言多すぎだろ・・・

 こ れ が 締 め の 講 演 か よ !

そういえば途中にまどマギネタも入ってた記憶があるのだが、上のインパクトが強すぎてどこかに飛んでった。

その後の高橋さん最後挨拶スタッフを集めてのスタンディングオベーションはちょっとうるっと来た。初参加だから今回の運営自体への思い入れはないのだけど、この回だけでも感激することが多かった。この完成度に達するまでどれだけの努力と熱意が投入されていたかと考えると。

隣の席が実はtdtdsさんでびびってたのだが、最初に立ち上がったのを見て、続く二人目のタイミング大事!とすぱっと立ち上がってみてよかった。その後前列の人がみんな!立とうよ!みたいにやって一気に雪崩状態。

herokuありがとう

これで会議は閉幕したのだが、さらにherokuの緊急パーティーが開催され、思い切って行ってみた。まあ、懇親会に輪をかけたリア充な雰囲気でまともに話せなかったのだが、

  • まつもとさんと入店前にgdbとかlua/rite/pythonの話ができた
    • 名刺を貰うのではなく、名前を覚えてもらえる自分になりたい!的なことを言った気がする(汗
    • まじでパッチくらいは書かないとだめだこれは / ていうか名刺とか割とどうでもいい(を。名刺よりパッチを受け取って下さい
    • 喉が痛そうだということに途中で気付いて申し訳なかった
  • ちなみに英語漬けの決意は、大学に入ったら自分ポルトガル語しか知らないがために遅れを取り、それが悔しくてやったそうな
    • その悔しさでその行動が取れる人は少ないと思う。やはりすごい

こんな一日だった。熱かった・・・

2009-02-13

[][]

出力関数無限ループを簡単に仕込める仕組みを使ってやるのが良いんでしょうね。

スタックレジスタを簡単に dump できる仕組みを用意すると楽です。




GDB の方では割りとそんな感じのことをやってます(スタックレジスタコードを毎回表示)。ただ、どうしても1インストラクション単位の実行になるので、なんともチマチマした時間のかかる作業です。

# あー、そうか。ソースプログラムからデバッグ情報ダンプできる関数に触れるようにすればいいのか……。つーか、インラインアセンブリを使えばいいのか……。

2008-08-08

cygwingdb

Cygwingdbが超使えねええええええええええええええええ

特にメモリ周りがいい加減すぎる!落ちるはずないところで落ちてんじゃねーよ!

おめーはそれでもデバッガか!

2008-02-29

http://anond.hatelabo.jp/20080229133914

いやー、Emacsがもてはやされたのは歴史の流れだから。歴史の視点で見ないとわからないよ。

viが比較的エディタ世界にとどまったのに対し、emacsシェルヒストリ機能をつけてみたり(bshにはなかった)、gdbにきちんとしたUIをつけてみたり(gdbの生のコマンドはひどい)、マルチウインドウを提供((テキスト画面で!))したりした。

だから、それらが全部洗練されたGUI環境で提供される現代、Emacsが統合環境だとかいっても通じない。結局、Emacsの今の利点は、統合開発環境すら作れそうなくらい強力なEmacs Lispマクロを持っている、ことだけだと思う。それが欲しい人は、それだけでEmacsを唯一絶対神と認めるよ。

おれは、Emacsにあこがれていたけど、こだわりはない。viにもない。edexがあれば最低機能は十分。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん