11–20 of 335 posts
(1) var thing Thing json.Unmarshall(reader, &thing)
(2) var thing *Thing = new(Thing) json.Unmarshall(reader, thing)
in (1) thing is a variable for a value of type Thing, while in (2) thing is a variable for a Thing pointer
shouldn't thing (2) need to be dereferenced first?
> To be clear, I don’t mean to dismiss the work of a lone programmer toiling on programs without anyone to pair with or learn from. I’ve been that person many times in my career as a programmer, it’s not fun. I'd say it's a lot of fun.
Earlier quoted context omitted.
I’d say it’s in fact where the real fun happens
Working on personal projects, not having to conform to other people’s requirements, trying a bunch of cool hacks and getting to see how things really work…that’s the most fun part of programming!
But the author said "in my career," which I took to mean during the course of ones paid employment.
Earlier quoted context omitted.
Working on personal projects, not having to conform to other people’s requirements, trying a bunch of cool hacks and getting to see how things really work…that’s the most fun part of programming!
Side projects are probably the most fun that can be had with programming, not just for the freedom of requirements but also because you can build something you truly enjoy building. I'm lucky to be writing fun code at work - most of the time -, but the side projects keep me sane for many reasons. Not having to deal with 'bad' code that I didn't write, is also a nice benefit. All the bad code in my personal projects i…
Earlier quoted context omitted.
Side projects are probably the most fun that can be had with programming, not just for the freedom of requirements but also because you can build something you truly enjoy building. I'm lucky to be writing fun code at work - most of the time -, but the side projects keep me sane for many reasons. Not having to deal with 'bad' code that I didn't write, is also a nice benefit. All the bad code in my personal projects i…
Bs, nobody will read your code. 1 per 10 000 maybe. And even that 1 will be polite enough. Don't spread this bs - people shouldn't be afraid of shaming when they have some code to publish.
EDIT: I have deleted the original statement. After your comment it made me think that it might involuntarily scare people from sharing things in the open source world, which is not my intention.
just new to Golang (in programming in general, actually) and this bug me. in the slide, it's indicated they are semantically the same. but how? (1) var thing Thing json.Unmarshall(reader, &thing) (2) var thing *Thing = new(Thing) json.Unmarshall(reader, thing) in (1) thing is a variable for a value of type Thing, while in (2) thing is a variable for a Thing pointer shouldn't thing (2) need to be dereferenced first?
In C++ it would look like this:
(1) x = thing.Property;
(2) x = thing->Property; (or (*thing).Property)
(1) x = thing.Property
(2) x = thing.Property
just new to Golang (in programming in general, actually) and this bug me. in the slide, it's indicated they are semantically the same. but how? (1) var thing Thing json.Unmarshall(reader, &thing) (2) var thing *Thing = new(Thing) json.Unmarshall(reader, thing) in (1) thing is a variable for a value of type Thing, while in (2) thing is a variable for a Thing pointer shouldn't thing (2) need to be dereferenced first?
They're semantically the same. The type of thing isn't, but that's syntax.
Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read.
Focusing on readability of the code and putting "machine execution" second, means putting the user experience second, after the developer experience. Imagine a race car engine which is designed first to be simple for an unfamiliar contract mechanic to repair, and secondly to power a race car, with the justification that the engine "will be repaired more often than it will be built". I have my suspicions that software which is fast, responsive, and a pleasure to use is designed by people who put the machine first; even if that means using difficult languages and low levels of abstraction and requires high levels of skill.
The most important skill for a programmer is the ability to effectively communicate ideas
Iverson Notation was designed as an improved way for people to communicate ideas, years before it got turned into the programming language APL. Look where that got it.
Go programmers realise that code is written to be read and so place the act of reading code above the act of writing it. Go goes so far as to enforce, via tooling and custom, that all code be formatted in a specific style.
Books are created to be read, not written. That doesn't happen by enforcing that all books have the same style and formatting.
If software cannot be maintained, then it will be rewritten; and that could be the last time your company will invest in Go.
Pushing a cult is the last word in the slides?
> To be clear, I don’t mean to dismiss the work of a lone programmer toiling on programs without anyone to pair with or learn from. I’ve been that person many times in my career as a programmer, it’s not fun. I'd say it's a lot of fun.
just new to Golang (in programming in general, actually) and this bug me. in the slide, it's indicated they are semantically the same. but how? (1) var thing Thing json.Unmarshall(reader, &thing) (2) var thing *Thing = new(Thing) json.Unmarshall(reader, thing) in (1) thing is a variable for a value of type Thing, while in (2) thing is a variable for a Thing pointer shouldn't thing (2) need to be dereferenced first?
> Unmarshal parses the JSON-encoded data and stores the result in the value pointed to by v. If v is nil or not a pointer, Unmarshal returns an InvalidUnmarshalError.[1]
In (1) the '&' in '&thing' means roughly "the address of", so you are passing "the address of thing" i.e. a Thing pointer that points to the thing variable.