Skip to main content

What is the Core Reason for the Controversy Over Chinese Programming?

This question gets dug up and discussed every few years, and the intensity of the debate often exceeds the technology itself. I once argued that if you write an open-source library in Chinese that beats Elastic Search and kicks Kafka, then Chinese programming would be a milestone in the history of programming. You would have thousands, if not tens of thousands, of believers. But unfortunately, no one has done that yet. At that time, someone chased me down and flamed me so hard I almost got PTSD.

Having written code for a few years and experienced the transition from pure English to AI-assisted development, I might be able to offer some observations from a different angle.

The hardest reason for opposing Chinese programming is actually very simple: The existing ecosystem is entirely in English.

  • Mainstream frameworks, libraries, and toolchains are in English.
  • Q&A and documentation on Stack Overflow and GitHub are in English.
  • Error messages and log outputs are in English.
  • API documentation for third-party services is in English.

This isn't "worshipping foreign things"; it's an objective reality. You write business logic in Chinese, but the underlying calls are still HttpServletRequest. When problems arise, you still have to go to the English community to find answers. This sense of fragmentation is real.

You can try naming variables and methods in Chinese in a Spring Boot project, like 获取用户信息() (getUserInfo). It feels smooth when writing, but when debugging, you see a stack trace like this:

com.example.service.UserService.获取用户信息(UserService.java:45)
    at com.example.controller.UserController.lambda$0(UserController.java:32)
    at reactor.core.publisher.FluxFlatMap$FlatMapMain.onNext(FluxFlatMap.java:421)

The visual experience of mixed Chinese and English is indeed not very good.

In actual projects, code is not written by one person:

  • There may be outsourced teams involved.
  • Open-source components need to be maintained by other developers.
  • Recruitment difficulty needs to be considered during technology selection.
  • The cost of understanding during code review and handover.

Chinese programming is not a big problem in small teams or internal systems, but once open collaboration is involved, English is indeed the current universal language. This is not a technical issue; it's a social network effect.

Many people think Chinese input is slow. This was indeed a problem ten years ago, but now Pinyin input methods are very mature. The real obstacles lie in:

  • The cognitive burden of switching between Chinese and English (though it gets better with habit).
  • Uneven support for Chinese identifiers in IDEs (some old versions of tools may display garbled characters).
  • Display issues for certain characters under different encodings.

However, these are all engineering problems, not fundamental obstacles. I have no problem writing Chinese comments and documentation in IDEA, but I'm still used to using English for variable names.

And now, in the last few days of 2025, we must talk about AI Programming + Chinese Programming​

Has AI programming saved Chinese programming?

Many people think that in the AI era, "you can generate code just by speaking Chinese," so there is hope for Chinese programming. You talk to AI in Chinese, and AI still generates English code. This process proves that:

  • Programming requires precision, not "natural" expression.
  • Identifier naming is the least important part; algorithmic logic is the core.
  • You are describing requirements in Chinese, but requirements and code are two different levels of things.

Taking reactive programming as an example, the core issue is not whether the method is named getUserInfo or 获取用户信息, but understanding concepts like Mono, Flux, backpressure, and schedulers.

These concepts are actually harder to understand when translated into Chinese:

// English
return userRepository.findById(id)
    .flatMap(user -> orderService.getOrders(user.getId()))
    .map(orders -> new UserOrderDTO(user, orders));

// Chinese Version
return 用户仓库.根据ID查找(id)
    .平面映射(user -> 订单服务.获取订单(user.获取ID()))
    .映射(orders -> new 用户订单DTO(user, orders));

Do you really think the second way of writing looks reliable? flatMap is a term in functional programming; translating it to "平面映射" (flat map / plane mapping) loses its precise meaning.

And when you need to distinguish pitfalls in reactive programming, Chinese doesn't give you any advantage either.

For example, the following code:

    @GetMapping("增加数量")
    public Mono<ResponseEntity> 增加数量"(){
        return Mono.just(1)
                .平面映射(i ->
                    Mono.fromRunnable(() -> 一些操作())
                        .subscribeOn(Schedulers.newSingle("线程池名字"))
                )
                .映射(it -> {
                    return ResponseEntity.ok().build();
                });
    }

The bug is that every time a request comes in, a new thread pool Schedulers.newSingle("线程池名字") is created, eventually leading to a memory leak.

Moreover, AI can help you generate Chinese code, but it cannot change the collaboration nature of software engineering.​

For example, if you write a third-party library like this:

// You write in Chinese
public class 用户服务 {
    private RestTemplate 请求模板;

    public 用户信息 获取用户(String id) {
        // Here it still calls RestTemplate.getForObject()
        return 请求模板.getForObject("/users/" + id, 用户信息.class);
    }
}

Your own code can use Chinese, but the underlying dependencies RestTemplate, Jackson, Netty are all English APIs. This fragmentation is structural and not something AI can solve.

So in other words, what about using Chinese + AI programming to generate English code?​

You describe business logic in Chinese -> AI understands and generates English code -> Naming and structure in the code are generated by AI based on best practices.

In this process, the naming of intermediate products doesn't matter at all. What matters is:

  • Whether your requirement expression is clear (Chinese or English is fine).
  • Whether the generated code logic is correct.
  • Whether the code can be read by other developers or AI.

You don't say, you really don't say, this actually works. But, Gul'dan, what is the price?

The price is that you still have to read English when maintaining it!!!

If AI becomes slightly less intelligent (looking at you, ChatGPT), or if AI is blocked (Claude), and you have to manually modify the code, you will face the pain directly.

The taste of being backfired by AI is absolutely, absolutely, absolutely something that will make you "addicted". Don't ask me how I know. I once had to rewrite everything because of a one-click commit and push of code generated by AI in 5 minutes, which took me a week to troubleshoot without finding the cause.

The good thing about ancient programming methods is that I know every detail of the code.

Alright, stop talking about Chinese programming; it's really not that important. If you let me earn 7 million dollars using Chinese programming, I would write an article titled "Chinese Programming is Awesome" every day.