51–60 of 172 posts
Earlier quoted context omitted.
It needs to be rephrased into this: "Watching this video will make you into a developer who is respected 10x more by their peers."
Would it?
If respect is measured by an integer, going from level 2 to 20 is great. But if you have no respect, then gaining 10 times as much still leaves you at none.
If you are disrespected DON'T WATCH THE VIDEO unless you want to be disrespected more by a factor of 10!
Let me answer this once and for all: > What are we optimizing for? You mean who are we optimizing for. For the guy who has to understand and maintain this code 2 years from now. (This guy could in fact be you yourself). Thats why I like Go. And C, now that I think about it...
I can't count the number of times I've encountered old C code that uses pointers and bytes and arrays, and I discover a bug, and on further inspection I can't even figure out what they were trying to do. It's all just pointers and bytes and arrays. The language is too low-level to encode intent, except at the lowest level, so you're putting all your trust in comments.
I’m starting to think that I’m in the minority that agrees with most (if not all) Go’s design decision and appreciate Rob Pike’s stewardship so far.
I'm in the opposite camp from you — I like generics, lack of null, and syntax highlighting — but that's fine! I don't think this is something we have to 'agree' or 'disagree' with. It simply means that you're within Go's target market. If you want to use a simple language, and the software you're writing works just fine without these features in your code, then of course it's OK to jettison them and stick with the si…
So these debates do have some merit.
Earlier quoted context omitted.
I had a math teacher in primary school who used to shout with an exaggerated accent, "simple is not the same as easy!" She really wanted to drill the idea into our heads that just because you know exactly how to do something, doesn't mean that it will be quick or easy to accomplish. Like, for a schoolchild, long division. The rules are simple, but given big enough numbers you'll probably mess up at least once. And th…
"It is straightforward to show that..." means that you could probably do it with your current knowledge, but it will take 6 dense pages, four false starts and about a week of focused work.
The quote of "If I had more time, I would have written a shorter letter" has been quoted so often that it is arguable who said it first, but it is definitely at least a 300+ year old concept. Simplicity takes effort. It takes time. And you often cannot write simple software in the first version because you are designing it as you go. Simplicity comes from maturity both in the product design and the development staff,…
I don't like seeing this quote in the context of programming.
Sure, they're both about writing, but in different settings. A person who writes a letter has one goal: for the intent of the letter to be understood by the recipient. However, a programmer writing code has two goals: not only for the intent of the code to be understood by future programmers, but also to make the code easy to change in response to unknown requirements without causing any regressions.
The article is a bit all-over-the-place, but I do agree with it in general, because I've seen far more bugs in production caused by changing code than by adding it. Therefore, I would rather use a language with advanced features I can use to make my code harder to change in the wrong way. I think that if you phrase it like that, it makes it more acceptable to "avoid simplicity".
The language is modern and powerful enough to spare the programmer from some of the worst drudgery (unlike C) and is much more inherently safe, but it's not a jungle gym of complicated constructs and difficult quasi-mathematical concepts that (while interesting) detract from the task at hand.
Simplicity is objectively measurable. Here is a practical suggestion, though directly applied to mechanical engineering is readily adaptable to application design. https://www.sciencedirect.com/science/article/pii/S235197891... One way to think about simplicity is to accomplish the greatest number of business objectives with the fewest number of abstractions. As others have said, that isn't easy. It takes increased e…
I think the confusion around simplicity is in what terms a thing is simple. For example, 2 pieces of text can be simple in 2 different ways: First text is long but uses fewer words in vocabulary. So it is "simple" in a sense you need to learn only few words to read it. Second text is short but uses richer vocabulary to describe things with fewer words (syntactic sugar). It is "simple" in a sense you only need few wor…