I think you might be misinterpreting what GP is saying by trimming the end of the quote; they're not saying that making something easier to read makes it harder to write, they're saying that making something easy to read but hard to write is a worthy goal.
Also, I think "hard to write" is meant as "require that critical or dangerous details are written explicitly; if a feature adds convenience for writing at the expense of reading, it should be avoided". (Type inference, overloads and reflection come to mind)
I think (hope) that no one is advocating making a language verbose or complex for it's own sake.
Re:Underhanded Solidity Coding Contest
by kronos29296 on Tuesday July 04, 2017 @04:15AM
(#14694353)
Like Rust? Rust does most of those things wrt explicit dangerous behaviour.
Exactly.
Thanks, I edited my comment to be more readable.
Golang is actually a good example of harder to write imo. It has good tooling that makes life easier, but unused variables, unused imports, and a lot of other things are errors. And if you do somewhat standard linting on top, it gets even more tedious.
Frankly if it weren't for the tooling I'd not be very sold on Go. The tooling totally sells it for me.
Do you have any actual basis to back this up? My counterpoint would be Golang, which is designed exactly to be simple, and is usually really easy to read.
As in, I haven't found another language where jumping into a library and reading the internals is easier than in Golang.
EDIT: A counterpoint is JavaScript, a language which I use in my day to day, and similarly has quite simple syntax. But I can have trouble understanding what is going on depending on the tools used in the local environment.