プロジェクトの特定のニッチで主流の選択肢ではない言語を使用してプロジェクトを行ったことがありますか？どうして？
しばらく前にSmalltalk（まあ、Squeak）での学業経験と、それを何かに使用したいかどうかを考えていたところ、確かに、他の一般的な言語と同じくらい優れていて、機能があり、いくつかあります。素晴らしいアイデアですが、プログラミングの特定のニッチにすでにしっかりと定着している特定の言語があります（Cはシステムプログラミング用、Javaは移植性用など...））、Smalltalkとco。は、特定の状況下で、または少なくとも私が知る限りでは、それらを正しい選択にするための明確な差別化機能を持っていないようです。それに追加すると、それを知っているプログラマーを見つけるのが難しいという事実があります。それは組織自体に他のあらゆる種類の問題を追加します。
では、非主流の言語（Smalltalkなど）がより主流の言語よりも使用されているプロジェクトに取り組んだことがある場合、その理由は何でしたか？
明確にするために：私はこれを命令型言語に焦点を合わせたいと思います。
私はスクリプト言語として、商用ゲームプロジェクトで Falcon を使用しています。
しかし、それは私の日課ではありません。
主な理由は、Luaと同じように、C++から簡単に埋め込み、制御できるものが欲しいということですが、構文と言語の機能はPythonに似ています。 Pythonは埋め込むことができますが、それができたとしても、埋め込むにはAPITAであることがわかります。
Falconの構文はPythonと似ていますが、より多くのパラダイムを提供するため、特定のプロジェクトでの作業により適したものを使用できます。完全にC++で記述され、埋め込まれるように作成されています（ Luabindの方法ですが、特定のエンジンライブラリを操作するのがより簡単です。モジュールを言語で挿入できます。モジュールはC++（または完全にFalcon）で記述されています。アプリケーション固有のモジュールを実行すると、次のことはできなくなります。ファルコンがそれを操作できるようにするために他のことをすること。
私の要件に一致するが、まだ若すぎる別の選択肢は ChaiScript -これは本当に有望です。おもちゃのプロジェクトで使おうとしていますが、まだうまくいきませんでした。
これを別のプロジェクトで使用しています。今のところFalconを使用しますが、組み込みシステムでリファクタリングされてさらに簡単になります。プロジェクトのスクリプティング部分を完了する必要があるときにリファクタリングが完了した場合（すぐに）、それを維持します（スクリプターがさらに別の未知の言語で作成する必要がある場合でも、この特定のことは気にしませんプロジェクトであり、PythonまたはRubyとにかく）に精通している人にとっては簡単に学ぶことができます。
私の日常の仕事で、私は最近、少し変更されたバージョンの Picol を介していくつかの機能を公開する小さなthrow-awayツールを作成しました。 =（非常に小さなTclインタープリター）。
これらのことが進むにつれて、ツールは捨てられず、代わりに成長し、プロジェクトにとって重要なツールになりました:(
私は通訳に興味を持っていたのでPicolを使用しましたが、同僚の誰もツールを見るはずがなかったので、それを回避できると思いました。
私はHaskellを使用して重要なミドルウェアプログラムをプログラムしました。これを行っているのは私だけだったので、この選択をすることができました（それ自体は良いことではありません）。それを選択した他の理由は、プロジェクトが非常に時間制限があり、結果として得られたプログラムが比較的低リソース環境で実行されなければならなかったことです。
そして最後に、私は何年にもわたってそれを研究してきたので、Haskellを本物の何かに挑戦することに飢えていました。
結果はかなり良かった。最悪の問題は、メモリリークがひどいライブラリ（Cライブラリのラッパー）でしたが、幸い、それを純粋なHaskellライブラリに置き換えることができました。この場合、プロファイラーツールが問題の発見に役立ちました。また、優れたXMLライブラリを見つけるのは非常に面倒でした。
最高の部分は、すべてを実装するのが一般的に速くて楽しいということでした。また、私は抜本的な変更を加えることができ、ghcはそのプロセスを通じて私を保護してくれました。
人々に新しい言語に興味を持ってもらうのは難しいです。特に経験豊富な人はプログラミングが得意であり、彼らのスキルが非常に具体的であることに気付くのはかなりモチベーションキラーのようです。
私は博士号のほとんどを行います。 [〜＃〜] d [〜＃〜] でコーディングを研究します。言語とツールチェーンの未熟さに対処しなければならなかったので、それは確かにいくぶんPITAでした。言語仕様が安定した今、これは急速に改善されています。ただし、もう一度やり直さなければならない場合は、次の理由で間違いなくやります。
私が書いたもののほとんどは、かなりメモリを消費し、パフォーマンスが重要ですが、開発速度が重要なプロトタイプ風のコードでもあります。 Dは、私が知っている唯一の言語であり、プログラマーの利便性と実行時の効率の両方で優れています。 （おそらくC＃は法案に適合しますが、Dのようなテンプレートメタプログラミングがないため、効率的な再利用可能/汎用ソリューションを思い付くのがはるかに困難になります。また、Javaスタイルの押し込みの痕跡もありますOO down喉と他の同様の束縛と規律の特徴。）
Dのライブラリサポートの欠如を補うために、私は自分でいくつかのライブラリを作成しました。これは素晴らしい学習体験でした。私は独自のSMP並列処理ライブラリを作成しました。これは現在、標準ライブラリに含めるために検討中です。私は自分の統計/機械学習ライブラリを作成しましたが、今では、クラスを受講しているときよりも、これを桁違いによく知っているように感じます。私は独自のプロットライブラリを作成し、そこからデータの視覚化とGUIプログラミングについて多くのことを学びました。さらに、これらはすべて私が履歴書に載せることができるオープンソースプロジェクトです。もっと主流の言語にこだわるなら、おそらくすべての「興味深い」ライブラリ開発作業はすでに行われているように感じるでしょう。
言語デザインなどの議論に参加することも、素晴らしい学習体験でした。
だれもがっしりしたレガシーテクノロジーできれいな休憩をとるために短期間の苦痛に耐えたことがなければ、私たちは皆、Fortran'77でプログラミングしているでしょう。私を理想主義者と呼んでください、しかしこれは私が望む未来ではありません。
特定の宛先ホスト/スタックを決定せずに、移行中のレガシーCOBOLシステムのクロスプラットフォームプロトタイプにTcl/Tkを使用しました。お客様は、3年および5年の技術計画で引き続きSolarisデスクトップが必要かどうかを決定していませんでした。そうでない場合は、NT/2000に移行することを希望していました。それは故意に使い捨てのコードの始まりでした
目的は、ターミナルインターフェイスからネイティブウィンドウ、および豊富にフォーマットされた出力に移行することでした。 Tcl/Tkを使用すると、レイアウトをすばやく変更し、その内部execを使用して、コマンドラインオプションによって純粋に駆動されるように最小限の調整で既存のCobol実行可能ファイルと対話できます。
最近、何が主流の言語として数えられるかはわかりませんが、Autocadのモデルと図面の自動生成を容易にするために（かなり前に）かなりのAuto/VisualLISPプログラミングを行いました。結局、生成するコードのほとんどはLISPにありました（Fortran/Cプロジェクトとして開始されましたが、その部分は非常に単純で、ある時点ですべてをLISPに移植しただけです）。ある時点でその場所を離れましたが、プロジェクトがまだ生きていても驚かないでしょう。
私の国では、マイクロソフト以外のものはすべて「非主流」と見なされます。これには、他の場所（JavaまたはDelphi、誰か？）で「主流」になる可能性のあるプログラミング言語も含まれます。
どの国でも、多くの企業や政府機関があります。与えられた（プログラミング言語とプログラミングフレームワーク）の開発者を雇わないことを恐れているので、彼らは主流の言語を好みます。
しかし、私の経験では、「主流」の言語は裏目に出る可能性があります。これは、開発者が簡単により良い仕事を得て、プロジェクトを離れることができるためです。
また、主流ではない言語で作業する開発者は、通常、ソフトウェアの品質にもっと注意を払っています。
開発者が多すぎるということは、品質の低い開発者が増えることを意味します。そして、いくつかの場所では、企業は悪い開発者をフィルタリングできない、それらをフィルタリングする方法を知らない、あるいは彼らが安い限り、悪い開発者をフィルタリングすることを気にしない。
より多くの開発者が必要なDelphiプロジェクトで働いていましたが、顧客はそれを知っていました。 C/VB開発者を雇い、言語とフレームワークについて教え、さらにはアルゴリズム/デザインパターンのスキルをチェックします。主流ではない言語を目的として教えることで、私たちを助けてくれました。彼らが問題を解決する方法も知っていることを確認してください。
Smalltalk自体は、おそらく、既存の主流のテクノロジーよりもそれほどキラーなものではありません。しかし、 Seaside を取る場合、それは確かに選択を正当化するかもしれません。
また、一般的なテクノロジーのどれよりもはるかに強力な非主流の言語があります。そのため、できるだけ多くのパワーを必要とする複雑なプロジェクトでは、選択の余地はありません。私は主に開発作業のほとんどにLISPを使用しており、LISP上に設計されたドメイン固有言語の巨大なツールチェーンを持っています-他の言語ではそれを行うことは不可能です。そのため、現在、私は主流の言語よりもはるかに多くの非主流の言語を使用しています。
「非主流」のもう1つのケースは、独自の奇妙なスクリプト言語（CADなど）を備えた古いレガシーシステムです。
私は、システムが開発された会社に固有のカスタム言語を使用して、いくつかのプロジェクトに取り組んできました。私はまた、Java 1990年代半ばから後半にかけて、専門家が予測した言語は広く採用されることはないが、たまたま何をしたかという、あいまいな新しい言語を使用していくつかのプロジェクトに取り組んできました。そして、私はCobolのカスタム方言で非常に大規模なプロジェクトに取り組んできましたが、今では別の言語が死んでいると言われています。次に、Fortranでやや関わったプロジェクト、QuickBasicでのプロジェクトがあります。 Delphi、今では「主流ではない」に適合するが、当時ははるかに一般的だったすべての言語。
プロジェクトの残りの部分が異なる言語で行われたTILISPでヒューリスティック最適化プロジェクトを実行しました（ CMS2 、知っておく必要がある場合）。
C/Java環境でのemacsLISPスクリプトの同様の使用。