5 ms·
>In general, the easier the code is to read, and the harder it is to write Do you have any actual basis to back this up? My counterpoint would be Golang, which
by Zyst 9y ago
>In general, the easier the code is to read, and the harder it is to write
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.
- saghm 9y agoI 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.
- serhei 9y agoThanks, I edited my comment to be more readable.
- xg15 9y agoAlso, 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.
- kronos29296 9y agoLike Rust? Rust does most of those things wrt explicit dangerous behaviour.
- xg15 9y agoExactly.
- jchw 9y agoGolang 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.