タグ付けされた質問 「language-design」

私は最近、プログラミング言語のオンラインコースに参加しました。このコースでは、概念の中でも特にクロージャが紹介されました。質問をする前に、このコースに触発された2つの例を書き留めて、コンテキストを説明します。 最初の例は、1からxまでの数字のリストを生成するSML関数です。xは関数のパラメーターです。 fun countup_from1 (x: int) = let fun count (from: int) = if from = x then from :: [] else from :: count (from + 1) in count 1 end SML REPLで： val countup_from1 = fn : int -> int list - countup_from1 5; val it = [1,2,3,4,5] …

14 language-agnostic  language-design  closures 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 それは少し主観的ですが、どの要因がオペレーターを使いやすくするのか、鈍くて難しくするのかをより明確に理解したいと思っています。私は最近、言語の設計を検討してきましたが、私が常に振り返る問題の1つは、言語の重要な操作をいつ演算子にするか、キーワードや関数をいつ使用するかです。 Haskellは、カスタムオペレーターの作成が簡単であり、多くの場合、新しいデータ型が複数のオペレーターで使用できるようにパッケージ化されるため、これについてはやや悪名高いです。たとえば、Parsecライブラリには、パーサーを結合するための多数の演算子が付属して>.おり、.> 今のような宝石を覚えていますが、今の意味を思い出すことさえできませんが、彼らは実際に意味します。などの関数呼び出しleftCompose(parser1, parser2)は改善されましたか？確かにより冗長ですが、いくつかの点で明確です。 Cライクな言語での演算子のオーバーロードも同様の問題ですが、おなじみの演算子のよう+な意味を通常とは異なる新しい意味でオーバーロードするという追加の問題によって混同されます。 新しい言語では、これはかなり難しい問題のように思えます。たとえば、F＃では、キャストはC＃スタイルのキャスト構文または冗長VBスタイルの代わりに、数学的に導出された型キャスト演算子を使用します。C＃：(int32) xVB：CType(x, int32)F＃：x :> int32 理論的には、新しい言語にはほとんどの組み込み機能の演算子があります。変数宣言の代わりにdef、decまたはvar変数宣言のために、なぜそうでない! nameか、@ nameまたは類似した何か。それは確かに、宣言に続くバインディングを短縮します。@x := 5代わりに、declare x = 5またはlet x = 5 ほとんどのコードは多くの変数定義を必要とするでしょう。 オペレーターが明確で有用なのはいつですか？

14 language-design  operators 

私はJavaを学ぶ初心者です。Javaでは、すべてのソースファイルにパブリッククラスが含まれている必要があり、そのソースファイルはそのパブリッククラスと同じ名前を持つ必要があります。さらに、ソースファイルに2つのパブリッククラスを含めることはできません。この制限はなぜですか？

14 java  language-design 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 9年前に閉鎖されました。 言い換えれば、すべての可能な文字列が有効な構文である言語ですか？ 編集：これは理論的な質問です。そのような言語を使用する ことに興味はありません。私はそれが可能かどうかを尋ねているだけです。 さらに編集する そのような言語を設計しました。ErrorFreeを参照

14 language-design  syntax 

KISS（「シンプルに保つ、バカにする」または「シンプルにバカにする」、例えばこちらを参照）は、明らかに工学に由来するものですが、ソフトウェア開発の重要な原則です。ウィキペディアの記事から引用： 原則は、ジョンソンが設計エンジニアのチームにいくつかのツールを渡したという物語によって最もよく例証されています。したがって、「愚かな」とは、物事が壊れる方法と、それらを修正するために利用できる洗練度との関係を指します。 これをソフトウェア開発の分野に適用したい場合、「ジェット機」を「ソフトウェアの一部」に、「平均メカニック」を「平均開発者」に、「戦闘条件下」を「予想されるソフトウェア開発/保守中」に置き換えます条件」（期限、時間の制約、会議/中断、利用可能なツールなど）。 したがって、後で作業しやすくするために、ソフトウェアの一部をシンプルに（またはコンマを省略した場合は単純な愚かさ）維持することを試みることが一般に受け入れられている考えです。 しかし、KISSの原則はプログラミング言語の設計にも適用できますか？この原則を念頭に置いて特別に設計されたプログラミング言語、つまり「平均的な労働条件の下で平均的なプログラマーができるだけ少ない労力でできるだけ多くのコードを記述および維持できるようにする」ことを知っていますか？ 特定の言語を引用する場合、この意図が言語設計者によって明確に表現されているドキュメントへのリンクを追加できると便利です。いずれにせよ、特定のプログラミング言語に関する個人的な意見ではなく、デザイナーの（文書化された）意図について学ぶことに興味があります。

14 programming-languages  language-design 

List（：+）の追加操作の実行時間は、のサイズに比例して増加することを読みましたList。 に追加することListは、かなり一般的な操作のようです。なぜこれを行う慣用的な方法がコンポーネントを前に付けてからリストを逆にする必要があるのですか？実装はいつでも変更される可能性があるため、設計の失敗にもなりません。 私の観点からは、先頭と末尾の両方がO（1）である必要があります。 これには正当な理由がありますか？

13 language-design  scala  list  immutability 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Haskellのように、Scala OptionタイプがMaybeと呼ばれないのはなぜですか？ 多分私にはもっと「意味論的」になりますが、Optionには私が知らない別の動作があるかもしれません。 ScalaのOptionがMaybeと呼ばれなかった特別な理由はありますか？

13 language-design  haskell  scala  naming-standards  monad 

私はC ++の男ではありませんが、これについて考えることを余儀なくされています。C ++では多重継承が可能ですが、C＃ではできないのはなぜですか？（ダイヤモンドの問題を知っていますが、それは私がここで尋ねていることではありません）。C ++は、複数の基本クラスから継承された同一のメソッドシグネチャのあいまいさをどのように解決しますか？そして、なぜ同じデザインがC＃に組み込まれていないのですか？

13 c#  c++  language-design  multiple-inheritance 

編集：私の言語は、Javaとは異なり、複数の継承を可能にします。 教育、レクリエーション、潜在的に有用な目的のために、独自のプログラミング言語の設計と開発を開始しました。 最初は、Javaをベースにすることにしました。 これは、すべてのコードがクラスの形式で記述され、そのコードがVMによってロードされるクラスにコンパイルされることを暗示しています。 ただし、インターフェイスや抽象クラスなどの機能は必要ないため、除外しました。彼らはパラダイムを実施しているようで、私の言語はそれをしないようにしたいです。クラスをコンパイル単位として保持したかったのは、実装が便利で馴染みがあり、アイデアが気に入ったからです。 それから、クラスをstaticディレクティブを使用して定数と関数を提供する「名前空間」として、またはインスタンス化する必要のあるオブジェクトのテンプレート（「実際の」クラスの目的）として使用できるモジュールシステムが基本的に残っていることに気付きました他の言語で）。 今、私は疑問に思っています：コンパイル単位としてクラスを持つことの利点と欠点は何ですか？ また、私のデザインに関する一般的なコメントは大歓迎です。私の言語に関する有益な投稿は、http：//www.yannbane.com/2012/12/kava.htmlにあります。

13 java  programming-languages  design  language-design 

私は言語設計と「理想的な」プログラミング言語に必要な要素について多くのことを考えてきましたが、GoogleのGoを勉強することで、そうでなければ一般的な知識の多くを疑問視するようになりました。 具体的には、Goはオブジェクト指向言語の構造を実際に持たずに、オブジェクト指向プログラミングの興味深い利点をすべて備えているようです。クラスはなく、構造のみがあります。クラス/構造の継承はなく、構造の埋め込みのみです。階層はなく、親クラスも、明示的なインターフェイス実装もありません。代わりに、型キャストルールはアヒルのタイピングに似た緩やかなシステムに基づいており、構造体が「リーダー」または「リクエスト」または「エンコード」の必要な要素を実装する場合、キャストして使用できます。一つとして。 Goのような言語に移行するときにあきらめなければならない、本質的に機能性、保守性、強力な、C ++およびJavaとC＃で実装されたOOPについて何かありますか？この新しいパラダイムが表すシンプルさを得るために、あきらめなければならないメリットは何ですか？ 編集 読者が過度にハングアップして怒りを覚えるように見える「時代遅れの」質問を削除しました。 問題は、一般的な言語の実装でよく見られる従来のオブジェクト指向のパラダイム（階層など）は、この単純なモデルでは簡単に実行できないものを提供する必要があるということです。または、言い換えると、今日言語を設計する場合、クラス階層の概念を含めたい理由はありますか？

13 programming-languages  object-oriented  language-design  go 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 ほとんどのプログラミング言語には、使用法と適用可能性に影響する設計上の決定事項がいくつかあります。 例えば： Pythonは、コードの保守性/可読性に焦点を合わせ、インデントを言語自体の一部にしました。 Javaの意図は、クロスプラットフォームOOPをC ++より「簡単」かつ「使いやすい」ものにすることでした Objective-Cは、当時のC ++の未来を知らないCのオブジェクト指向ラッパーとして構築されました。 Erlangは、高度なフォールトトレラントな同時システム向けに設計されています Webページの動的作成を処理するために設計されたPHP Javascript の優れた部分を公​​開し、OOPの構文糖を追加し、JSの「舞台裏」などのニュアンス（グローバルなど）を隠すように設計されたCoffeeScript 各プログラミング言語は、特定のニッチなIMHOを活用して活用しようとしました。上記は、プログラミング言語の創立原理であり、それらの進化と広範な採用可能性を支配したものについての私の見解です。もちろん、もっとたくさんありますが、リストは例としてのみ意図されています しかし、Rubyの基礎となる人気の原則とその人気の高まりを理解するのに苦労しました。今日人気のあるRubyの設立原則は何でしたか？それとも、Railsフレームワークを設計した一人の男の天才でしょうか？後者が、RubyがRailsの設計をより良く、より簡単に、より速くしたとしたら？どのような意味で？ その作成者による最も一般的に引用された理由は、「...弱く型付けされた楽しいプログラミング言語を望んでいた」です-新しいプログラミング言語を完全に作成する理由とは思いません！プログラミングは言語に関係なくまったく楽しいです（各言語にはいくつかの悪い部分がありますが、それを回避するか、それと一緒に生活します）。 では、現在の言語では活用されていないRubyの活用法はどのようなニッチなのでしょうか？広く採用されているRubyの「強み」（USP）とは何ですか？Rubyは、これまで行われなかった（または非常に困難だった）ことをしましたか？ 私はRubyプログラマーではなく、単にRuby初心者であり、それゆえ混乱しています。 免責事項：これはフレーム戦争ではなく、Ruby vsプログラミング言語タイプの回答を探しているわけではありません。私は、Rubyのベースとなっているデザインの決定を探しています。Rubyが人気を博したために満足しているニッチとは何か、それは純粋にRailsに起因するものですか？

13 programming-languages  ruby  ruby-on-rails  language-design 

C＃とJavaのバックグラウンドから来た私は、リストが同種であることに慣れていて、それは私にとって理にかなっています。私がLispを取り上げ始めたとき、リストが異種であることに気付きました。dynamicC＃でキーワードをいじり始めたとき、C＃4.0の時点で、異種のリストが存在する可能性があることに気付きました。 List<dynamic> heterogeneousList 私の質問は、ポイントは何ですか？異種リストは、処理を行う際のオーバーヘッドがはるかに大きくなるようであり、1つの場所に異なる型を格納する必要がある場合は、異なるデータ構造が必要になる場合があります。私の素朴さはそのい顔を育てているのですか、それとも異種のリストを持つことが本当に役立つときがありますか？

13 language-design  data-structures  language-features 

Java、Ruby、Haskell、Pythonなどの多くの言語でプログラミングを行ってきました。作業しているプロジェクトが異なるため、1日に多くの言語を切り替える必要があります。今、問題はself、Pythonの関数定義の最初のパラメーターが同じオブジェクトのメソッドを呼び出すことと同じであるため、書くのを忘れることが多いことです。 そうは言っても、このPythonのアプローチには非常に驚かされます。基本的には、JavaやRubyなどの言語では、現在のオブジェクトの変数を自動的に参照することで簡単にできるように、もっと入力する必要があります。 私の質問は、なぜこれがself必要なのですか？それは純粋にスタイルの選択ですか、それともPythonでselfJavaとC ++で省略できる方法を省略できないのthisですか？

13 object-oriented  python  language-design  language-features 

他のいくつかの言語と比較したCの興味深い特徴は、そのデータ型の多くが、絶対条件で指定されるのではなく、ターゲットアーキテクチャのワードサイズに基づいていることです。これにより、特定のタイプでは困難なマシンでコードを記述するために言語を使用できますが、異なるアーキテクチャで一貫して実行されるコードを設計することは非常に難しくなります。コードを考慮してください： uint16_t ffff16 = 0xFFFF; int64_t who_knows = ffff16 * ffff16; int16ビットのアーキテクチャでは（多くの小さなマイクロコントローラーに当てはまります）、このコードは明確に定義された動作を使用して値1を割り当てます。int64ビットのマシンでは、明確に定義された動作を使用して、値4294836225を割り当てます。int32ビットのマシンでは、-131071の値を割り当てる可能性があります（それが実装定義の動作か未定義の動作かはわかりません）。コードは名目上「固定サイズ」タイプであると想定されるもの以外は何も使用しませんが、標準では、現在使用されている2種類のコンパイラーが2つの異なる結果を生成し、今日の多くの一般的なコンパイラーが3番目を生成する必要があります。 この特定の例は、実際のコードでは2つの16ビット値の積を直接64ビット値に割り当てるとは思わないという点で、多少不自然ですが、3つの方法の整数を示す簡単な例として選ばれました。プロモーションは、固定サイズと思われるサイズの符号なしタイプと対話する場合があります。符号なしの型の数学を数学的な整数演算のルールに従って実行する必要がある現実の状況、モジュラー演算のルールに従って実行する必要のある状況、実際にそうでない状況があります問題ない。チェックサムなどの実世界のコードの多くは、算術に依存しており、少なくとも、未定義の動作をトリガーするのではなく、正確なmod 65536として定義されている結果を取得します。uint32_t算術ラッピングmod2³²におり、任意のを実行できます。uint16_t この状況は明らかに望ましくないと思われますが（多くの目的で64ビット処理が標準になると、より多くなります）、私が観察したC標準委員会は、いくつかの顕著な生産ですでに使用されている言語機能を導入することを好みます環境を「ゼロから」作成するのではなく、C言語には、型を格納する方法だけでなく、可能なプロモーションを含むシナリオでの型の動作をコードで指定できる顕著な拡張機能がありますか？コンパイラー拡張機能がそのような問題を解決する可能性がある少なくとも3つの方法を見ることができます。 特定の「基本的な」整数型を特定のサイズに強制するようにコンパイラーに指示するディレクティブを追加します。 ターゲットアーキテクチャ上の型の実際のサイズに関係なく、マシンの型が特定のサイズを持っているかのように、さまざまなプロモーションシナリオを評価するようコンパイラーに指示するディレクティブを追加します。 添加;（特定の特性を有するタイプに関係なく、基礎となるワードサイズの、MOD-65536ラッピング代数環として振る舞うべきであり、他のタイプに暗黙的に変換すべきではないこと、例えば宣言をタイプを宣言する手段を可能にすることによってwrap32には、int得られるはずが16ビットより大きいwrap32かどうかに関係なく、型の結果。ただしint、にwrap32直接aを追加するwrap16ことは不正です（どちらも他方に変換できないため）。 私自身の好みは3番目の選択肢です。なぜなら、異常なワードサイズのマシンでさえ、変数が2のべき乗サイズの場合と同じように「ラップ」する多くのコードで動作できるからです。コンパイラは、型を適切に動作させるためにビットマスキング命令を追加する必要がありますが、コードがmod 65536をラップする型を必要とする場合、ソースコードを乱雑にするよりも、それを必要とするマシンでコンパイラにそのようなマスキングを生成させる方が良いですまたは、そのようなマスキングが必要なマシンで使用できないため、単純にそのようなコードを持っています。しかし、上記の手段のいずれかを介して、または私が考えていない手段を介してポータブルな動作を実現する一般的な拡張機能があるかどうか、私は興味があります。 私が探しているものを明確にするために、いくつかのことがあります。最も顕著な： 望ましいセマンティクスを確保するためにコードを記述する方法は多数ありますが（たとえば、特定のサイズの符号なしオペランドで数学を実行して、明示的にラップするかしないかの結果を得るために実行するマクロを定義する）、または少なくとも望ましくないセマンティクス（たとえば、a が昇格しないコンパイラーで条件付きで型wrap32_tを定義し、その型が昇格するマシンでコンパイルに失敗する必要があるコードの方が、実行して偽の動作をもたらすよりも優れていると考える）将来の言語拡張機能で最も有利に動作するコードを記述する方法がある場合、それを使用することは、独自のアプローチを考案するよりも優れているでしょう。uint32_tuint32_twrap32_t 多くの整数サイズの問題を解決するために言語をどのように拡張できるかについて、かなり堅実なアイデアがあり、コードが異なるワードサイズのマシンで同一のセマンティクスをもたらすことを可能にしますが、それらを書くのにかなりの時間を費やす前にその方向でどのような努力が既に行われたかを知るため。 私は、C標準委員会または彼らが作成した作業を軽disするような見方を決して望みません。ただし、「自然な」プロモーションタイプが32ビットであるマシンと64ビットであるマシンで、数年以内にコードを正しく動作させることが必要になると思います。言語の控えめな拡張（C99 nnd C14間の他の多くの変更よりも控えめ）を使用すると、64ビットアーキテクチャを効率的に使用するクリーンな方法を提供できるだけでなく、バ​​ーゲンでも標準が歴史的に後方に曲げてサポートするために「異常なワードサイズ」のマシン（例えば、12ビットのマシンを可能にするchar、uint32_tmod2³²をラップする]。将来の拡張機能の方向に応じて、デフォルトの整数型が「期待される」ように動作する今日のコンパイラで使用できるマクロを定義できるようになると期待していますが、整数の将来のコンパイラでも使用できますタイプのデフォルトの動作は異なりますが、必要な動作を提供できる場所です。

12 c  language-design  data-types 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 Greenspunの10番目のルール（実際には唯一のルール）は次のように述べています： Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. 私の記憶は、おそらくBorlandのQuattro（スプレッドシート）プロジェクトとおそらく他のもののために、トピックに関するいくつかの論文があるということです。Googleは役に立たず、適切な検索用語が思い浮かばないかもしれません。この主張を支持する論文または記事を探しています。

12 c  language-design  lisp  fortran