帰納プログラミングは，不完全な形式的仕様からのプログラムやアルゴリズムの学習に関する全てのアプローチを含んでいる．帰納プログラミングシステムへの可能な入力形態としては，訓練入力と対応する出力の組の集合や出力評価関数，意図したプログラムの望ましい挙動の記述，トレースすなわち特定の出力を計算する過程を記述した行動系列，得られるプログラムの計算量を考慮した制約，種々の背景知識が挙げられる．背景知識としては，標準的なデータ型，使用する定義済み関数，データの流れや意図したプログラムを記述するプログラムの概形あるいはテンプレート，解の探索を誘導するヒューリスティクスやその他のバイアスが挙げられる．帰納プログラミングシステムの出力は，条件分岐やループや再帰構造を含む様々なプログラミング言語や，その他のチューリング完全な表現言語の形態を取り得る．多くの応用において，出力プログラムは例や不完全な仕様と合致することが要求される．このため，通常完全な仕様を用いる演繹的プログラム合成と対比されて，帰納プログラミングは自動プログラミングやプログラム合成の分野内において特殊な分野と考えられている．場合によっては，帰納プログラミングは，宣言型プログラミングや表現言語を用いることができる，より一般的な領域と考えられることもある．一般の機械学習や，構造マイニングの特定領域や，記号人工知能の領域に見られるように，例の中にある程度の誤りを認めることもある．これらの他分野との明らかな違いの1つは，必要とされる例や不完全仕様の数である．一般に，帰納プログラミング手法は少ない例から学習することができる．帰納プログラミングの多様性は，適用先や使用言語の多様性から来ていることが多い．論理プログラミングや関数プログラミングの他にも，関数論理プログラミング，制約プログラミング，確率プログラミング，abductive logic programming, 様相論理，action language, agent languageや多くの種類の命令型言語など，多くのプログラミング言語や表現言語が，使用され，または使用することが提案されている．
メッセージングは哲学的側面が強いパラダイムである。仕組み的には、オブジェクト（=インスタンス）のメソッドコール、またはオブジェクト間通信におけるリモートメソッドコールと同じものと考えてよいが、メッセージングのパラダイム下では、イメージ的にオブジェクトそのものをメソッドとしてコールする点が異なっている。それは各オブジェクトが一般にレシーバーと呼ばれるデフォルトメソッドを持つ事で実現されている。オブジェクトのコールとは、このレシーバーをコールするのと同義となる。引数無しでコールされる事はなく、基本的に一つのオブジェクトが引数となってコールされる。これも留意すべき点である。元祖オブジェクト指向では「EverythingIsAnObject」の通り、プリミティブからデータストラクチャ、コードブロックまであらゆるプログラム要素がオブジェクトとされる。ここにオブジェクトA、Bがあるとすると、メッセージングの基本構文は「A B」のようになる。これは「Bを引数にしてAを呼び出す」の意味であり、イメージ的に「Aに対してBというメッセージを送る」と形容される。引数Bを受け取ったAのレシーバー内で任意の処理が行われた後に結果値としてのオブジェクトが返される。Aそのものが返される事もあれば、別のオブジェクトが返される事もある。この流れがメッセージングと呼ばれるものである。返値オブジェクトに対して別のメッセージを送る事も可能であり、また返値オブジェクトをメッセージにして別のオブジェクトに送る事も出来る。こうしたメッセージングの連鎖はAのレシーバー内でも同様に行なわれる。メッセージング・パラダイム下でのオブジェクトは言わば独自の記憶を備えた変換式であり、これらオブジェクトのコミュニケーションとは高階関数と第一級関数の仕組みと同じものである。メッセージング・パラダイムの本質はオブジェクトの代数（algebra）化であり、その代数値は前述のメッセージングの連鎖による結果値である。メッセージングを行なうオブジェクトもまたメッセージング連鎖の集合体という事になる。それはただのプリミティブ値であっても決して例外ではない。レシーバーでの処理をコードとすると、メッセージング・パラダイム下でのデータはメッセージング連鎖によるコードの集合体であり、その各コードは他のデータ群を参照しており、その各データもまたコードの集合体～という風になる。勿論最終的には根っことなるオブジェクトの定形データに行き着いてそれが値算出の原点になるが、こうなるとイメージ的にコードとデータが融合して両者の区別はなくなる。オブジェクトは抽象化の一形態である代数的（algebraic）存在なので、代数計算と同様に理念的には単体で成り立つ事はなく、二つのオブジェクトが出会うメッセージングによって始めて一定のプロセスが発生し、または一つのデータが体現される。これが引数無しでもよいメソッドと引数が要るメッセージングの明確な違いである。なお、実装面では便宜上の理由から、メッセージングの際の引数オブジェクトにはセレクタを付けるのが許容されている。大抵は「A selector:B」の様になる。セレクタはメソッド名と同義であり、引数オブジェクトに貼られるラベルと考えていいものである。セレクタによってレシーバー外の対応メソッドに自動分岐されるのでコーディングが簡便になる。演算子も事実上のセレクタであり「5+3」は、+セレクタを貼った3オブジェクトを5に送ると解釈できる。括弧記号はコンパイラのためのただのディレクティブとなる。メッセージングは二つのオブジェクトが出会った時点で発生するプロセスなので引数は常に一つであり、複数の引数を用いたい場合はパーシャルアプリケーションまたはカリー化を適用するべきであるが、これは困難なコーディングになる事が多いので、セレクタによるパターンマッチング的な各メソッドへの自動分岐も許容されている。このメッセージングのパラダイムは様々な理由から広くは認知されず、やがてその言葉だけが一人歩きするようになって本来の定義からシフトし、前述のレシーバーの仕組み自体がメッセージングと見なされるようにもなり、オブジェクト間通信で行なわれるバイトデータ列の送受信もメッセージングの代表例とされるようになった。また、インスタンスの単純なメソッド呼び出しもメッセージングであると説明される事もある。この様にメッセージングの本質は見失われながらも、その側面的仕様は数々のOOP言語に導入されてもいる。