Why is it so hard to make things simple for developers?

Earlier, we wrote that one of TON’s biggest problems is its complexity for everyday users. But there’s another issue, less visible from the outside: TON is often hard on developers too. And the less they want to stay in the ecosystem, the worse it is for everyone. Here’s an #opinion on the matter — feel free to share yours in the comments.

Experienced developers sometimes say: “It’s much easier to build on other blockchains.” What makes their work harder here is mainly the blockchain’s asynchronous model. The FunC smart contract language has also been criticized.

Newcomers don’t have it easy either. Someone arriving from Ethereum quickly finds that familiar approaches don’t work here. In a TON tutorial, they’re told to “choose a language: FunC, Tolk, or Tact,” which immediately raises questions: “How do I pick between three unknown languages? Why are there even three?” They might choose Tolk… only to discover that the sample code from the tutorial doesn’t run.

At this point it’s tempting to look for someone to blame:

Why didn’t Nikolai Durov design the blockchain to be simpler?
Who decided to confuse people with three different languages?
Why isn’t there a smooth onboarding path for beginners?
Is it really that hard to make life easier for developers?

The answer seems to be: yes, actually, it is that hard. It was hard to build one of the world’s first scalable blockchains at a time when best practices didn’t yet exist. It’s hard to design a language that’s both simple and powerful on the first try. It’s hard to avoid “breaking things” along the way: for instance, changes to Tolk made some published tutorials obsolete, with sample code that no longer worked.

That said, if you look at the situation over time, you can see the issues being recognized and gradually addressed. First came the realization that “developers struggle with FunC,” so more user-friendly options like Tact and Tolk were created. Then Tolk was made the “recommended” language to reduce the confusion of choice. Back in the day, working with TON meant fumbling in the dark with minimal documentation and tools. Compared to that, it’s now far more accessible.

So pointing fingers doesn’t feel fair. A lot of capable people have put serious effort into TON, and many problems have already been solved. Still, in a tough period for TON, the pressing question remains: will the ecosystem’s biggest developer pain points be fixed in time — and will developers still be around by then?

@thedailyton