タグ

ブックマーク / developers.srad.jp (5)

  • プログラミング習得は時間のムダ? | スラド デベロッパー

    先日、米ニューヨーク市のBloomberg市長がプログラミングを学ぶことを新年の抱負としたことが話題になったが、あるAnonymous Cowardのタレコミによると、これに対し「プログラミング習得は時間のムダ」という発言が話題になっているという(マイナビニュース)。 懸念されているのは、「コード信奉やプログラミング中毒に陥り、それ以外のソリューションを軽視すること」だという。また、OracleAndroid裁判とコードの関係についても記事では紹介されている。

    koroharo
    koroharo 2012/05/31
    『プログラミングをすることで、論理的思考とかコンピュータの基礎知識とかが上がるとして、「政治家として役に立つ」ようになればいいとは思うよ?問題はそういうトレーニング方法が社会的にもコンセンサスとれてな
  • Oralceの対Google訴訟、プログラミングの将来を危うくしている | スラド デベロッパー

    Oracleは、Android OSに使用されているJava APIOracleの保有する特許を侵害しているとしてGoogleに対して訴訟を起こしているが、Dr. Dobb's記事は、もしOracleが勝訴することになれば「プログラミングの将来は終わる」と予測している(家/.、Dr.Dobb's記事)。 Oracleとのライセンス契約がないまま、GoogleJava技術を無断で使用したことが特許侵害に当たると判断されれば、GoogleOracleに対して多額のライセンス料を支払わざるを得なくなる。話はこれで済めばよいのだが、この訴訟から多くの訴訟が派生する可能性があるという。 つまり、例えばPythonにおけるJythonやIronPython、PyPy、またRubyにおけるRubinius、CやVBにおけるRono、CにおけるGCCといった、既存言語処理系の再実装によって著作権侵

    koroharo
    koroharo 2012/05/05
    実装じゃなくてAPI仕様に著作権を主張してるのか、なるほど。Oracleの言い分通ると確かに厄介。
  • スペースシャトル専用言語HAL/Sに関する電子書籍 | スラド デベロッパー

    目の付け所は面白いと思いますが、 PDF 版の第 3 章「演算」 (12~14 ページ) を眺めて 2005 年版言語仕様 (英語) [klabs.org] と照らし合わせてみたところ、内容の正確性に疑問が残ります。 ** は「階乗演算子」と説明されていますが (p. 12)、正しくは「べき乗演算子」です (言語仕様 6-4 ページの表 6-2)。論理否定 ¬ の優先順位が定義されていないという記述があります (p. 13)。言語仕様 6-11 ページの図 6-10 によれば、 ¬ を論理否定の単項演算子として使う場合、括弧を付けなければならないことになっているので、優先順位が問題になることはありません。単項演算子 ¬ はこのほかにビット否定や「イベント」の否定にも使われますが (「イベント」というのが何であるかは僕は把握してない)、構文によればこの単項演算子がとれるのは単独の変数か括弧に

    koroharo
    koroharo 2012/01/21
    『正直なところを言おう。シャトルがこの言語を使いながらコンピュータシステムで致命的な不具合を出さなかったというのは、ひとつの奇跡だ。』言語なんて関係ない派に読ませたい。
  • いいコーディング規約、悪いコーディング規約? | スラド デベロッパー

    格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。 可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか? ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか? /.J諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか? 逆に規約のせいで問題が起きてしまったケースなどあるだろうか? 他にも、使える「自分ルール」などもあれば是非。

  • 将来しなくても良くなるコーディングテクニック | スラド デベロッパー

    もうやらなくていい昔のコーディングテクニックあれこれという話題がありました。過去は過去として振り返るのは有効ですが、それを踏まえた上で、将来しなくても良くなるコーディングテクニック、というのは何でしょうか ? IDE や言語環境の改善により、人間が無駄なことをしなくて済む環境は整いつつあるも、まだまだ改善しなければならない部分は多い。そんな環境改善に伴い、今は行っているけど将来的には意味が乏しくなるコーディングテクニックというのを語り合うのも面白いのではなかろうか ? 日頃の不満点、こうなったらいいな、など色々思いはあるでしょうが、コーディングテクニック関連の雑談ということでは丁度良い機会でもあることだし、忌憚無い意見をお聞かせ下さい。

  • 1