61–70 of 126 posts
Earlier quoted context omitted.
Well his personal taste likely informed the design decision to use capitalization to confer some semantics for a variable.
I'm not sure I see how capital letters make a language harder to syntax highlight.
Let’s say I want to declare a pointer to a variable length array (what Python calls a list and Go calls a slice) of pointers to FooType objects: var foo *[]*FooType It reads very simply ... What???? Not that it's better in other languages but this makes the article feel like satire. It reads like "The Ugly" and "The Bad". Aside: What's with the completely defective comment syntax on HN? Can anyone give some hints on…
I don't think there would be a simpler way of describing a type as complex as "a pointer to a slice of pointers to FooType". Simpler variables are declared as var a int or with type inference: var a = 10
[FooType]
Slice
Earlier quoted context omitted.
Well Rob Pike did call it "juvenile" and compared it to those colored rods that are used to teach children how to count. http://news.ycombinator.com/item?id=5125958
He was joking. But still, it's his personal taste to not use it.
If it was someone else on board in Go, we might have had a vastly better language.
Earlier quoted context omitted.
Well his personal taste likely informed the design decision to use capitalization to confer some semantics for a variable.
I'm not sure I see how capital letters make a language harder to syntax highlight.
I'm just speculating here. I don't really have an opinion one way or the other, although I don't think anyone's an idiot for having an opinion about it, as the OP does.
Earlier quoted context omitted.
I'm not sure I see how capital letters make a language harder to syntax highlight.
It doesn't, and I wasn't arguing that... I was suggesting that if one were to prefer reading and writing code without highlighting, one might be more inclined to design a language such that capitalization carries some semantic weight. I'm just speculating here. I don't really have an opinion one way or the other, although I don't think anyone's an idiot for having an opinion about it, as the OP does.
Earlier quoted context omitted.
If I'm fixated on changing private -> public, that's because it's a common case. I doubt I'm alone with a programming approach of "start with everything private and expose public behavior only as necessary". More philosophically, I have to wonder what the benefit of this capitalization scheme is. Just to avoid typing 'public'? Hardly seems worthwhile. To make it obvious when reading code? This is the same argument fo…
The two major virtues of case-based visibility: 1. It creates a coherent syntax for making names visible that works both for member variables and package variables; you don't ever have to wonder how to expose something, because you always do it just by making the name uppercase. 2. It allows readers to see at a glance without thinking whether a value is public --- it's public if it's a proper name. In practice, Go st…
#1 does not seem to be a real issue. Most similar languages have the common, popularly understood, and easily-remembered keyword "public". Whereas capitalization is an exotic special rule that must be learned. If "you don't ever have to wonder how to expose something" is an important measure, I think Go is at a disadvantage here - especially if you want your code to be read by neophytes.
#2 is the argument for hungarian notation. Why is it important to visually distinguish public/private as opposed to, say, local vs member variable? I point this out because IDEs have a long history of visually distinguishing local vs member variables and some programmers even use naming prefixes like '_' or 'm_'. Yet I've never seen an IDE highlight members based on visibility. Given this backdrop, it's certainly not obvious that visibility requires such an important visual reference. And why shouldn't the IDE be responsible for this decision? Counterarguments that programming languages should be designed for 80-col amber VT100s sound pretty wacky in 2013.
Regarding terseness of the language, I'm not convinced. Without exceptions, Go adds an ton of "if error then return error" boilerplate to practically every function call. This is a lot more typing than adding 'public' to struct members.
Earlier quoted context omitted.
He was joking. But still, it's his personal taste to not use it.
I find I tend to disagree with most of the design decisions of Rob Pike, from minor (like that one), to the more important like the bogus emphasis on compilation speed and the half-baked excuses on not having Generics. If it was someone else on board in Go, we might have had a vastly better language.
But it sounds like you don't like Go. As you say, it's heavily influenced by Rob's personal vision of how things should be done. Plan 9, unicode, refusal to complicate the parser etc. They're all decisions that have given Go its (IMO) unique feel. Without Rob we'd have a vastly different language, certainly.
Earlier quoted context omitted.
What do you think of Go so far? (I've written ~10kloc). Did this article in any way change your mind about it?
To be frank, no. The article pretty much sums up my conclusions too. I generally like Go, but dislike some of the design decisions (like the lack of Generics, or the special casing of a few select structures). Not much sold on the error handling either. But those would be minor gripes if it had real good performance, which it does not, considering it's a statically typed, compiled language. It's been around 2x faster…
To me, there are two kinds of languages:
1. Languages that are fast enough that when I'm writing in them I can tell myself "no matter what I write, it can't possibly be slower than what Ruby would have done for me". C obviously falls into this class, as does Java, and Go.
2. Languages that are so slow, like Ruby and Python, that it doesn't matter what I do in them, short of picking the right problems to work on in them.
If I wrote a lot of kernel code, or games code, I'd probably have a third class of language that would admit C but not Go. Similarly, if I broke languages up by runtime footprint, I could make C work for embedded stuff for which neither Java or Go would work.
Obviously, this is all subjective.
Earlier quoted context omitted.
I don't think there would be a simpler way of describing a type as complex as "a pointer to a slice of pointers to FooType". Simpler variables are declared as var a int or with type inference: var a = 10
Two examples come to mind: [FooType] and: Slice If you think you must, apply sigils. The position of the brackets in the Go version is atypically bad for readability.
Where do your examples say they're pointers?
How would you express this using your first syntax?
*[4]*FooTypeEarlier quoted context omitted.
They mean syntax and semantic highlighting. It's mostly a generational thing that goes along with 80 column line widths on amber terminals.
I wonder how much of that is older programmers being used to not having highlighting, and how much is younger programmers having never tried programming without it. I think the default assumption is that it is all old people resisting change (hence the 80 columns amber terminals bit), but I'm a younger anti-highlighting example. I am not old, I learned to code with coloured syntax highlighting. I didn't realize how m…
If anything, I think coloring is slightly helpful, but I'm fine without it.