Wing:人工智能时代的云开发编程语言

编程语言及工具

99人已加入

描述

只要人工智能(AI)是充当副驾驶而不是自动驾驶的角色,就存在开发一种促进人类与人工智能之间有效协作语言的空间。这可以通过减少认知负荷并支持快速测试来实现,从而显著地缩短迭代时间。此外,人工智能简化了新语言的采用。

那么,在人工智能快速发展并接管了更多编码任务的今天,为什么还要投入时间和精力来开发一种新的编程语言(面向人类的)呢?

我经常会以各种形式遇到以下的问题:

难道人工智能最终不会直接编写机器码而使编程语言过时吗?

一种新的语言能否引入人工智能使用现有语言无法实现的特性或功能?(例如,当人工智能可以为特定的云编写代码,然后为另一个云重写代码时,为什么要创建一种云可移植语言呢?)

为可能很快就会被人工智能所取代的开发人员创建工具值得吗?

首先,我必须承认,我无法预测人工智能的发展速度。对于人工智能何时或是否会取代人类开发人员,知名专家持有不同的意见。

然而,即使人工智能最终取代了人类开发人员,它也未必能直接编写机器码。当人工智能可以依赖于成熟的抽象层和编译器,使其能够有效地专注于其所服务的业务的独特面时,为什么还要选择通过直接编写机器码来为每个应用程序重新发明轮子呢?通过在现有工作的基础上再接再厉,专注于更小、更简单的任务,人工智能可以获得更快、更高质量的结果。

在讨论了更遥远的未来之后,我现在想在这篇文章的剩余部分重点讨论一些更近期的未来。

我相信,考虑到人类的局限性和心理,尽管人工智能发展迅速,但变化可能是渐进式的,从而导致人类仍处于一个重要的过渡期中。例如,很难想象组织不希望人类对人工智能的输出负责。人类将非常不愿意让人工智能以一种人类无法理解、修改和维护的方式工作。

想想看,你会让 ChatGPT 以你的名义,用你不会说的语言,为你的同行写一篇专业文章吗?你会在无法阅读的情况下发表它吗?可能不会。同样地,工程经理是否会在明知道某个关键任务的应用程序是由人工智能编写的情况下,还要将其发布到生产中?如果出了问题,人类很难介入。

此外,虽然人工智能在某种程度上确实是工具之间的均衡器,但它仍然不能完全解决问题。让我们以上面的云可移植性为例:即使人工智能可以在云之间移植代码,但我仍然希望能够读取和修改它。因此,我必须在人工智能所使用的抽象级别上成为所有这些云的专家。如果一门新的语言允许它在更高的抽象级别上编写,那么我也能更容易地理解并修改它。

假设人工智能使我们快速生成了大量的代码,那么瓶颈不可避免地就会转移到测试和验证阶段。这种情况的发生不仅是因为人工智能的固有局限性,而且主要是因为我们作为人类自身的不完美。我们无法完美地阐明我们的需求,这就需要体验最终产品的工作版本,与之互动,并确定它是否满足我们的需求,或者我们是否忽略了任何的边缘案例。这个迭代过程会一直持续,直到我们的创作达到完美状态为止。

在测试和验证消耗了大部分软件交付时间的情况中,对于使用工具来显著简化这一阶段来说有足够的机会。通过减少在开发环境中部署和评估应用程序所需的时间,这些工具可以大大提高整体效率。

因此,我相信,在可预见的未来,有一些工具可以让人类和人工智能更容易地快速编写出高质量的代码、并有效地协作更快地测试。这些工具能帮我们提高应用程序的交付质量和速度。

关键:减少认知负荷,加速迭代

无论你是人工智能还是人类开发人员,降低复杂度并加快迭代速度都能更快地开发出更好的应用程序。

那么,我们可以做些什么来实现这些改进呢?

在更高的抽象级别上工作

利用更高级别的抽象可以为人类和人工智能编码者提供如下的好处:

通过关注应用程序的业务逻辑而不是实现细节,可以减少开发人员的认知负荷。这使开发人员能够专注于更小的问题(例如,指示汽车右转,而不是教它如何右转),处理更小级别的堆栈,编写更少的代码,并最大限度地减少错误的表面积。

可以减少人工智能的认知负荷

这一概念可能需要进一步澄清。人工智能系统预训练了所有级别的堆栈知识,因此知道得越少并不是一个显著的优势,专注于一个较小的问题也不像人类那样有益,因为只要人工智能知道了如何指示汽车转弯,那么在教它如何转弯就不应该遇到问题,而不仅仅是告诉它要转向。但如上所述,这仍然是有利的,因为它减少了问题面,使人工智能能够更快、更高质量地生成代码。然而,允许人工智能编写更少的代码并减少其出错的机会是非常有益的,因为人工智能并非万无一失。任何目睹过它产生幻觉的接口或生成断开连接代码的人都可以证明这一点。此外,人工智能还受到其在失去上下文之前可以生成的代码量的限制。因此,编写更少的代码使人工智能编码器能够创建更大、更复杂的应用程序。

可以加快迭代速度,因为它需要编写更少的代码,减少了编写和维护代码所需的时间。虽然这看起来可能并不直观,但这对人类和人工智能程序员来说同样重要,因为人工智能一次生成一个令牌代码,与人类的编写方式类似。

可以改善人类和人工智能编码者之间的协作。以更高抽象级别编写的更小的代码库使人类开发人员能够更快、更容易地理解、修改并维护人工智能生成的代码,从而更快地开发出更高质量的代码。

更快的部署和测试

目前,部署和测试云应用程序可能需要几分钟。当多迭代周期叠加时,就会有很大的改进潜力。特别是,随着我们的人工智能朋友帮我们加速了代码编写,与代码编写相比,在每个迭代周期中测试和验证所花费的时间比例就变得越来越重要了。

一种普遍的解决方案是在本地运行测试,绕过云部署。然而,这种方法也带来了自身的挑战,因为它需要模拟测试组件周围的云环境。因此,这些测试的范围受到了限制,通常需要在云上运行的补充测试来确认实际环境中的代码功能。

然而,这并不是旅程的终点。此类解决方案主要用于自动化测试,而开发人员经常希望在开发过程中与应用程序进行手动交互,或寻求各种利益相关方(产品、销售、管理、潜在用户等)的反馈。在没有云部署及其相关时间损失的情况下实现这一点仍然是一个挑战。

因此,我们需要能够生成既可以在本地运行,也可以在云上运行,并能快速执行的测试。此外,我们必须支持云应用程序的快速部署,并为利益相关方的验证提供方便。

通过实现这一点,我们可以显著地提高迭代速度,无论代码是由人工智能、人类还是它们一起协作创建的。

那么,我们如何将这一愿景变为现实呢?

引入 Wing

Wing 是一种用于云开发的新编程语言,它使人类和 AI 开发人员都能在更高的抽象级别上编写云代码,并且它还附带了一个本地模拟器,可以让开发人员快速地进行测试。

 

量化改进

正如我们将在下面演示的那样,我们讨论的是代码减少 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 可以使用经过验证的可靠工具进行部署。

现在,让我们来看看同样的代码在当今领先的云开发栈之一——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 开箱即用,配有一个本地模拟器和一个可视化的调试控制台。

这些工具使开发人员能够通过近乎即时的热重载方式来处理代码,并可以非常容易地测试云应用程序,而无需模拟周围的云环境。

在上面我们那个非常简单的应用程序示例中,为了运行测试而部署到任何云提供商都需要将近一分钟的时间,而使用 Wing Simulator 只需要不到一秒钟的时间,或者说少了两个数量级。此外,使用 Wing,你可以在不模拟云的情况下编写测试,并在模拟器和云上运行相同的测试。

你可以在 Wing Playground 上亲身体验。

结   论

尽管 Wing 在云开发方面引入了重大的改进,但我们知道,迁移到一种新语言是一项艰巨的任务,在许多情况下可能难以证明其合理性。

我们竭尽全力通过以下功能来使该语言的采用变得尽可能容易:

很容易学,因为它和其他语言很相似。

能与现有的堆栈和工具(尤其是部署和管理)无缝协作。

成熟的生态系统——能将任何的 NPM 模块或 Terraform 资源导入到代码中。

集成到现有的代码库中——能用其他语言编写运行时代码,并用 Wing 引用该代码。

此外,我们相信,在人工智能时代,采用 Winglang 这样的新语言对人类来说更容易,因为人工智能有助于用不熟悉的语言和框架来编写代码,并简化了现有代码向新语言的迁移。

随着我们迈向人工智能在代码开发中扮演更重要角色的未来,像 Winglang 这样语言的创建和采用将确保人类和 AI 开发人员更好的协作、更快的开发和更高质量的应用。

想要一窥未来,体验在 Wing 中编写代码并立即进行测试,可以访问我们的游乐场。




审核编辑:刘清

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分