  |
はてなキーワード:ソフトウェアとは
フリーソフトは頑張って探せばあるかもしれない
俺は金が無いだけでマニアじゃないからほぼそういう使い方してた（ネットサーフィンに動画みて大学のレポート書いてたくらい）から基本問題なかったけど、大学に提出するレポートとかのファイル拡張子設定とかがすごく面倒。
あまりにめんどくさくて家で書いたファイルをUSBメモリに入れて大学のパソコンでマイクロソフトオフィスを開いて（そういえばこのとき初めてワード・エクセル＝マイクロソフトOfficeではなくファイル拡張子はワードと言ってもいろいろあるってことを知ったな）コピーしてた。
今はブラウザ依存のサービスが増えてるし、Googleサービスで大体カバーできるから当時よりは使いやすいだろう、とは思うんだけどならタブレットとかスマホで十分なんだよな。
簡単にまとめれば
「Linuxでもできる」ことは確かにあるんだけど「Linuxだからできる」や「Linuxしかできない」ことってほとんどなくて「Linuxはできない」ことはすごくたくさんあった。
金がなくてOSがない（保証切れ）の古いパソコン使い回していきたいって人らならLinuxは一つの選択肢だろうと思うけど、そうじゃない人に押し付けても嫌がられるだけだよ
（Linux界隈の「軽さこそ至上！」みたいなノリ見る限り、Linuxフリーク気取ってる人らの多くもサブだったりジャンク品のちょっと性能足りてないパソコンに入れてると思う。そしてそういう使い方でLinuxを使うというほど軽くないんだ）
MacとLinuxを両方使っている人として言わせてもらうと、Linuxの方がいいとは限らないけど、Macにする特別な理由がなければLinuxにした方がいいと思います。
そもそもMacは高いですし、パフォーマンスは確実にLinuxの方がいいはずです。
特にセキュリティの観点からも、Linuxの方が優秀な点が多いです。
例えば、Linux自体はカーネルという、OSのうちの一部分に過ぎないため、Linuxで脆弱性が見つかっても、UbuntuやFedoraなどのよりソフトウェアに近い段階(厳密にはLinuxディストリビューション)とはある程度分離された状態なので、よほどの変更がない限りLinuxだけアップデートすることが可能です。
また、Linuxはアップデートというより、新しいバージョンのLinuxカーネルを用意してそちらに切り替える、という構造になっています。
そもそもLinuxは元々、あまり日常用途で使用することはあまりなく、最近になって増えてきたところです。
最近の、特にOSに関わる部分の機能では、どうしても標準では対応できていません。(例えばパスキーなどです)
また、先ほども言及したLinuxディストリビューションは、様々な種類があるため、それらから選ぶのも難しいかもしれません。(実際私も最近までずっと色々なディストリビューションを試して、ようやくFedoraに落ち着いたところです)
日本語IMEだけでも様々な種類がありますし、慣れている人でなければなかなか使いにくい部分もあります。
一応、MacBookでLinuxを動かすという「AsahiLinux」というものがあり、M1/M2には既にある程度対応しているため、もしMacBookでmacOSとLinuxを同時に使う、というのが許容範囲であればそれも良さそうです。
また、Macの固有機能としてはスクリーンタイム(アプリの利用制限や時間での制限、コンテンツの制限などを行える機能)などが存在するので、それを利用する、と言えば納得されると思います。
実際、スクリーンタイムはMacにする特別な理由として十分です。
Linuxの場合どうしても自由度が高過ぎて、様々な方法で同じことをできてしまい、制限が難しいため、スクリーンタイムのような機能は追加しにくいわけです。
ちなみにデスクトップとラップトップの話に関しては、私はまあまあ納得できます。実際デスクトップの方がコスパはいいですし、持ち運びさえしなければデスクトップ一択です。
ただしおそらく持ち運びするでしょうし、コスパをそこまで気にしないならラップトップでもいいかもしれません。
Windowsの話に関しては、Windowsがそもそも最近不具合が多すぎるため、前から一般的に使われているOSの中で安定しているもの、としては現在Macの方が優秀です。
そのため流石にそれには納得できません。
まとめると、Linuxも優秀だがMacにも様々な利点があるため、MacにしたいならMacでいいし、LinuxにしたいならLinuxでいいと思います。
本ドキュメントは、外部の観察者による戦略的視点からの提言案であり、事実認定や人物評価ではなく、「もしこういう前提なら、このような戦略もあり得る」という仮説的な提案です。
2. 大規模言語モデルや生成AI技術は、急速にコモディティ化しつつある。
- 単価の下落
- 競合の増加
-API /SDK /オーケストレーション
などを含めた **ソリューション／プラットフォーム** を提供し得る立場にある。
自前で大規模データセンターを保有・拡張する戦略には、以下のリスクが存在する：
-認定DC は「OpenAI対応インフラ」として市場にアピールできる
3. **DC 側はCAPEX・OPEX・運用リスクを負担**
- OpenAI：
-ライセンス料
- 利用料のレベニューシェア
このモデルは、コンビニエンスストアやクラウド基盤ソフトウェア（例：VMware、ARMライセンスモデル）に類似した **フランチャイズ／プラットフォーム戦略** に近い。
など「差別化要因」に集中投下できる。
を分散できる。
- 未到来のブレイクスルーを前提にした大規模CAPEX は、
-価格低下
2. **既存技術＋既存インフラをフル活用することで「時間を買う」**
-既存DC を活用することで、市場展開までのリードタイムを最短化できる。
を作れる。
3. **「今ある技術でどこまで世界を押さえられるか」を優先的に考える**
-未来の理想状態より、現在の配備速度・採用件数・開発者エコシステムの拡大をKPI に置く。
1. **ビジョンと所有欲の分離**
-インフラ所有
-資産規模
を混同しない。
- 自社が全てを所有するモデルではなく、
-世界中のプレイヤーに役割を与えるプラットフォーム構造の方が実現しやすい。
- 「OpenAI と組む方が得だ」と明確に感じる収益構造・責任分担を設計する。
- 握るべきは、
-安全性と信頼
-ブランドと標準
- 手放してよい（外部に任せる）ものは、
-建物
-ラック
- 電力インフラ
- 日々の運用
-CAPEX 回収の難しさ
を考えると、必ずしも最適とは限らない。
- OpenAI が「AIプラットフォーム」「AIフランチャイズの本部」として振る舞い、
-スピード
-支配力
のすべてにおいて合理性が高い。
-戦略構造と資本効率、時間軸の観点からの一つの選択肢として提示するものである。
以上。
英語での「piggyback」の意味について詳しく説明します。
「piggyback」は、元々はおんぶや背負うという意味で使われる言葉です。具体的には、何か（または誰か）を他の人の背中に乗せて運ぶ、または背中に乗ってもらう行為を指します。子どもが大人の背中に乗る時などに使われる表現です。
• 例文:
• “The childwas givinghis father a piggyback ride.”（子供は父親におんぶしてもらっていた。）
「piggyback」は、物理的な「おんぶ」や「背負う」の意味だけでなく、比喩的に使われることも多いです。以下のような意味で使われます。
何かを他のものに「乗せて」進行させる、もしくは他のものに依存して動かすという意味で使われます。この意味では、物理的な「乗る」という感覚が比喩的に使われています。
• 例文:
• “The newsoftware runson a piggyback system ofthe existing platform.”（新しいソフトウェアは、既存のプラットフォームを基盤にして動作する。）
• “The small companyis piggybackingon the success of the larger corporation.”（その小さな会社は、大企業の成功を利用している。）
2.2. 一緒に運ぶ/追加する
何かを主となるものに「追加して」進める、あるいは別のプロジェクトやタスクに「加える」という意味で使われることもあります。
• 例文:
• “Wewill piggyback a marketing campaignon our product launch.”（製品発売に合わせて、マーケティングキャンペーンを一緒に行う予定です。）
2.3.一時的な付加
何かが既存のシステムや方法に追加的に加えられるという意味でも使われます。特に、主となるものに追加的に乗せて使う場合に使われます。
• 例文:
• “The new featureis piggybackingon the oldversion of the app.”（新機能はアプリの古いバージョンに追加されている。）
3. 他の使い方
• Piggyback ride:おんぶや背中に乗ることを指しますが、特に遊び心のある、軽い意味で使われます。
• Piggybackjump:競技やトレーニングにおいて、他の選手の背中に乗ってジャンプする動作を指すこともあります。
まとめ
「piggyback」は、もともとおんぶや背負うという意味から派生し、比喩的には「何かを他のものに乗せて運ぶ」「依存している」「追加する」といった意味でも使われます。特にビジネスやテクノロジーの分野では、既存のシステムや成功に依存して新しいプロジェクトやアイディアを進めるという意味で広く使われています。
電話屋さんで培ってきた技術はインターネットの発展でTCP/IPに乗っ取られてEnd-EndのOSが頑張るから電話屋の出番は出てこない
そんでWiFiとか光ファイバとかのL2以下の仕事しかなくなったんだけど今となっては完全に飽和してやることなし
頑張ってIOWNとか言ってるけど中身は光回路のプロセッサーで通信速度じゃ無くて電気代が安くなるだけ
L3より上のユーザー体感できる部分は何も変化が無いのでいくらIOWNとか言っても顧客体験は何も変わらない
当時からソフトウェアが主流になることは分かってて優秀なソフトウェア技術者をいっぱい雇ったり育てたりしたけど
いわゆるGAFAだとかにガンガン引き抜かれて「NTT大学」とか揶揄される始末
まぁNTTの研究所がソフトウェアをリリースするのは法律的にも文化的にも大きな壁があるので事実上無理で
子会社に論文を渡して開発してもらう、みたいなことをいまだにやってるんだけど全然時流に合ってない
良い例がTsuzumiとかいう劣化チャッピーで、意気揚々とTsuzumi2を発表したのに前日にgpt-ossが発表されてたので誰にも見向きされてない
そりゃわざわざ金出して性能低いもの使う奴おらんわな
継続的なインテグレーションと顧客体験との統合が今時のソフトウェアでは当たり前に必要なのに
研究→開発→テスト→販売 みたいなモデルで会社構造を組んでしまってるからソフトウェア開発に1mmも合って無いし
GAFAに行けない無能が「精度で勝った！」とか部屋の隅っこで騒いでるだけ
補聴器もずっと出す出すと言ってたのにAirPodsが補聴器機能を先に搭載してしまって今頃になって「オープンイヤー」とか言って発表してる
残念ながらこんな市場は中華製品に蹂躙されるのが目に見えてるので第二のバルミューダになる未来しか見えない
苦し紛れにパーソナライズドサウンドゾーンとか言って音の打ち消し距離だとかを突き詰めてる一方で
AirPodsはノイズキャンセリングしながら同時通訳まで搭載していますよ？勝てるんですか？コレ
時価総額だけやたら高いけどトヨタみたいにGRGTとかのぶっ飛んでる車を出したり自動車の最先端を走ってる企業とは全然レベルが違うんよ
人口が増えないのに成長できるの？今期、ソフトウェア投資マイナスだった。AIやロボットを活用するはずなのに投資されていない。マイナス。やばくね？？みんなで落ちるの？
最初は気づかなかった。シミといっても左下と右上の隅なので、下に配置したDockやメニューバーと重なって実用上は問題無い。
ブラウザを全画面表示にして気づいた。あれっ、この黒いグラデーション動かないぞ。position: fixed; なのかな？
全画面表示を解除してもシミは残ったままだった。よく見ると、そのシミは立体的で見る角度で違ってくる。これがソフトウェア的なものであるはずが無い。
故障としては買い替えるほどでは無い。今は作業用にしか使っていないので、実用上は問題無い。
ただ、完全性、integrityというのかな？が失われたのが悲しい。
例えるなら、新車に擦り傷をつけてしまった時の悲しさというか。
2019年に買った27インチ・HDR対応・4K。当時でもけっこう安くなっていたと思う。今同じようなのを買おうとすると3〜5万円くらい。
買い直せばシミは無くなるけど、今は家を買うためにお金が必要なので、余計な出費は抑えない。
実用上は困らないのだけど、シミを見ると悲しくなるのはなぜだろう。
お祭りの一形態であるネット炎上で暖をとろうとしていたら、迅速な消火活動でボヤに終わってしまい残念です。
消化不良なのでソフトウェア開発の文脈で本件を整理しておきたいと思います。
なぜ「チンパンジーを従業員」とする例え話は炎上し、何がダメだったのでしょうか。
それは、何故マンホールが部署に配属されなかったか、という問題に帰結します。
労務管理ソフトを手がけるIT企業「SmartHR」（東京都港区）が、「チンパンジーが配属されてきたら、あなたはどうマネジメントする？」という記事をQiitaのアドベントカレンダーに投稿した。
記事の内容は、"マネジメント職の職責は、事前に与えられ決められた作業を行うことではなく、臨機応変にチームを守ることだ"という趣旨のものだった。
従業員をチンパンジーに例えるように読めてしまう為、不適切では？という文脈で軽く炎上、記事は削除され現在は謝罪文が掲載されている。
理不尽なマネジメントを強いられるマネージャーという文脈において、最も想定しやすいのが新しい社員の配属だから、「XXXが配属されてきたら、あなたはどうマネジメントする？」という記事になったと想定できます。
さて、この一文だけでほぼ説明は終わってしまうのですが、この例え話はXXXを何に置き換えても、結局のところ新しく配属された社員を理不尽に感じる、としか読み取ることが出来ません。
これは、どのように予防線を張ろうとも、どのような説明をしようとも、「社員に問題があったときに、あなたはどうするのか？」という問いとして読むしかありません。
そこで、問題の社員を表現するXXXに、チンパンジーを置けば、炎上するに決まっています。
なぜか。非常に品の無い界隈の話で恐縮ですが、人間をチンパンジーに例える文化圏が日本にはまだ残っています。
もしかすると非常に上品な方たちのみで形成されている共同体では非常識なのかもしれませんが、残念ながら人を罵倒するときにチンパンと呼んだり豚とあてこする文化圏は間違いなく存在するのです。
百歩譲って、問題の社員を無機物で表現するのであれば、まだ許されていた可能性が高いでしょう。
この場合、まったく意味が分からない行為を上司に押し付けられた、としか解することができないからです。
マンホールを転がして席に立てかけたところ机ごとMacbook Proをぺしゃんこにした。同僚が躓いて怪我をした。意味が分からな過ぎて怯えて社員が辞めた。
これすら、本来は社名の入った記事として出すにはリスクが高いはずです。なぜならば「社員に問題があったときに、あなたはどうするのか？」という問いの本質は変わらないからです。
問題のある社員を表現するときには、非常に気を使って書く必要があります。
ソフトウェア開発の話題で非常に有名な表現にブリリアントジャーク(Brilliant Jerk)があります。
HighAttitude, High Performance — TheRockStar
HigherAttitude,Low Performance -The Team Player
ココで着目して欲しいのは、能力のある嫌な奴(The Brilliant Jerk)ではありません。
非常に協調性が高く、低い生産性の人物をThe Team Playerと表現していることです。
成果主義であれば、Low Performanceであればいずれ職場からいなくなるのが自然です。
しかし、高い協調性（非常に良い態度）があるなら、それはチームプレイヤーとして欠かせないのかもしれないよ？という予防線の張り方をしているわけです。
その上で、真っ向から、態度が悪い嫌な奴はチームに入れると全体の生産性が落ちる、という筋の話をしているわけです。
そして、職場からThe Brilliant Jerkを排除せよという書き方にもなっていません。
もうそういうヤツに居場所はない、リーダーなら協調性がありコミュニケーションがとれるべきであるという、「リーダーかくあるべし」論に着地している所が優れているのです。
つまり、「XXXが配属されてきたら、あなたはどうマネジメントする？」というタイトルの記事を書くべきではありませんでした。
「XXXな状況になったときに、マネージャーはどうあるべきか？」というタイトルの記事を書くべきでした。
微に入り細を穿つ描写で、チンパンジーが職場で暴れてチームを壊す筆致を見せる必要は全くありませんでした。
どう贔屓目に見ても、それはチームを壊す厄介者が配属された時に、如何にして（合法的に）チームを守るのか、という寓話としてしか読み取れません。
「あーあ、あんな奴がいるから、会議室を潰して追い出し部屋を作らなきゃならない俺は大変だなあ」みたいなことを令和に書いて許容されると思う方がどうかしています。
人物ではなく現象ですと注記して許されると思うのは、どう見ても未成年を描いておきながら登場人物は全員成人ですというのと同じです。
私個人としては、表現の自由の最前線で戦う方達を畏敬の念でもって(経済的に)支えることしかできないわけですが、労務管理ソフトを手がけるIT企業がそんな気概を持つ必要性は全くないと思慮する次第です。
（たぶんだけど、ボリュームが多いので全部読まずに雰囲気で説明されてそのまんま出したんじゃないかなーと言う気はします。法務とか広報は通ってないんじゃないかな）
社長から急に巨大なクリスマスツリーを飾れと言われて困る、くらいの現象にして「令和にもなってクリスマスのような宗教的な話題を載せるのは大丈夫なの？」とか言われるくらいが良かったんじゃないのかな、と言う気がします。
ソフトウェア開発に携わる人たちには、驚き最小の原則(Rule of least surprise)を忘れて欲しくないと常々思っています。
私は趣味の悪い野次馬根性のネットウォッチャーです、これから炎上させにくい記事の話をしますと冒頭に書いてあるのはそのためです。
直観的に、ああこれはチンパン従業員をマネジメントする話をこれからするんだろうな、と思われた時点で負けなわけです。
そして、労務管理を行う会社が、問題のある社員をマネジメントするのは大変だよねと読みとれるような寓話を書いてはならないわけです。
何をどう誤読しようとも、社長に無茶振りされて中庭に巨大なクリスマスツリーを電飾するか消すかで翻弄される中間管理職を書くべきだったわけです。
良く読めばわかるように書いてあるというのは、誤読して欲しい時にだけ使うのです。
それにしても、割と今回は穏当な指摘が多かったと思います。
これ、外資の日本支社だったら、同僚から速攻で訴えられて普通に負けると思います（偏見）。
しかし、縁故採用に見える話を社名載せて出して大丈夫なの？とか、不透明な資金調達してますが凄腕の社長ですみたいな表現どうなの？とか、もっとこう火種があったと思うんだよなあ。
もっと面白い炎上をたくさん見たいので、こういう直球のノープラン炎上で企業名のある記事が減ってしまいかねないのは避けていただきたく。
もっとさあ、ローパフォーマーを特定して左遷してチームの生産性を改善した話とか書いて大炎上してくださいよ。
いちおう、本番環境でやらかしちゃった人アドベントカレンダーにしれっと書いて大炎上ルートは残されているので、そっちでなんとかならんか？
これさ
愚かな人間の都合など完全無視、LLMのための高効率プログラミング言語「Sui」（粋）
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
別にいいんだけど、どうにもブクマカ含めて、しっくり来る批判できてないんだよな
それが気になってしょうがない
俺ごときが言ってもアレだから、Gemini3.0先生に頼んだよ（一時チャット、Pro 3.0思考モード）
ユーザーが提供した情報と、一般的なLLMの技術特性に基づき、プログラミング言語「Sui」についての冷静かつ客観的な評価をまとめます。
感想:一言で言えば、**「思想実験としては極めて面白いが、実用性とLLMの学習原理を無視した『早すぎた最適化』」**です。
作者の「人間ではなくLLMを主客にする」という視点の転換は、アーティスト的・哲学的な問題提起としては鋭いですが、現在のLLM（Transformerアーキテクチャ）の動作原理を工学的に捉えると、メリットよりもデメリットが上回る可能性が高いです。
メリット:
・トークン効率の改善:Python等と比較して記述が圧倒的に短くなるため、出力速度の向上と課金コストの削減（トークン節約）は確実に達成できます。
・構文エラーの激減: 括弧やインデントの複雑なルールを排除しているため、「閉じ忘れ」などの単純なSyntaxErrorは減るでしょう。
・コンテキストウィンドウの節約: 長いプログラムでもコンテキスト（メモリ）を圧迫しにくくなります。
・学習データとの不一致: LLMは「大量の人間用コード（Pythonなど）」を学習して賢くなっています。未知の言語「Sui」を書かせるには、Few-shot（プロンプトでの例示）に頼るしかありませんが、これではLLM本来の推論能力やコーディング能力（事前学習の重み）を活かせません。
・ブラックボックス化: 生成されたコードがバグっていた場合、人間が読んで直すことが不可能です。「LLMに直させる」にしても、LLM自身がSuiのロジックを深く理解していないため、無限ループ（幻覚の連鎖）に陥るリスクが高いです。
・CoT（Chain of Thought）の阻害:最近の研究では、LLMは「冗長な思考過程」を出力することで論理的整合性を保つことがわかっています。極限まで圧縮された記号列は、LLMの「考える余地」を奪い、論理破綻を招く可能性があります。
正しいと思う所（Agree）
理由:人間にとっての「読みやすさ（可読性）」は、機械にとって単なるトークンの無駄遣いです。if x>10: よりも ? x10 の方が情報密度が高いのは事実です。
理由: TransformerのAttentionメカニズムにとって、遠く離れた ( と ) の対応関係を維持するのは計算コストが高く、ミスの原因になりやすいです。ネストを排除する方向性は機械的処理として正しいです。
正しくないと思う所（Disagree）
・「可読性を排除しても良い」:
理由:ソフトウェア開発においてコーディングは「書く」時間より「読む・直す」時間の方が長いです。AI生成コードであっても、最終責任は人間が負う現状では、人間が検証不可能なコードは「危険なバイナリ」と同義であり、プロダクトには採用できません。
理由: 前述の通り、現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。Suiは「計算機にとっては最適」ですが、「現在のLLMにとっては異言語」です。
パース（解析）は容易になりますが、LLMは「前の行の文脈」を読んで次の行を出力するため、行を独立させすぎると文脈の連続性が失われ、複雑なアルゴリズムの構成力が落ちる可能性があります。
LLMが最も苦手とする「深いネスト構造の維持」を回避する策として有効です。アセンブリ言語に近いフラットな構造は生成難易度を下げます。
これが最大の問題点です。LLMは変数名（user_id, total_price など）に含まれる「意味」を使って推論を行っています（Semantic Grounding）。すべてを記号化すると、LLMは変数の役割を見失い、論理的なバグを埋め込みやすくなります。
トークン効率は最強ですが、1文字の違いで意味が激変するため、LLMの確率的な「ゆらぎ」による1文字ミスが致命的なバグになります。冗長さはエラー訂正の役割も果たしています。
goto 文の多用はスパゲッティコードを生みます。LLMにとっても、構造化プログラミング（if/forブロック）の方が、「ここからここまでがループ」というチャンク（塊）として認識しやすいため、一概にジャンプ命令が良いとは言えません。
＞現在のLLMは「人間語の確率分布」を学習したモデルです。「LLMにとって自然な言語」とは、実は「人間にとって自然な言語（英語やPython）」そのものです。
ここ！マジで覚えてね
LLMはこれまでの機械よりも人間に近いと思ってほしい、人が苦手なことはAIも苦手
機械は論理的でロジックに強くて〜っていうのはAIには通用しない
ついでに、「LLM用プログラミング言語」の潮流について
「LLMのための言語」という文脈は、大きく2つのトレンドに分かれます。Suiは後者に属しますが、主流は前者です。
・DSPy, Guidance,Microsoft Guidance:
・プロンプトエンジニアリングを構造化し、LLMの出力を型（JSONなど）に強制したり、思考プロセスを制御するためのフレームワーク。
・SGLang:
・これらは「人間がLLMを操るための言語」であり、実用化が進んでいます。
・Gorilla LLMなどの試み:API呼び出しに特化したファインチューニングなどがありますが、独自の「新言語」を作らせるよりも、既存のPython やJSON を正しく出力させる方向（Constrained Decoding）が業界の標準解です。
・擬似コード:論文レベルでは、Pythonの代わりに中間的な擬似コードを出力させ、それをコンパイラで処理する手法も研究されていますが、Suiほど極端な記号化は稀です。
後者については
現状の最適解:現在のLLMを使う限り、「LLM用言語」の最適解はPython です。なぜなら、世界中のGitHubのコードを学習しており、LLMが「最も流暢に話せる言葉」だからです。無理にSuiを話させるのは、日本人にエスペラント語で詩を書かせるようなもので、パフォーマンスは落ちます。
総評: Suiは、「既存のLLM（GPT-4など）に書かせる言語」としては失敗する可能性が高いですが、「未来のAIネイティブなコード生成のあり方」を示唆するアート作品としては高く評価できます。作者の「愚かな人間に合わせるな」というパンクな精神は、エンジニアリングの枠を超えた鋭い批評性を持っています。
お前らは安易にオレオレ言語作るんじゃないぞ、作るにしてもAIに聞きなよ？
聞く時は忖度させるんじゃないぞ？
この作者もAIに乗せられたのかもしれんし
＿＿＿＿＿＿
プロンプト
以下が「LLM用プログラミング言語」としてメリットがありそうか、感想を教えて下さい。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2069573.html
https://github.com/TakatoHonda/sui-lang
・思想的に正しいと思う所、正しくないと思う所を理由込みでまとめてください
・最近のLLM用プログラミング言語についてもまとめてください
・そもそもLLM用プログラミング言語という目標自体の評価をしてください
（省略）
