21–30 of 362 posts
I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…
And functions should be no bigger than your head.
This is my least favorite programming advice. Splitting functions for no reason other than "it's too long" is a bad practice. https://news.ycombinator.com/item?id=25263488
Earlier quoted context omitted.
Hah, I wrote it in a comment myself a while back :) (I'm the author of the article): https://news.ycombinator.com/item?id=24919615
Oh, nice! Seems like we got the same thing out of the article.
Sometimes an analogy is funny but that doesn't make it less wrong...
I like the sentiment of this article. It's a great analogy. Might be a little off topic, but it reminds me how I am happy that the Go programming language and its philosophies gained popularity even though I don't use the language regularly. Watching Go talks made me appreciate simplicity and clarity. It made me accept that I don't always need to use every design pattern in the book. It made me think about the reader…
I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…
I agree with this part assuming that graphics and video along with the words are allowed.
>"I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably start over."
This is very narrow minded approach that will only work for a very limited set of possible domains. Simplest example to the contrary: the domain is a creation of efficient way of solving some math related problem. What query?
Earlier quoted context omitted.
What if my cranium is extra large? Do I get to write bigger functions?
Python's developers must have enormous heads if that's the case: https://github.com/python/cpython/blob/b8fde8b5418b75d2935d0...
Earlier quoted context omitted.
Python's developers must have enormous heads if that's the case: https://github.com/python/cpython/blob/b8fde8b5418b75d2935d0...
It's mostly a giant switch case for opcodes though, that's not really what is meant here.
I would say functions are important, but absolutely pale in comparison to modeling[1]. If you are unable to describe, on paper, what your problem domain actually is , then you have no business opening up an IDE and typing out a single line of code. I will take that further. If, with your domain model, you are unable to craft a query that projects a needed fact from an instance of the model, the you should probably st…
What if code is needed to explore the problem domain? There is utility in discovery, especially for analysts/data scientists who tend to write a surprising amount of code.