Printable is bad. 曰く、

MicrosoftがWindows公式ブログにて、Visual Basic 6（VB6）のランタイムがWindows 10でもサポートされることを明らかにした。

VB6は今から約17年前の1998年にリリースされた開発ツールであり、.NETではない「旧来型VisualBasic」の最後のバージョンである。開発ツール自体のサポートはとっくに終了しているが、経験の少ないプログラマでも短時間で開発を行うことが可能なシンプルな構造であることから、未だに根強い人気がある。

約3年前に、MSDN MagazineのコラムニストDavid Platt氏が「ビールを賭けてもいい。MicrosoftはWindowsが9や10になってもVisual Basic 6をサポートしなければならないだろう」と述べていたことがスラドで話題になったが、この予測は見事に当たったようだ。

本家/.「The Programmers Who Want To Get Rid of Software Estimates」より

ソフトウェアの世界からプロジェクトの所要時間の見積をなくそうとする#NoEstimatesムーブメントについて、Mediumの記事が紹介している。所要時間を正しく見積もることは困難であり、時間の無駄だとプログラマーたちは主張する。一方、他のプロジェクト関係者は、計画を立て、プログラマーに責任をもって仕事をさせるために見積が必要だと考えている。妥協点はあるのだろうか。

記事によれば、「ソフトウェアプロジェクトの見積は誤っていることがあまりに多く、見積を作るのに時間を使えば使うほど、実際にソフトウェアを作成する作業時間が減ってしまう。また、マネージャーは開発者が適当に作った見積を契約上の締め切りのように扱う習慣があり、見積時間内に完成しなければ大騒ぎする。それだけではない。そのような結果を恐れる開発者は、より多くのエネルギーを見積という兎の穴に注いでいく。見積はヤクの毛刈りのように、実際の仕事を先送りにする儀式となっている。」とのことだ。

Mediumの記事で最初にリンクしているツイートは2年以上前のものだが、実際に見積がなくなるまでにはどれぐらいの期間が必要だろうか。

あるAnonymous Coward 曰く、

これまで掲示板データがdatファイルという単純な形式で公開されていた「2ちゃんねる」（以下2ch）だが、datへのアクセスを廃止し、APIを用いたアクセスならびに開発者にAPIの使用許諾を取得することを義務付けることが発表された（株式会社ジェーンによるアナウンス、GIGAZINE）。

datとはいわゆる2chのcgiが参照する生データのこと。単純な形式であることから、また過去cgiが負荷によりたびたび閲覧不可となったことから、datファイルを直接参照する専用ブラウザが多数開発され用いられてきた。今回の発表では「datへのアクセスは近日廃止」と予告されており、また「3月3日以降専用ブラウザを開発する場合は、2ch.netの所有者であるRaceQueen社の許諾を得てAPIを用いる必要がある（ジェーンが一部代行）」「使用許諾を得ずにAPIを使用することは不正アクセス法違反となる」ことが通知されている。

ユーザーにとっては、専用ブラウザ側が移行してくれれば影響は少なそうであるが、Webアプリ型やJavaScriptの専用ブラウザ、また専用ブラウザ以外のアプリについては使用許諾されないという話があるので注意が必要である。

また、オープンソースの2ちゃんねるブラウザについては許諾されない、という話も出ている（2ちゃんねるへの投稿）。

あるAnonymous Coward 曰く、

プログラミングやCUIのサンプルとしてよく使われる「hoge」という単語を知らない若者が増えているそうだ。

元ネタはTogetterまとめだが、ITmediaが社内や情報科の高校生にヒアリングを行ったところ、高校生や20代は「hoge」という言葉を知らない傾向が明らかになったという。

これはグローバル化によって日本独自のhogeではなくfooやbarが多く使われるようになったためだろうか。日本独自文化であるhogeを守るためのキャンペーンが必要かもしれない。ちなみにタレコミ子的にはhogeと同列の言葉に「moge」があるのだが、最近これがあまりポピュラーではないことを知って驚いた。

プログラミングの際に、さまざまな理由でコーディングのルールを破ってしまうことがある。これらは誰もが「悪い」プログラミングテクニックであると認めるようなものだが、結果としてコードがクリーンになり、高速かつシンプルになることもある。InfoWorldの記事では、愛される悪いプログラミングテクニックを9つ選んでいる。

InfoWorldが選んだ悪いプログラミングテクニックは以下の通り。

1. gotoを使う
2. 関数名だけで内容がわかるようにしてドキュメンテーションを避ける
3. 1行に大量のコードを詰め込む
4. 型宣言をしない
5. 値の型を繰り返し変換する「ヨーヨーコード」
6. 独自のデータ構造を書く
7. ループの半ばでループを抜ける
8. 短い変数名を使う
9. 演算子や関数を再定義する

プログラミング言語や環境によっては使用できないものもあるが、皆さんがよく使うものはあるだろうか。また、リストに追加するとしたらどのようなものがあるだろう。

Edsger Dijkstra氏がgoto文の危険性を主張したのは1968年。それから50年近く経過した現在もgoto文は使われ続けているが、Dijkstra氏が懸念したようなgoto文の無制限な使用が行われているのかどうかという点や、それがバグの原因となるような有害なものなのかどうかといった点については、よくわかっていなかったという。こういった点に関する実証研究が本家/.で紹介されている。

本家/.「Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"」より

200万近いC言語のファイルと1万1千件を超えるプロジェクトからランダムに抽出した統計的に有効なサンプルを質的および量的に分析したところ、開発者はほとんどの場合gotoの使用を適切に制限しており、Dijkstra氏が懸念したような無制限な使用は行われていないことが判明した。これらのことから、実際にはgotoは有害でないものと考えられる。

本家/.「Why I Choose PostgreSQL Over MySQL/MariaDB」

過去10年、開発者や技術者はMySQLとPostgreSQLを比較し、後者が技術的には優れていると考える人が多かった。PostgreSQLの支持者は、そのANSI標準サポートやACID準拠がMySQLのスピードに勝ると主張する。しかし、すべてのLinux Webホスティングパッケージに含まれることから、非常に多くのWeb開発者がMySQLを使い続けている。Diceの記事では、開発者のDavid Bolton氏がMySQL/MariaDB 5.7.6(2015年3月9日、コミュニティーにリリース)とPostgreSQL 9.4.1を比較し、サブクエリやJSONサポート、ライセンス、データの完全性といった点で現在もPostgreSQLの優位性は変わらないとみる。10年以上にわたって両方のデータベースを使用しているというBolton氏は、MySQLにも改善はみられるものの、PostgreSQLを支持するとの結論に達している。

本家/.「Was Linus Torvalds Right About C++ Being So Wrong?」より

最も有名なC++への批判は、おそらく2007年のLinus Torvalds氏の発言だろう。「C++はひどい言語だ。」彼はこう書き始める。「これをさらにひどいものにしているのは、水準以下のプログラマーが数多く使用していることで、またさらに簡単に完全なゴミを作り出せるようになっている点だ。」と続く。C++を嫌うのは彼だけではない。STLやBoostを潜在的に不安定で非効率にした原因がC++だと考える開発者も多い。しかし、C++の需要がなくなることはない。Diceの記事では、C++はそれほど嫌悪するべきものではないとJeff Cogswell氏が主張している。「実際には一度しか使用しないのにも関わらず、複数の継承を重ねて再利用可能なクラスを作成するといった、過剰な設計をこれまでに何度も目にしてきている。」と、Cogswell氏は語る。「しかしこれは例外であり、標準ではないと主張したい。適切に使用すれば、一般的なプログラミングや、C++のより高度な機能を使用したプログラミングで、大きな利益が得られる。」とのこと。Linusの発言は行き過ぎだったのだろうか。

本家/.「AP Test's Recursion Examples: An Exercise In Awkwardness」より

FacebookのAP Computer Sicence(大学先修課程のコンピューターサイエンス科目)グループ(非公開)に投稿された、再帰呼び出しを使って0から6の数字を出力するコード例について、「APの試験で粗末なコーディング技術が使われていることを示す例がまた現れた」とAlfred Thompson氏が皮肉った。Thompson氏は「我々はしばしば、コード例に理想的ではないコーディング技術を使わざるを得ないこともある」と指摘。「通常は使うことのないコードを例にするのは、物事を明確にし、特定の概念を説明するためだ。特に再帰呼び出しを必要とする例はかなり複雑になる傾向があるので、このようなコード例は再帰呼び出しの解説で多く使われているようだ。」という。「0123456」を出力するためにループではなく再帰呼び出しを使用しているのは再帰呼び出しの処理を教えるためではあるのだが、Thompson氏はこれも粗末なコーディング技術の例であると主張する。

ただし、「再帰呼び出しで反復処理を行うのが一般的な関数型プログラミングを学んできた人は、当然これに同意しないだろう。」と付け加える。「金槌しか持っていなければ、すべての問題が釘に見えるなどと言われるが、再帰呼び出しとループの問題も同様だ。反復処理のために最初に選んだ(または最初に学んだ)のがループであれば、再帰呼び出しを解決方法だとは思わない傾向がある。同様に(関数型プログラミングで一般的な)再帰呼び出しから始めたのであれば、再帰呼び出しが反復処理のためのものだと考えるだろう。」とのことだ。皆さんの場合、再帰呼び出しをよく使う傾向があるだろうか。それとも避ける傾向があるだろうか。

ソフトウェア開発者の間では一般的に、ディスクアクセスを避けてできるだけメモリー上で処理することが実行時間の短縮につながると考えられているが、これに逆行する研究結果をカナダ・カルガリー大学とブリティッシュコロンビア大学の研究チームが発表した(論文: PDF、 ITworldの記事、 本家/.)。

実験はJavaおよびPythonを使い、WindowsおよびLinux上で1バイト、10バイト、1,000バイトの文字列をそれぞれ100万バイトになるまで繰り返し結合し、結果をディスクに書き込むというもの。比較対象としては同じく1バイト、10バイト、1,000バイトの文字列を結合せずに計100万バイトになるまで直接ディスクに書き込んでいる。また、同じコードにより100万バイトの文字列を処理する実験も行っている。

その結果、Javaで1バイトの文字列を結合処理してからディスクに書き込んだ場合、ディスクへの直接書き込みと比べて約9,000倍の時間がかかったという。PythonではJavaほどの速度低下は見られなかったものの、直接書き込みの方がメモリー上での処理よりも数百倍高速だったとのこと。また、Linux上で実行したPythonのコードでは、元の文字列に新しい文字列を結合する方が新しい文字列に元の文字列を結合するよりも高速だったとしている。

論文ではこのような結果になった原因として、OSによるバッファリングがあるためにディスクへ直接書き込んでも速度がそれほど低下しないと指摘。また、OSのメモリー管理がメモリー上での処理を低下させる原因になる可能性もあるとし、開発者はOSやライブラリーなどについてより多くの知識を持つことでパフォーマンスを改善できるなどと結論付けている。ただし、論文の最後に掲載されているコードを見ればわかるように、文字列の結合には「+=」または「+」を使用しており、効率の良い処理を選択しているとはいえない。論文には「JavaではStringBuilderやStringBufferといったミュータブルなデータ型を使用すれば結果が大幅に改善する」といった記述もある。本家/.では結論に合わせた結果が出るように実験したのではないかとの指摘もみられるが、皆さんはどう思われるだろうか。