EYG: 人間向けプログラミング言語

人間向けプログラミング言語。 Eat Your Greens（EYG）は、静的型付けの関数型プログラミング言語です。 これは、ある種の「より良い」プログラミング言語です。この記事では、私が「より良い」と考えるものと、そのために言語に追加または削除する必要がある機能について説明します。 エンドユーザープログラミングの失望 私は、新しい仕事のためにスウェーデンへ行くビザを待つ10週間の間に言語の構築を始めました。EYGは、技術に詳しいがプロフェッショナルではない開発者の間で繰り返し見られるパターンに気づいた後に特に構築しました。そのパターンは、以下のようなサイクルでした。 技術に詳しい人が、自動化できるはずだと感じる問題を見つけます。彼らはノーコードまたはローコードツールを選択し、それを機能させます。しかし、ツールの複雑性の増大への対応がうまくいかず、すぐにフラストレーションを感じます。 この時点で2つの選択肢があります。 開発者に助けを求める。開発者はすぐに、それは「本物の」言語で書き直す必要があると言って、最初の解決策を却下します。 元の作成者は自分で「本物の」プログラミング言語を学び始め、その間に進歩は遅くなります。 これらのツールと問題は、エンドユーザープログラミングという広範なカテゴリに分類されます。一部の人々は、非専門家が職場で有用な貢献をすることを表すため、市民開発者という言葉を好みます。 大量消費を目的としないソフトウェアを説明する私の好きな方法は、自家製です。 基本的に、問題を解決するためのソフトウェア作成は、それをフルタイムのアイデンティティとして開発者にならない人々にも利用可能であるべきです。 人間対開発者 このセクションは、この記事のタイトルのほぼすべてでした。 フルタイムの開発者は、他の人よりも変化し続ける技術についていくのに多くの時間を費やすことがあります。もしあなたの仕事の10％しかソフトウェアを書くことでないなら、ソフトウェアの書き方について読むことは起こりません。 機械への共感は開発者にしか存在しません。彼らは、整数オーバーフローがなぜ起こる必要があるのかを喜んで説明します。 整数オーバーフローに対する平均的な人間の反応は、「なんだ、数字はそんな風に動かないだろ」です。 私たちはBigIntを持っており、99％の時間は「なんだ」という反応が正しいのです。 平均して、開発者はより大きな問題に取り組んでいます。 これは理にかなっています。一部の開発者は数百人もの他の人と協力してソフトウェアプロジェクトに取り組んでいますが、エンドユーザーソフトウェアは人間のフルタイムの注意よりも少ないです。 これは、開発者ツールがより小さな問題を十分にカバーしていないことを意味します。 私の仮説 開発者は、2つの広範なカテゴリの作業を扱います。 if、loop、varなどの言語構造を使用して、解決している問題のロジックを記述すること。 $PATH、/var/tmp、AWSなどの構造を使用して、それらの問題をコンピューターで実行すること。 最初の作業は問題なくできるが、2番目のカテゴリを習得する時間がない人間はたくさんいます。 私はこれらの人間を「メーカー」と呼びます。 したがって、プログラミングを容易にしようとするエンドユーザープログラミングツール（例えば、ビジュアル言語を作成するなど）は、間違った問題を解決しています。 Excelは、エンドユーザープログラミングの会話で常に称賛されています。 「実際、それは最も人気のあるプログラミング言語だよ、知らなかったの？」 Excelマクロはテキストベースのプログラミングのままですが、マクロのデプロイと実行に関するすべての問題を排除します。 Excelはカテゴリ2を完全に解決します。 EYGは、カテゴリ2の問題（プラットフォームやランタイムによって自動的に処理されるか、実行される）を排除し、メーカーが問題の記述に集中できるように存在します。 それは、ソフトウェアスペクトルの自家製エンドに焦点を当てています。 EYGは以下のような場合に適しています。 グルーの問題：「このスプレッドシートをこのDiscordボットと連携させたい。」 パーソナルダッシュボード：「ソーラーパネルの出力をカレンダーと一つの場所に、古いiPadで見たい。」 自動化：「ドアベルが鳴り、私がZoom会議中にいたら、デスクランプを点滅させる。」 Gleamからのさらなる証拠 スウェーデン滞在中、私は自動化エンジニアと協力しました。 彼らは技術的にリテラシーの高い人々ですが、ソフトウェアについて考えるのと同じくらい、電気、機械、安全の問題について考えていました。 これが彼らが働くソフトウェア環境です。 明らかに彼らは本物のプログラマーです。 しかし、私は彼らの何人かが、ウェブサイトのような他のドメインでソフトウェアを構築しようとする際に、上記と同じサイクルを経験するのを見ました。 これはGleamとどう関係があるのか？ さて、私は彼らの何人かにGleamツアーを試してもらうことに成功しました。 静的型付けの関数型言語は彼らにとって新しいパラダイムでしたが、これらのエンジニアはGleamを学ぶのに全く問題がありませんでした。 実際、彼らのほとんどはツアーを終え、「次はどうすればいい？」と尋ねました。 彼らは言語の構造に満足していましたが、どこに適用し、どのようにデプロイすればよいかわかりませんでした。 Gleamは素晴らしい言語であり、ドメイン問題（カテゴリ1）への解決策を非常にうまく表現できます。 しかし、リリースとデプロイにはまだ苦痛があります。 それは明らかに、カテゴリ2の問題を円滑にするという点でExcelの利便性レベルにはありません。 なぜGleamで作業しないのか しばらくの間、私の言語はGleamに戻ることを期待した実験でした。 しかし、優先順位の違いにより、いくつか修復不可能な違いがあります。 Gleamは名目型付けであり、EYGは構造型付けです。 名目型付けは、プロフェッショナルがドメインを厳密に記述するための最良の方法です。 構造型付けは、ユーザーが事前に型について考える必要なしに、コンピューターがユーザーを助けるための最良の方法です。 Gleamはアプリケーションを構築する開発者のためのものです。 EYGは機能を作成するメーカーのためのものです。 EYGの機能 EYGは、サポートしたいメーカーにとってうまく機能するために多くの選択をしています。 以下は、他の言語との主な違いです。 健全な型推論 現時点では、型は誰にとっても良い選択だと思います。 トレンドはJavaScriptからTypeScript（そしてGleamへ）です。 EYGでは、ユーザーが事前に型を定義することを決して強制せず、実行もオプションである型システムを選択しました。 それは、型システムをプロセスにおける儀式よりも、クラス最高のヘルパーにすることに焦点を当てています。 ハッシュ化された依存関係 自動化エンジニアにGleamを試してもらうように説得した後、最も問題を引き起こしたのは、更新時の依存関係地獄を理解することでした。 Gleamはまだ1.0未満だったので、現在よりも頻繁に発生しました。 EYGは、モジュールの内容のハッシュによって識別されるインラインで依存関係を定義することで、依存関係の問題を回避します。 効果型付け 型システムに副作用をキャプチャすることで、ランタイムがメーカーにより多くのヘルプを提供できるようになります。 ウェブページ用のスクリプトを書いている場合、ファイルシステムを呼び出す依存関係は、ヘルプフルな型エラーとして表示されます。 私はさらに進める計画があります。例えば、ラムダ関数がキーバリューストアの効果を使用する場合にのみ、プラットフォームがキーバリューストアをプロビジョニングできる可能性があります。 「より良い」の他の測定基準 私の「より良い」の測定基準は、言語がメーカーに信頼性が高く共有可能なプログラムを構築することをどの程度可能にするかです。 これは、設定、スクリプト、自動化、ウィジェットなどに及びます。 これが私の「より良い」の測定基準であり、もちろん他のものもあります。 もしあなたが大規模チームが新しいブラウザを構築するための最良の言語を探しているなら、Rustをお勧めします。 私はEYGを、ある種の「より良い」のための、より良い言語とツールの構築における実験として構築しています。 すべての進捗は、私の不規則なニュースレターで報告されます。