Wing：人工智能時代的云開發(fā)編程語言

只要人工智能（AI）是充當副駕駛而不是自動駕駛的角色，就存在開發(fā)一種促進人類與人工智能之間有效協作語言的空間。這可以通過減少認知負荷并支持快速測試來實現，從而顯著地縮短迭代時間。此外，人工智能簡化了新語言的采用。

那么，在人工智能快速發(fā)展并接管了更多編碼任務的今天，為什么還要投入時間和精力來開發(fā)一種新的編程語言（面向人類的）呢？

我經常會以各種形式遇到以下的問題：

難道人工智能最終不會直接編寫機器碼而使編程語言過時嗎？

一種新的語言能否引入人工智能使用現有語言無法實現的特性或功能？（例如，當人工智能可以為特定的云編寫代碼，然后為另一個云重寫代碼時，為什么要創(chuàng)建一種云可移植語言呢？）

為可能很快就會被人工智能所取代的開發(fā)人員創(chuàng)建工具值得嗎？

首先，我必須承認，我無法預測人工智能的發(fā)展速度。對于人工智能何時或是否會取代人類開發(fā)人員，知名專家持有不同的意見。

然而，即使人工智能最終取代了人類開發(fā)人員，它也未必能直接編寫機器碼。當人工智能可以依賴于成熟的抽象層和編譯器，使其能夠有效地專注于其所服務的業(yè)務的獨特面時，為什么還要選擇通過直接編寫機器碼來為每個應用程序重新發(fā)明輪子呢？通過在現有工作的基礎上再接再厲，專注于更小、更簡單的任務，人工智能可以獲得更快、更高質量的結果。

在討論了更遙遠的未來之后，我現在想在這篇文章的剩余部分重點討論一些更近期的未來。

我相信，考慮到人類的局限性和心理，盡管人工智能發(fā)展迅速，但變化可能是漸進式的，從而導致人類仍處于一個重要的過渡期中。例如，很難想象組織不希望人類對人工智能的輸出負責。人類將非常不愿意讓人工智能以一種人類無法理解、修改和維護的方式工作。

想想看，你會讓 ChatGPT 以你的名義，用你不會說的語言，為你的同行寫一篇專業(yè)文章嗎？你會在無法閱讀的情況下發(fā)表它嗎？可能不會。同樣地，工程經理是否會在明知道某個關鍵任務的應用程序是由人工智能編寫的情況下，還要將其發(fā)布到生產中？如果出了問題，人類很難介入。

此外，雖然人工智能在某種程度上確實是工具之間的均衡器，但它仍然不能完全解決問題。讓我們以上面的云可移植性為例：即使人工智能可以在云之間移植代碼，但我仍然希望能夠讀取和修改它。因此，我必須在人工智能所使用的抽象級別上成為所有這些云的專家。如果一門新的語言允許它在更高的抽象級別上編寫，那么我也能更容易地理解并修改它。

假設人工智能使我們快速生成了大量的代碼，那么瓶頸不可避免地就會轉移到測試和驗證階段。這種情況的發(fā)生不僅是因為人工智能的固有局限性，而且主要是因為我們作為人類自身的不完美。我們無法完美地闡明我們的需求，這就需要體驗最終產品的工作版本，與之互動，并確定它是否滿足我們的需求，或者我們是否忽略了任何的邊緣案例。這個迭代過程會一直持續(xù)，直到我們的創(chuàng)作達到完美狀態(tài)為止。

在測試和驗證消耗了大部分軟件交付時間的情況中，對于使用工具來顯著簡化這一階段來說有足夠的機會。通過減少在開發(fā)環(huán)境中部署和評估應用程序所需的時間，這些工具可以大大提高整體效率。

因此，我相信，在可預見的未來，有一些工具可以讓人類和人工智能更容易地快速編寫出高質量的代碼、并有效地協作更快地測試。這些工具能幫我們提高應用程序的交付質量和速度。

關鍵：減少認知負荷，加速迭代

無論你是人工智能還是人類開發(fā)人員，降低復雜度并加快迭代速度都能更快地開發(fā)出更好的應用程序。

那么，我們可以做些什么來實現這些改進呢？

在更高的抽象級別上工作

利用更高級別的抽象可以為人類和人工智能編碼者提供如下的好處：

通過關注應用程序的業(yè)務邏輯而不是實現細節(jié)，可以減少開發(fā)人員的認知負荷。這使開發(fā)人員能夠專注于更小的問題（例如，指示汽車右轉，而不是教它如何右轉），處理更小級別的堆棧，編寫更少的代碼，并最大限度地減少錯誤的表面積。

可以減少人工智能的認知負荷。

這一概念可能需要進一步澄清。人工智能系統(tǒng)預訓練了所有級別的堆棧知識，因此知道得越少并不是一個顯著的優(yōu)勢，專注于一個較小的問題也不像人類那樣有益，因為只要人工智能知道了如何指示汽車轉彎，那么在教它如何轉彎就不應該遇到問題，而不僅僅是告訴它要轉向。但如上所述，這仍然是有利的，因為它減少了問題面，使人工智能能夠更快、更高質量地生成代碼。然而，允許人工智能編寫更少的代碼并減少其出錯的機會是非常有益的，因為人工智能并非萬無一失。任何目睹過它產生幻覺的接口或生成斷開連接代碼的人都可以證明這一點。此外，人工智能還受到其在失去上下文之前可以生成的代碼量的限制。因此，編寫更少的代碼使人工智能編碼器能夠創(chuàng)建更大、更復雜的應用程序。

可以加快迭代速度，因為它需要編寫更少的代碼，減少了編寫和維護代碼所需的時間。雖然這看起來可能并不直觀，但這對人類和人工智能程序員來說同樣重要，因為人工智能一次生成一個令牌代碼，與人類的編寫方式類似。

可以改善人類和人工智能編碼者之間的協作。以更高抽象級別編寫的更小的代碼庫使人類開發(fā)人員能夠更快、更容易地理解、修改并維護人工智能生成的代碼，從而更快地開發(fā)出更高質量的代碼。

更快的部署和測試

目前，部署和測試云應用程序可能需要幾分鐘。當多迭代周期疊加時，就會有很大的改進潛力。特別是，隨著我們的人工智能朋友幫我們加速了代碼編寫，與代碼編寫相比，在每個迭代周期中測試和驗證所花費的時間比例就變得越來越重要了。

一種普遍的解決方案是在本地運行測試，繞過云部署。然而，這種方法也帶來了自身的挑戰(zhàn)，因為它需要模擬測試組件周圍的云環(huán)境。因此，這些測試的范圍受到了限制，通常需要在云上運行的補充測試來確認實際環(huán)境中的代碼功能。

然而，這并不是旅程的終點。此類解決方案主要用于自動化測試，而開發(fā)人員經常希望在開發(fā)過程中與應用程序進行手動交互，或尋求各種利益相關方（產品、銷售、管理、潛在用戶等）的反饋。在沒有云部署及其相關時間損失的情況下實現這一點仍然是一個挑戰(zhàn)。

因此，我們需要能夠生成既可以在本地運行，也可以在云上運行，并能快速執(zhí)行的測試。此外，我們必須支持云應用程序的快速部署，并為利益相關方的驗證提供方便。

通過實現這一點，我們可以顯著地提高迭代速度，無論代碼是由人工智能、人類還是它們一起協作創(chuàng)建的。

那么，我們如何將這一愿景變?yōu)楝F實呢？

引入 Wing

Wing 是一種用于云開發(fā)的新編程語言，它使人類和 AI 開發(fā)人員都能在更高的抽象級別上編寫云代碼，并且它還附帶了一個本地模擬器，可以讓開發(fā)人員快速地進行測試。

?

量化改進

正如我們將在下面演示的那樣，我們討論的是代碼減少 90%-95%，測試速度提高幾個數量級。

我們來看一下代碼

以下是一個小應用程序的示例，它使用了云函數（AWS Lambda、Azure Function 或 GCP Cloud Function）將文件上傳到 bucket（比如 AWS S3、Azure Blob Storage 或 GCP Bucket）上。

這是 Wing 中的代碼：

?

bring cloud;


let bucket = new cloud.Bucket();
new cloud.Function(inflight () => {
  bucket.put("hello.txt", "world!");


});

?

正如你所看到的那樣，無論是人類還是 AI 編碼者編寫的 Wing 代碼，它們都是在較高的抽象級別上工作的，使 Wing 編譯器能夠處理底層的云機制，如 IAM 策略和網絡（別擔心，它是可定制和可擴展的，能確保你在需要時對其進行控制）。

與人類和 AI 編碼者不同，編譯器是絕對可靠的。此外，它的速度更快，更具確定性，并且不會隨著時間的推移而丟失上下文。因此，我們把更多的責任委托給編譯器，而不是給人類或人工智能，結果也就更好。

編譯器可以為任何云提供商調整應用程序，從而人們只需知道并維護更高級別的、與云無關的代碼即可。生成的編譯構件、Terraform 和 JavaScript 可以使用經過驗證的可靠工具進行部署。

現在，讓我們來看看同樣的代碼在當今領先的云開發(fā)棧之一——Terraform+JavaScript 中的表現。

?

main.tf:


terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}


provider "aws" {
  region = "us-west-2"
}


locals {
  lambda_function_name = "upload_hello_txt_lambda"
}


resource "aws_s3_bucket" "this" {
  bucket = "my-s3-bucket"
  acl    = "private"
}


 data "archive_file" "lambda_zip" {
 type        = "zip"
  source_file = "index.js"
  output_path = "${path.module}/lambda.zip"
}


resource "aws_lambda_function" "this" {
  function_name = local.lambda_function_name
  role          = aws_iam_role.lambda_role.arn
  handler       = "index.handler"
  runtime       = "nodejs14.x"
  filename      = data.archive_file.lambda_zip.output_path
  timeout       = 10


  environment {
    variables = {
      BUCKET_NAME = aws_s3_bucket.this.bucket
    }
  }
}


resource "aws_iam_role" "lambda_role" {
  name = "lambda_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}


resource "aws_iam_role_policy" "lambda_policy" {
  name = "lambda_policy"
  role = aws_iam_role.lambda_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
    {
        Action = [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
        ]


        Effect   = "Allow"
        Resource = "arnlogs*:*"
    },


    {
        Action = [
        "s3:PutObject"
        ]


        Effect   = "Allow"
        Resource = "${aws_s3_bucket.this.arn}/*"
    }
    ]
  })
}


output "bucket_name" {
  value = aws_s3_bucket.this.bucket
}


output "lambda_function_name" {
  value = aws_lambda_function.this.function_name
}


index.js:
const AWS = require('aws-sdk');
const S3 = new AWS.S3();


exports.handler = async (event) => {
  const bucketName = process.env.BUCKET_NAME;
  const key = 'hello.txt';
  const content = 'Hello world!';
  const params = {
    Bucket: bucketName,
    Key: key,
    Body: content,
  };


  try {
    await S3.putObject(params).promise();
    return {
      statusCode: 200,
      body: JSON.stringify('File uploaded successfully.'),
    };


  } catch (error) {
    console.error(error);
    return {
      statusCode: 500,
      body: JSON.stringify('Error uploading the file.'),
    };


  }


};

?

正如你所看到的那樣，Wing 代碼只有 7 行長，而 Terraform 和 JavaScript 的代碼有 122 行，或者說多了 17 倍的代碼。不僅如此，它還深入到了云堆棧的較低層。

你可能想知道是否還有更新的解決方案能將 Wing 的收益比下去，或者是否可以通過庫或語言擴展實現相同的結果。你可以在這里查看 Wing 與其他解決方案的比較，以及為什么它是一種新語言而其他解決方案不是。

用 Wing 進行測試

Wing 開箱即用，配有一個本地模擬器和一個可視化的調試控制臺。

這些工具使開發(fā)人員能夠通過近乎即時的熱重載方式來處理代碼，并可以非常容易地測試云應用程序，而無需模擬周圍的云環(huán)境。

在上面我們那個非常簡單的應用程序示例中，為了運行測試而部署到任何云提供商都需要將近一分鐘的時間，而使用 Wing Simulator 只需要不到一秒鐘的時間，或者說少了兩個數量級。此外，使用 Wing，你可以在不模擬云的情況下編寫測試，并在模擬器和云上運行相同的測試。

你可以在 Wing Playground 上親身體驗。

結? ?論

盡管 Wing 在云開發(fā)方面引入了重大的改進，但我們知道，遷移到一種新語言是一項艱巨的任務，在許多情況下可能難以證明其合理性。

我們竭盡全力通過以下功能來使該語言的采用變得盡可能容易：

很容易學，因為它和其他語言很相似。

能與現有的堆棧和工具（尤其是部署和管理）無縫協作。

成熟的生態(tài)系統(tǒng)——能將任何的 NPM 模塊或 Terraform 資源導入到代碼中。

集成到現有的代碼庫中——能用其他語言編寫運行時代碼，并用 Wing 引用該代碼。

此外，我們相信，在人工智能時代，采用 Winglang 這樣的新語言對人類來說更容易，因為人工智能有助于用不熟悉的語言和框架來編寫代碼，并簡化了現有代碼向新語言的遷移。

隨著我們邁向人工智能在代碼開發(fā)中扮演更重要角色的未來，像 Winglang 這樣語言的創(chuàng)建和采用將確保人類和 AI 開發(fā)人員更好的協作、更快的開發(fā)和更高質量的應用。

想要一窺未來，體驗在 Wing 中編寫代碼并立即進行測試，可以訪問我們的游樂場。

審核編輯：劉清