Previous Page | Next Page

次世代のプログラミング言語とは？

AIによって、プログラマーが淘汰されようかという今になって「次世代のプログラミング言語とは何を言っているのか？」と返されそうですが、今とあるプロジェクトをやっておりまして（具体的なことは控えます）、AI時代に必要なプログラミング言語についてより意識するようになってきました。


■ 現在のAIプログラミングの構造


今までのプログラミングとは「人間からコンピューターへの指示」ということでした。ではAI時代になると何が変わるのでしょうか。


現状、AIを使ったプログラミングは次のような形になります。


人間 → [自然言語（プロンプト）] → AI → [プログラム] → コンピュータ


■ 次世代言語という発想


これについてまず考えられるのは、次のような形です。


人間 → [次世代言語] → AI → [プログラム] → コンピュータ

つまり、人間とAIの間に共通言語を持てないか、という発想です。


さらにいうと、


人間 → [次世代言語] → AI → [次世代言語] → コンピュータ

ここまで踏み込めれば、AIが生成した内容も（原理的に）人間が確認可能になります。
つまり、問題が発生したときに「何が意図されていたのか」を追跡できるようになります。



■ 想定される批判


ここで当然、次のような批判が出てきます。


人間 → [次世代言語] → AI
AI → [次世代言語] → コンピュータ

同じ言語を使うのであれば、AIは人間が入力した内容をそのまま返すだけではないか、というものです。


実際に、そういうことは起こり得るでしょう。



■ それでも何が便利なのか？


ポイントは、人間・AI・コンピュータの間で共通言語を持つこと自体にあります。


自然言語ではなく、このような言語を想定する理由は以下のとおりです。


  • 表現にムラがなく、曖昧性を排除できる
  • 最終的に機械で実現可能な形に落とし込める

一方で、従来のプログラミング言語との違いは、


  • 人間が理解可能な抽象度を保つこと

にあると考えています。



■ 実は新しくない発想


このアイデアは一見すると突飛に見えるかもしれませんが、実は全く新しいものではありません。


第5世代コンピュータで目指されていた、論理型言語の思想に近いものです。


論理型言語の代表格であるPrologは、当時日本でも注目されました。
また、このブログでたびたび触れているADPも、Prologをベースとしています。


また、Grokに言わせるとLLMとPrologをつなぐアイデアは既に研究対象となっているようです。AIに聞けば多数出てくるようです。下記面白そうなもの2点をピックアップします。


・Arithmetic Reasoning with LLM: Prolog Generation & Execution
LLMが自然言語の算術問題からPrologの述語・ルールを生成し、Prologインタプリタで実行。CoT（Chain-of-Thought）より精度が大幅に向上した実験。


・LLM and Prolog: the logical alternative to chain-of-thought reasoning (Medium, 2025)
金融領域での実践例。LLMが自然言語からPrologルールを抽出し、シンボリック推論エンジンで処理。非常に読みやすい解説。


そりゃPrologを知っている人なら絶対に考えるよなという話ですね。



■ 宣言的という考え方


Prologのような言語は「宣言的」と呼ばれます。


つまり、


  • 「何を作るのか？」にフォーカスする
  • 「どう作るのか？」は実行系に委ねる

という考え方です。


現在のAIによるコーディングもこれに近く、人間が「何を作るのか」をプロンプトで与え、「どう作るか」はAIが担っています。



■ 批判への一つの答え


この役割分担を前提とすると、


「AIは入力をそのまま返すだけではないか」


という批判にも、ある程度対応できます。


もう少し踏み込んだイメージとしては、


  • 人間は「満たすべき条件」（述語）を定義する
  • AIはその実装（述語の本体）を生成する

という形です。


ここでいう「述語」は論理型言語の用語で、「関数」に近い概念です。


処理手順ではなく「満たすべき条件」を中心に表現することで、結果の妥当性を人間が確認しやすくなります。



■ 現実的な課題


とはいえ、このような構想は「言うは簡単で実現は難しい」ものです。第5世代コンピュータプロジェクト自体が頓挫した経緯もあり、AIを使えば当時の問題は解決できるのか？という問いは依然として残ります。

具体的には、


・人間に読みやすいと言ってもPrologはコンピュータよりの言語である。
・宣言的といっても、それだけですべてが上手くいくわけではない。Prolog自体が流行っていない。
・現実案としては、コメントがAIに対する補足（プロンプト）になるが、そうすると自然言語が残ることになる。


というジレンマがあります。特に「宣言的プログラミング」とは当時一瞬流行ったパラダイムになりますが、純粋さを追求すると却ってコードを分かりにくくする側面があります。またAIの出力は手続き的にもなりえます。このあたりの折り合いをどうつけるのかというのが課題かと思います。

このような「純粋な理論」と「現実の泥臭さ」の板挟みを解決するために、私は一つのアプローチをとっています。例えば、ADPは、Prologをベースにマルチパラダイムを追求しています。つまり純粋な宣言的なパラダイムを捨てて、手続き的にも書けるようにしています。このあたりの落としどころが現実的ではあるかと思います。



■ 最後に


もっとも、私自身も30年ほど前にこうしたアイデアの断片を考えたことがあります。


さらにいうと、ADPの機能として次世代言語に必要な要件を備えることができれば、ADPそのものが次世代言語になり得るのではないか、とも思っています。


夢は広がりますが、まずは時間を見つけて少しずつ形にしていきたいところです。


2026-04-06 | コメント:0件

What Is a Next-Generation Programming Language?

■ The Structure of AI-Assisted Programming Today


Traditionally, programming languages have been a way for humans to instruct computers. So what changes in the AI era?


Today, AI-assisted programming typically looks like this:


Human → [Natural Language (Prompt)] → AI → [Program] → Computer


■ The Idea of a Next-Generation Language


From here, one natural idea is:


Human → [Next-Generation Language] → AI → [Program] → Computer

In other words, can we introduce a shared language between humans and AI?


Taking this a step further:


Human → [Next-Generation Language] → AI → [Next-Generation Language] → Computer

If this were possible, then—even in principle—humans could verify what the AI produces.
When problems occur, we could trace and understand the original intent behind the system.



■ Expected Criticism


At this point, a natural criticism arises:


Human → [Next-Generation Language] → AI  
AI → [Next-Generation Language] → Computer

If the same language is used on both sides, wouldn’t AI simply return what the human provided?


In fact, this can certainly happen.



■ So What’s the Benefit?


The key point is the value of having a shared language across humans, AI, and computers.


Why not just use natural language?


  • It introduces inconsistency and ambiguity
  • It is not directly executable by machines

A next-generation language would instead aim to:


  • Eliminate ambiguity
  • Be directly translatable into executable form

And compared to traditional programming languages, the key difference would be:


  • It maintains a level of abstraction that humans can understand


■ Not Actually a New Idea


This idea may sound radical, but it is not entirely new.


It is closely related to the concepts explored in logic programming languages during the Fifth Generation Computer era.


For example, Prolog—one of the most well-known logic programming languages—was once widely discussed in Japan.
The language I’ve mentioned occasionally in this blog, ADP, is also based on Prolog.



■ The Declarative Approach


Languages like Prolog are often described as declarative.


That means:


  • Focus on what should be done
  • Leave how to do it to the execution system

Interestingly, modern AI-assisted coding follows a similar pattern:
humans specify what they want, and AI handles how to implement it.



■ A Possible Answer to the Criticism


If we properly recognize this division of roles, we can respond to the earlier criticism that “AI would just return the input as-is.”


A more concrete idea would be:


  • Humans define conditions—what must be satisfied (predicates)
  • AI generates the implementation (the body of those predicates)

Here, a “predicate” is a concept from logic programming, somewhat similar to a function.


Instead of describing step-by-step procedures, we describe conditions to be satisfied.
This makes it easier for humans to verify whether the result is correct.



■ Practical Challenges


Of course, this kind of idea is much easier said than done.
The Fifth Generation Computer project itself failed, which raises the question:


Can AI solve the challenges that existed back then?


More concretely, several dilemmas remain:


  • Even if we aim for human readability, Prolog is still closer to a machine-oriented language
  • Declarative approaches alone do not solve everything—Prolog itself never became mainstream
  • In practice, comments may act as prompts for AI, which means natural language still remains in the system

This creates a fundamental tension.


Declarative programming was once a briefly popular paradigm, but pushing it too far can make systems impractical.
At the same time, AI-generated output can also be procedural.


How to balance these aspects remains an open challenge.



■ Final Thoughts


That said, I personally had fragments of this idea over 30 years ago.


And if the language I’m developing—ADP—can incorporate the necessary characteristics of such a next-generation language, it might itself become one.


It’s an ambitious thought, but for now, I’ll continue working on it little by little, whenever time allows.

2026-04-05 | コメント:0件

Visual C++ 2022 でも regex の multiline はサポートしない

時が流れるのも早いもので、ADPの開発に使用しているコンパイラをVisual Studio 2012 に変えてから10年が経とうとしています。
途中、一度Visual Studio 2017 C++を試したのですが、regex がboostのモノと挙動が違うらしく（$を行末とするにはmultilineサポートが必要とのこと）、この時はVisual Studio 2012に戻した。

最近、OSをWindows 11に変えて、『いい加減コンパイラも変えるか』ということで、Visual Studio 2022 の C++に変えました。
ちなみにVisual Studio 2012 は Professional を購入しましたが、Visual Studio 2022 は Community版 をインストールしました。
まぁ仕事で使うようになったら Professional を購入します。
Visual Studio は 2003、2008、2012と一つ飛ばしで買っていましたが（2012は不本意ながら、2008がWindows8で動かなかったから買った記憶があります）、その後、Visual Studioを使うのも ADP と SQL Server 2012 の開発用となったので、特にバージョンアップをしないで、だらだらとしていたら気が付けば、2013、2015、2017、2019、と結構なスキップとなりました。

気が付けば、Gitに対応していたり、なかなかの変わりっぷりですが、C++の開発関係はあまり変わらずでよかったです。
もっとも、C++言語の方が、C++11、C++14、C++17、C++20 と今迄の停滞はなんだったんだというぐらいに変わっているので如何したものかと思う。
一部、最適化に関わる部分（右辺値参照とか）があるので無視するわけにはいかず、コード自体は今後、変えていこうかと思います。
ちなみに長く止まっていた、C言語の方もC11やらC17やらに対応しているらしく（単にプロジェクトのプロパティを見ただけ）、C言語に徐々に書き換えるのもありかと思う今日この頃です（現実的ではないですが）。

新しい規格への対応で、1点、期待していたものが regex がありました。ADPは boostライブラリの regex を使っていたのですが、そのregex がC++11から規格に入り C++17 ではmultilineをサポートしたものになっていました。あくまでも個人的な趣味もありますが、私的には $ を行末としたいのですが、それまでのC++ の 標準regexは$はあくまでも文字列の最後という扱いでした。multilineで$が行末とみなしてくれるようになります。
ということで、さっそく試してみたのですが、VC 2022 ではどうも、multilineに対応していないようでした。
「なんでやねん」ということで、色々検索してみましたが、以下、Microsoft のDeveloper Communityの投稿を見つけました。

multiline [C++]

同じようなことを感じた人が投稿したらしいのですが、Visual C++の開発者と思われる方のコメントで、要約すると『規格制定で色々あったのですが、現在のところABIの破壊がないようにするために、このような実装となっています。回避策として引き続きBoostのRegexを使ってください、その方が挙動が一貫しているだけでなくパフォーマンスも良いです（意訳）』とのことです。

BoostのセットアップがVisual C++の環境では面倒なのですが、Boostも一緒にバージョンアップし（1.45 → 1.80）Visual C++ 2022の環境に移行しました。ちなみにコンパイラを変えただけではパフォーマンスが変わることは特になかったです（AVX等の命令を使うように変えればまた違うかもしれませんが・・・）。
2022-09-19 | コメント:0件

RYZEN

2020年もすっかり明けて２月になりましたが、年明けに１０年ぶりにPCを更新しました。
ちょうど１０年ほど前に、購入するPCの世代を統一しようと初代Core i7でソケット1366に決めたのですが、そこからCore i7-980Xを３つ程とi7-920を入手し４台のPCがあるわけですが、その後継ということでZEN2世代のRYZENに決めました。
Core i7を買ったときはちょうどWindows7に乗り換えた時でそこから8,10ときて、ここ2，3年は自分のPCがもっさりしていてグラフィックカードを変えたりしていましたがやっとこさ全とっかえができました。

今回はインテルからAMDに乗り換えたのですが、長いPC歴でちょこちょこAMDを使っています。今までメインマシンで使ったCPUを思い出すだけ書き出すと、こんな感じになります。

1984 （不明）ポケコンPB110
1985 uPD780(Z-80相当品) NEC
1989 80286相当品 AMD
1989 V30 NEC
1992 i486SX(J) Intel
1994 Am486 SX2-66 AMD
1996 Pentium 133 Intel
1997 MMX Pentium 166 Intel
1998 K6 AMD
1998 K6-2 AMD
1998 M2 Cyrix
1999 K6-III AMD
2000 Pentium III 600 Intel
2000 Pentium III 1000 Intel
2002 Celeron 1.4(PentiumIII系） Intel
2003 Celeron 2.3(Northwood-128K) Intel
2003 Pentium4(Northwood) Intel
2004 Athlon 64 3000+ AMD
2006 Pentium D 805 Intel
2006 Core 2 DUO E6400 Intel
2008 Xeon X3350(Core 2 Quad) Intel
2009 Core i7 - 920 Intel
2010 Core i7 - 980X Intel
2020 RYZEN9 3950X AMD

年号は大体ということで割といい加減です。その時の懐事情と趣味とその他諸事情で買い集めたり絞ったりしていましたが、こうしてみると2010年代のスキップぶりが半端ないですね。Core i7についてはSandy Bridge世代でそろえればよかったと少し後悔して、AMDからZenマイクロアーキテクチャが出る噂を聞きつけたときに様子見をしてZen2になったところで「行こう！」となった感じです。

話は戻って、初めての16ビット、32ビット、64ビットCPUは、AMDになります。初めての16ビットパソコンはPC-9801RXでしばらくはIntelを使っていると思っていたのですがあるときに中を開けてみたらAMDのCPUでした。よくよくカタログをみたら80286相当品と書かれていてものすごくがっかりした記憶があります。初めての32ビットCPUは、i486SX(J)と思いきや、このCPUは外部バス16ビットで、それを初めて知った時のがっかり感は半端なかったです。そのあとに買ったパソコンが今はなきコンパックのPresario CDS 524でこちらもメモリの増設で筐体を開けた時にみたらAMDでまたもやがっかりした記憶があります。その後、懐事情が改善し自作に移行して狂ったように買いましたが、初めてのDual-processor, Dual-core, Quad-core, Hexa-core はIntelになります。
RYZEN9は、初めての16-core（書き方を探すのが面倒）、PCI-E Ver4.0(Ver3.0はスキップ）、DDR4-RAM、UEFIです。利用面からは、初めてのCPUプロファイラ（AMDuProf）を使うプロセッサになります。CPUはキャッシュミスとか分岐予測ミスとかが発生すると内部のカウンタで記録をとるのですが、それを読み出すソフトウェアがCPUプロファイラということになります。有名どころではIntelのVTuneがあるのですがこのソフトがめっぽう高くCPUと合わせての購入となると個人では手が出しにくいです。AMDの方はなんと無料ということでまぁAMDということになりました。
そんなものを何に使うのか？と言われそうですが、もちろんADPのインタプリタ部分で、当初はVisualStudio付属のプロファイラを使って最適化を行っていましたが、いろいろ私に合わず、『V-Tuneかー』と思っていたところへ、CodeXL(AMDuProfの前身)の存在を知り、CodeXLに乗り換えたのが5年ほど前になります。CPUがIntelの場合、プロファイラは命令毎にかかった時間が分かるのですが具体的な原因（キャッシュミスなのか？ブランチペナルティか？とか）までは分からずそのあたりは手探りになっておったのがこれでばっちりと分かるようになります。早速プロファイルをしてみると、



パットと見てよくわからない指標があるのでカウンタの意味についてはお勉強が必要なようです。例えばハイライト部分はただの代入になるのですが、それでなぜRet branchとかが関係するのか？（おそらく他のブランチとの関係で結果的に実行された／なかったとか言いたいのかもしれないのですが・・・）とか直接的でないところがあります。

ここにきて、ADPの実行ファイルサイズは約1MBになりますが、今まではプログラムやデータのメモリへの配置はコンパイラに任せていましたがそろそろそういったところまでも手を出す必要があるのかなと思っています。といっても具体的にどうするのか？という話ですが、先ずCPUプロファイラを使いながら基礎データを集めてその上でソースコードを再編集したり、インタプリタ本体を抜き出してミニマムなプログラムを作ってプロファイルをかけたりいろいろ実験ができそうです。

ちなみにこういった話をすると『じゃアセンブラで組めや！』と言われかねないのですが、まぁうざい煽りに真面目に答えると、要は今のプログラムはCPUの潜在能力を十分に生かし切れていないので工夫の余地があり、上手くいけば数倍早いプログラムが作れるということになり、2020年現在ではシングルスレッド性能で数倍といえば時間軸に置き換えると10年以上先に行けるという話になります。

どういうことかと言いますと、例えば1989年に出たi486DX（33MHz）と2000年に出たPentiumIII(1GHz）の性能比は、単純にクロック周波数で見ても30倍（実際はそれ以上）になります。次いで2010年に出たCore i7-980X（3.33GHz、ブースト3.6GHｚ）とPentiumIII(1GHz)との性能比は、クロック周波数でみて約3.3-3.6倍と伸び率が10分の１程度に減速しています。そして今回のRYZEN9 3950X（3.5GHZブースト4.7GHZ）とCorei7-980Xはクロック周波数ではブースト時で比較して1.3倍、実際に手元にあるADPのプログラムを動かしてみると整数演算で2倍となっています。つまり、それまでは最新のCPUと言えば以前のCPUより格段に速くなって10年も経てば桁違いの速さを見せたのですが2000年代の中盤頃からそのスピードが止まり、今では10年で2倍のパフォーマンスアップに留まることになります。
つまり今まではプアなプログラムを組んでも時間が経てば解決してくれるのですが、これからはきちんと考えて作らないとダメということになります。

CPUプロファイルの話はこの辺にしておいて、今回もう一つ試したいことがあるのが、仮想マシンの活用で今回、私が使う必要のあるプログラムの一部（eTaxとか弥生会計とか）を仮想マシンの方へ移しました。今までは再セットアップとなるとこれらのソフトを再インストールしなければならなくなり面倒なだけなのですが、それが不要となり気軽に再セットアップができるようになるので便利です。欠点としてはOSやらその他のライセンスがインストールするマシンの台数分必要になることと、RYZEN9 3950X特有かもしれませんがCPUプロファイルとの共存ができない（切替にUEFIレベルで設定変更が必要になる）ことでCPUプロファイルを取りたいときはいちいちマシンを再起動することになります。

2020-02-02 | コメント:2件

今週の英語勉強（7/13）と久しぶりのADPの開発

英語の勉強は今週の前半は順調だったが、週の後半に夏休みをとり久しぶりのまとまった時間がとれたので、ADPの開発にいそしんだ。ので週の後半、英語の勉強はおろそかになった。
　ADPのパフォーマンス改善に取り組んだが上手くいかなかった。生成されるコードを読むかぎりC++では厳しくなってきてCで組みたくなってきたこの頃である。仮想関数やテンプレートは便利な反面どういったコードが生成されるか読みきれないところがあり（ビジターパターンで実装している多重ディスパッチの最適化の為、メンバ関数ポインタを用いて２つのクラスにまたがる仮想関数に対して自前の仮想関数テーブルを作ったが、VCでは余分なJUMP命令が挟まれパフォーマンス改善が今一つだった）、パフォーマンスを追及するには結局のところCの方がよいと実感する今日この頃であるが、全てをCにするのはそれはそれで厳しいので悩みどころではある。
　話を英語に戻すと３日程サボったことになるが、たった３日サボっただけだが全体的に勉強していて実力が下がった気がする。少しづつでもよいので毎日勉強した方がよいようだ。また６月の末に音読の授業が終わったのだがそれを補完するメニューが必要と思うが、今週から単語の問題集を取り入れたので時間が足りなくなった。日曜日の午前中はテレビを見て過ごしていたが今週は英語勉強で潰れてしまった。とくにワイドナショーが見られなかったのが残念だ（まぁ夜に見た）。

(1)単語
　出る順パス単　英検準１級　１週目　 1120(+200)
　出る順パス単　英検１級　　１週目　 1440(+200)
　学校提供単語帳　単語 180(+20)、述語 140(+20)
　学校提供問題集（PartI対策）第1回 6/25(1回目）,15/25(2回目）
　学習時間はパス単が４時間/週。学校提供の単語帳が２時間/週。問題集が３時間。学校提供の単語帳の進捗が特に悪いが来週から学校が始まるのでパス単の比重を下げてこっちを勉強しようかと思う。
また学校提供の問題集をやった。この問題は4択で単語を選ばす問題が25問あり計100個の単語が出てくるが、1回目は9割が知らないと思った単語だった。が答え合わせ後、一つ一つ辞書で調べたところパス単や単語帳でやったことを思い出したものが4割ほどあり、計5割程度は既出のものだった。結構忘れていることに驚くが、問題をやった後はそのままにせずに、復習することも重要であることを知った。そのあと2回目を行ったが結果をみると完全には覚えきれていない。金曜日の晩にでも復習と3回目のテストをやってみようかと思う。
　今週の英語の語彙力レベル測定テストの各種テスト結果を載せます。総合判断のスコアが先週から落ちたが勉強をサボったからか、もっとも問題自体は解らない単語が多く出たので妥当な結果だと思うが、準１級が『合格多難』と言われているので疑問がのこることろではある。
実は先週、会員登録をしたのだが、会員と非会員では出題アルゴリズムが異なるのかもしれない（ってわけないか）


(2)RADIO JAPAN
　今週は21時のニュースを概ね3回ずつ聞いた。理解度は３０％程度、学習時間は２時間/週。
週の前半はだいぶ聞き取れるようになったがしばらくサボった後に聞くと元に戻った。特に聞いていると違和感が出てきた。毎日きちんと聞いて練習する必要があると実感した。
　印象に残ったニュースは、首相（Prime minister）のオセアニア訪問。集団的自衛権（collective defense）の説明とオーストラリアとのEPA交渉。そして土曜日に帰ってきた。中国の監視船（patrol ships)が尖閣沿岸に侵入した。
ちなみに、patrol shipsが最初聞き取れなくて（ペイトレールシプスのように聞こえた）何回か聞き直した。

(3) 工業英検２級過去問
　80回をやった。時間切れになることはなくなったが、筆記試験なので、解答を見てもどの程度の得点が取れているか今一つよくわからない面がある。英訳、日本語訳共に模範解答と比べると自分の答えは稚拙な感じは否めないがそれがどの程度減点になるのか今一つ解らない。まぁ受ければ結果が出るのでそれで解るからよしとする。文章をつなげる問題と簡略化させる問題は計10問中7問が合っていた、少し低いか。

2014-07-13 | コメント:0件
Previous Page | Next Page