Content
@
https://ethereum.org
0 reply
0 recast
0 reaction
sudo rm -rf --no-preserve-root /
@pcaversaccio
A smart contract programming language that prioritises readability, simplicity, and auditability is not just a good idea—it's essential. In our ecosystem, unlike in fields like aerospace engineering where only experts can design and build aircraft, anyone can build and deploy smart contracts. This democratisation of building capabilities—which is a feature to be clear—means we can't just cater to the 1% of highly skilled developers who excel at memory optimisation and EVM intricacies. Instead, we need to empower the 99% who could easily make costly mistakes. Built-in guardrails ensure safer development, and readable code is invaluable for auditors and the broader community. Most people appreciate a language that makes their work more secure and accessible, even if they might not admit it. You may not like this approach, and I'm not here to patronise, but complexity is the bridge to simplicity and not the end goal.
3 replies
1 recast
13 reactions
I. Christwin〔▸‿◂〕💡
@ichristwin.eth
Well sad, However, it now seems that this feature has been demoted by many blockchain ecosystems outside of Ethereum, in the quest for high throughput chains 🥲 My journey toward becoming a solidity developer started as a result of being able to read the source of my favourite dapps in 2017 and coming up with my own ideas, that I was curious to implement. I strongly agree that the languages we use to build these contracts should be as intuitive as possible to an normie reader. How else can we maintain the mantra of "do not trust, verify!" 🤨
0 reply
0 recast
1 reaction
Sumaa
@sumaa
100% agree. On the extreme other end of the approach you're suggesting is maker contracts. Maker contracts have an insane amount of TVL, yet reading their contracts is nearly impossible unless you spend quite some time getting used to it. I never understood the rationale behind the unique naming convention
0 reply
0 recast
4 reactions
Philip Sheldrake
@sheldrake
I believe our work on homoiconic modeling will be relevant here. More immediately, and with different but related and complementary potential benefits, it seems to us that there’s something here … https://www.wolfram.com/natural-language-understanding/ … not least in the contexts of the very recent emphasis at Wolfram on a “symbolic discourse language”.
0 reply
0 recast
1 reaction
