小白上手 Github Copilot：花一个星期写了个轻量级 ggplot

meeeeeeeeo

yihui 借鉴所有 ggplot 的设计智慧

丢块砖头先，从产品的角度来看，设计智慧有以下几方面：

数据可视化概念下，基本的作图元素和组合方式
原始（上一代）作图代码的方式，不便点
ggplot2 通过什么范式的代码风格，解决了哪些痛点问题
ggplot2 的使用群体的使用场景/代码习惯
ggplot2 有哪些缺点/改进点

lovebluesky

瞎说点有的没得:

跟 ggplot 熟的自然肯定是喜欢一样的命名方式，无缝过渡。
从推广角度，自然是一样的名字对更多的人友好。
如果是我的包，我就宁肯翻烂字典自己起名字，自己的崽，不愿意和别人起一样的名字，也不想被别人说做模仿或者其他，我就要打上自己的印记。别人的东西有名无名跟我无关。虽然都是基于图层，但毕竟这个基础是来自 grammer of graphics，而非 ggplot。
从使用角度，即使不一样的名字，有什么关系呢，这年代还有AI 帮助文档都能读，更何况没有 AI 时代的自动补全都可以做到 tab 搞定，我甚至觉得可能不用字典翻烂，把想法丢给 AI，然后从它给的选项里大概率能找到灵感。
我觉得公式挺好的。

以上观点带有强烈的个人主观倾向，因此并非个人建议。如观点相左，无需在楼下批判，我自己承认。

yihui

lovebluesky 我甚至觉得可能不用字典翻烂，把想法丢给 AI，然后从它给的选项里大概率能找到灵感

这事儿真还有点难，我自己想也想破了头，跟各家 AI 聊也聊烂了键盘，愣是没找到一套我满意的动词或名词。看你们谁家的 AI 强，来帮我出主意：https://github.com/yihui/gglite/issues/45

不过呢，我确实同意你说的，反正将来都是 AI 来写代码，具体是啥函数名也不像过去那么重要了。这么说来我又要脑洞大开了，用阿猫阿狗米老鼠唐老鸭史努比风雷水火土影佩恩六道来给这些图形元素命名也未尝不可……

lovebluesky 如果是我的包，我就宁肯翻烂字典自己起名字，自己的崽，不愿意和别人起一样的名字

这让我想起姩菡这个名字。

chuxinyuan

函数和变量命名真的是一件很纠结的事情，这也是我喜欢管道的很重要的一个原因。题外话，base R 的函数命名要是一开始就限定好不用驼峰，不用点，只用小写和下划线连接该多好啊！不同编程语言同一个功能的函数用同一个函数名该多好啊！回归正题，关于函数名甚至是里面的参数名的问题:

一分为二，有好处也有坏处。我觉得保持名称一致的好处是将来两个包无缝切换，减少用户学习成本，也方便功能对标，跟 AI 提需求也会更方便。坏处是容易被 ggplot 的车辙约束，变得不自由，缺少新意。

合二为一，好处总体上大于坏处。名称保持一致总体上开发成本和学习成本都相对更小，有肩膀踩，不踩白不踩，前期可以采取先完成再完美的渐进式迭代升级策略，后期有不满意地方可以再新增新的函数名小修小补即可。

Cloud2016

yihui 我个人不是很喜欢 Tidyverse 带火的 NSE 风格，也就是不带引号的变量名，所以这个包里要么是用简单粗暴的字符串变量名，要么用公式，长远看我个人有点倾向于用公式

这里我说一句，从使用上看，少打引号，就好像少了层语法束缚，这是 ggplot 的选择。
使用公式语法确实很 R 范，函数 g2() 越来越像函数 plot() ，用公式也是 plotly 包的选择。

Cloud2016

来帮我出主意：https://github.com/yihui/gglite/issues/45

Base R 提供的函数 labels 和 transform 都是泛型函数，有没有可能 gglite 提供自己的实现，这样加载 gglite 包就不会与 Base R 命名冲突了呢？至于 title_ 的功能，收进 labels 里，不知道是否可能？因为我想到 ggplot2 包只有函数 labs() 来负责标题（包括图、轴、图例等）。

yihui

Cloud2016 Base R 提供的函数 labels 和 transform 都是泛型函数，有没有可能 gglite 提供自己的实现，这样加载 gglite 包就不会与 Base R 命名冲突了呢？

我了个去，摆在眼皮底下的答案为啥我没想到？！天才啊你。来，壮士请留下收款码，这个天才想法值得为你加一个月鸡腿！

Cloud2016 至于 title_ 的功能，收进 labels 里，不知道是否可能？

呃，这个恐怕不行，因为 G2 里 label 的概念是在主图区域内对图形元素打标记（不限于文本标签）；标题不属于标签的范畴。当然，也不是说我需要严格遵守 G2 设定的框架，只是我感觉无论 labels() 还是 labs() 都不像是与标题相关的名词；ggplot2 用了 labs() 大概也是抓破了头要避讳 title()。目前我暂时用了 header() 这个名字来加标题和副标题（并设定它们的样式）。

lovebluesky 不过我不赞成谢大起名太天马行空了，毕竟我没看过火影，谢大的写轮眼什么的，我不看介绍我是真不知道啊。

同意。

chuxinyuan 是个办法，但要投票的事情可能还有点多啊。我是选择困难症患者，脑子能承受的选择题非常有限，尤其左也有理右也有理的时候，经常会杀了我。

lovebluesky

函数命名确实很麻烦，尤其是现在好多好名字都被占用了的情况下,楼上讲了要是最初规定好使用小写字母加下划线该多好，这个也很难讲，毕竟这是一种习惯，我最开始的时候也觉得这种方式很方便，后来学了点C和python，也不觉得其他方式不好，当然现在流行的是下划线。
我个人不觉得太需要考虑无缝过渡的问题，如果按照我的习惯，我可能更喜欢使用add_这种形式加图层，例如：
g2() |>add_point()|>add_barplot()
这种形式，手机码字，打符号不方便，就这样凑合这个意思得了，应该能表达清楚我的观点，实际上我觉得g2用的也不好吧，我是觉得没必要非得对标ggplot，即使都是基于图层的语法，毕竟他只是grammer of graphics的实现，也不能说最早吧？最早是不是grid和lattice?我并不确定啊，这几年记忆退化的厉害，我只是想表达，没必要非得遵循别人的规矩。我觉得gg都比g2顺眼，可能测试代码随便写的时候我会随意加个数字，懒得想名字，但是正式情况，我觉得带数字挺丑的。

目前想到这些，还是相当于个人感情的宣泄，毕竟不是正主，站着说话不腰疼。不过我不赞成谢大起名太天马行空了，毕竟我没看过火影，谢大的写轮眼什么的，我不看介绍我是真不知道啊。

chuxinyuan

确实没有标准答案，纯偏好问题。要不要考虑采取 pivot_longer() 和 pivot_wider() 产生的方法来一个投票？

lovebluesky

当年中国移动的动感地带，请周董唱的歌，我其实就能听清我的地盘听我的......

当然，倾听使用者的意见投票也是个好选择，毕竟要考虑用户的感受。

Cloud2016

yihui 开心开心，我的建议被采纳了呢！以后，用这个包，我可以吹牛皮，说我参与了这个功能函数的设计 😂 。

yihui

nan.xiao 我同意这个暴论。

给未来留出空间当然也很重要，我写包通常会考虑这个问题；只是图形这一块非我强项，我需要多借几只手电筒帮我看到更远一点的路。

Cloud2016 我也并不满意 header() 这个名字，只是各种约束条件下的一个临时解法。看样子我还得求助更多场外嘉宾。

Cloud2016 然而在实现过程中我踢到了一块铁板：定义 S3 方法对管道式用法毫无问题，但我对加号式用法的黑魔法就无法生效了，因为我把魂器交给了 base R 的函数，我得追随它的参数，无法再同时驾驭两种魔法。现在又来到一个十字路口：全盘放弃对加号的兼容，或是继续寻找类似 labels()/transform() 的新名字。

Cloud2016

我突然想到 caption 这个词来表示图标题。

chuxinyuan

Cloud2016 好像做表的包里很常见。

yihui

Cloud2016 我想过这个，但 caption 和 title 是两回事；前者存在于图之外（如 LaTeX 中的 \caption{}），后者在图内。

chuxinyuan 用公式语法一样也可以自动补全变量名，例如你敲 iris |> g2(Se 然后 Tab，就会有 Sepal.Width/Sepal.Length 候选，敲 iris|> g2(Sepal.Width ~ Pe 然后 Tab，就会有 Petal.Width/Petal.Length。至少 RStudio 是这样，Positron 我没用过不知道。我不喜欢 x = mpg 这样的裸变量名以及 NSE 有很多原因，就只说一个最让我感到如芒在背的点——对 R 包开发者来说，用 utils::globalVariables() 来绕过 R CMD check 简直是世界上最糟糕的骗术（如此这般的代码让我简直看了夜不能寐——万一什么地方误用了一个声明过的“全局变量”，比如打错了名字碰上了它，而 R CMD check 听话放过了它，那就只能仰仗作者多写点测试能检测到这种错误了）。R 语言本来最大的一个槽点就是难以静态分析，再搞这些来源难以定义的裸变量名，简直是雪上加霜。别的方面我都可以商量，但裸变量名和 NSE 我应该会在 gglite 中一意孤行地避免。

chuxinyuan

我赞同 @lovebluesky 的观点，把 g2 换成 gg，我也不喜欢字母和数字组合。另外，参数值不带引号如x = mpg这个在管道里是有好处的，mtcars 连接一个管道，然后后面的函数里输入 x = 后按下 Tab 键会自动提示。

Cloud2016

yihui 我想到 caption 是想往 title 靠，尝试沾点边。目前，用 header() 来表示标题，是 HTML 里的标记，或者段落的标题？

chuxinyuan

Cloud2016 忘记哪篇文章里提过这事了，当时还没有管道，所以 Hadley 就发明了个加号，积重难返，改不过来了。后来搞了个 ggvis 把加号改成管道符号了，但是最近两年没怎么开发了。

yihui 关于裸变量名的问题，我想起来了，我的 ecce 包里调用了 dplyr 包的一个函数，然后 CRAN 那边反馈一条 NOTE "no visible binding for global variable 'xxx'"，后来换成 base R 代码就一切正常了，尽管 fenguoerbian 当时也给出了 R 包中使用 dplyr 函数的正确办法。

nan.xiao

那么我来一个暴论：其实在 AI/AGI 时代 NSE 这种针对旧人类输入方便而设计的人体工程学魔法已经成为了鸡肋。新的设计需要优化的是写出的代码中的词元不微妙无歧义，让 AI agent 能够快速读懂 API 文档（以及建立 skill 之类的长期记忆），每次都能根据人类意图快速映射到正确的代码实现。由此易得，我们其实都应该写 Rust……

另外就是在设计上留出空间方便未来迭代，一个反例是 Tailwind CSS v3 和 v4 大版本之间做了过多的毁灭性更新，让现有模型在一时之间很难写对新版。

Cloud2016

yihui 我觉得完全可以放弃加号，保留管道式一种。ggplot2 都后悔死当初用加号来着。现在已经是管道的天下了！

yihui

Cloud2016 问题是我并不太赞成他们后悔加号的理由。我觉得数据处理和画图这两件事不应该用管道揉在同一个表达式中，所以也就不应该存在“（dplyr 式的）数据处理用管道、管道流进 ggplot2 却被迫切换加号”这种矛盾。对 GG 画图来说，我个人认为加号是更自然的选择：画图是元素叠加，而不是元素流入下一个元素（不像数据处理）。他们后悔死，我觉得是被自己制造的规则给束缚了，仿佛去掉了格律就无法写诗一样。

不过我已经想到踢开这块铁板的办法，现在基本上可以把这两个函数定型在 labels() 和 transform() 上了。加法的魔法可以继续，对管道爱好者也毫无影响。title() / header() 函数的问题我用复数 titles() 解决了，正好和 labels() 复数保持一致，本来标题也就包含正标题、副标题（虽然副标题是可选的）。

他们同样后悔死的还有 qplot()，但在这一点上，我又不太同意，我觉得快速出图的优势大于它背后的魔法带来的学习理解障碍。这就像帕累托法则一样，若快捷通道能解决相当大一部分应用场景，那我觉得就该提供快捷通道，而不是每幅图都非得严格按照那个图形语法一项项显式叠加；画个简单的散点图、条形图、直方图都要显式声明 geom 的话，我觉得好累人。