LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@hiroki_fukuoka

【3日目】0から始めるプログラミング学習生活　生成AIによる現代版簡素型Markup-Languageの作成について

Posted at

　さて、学習を始めてから三日目になった。
　本屋に行き、もう一冊参考書を購入。
　平積みされていたので、気になりました。

　とはいえ、先日の書き物からの続きを始めよう。

　HTMLの歴史について、Chat GPTに訊いてみた。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
初期のHTML（1990年代前半〜中頃）は、今のような複雑なウェブアプリのための技術ではなく、論文や報告書のような文書をインターネットで共有するための簡易なマークアップ言語として誕生しました。以下に、その特徴と歴史を整理します。

1. 誕生と背景

  • 発案者: ティム・バーナーズ＝リー（Tim Berners-Lee）
  • 時期: 1991年に最初の仕様（HTML Tags）が公開
  • 目的: CERN（欧州原子核研究機構）内部で研究者同士がハイパーリンクで論文や資料を結びつけて共有するため
  • 影響を受けた技術: SGML（Standard Generalized Markup Language）

2. HTML 1.0 以前の姿

当初のHTMLは、わずか 18個程度のタグ しかありませんでした。代表的なものは次の通りです。

タグ 役割
<html> HTML文書の開始
<head> メタ情報（タイトルやメタデータ）
<title> ブラウザのタイトルバーに表示する題名
<body> 文書本体
<h1>〜<h6> 見出し
<p> 段落
<a> ハイパーリンク
<img> 画像表示
<ul> / <ol> / <li> 箇条書き（順序なし／順序あり）
<pre> 整形済みテキスト
<br> 改行

ポイント: 当時はレイアウト機能（背景色やフォント指定）はほとんどなく、純粋に文章構造を表すためだけの言語でした。

3. 初期の仕様の特徴

  1. 非商業的で学術向け
    HTMLは論文・報告書・メモの共有が主目的。デザイン性よりもリンク性と簡易性が重視されていました。

  2. CSSやJavaScriptなし
    見た目や動きの制御はほぼ不可。背景画像、文字色、アニメーションなどは存在しません。

  3. 非常に寛容な構文
    当時のブラウザは誤ったタグの閉じ忘れにも寛容で、文法的な厳格性は低かった。

4. HTML 2.0（1995年）

  • 初めてIETF（インターネット技術標準化委員会）が標準化
  • フォーム（<form>） が導入され、入力フォームや送信が可能に
  • 電子商取引の基礎となる仕組みが登場
  • この頃から背景色やテーブル表示など、装飾的要素も追加され始めた

5. 当時の制限とデザイン

  • 背景は白、文字は黒、リンクは青（未訪問）と紫（訪問済み）が基本
  • <body background="画像URL"> で背景画像が設定できるようになったのはHTML 3.2頃（1997年）
  • スタイルはタグ属性で直指定（CSS導入は1996〜1997年頃）

6. 歴史的意義

  • ウェブの「読み物」文化の土台を作った
  • ハイパーリンクという概念を普及させた
  • 学術用ネットワークから一般社会へのWeb拡大を促進

もしご希望であれば、1993年当時の実際のHTMLコード例を再現して、どのようにシンプルだったかをお見せできます。
これを見れば、今のHTMLがどれだけ複雑になったかが一目で分かります。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

　なるほど、よく分からない。
　要約すると、HTML初期は、論文などの文書を読むために開発されていた。現在のようなWEBサイトを作成するためのCSSやJavaScriptは導入できなかった。

もし、現代版の生成AIによって、HTMLを車輪の再発明するとしたら、どのような技術が必要ですか？と訊いてみた。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

はい、可能です。しかも「初期HTML」に類する極めてシンプルなマークアップ言語を、生成AIは比較的容易に設計・生成できます。
ただし、「可能」という答えは二つの側面があります — 技術的に可能かと社会的・実用的に意味があるか。

1. 技術的な可能性

現代の生成AIは以下の理由で、初期HTML相当の新しいマークアップ言語を作ることができます。

  1. 文法設計が容易

    • 初期HTMLは十数個のタグから成り立っていました。
      AIはそれを参考に、タグ名・構造・属性を数分で提案可能です。

    • 例:

      <doc>
  <title>私のページ</title>
  <para>こんにちは世界！</para>
  <link url="https://example.com">こちら</link>
</doc>

  2. パーサーやレンダラーの自動生成

    • AIは同時に、提案した文法を解釈するプログラム（パーサー）や表示プログラムもPythonやJavaScriptで生成できます。
    • つまり「言語仕様」と「処理系」を同時に作れる。

  3. ドキュメントやチュートリアルも即時作成

    • マニュアル、入門書、サンプルコードなども自動生成可能。
    • これは初期のHTML開発時より圧倒的に速い。

2. 実用的な意味・注意点

ただし、現代に新規のHTML的言語を作る意味はケースバイケースです。

  • Webブラウザとの互換性
    新しい言語を作っても、ブラウザが理解しなければ表示できません。HTMLは30年の歴史で全世界に普及しているため、置き換えは困難。

  • 用途特化型マークアップの可能性

    • ePubやMarkdownのように、限定領域向けにシンプルなマークアップを作るのは現実的。
    • 例えば、教育用（プログラミング学習用の超簡易Web言語）や社内資料専用のマークアップなど。

  • 生成AI×マークアップの強み

    • ユーザーの要望や目的に合わせて即座にカスタム言語を作る。
    • 既存HTMLやMarkdownよりも学習コストが低い設計が可能。

3. 生成AIで作る「現代版 初期HTML」の例

例えば、研究メモ共有用に作るとすると、こんな仕様が数分で作れます。

文法案

<note>
  <title>実験結果</title>
  <date>2025-08-14</date>
  <summary>AIによる言語設計のテスト</summary>
  <section>
    生成AIはシンプルなマークアップを容易に設計できる。
  </section>
</note>

パーサー生成（Python例）

import xml.etree.ElementTree as ET

def parse_note(file_path):
    tree = ET.parse(file_path)
    root = tree.getroot()
    print("タイトル:", root.find("title").text)
    print("日付:", root.find("date").text)
    print("概要:", root.find("summary").text)

parse_note("sample.note")

4. 結論

  • 作ることは技術的に簡単
    AIはタグ設計からパーサーまで自動生成できる。
  • 汎用Web向けは非現実的
    HTMLの代替は難しいが、特定分野や教育用途では実用的。
  • AI時代ならではの強み
    ニーズに応じたカスタム言語を「その場で作れる」柔軟さ。

もしよければ、次のステップとして
**「1993年当時のHTMLを参考にした、現代版シンプルWeb言語」**を実際に私が作って、動作サンプルコードもお見せできます。
これをやると、AIの言語設計力を体感できます。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーー

　生成AIはweb言語を作れるらしい。
　優秀なプログラマだ。

　とはいえ、まさか、そんな簡単にweb言語が作れるとは思えない。
　バグが多数散見されるだろう。

　プログラム言語を作成するのに、必要な知識を教えてもらう。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
いい質問です。新しい言語づくりは「設計」「実装」「エコシステム」の三本柱で回ります。順番に、必要な知識と技術を要点だけギュッと。

1) 設計（言語そのものの頭脳）

  • 目的設計：何を最優先にするか（安全性/速度/並行性/DSL性/教育用…）。ここが曖昧だと全部ブレます。
  • 構文（Syntax）：字句設計（トークン）、文法（式/文/宣言）。
    代表知識：BNF/EBNF、PEG、曖昧性と前置/中置/後置の扱い、優先順位・結合規則。
  • 意味論（Semantics）：式の評価規則、スコープ/束縛、可変/不変、評価戦略（値渡し・参照・遅延）。
    代表知識：操作的意味論/公理的・指示的意味論、環境モデル。
  • 型システム：静的/動的、型推論（Hindley–Milner など）、代数的データ型、ジェネリクス、エフェクト/所有権モデル。
    代表技術：単一化(unification)、サブタイピング、リージョン/借用チェック。
  • エラーモデル：例外/結果型/チェック例外、型と制御フローの一貫性。
  • 標準ライブラリ設計：最小核（文字列/配列/マップ/入出力）と拡張方針。

2) 実装（言語の身体）

  • 字句解析/構文解析：手書き/パーサジェネレータ（例：ANTLR、PEG系）、インクリメンタル解析の思想。

  • 中間表現（IR）：AST→SSA等のIR。最適化（定数畳み込み、DCE、CSE、インライン化）。

  • 実行方式の選択：

    • インタプリタ（実装容易・遅め）
    • AOTコンパイル（ネイティブ/LLVM）
    • JIT/VM（HotSpot型、Tracing JIT）
    • WASMターゲット（配布容易・安全）

  • コード生成：レジスタ割り当て、呼出規約、ABI、リンク。実務では LLVM を使うと一気に現実的。

  • ランタイム：ガーベジコレクタ（Mark-Sweep、Generational、Arena、RC+サイクル検出）、アロケータ、文字列/配列実装。
    （ここがドラゴン。飼いならせば王国＝言語は安泰）

  • 並行/並列：スレッド/アクタ/グリーンスレッド/async-await、メモリモデル、データ競合の回避。

  • 安全性：未定義動作の排除、境界チェック、型健全性、サンドボックス（WASM/VM）、安全なFFI。

  • ツール連携：デバッガ、プロファイラ、カバレッジ、ビルド/パッケージ。

3) エコシステム（言語が“使われ続ける”仕組み）

  • パッケージマネージャ：依存解決、セムバー、レジストリ設計。
  • LSPサーバ：補完/定義ジャンプ/リント。使われる言語は総じてエディタ体験が良い。
  • ドキュメント/仕様：言語仕様（簡潔・矛盾なし）、チュートリアル、標準エラーの分かりやすさ。
  • 互換性戦略：バージョニング、破壊的変更の手続き、RFCプロセス、テストスイート。
  • ガバナンス：BDFL型/委員会型、提案→実装→安定化の流れ。

進め方のロードマップ（実践的）

  1. 目的を一行で固定（例：「安全な並行処理を“素のコード”で書ける教育用言語」）。

  2. MVP言語の核を決める：式、変数、関数、if、while（or 再帰）、配列/マップ、文字列。

  3. パーサ実装（最初は PEG/LL(1) 等でOK）。ASTを出す。

  4. インタプリタで意味を固める（評価器 + 環境）。テスト大量。

  5. 型付けを導入（動的→静的/局所型推論へ段階的）。型エラーを“教育的に”表示。

  6. IRを設計（SSA風でも簡易3アドレスでも）。小さい最適化を数個だけ。

  7. バックエンド選択：

    • ネイティブ：LLVM
    • ブラウザ配布：WASM
    • JVM/.NET 互換重視：バイトコード出力

  8. ランタイム最小実装：文字列、配列、GC（まずは停止型Mark-SweepでOK）。

  9. ツール整備：REPL、フォーマッタ、LSP（名前解決/型情報だけでも体験が激変）。

  10. 標準ライブラリの核：I/O、コレクション、JSON、時間、HTTPくらい。

  11. パッケージ管理とテストフレームワークを最小で用意。

  12. サンプル集/ベンチ/ガイドを整え、早期ユーザからのフィードバックで設計を“戻す勇気”。

技術選択の定石（ターゲット別）

  • CLIツール＆高速ネイティブ：Parser（手書き or ANTLR）＋ 自作IR → LLVM → 実行ファイル。
  • ブラウザで配布したい：同上 → WASM 出力、または最初から WASM 向けVM。
  • エコシステム活用：JVM/CLRバイトコードに載せる（GC・JIT・ツールを借りる戦略）。

最小実装チェックリスト（MVL：Minimum Viable Language）

  • 字句/構文エラーの親切なメッセージ
  • 変数・関数・制御構文（if/while or 再帰）
  • 文字列/配列/マップ + 基本演算
  • 単体テストランナー
  • REPL（学習・デバッグに最強）
  • フォーマッタ（合意されたコードスタイル）
  • 10〜20本の例題（CLI、HTTP、JSON、並行サンプル1つ）

学ぶべきキーワード（検索の指針）

  • 構文：EBNF / PEG / Pratt parser / incremental parsing / tree-sitter
  • 型：Hindley–Milner / subtyping / GADTs / effect system / borrow checking
  • 実装：SSA / register allocation / calling convention / GC algorithms / escape analysis
  • 最適化：CSE / DCE / inlining / constant folding / LICM
  • 配布：ABI / WASM / JIT vs AOT / sandboxing
  • ツール：LSP / formatter / package manager / fuzzing / property-based testing

私の“強めの意見”

  • まずインタプリタ→あとでLLVM：意味論とエラーメッセージの質が先。速度は後から乗ります。
  • 型エラーは教材：ユーザの“次の一手”を提案するメッセージは、標準ライブラリより価値が出る。
  • “少数の強い特徴”に絞る：全部乗せは失敗フラグ。1〜2個の美点を極端に磨く。
  • ツール体験に投資：LSP/フォーマッタ/REPLが使いやすければ文法の好みは割と許される。
  • 破壊的変更は儀式化：RFC→実装→実験版→安定化。信頼は儀式から生まれる。

必要なら、**「1993年風の simpleWeb 言語」**の設計スケッチ（文法/型/実行系/WASM化まで）を、そのまま着手できる粒度で一式まとめます。どの方向（教育用？DSL？高速系？）でいきます？一言くれれば、即プロトタイプ案まで出します。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーー
　いやいや、分からん。
　よく分からないどころではなく、用語・術語が多すぎて、理解できない。

◆本日のまとめ
　プログラミングが難しいことが分かった。
　でも、自分でもプログラミングの言語を作成できることは理解した。
　長期的目標で、独自プログラミング言語の作成を掲げることにしよう。
　10年学習すれば出来るだろうか。長い学習の旅路が始まる。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?