Proposal: 表达式体验优化与引擎更换 about arthas HOT 11 OPEN

感觉可以分开为两个事情来讨论：

1. 在现在的基础上增加 QLExpress 支持
2. Arthas 是否要考虑增加功能：表达式执行之后，把结果保存到某些 缓存/临时对象 里

QLExpress 支持

1. 在 arthas 的表达式引擎里，增加 QLExpress 的实现。通过一个全局的配置，用options命令可以切换。默认的表达式还是用 ognl
2. 收集真实的用户反馈，再决定是否把默认的表达式引擎 替换为 QLExpress

表达式执行之后，把结果保存到某些 缓存/临时对象 里

这个很久之前就有这个想法。但也有一些可能出问题的地方。

• 比如对象是否线程安全的。比如调用对象的 函数，解析展示对象的某些 Feild

我建议是先实现第一个 QLExpress 支持，可以分多步来演进。

from arthas.

@hengyunabc 多步演进的话，实现层面没啥问题。推广层面存在两个重大问题：

1. 没有新功能吸引用户来尝试新表达式，大多数用户肯定不会去升级新版本，或者尝试新表达式。既然没有用户，那也不可能收集到反馈
2. 缺少一个重大新功能更新一起运营宣传，吸引不了用户注意力，大多数用户都很难知道这个更新。也就很难有真实用户的反馈

多步演进也得考虑这两个推广问题，不然很容易流产。至少要有足够的运营素材，方便推广。这也是我建议把两件事一起做的原因。

1. arthas的首要目标是保持稳定。我相信好的功能用户会自发推广使用的，arthas本身便是如此。
2. 推广和多步演进 并不冲突。
3. ognl 在集成到 arthas 之后，也发现了不少问题。同样 QLExpress 应该也会遇到问题，我们需要保持足够的耐心来解决这些问题。

@hengyunabc

ognl 和 arthas 本身都是增量市场，不需要考虑推广问题。ognl 是 arthas 第一次集成表达式，属于新增功能，肯定会有用户尝试。QLE 做存量功能替换的话，用户动力没这么大。不会有用户为了新引擎，看文档，知道并且加这个选项的，第 1 步最大的可能没用户知道选项，然后没用户用，这是最大的可能。

大佬肯定也不希望这变成一个烂尾工程，如果要多步演进的话，避免烂尾，我觉得要考虑得更周到点：

1. 增加 options 新选项，可能没有用户用和反馈，需要有这个预期。这个也是正常的，不影响我们下一步推进。
2. 多步式作为 QLE 独占的新功能推进，可以成熟后，晚些上线。然后以这个为契机，会有更多用户尝试新表达式引擎。
3. 然后再根据用户反馈，决定是否将默认的表达式也切成 QLE

from arthas.

多步表达式的方式也是我一直赞成的方式，现有热门的脚本语言都有REPL，使用方式简单而且深入人心。

• 为了不影响现有使用习惯，可以将类似subprocess作为函数引入，执行命令，subprocess.run(["watch", "demo.MathGame", "primeFactors", "-x", "5"], out=PIPE, text=True) 。其中PIPE可以是一个outputStream，这样不用考虑如何表达将watch的结果存起来。
• 基于表达式和语句还可以做成jupter notebook的操作界面，编写自动化流程

from arthas.

Arthas和QLExpress的用户，看到了内部技术产品联合很兴奋！可以支持需求的快速迭代，这个效率是用外部工具比不了的。
对于用户说，定位排查要快速，数据分析要容易上手，REPL模式是能够让数据分析的成本降低的，可以考虑支持一个快速导出导入脚本到REPL的能力，对于场景问题定位的话能够类似像批量跑场景自动化case一样，做到问题的快速归类和定位

from arthas.

idea的插件，生成的表达式 后面也会改成QLExpress 吗

from arthas.

Arthas 较复杂的表达式体验确实有待优化， 引入脚本语言确实是一个好的idea，能解决一些痛点问题

from arthas.

idea的插件，生成的表达式 后面也会改成QLExpress 吗

这个要看一下后续如何演进 ，ognl 和 QLExpress 应该都会支持，可能独立一个插件出来。

from arthas.

多步表达式的方式也是我一直赞成的方式，现有热门的脚本语言都有REPL，使用方式简单而且深入人心。

• 为了不影响现有使用习惯，可以将类似subprocess作为函数引入，执行命令，subprocess.run(["watch", "demo.MathGame", "primeFactors", "-x", "5"], out=PIPE, text=True) 。其中PIPE可以是一个outputStream，这样不用考虑如何表达将watch的结果存起来。
• 基于表达式和语句还可以做成jupter notebook的操作界面，编写自动化流程

我在正文中用的方式是类似 shell 的赋值语句:

n=${原生Arthas命令}

如果是类似 PIPE 的方式, 在命令行上要如何表达呢? 我理解类似管道命令? 但是在表达式场景下也需要绑定某个变量, 才能拿这个变量使用

from arthas.

Arthas和QLExpress的用户，看到了内部技术产品联合很兴奋！可以支持需求的快速迭代，这个效率是用外部工具比不了的。 对于用户说，定位排查要快速，数据分析要容易上手，REPL模式是能够让数据分析的成本降低的，可以考虑支持一个快速导出导入脚本到REPL的能力，对于场景问题定位的话能够类似像批量跑场景自动化case一样，做到问题的快速归类和定位

这个想法很好啊, 听起来是一个更加上层的诊断平台了

from arthas.

感觉可以分开为两个事情来讨论：

1. 在现在的基础上增加 QLExpress 支持
2. Arthas 是否要考虑增加功能：表达式执行之后，把结果保存到某些 缓存/临时对象 里

QLExpress 支持

1. 在 arthas 的表达式引擎里，增加 QLExpress 的实现。通过一个全局的配置，用options命令可以切换。默认的表达式还是用 ognl
2. 收集真实的用户反馈，再决定是否把默认的表达式引擎 替换为 QLExpress

表达式执行之后，把结果保存到某些 缓存/临时对象 里

这个很久之前就有这个想法。但也有一些可能出问题的地方。

• 比如对象是否线程安全的。比如调用对象的 函数，解析展示对象的某些 Feild

我建议是先实现第一个 QLExpress 支持，可以分多步来演进。

@hengyunabc 多步演进的话，实现层面没啥问题。推广层面存在两个重大问题：

1. 没有新功能吸引用户来尝试新表达式，大多数用户肯定不会去升级新版本，或者尝试新表达式。既然没有用户，那也不可能收集到反馈
2. 缺少一个重大新功能更新一起运营宣传，吸引不了用户注意力，大多数用户都很难知道这个更新。也就很难有真实用户的反馈

多步演进也得考虑这两个推广问题，不然很容易流产。至少要有足够的运营素材，方便推广。这也是我建议把两件事一起做的原因。

from arthas.

@hengyunabc 多步演进的话，实现层面没啥问题。推广层面存在两个重大问题：

1. 没有新功能吸引用户来尝试新表达式，大多数用户肯定不会去升级新版本，或者尝试新表达式。既然没有用户，那也不可能收集到反馈
2. 缺少一个重大新功能更新一起运营宣传，吸引不了用户注意力，大多数用户都很难知道这个更新。也就很难有真实用户的反馈

多步演进也得考虑这两个推广问题，不然很容易流产。至少要有足够的运营素材，方便推广。这也是我建议把两件事一起做的原因。

1. arthas的首要目标是保持稳定。我相信好的功能用户会自发推广使用的，arthas本身便是如此。
2. 推广和多步演进 并不冲突。
3. ognl 在集成到 arthas 之后，也发现了不少问题。同样 QLExpress 应该也会遇到问题，我们需要保持足够的耐心来解决这些问题。

from arthas.