Golang is verbose, as modern languages go. In its idiom, it's actually a little more verbose than some modern, tight C (though less verbose than most C code, and much tighter than Java).
It's the difference between "programmable programming languages" (which the lisps are, as are haskell and ruby) versus "languages for programming in" (exemplified by go and java).
Go code is very terse compared to the general run of "languages for programming in". And if you know the language, you can just read it.
On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty.
On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty
I wish this meme would stop. Your "if you know the language, you can just read it" applies just as much here as it does there.
I think you can be pretty proficient in writing regular Clojure and still find macros "twisty". Most Clojurians would agree that "The first rule of Macro Club is Dont Write Macros".
Well, I wish that meme would stop too. It makes macros sound all freakazoid, when really they're just another technique.
The obvious and natural and historically standard guidance is "Don't write a macro when a function will do."
The concrete example is a perfect use case for a macro: In other languages you have to understand and change the compiler implementation to achieve the same effect. That's most likely more work.
Another interpretation is that you can read "programmable programming languages" at the level of the problem domain, rather than at the level of the base language. (Assuming the problem domain is encoded sufficiently decently in a DSL).
Depends on what you compare it to. Go doesn't have macros and idiomatically prefers C-style for loops to higher-level abstractions (except for the built-in "range" construct) for iteration. So in general Lisps like Clojure offer more opportunities for terse code. (Which style is easier to understand is of course a never-ending debate.)
It's a bit more verbose than popular dynamic languages like ruby, python, clojure, etc. but a lot less verbose than Java, C#, or C. To me it feels roughly on par with javascript LOC-wise, though it has much stronger constructs.
That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?
Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you. Your absolute statement is false when looking at most of the valued literature over the last few hundred years.
The more verbose code is, the more prone to error and less maintainable it is.
I think this is true, but only to a certain point. Past that point the code becomes more difficult to understand and less difficult to maintain (for example all variables with one-letter names, few new lines). So there's a continuum there between terse impenetrable languages, and verbose impenetrable languages on either extreme, and you disagree with the OP about where on that continuum Go falls. It's all a matter of opinion and frankly is more subjective than objective and depends on things like the standard library and culture of the language far more than the syntax.
There are also many other factors in being maintainable and error prone - verbosity is only one of them. So saying that Go is more verbose than language X doesn't really tell us much about how prone to error or maintainable Go is compared to language X on its own. For what it's worth, I find it comparable to languages like C, Ruby or Python in terms of verbosity, which feels about the right place to stop being terse to me. YMMV.
>Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you.
I don't value verbosity and I do appreciate the works of those authors: I do not consider them verbose. Verbosity is not a measure of the absolute length of a document; it's relative to a minimum expression of an idea. Per this definition, all verbosity is unnecessary because it conveys no additional information.
What a curious statement. James did not consider the 'minimum expression of an idea' a virtue, he's almost infamous for his verbosity, as are many of the others in that list. I'll leave you with something from the start of The Ambassadors as an example:
The principle I have just mentioned as operating had been, with the most newly disembarked of the two men, wholly instinctive--the fruit of a sharp sense that, delightful as it would be to find himself looking, after so much separation, into his comrade's face, his business would be a trifle bungled should he simply arrange for this countenance to present itself to the nearing steamer as the first "note," of Europe.
I don't consider that verbose at all. It expresses a great deal more information than you're giving it credit. It would not be easy to pare down without destroying this information. Thus, it is very close to the minimum expression of the intended idea.
One mans verbosity is another's great literary detail.
The same is true for programming languages, the fact some languages make you two say 2 lines, to achieve what another language does with one, can itself be a benefit or not. It might force the developer to make the same mistake twice, otherwise resulting in a compiler error. Or it might allow extra space for a mistake to creep in.
It is the perspective of the users and the context that determine if something is right or not. This project has apparently 14,000 classes, with about 3,500,000 lines of code. It is verbose, but it is also very manageable. A smaller more 'intelligent' less static language would make working with this a lot harder.
terseness is not a feature Go is striving for. That being said, it's still more terse than most other statically typed languages, simply due to type inference. You do have to write out some loops that other languages provide syntactic sugar for... people from those languages call that verbosity. Gophers call it clarity :)
Well, it's not so much syntactic sugar as having the power to abstract them away via generic functions like map, which I'd argue are both more clear and less error prone.
