2024年JSF(Jakarta Faces)をTomcatで試すメモ

JSF(Jakarta Faces)をTomcatで試すメモ
Jakarta Faces」って長いので、ここではJSFって書きます。

Tomcat用のプロジェクトがあるとして追加する、って感じで書くので、基本的な構成は省略。
Tomcat 10.1.24で試してます。
https://tomcat.apache.org/download-10.cgi

最初から構成を作るのであれば、Quarkusが無難かなぁという気はする。
その場合はstarterでPrimeFacesを選ぼう。
https://code.quarkus.io/

Jakarta EEがよければ、Eclipse Starter for Jakarta EEで。そうするとPlatform ProfileかWeb ProfileであればJSFは含まれるので設定不要のはず
https://start.jakarta.ee/

Springとは相性がわるいです、たぶん。

設定

ということで設定

mojarra組み込み

今回はJSFの実装にはmojarraを使います。
導入方法はREADME.mdにだいたい書いてあります。
https://github.com/eclipse-ee4j/mojarra/blob/4.0/README.md

Bean Validator使いたかったら最新バージョンを指定しろと書いてあるので、もし使いたければここで調べましょう。8.0.1が最新かな。
https://mvnrepository.com/artifact/org.hibernate.validator/hibernate-validator

けど、必要なものだけであれば次のふたつをdependencyに追加すればよさそう。CDIに依存するようになったので、weldも組み込みます。

<dependency>
    <groupId>org.glassfish</groupId>
    <artifactId>jakarta.faces</artifactId>
    <version>4.0.7</version>
</dependency>
<dependency>
    <groupId>org.jboss.weld.servlet</groupId>
    <artifactId>weld-servlet-shaded</artifactId>
    <version>4.0.0.Final</version>
</dependency>

mojarraではなくMyFacesを使ってもいいと思う。Quarkusだとこちらになるはず。
https://myfaces.apache.org/

web.xmlの設定

web.xmlにFacesServletの設定が必要になります。

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="6.0" xmlns="https://jakarta.ee/xml/ns/jakartaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd">
    <context-param>
        <param-name>jakarta.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
        <!-- <param-value>Production</param-value> -->
    </context-param>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>jakarta.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>
</web-app>

beans.xml

CDIを有効にするためにbeans.xmlが必要です。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="https://jakarta.ee/xml/ns/jakartaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/beans_4_0.xsd"
       bean-discovery-mode="all">
</beans>

試しに動かす

じゃあ動かしてみましょう。

faceletを書く

画面をfaceletとして書きます。
hello.xhtmlとして保存。

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="jakarta.faces.html"
      xmlns:f="jakarta.faces.core">
    <h:head>
        <title>Facelet Title</title>
    </h:head>
    <h:body>
        <h1>Hello JSF</h1>
        <f:view>
        <h:form>
            <div>
                <h:inputText id="in" value="#{helloBean.input}"/>
                <h:commandButton value="Hello" actionListener="#{helloBean.go()}">
                    <f:ajax execute="in" render="out"/>
                </h:commandButton>
            </div>
            <h:outputLabel id="out" value="#{helloBean.message}"/>
        </h:form>
        </f:view>
    </h:body>
</html>

管理ビーンを作る

処理をするための管理ビーンを書きます。

package example;

import jakarta.enterprise.context.RequestScoped;
import jakarta.inject.Named;

@Named
@RequestScoped
public class HelloBean {
    private String message = "Hello!!!";
    private String input = "";

    public String getMessage() {
        return message;
    }
    public void setMessage(String message) {
        this.message = message;
    }
    public String getInput() {
        return input;
    }
    public void setInput(String input) {
        this.input = input;
    }
    
    public void go() {
        message = "hello " + input;
    }
}

実行

うごいた

コンポーネント型Java WebフレームーワークZKをSpring Bootと一緒に試すメモ

ZKという、コンポーネント型のWebフレームワークがあって、ちょっと面白そうなので試してみた。
https://www.zkoss.org/

コンポーネント型なのでJSFが近い。
とりあえず始め方がここにいろいろある。
https://www.zkoss.org/wiki/ZK_Installation_Guide

プロジェクト作成

まあ、結局Spring Bootと一緒に使うことになるだろうから、Spring Bootで始めるやつを見る。
https://www.zkoss.org/wiki/ZK_Installation_Guide/Quick_Start/Create_and_Run_Your_First_ZK_Application_with_Spring_Boot

まずSprig Bootのプロジェクトを作る。
https://start.spring.io/

Dependencyは何もいらないということなので、そのまま。

Spring MVCなどはZKの依存ライブラリとして入ることになる。

で、pom.xmlにrepositoryの追加。

 <repositories>
        <repository>
            <id>ZK CE</id>
            <name>ZK CE Repository</name>
            <url>https://mavensync.zkoss.org/maven2</url>
        </repository>
    </repositories>

あと、dependencyを追加。

     <dependency>
            <groupId>org.zkoss.zkspringboot</groupId>
            <artifactId>zkspringboot-starter</artifactId>
            <type>pom</type>
            <version>3.2.3</version>
        </dependency>

ドキュメントには、${zkspringboot.version}の部分はmavenレポジトリを確認してくれと書いてあったので、ここにある最新っぽい3.2.3を指定。
http://mavensync.zkoss.org/maven2/org/zkoss/zkspringboot/zkspringboot-starter/

最初の画面を作る

ではZKのコードを書いてみる。zulという拡張子でXMLを書くらしい。
ドキュメントをそのままコピペ。してsrc/main/resources/web/hello.zulに保存

<zk>
    <window title="Hello ZK - Spring Boot!" border="normal">
        You are using ZK version <label value="${session.webApp.version}"/>
    </window>
</zk>

あと、src/main/resources/application.properties ファイルに設定を一行追加

zk.homepage=hello

で実行やーと思ったらorg.zkoss.zk.ui.http.HttpSessionListenerがないというClassNotFoundが・・・。

zkspringboot-starter.3.2.3のPOMを見るとzkbindがprovidedになってるのでプロジェクトに含まれない。provideされてないし。

ということで、自分のpom.xmlにzkbindも追加。zkspringboot-starterにあるものからscopeを取り除いただけ。

     <dependency>
            <groupId>org.zkoss.zk</groupId>
            <artifactId>zkbind</artifactId>
            <version>10.0.0-jakarta</version>
            <exclusions>
                <exclusion>
                    <groupId>org.slf4j</groupId>
                    <artifactId>slf4j-jdk14</artifactId>
                </exclusion>
            </exclusions>
        </dependency> 

改めて起動したらlocalhost:8080にアクセスしたら動いた!

独自のファイルを追加する

では独自のファイルをsrc/main/resources/web/world.zul に置いてみる。

<zk>
    <window title="My Page" border="normal">
        It works!!
    </window>
</zk>

で、localhost:8080/worldとかにアクセスしてもNot Found。
どうやってアクセスすればいいのか全然わからなかったのだけど、サンプルコードとか見てたらコントローラーかかないといけないっぽい。

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class HelloController {
    @GetMapping("/helloworld")
    public String hello() {
        return "world";
    }
}

なんかダサいな。パスをそのまま返すコントローラを作ることになりそう。
ドキュメントさがしたら、ここにあった。
https://github.com/zkoss/zkspringboot/blob/master/README.md

改めてコントローラのパスにアクセスしたら見れた。

Javaコードと結び付ける

じゃあ、ボタン押したらなにかJavaのコードを呼び出すっていうのをやろう。
それっぽいタグを書いてコンポーネントを置いてみる。idをちゃんと指定しておけばどうにかなる。

<zk>
  <window title="My Page" border="normal"
      apply="com.example.demo.HelloComposer">
    It works!!
    <vlayout>
      <hlayout>
        <textbox id="input"/>
        <button id="exec" label="Go"/>
      </hlayout>
      <label id="output" value="hello"/>
    </vlayout>
  </window>
</zk>

コンポーネントはこのリファレンスに。
https://www.zkoss.org/wiki/ZK_Component_Reference

そしたら対応するJavaコードを書く。クラス名をwindowタグのapplyに指定している。このクラスはSelectorComposer<Component>を継承する必要がある。

package com.example.demo;

import org.zkoss.zk.ui.Component;
import org.zkoss.zk.ui.select.SelectorComposer;
import org.zkoss.zk.ui.select.annotation.Listen;
import org.zkoss.zk.ui.select.annotation.Wire;
import org.zkoss.zul.Label;
import org.zkoss.zul.Textbox;

public class HelloComposer extends SelectorComposer<Component>{
    @Wire
    private Label output;
    @Wire
    private Textbox input;
    
    @Listen("onClick = #exec")
    public void go() {
        output.setValue(input.getValue());
    }
}

あとは、コンポーネントに対応するフィールドを定義して@Wireアノテーションを貼る。フィールド名はたぶんIDと同じ名前にする必要がある。違う場合はアノテーションに指定すればいいのかもしれないけど試してない。
イベントハンドラには@ListenをつけてonClickにボタンのIDを指定する。

実行したら動いた!

Spring Bootとの組み合わせはJSFよりもやりやすい。
結構よさそうなんだけど、コンポーネントベースのフレームワークを使いたいのは企業の社内システムで、そうするとJEEアプリケーションサーバーをたててそうだし、いろいろ考えるとJSFがいいかなぁ。

Javaで最低限おさえておいてほしいクラス・インタフェース35 - 2024年版

ま、このくらい知っておいてもらわないと&とりあえずこんだけ知ってればだいたいの処理が書けるクラス・インタフェースをまとめてみました。2024年版。
詳しく知りたい人は「プロになるJava」を!

java.lang.Class
java.lang.Exception <- new
java.lang.Integer
java.lang.Object <- new
java.lang.Runnable
java.lang.String
java.lang.System
java.lang.Thread

java.nio.file.Files <- new
java.nio.file.Path <- new
java.io.InputStream
java.io.InputStreamReader
java.io.BufferedReader
java.io.OutputStream
java.io.PrintWriter

java.math.BigDecimal <- new

java.util.List
java.util.ArrayList
java.util.Map
java.util.HashMap
java.util.Optional <- new

java.util.stream.Stream <- new
java.util.stream.Collectors <- new
java.util.function.Function <- new
java.util.function.Consumer <- new
java.util.function.Supplier <- new

java.time.LocalDateTime <- new
java.time.ZonedDateTime <- new
java.time.LocalDate <- new

java.net.URI <- new
java.net.http.HttpClient <- new

java.sql.Connection
java.sql.DriverManager

java.awt.Graphics
javax.swing.JFrame

Java 5時代の2005年版はこちら
Javaで最低限おさえておいてほしいクラス・インタフェース35 - きしだのHatena

Swing知らんわーという人は、これを10分くらいでちょろっとやっておくといいと思います。
https://qiita.com/nowokay/items/e0b9c676567134e4a622#swing

out

外したものはこちら。代替APIが出たか、FormatやResultSetとかはフレームワークで対応するよね、とか。

java.io.File
java.io.Reader

java.text.DecimalFormat
java.text.SimpleDateFormat

java.util.Iterator
java.util.Calendar
java.util.Date
java.util.Properties

java.sql.PreparedStatement
java.sql.ResultSet
java.sql.Statement

掛算順序問題を学校という権威を叩くための棍棒として使う人がいる

掛算順序問題のやりとりや反応を見るときに、掛算順序否定派の人に攻撃的だったり侮蔑的な発言が目立つことが気になっていました。
また、借りてきた論拠をそのまま使ってるんではないかと感じることもあります。
これ、学校という権威を叩く棍棒として使ってる人も結構いるんじゃないだろうか。

こういうことを感じたのは、前のブログに「ルールでの順序はどちらでもいい」とわざわざ見出しにしているにも関わらず、ルールを固定しているのがダメだという論調で反論めいたやりとりがあって、「なんだか話が通じてないな」と思ったのがきっかけです。
書いてることを読んでないというのだけじゃなく、書いてないことへの批判のようなものもあったりします。

そして気になったのが「学習指導要領解説には法的拘束力はない」という、あまり意味のないことが異口同音に持ち出されてることです。
文部科学省の通知で「学習指導要領は大綱的な基準であることから,その記述の意味や解釈などの詳細については,文部科学省が作成・公表する学習指導要領解説において説明」という位置づけがされて「学習指導要領解説を活用して、教職員が学習指導要領についての理解を深められるよう周知・徹底を図ること」のように指示されているので、法的拘束力のある学習指導要領を運用するための強い指針であるので、法的拘束力がなくても無視していい文書ではありません。
そもそも、議論においては何が書かれているかが重要で、法的拘束力の有無はあまり関係ないように思います。

これ、だれかが「学習指導要領解説には法的拘束力はない」ということを言いだして、掛算順序を否定するときの材料として普及してそのまま使われてるんじゃないかと思います。

似たようなものに「数学者も言ってる」と数学者や物理学者を持ち出す人を見かけるというのもあります。
けど、数学者だからといって児童教育に詳しいとは限らないので、あまり意味がないように思います。 議論においては、誰が言ったかより何を言ったかのほうが大事なはずというのもあります。

ネットで目立つダメな例を使って全体を批判するというのも大きな傾向に思います。
そして、実際の教育の現場の人が、どのような必要性があってどのような意図で掛算順序を使っているか、どのように運用するべきであるか、現実的な問題として何があるかを説明しても、聞く耳もたないような反応を目にします。

小学二年生という発達段階の児童への教育は、大人への教育と比べると気をつけないといけない点が違うはずです。そこでは現場にいる人の知見は大事だと思いますが、尊重されずに批判を受けていることも見かけます。
数学者を持ち出す人がいると書きましたが、数学者でも児童教育の現場に立ち会った人、現場経験はなくても児童教育の心理学などを勉強した人というのは少ないと思います。

学校という権威を叩ける材料だとして、掛算順序の話に借り物の論拠で参加している人が議論をかきまぜてる面が結構あるんじゃないかというように思います。

目的を規定せずにモデリングを考えても意味がない

オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。
けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。

よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。
例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。
そうすると、まず

void 鳴く() {
  print("コケコッコー");
}

のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。
いや、そもそも、コケコッコーと鳴くようになる前、ヒヨコとしてピヨピヨ鳴いています。ヒヨコからニワトリへの遷移も必要になるのでは?
また、インフルエンザなどの病気にかかればうまく鳴けなくもなりそうですね。

「現実をモデリング」をやろうとすると、どんどんコーナーケースがでてきて、そのすべてのコーナーケースに対応しようとすると、結局は細胞モデルや分子モデルなど、微細要素まで分解してシミュレーションすることになっていきます。

そもそもモデリングというのは抽象化なので、現実のシミュレーションではないですね。
そして抽象化というのは、必要な要素を残して不要な細部を切り捨てる作業です。では何を残して何を切り捨てるかというのは、何に使うかということなしには決めれません。
モデリングでは「何に使うか」が重要です。
何に使うかということなしでは上記のニワトリモデリングのように、いろいろな条件をどんどん再現する必要がでてきます。そして、この作業は結構たのしいので、目的なくどんどんモデルを膨らませていくことになります。
目的が決まっていないモデリングは、モデリングのためのモデリングになってしまいます。

実際には、どのようなシステムで使うかということが、何をモデリングするかよりも大切です。
たとえばデータをメモリだけで扱うのか、ファイルに保存するのか、データベースに保存するか、データベースはMySQLかMongoDBか、そこでモデルの大きな方向性が決まります。

なにを目的にするのかも大切です。販売管理なのかゲームなのか動物百科事典なのか。

販売管理で、肉屋だとニワトリを仕入れてさばいて部位ごとにわけて、一部はミンチにして、という扱いが必要です。システム化のことを考えずにそういった解体可能なニワトリモデルを考えると、骨や肉、羽、そして細胞のモデルまでいきついてしまいますが、ほとんどは販売管理に不要な詳細になります。
現実をモデリングするのであれば、モモやムネの肉オブジェクトは仕入れたニワトリオブジェクトの一部である必要がありますが、実際には仕入れたニワトリと解体されたモモ肉は無関係なオブジェクトで構いません。

そして、このときのモデルを決めるのは、「ニワトリとはどういうものか」ではなく、「ニワトリの肉を売るとはどういうビジネスか」です。ニワトリとモモ肉は無関係でいいと書きましたが、トレーサビリティでモモ肉の生産業者わかるようにするとしても、大事なのはニワトリのモデリングよりも農水省のトレーサビリティ関連文書でしょう。

結局のところ、モデリングするべきは、モノではなくプロセスです。プロセスをモデリングしたあとで、そのプロセスを可能にするデータとしてモノをどうあらわすかというモデルが必要になるわけです。
オブジェクト指向が衰退した流れのひとつに1990年代後半に開発手法から開発プロセスに関心が移ったことを取り上げるのですけど、90年代後半にビジネスプロセス・リエンジニアリング(BPR)という言葉が流行りビジネスプロセスを分析設計することに関心が集まったこともオブジェクト指向の衰退に無関係ではないのかもしれません。

追記 2024/4/14
こういうモデリングはいつからあるんだろうというコメントありますが、オブジェクト指向モデリングの原典とも言える「オブジェクト指向方法論OMT」の最初に自転車の例があります。ただ、これはコンセプトを示すためで、実際の例としてはATMなどもっと実務に即した題材を使っています。意図せず広まってしまった感じ。
ランボーのOMT本はオブジェクトモデル→状態遷移→データフローと章が進んでいるけど、現実的には逆のほうが適切ですね。そこでヤコブソンのOOSEと組み合わさって、ユースケースを起点としたICONIXやRUPにつながっていきました。

AIがコードを書くようになるなら、AIだけに理解できる言語を作ればいい、のかな?

AIがコードを書くようになって、そしてその品質がどんどんあがってきて、人間がコードを書く必要性が薄れてきています。
であれば、プログラミング言語そもそも不要で日本語で命令与えるだけでいいのでは、とか、人間には読み書きできないAI専用言語を作るといいのでは、という話になりそうだけど、やっぱ今のプログラミングは残るんじゃないかな。

(画像は「創るJava」初版の挿絵です。初版のイラストは自分で描いてます)

大森さんと話をする機会があって、そこで話した内容が日経XTECHの記事で少し触れられていました。
生成AIは所詮は人間の亜種、企業のITシステムの置き換えにはならない | 日経クロステック(xTECH)

人の言葉を理解できるようになったのだから、プログラミング言語はもう不要なのではないか。
この考えをある著名なソフトウエアエンジニアに話してみたところ、意外なことに「プログラミング言語はなくならないと思う」という意見が返ってきた

このとき話した内容をもとに、すこしAI時代のプログラミング言語の必要性をまとめてみます。

AIがあるならプログラミング言語は不要?

AIが解釈してくれるのであれば日本語なり英語なりで命令与えればいいだけでは?と思ったりするけど、やはりなんらかの言語は必要だろうと思います。
システムにおいて大事なことは再現性と検証可能性、そして性能だからです。

再現性

システムでは、多数のユーザーに対して同じ動作を何回も提供する必要があります。そうすると、各実に同じ動作を何万回も繰り返せるよう、動作を規定できる必要があります。いまのAIのように、場合により少し動作が違ったり、うまくいかなかったりするというのではダメですね。
そのためには、なんなりか形式的な言語で動作をゆらぎなく記述する必要があります。プログラミング言語はそのための知見がつまって今の形になっているので、活用するほうがいいです。

もちろん、テストを十分に行えば動作保証できるのではという考え方もできますが、そのようなテストを行うのは困難です。まずは記述によって正確性を担保する必要があると思います。

検証可能性

同じ動作を何万回も繰り返せる必要があると書いたのだけど、やっぱり少しずつ条件が変わりますね。こういったブログの投稿を考えても、基本的には同じだけど書かれている内容や文字数、タイミングが違います。 そうすると、なんらか特殊な条件で動作がおかしいということが起きることがあります。
そのとき、どういう条件で動作がおかしいのか、なぜそのような動作になるのか検証できる必要があります。そして、その動作を修正したときに、他に影響がないのかも確認できる必要があります。

「なんかよくわからないけどいろいろ試してプロンプトに『よろしくお願いします』を付けたら治った」ではダメですね。
そうすると、確認できる可読性も必要になります。
いま広く使われている言語は、読み書きしやすいバランスが保たれているので、活用したほうがいいでしょう。

性能

そもそもAIは遅いし電気を食います。電気を食うということはコストがかかるということです。AIを動かすコストはかなり高いです。
サンプルプログラムレベルのTODOアプリを使うために月1000円の課金が必要になっても、だれも使わないですね。 システム構築では、いかにコンピュータを効率よく使ってコストを下げるかということも求められます。

では、AIに直接機械語を出力させればどうなのか、となります。けれども、効率のいい機械語を出力できるようAIを学習させるのは難しく、またそうやって出力した機械語が常に最適であるという保証もできません。
コンピュータには物理制約があり、その制約を回避するためにキャッシュやパイプラインといった複雑な仕組みをもっています。その仕組みをいかして性能を出すには、特性をいかしたコードを生成できる必要があります。AIにそのような特性を教え込ませるよりも、すでに存在するLLVMJVMといった最適化の仕組みを利用するほうが、効率が高く確実です。コードはプログラミング言語で記述して、そういった仕組みに高度な最適化を行ってもらうのが、一番効率がいいと思います。

AI専用のプログラミング言語でいいのでは?

プログラミング言語が必要というのはわかった、しかし人間に読み書きできることをあきらめてAI専用の言語にすれば、もっと高度なプログラミング言語ができるのでは」と思うかもしれません。
けど、それは難しそうだし、必要性もないんじゃないかなと思います。

どうやって作るのか

まず、どうやって作るのかという問題があります。結局のところその言語は人間が作る必要があります。 そうすると、人間には理解できないけどAIに理解できるということを想像しながら言語を作っていく必要があります。
そうやって作った言語が本当にAIに理解可能なのかを検証するために、言語を作って、その言語で書かれたコードを大量に作って、学習させて、理解度を確認する必要があります。
そしてAIに理解できていなさそうとなったとき、AIに本質的に理解できないのか、単に学習の量や質が足りないのかの判断は難しいですね。
そういった試行錯誤を行いながら言語を技術的に作れるか、現実的にそのような困難な作業をするモチベーションがあるかというと疑問があります。

必要なのか

人間じゃなくてAIが作ればいいんでは、となるかもしれませんね。じゃあなんなりかそのような言語が作れるとします。そうなると、そもそも必要かという話をする必要がでますね。

機械専用の言語を作るとしたときに、イメージとしては自然言語の単語で表しているものを記号にするというものがありますね。
たとえば、extendsと書いているところを:で表すような。これはJavaC++などの違いですけど。
けど、AIが扱うと考えたときにそのような記号化のメリットはほとんどありません。文字数は問題にならないからです。
また、いまのAIは自然言語で常識を学びつつプログラミング言語を学ぶという形になっています。自然言語がベースにあるのです。そうすると、AIにとっても記号より単語のほうが理解しやすいということになります。

では機能的なところはどうか、ということになりますね。AIだとより高度な言語機能を扱えるのではないかと。
言語機能といったとき、大事なのは型システムと並列性だと思います。ちょっと記述量が減らせるといったものは、AI専用としては不要です。いい感じに記述が減らせるなら、人間用の言語にも取り込めばいいですね。

まず並列性で、最近はコルーチンなど並列性の機能を取り込んだ言語も増えています。これをAIが扱うならさらに高度な並列機能が可能では、というのを考えたいところですが、並列性の難しさって本質的ではないかというのがあります。また、いまのAIの仕組みはトランスフォーマーからニューラルネットの階層に直列的に情報が流れるので、並列処理が人間に比べて得意になる要素がない気もします。
AIだからといって訓練された人間以上に並列処理の記述が得意になるとは思えないです。

型システムについては、人間よりちょっと複雑な型システムを扱えるかもしれないなという気はします。ただ、型システムを強くすると、広範囲に記述が面倒になりがちというのがあります。AIといえども、そういった面倒な記述は不得意で、不整合がでやすくなる型システムとの戦いが必要になる気がします。

そもそもとして、並列性も型システムも、いまある以上に高度なものが必要なのかという疑問があります。いま広く使われる実用言語で一番高度な型システムとしては、Rustの借用がありますが、ほとんどの人がそれを求めていないですね。求めている人も、コードのすべてでそれが必要とは思っていないはずです。
つまり、いま人間向けとしてある言語はすでに実用システムを書くために必要十分なんではないかということです。 いまプログラミング言語に採用されていない高度な型システムは、仕様記述言語のように用途限定して使うので十分な気がします。用途限定であれば人間にも扱えてるというのもありますね。

ということで、AI専用の言語というのは必要性が薄いなと思うし、そのような薄い必要性のためにコストと労力をかけて言語を作ることもないように思います。

今のプログラミング言語は1000年残る

10年以上前はITの世界はドッグイヤーだと言われて変化が速いと言われていましたが、最近は新しいものがでなくなっています。生成AIが久しぶりに話題になった感じ。
もう新しい言語は10年近く出てないです。また他の技術としてもAWS LambdaやKubernetesも10年近くたってますね。システム開発のためのIT技術の進化は一段落ついたように見えます。
いまあるプログラミング言語はある程度の淘汰や変化はあるとしても、漢字が2000年続いているように、それなりに今の形を保ったまま残っていくように思います。

なぜ掛算順序の話が混乱するのか

掛算順序について学習指導要領解説を見て整理したらいろいろ反論あって、結局のところ問題が三層構造になっていることと、表現という層が認識されていないことで混乱があるように見える。

前回のブログに書いたように「被乗数と乗数の順序が,この場面の表現 において本質的な役割を果たしている」と学習指導要領解説で説明されていて、表現の問題であると整理されています。
掛算の順序と学習指導要領 - きしだのHatena

というの書くと「解説だから・・」みたいな反応がつきますが、文部科学省の通知に「学習指導要領は大綱的な基準であることから,その記述の意味や解釈などの詳細については,文部科学省が作成・公表する学習指導要領解説において説明」とあるので、運用においては最重要な文書だと思います。

まあそれはそれとして、だいたい「交換則があるんだから」とか「ルールは固定されていない」とかが主な反論になっていて、交換則は計算のレイヤー、ルール固定は教育のレイヤーなので、表現として順序が大切かどうかということとはまた別の話になります。

表現の話なので、文化や文書の中で統一したほうが伝わりやすいということで、必要な範囲で統一されていれば、ルール自体はどうなっていてもいいですね。ただ、教えるときにはルールを決めておいたほうがやりやすいので、ルール固定になりやすい。

あと、順序を教えるのは教育の問題ですが、小学二年生の発達段階や理解の構造を考慮せず、できあがった大人と同じ理解力をしてる前提、もしくは理想の理解を前提に話す人も多いようにも思います。

ただ、学習指導要領解説での掛算順序の記述は2017年の改訂で加わったもので、それまでは学習指導要領解説にも掛算の式の表現をどのように教えるか具体的な記述がなく、掛算順序が表現のレイヤーの話であることが明確じゃなかったのだと思います。

表現のレイヤーが認識されていなくて、掛算順序肯定にしろ否定にしろ、教育か計算かどちらかに寄ってしまって、本来議論するべき内容から外れていくんではないかという気がします。