  |
はてなキーワード: javaとは
スクリプト言語系の人がよく挙げるJavaの良さで「スタイルを強制できる」っていうのがありますよね。だから大人数・大規模開発に向いてるって。
口の悪い人は「奴隷用言語」とかいいますけど、悪くない人もまあ遠まわしにそう言ってるわけです。
でも、実際の人海戦術的に質は問わないでとにかく人数を投入するような現場で行われてるコードのスタイルを統一する手法って、まず少数の「できる人」が一画面分とかのコードを書いて、残りの人がそれをコピペして改変してコードを書くって方法で、オブジェクト指向であるとか静的型の言語であるとか、そういうJavaの特性とはまったく関係ないところで行われてます。
Rubyだろうが、Pythonだろうが言語を問わないで実行できる手法です。
ちょっと考えたらわかりますよね。静的型だからとかフレームワークを使うからとか、そんなことでスタイルを統一できるわけないって。
その昔 C.vs.Pascal の論争でも、Pascalは教育用に作られて採点用が楽になるように誰が書いても同じようなコードになるように作られてるって珍説がありましたけど、JavaにしろPascalにしろ、その言語を使っただけで誰が書いてもおなじようなコードになるような言語が存在したら、いまごろその言語が世の中を席巻してますって。
プログラミングにそれほど見識がなくても「Javaはスタイルを強制できる」っていうのは間違いだって分かりそうなのに、それなりに技術力のありそうな人がこんな意見を言ってしまうのって、Javaが生産性が高いって部分は認めたくないけど全否定すると大人げないから「大規模開発に向いてる」ってくらいは言っておこう、遠まわしに奴隷用って言ってるだけだし、みたいな心理なんじゃないかって思ってます。
何にイラついてるかって、「人気エントリに入ってきてウザい」「なんだよ焼き直しじゃねえか」「はてブやたらついてる」「PV稼ぎかよクソ」「英語勉強記事と同類だわ」「入れるべきって、あんたの仕事環境や趣味嗜好を根拠にすんな」「また全部MacVimじゃねえの」とかそういうことを思うわけ。
とは言え自分もそういう記事を参考にトレンドを知ったりしてお世話になってきた部分もあるんだけど、じゃあ自分も同じように紹介して還元したいかっていうと、そうじゃない。だけど需要はあるみたいだ。みんな、良いアプリを知りたいんじゃなくて、自分の作業をもっと楽に早くできないか考えてるんじゃないかな。
アプリはあくまで道具。どんな目的を達成するために、どう組み合わせて、どういう手順でそれを使うのか。それを導入すると、どういう人がどう嬉しいのか。それをはっきりさせてほしい。それが理解できないままインストールするなんてことはしたくない。
だから、業種や職種、OS、作業目的を明示したレシピを公開して共有するサービスがあれば素敵じゃないか。例えば、
といった感じでぱっと自分の思いついたものを適当に上げてみました。
で、投稿されるレシピに含まれるアプリの統計を取ってトレンドを探ったり、時代の移り変わりに応じてレシピをバージョンアップしたり。黒い画面に抵抗がある人はそれが含まれるレシピを省いて検索。同じ作業目的でも効率に差が出るレシピには知識要求レベルも割り当てることでステップアップ形式にするとか。
これらを充実させていけば、目的に特化したレイアウトで規格化・整理した状態で横に並べて比較参照でき、それに慣れた人々はエゴに満ちた中途半端なブログ記事のクソデザインで邪魔なサイドバー、冒頭のよくわからない挨拶、わざわざ自サイトでそれをやることにイラついて糾弾が加速し、次第にアプリ紹介記事は消えていくことになるでしょう。そして結局何を目指しているかというと、
ということなのです。会社としての強みとしてそういったノウハウを抱え込むのもよいですが、なんかもっと高レイヤーで競いあったほうがいいんじゃないのとか思うわけです。業務フローをオープン化したらプレイヤーのスキルが汎化されて、より人材の流動性も高まって、もっと人間にしかできないようなことで悩めるようになるんじゃないでしょうか。
すごい今更だけど、1に対してだけ少し。
基本的に、まだ発展途上にあるものほど、理論面が強調されがちなんだと思う。
今の関数型言語は、まだデザインパターンが、色々発案されだしているけど、確立しきっていなかった頃のJavaやオブジェクト指向の時代、みたいな感じ。
Javaで言うデザパタは、関数型言語では大体、モナドとしてまとめられるわけだけれど、そのモナドを色々発明するために、圏論をしっておくに越したことはない、みたいな感じなんじゃないかと。
もっとも、そろそろすでに出てきているデザパタ≒モナドを利用するだけの、純粋な学習者も増え始めている頃合だから、気になりだしては来るタイミングなんだろうけど。
今日から新卒研修の技術研修が始まりました。初日はJava(JDK)をMacにインストールして、簡単なプログラムを書くことから始めます。
さて、なんでJavaなのかと感じるかもしれません。Webに限らずスマートフォンのマルチプラットフォーム開発にもJavaScriptが浸透し、RubyやPythonは学生の間で人気があります。
逆説的ですが個人的には、Javaを研修に選びながらも「Javaを覚えてほしいわけじゃないだよね」って思っています。
習得して欲しいのはJavaそのものではなく、どこまで言語の深いところまで掘り下げたのか。つまり「深さを探った経験」を得てほしいからです。
Javaが新卒研修に適しているのは、適度な深さと広がりがあるから。それも、C++ほど底が途方もなく見えない感じもなく、Rubyのようにあs（以下略）
この「言語を深く探った経験」は、まとまった時間がないとなかなか掘り下げられなかったりします。配属されて仕事や成果を求められるようになると経験しづらい。興味本位でアプリを作ることに没頭する学生時代にも経験しづらい。教授に多くのタスクをふられがちな院生時代にも経験しづらかったりします。
プログラミング言語を、深いところまで掘り下げる機会は、新卒研修の時期に適していると僕は思います。成果や責務に追われずに、プログラミング言語に没頭することが許されているからです。
深く掘り下げた結果、何が見えてくるか
Javaのもうひとつの側面は、個性があらわれやすい言語だと僕は感じます。きれいに書けば人間性が感じられるほど美しく書けます。逆に雑に書けば、プログラマとしての伸びしろが良い感じに見えるくらい、未熟に書けます。
Javaが新卒研修に適しているのは、適度に思考の深みを表現できるから。それも、C++ほど哲学的に難解になることもなく、Rubyのようにとr（以下略）
ここは賛否両論ありますが、いずれにせよJavaで何ができるのかではなく、Javaを通してその人の可能性の何が見えるのかが大事になります。アプリを開発する新卒側と、人材を開発する人事側の、視点の違いもありましょうが。
だからこそ、Javaというプログラミング言語を通して、深く掘り下げる機会を大切にしてほしいと思います。それから、Javaを通して何を表現できるのか。プログラム設計という点から、いろいろチャレンジしてほしいなって思います。
そうすれば、掘り下げた分だけ他の言語も、もっと深く短時間で掘り下げられるでしょう。
そうして、自分の思想や仕事に対する人間性を、プログラミングで伝えられるようになったら、きっと一人前のプログラマになるでしょうね。
ゆーすけべーさんが以前に作ってたimeeroみたいな感じです。画像Blogをスクレイピングしてエロ画像を効率的に見るサイトです。
なお、先程解約手続きを済ませたので4月末くらいに見れなくなります。エロサイト自体にあまり興味がなく、ローンチしたらやる気が無くなったのです。
テスト駆動開発がやりたく、DSLに強いロック魂を感じたRSpec。
はやりに乗ってBootstrap。
特にCapistranoは名前がキュートでやっていることがカッコイイのでどうしてもやりたい技術でした。
あと、メインとなるRailsはこの記事に書いているスキルの中で唯一経験が無かったというのが一番の理由です。Rubyが好きなのもありますけどね。
いやぁ、退職しようとすると会議室で8時間説教されるって都市伝説じゃないんですね〜。
ところで転職活動をした感覚だと、今より給与が2倍出るところでも簡単に内定が出ることが分かりました。
転職活動やエロサイト作成を通して精神的な余裕も出ましたので、もう少しSIerそのものの問題、仕事の進め方などを熟考した上で、本当に正しいSIerのあり方を考えたいと思います。無理そうなら逃げます。
以上、よろしくお願いいたします。
なんだか話題になってるから書く。
やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。
Haskellが短いコードでプログラムを書けるというのは分かる。
それでやりたい処理のほぼ全てがまかなえるということも実感している。
副作用のない小さな関数を合成して大きな関数を作る利点も分かる。
再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。
ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。
むしろ邪魔なんじゃないかと思う。
ファンクターやモナドの概念が圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。
圏論が必要なのは、Haskellを設計する人であって、使う人ではないと思う。
なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。
Linux上で開発環境整えるのにカーネルのコードを読めって言うぐらい的外れだと思う。
いや、知識として持っとくのはいいだろうけど、役に立たんだろ。
Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語もオブジェクト指向言語とそこまで違いがあるような気がしない。
純粋な言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。
その無名オブジェクトにもっとあれこれデータや関数詰め込めば、いつの間にか普通にJavaやC#で使うようなクラスのできあがり。
その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。
関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。
上級者はデザインパターンをdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。
デザインパターンはオブジェクト指向言語の欠点を補うための苦肉の策じゃないよ。
関数プログラミングの基礎的なパーツだと思う。
だからちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。
関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。
もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。
けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。
役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。
せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。
ということなんだけど
↑これを見たら、単純に+は遅いって認識の人もけっこういるんじゃないかって不安になってきた。
以前 + が禁止の現場で作業をしたことがあって「+は最適化されますよ」と報告しておいたけど「いままでずっとこうだったから」というよく分からない理由でルールはそのまま。
ほかの人はStringBuilder()なんか使うの面倒だからか、文字列連結はconcat()を使っていて、+を使ったときの記述の簡潔さもStringBuilder()を使ったときのパフォーマンスも失われて悪いとこどりのコードが蔓延してた。
俺みたいに底辺の現場で働いてる人間には「文字列連結に+を使うのはご法度」みたいな常識が広まると、面倒くさいことになってしまう。
余計なお世話を言えば、+とStringBuilder()の使い分けが理解できないレベルのプログラマにはとりあえず「+を使っておけ」って言えばいいんじゃないのかな。
+を使ったばかりに耐えられないくらいパフォーマンスが落ちる局面って少ないだろうし、そういうレベルのプログラマが投入されるプロジェクトなんてそんなにパフォーマンスにシビアじゃないだろうし。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
とりあえず、Androidアプリ作りたいならJavaでいいか？
いいんだな？よーし始めちゃうぞ～
「よくわかるJavascript」
動的言語は使わない。
動的本をすべて捨てる(人の手に渡るような捨て方はしない ちり紙交換がよい)
動的DBは使わない。リレーションのない動的DBは使わない(mongoDBやNoSQL系）
動的オープンを紹介してくるメデイアのステマに気づき騙されない
Silerが勧めてくる技術は独立できない技術だからやらない 関わらない
職務経歴書に黒歴史(PHP Java JavaScript Ruby RoR Html5)を書かない
PHP Java JavaScript Ruby RoR Html5の仕事は請け負わない
C# Objctive-cだけ使う
VisualStudio Xcodeだけ使う
VisualStudio Xcodeを機能をフル活用する
WindowsServerを使う
デザパタを覚える
コミュニケーションはOffice 365 redMine,イラレGit Svnを使う
動的言語をこれ以上広げるな 罪を重ねるな 脆弱性をばら撒くな トラブルを撒くな
セキュリティに問題のある動的言語はどこにいってもトラブルになる
原発のシステムにRuby,RoR,PHP,JavaScriptを使いたいと思うか？Silerはなら提案してくるだろう儲かるから
使えば必ず原発はハックされる
C# ASP.netは2007年頃から海外では大流行だった 一方日本のメディアは盛んにLAMP!LAMP!RoR!RoR!煽っていた
C#（静的言語）は14年前のソースが今でも使うことができる。VisualStudioにはソースを自動バージョンアップ機能があり書き換えてくれる。 コードが負債にならない コンパイル時バグがわかる DLLのバージョンをチェックしてくれる ブレイクポイント リモートデバッグ
動的言語・オープン系は 手作業で直す どこにバグあるか実行しないとわからない 脆弱性が出るたび バージョンアップ、機能追加のたびに修正することになる リファクタが使えない 負債言語
この数字を見て動的言語関係者はびっくりしているだろう。 14年前のPHPソース 使えると思うか？関係者は首を横に振るだろう。時間と人手をかけて改修すれば使えるかもしれない(多くの場合作り直したほうが安上がりという結論になると思うが) 脆弱性や仕様変更がたくさん埋まっているソースだ 修正には手間と時間と予算がかかる
C#なら一瞬で最新の.netフレームワークのバージョンに書き換えてくれる。エラーや警告の表示も一緒に出力されるから手直しが簡単
PHPを捨てたほういい理由
今はRoRのステマが醜くそれに騙されて使ってしまった人がいるが、今後、仕様変更やバグ、脆弱性は出続け、そのたびに全ソースを検索し手動で手直しをしなければならなくなる それは新しいことをやっている時に起こるだろうし、今やっている新しいことが負債に変わる。作れば作るほど負債が増え、前に進むことができなくなる言語 それが動的言語 メンテナンスが常に必要でほっとけばハックされる。保守や改修に人が多く必要で中間業者は儲かるのでメディアや無料育成を通して広めてくる 煽っておいて自己責任の国 日本
静的言語のサーバーサイドで何がいいかというと 自分は C＃ Asp.net(asmx or webApi) Ado.net 接続 & 非接続のDataSet 管理.exeアプリ(C# WinForms)をお勧めする やり方
もうお分かりいただけただろうか？動的言語とはSilerが定期的に仕事を得るために広めたガラクタ言語だったということを この言語をいつまでも高い稼働の保守作業が必要だ。機能追加、言語の仕様変更、脆弱性を修正するのにお金も時間もかかる Silerはパンク屋だったのだ。 メーカー製の静的言語を使えばここまで時間も手間もかからなかった。
これ以上元請けはSilerが言われるがままにガラクタ言語を導入しないほうがいいだろう。技術者はSilerが無料で教育してくれるからといってガラクタ言語を学ぶのはやめたほうがいい。(洗脳されて信者になるな) 特に技術者はこの言語をマスターしたからといって独立はできない。なぜなら、５人以上のプログラマーが働いてやっと出来上がるものがほとんどだ。手間がかかるということは自分が一番よくわかっているはずだ。言語とともに使い捨てられる運命にあるのだ。IT経営者やSilerはその方が都合がいい。こき使ってやめられても独立できないのだから。雇ってはこき使って使い捨てる。まさにIT版のねずみ講 上のしか儲からないようになっている。 それに加えて酷いピンハネ。１００万で売って７割以上搾取 一人送れば７０万円入る世界だ。Silerにとって開発現場は炎上すればするだけよい。言語は脆弱性があればあるほどいい、システムが手間が掛かるなら掛かるほどいい その分人を送り込めるからだ。その辺にいる素人を適当に教育して３年開発の下駄はかせて送り、現場を炎上させて新たに人を送り込んで利益を得ている。
#1 PHPで改修しようにも簡単には改修できなくて、その間にハックされ情報が流出すること結構あるようだ @WikiはPHP
#2 2013年 Javaフレームワーク Strutsのサポートが終了した こういうフレームワークをメデイアで煽っておいて最後は自己責任される。オープン言語はやってはいけない
#3 これはどの業界にも言える事だが、気合い、根性の気合馬鹿から組織を乗っ取られないようにするにはどうすればいいか考えないといけない。コミュニケーションで社員を懐柔し組織を乗っ取った筋肉馬鹿は面倒なことを気合い根性で乗り切ろうするから失敗する。日本はそのしわ寄せがまず下くるから会社が壊れる。脳筋バカは最後まで居残る。（○ーイズ、○ルマー、○ニー、旧日本軍、ジオン軍）タバコ室や残業は特定の社員を仲良くさせるからだめなんだろう 履歴書の項目が少ないのも問題なんだろう 理系か体育会系,血液型,さう脳とか履歴書は書く項目が少なすぎる
#5 仕事の最終目的はコミュニケーションではない コミュニケーションするコストが高いといつのまにかそれが目的に置き換わってしまう事がある。コミュニケーションの得意な奴が本当に優秀な人をさしおえて前にでてくることだってある。Office 365やRedMineイラレSVNなどでコミュニケーションコストを下げることで優秀な人が大声を張り上げなくても力を発揮できる環境を作るべきだ
#6 事務仕事のツール化、自動化、ロボット化、コミュニケーションコストを低くするツールの導入で、声が大きい人や事務だけ得意な人が権力を握ることを防ぐ事が出来る
#9思えばSiler業界は自分たちが儲かりがたいためにガラクタ言語(Java,PHP,RoR,Ruby,Js,Html5,Flash)に人材を誘導しすぎた。出来損ない言語の非効率な生産性と保守作業は社会の進化が遅れ世界とのソフト技術に差がついてしまった。人材も非効率的なスキルしか身に付かなかった。それしかやらせてもらえなかった。
しょーもない言語は社会の発展を止め、技術者を路頭に迷せた。有益な言語を一つだけ覚えさせ、いろんな業界で使い回した方が業界的にも技術者的にも幸せになれたのではないか？
C#はロボットや組み込み機器,医療機器,WEB,スマートフォン,ゲーム,CG デスクトップアプリ,業務用ツール 様々なところで使う事ができるのだ。
特にロボットはMocrosoft Robotics StudioというVisualStudioのロボット版の開発環境が2006年頃から出ており、ロボット産業を発展させることだってできたのだ。(そのころのIT業界はJavaとLampが主)
続き
俺は請負で業務アプリを作成する残念なお仕事をするプログラマーだ。
最近はJavaとかJavaScriptを書いてたりする。
先日PHPのコードを久々に書いたのだがあまりのすごさに手が震えてきた
$hoge = new Hoge(); $hoge.execute();
これが動かない。なぜだ。
メソッドの呼び出しが「->」と気づくのに数分の時間を要した。
"hello world".split(" ");
勿論これは動かない。
現れる警告文。
この関数は PHP 5.3.0 で 非推奨となりました。 この機能を使用しないことを強く推奨します。
ほう。なにを使えと。
。。見当たらない。。。
下のほうの注意に書いてあるなぜここなのか。
なるほど正規表現がいらないなら「explode」を使えとな。
毎回悩む、なぜ爆発なのかと。
あれ？そういえば「explode」ってマルチバイト対応してなかったな。
なら「mb_split」か？
「split」が非推奨なんだから非推奨だろうがヒントはあるだろうし、一応見ておくか。
非推奨じゃない！
非推奨じゃない！
mb_splitは非推奨じゃないんだ！
俺は考えるのをやめた。
「preg_split」にオプションで「UTF8」をつけるのが正解だったような。
俺は考えるのをやめて爆発の呪文を唱えた。
Symfony2はDIをサポートしているからInjectするようにしようか。
たぶんAutowiredくらいあるだろう。
class Service { /** * @var \PDO */ protected $pdo; /** * @param \PDO $pdo * @Inject */ public function setPDO(\PDO $pdo) { $this->pdo = $pdo; } }
・・・・？
俺は震える手を押さえながらそっとパソコンの電源を切った。
遠隔操作事件の議論で、C#ができる・できないを重要視してる人がいて「被告はC#はたいしてできない」→「マルウエアは作成不能」という意見を述べられていますね。
被告の方のスキルがどの程度か知りませんけど、仮にほかの言語でマルウエアを作成できる能力があったら、C#でも普通に作成可能ですよね。実務経験がなくても休日にでも少し勉強するくらいで。
マルウエアを作成可能かどうかの議論が「C#ができるかできないか」の議論にすり替えられていてどうしてこうなっているんだって思います。
で、常日頃感じているのが、言語を複数使えるというのが理解できない人が世の中には相当数いて、もしかするとそちらのほうが多数派なのではないかということ。
プログラマの能力を測るのに「Java歴3年以上」みたいな条件を見るのって普通に行われてますよね。
たとえばPHPを使用するプロジェクトのプログラマを選ぶのに、個人的にはPHP歴5年のヘボプログラマより、PHP経験なしでも他の言語でWeb開発の経験があって優秀なプログラマを採用したほうが生産性が高いと思うんですよ。
何年もPHPをやっていても成長曲線が1年や半年で止まってるようなプログラマなんて、優秀なプログラマならPHPの経験なしでも一瞬で追い抜けます。
でも世の中、PHPの経験がないと他の言語でWebの開発経験があって優秀でも、検討もされないみたな採用基準のところばかりですよね。
それと2chあたりで「同じパラダイムの言語なら複数の言語を使うのは簡単だよ」「言語って二つ目からはそんなに難しくないよね」みたいなことを言うと、猛烈に反論されることがあります。まるで己のアイデンティティを否定でもされたかのように、簡単に複数の言語を使えるってことに反論してきます。
joel on softwareに、ポインタと再帰がプログラミングをできる人とできない人の壁になっているという話がありますけど、これと同じで複数の言語を使えるか使えないかにも壁があるような気がします。
言語の機能を抽象的にとらえて、それぞれの言語の共通点や違いを把握する能力がある人と無い人が世の中にはいて、プログラミングができてもそういう能力に欠けていると、複数の言語を使いこなすってことが想像もできないんじゃないかって推測します。
で、世の中にはそういう人のほうが多数派だから、プログラマの採用とか遠隔操作事件の議論でも特定の言語の使用歴がプログラミングの能力に直結してるかのような前提で議論になってしまっているのではないかと。
「MacはUnix互換」とかMacユーザはいうが、Linuxユーザからするとディストリビューションが違うので正直使いにくい。別に調べりゃ使えるしLinuxユーザというのは黙って調べる人たちなので文句を言わないだけで、好んでMacをUnixのように使おうとは思わない。GUIがクソだが便利なLinuxユーザからすればMacはGUIがすげぇ糞なディストリビューションだ。情報少ないし。
なお、これは他のLinuxについても言えることで、Ubuntu使いからするとRedhat系は使いにくいし、Redhat系からするとUbuntuはコマンドがわからんことが多々あるので若干めんどくさい。もちろん他のディストリビューションも同じ。BSDとかあんまり使いたくない。まぁやりゃできるのだが、めんどくさいを極めた結果としてコマンドライン使ってるのに、調べるのはもっとめんどくさい。あと変なエラーが出ると大変なのでPCライトユーザにはまったくおすすめしない。
最近はWindowは一発ポンで入ることが増えてきたので便利だと思う。Cygwin使うよりはVM使ったほうが楽でねーかと個人的には思うが。PHPなどはXamppがあるのでむしろWindowsのほうが楽。文字コードが面倒だが。
なおLinuxは常に糞めんどくさい。すでに入ってるパッケージのバージョンが古いが、ディストリビューションによっては上げるのに四苦八苦とかふつうにある。サーバー関連のプログラム以外はいまどきWindowsとかMacとかのほうが断然楽だ。
Windowsのコマンドはよくわからんが、最近は情報が多いので特に…あと下手にコマンドいじるよりはフリーウェアを探してくれば良いと思う。
Linuxは慣れてるディストリビューションならCUIだけで十分。慣れてない奴はめんどくさい。
Windowsも良いとは言わないが、不便はない。細めのフォントが好みなのでむしろWindowsのほうが見やすい。
そりゃiOSアプリを作るならXCodeしかないし、XCodeは悪く無いと思うが、C/C++とか書く時は使いにくい。
WindowsアプリつくるならVisualStudioしかないし、最近のVSは使いやすいので特に文句はない。C#も良い言語だと思いますよ。すごくよく考えられてると思うし。
Webアプリケーション系もnetbeansなんかはWindowsのほうが軽い印象があるなぁ。ただC++はnetbeansだと補完機能が弱めになる気がする。まぁそもそもWindows上でMSのライブラリ使わないC++とか書きたくないですね。色々違うし。
LinuxのIDEはEclipse一択みたいな感じになっているが、正直Javaはいいが、それ以外は微妙。と言うか糞重い。netbeansが個人的には好きだが、前述のとおり補完機能がEclipseより弱いかんじがするのであんまり。Rubyはすっげぇ使いやすかった。C++で一番軽いIDEはQtかな。Vim?いうほどいいかね…まぁEmacs派なんですけどね
そりゃiOS開発するならMacしかないだろう。Windowsアプリケーション開発するならWindows機使うしかないのと同じでな！！！
LinuxでGUIのあるアプリケーション作るとか、考えたくないな！つうかGUIつかいたくないからLinux使ってんだよ！
Macは選択肢が少なすぎる。金だせばなんでもできるが、カネがないとストレスが溜まる。あとかねかければかけるほど周辺機器もグレードアップしなきゃいけなくなる感じがするのだが…正直Unix系のマインドに反しすぎていると思う。
あといまおれのMacbookProはバッテリが膨らんできてパッドが使えなくなったんだが、Mac対応のマウスがないのでコピペすらできない。キーボードも純正のやつ使いにくくね？プログラマとしてはHome,Endあたりはキー一個で対応して欲しいですし、Backspaceキーがないのは意味がわかりません。deleteキーって書いてるけどそれBackspaceやん、ほんとのdeleteどこいった！！！とにかくキーボードがひどいのでMac使ってプログラミングしようという意欲がおこらない。むしろ俺がMac嫌いな理由の一番がそれですね！
しらねぇがLinuxで音楽制作しようとする奴はアホだと思う。
が、若干コントラストが強目にでるか？という気がする。
Mac以外のディスプレイを自分で細かくカスタマイズしたほうが実際にあってる場合もあり、なんとも言えない。
ちょちょっといじる素人用フリーウェアが貧弱すぎて辛い。いやらしい成金に札束で顔はたかれているような気持ちになる。
いいわすれたがLinuxでデザインやデジタル現像しようっつうやつはアホだね。Ubuntuならあるのかなぁ…でもさいきんUbuntu重すぎて…
しらん。
MSOfficeは使いやすい。Officeを貶してる奴はだいたいOfficeを使いこなしていない。
LibreOfficeとか一昔前のMSOfficeじゃないですかーLinuxだとそれしか選択しないけど使いたくねぇ…それならGoogleDriveのをつかうわ…一太郎とか悪い冗談はやめていただきたい。
ただ、Latexを使う場合はLinuxは使い良いとおもう。もちろんWindowsならLatex用のエディタあるんですけども！
WindowsとMacで特に違いはないが、あえていうならMacはフリーウェアが少ない。
Linuxをホームユースで使いたがる人がいたら止めたいが、最近はWebだけでも色々できちゃうので、別段問題ない気がしてきた。
9. Macは性能に対してコストパフォーマンスが高い(……かも)
スペック対価格を比較すると、CPUやメモリやらのコストパフォーマンスが悪くない、と思います。
10年前は「Macは高くつく」という印象だったものが、ここ5年で「Macって割安」という印象に変換したと記憶しています。
むしろ使ったらMacって割高…って思うと思うけどなぁ。最近のWindows機は安いしデスクトップなんて価格破壊完全に起こしてるし、使い始めてからもほとんどお金がかからない。情報も多いし。なんか情報が全体的に五年くらい古い感じがしますね。もしかして2009年ごろからいらした方が書いたのでしょうか。
何をもって"無駄"と判断するか、非常に難しい論点ではありますが。
へんてこなアザラシのマスコットがデスクトップを泳ぎ出したり、なんとも言えないモッサリ感の明るさ調整ソフトが突如画面に出現したり。なんて事はありません。
常駐ソフトウェアはWindowsは決して多くないし、あるならメーカプリインストールアプリじゃねぇのっていう。
明るさ調整ソフトってそれはディスプレイのやつだろ？Windowsのせいじゃねぇよ。むしろMacはそういうの調整するときに探すのが大変。いや、あかるさ調整くらいならキーボードでできるけどさ…
常駐ソフト気にするならLinuxが一番管理できると思いますし、LinuxにくらべればMacもWindowsも似たようなもんです。
サーバサイドの通信プログラムなど、OSのシステムコール使いまくり系の、所謂システムプログラミングのうち、電話の交換器とか緊急地震速報のように、処理速度と信頼性が求められる仕様のソフトウェアは、未だにUNIX系(というか実質Linux)にC/C++になってしまうのだろうか。
速さの問題でJavaやPerlがダメとなると、未だにシステムプログラミングはアプリケーションプログラミングよりも高難易度というイメージがある。
かくいう自分の場合、C言語は学生時代の授業でポインタに挫折して以来、仕事で画像処理のプログラム実装でちょっと使ったけど結局よく分からない状態で、急病でリタイヤした人の仕事(C言語で少しだけ作った通信プログラムの引き継ぎ・納品)をムチャ振りされ、泣く泣く取り組んだ経験が半ばトラウマ化している。
だってC言語やっててポインタが分からないとか本当にド素人レベルの初心者が、socket()のノンブロッキングにpipe()にsignal()にselect()無限ループで複数のファイル記述子の監視を非同期通信でfork()もあるよという世界に放り込まれたのだ(当時のLinuxカーネルはpselect()がシステムコール実装されてなかったというオマケ付き)。
K＆Rと「UNIXネットワークプログラミング」片手に涙も枯れた状態で帯状疱疹作りながら挑み、最後はどうにかこうにか元請けが引き取ってくれたけど、共有メモリやマルチスレッドはハイレベル過ぎて手が出なかったのが悔やまれる。
これがC++(当時未経験)なら、Javaで体得したオブジェクト指向で複雑な仕様もかなり楽に出来るかと思ったけど、いざ始まってみたらC言語とLinuxのシステムコールを使いこなすだけで精一杯で、C++は今でも未経験と。
あとmalloc()やfree()とかも全く活用できなかった。懸案だったポインタと構造体は嫌でも覚えたけど。
というか休日遊んでいて、突然それまで分からなかった部分が理解できたのはいいが、次の瞬間「やべ！あのまま本番動かしたら洒落にならん！」という展開になり、休日こっそり会社に忍び込んで必死にソース直したこともあったっけ。
・・・という経験をしているので、いつかまたシステムプログラミングの仕事が振られた時のことを考えて、一応PGで飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術やフレームワークが生み出されていると嬉しいんだけどなーという感じ。
