 
|
はてなキーワード: コードとは
ここでいう苦労人とは、進学するお金がなかったり、家庭環境にめぐまれなかったり、いろいろとめぐり合わせが悪くて、自分の判断や努力以外でのっぴきならない境地に立たされた人のことです。
まず、苦労人であることは特に触れられることがない限り隠しておきましょう。別に自慢することではありません。
苦労人であることやそれによって得た経験やスキルは評価の対象になりません。
とても残念なことでありますが、あなたが引退して、成功者インタビューを受けるときまで、そのエピソードは封印しておくのがベターです。
苦労だったり、他人の失敗に巻き込まれたり、天災に巻き込まれたりした経験は、自分にとってプラスではありますが、水平飛行の人生を送ってきた人からみれば、特異値をもったスキルや考え方は脅威です。ツメは隠しておきくことをおすすめします。
苦労したタイミングで、徹底的に誰かに助けられるような状況ならば、問題がないのですが、苦労人は、その苦労をなんとかぎりぎりで克服できたのではないでしょうか。克服できたことは大変大きな自信につながります。自信は持っていいのですが、この自信もそっと胸のうちに秘めておきましょう。
どん底から見てはいけないものがあります。水平飛行の人生を送っている人たちの不平不満です。
車で歩行者突っ込んだ人、バスジャックしちゃった人のように感情の高まりがすべてをリセットさせる方向へ暴走しかねません。しかし、そのくらいのことで世の中は変わりません。より多くの水平飛行の人生を望む人がいるからです。
恵まれてくると、生きる困難に立ち向かうためでなく、どうでもいい人生の枝葉のことに対して不平不満をいうようになります。
そういう人に近づかないことは重要です。近づかなくてもインターネット上の交流サイトでは、見たくなくても見かけてしまいますので、情報の取捨選択には過分に注意を払ったほうが、余計な気持ちのフラストレーションを発生させることもなくいいと思います。
水平飛行中の人の悪事を偶然にも目にすることがあるかもしれません。しかし、これはあなたにとってチャンスではなくトラップです。
あなた自身がかかわることは何のプラスにもなりません。義侠心や正義感から何かしらのアクションを起こしてしまうかもしれません。
それは、災いを招く以外のなにものでもありません。積極的に応援しない立場をとるのが今後のためです。
あなたのコツコツした積み重ねよりもむしろ、降って沸いた幸運のほうがはるかに効率がよかったりします。
幸運があったら、大切な人とこっそりと分け合ってください。人に見せてはいけません。
あと、あわてる必要はありません。われ先にいった人は次の信号で止まって待っています。
一日に寝る時間も、一回で食べれるごはんもお金持ちでも貧乏人でもそんなに変わりません。健康食材を食べても死ぬ人は早死にしますし、ジャンクなものを食べて長生きする人は長生きします。
一人の人が管理できるものの絶対量は決まっています。たくさん持ちすぎるととそれを管理することに時間と手間をとられて楽しめません。
死ぬときは手ぶらです。持ち物を少なくしておかないと残った人に迷惑をかけることもあります。
大切な家族といっしょにご飯が食べれることのような他愛もないことが実は一番のしあわせだったりします。そんな他愛もないことからすら見放されてしまったかのように思い込みがちです。
そのくらいの幸せならば、ちょっとしたきっかけで、ふっと幸運が沸いてくるのではないでしょうか。
それでも、へこたれそうなときは、あなたが祖国やふるさとの一員であることを思いだしてください。あなたが締めるネジが、あなたが読み取るバーコードが、必死に打ち込むプログラムコードが、「ありがとうございます」という挨拶が、あなたの運ぶ荷物が…、私たちの国を地域を作っているのです。このような考え方は、戦後の日本ではタブー視されてきたかもしれません。苦しいとき、つらいときにこっそりと心の中で思い出してください。あなたは一人ではありません。
ぜんぜんアドバイスにもなっていないかもしれませんが、あなたの大切な人をいちばんに思って生きてみてください。それだけです。
以上、送ることばでした。
いや、文系でコード５年目です。とかでも、普通にGoogleに入ってるぞって話だが？Googleは外資で簡単に首を切れるから、そこまで敷居が高くない。
高年収でかつ、余裕でGoogleに入れるという事ならおっしゃるとおりだが、そもそも、高年収で余裕でGoogleに入れるという段階で、高年収を保証してしまっているから意味が無い。
また、Googleに余裕で入れれば高年収である。という論理も成り立たない。
年収１０００万超がウジャウジャいるのは知ってる。
視野が狭いも何もエンジニア自身は皆そう思ってるから転職してる訳だろｗｗｗｗ
コードも書けないアホ共と一緒にするなと思ってる奴らが実際にコードを書けるエンジニアに高収入を提示するソーシャルゲー業界に流れてるんだよ。
ある程度形ができて動き出したら、コードじゃない一般人が読んで判るような手続きの流れを紙に書いて、だいたい一から作りなおす羽目になるけど、そういうやり方が俺には合ってる。
そっちの方がやる気もでる。
俺はコード書くのは好きで何時間でもやってられるけど、設計とか要件とか整理したりマニュアル書いたりするのはマジでヤリたくないよ。
そんなのコード書けないヤツがやれよとか思うわ。
ガチでメーラとWordとExcel,パワポ（しかも2003（笑））、teraterm、FFFTP位しかつかわねーからさ
あいつら本気でXP(笑）、メモリ1GBで足りてるとか思ってるからタチがわりーわ。
・コードがかける若手SE（笑）がEclipseとかMySQL、Oracle,Chrome,Firefox,IE,Java,.netと使うからある程度スペックが欲しい。(と言っても今時の５万で買える普通スペックで良い。。）
↓
・若手が新しいPC寄越せと要求
↓
・年食ったコードがかけないSE（笑）はOffice2003（笑）位しか使わないし、めんどくさいから要らないと抜かす
↓
・先輩がいいって言ってるのにお前らが要求するのか？とか言って取り合わない。
↓
・ほんとに必要な最前線の若手にまともなPCが行かない、その結果朝にパソコン起動してメーラとEclipseが起動するのに１５分かかる環境の出来上がりｗｗｗ
一方部課長以上の役職には全員Androidタブレットが支給され
お飾り部長には組織移行都度に新PCが卸される（結局何してるかもしらんがｗOfficeとIEしかつかわねーくせによｗｗｗ）
そりゃ社員がセットアップするし、何も入ってねぇから環境移行もし易いもんなｗｗ
もちろんAndroidタブレットはメール確認するくらいにしか使わないｗｗｗ
iPadやAndroidタブレットのブラウザ、メールをちょこっと触った位で最新になったと思い込むめでたい老害達。
そのHTML5とサーバサイドの開発するのは俺たち若手SEなんだがなｗｗｗｗ
でも結局使わないし飽きて部長のタブレットは机の中に入れっぱかおきっぱ。
クラウドクラウド、SalesforcrSalesforce
クソウォーターフォール維持しながらスピード感がとか寝言ぬかしてんじゃねーぞｗｗヴォケが。
上の承認が～承認が～って要件定義が～ってお前らクソ共の承認があってスピードも何もねぇだろうがｗｗｗ
その上テストドリブンしようとすると、要件が固まってないだろ！とか抜かすし、殺すぞ。
結果アホ共が思いつきで言い放った言葉は忘れない
SalesForceのパンフレットに開発は１月を目処に実装する、みたいな文言を間に受けて
え？じゃあ、プロトタイピングとかテストドリブン型とかでやるの？とか聞くと、
いや、客の要件をしっかり聞いて要件をしっかり洗い出して～上司の承認をしっかりと得て手戻りがないように～とか抜かすｗｗｗｗｗｗ
おい、お前それ今までとかわらねーじゃねーかｗｗｗｗｗ
あーいうのは少人数チームで全員が開発者としてプログラムが十二分に書けて仕様書とかの書類を最低限にして
要件定義や決定権限の大部分を現場に委任して優先順位の高い項目からを集中してやるから出来るのであって
日本のほとんどのアホSI企業の典型的なコードの書けないExcel書くだけの御用聞きSE（笑）なんて邪魔以外の何者でもないｗｗｗ
そんなゴミSE（笑）が多くを占める会社で出来る事じゃねーんだよｗｗｗｗ
あーいうゴミ共は居るだけでどーでもいい好みでの文句をグダグダいうから余計に作業が遅くなるｗｗｗ
こういうクソみたいなことばっかりやってるから古い日本企業はダメなんだよ、ゴミどもが、さっさと潰れろ。
そして俺はクソSI業界を見限ってソーシャルゲーム業界に転職準備をしているのであった（完）
http://anond.hatelabo.jp/20120207005408
まなめはうす恐るべし
ちなみに私のPCのスペックはPen4 1.6Ghz メモリ1GB HDD 30GBです。
これでメインはJavaのStruts2とSpring Eclipse3.7で組んでます。
これより低い奴出てこいや…
とりあえず一部間違えていたので訂正ｗｗｗ
１．HDDは37GBでした。ごめんなさい、実際に見てみたら間違えてました。でもいつもSVNチェックアウトするときとかデカイzipを落とす時はいつも何か消してからしています。
２．ケースはチェーンで鍵がかけられているので開けられません(^p^)よって自分での拡張は不可
後、時々あった。
PGなんてのはゴミがやる仕事だからそんなの気にかける方がゴミ
とか
とか
コードを書かなきゃいけない時点で大手ではない
ちなみにT○SとかI○M、NT○の人もコード普通に書いてたよ。
ってか書くとこは書くでしょｗｗ
んで上みたいな考えの人はそれで構わないでしょう。
そうやって思っててコードやプログラム部分なんてどうでもいい。
フロントエンドやバックエンドが発達しても設計書レベルや提案レベルに落としこむ場合に実コードの知識なんて影響しない思うならそれでどうぞって感じ
いつまでも何でもバッチ処理（笑）にこだわる人も良くいますしねｗｗｗｗ
私からしたらいつまでコードの書けないSE（笑）が成り立つか逆に聞きたい位ｗｗｗ
ま～コードがかけないSE（笑）からいつも馬鹿にされてるのを知ってるから、コードがかけるSE（笑）はどんどん逃げてっているんですよね～
わざわざプログラム（笑）とか馬鹿にされてまで居るものじゃねーよｗｗｗ
現在どんどんSI業界から出来る人が率先して辞めてるからｗｗｗ
ただでさえ人材不足のクソSI業界にいつ影響が表面化するか（もうしてるか？）楽しみですNE!
私は先に役に立たない大量の船頭しかいない泥船から抜け出しますｗｗｗ
戻って来ることもないでしょう！多分！
それではアデュー！
いちおうフォローしておくと
大規模SI,SE会社でも 部署によってはコードリーディングから始める部署もあるから 会社名というより部署名。
同じ会社でも ビルやオフィスが違うと 設計＝なんちゃって設計 だったり 設計＝コード読めるだったりする。
その辺が 大規模会社の 問題点かと思う。 できる部署もできない部署も 同じ会社名でよばれるからね。
それで、いや会社に出したんだから会社として責任取れよってお客さんは思うけど、そんなん別部署だし。
NTTや東芝程の大会社ともなれば、部署が違えばもはや別会社。
その辺を踏まえて 設計を発注しないとお客さんはあぶないとおもう。
そうはいっても、 設計＝コード読めるレベルの人は高給取り確定で そこらの小さな会社にいるかと言われると・・・
というレベルだし、やっぱり大企業に出すしか無いというのもまたけっこう真実だと思う。日本の場合。
んーそれが現状のITは上流はろくにコード読めないのが当たり前になってる
http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg2-0e2d.html
http://d.hatena.ne.jp/ryoasai/20120125/1327501906
本当はあなたの言うとおり、設計するならそれについて知らないといけないのが当たり前なんだけどそうじゃなくなってるのがおかしい。
簿記会計の処理するために 自分自身が簿記できるくらい勉強する のは 設計に入るし
デザイン周りの処理するのに 簡単なデザインできるくらい勉強するのは 設計に入るし
プロ並みにとはいわんが、業務知識があって、それをベースにそれぞれのプロとコミュニケーションして設計するってのは設計の基礎。
既存システムの巻き取りで、死にながら既存システムのコードを読んでコードレベルで、旧設計を理解するのも設計の基礎
って思ってる俺は間違ってるのか？
（俺自身 大規模設計の時はそれをやるので、最初はプロと作って業務知識を担当者に教えてもらうところから始める）
設計だけの設計がなんか、半完成のプラモを組み立てるみたいなことをイメージしている気がした。（それ設計違う）
例えが違うかもしれないけど、楽譜が読めないけど指揮者なら出来る、みたいなことをいわれても、指揮の前提には、楽譜が読めて、総譜を暗記していて、その次に指揮ってのがプロでしょ？指揮しかできない。っていわれたら、普通は楽譜は読めるのが前提だよね。一般的には。そうじゃなければ、指揮の真似で棒を振るしかできないという言い方になると思う。
DeNAが「ソースは公開するが勝手な改変禁止、用途限定」の極めてユニークなライセンスを打ち出して数時間後に撤回した。
https://github.com/DeNADev/Arctic.js/commit/b92eea0a83b9b01c53eb3f6fb65fdb8af6bc0aab#diff-1
さて、「内容は公開するが、内容の改変は許諾が必要」というオリジナリティ溢れるライセンスを、この記事では「DeNAスタイルライセンス」と呼ぶ事としたい。さて、DeNAライセンスの内容から、DeNAのたくらみが幾つか想像できる。
「ウチのソースを侵害しとるやんけワレぇ、出るトコ出てもらおかい」と中小ソフトハウスを牽制恫喝し、囲い込むために敢えてソースを公開し、他社プロダクトの類似動作やモバゲー参加ベンダーへの牽制に利用したかった、と読むことは難しくあるまい。それはDeNAスタイルライセンスの指針はOSSのそれではなく、明らかに特許指向であるからも伺い知れる。MicrosoftやAppleに範を取り、知財戦争における兵器兼防衛機構としてDeNAスタイルライセンスで守られたコードを行使したかったであろう事は想像に難くない。
多くの日本企業が製品のOSS化に踏み切れないのは、正に上記の一点に尽きる。
というのがエンタープライズエグゼグティブ様の本音であることを考えると、DeNAスタイルライセンスは、日本企業の欲望を満たす厚顔無恥なジャパニーズスタイルライセンスとして社畜や下請けの皆様の献身を一身に集めたであろう。仕事のない下請けソフトハウスが、DeNAスタイルライセンスの大手SIer謹製フレームワークを必死にカイゼンしてコネ作りに励む美しい光景が、数年後には見られたかも知れない。
DeNAスタイルライセンスの隆盛が、日本のIT企業に利益を齎したかもしれないのに。DeNAスタイルライセンスが、日本のIT企業を更に強固にガラパゴス化して守る鉄壁のゾウガメの甲羅になれたかもしれないのに。「Googleっぽいからいいよね」みたいなノリでMITライセンスに安易に逃げたDeNAの及び腰が残念でなりませんでした。まる。
Pythonをかれこれ5年ほど使っているけれど、いい加減頭にきた。
大体頭に来るような内容というのは限られていて大体は
http://www.aoky.net/articles/steve_yegge/tour_de_babel.htm
本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメインの言語となる望みを絶ったのは、永久凍土の問題なのだ。人々はいまだ埋め込みインタプリタにTclを使っている。どのような面から見てもTclよりPythonの方が遥かに優れているというのに——ただし永久凍土の問題を別にすれば。
これに尽きる。
よく言われるが、インデントに縛りがあるのもselfが付くのも慣れてしまえばさほど気にならないし、むしろ魅力的とも感じる。
しかし、Pythonを本当の意味で糞たらしめて居るのはその言語を使っているコミュニティがあまりにも思考停止しているからだ。
インデントやselfが気に入らないなんて些細な問題を他の言語使いから散々文句を言われたがために、本当の意味で言語の弱点になっている部分が指摘された時にも「それは言語仕様が悪いんじゃない。言語仕様に沿って考えられないお前の頭が悪いだけだ」と言ってくる。
実際のところ、Pythonの仕様には言い逃れのできない仕様の穴は幾つもある。もちろんよく引き合いに出されるRubyやPerlにも仕様の落とし穴は山ほどある。仕様の穴そのものは実はそんなに深刻な問題ではない。
真に問題なのは、Pythonコミュニティはその仕様の穴を断じて穴と認めない事だ。
言語同士でdisり合いになったとき、何かその穴をつつかれた場合の各人の反応はおよそこんな感じだ。
Perl使い「そうだよね、そこの仕様は頭悪いよね。でもPerl6のこの機能使えばこんなに短く綺麗に書けるんだぜ(と全く読めないコードを出す)」
Ruby使い「うんうん、仕様の話題でもそこは殺人現場とか呼ばれてるね。コミュニティ的にはこっちの機能を使うことを推奨しててそっちはobsolatedだね」
PHP使い「それ言い出したらこっちにこんなに大きな地雷あるし、この地雷なんてもっと大きいぜ。ほんとPHPは地獄だぜ」
Python使い「お前の思考通りに言語が動くんじゃなくてお前の思考を言語に添わせるんだよ、言語の挙動すら理解せずに使おうとするんじゃねえ」
こんな感じに、まず最初に質問者へ人格攻撃を行う。インデント言語であることやselfの問題について未熟なプログラマからのどうでもいい指摘を散々受け流してきたPythonコミュニティは、言語仕様について文句を言われる事に慣れているためまず相手を攻撃する。初心者を寒波が洗礼するのだ。
言語仕様が汚くなっている事まではどの言語も一緒なのだけれど、Pythonコミュニティだけは欠点を認めず必死に(∩ ﾟдﾟ)アーアーきこえないという態度を取る。
これこそがPythonを糞言語たらしめる最大の弱点である永久凍土の問題。コミュニティが凍れば言語の進歩も凍る。
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
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です。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？