密接に関わり合っている例として、コンピュータ言語を取り上げてみましょう。

コンピュータ言語
コンピュータ・サイエンス系の学生が、筆者の学生の頃（恐らく今でも）やっていた演習の一つに、言語作り―コンパイラ制作の演習があります。
オートマトンや言語理論を一通り習った後、学生が自分で言語を好きな様に設計して、自分が作った言語の処理系（コンパイラ等）を製作する訳ですが、筆者も学生時代やらされました。

言語の設計そのものは結構楽しく、自由度も高くて好きなように定義できるのですが、あまり複雑な言語体系を作ってしまうと、その処理系（コンパイラやインタプリタ等）を作るのが大変になるので、当時の学生の常として極めてシンプルな言語体系を設計して楽をしようとする傾向がありましたが、あまりシンプルにしてしまうと何も出来ない言語系になったり、あるいはFORTRANのような機械語のニーモニックの様な言語になってしまって面白みが無くなってしまうので、演習担当の助手たちは最低限必要な条件を、演習の最初の頃に提示していました。

当時コンピュータが大嫌いだった筆者も、仕方なく何か適当に言語を定義して（リカーシブ・コール出来る事が必須だった様な気がしますが、かなり記憶が曖昧）、ハノイの塔かアッカーマン関数か何かを計算させていました。

文脈自由言語であれば、当時既にあったyaccなどのツールを使って構文解析部分などサッサと作れるのですが、それも、使用が禁止されていて様な気がします。
また中には、自分の設計した言語で、自分自身のコンパイラを書く、いわゆるコンパイラーコンパイラに挑戦した偉い人もいたと思いますが、うまく行ったかどうかは、全く憶えていません。

しかし、後から翻って考えてみると、この言語の設計製作の演習は、結構有益でした。もちろん、実社会に出ると、実際に言語処理系を作る事は、そういう部署にでも行かない限りは、まずやりませんが、言語そのものは、直接的もしくは間接的に、様々な形で常に付合って行く事になります（UMLも言語体系の一つです）。

当時、システム記述言語（OSや組込み系を記述する言語）として最もポピュラーだったのがC言語でしたが、当時の学生としては、不満が多く（それは、今の学生がC言語に対して持つ不満と殆ど同じだと思います）、さっさと進化して、D言語やE言語が出来て、21世紀当たりだと当然、Z言語か、ひょっとしたら自然言語でシステム記述が出来るのではないかと想像していましたが、残念ながら、21世紀に入って10年近くたった今でも、相変わらずC言語が主流であるとは、当時は想像もしていませんでした。

さて、言語設計が有意義だというのは、つまり、それが「設計」だったからです。
設計というのは、トレードオフを決定する場です。例えば、言語を出来るだけ精密にしようとして数学式の様な言語にすると、プログラミングの生産性が落ちたり、習得に時間がかかったりして不人気となり誰も使わない言語になったりします。また、生産性を上げようとして簡略な表現法を取ると、可読性が落ちてプログラミング品質が劣化したりします。あるいは、品質を上げようとして、プログラミングの自由度を減らし可読性の高い表現方法を採用すると、今度は生産性が落ちたりして不人気になったりします。

設計は、通常唯一解が存在せず、設計者の個性と市場の間のバランスの上に成り立っています。
こうして、言語の使用者（プログラマ）の観点だけではなく、言語の設計者の観点から言語を眺めるのは、学生にとって非常に良い機会だと思います。

そして、設計法や開発論などに代表される方法論（Methodology)を考えるという事は、徐々にサイエンスから工学（エンジニアリング）の分野に足を突っ込んでいく事を意味します。方法論というのは、原理法則とは異なり、絶対的なものではなく、例えばオブジェクト指向設計論に則らなくてもシステムは出来ますし、また大抵の場合、適用分野の向き不向きが存在します。
あくまでも、合目的的な思考です。

ところで、組込み系の1つの主要なシステム記述言語がC言語だとしたら、C++言語はどうでしょうか？
答えは“YES, but..”と少し口ごもった感じになるでしょう。勿論、主流言語の一つである事は間違いありませんが、実は、評判が手放しで良いという訳ではなく、バグを呼び込みやすい言語、使用する上で、注意を要する言語として知られています。

C++言語でプログラミングしたからと言って、オブジェクト指向分析設計をしたとは言えない事は，皆さんご存知だと思いますが、逆も真であり、オブジェクト分析設計をしたからといって必ずしもオブジェクト指向言語でコーディングする必要はありません。

実装言語を何にするかは、対象エリアの特徴を考え慎重に決定する必要があります。
C++言語が要注意と言われる理由の一つはメモリーの使い方であり、例えば、メモリーサイズの小さなシステムでは、C++の動的なメモリーのアロケーションが問題となったり、また、リアルタイム系では、イベント発生から、メモリーをアロケーションしてオブジェクト生成が終わるまでに要する時間が嫌われたりします（このような、現象をさけるために、C++系の組込みシステムでは、シングルトン等を使用し、初期化の際にメモリーを割り振ってしまう事が、よく行われます）。

C++言語のもう一つの問題は、コーディングの自由度の高さです。
先ほど、C++で書かれているからと行って必ずしもオブジェクト指向分析設計をしているとは言えないと言いましたが、中にはそれを遥かに超えて、オブジェクト指向プログラミングでさえない場合もあります。
表現するとすれば、「バレンシア風　スパゲッティ・プログラム　オブジェクト指向香味添え」という様な、一見高級そうな複雑な味わいのプログラムが結構存在します。 勿論、こう言った事は経験の浅いプログラマが犯しやすく、経験を積むに従って無くなって行く問題ですが、プログラミングの現場は、多くの場合、多数派の経験の浅いプログラマと少数の熟練者という形で構成されやすく、それだけ熟練者の負担が重くなって、全体の生産性や品質を下げやすくなってしまいます。

というわけで、言語の設計というのは、言語を考える上で非常に有意義です。先ほど上げましたyaccやlexと言った構文解析ツールも使えますので、コンピュータ・サイエンス系以外の方でも、サンデー・プログラミングで挑戦可能な域にあると思います。

ただ、風変わりな言語体系を作り、その誰にも理解不能な言語を使って自分だけの世界（システム）を構築をするという事は、一歩間違えると漆黒のオタク空間へ吸い込まれてしまい元に戻れなくなってしまう事を意味しますので、耐性が無い方は控えた方が良いでしょう（冗談です）。