「C/C++」を含む日記 RSS

はてなキーワード: C/C++とは

2018-10-27

anond:20181027181451

RustはC++代替では?(Javaとは用途が違う)

http://golang.rdy.jp/2017/12/20/go-fact/

Rustは昨年に非同期サポートを標準から切り離しました。事実上システム記述用途に特化していく模様です。 C/C++資産ゼロオーバーヘッドで取り込みつつC/C++利用領域を置き換えていくと思われます

2018-03-16

ちょっと羨ましい

プログラマやってるけど、昔話を聞くに、本当に隔世の感があると思わされる。

だって昔のプログラマ仕事って、入念に机上デバッグされたフローチャートを、ただひたすらCOBOLFortranアセンブラ翻訳して、コーディングシートに書くだけの仕事だったんでしょ?

フローチャートで書ける程度のロジックなんて全然難しくないので、シートを書き終わった時点で事実上プログラムは完成したに等しいと。

あとはパンチしてもらって、テストは大抵一回動かすだけで全部問題なく通って一丁上がりと。

そうなると、これはもう気合と体力の問題って話になる。

そりゃ月残業300とか働くのも決して不可能じゃないし、それだってハイになった勢いでガシガシ書けるだろう。

そうやってカネがっぽり稼いで、日々のモヤモヤは酒タバコ麻雀パチンコ風俗スッキリさせて、そんでまた思いっきり働く。それが男だろ!ってノリだよな。

仕事懇意になってるパンチャーのお姉ちゃんと裏で仲良くなって、そのまま付き合って…なんてのも普通にアリだろう。

昭和は明るい時代だったんだなあと、少し羨ましくなる。


今はもう、あらゆることが複雑になりすぎて、設計だってUMLER図で対処できるかすら怪しくなっている。

言語だってJavaだけじゃなく、SQLやら、HTMLCSSJavaScriptと心得てないと仕事にならない。

そして何より、動かして試して、都度直していかないと分からないことだらけになっている。

プログラマの脳にかかる負荷は昔と比べ物にならない。当然あまりに長時間労働事実上不可能

俺は残業100まで行った所で帯状疱疹が出て、シャワーで腰をさすりながらココらへんが限界と思い知らされた。それが10年前。

勿論今はもっと無理が利かない状況。


でも、残業300可能時代を、色んな会社で現役として駆け抜け出世した幹部オヤジ達に、今のプログラマが抱えているアレやコレやらは、多分理解できない。

それくらい、時代が変わりすぎたのだろう。見えている世界が違いすぎる。

から今の若い奴らを根性無しとして完全に見下しているし、本音では「なんだよ急に辞めやがって使えねーなー」とか「アイツ死にやがった、ざまあwww」と思ってる、人でなしの老害ばっかり。

勿論FortranC/C++Javaみたくスキルを身につけてきた人は例外だけど、本当に例外中の例外でめったにいない。

それで「昔のままのノリじゃ、今の開発は絶対に稼げない」ということに思い至らない。

こんなブラック業界、やっぱり一度潰れたほうがいいんだろうと思わされる。

2018-03-10

anond:20180310222660

もしかして俺と勘違いしてない?

あー、俺のことな

ぐらいしか普段使ってないポンコツプログラマーだよ。

Hello Worldを含めたら、他にもいろいろやったけどもう覚えてないw)

どうせ、みんなもプログラミング言語はせいぜい100個ぐらいしか使ったことがないでしょ?自作プログラミング言語とか、DSLとかないでしょ?

お互いバカ同士、低レベルの争いをするのではなく、切磋琢磨してスーパープログラマーになろうぜ!w

2018-02-19

50代間近、毎月60時間残業しても手取り35万ちょっと。なんか生きるのに

こういうところで、自分の中にある、苦しみや悩みを吐き出す日が

来るとは思っていなかった。

中年を過ぎたオヤジの読みづらい戯れ言だと思われても仕方ない。

からスルーしてくれても問題ない。

仕事IT系システムエンジニアであり、プログラマーでもある。

経験した言語C/C++SQLPL/SQLPHPJS。あとCOBOLは少しはできる。

PHPJSフレームワークはよく知らない。仕事で使う機会が皆無だったからだ。

もちろんシステム設計問題ない。

最近本業タスクが無くなってしまうと、PL/SQL言語類似する

DELPHIを独学している。そのためにスターター版をインストールした。

もちろん、発注元には承認を得た上で残業させてもらっており、その点は感謝している。

ここからが本題。

発注元とは派遣契約。単金がいくらかも知っているから、どのくらいの

金額となるかもわかっている。問題なのは、その間にある会社

その会社で4割以上、ぼったくられている。。

社員扱いにしていると言うが、実際はアルバイトと同じで

有給休暇なんて存在しない。休めば単純に差し引かれるだけ。

から健保負担人間ドックや定期健康診断なんか行けない。

住民税はぼったくられた中には含まれておらず自腹だ。

両親は介護老人ホーム借家暮らしているが、

両親自身年金だけでは暮らせるわけも、毎月15万の仕送りをしている。

私自身はその会社一方的に決めた法人契約アパート暮らしている。

法人契約とは名ばかりで住宅補助は一切無く全額ぼったくられ、

水道光熱費も全額負担

生計が苦しいから、もう少し給与を上げて欲しいと2度、3度と

お願いしたが、40時間残業すれば手取り40万を超えるから大丈夫だと

すべて笑って誤魔化され一蹴された。

年齢からし転職できないと思われている。実際に、自分でも

この年齢で転職は無理だろうと感じている。

できるだけ支出を減らすために、1日1.5食まで減らして暖房も使わず

可能な限り無駄を減らしているが、それでも生保定期積金も難しくなっている。

預金は減る一方で増える見込みはない。そろそろ底が見え始めてきた

これを書いていて思ったのが、ひとつ救いだと思えたのは独身で良かったと。

もし結婚していたらカミさん申し訳ない。

カミさんが協力的な人だったとしても心苦しいし、顔を合わせづらい。

そんな状態が続いたから、なんか生きるのに疲れてきた。

さら支出を減らす努力生保定期積金の解約が必要になっている。

こんな生き方しかできないなら、生きるって何だろうと考える日々を過ごしている。

2017-06-07

anond:20170513175715

残酷だが「職業訓練プログラミング」という人たちはこの業界はあきらめた方があなたのためにとって良い。

そのような人の上司になったことが何度もあるが成功した人を見たことがない。

はいものの、私も35歳から異業種転職にてアプリ屋になったが、転職直前の段階でC/C++/Pascal(Delphi)/html/js/SQL が書けた。

10代前半から8bitCPU(特に名を伏せる)のマシン語(ハンドアセンブル、つまり16進数直書き)でプログラムした経験がある。(もちろんBASICもある)

8bit時代ならメモリー増設設計実装(ハードウエア)ができた。

一応そのような状況ではあってもプロに知り合いもなく心配だったので、

(当時)第二種情報処理技術者試験に3週間の勉強(1.0/日程度)で

一発合格しなければ転職しないというような目標もたててクリアした。

技術的には 0 スタートではかったからこそ転職にも成功できたと思っている。

おっさん技術知識経験ほぼ 0 スタートはきついでしょ。

おっさんなんだからこそ無駄時間を使わないでほしい。

自分も一流でもなんでもないくせに上から目線で自慢話みたいのしてごめんなさい。

あなたに向いた仕事はきっと他にある。がんばれおっさん

2017-04-11

オライリーに出てくるフレンズ

参考:http://www.oreilly.com/animals.csp

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2016-07-05

スマホネイティブ開発とハイブリッド開発、どっちが

はてなにはエンジニアクラスタが多いと聞いたので相談してみる。

iPhoneAndroidアプリを開発することになったんだけど、ぶっちゃけハイブリッド開発ってどうなん?

Ionicっていうフレームワークの最新(まだベータ)がいいよとは聞いたのだけど。

SwiftなりJavaなりでネイティブ開発できる人なら、別にハイブリッド開発なんて手を付けないほうがいいと思いますか?

当方SwiftJavaのほか、PHPだったりC/C++あたりのプログラミングの基本は身についてる初級者〜中級者の間くらいのレベルです。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。

かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日リリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。

今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。

Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日オラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」(The Network is the Computer)というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。

当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。

1996年の時点にこんな言語が登場したのですから革新的でした。

いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。

プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロードテンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

Wikipediaからピックアップすると1.1での大きな機能追加は

といったところです。当初よりJavaの内部文字コードUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ!というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。

なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。

当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。

JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。

Microsoft Visual J++ もこの時代ですよ。

Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。

当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

strictfpキーワード浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。

リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。

1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。

初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。

JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。

あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。

Microsoft 離反

Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつMicrosoftだったわけですね。

Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの!と喧嘩になったわけです。当時のMicrosoftブラウザまわりでも独自拡張がやりたい放題、標準規格?なにそれ美味しいの?みたいなスタンスをあちこちで見せていたものです。

結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。

JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。

Java EE

Java SE とは別にこの時代に Java EEリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。

2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的ユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。

企業で用いられる社内システムにもServletは多く採用されました。

理由はいろいろ挙げれると思うのですが

というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャある意味では便利で簡単でした。

もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を2001年に戻しましょう。

Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。

Java Appletブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。

Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。

端的に言えば入力値が数字かどうか?みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。

また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。

こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい!という要望があったわけです。Webシステム使いにくい!という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。

Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。

RIAの代表とされるのは

あたりです。三つ巴の戦い、どこに軍配が上がるのか!?と注目されましたが、勝利したのはHTML / JavaScriptでした。

Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。

RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。

しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。

Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。

言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。

その後

Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。

Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日オラクル吸収合併されました。

Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。

やや戻って2007年Androidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。

Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。

このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-01-21

http://anond.hatelabo.jp/20160121160933

ポインタ再帰がすんなり理解できたなら、プログラミング素養があるよ

http://local.joelonsoftware.com/wiki/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

伝統的に大学コンピュータサイエンスカリキュラムで教えられているもので、多くの人がうまく理解できないものが2つあった: ポインタ再帰だ。



C/C++使っててポインタ使わないってどういうことだよって思うけど

ダイナミックにメモリ確保できない/する必要無い環境だと、必要領域グローバルな配列宣言しておいて、プログラム全体で使い回してたりするんだってさ。

そんな環境だと、ポインタからないCプログラマもいるんだと。

http://anond.hatelabo.jp/20160121155603

プログラム苦手で嫌いだけど再帰だのポインタだのくらいは使うわ。必要ならな。

(つうかC/C++使っててポインタ使わないってどういうことだよって思うけど)

プログラミングができるかどうかってのはそんなもんを使ってるかどうかで判断できるもんじゃねーと思うわ。

再帰メモ化しますとか言われて「うっひょーカッコいい〜!!!」って思うか「うわっめんどくせえし興味ねえ」って思うかとかの差だと思うわ。

2015-01-29

初めてじゃなかったCの思い出

今やプログラミングといえば、Webなどで使われるような高水スクリプト言語中心のアプリケーションプログラミングが主流だ。

そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である

そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。


今も昔も、基本的に難しい仕事無茶振りから始まるものだ。

少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。

大学で初めて触ったC言語しかポインタからないで止まっているような奴に、電文の再配信プログラムを任せたのだから


客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。

そうなるとC/C++くらいしか事実上選択肢がない。

このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。

勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。

あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。

その時点で相当ヤバいである


コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなもの絶対必要である

その時のルールは「gccオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。

というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様コンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しか言語仕様以外の環境依存要素が山積していると来たもんだ。

そんな言語システムコールだらけのコードかつ複数ファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかマルチプロセスシグナルもあるよ!とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。

仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。

後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。

そこまで凄い良書なのになんで絶版になったんだか。


いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。

シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか!と途方に暮れたこともあった。

そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。

結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分仕事ぶりには全く満足していない。

無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッドmalloc()、可変長引数は遂に習得できなかった。

こういうプログラムって、どうやったら正しく動かせるんだろ。


このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が

Cはとても高効率ですし、マシンリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルリソース管理(たとえばメモリ管理)を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります今日マシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシン時間を少し非効率に使っても、あなた時間をずっと効率的に使う言語を使うほうが賢明でしょう。

本物のプログラマアプリケーションプログラムなど書かず、まっさら金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。

と言っていたことは正真正銘の事実であると痛感した。

あと、あれほど苦手だったポインタについても、「ポインタ理解できないと永久にC初心者」というのを嫌でも理解した。

あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ


・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。

それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分

配列ポインタ構造しか使わないで済むなんて、なんて楽な仕事なんだ!」と左うちわのんびり過ごし、しかも高評価をいただいて帰ってこれた。

実は今までの案件で一番幸福感が最高だったのは内緒である

2014-06-04

何が言いたいか?というと

Undefinedable<bool> であって

false != undefined

というのはすぐにわかるが

Nullable<bool> であって

false != NULL

というのは その言語固有の問題であって、言語仕様トリッキー

 

C/C++などの言語ではfalse==NULLだし。 他の言語を考えて false!==NULLかもしれないが、false!=NULLがどうなるかは予測できん。

falseとNULLを比較するのは定義曖昧すぎて推奨できないよ。

2014-03-22

http://anond.hatelabo.jp/20140322140822

Linux視点追加しつつ突っ込んだ。

MacUnix互換

MacUnix互換」とかMacユーザはいうが、Linuxユーザからするとディストリビューションが違うので正直使いにくい。別に調べりゃ使えるしLinuxユーザというのは黙って調べる人たちなので文句を言わないだけで、好んでMacUnixのように使おうとは思わない。GUIがクソだが便利なLinuxユーザからすればMacGUIがすげぇ糞なディストリビューションだ。情報少ないし。

なお、これは他のLinuxについても言えることで、Ubuntu使いからするとRedhat系は使いにくいし、RedhatからするとUbuntuコマンドわからんことが多々あるので若干めんどくさい。もちろん他のディストリビューションも同じ。BSDとかあんまり使いたくない。まぁやりゃできるのだが、めんどくさいを極めた結果としてコマンドライン使ってるのに、調べるのはもっとめんどくさい。あと変なエラーが出ると大変なのでPCライトユーザにはまったくおすすめしない。

プラグラム開発環境の導入

最近はWindowは一発ポンで入ることが増えてきたので便利だと思う。Cygwin使うよりはVM使ったほうが楽でねーかと個人的には思うが。PHPなどはXamppがあるのでむしろWindowsのほうが楽。文字コードが面倒だが。

なおLinuxは常に糞めんどくさい。すでに入ってるパッケージバージョンが古いが、ディストリビューションによっては上げるのに四苦八苦とかふつうにある。サーバー関連のプログラム以外はいまどきWindowsとかMacとかのほうが断然楽だ。

シェル環境

Windowsコマンドはよくわからんが、最近情報が多いので特に…あと下手にコマンドいじるよりはフリーウェアを探してくれば良いと思う。

Macはむしろシェル使うほうがめんどい(前述のとおり)

Linuxは慣れてるディストリビューションならCUIだけで十分。慣れてない奴はめんどくさい。

フォント

正直Macフォントは目が疲れる。画面のせいかね?

Windowsも良いとは言わないが、不便はない。細めのフォントが好みなのでむしろWindowsのほうが見やすい。

Linuxは標準のやつは好きだけどもうちょっと細くていい。

IDE

そりゃiOSアプリを作るならXCodeしかないし、XCodeは悪く無いと思うが、C/C++とか書く時は使いにくい。

WindowsアプリつくるならVisualStudioしかないし、最近のVSは使いやすいので特に文句はない。C#も良い言語だと思いますよ。すごくよく考えられてると思うし。

Webアプリケーション系もnetbeansなんかはWindowsのほうが軽い印象があるなぁ。ただC++netbeansだと補完機能が弱めになる気がする。まぁそもそもWindows上でMSライブラリ使わないC++とか書きたくないですね。色々違うし。

LinuxIDEEclipse一択みたいな感じになっているが、正直Javaはいいが、それ以外は微妙。と言うか糞重い。netbeansが個人的には好きだが、前述のとおり補完機能Eclipseより弱いかんじがするのであんまりRubyはすっげぇ使いやすかった。C++で一番軽いIDEQtかな。Vim?いうほどいいかね…まぁEmacs派なんですけどね

iOS開発

そりゃiOS開発するならMacしかないだろう。Windowsアプリケーション開発するならWindows機使うしかないのと同じでな!!!

LinuxGUIのあるアプリケーション作るとか、考えたくないな!つうかGUIかいたくないからLinux使ってんだよ!

開発マシン選択肢

Mac選択肢が少なすぎる。金だせばなんでもできるが、カネがないとストレスが溜まる。あとかねかければかけるほど周辺機器もグレードアップしなきゃいけなくなる感じがするのだが…正直Unix系のマインドに反しすぎていると思う。

あといまおれのMacbookProはバッテリが膨らんできてパッドが使えなくなったんだが、Mac対応マウスがないのでコピペすらできない。キーボード純正のやつ使いにくくね?プログラマとしてはHome,Endあたりはキー一個で対応して欲しいですし、Backspaceキーがないのは意味がわかりません。deleteキーって書いてるけどそれBackspaceやん、ほんとのdeleteどこいった!!!とにかくキーボードがひどいのでMac使ってプログラミングしようという意欲がおこらない。むしろ俺がMac嫌いな理由の一番がそれですね!

Linuxはしょぼい機器でも開発可能なのでよいと思います

音楽制作

しらねぇがLinux音楽制作しようとする奴はアホだと思う。

デザインアート制作

ま、正直Macディスプレイはいいと思う。

が、若干コントラストが強目にでるか?という気がする。

Mac以外のディスプレイ自分で細かくカスタマイズしたほうが実際にあってる場合もあり、なんとも言えない。

ちょちょっといじる素人フリーウェアが貧弱すぎて辛い。いやらしい成金札束で顔はたかれているような気持ちになる。

いいわすれたがLinuxデザインデジタル現像しようっつうやつはアホだね。Ubuntuならあるのかなぁ…でもさいきんUbuntu重すぎて…

ゲーム用途

しらん。

ビジネスユース

MSOfficeは使いやすい。Officeを貶してる奴はだいたいOfficeを使いこなしていない。

LibreOfficeとか一昔前のMSOfficeじゃないですかーLinuxだとそれしか選択しないけど使いたくねぇ…それならGoogleDriveのをつかうわ…一太郎とか悪い冗談はやめていただきたい。

ただ、Latexを使う場合Linuxは使い良いとおもう。もちろんWindowsならLatex用のエディタあるんですけども!

ホームユース

WindowsMac特に違いはないが、あえていうならMacフリーウェアが少ない。

Linuxをホームユースで使いたがる人がいたら止めたいが、最近Webだけでも色々できちゃうので、別段問題ない気がしてきた。

その他

9. Macは性能に対してコストパフォーマンスが高い(……かも)

スペック価格比較すると、CPUメモリやらのコストパフォーマンスが悪くない、と思います

10年前は「Macは高くつく」という印象だったものが、ここ5年で「Macって割安」という印象に変換したと記憶しています

10年前に比べて自作メリットが薄れたから、そのように感じるんですかね。

しろ使ったらMacって割高…って思うと思うけどなぁ。最近Windows機は安いしデスクトップなんて価格破壊完全に起こしてるし、使い始めてからほとんどお金がかからない。情報も多いし。なんか情報が全体的に五年くらい古い感じがしますね。もしかして2009年ごろからいらした方が書いたのでしょうか。

12. Macには無駄な常駐ソフトウェアが少ない

何をもって"無駄"と判断するか、非常に難しい論点ではありますが。

へんてこなアザラシマスコットデスクトップを泳ぎ出したり、なんとも言えないモッサリ感の明るさ調整ソフトが突如画面に出現したり。なんて事はありません。

いったいいつのWindowsの話をしているのか…

常駐ソフトウェアWindowsは決して多くないし、あるならメーカプリインストールアプリじゃねぇのっていう。

明るさ調整ソフトってそれはディスプレイのやつだろ?Windowsのせいじゃねぇよ。むしろMacはそういうの調整するときに探すのが大変。いや、あかるさ調整くらいならキーボードでできるけどさ…

常駐ソフト気にするならLinuxが一番管理できると思いますし、LinuxにくらべればMacWindowsも似たようなもんです。

2014-03-18

システムプログラミングは未だに難しいのだろうか

サーバサイドの通信プログラムなど、OSシステムコール使いまくり系の、所謂システムプログラミングのうち、電話の交換器とか緊急地震速報のように、処理速度と信頼性が求められる仕様ソフトウェアは、未だにUNIX系(というか実質Linux)にC/C++になってしまうのだろうか。

速さの問題でJavaPerlダメとなると、未だにシステムプログラミングはアプリケーションプログラミングよりも高難易度というイメージがある。


かくいう自分場合C言語学生時代の授業でポインタ挫折して以来、仕事画像処理プログラム実装でちょっと使ったけど結局よく分からない状態で、急病でリタイヤした人の仕事(C言語で少しだけ作った通信プログラムの引き継ぎ・納品)をムチャ振りされ、泣く泣く取り組んだ経験が半ばトラウマ化している。

だってC言語やっててポインタが分からないとか本当にド素人レベル初心者が、socket()のノンブロッキングにpipe()にsignal()にselect()無限ループで複数のファイル記述子の監視を非同期通信でfork()もあるよという世界に放り込まれたのだ(当時のLinuxカーネルはpselect()がシステムコール実装されてなかったというオマケ付き)。

K&Rと「UNIXネットワークプログラミング」片手に涙も枯れた状態で帯状疱疹作りながら挑み、最後はどうにかこうにか元請けが引き取ってくれたけど、共有メモリマルチスレッドハイレベル過ぎて手が出なかったのが悔やまれる。

これがC++(当時未経験)なら、Javaで体得したオブジェクト指向で複雑な仕様もかなり楽に出来るかと思ったけど、いざ始まってみたらC言語Linuxシステムコールを使いこなすだけで精一杯で、C++は今でも未経験と。

あとmalloc()やfree()とかも全く活用できなかった。懸案だったポインタ構造体は嫌でも覚えたけど。

というか休日遊んでいて、突然それまで分からなかった部分が理解できたのはいいが、次の瞬間「やべ!あのまま本番動かしたら洒落にならん!」という展開になり、休日こっそり会社に忍び込んで必死ソース直したこともあったっけ。

あれからもう10年近く経つ。


・・・という経験をしているので、いつかまたシステムプログラミングの仕事が振られた時のことを考えて、一応PGで飯食ってる仕事人として、何か準備しておきたいと思っているのだが、できればもう少し楽になる技術フレームワークが生み出されていると嬉しいんだけどなーという感じ。

2013-11-26

バグテスト残業

ストライクswitch文 これはゾンビプロセスですか? キル-9キル

シューウデンタイム 最終納期彼女 テイルズ・オブ・エンジニア

VeriSignのばら ガンプラC++ビルダーズ IT土方まさかデスマ

ブラックラー刃牙 ロード・ストア戦記 れじ☆すた 謎の変数X

クレームモア 売るSEやつら フリージングサーバーが)

コード・アサート・オンライン(本番)環境 エクセル・ワード

文字化け物語 進捗の巨人 gdgd進捗s 11人月いる!

シスターprintf 新製品エヴァンジェリスト 鉄腕atof 評価

コード規約~反逆のリリース コードゼロ 大ピンチコード コード:ブレイカー

OCaml香辛料 あらいぐまHaskell ヒカルGo ななかC/C++ コボラ

あした納める製品仕様を僕達はまだ知らない。 LOTUS;NOTES

継承ダイモス 鋼の連勤術師 コンパイラ 機動戦士ガンダム0080 パケットの中の戦争

廻るpingDRAM とんでboolean ゼロ除算の使い魔 THEビッグオー記法

頭文字D言語 吸血鬼ハンターD言語 D.言語-man Apache野球

ニンゲツスレイヤー プロジェクト炎上 業界は衰退しました

2013-06-18

C++に大きく劣らない速度がある静的型付け言語で、

できれば型推論があって、

D言語くらいの明解言語仕様があって、

pythonのnumpyやscipy並のライブラリがあって、

ネイティブC/C++との接続が簡単な言語が欲しいです。

ないですか?

2013-05-14

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき、女はどう答えたらいいの?

あ、まず前提として、

貴女プログラミング大好き男を夢中にさせることが、

はたして貴女幸福にするかどうか、それはまた別問題だけれど。

はいえ、プログラミング大好き男たちは玉石混交ながら、

IT系の超かしこい男なども多く、

多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこ学生まぁこれは有望株)か研究者系なんか、

あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます(キリッ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、

したがって、釣り師たる女たちにとっては、

なかなかあなどれない釣り場です。

では、プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女は、どう答えれば理想的でしょう?

まず最初に、その男COBOLのようなタイプレガシーコード

あとはC/C++、そして(TechEdに参加するほどではないけれど)VisualBasicが大好きな、

そんなタイプ場合は、

貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、

「わたしが、仕様書を作ってあげる♪」

これこそまさに必殺の答えです。

そこでプログラミング大好き男が、えへへ、とやにさがったならば、

貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを

ひそかに練習しておきましょう。これで成功まちがいなしです。

しかし、ここでは、もう少しハイブロウな(?)いわゆるプログラミング好きの男の

落とし方をお伝えしましょう。

この場合貴女は、こう答えましょう、

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

もしも貴女がそう答えたならば、

その瞬間、プログラミング大好き男の目はきらりと輝き、

かれの貴女への恋心は、

20%増量になるでしょう。

なぜって、Scalaは、

ちょっぴりお洒落Ruby風味に記述できて、

Maybeモナド差し込んで、

コンパイルは遅いながらも、そこがまた

ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。

しか関数型言語としての不変変数・不変Listを実装して

質高くふるまっていて、なおかつ、

JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド型推論を実装した功績もあって。

したがってScalaこそは、

本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、

インタプリタ言語大好きな綺麗系OLと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、

この世界で唯一(いいえ、JVM系列のJRubyClojure と並んで唯三)遭遇しうる場所です。


では、参考までに、危険な回答を挙げておきましょう。

プログラミング大好き男に「どの言語が好き?」と訊ねられたとき

貴女がこう答えたとしましょう、

MicrosoftVisual Basic for Applicationが好き♪ 週3回は Excelコーディングするの。」

その瞬間、プログラミング大好き男の貴女への恋心は消えます、

なるほどMicrosoftは、世界最大のOS供給メーカー

特にOfficeは平凡ながら、ま、無難にまとめてあるものの、

しかし、「新UIのリボンUI!」「メトロUI対応!」とかなんとか無意味な自慢を吹聴し、

VBAはさらプログラミングについての謬見を撒き散らした罪がありますからプログラミング大好き男にとっては天敵なんです。

ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど

社内SESIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。

また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに7件あるよ♪」

と答えたとしても、同様の効果をもたらすでしょう、

なぜって、PHPは、1990年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、

しかし2000年代うそうからセキュリティ関係の問題で転落し、

いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。

(注1)

またもしもたとえあなたプログラミング言語が大好きで、

「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、

最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」

と、答えたとしたらどうでしょう

なるほど、貴女の趣味は高く、

しか.NET Frameworkは、C# が cool であるのみならず、

.NET Framework上で動く F# や IronPythonIronRubyマネーJScriptも最高においしいんですけれど、

しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、

(なんだよ、MS信者な女だな、カネかかりそう)って。

(注2)

貴女が、プログラミングが大好きで、言語の名を挙げるにしても、

たとえば、JavaScript(node.js)ならば安心でしょう、

なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、

貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたプログラミング言語おた宣言をしているとは受け取られないでしょう。

しろへぇ。ちゃんとprototypeは使ってる?」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。

男は嬉々として、30個くらいのnode.jsフレームワークを教えてくれることでしょう。(まぁどれもどれで帯に短し襷に長しなんですが)

あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。

しかし、たとえば、世界が(つーか竹内先生ポール・グレアムが)誇る超絶関数型言語の名作、Common Lispにせよ、

selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、

バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすRubyにせよ、

まったく読めない$_だらけで頭悪い仕様リセットしてPerl6にする(そしてまた全く読めない)Perlにせよ、

気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語ひまわりなでしこにせよ、

基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、

そういう言語名前をいきなり挙げるのは、ちょっぴり微妙。

ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクトオイラーの問題もうほとんどHaskellで、解いちゃった♪」

と答えたならば、どうでしょう

これはかなり博打な答え方で、

なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、

あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、

へぇ、やっぱりHaskellなら大抵の問題は4行以内くらいで解いちゃった?」とか言いながら

鼻の下がだら~んと伸びちゃう可能性もあるにはありますが、

しかし、逆に、(なんだよ、この女、プログラミングおたくかよ)とおもわれて、どん引きされる可能性もまた大です、

なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから

しかも、この答えには、もうひとつ問題があって、

男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、

もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、

そこにはもはや、男が貴女圏論モナド教育する余地がまったく残されていません、

したがって貴女のその答えは、

プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。

ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが

しかし、ああ見せて、プログラマープログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数名前一つにも気を使い、女と自分の将来に夢を持っています、

貴女の答え方ひとつで、プログラマー貴女への夢は大きくふくらみもすれば、

一瞬で、しぼんでしまいもするでしょう。


では、スキットを繰り返しましょう。

「わたしは、JVM上のScalaが好き。

型推論もあるしラムダ式クロージャスクリプト言語みたいに書けるの、豊富組み込みのコレクションメソッドはいつも便利だし、

XMLリテラルCaseクラスによるパターンマッチもTraitベースMixi-inも、大好き♪」

そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、

貴女はこう重ねましょう、

それからね、いま、わたしが使ってみたいWebアーキテクチャは、

Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。

あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」

これでもう完璧です。

PlayFrameworkと、Play(遊ぶ・じゃれる)のダブルミーニングでかれの股間も刺激しちゃえます。

そうなったらこっちのもの

デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて(注3)、

github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね!ボタンがムネのところにあるTシャツ、 あるいは初音ミク(ないし彼のお気に入りアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど)のコスプレを着てゆきましょう。

その日からプログラミング大好き男は貴女の虜になるでしょう。

では、釣り師としての貴女の、愛の幸運幸福をお祈りします!

注1:

(と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった)

(あと、マジで機能とかTwitter連携とか診断メーカー的なのでもPHPで7つも作ってる女子居たら付き合いたい)

注2:

もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。

注3:

プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。

半数くらいのプログラマーしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ(ただしキャラ絵のは除く)とか、

過度でないていどにフリルがついたものオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう(だってそれはコンパイルエラーときの色だ)ので、薄ピンクホワイト、薄ブルー、せめて黒(に差し色でピンクとか)あたりに留めたい。

補記:

 元ネタhttp://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/

補記2:

  「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。

補記3:

 言うまでも無いけど、ネタです。 

 また、COBOLとVB、C++ではまったくもって難易度が違うことも分かっています。後者になるほど圧倒的に難しい。

2013-03-28

http://anond.hatelabo.jp/20130328003550

そもそも、よくよくLinkedListクラスインターフェースを眺めてみると、これは連結リストノード表現するクラスではなく、連結リストのもの表現するクラスのようですね。こんなものをいくらネストしたところで多次元配列構造しか作ることができないのは自明でした。現段階では、元記事の文章は不適切であると言わざるを得ません。

ところで、Lispの真似事をC/C++でさせたいのであれば、タプルを定義するのが先だと思いますが、いずれにしても教育カリキュラム人材の選別過程でこのようなコードを組ませる方針は私はあまり感心しません。あれは一種のハックであって、木構造アルゴリズムコード表現する際に必須の、本質的概念ではないからです。仮に知らなくとも、それは「その人が育ってきた文化が違う」だけの話です。例えばB木を実装するにもRadix Treeの実装にしても知らないままで全く困らないでしょう。

ほかにも、計算量の評価に触れていないなど、気がかりな点はありますが、元増田からコメントもないようですので、ひとまずこのへんで。

2013-03-03

お前らの言う大規模開発ってなんだよ。

型論争の一部。

動的型陣営と静的型陣営がそれぞれ大規模開発に向いてるとか向いてないとか言うけど、「大規模開発」って何よ?って話。

自分としていくらかのパターンがおもいつくし、それぞれ質的に異なるからごっちゃにしても話が混乱するだけだ。

お前らの言う大規模開発ってどれだよ?あともちろんこれ以外にもあれば募集。

  • 人的な大規模開発
  • 量的な大規模開発
  • データ量的な大規模開発

人的な大規模開発

ITゼネコンみたいな連中が行う、何万人月というコストをかけて行う開発。失敗した特許庁の開発みたいなやつだ。典型的にはワンオフ品なので、かけたコストのわりに品質は低い。fizzbuzzも書けない人すら1人月と数えられるし、そういう人が生息するのはここである2013年現在では多分Java(かたまにScalaなど)で開発される。末端の人には自分たちの担当領域外の仕様をどうこうする権利が基本的にはない。

量的な大規模開発

OSカーネルのみの狭義のOSではなくパッケージとしての広義のOS全体)とか、あるいはモダンブラウザみたいな、膨大な機能セットをもち、様々な環境ロバストに動く必要がある開発。膨大な機能セットの中には、膨大な後方互換のための機能(例えばブラウザであればクソみたいなレガシーHTMLでもなんとなく見せてやるような機能)や、ありとあらゆるハードウェア言語などの細かな実行環境の組み合わせで動作するための抽象化および各環境のための固有の機能を含む。オープンソース形態で開発されることもよくあり、2013年においては多分C/C++で開発される。自分たちで仕様コントロールする権利があったりなかったりする。

データ量的な大規模開発

1日のPVが億オーダー以上になるようなWebサービスなど。昨今だと1日にGバイト〜Tバイトにもなるデータを解析できるシステムもセットになってることが多い。サーバの1台や2台がハードウェア的な故障してもロバストに動き続けるための機能や、そのときリカバリが容易であること、壊れた分や単なる新規追加ののサーバの補充が容易であること、みたいや機能および設計上の工夫が求められる。人的な大規模開発や量的な大規模開発と比べると比較的少人数(数人〜数百人。数千人になるのは数えるほど)で開発される。2013年においても様々な言語で開発されていて決定打はない。自分たちで仕様をある程度コントロールする権利がある。

haskell はどの大規模開発に向くか?

例えばこの方が、Haskellは大規模開発に向いていると主張されているが、おそらく人的な大規模開発には向かない。これは2013年においてHaskellを使うユーザがそれほど多くないから、というのも大きな理由だがそれだけではない。Haskell学習コストが低いことを目指して作られた言語ではないことも極めて本質的かつ決定的な理由の一つである。(自分の思う学習コストが低いことを目指して作られた言語とは例えばJavaPHPだ。)fizzbuzzを書けない人をHaskellを書けるまでに教育するのは、どうしたらいいのだろう?

Haskellが量的な大規模開発に向いているかどうかは(自分無知により)よく分からない。典型的には量的な大規模開発を実現するためには、そのソフトウェアWindowsとか各種ブラウザ並に多くの計算機上で稼働することが必須だ。そうでないと膨大な開発コストがペイできない。オープンソース的に貢献を募るとしても、量的に巨大なソフトウェアに貢献する人を一定以上集めるには、それなりのユーザベース(単に使うだけの人も含めて)が必要であるHaskellの実行環境というのは全然枯れていないが、10年前のハードウェアOSを未だに使っている人の計算機上でもちゃんと動くのだろうか?HaskellってVMで動くんだっけ?ネイティブコードを吐くんだっけ?

2013-02-28

ついに顕在化しはじめた「Perlリスク

英語圏ではかなり前からPerlで開発し続けることのリスクについて語られていたが、いよいよ具体的な弊害が出て来ているようなので、かいつまんでメモ日本でもそう遠くない未来だと思う。

若手エンジニアの不足

Objective-Cのように需要が逼迫しているのに人材供給が増えず需給ミスマッチが起っているわけでは無く、需要供給も減るという状況下でわずかだが需要が上回っているとう性質の悪い状況がPerlに起きている。特に深刻なのは安価な若手エンジニア採用絶望的に難しいという現実だ。Rubyが台頭して数年経ちPythonメインストリームの先頭を突っ走る2013年において新しくPerl勉強しようとする若者はよほどの物好きしかいない。30~40歳Perlエンジニアを雇うのはそれほど難しく無いだろうがコストがかかる。安価20代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にPerlを新たに学ぶ若者絶滅寸前だ。

とても優秀な若者雇用できるチャンスが巡って来た。採用担当者はこう尋ねる。「Perlは習得していますか?」「もちろんC/C++/Pythonはお手の物です。Javaもある程度可能です」「もう一度伺いますPerlは習得していますか?」「申し訳ございません 未習得です」

悲劇だ。

イノベーションの枯渇

もう何年もPerl界隈で新しいモノが生まれたと言う話を聞かない。こんな事を言えばPerlハッカー激怒するかもしれないが、しか現実RubyPythonJavaに比べればこの10年の間にPerlから生まれたものは微々たるものだ。何かしらのライブラリにしてもwebフレームワークにしても、ハッカーが新しいモノを試す土俵はいつもPythonRubyJavaが選ばれて来た(もちろんC/C++もね)。

もはや彼らがPerlを選ぶ理由はただ一つ「今Perlで開発しているから仕方なく」

最低の理由ではないだろうか。

10年前にPerlで開発していた企業最先端を走っていた。迅速に自らのアイディアを具現化するツールとしてPerlは最適だった。それが今やどうだろう。自分たちの書いたコード保守し続けなければいけないという理由「のみ」でPerlを使い続けている。他に理由など無い。Perlで開発する理由は自分たちの過去仕事保守しなければならないという理由のみだ。

控えめに言っても、そういう企業未来は無いと思う。過去とは決別し、10年後の自分たちにとって最適な選択をすべきだ。今すぐにだ。本当に手遅れになる前に。

2013-02-05

Perlそんなにダメかなあ

言語なんてツールの一つに過ぎないし、ツールなんて適材適所という前提で書いてみる。


PerlC言語Javaとともに、自分にとっては原点とも言うべき言語で、今は全く使ってないけど、昔はとてもお世話になった。

今更書くまでもなく文字列処理やハッシュが強力で、あんな便利なものはないという感じ。

少なくともPerlのないLinux/UNIX環境なんて死ぬほど使いにくいだろう。というか実質不可欠だろう。

書きやすいけど読みにくいのが玉に瑕で、間違っても最初に覚える言語ではないけど(書き散らかすクセがつくので)。


でもPerlは、C/C++バリバリ古参プログラマでは嫌っている人が結構多い。なんでかなあ。

最近ではPHPPythonなど、Perl以外のLLから微妙な感じで見られている。

確かにCでも文字列処理は可能だけど、Perlに比べたら機能的にとても貧弱だし面倒。だからちょっとした作業なら間違い無くPerlのが楽。

PHPWeb方面ではPerlより手軽だし、Pythonシンプルかつ見た目もスッキリ初心者には一押しなんだけど、それでもPerlの書きやすさにはまだまだ及ばないと感じる。


というわけでC同様、今でも決して色褪せないし、これからもあって欲しい言語なのだが。

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