すでに LISP に精通している場合、F# を学習することの付加価値は何ですか?
11 に答える
- 静的型付け(型推論あり)
- 代数データ型
- パターンマッチング
- アクティブなパターンとの拡張可能なパターン マッチング。
- カリー化 (いい構文で)
- 「ワークフロー」と呼ばれるモナディック プログラミングは、非同期プログラミングを行う優れた方法を提供します。
これらの多くは、プログラミング言語の世界で比較的最近開発されたものです。F# 標準はまだ開発中であるため、これは Lisp、特に Common Lisp では見られない F# では見られるものです。その結果、学ぶべきことがかなりあることがわかります。もちろん、ADT、パターンマッチング、モナド、カリー化などは Lisp のライブラリとして構築できますが、それらが便利に組み込まれている言語でそれらを使用する方法を学ぶ方がよいでしょう。
実際の使用のために F# を学習する最大の利点は、.NET との統合です。
Lisp と F# を直接比較するのは公平ではありません。結局のところ、十分な時間があればどちらの言語でも同じアプリを作成できるからです。
ただし、C# や Java の開発者が F# を学ぶ必要があるのと同じ理由で、F# を学ぶ必要があります。.NET プラットフォームで関数型プログラミングが可能になるからです。私は Lisp に 100% 精通しているわけではありませんが、優れたライブラリ サポートがないという点で、OCaml と同じ問題をいくつか抱えていると思います。Lispでデータベースにアクセスするにはどうすればよいですか? 高性能グラフィックスはどうですか?
「Why .NET」について詳しく知りたい場合は、このSO questionを確認してください。
F# と Lisp を知っていれば、これは奇妙な質問だと思うでしょう。
他の人が指摘したように、Lisp は動的に型付けされます。さらに重要なことに、Lisp のユニークな特徴はホモイコニックであることです。Lispコードは基本的な Lisp データ型(リスト) です。マクロ システムは、コンパイル時に実行され、他のコードを変更するコードを記述できるようにすることで、この利点を利用します。
F# にはこのようなものはありません。ML と Haskell から多くのアイデアを取り入れ、.NET 上で実行する静的に型付けされた言語です。
あなたが尋ねていることは、「フォークの使い方を知っているのに、なぜスプーンの使い方を学ぶ必要があるのですか?」に似ています。
LISP が動的に型付けされ、F# が静的に型付けされることを考えると、このような比較は奇妙に思えます。
お金。F#コードはLispコードよりもすでに価値があり、F#が広く採用されるにつれて、このギャップは非常に急速に拡大します。
つまり、Lispを使用するよりも、F#を使用して安定した収入を得る可能性がはるかに高くなります。
乾杯、ジョン・ハロップ。
私が Lisp から F# に切り替えるとしたら、.NET のみのライブラリから大きな恩恵を受けるタスクがあったからです。
しかし、私はそうではありません。
F# は、ほとんどの Lisp 方言とは大きく異なる言語です。したがって、F# はまったく異なるプログラミングの角度を提供します - Lisp からは学べない角度です。ほとんどの Lisp の方言は、シンボリック ソフトウェアのインクリメンタルでインタラクティブな開発に最適です。同時に、ほとんどの Lisp 方言は関数型プログラミング言語ではなく、マルチパラダイム言語に似ています - 方言が異なれば、FPL 機能のサポートに異なる重みが置かれます (副作用、不変のデータ構造、代数データ型などの影響がない)。したがって、ほとんどの Lisp の方言は、静的型付けを欠いているか、静的型付けをあまり重視していません。
したがって、Lisp の方言をある程度知っている場合は、F# を学ぶことは非常に理にかなっています。F# は非常に異なる言語であるため、Lisp の知識の多くが F# に当てはまるとは思わないでください。C や Java に使用される命令型プログラミングが Lisp を学習するときにいくつかのアイデアを忘れる必要があるのと同じように、F# を使用するときにも Lisp の習慣 (型、副作用、マクロなど) を忘れる必要があります。F# も Microsoft によって推進されており、.net フレームワークを利用しています。
F# には、(一般的に) .NET 開発が非常に広く採用されており、簡単に入手でき、マス マーケットが多いという利点があります。
F# をコーディングしたい場合は、LISP 環境を立ち上げて実行するのではなく、多くの開発者が既に持っている Visual Studio を入手できます。
さらに、既存の .NET 開発者は、LISP よりも F# を検討する可能性がはるかに高くなります (それがあなたにとって意味がある場合)。
(これは、大学在学中に LISP をコーディングし、LISP を愛した .NET 開発者からのものです)。
あなたがそうするかどうかわかりませんか?F# が面白いと思ったら、それが理由です。あなたがそれを必要とする仕事をしているなら、それは理由になるでしょう。生産性が向上したり、現在の知識よりも付加価値が得られると思われる場合は、それが理由になります。
しかし、F# に興味がなく、自分の仕事に F# を必要とせず、F# によって生産性が向上したり、付加価値がもたらされたりするとは思えないのであれば、なぜそう思うのでしょうか?
一方、F# が提供し、Lisp が提供しないものについての質問がある場合は、型推論、パターン マッチング、および .NET フレームワークの残りの部分との統合を検討する必要があります。
このスレッドが古いことは知っていますが、このスレッドに出くわしたので、理由についてコメントしたかっただけです。.NET は、私の分野を支配する企業のカテゴリで大きな重みを持っているため、単に専門的な機会のために F# を学んでいます。機能的パラダイムは、より定量的でデータ指向の企業の間で使用されるようになってきており、私はこのトレンドの初期の参加者の 1 人になりたいと考えています。現在、.NET ライブラリと完全かつ安全に統合できる強力な関数型言語は存在しません。私は実際に Lisp コードからいくつかの .NET を移植しようとしましたが、FFI は C プリミティブしかサポートしておらず、.NET の相互運用性には「インターフェイス」構造が必要であり、C でこれを行う方法を知っていても、それは本当に大変です。痛み。それは本当に、本当に、Lispが次の標準でさらに一歩進んで、C++クラス(vtablesを備えた仮想関数を含む)と、FFIのC#スタイルのインターフェースタイプを必要とする場合は良い. たぶん、Java インターフェース スタイルの型も投入するかもしれません。これにより、.NET ライブラリとの完全な相互運用性が可能になり、Lisp は大規模言語として有力な候補となります。しかし、そうは言っても、Lisp のバックグラウンドを持っていることで、F# の学習はかなり簡単になりました。そして私は、F# が、量的な型が機能することがよくある型を提供するために、さらに一歩進んだ方法を気に入っています。F# は数学的作業を念頭に置いて作成されたものであり、それ自体が Lisp よりも価値があると私は信じています。これにより、.NET ライブラリとの完全な相互運用性が可能になり、Lisp は大規模言語として有力な候補となります。しかし、そうは言っても、Lisp のバックグラウンドを持っていることで、F# の学習はかなり簡単になりました。そして私は、F# が、量的な型が機能することがよくある型を提供するために、さらに一歩進んだ方法を気に入っています。F# は数学的作業を念頭に置いて作成されたものであり、それ自体が Lisp よりも価値があると私は信じています。これにより、.NET ライブラリとの完全な相互運用性が可能になり、Lisp は大規模言語として有力な候補となります。しかし、そうは言っても、Lisp のバックグラウンドを持っていることで、F# の学習はかなり簡単になりました。そして私は、F# が、量的な型が機能することがよくある型を提供するために、さらに一歩進んだ方法を気に入っています。F# は数学的作業を念頭に置いて作成されたものであり、それ自体が Lisp よりも価値があると私は信じています。
これ (元の質問) を見る 1 つの方法は、言語 (および関連するツールとプラットフォーム) を当面のタスクに一致させることです。タスクに圧倒的な割合の .NET コードが必要であり、そのタスクに正面から取り組むには、ある言語で別の言語よりもシューホーニングが少なくて済む場合は、抵抗が最も少ない方法 (F#) を選択します。.NET 機能を必要とせず、LISP を快適に使用でき、腕を曲げて LISP から離れる必要がない場合は、引き続き使用してください。
ハンマーとレンチを比較するのと大差ありません。作業に最も効果的なツールを選択してください。客観的に「最高」のツールを選択しようとするのはナンセンスです。いずれにせよ、20 年後には、現在「ホット」な言語はいずれも時代遅れになる可能性があります。