パスワードを忘れた? アカウント作成
7389072 story
プログラミング

関数型言語を採用するプロジェクトが増加、果たして本当に開発効率は高いのか? 83

ストーリー by reo
二極化とかさあ 部門より

insiderman 曰く、

ソフトウェア開発に Scala や Haskell、Erlang といった関数型言語を採用する企業が増えているそうだ (ITpro の記事より) 。

関数型プログラミング言語には「迅速に開発できる、バグを抑えやすい、アプリケーションの性能を向上させやすい」といった特徴があるとし、これらは新規のサービス開発に向いているという。「言語選定が競争力に直結」といった意見も記事には掲載されている。

これだけだといいことずくめのようにも聞こえるが、関数型言語は習得しにくく、ライブラリなども C/C++ や Java と比べるとまだ少ない。使いこなせるプログラマも少なく、関数型言語で大規模システムの設計を行えるエンジニアはまだ少ないのではないだろうか。関数型言語を使える人材はある程度スキルの高い人であり、そのために生産性が高いのではという疑問もある。今後日本で関数型言語の採用は進んでいくのだろうか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Haskellを触ってみた感じ、デバッグが難しそうなんだけど、バグ自体が少ないから構わないって言うのかな?

    • by Anonymous Coward on 2013年02月05日 13時35分 (#2319384)

      Haskell のデバッグは絶望的に難しい。従来の手続型言語のようなステップ実行によるデバッグは、あんまり役に立たない。
      自分は GHC しか知らないけど、クラッシュした時にスタックトレースすらとれない。
      というか、基本が遅延評価の Haskell は原理的にスタックトレースに意味がないので、たいていはどこでクラッシュしたのかすらわからない。
      バグの個数は 100分の1になるけど、残り1%のバグが 100 倍強力になって襲い掛かってくる感じ。

      つまらない NullPointerException や ClassCastException に悩まされるようなことはほぼなくなるから、そういう意味ではバグを抑えやすいのは確かかもしれないね。
      デバッグが難しい代わりにテスト周りは充実していて、QuickCheck [nikkeibp.co.jp] なんかはすごい便利。
      だからとにかく丁寧にテストを積み重ねていって、あとはバグに遭遇しないことを神に祈るのが Haskell 流だと思う。

      親コメント
    • by imunolion (39292) on 2013年02月05日 13時21分 (#2319370) 日記

      バグ自体が少ないと言っているのは,
      ・プロジェクト数が少ない
      ・実行時バグの余地が少ない
      と2通りあります.

      前者は仕方のないことで,
      別に批判されるべきことじゃありませんよね.

      後者については型システム(およびコンパイラ)が,
      性質を静的に保障してくれることが多く,
      これは開発のうえで非常に強力です.

      デバッグの難しさについては,
      ちょっと真面目にすごいH [amazon.co.jp]で勉強した私はそうは思いません.
      まず, テストのしやすさは手続型言語よりも容易です.
      また, 従来再現しにくいバグの発見に至っては, そもそも入力が同じであれば必ず再現できます.

      「触ってみた感じ」ということですから, あまり体系的に勉強していないんじゃないでしょうか?
      もし単に謙遜しているだけで,
      実はベテランということだったら本当にごめんなさい.でも, その場合はデバッグがどう難しいかをコメントしてくれれば,
      多くの人にとって, とてもinformativeなコメントになりますよ

      親コメント
      • 変数が無く、動かしながら確認するっていうのが難しいから、ひたすらソースコードを見てバグを突き止めざるを得ないと思った。
        参照透明性があるからテストは容易なのだろうけど、printf的な出し方が面倒。

        親コメント
      • by Anonymous Coward

        すごいH本にデバッギングの解説ってあったっけ?あんまり精読してないので、見落としたかも。
        今ちょっと日本語版が手元にないので英語版 [learnyouahaskell.com](無料で全部読めるよ!)の目次見たけど、
        それっぽいのが見当たらない

        • デバッギングの解説はないですが,
          実行中の挙動について表示させる例はありましたよね.
          そう, 12章の"Walk in the line"の例です.
          失敗するかもしれない関数landLeft,landRightの仕様をMaybeという文脈つけて変更していました.

          でも実はこれだけじゃなくて,
          純粋な関数であったとしても, トレースを使えます.
          山本先生のブログ記事 [hatena.ne.jp]

          究極的には, プログラムがstuckするのは,
          パターンマッチに転けた場合が多いです.
          そのときパターンマッチした際の値を得ることで,
          原因は大体わかりますよね

          親コメント
          • by Anonymous Coward on 2013年02月05日 16時01分 (#2319536)

            自分の書いたコードのパターンマッチングで落っこちるとちゃんと行番号が出てくるし、オプションつければ漏れがあっても警告出るから問題ないね。
            困るのはゼロ除算や head [] で落ちたりとか、クラッシュせずに誤った結果を返してくるときとかかな。
            head [] なんて、エラーメッセージは "Prelude.head: empty list" だけだからね。どうやって原因を突き止めろと。
            trace を埋め込む場所がわかるなら、バグは半分見つけたようなもので……。

            自分はその山本さんの記事も読んだことあるんだけど、

            あと、例外がどこから来たのか知りたい場合は、GHC のデバッガを使うといいでしょう。

            という一文にがっかりした覚えが。その GHCi のデバッガが、ほとんど役に立たないんだよ……。

            だいたい GHCi (Haskell 処理系のデファクトスタンダードだね)のデバッガのマニュアルがこんな調子なんだよ。

            プログラムをデバッグしている時にしばしば問われる問いの一つに、「どうやってここに来たんだ?」というものがある。伝統的な命令的デバッガは通常何らかのスタックトレースの機能を持っていて、それを使ってアクティブな関数呼び出しのスタック(字句的呼び出しスタックと呼ばれることもある)を確認することができる。このスタックによって、現在の地点に至るまでのコード上の道のりが分かる。残念なことに、これをHaskellで用意するのは難しい。正格な言語と違って、実行は深さ優先ではなく必要に応じて進むからである。

            もう一つデバッグ中によく発生する疑問として、「この例外はどこから来たんだ?」というものがある。errorやhead []によって発生する例外には文脈情報が付属していない。プログラム中のどのheadの呼び出しがエラーの原因になったかを調べるのは骨の折れる作業であり、通常Debug.Trace.traceを使ったり、プロファイル付きでコンパイルして+RTS -xc(5.3. 時間及び確保量のプロファイルを取るを見よ)を使ったりすることになる。

            GHCiデバッガの提供する方法を使うと、このようなエラーを素早く、かつコードを再コンパイルすることなしに突き止めることが、うまくすればできるかもしれない。

            http://www.kotha.net/ghcguide_ja/7.0.4/ghci-debugger.html [kotha.net]

            うまくすれば (hopefully) っておい……。Haskell のデバッグの難しさを知りたければ、このマニュアル読むのが参考になると思う。

            親コメント
            • by Anonymous Coward

              場当たり的なコメントで申し訳ないですが,
              head []はパターンマッチで書く方が筋が良い.
              (listToMaybe的なものをつかっても一緒)

              ゼロ除算はcatchするよりも,
              Integerを使うか最初から除算に気をつければいい.
              失敗するかもしれない演算なんだから.

              手続き型言語の例外は最初から想定しているもので,
              それぞれcatchすればいいよね, という風潮だけど,
              関数型言語の例外は, 発生しないように書くという前提.
              究極的には関数型言語を好きになるかどうかって,
              例外が発生しうる範囲が非常に限定されているんだから, 最初から避けて設計するよね,
              というのを受け入れるか否かの違いだと思う.

              • by Anonymous Coward on 2013年02月05日 17時16分 (#2319598)

                んで、その「究極的には」の内容を実践できる人だけが、「いいねーいいねー」って言いながら使っているから、バグが少ないって「思われている」だけなんじゃなかろか?
                VBやPHPなんかで、バグがそりゃもうひどいことになるのは、言語設計がどうのと言うよりも、技術屋のレベルの問題に落とし込める気がしてなぁ。

                親コメント
              • by Anonymous Coward on 2013年02月05日 18時42分 (#2319679)

                つまりだ、Haskellで開発するから技術者集まれ!ってやると優秀なのだけ集まってくるって訳だな。

                素晴らしい。

                # 実際身の回りの関数型言語を好む人って優秀な言語フリークが多いイメージ。
                # もしくは、そういう優秀なフリークに英才教育されてる感じ。
                # ちゃんと生き残ってついて行ければ優秀に育つだろうなぁ。

                # 数学的な訓練を受けていないとあまり直感的ではないので
                # そもそも優秀なフリークが身近に居ないとはまりにくいと言うのと、
                # コミュニティが狭いので優秀なフリークが直接手ほどき出来る程度の規模で
                # 布教に熱心になりやすいというのはあると思う。

                親コメント
  • 高度なプログラムを書く人間は人件費が高い
    なので多少バグっても顧客のいうものを作れる使い潰しのきく安いプログラマーを連れてこい。

    みたいな感じになるのでなかなか普及しないかも。

    • by nmaeda (5111) on 2013年02月05日 14時45分 (#2319458)

      >顧客のいうものを作れる使い潰しのきく安いプログラマー

      これ、考えようによってはかなりスキルが高いのでは?

      親コメント
      • by Anonymous Coward

        実現するだけなら結構難しくはない。
        それをバグ無し及び効率的な手段で、となると一気に難易度が上るだけで。

        プログラムで言うならソートしたい時にバブルソート(ライブラリ使わず自力実装するとして)なら馬鹿でもできるけど
        そうなると結果ソートはできても量が膨大だと効率が悪い。
        しかし敏腕プログラマならもっと複雑な実装で効率のいいソートアルゴリズムが組める。

  • 関数型言語は、ちゃんとロジックに落ちている仕様を確実にプログラムにするあたりには役に立つようには思う。けど、多くのバグ、とくに悩ましいバグは、そのロジックに落とす前の「もやもや」っとした部分。

    「やりたいことをこう整理すれば、希望する結果が得られるはず」と思ってアルゴリズム組むけど、そこに穴があって、orz ってことに。

    あと、ロジックの実装ミスは、綺麗なコーディングに心がける(歪な局所抜け出しとかさせずに、入れ子構造を正しく保つ)とか naming ルールを整理しておけば、けっこう、ソースコードの形でバグが見えてきたりする場合があると感じている。関数型言語は、その歪さ検出を言語仕様に入れているだけ、というのは、浅はかな理解?

    • by Anonymous Coward on 2013年02月05日 16時05分 (#2319542)

      大体合ってると思います

      有名な話に, 「A well typed program never gets "stuck"」があるように,
      きちんと設計された関数型言語の一つの目的です

      もっと言うと, そうした検出機能があると言うより,
      そう書かなければ文法として正しくない.

      # と言う割にHaskellはパターン漏れはデフォルトで許容してるんだよなあ
      # デフォルトで-Wオプション使えってことかもしれないけど

      親コメント
  • by Anonymous Coward on 2013年02月05日 12時55分 (#2319319)

    同時に「構造化プログラミング」という手法もセットでしたが

  • by JULY (38066) on 2013年02月05日 13時29分 (#2319381)

    使いこなせるプログラマも少なく、

    そもそも関数型言語を使いこなせるプログラマのレベルが高いから、結果として

    「迅速に開発できる、バグを抑えやすい、アプリケーションの性能を向上させやすい」

    ということは無い?

    • by Anonymous Coward

      間違いなくその通りだと思うけど、夢のないこと言うなよ。
      関数型言語の特長だと言っておけばみんな幸せなんだ。

      # どうせ一般レベルに普及するのはまだ先だし(その前に廃れるかも知れん)

  • by Anonymous Coward on 2013年02月05日 13時55分 (#2319411)

    そうだFORTHを使え

  • by Anonymous Coward on 2013年02月05日 12時55分 (#2319318)

    FORTRANと並ぶ太古からの歴史のあるLispを使えばいいじゃないか

    • common lispで
      パターンマッチさせたいならCLOSを。
      マッチして高度に分解したいならoptimaを。
      遅延評価させたいならCLAZYを。
      メモ化させたいならfare-memoizationを。
      複雑に繰り返したいならiterateを。
      なんでもござれ、みなさんいらっしゃい・・・

      --
      新人。プログラマレベルをポケモンで言うと、コラッタぐらい
      親コメント
    • by Anonymous Coward

      関数型に馴染んでない素人(俺)がLispを使ってみると、
      prognだのifだのを使いまくって手続き型じゃんってことに。

      • by nmaeda (5111) on 2013年02月05日 14時49分 (#2319464)

        あれはメリットだと思うけどな。見た目はカッコだらけで異様(?)でも、実はスタイルや用途を選ばない万能言語。

        親コメント
      • by Anonymous Coward

        あ、それ俺だ
        昔、LOGO を使ってアプリ組むバイトをしたんだが、思いっきり関数型的な
        作り方でやっちゃった。
        動作スピードも、関数型でやるよりずっと速くしたんだけどね

        #誰だかばれるかな(汗

  • by Anonymous Coward on 2013年02月05日 13時06分 (#2319342)

    いぜんちょっと囓っただけだけど、Javaの言語仕様を包含してるのがメリットでありデメリットに感じた。

    >ライブラリなども C/C++ や Java と比べるとまだ少ない。
    javaのライブラリがそのまま呼べたはずなので、この問題だけはすくないけど、
    記述が煩雑で言語仕様が無駄に複雑。
    おかげでコードの読みにくさはかなりのもので、仕事で使いたいとは思わなかった。

    • by Anonymous Coward on 2013年02月05日 13時15分 (#2319356)

      論理的に常に正しく考えられる頭のいい人しか使えない言語だと思います。
      世の中の大半のプログラマがそこまで頭がいいわけではないので、現実問題として普及しないのではないかなあと。

      問題が起きにくいけれど習得のハードルが高い言語よりも、習得しやすい言語のデバッグ環境を強化していく方向が現実解の気がします。

      親コメント
      • オブジェクト指向言語だって、オブジェクト指向らしいコードを書けるプログラマばっかりでないのに普及してるし。
        Scalaみたいな言語も有力なところがプッシュしたら、関数型らしいコードが書けるプログラマが少なくても普及すると思う。

        • by Anonymous Coward

          オブジェクト指向はメリットが見えやすかったからね。
          カプセル化なんて初心者プログラマでも「なるほど、確かに自然で分かりやすい!」だし、
          切り分け方が非プログラマ(経営層、マネージャ層)にも分かりやすいのも良い。
          UMLやらOO分析手法の助けもあって、上流から下流まで一貫性があるし。(震え声)

          さて、関数型言語はどうだろう?

          • 関数型言語でユーザが関数を定義せずに8割方のプログラムが書けるのなら普及すると思います.

            カプセル化なんて初心者プログラマでも「なるほど、確かに自然で分かりやすい!」だし、
            切り分け方が非プログラマ(経営層、マネージャ層)にも分かりやすいのも良い。
            UMLやらOO分析手法の助けもあって、上流から下流まで一貫性があるし。(震え声)

            本当にそうであればよかったですよね. init()メソッドしかないクラスなんて存在しなかったでしょうし, しかもそれが1メソッドで数千行も続くこともなかったでしょうし.

            親コメント
    • by Anonymous Coward

      >javaのライブラリがそのまま呼べた

      バグの内包とかを考えると、これはメリットなのかデメリットなのか・・・。

    • by Anonymous Coward

      Groovyにかけた時間を返して
      -> Scalaに時間をかける気などない
      に遷移するのが正解。
      Javaで不可能なことがScala環境になれば出来るということも無い

  • by Anonymous Coward on 2013年02月05日 13時19分 (#2319367)

    一山いくらで使い潰せていくらでも代わりが効くスキルのほうがいいというのは経営者の論理だろ。
    雇われる立場では他人と差別化できるスキルがなきゃ使い潰されるだけだぞ

  • by Anonymous Coward on 2013年02月05日 14時48分 (#2319463)

    実際に仕事で言語を使う場合、
    言語を使ってるというよりもライブラリを使ってるという側面が大きくて
    どの程度ライブラリがそろってるかということは
    言語自体の質よりも格段に重要だと思える。

    開発言語オタクや専門家に持ち上げられる言語って、
    たいていライブラリがあんまり充実してなくて、
    サンプルがコマンドラインで動かす程度のものしか無いんだよね。
    「で、これで何作るの?」とでも言うしかないレベル。

    ウィンドウシステムからマルチメディアコントロールまで自力で作れる人には
    問題ないんだろうけどね。

    • by Anonymous Coward on 2013年02月05日 15時15分 (#2319489)

      Haskell は GUI ツールキットもあるし、OpenGL も呼べるしWeb アプリケーションフレームワークだってある。
      もちろん選択肢は少ないけど、ぜんぜんないわけじゃないんだよね。

      それに Scala は JavaVM で動いて Java の API 全部呼べるし、F# に至っては .NET Framework の一部。
      F# や Scala ならライブラリの心配はないんじゃないかな。

      親コメント
    • by Anonymous Coward on 2013年02月05日 16時41分 (#2319576)

      うちの会社はとある大規模並列処理にErlang、そのジョブを管理するマネージャにPython、Web周りや検索系、Hadoop、HBaseにJavaを使ったプロジェクトをやっています。Erlangで全部賄おうというつもりは毛頭無く、システムの売りのコアになる特定処理に絞って投入しています。仮に既存のライブラリが少なくてもそれがカバーする範囲と自前で用意できる実装が目的とピタリとマッチすればすごく強力です。

      そして全ての言語でゲンミツにロジックを共有したい場合はCで書くという・・・

      親コメント
    • by Anonymous Coward

      ScalaのPlayFrameworkはなかなか便利、Railsくらい便利かって言われるとわからないが。

  • by Anonymous Coward on 2013年02月05日 15時11分 (#2319484)

    > 関数型言語で大規模システムの設計を行えるエンジニアはまだ少ないのではないだろうか

    いやいや、ひいひい言いながら「オブジェクト指向+デザパタ」の実務経験を積んできたんだがな~。orz

  • by Anonymous Coward on 2013年02月05日 15時50分 (#2319525)

    並列処理に強いプログラミング言語だからじゃないの?

typodupeerror

人生の大半の問題はスルー力で解決する -- スルー力研究専門家

読み込み中...