191–200 of 332 posts
Earlier quoted context omitted.
> I just go with their suggestions. Why though? I am not going to go with suggestions if they make the code less readable for me!
I think the whole world would benefit if we’d make it so that code formatting happened separately from what was committed. Then everyone could have their local checkouts formatted the way they wanted and there would be nothing to argue about in terms of coding style.
It becomes much easier to understand what data exists and build tools on top of it's schema. But the extra cludge it adds to optimise the specific case of returning less data in a field is often counter productive.
Earlier quoted context omitted.
People keep repeating this, but it's not true. The interface has so many "this flag in this case" but "this other flag in that case" and "that command doesn't support this flag like that" etc. There's no composability or orthoganality or suggestiveness. It's nonsensical and capricious and unmemorable, even though I understand the "simple" underlying model and have for years.
Has anyone attempted to re-engineer a superior UX on top of the git data structure? Would it even be possible?
Earlier quoted context omitted.
This was adapted into a novel about IT/devops called The Phoenix Project. It's an excellent read.
I second this. Quite the entertaining read, honestly. I also enjoyed the completely unnecessary transformation of the security dork into a security ubermensch.
Anyone want to share their main takeaways from these books?
"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." — Linus Torvalds
Amateur mathematicians worry about patterns, professionals worry about numbers
> Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. I wish people would follow this rule and just let stuff work. I recently encountered the most extreme version of this I've ever seen in my career: a design review where a guy proposed a Redis caching layer…
That case you've seen speaks of the guy's inexperience and lack of understanding. I have a problem with this rule because what I see happening is people taking it to heart and no longer thinking about what they're doing performance-wise. And then the program is working 1000x slower than it should, at no extra gain (and often a loss) of readability or safety, just because someone decided to use O(n) data structure whe…
This rule a la Pike is about doing things like writing assembly or manually unrolling loops in noncritical parts of code. However, in some code, almost everything is on the critical path, and that requires architecture. I’m thinking of Carmack’s single function game loop here.
I remember working on a project that claimed to want 10,000 transactions per second. “Okay”, I said, “how much can be accomplished in 100us?”
They looked at me like I was an idiot. “No, it’s going to be clustered and pipelined.”
“Ok, if you can do that maybe you have a budget of 1-5ms.”
“No, we’re going to give each transaction up to a second to get done”
I smiled and admitted that they were obviously a lot smarter than me. Oddly enough the product never saw the light of day.
I feel ike #5 is why many people like GraphQL, and #1 - #4 is why many hate it. It becomes much easier to understand what data exists and build tools on top of it's schema. But the extra cludge it adds to optimise the specific case of returning less data in a field is often counter productive.
Could you elaborate?
Earlier quoted context omitted.
One way of looking at it is that equipping our data with that bookkeeping gives us something that commutes.
Hmm sure, but it is not a requirement that your underlying algebraic structure should commute, so I think original phrasing was misleading. The bookkeeping allows you to commute a specific list of objects, even though the underlying operation is anti-commutative (i.e. exists a,b a.b != b.a). At the moment of computation, you can build a new structure that commutes by enumerating the data. I guess it's true that you n…
As an interesting nit, "anticommutative" specifically means that a.b = -(b.a), which is different than simply not being commutative.
A group might be commutative, anticommutative, neither, or even both (trivially true of the empty group and the group with one element, but I think it can be true of larger groups).
Modeling the problem domain is so important that I dont know why the first year of every compsci undergrad program isnt entirely dedicated to teaching the idea. Instead, day 1 is installing python or java, running hello world and talking about pointers, binary, encoding, logic gates, etc. We should be teaching students on day 1 that code is a liability and to be avoided whenever it is convenient to do so.
"1. From Problem Analysis to Data Definitions
Identify the information that must be represented and how it is represented in the chosen programming language.
Formulate data definitions and illustrate them with examples."What tends to happen in real life is that the profiling and optimization of bottlenecks is forgotten once the software is "ready".
I would propose Rule 0: Developers are irrelevant, only end users of your software matter.