761–770 of 788 posts
Earlier quoted context omitted.
I’d say that globally we have agreed on a system of units and measurements. It’s just the US and a handful of third world countries that don’t follow that system.
Only USA, Myanmar and Libera are switching to metric
Earlier quoted context omitted.
> time++; // increment time This isn't too many comments, it's a poor quality comment. Try: time++; // advance 1 simulated second
Like many comments, I find we can eliminate it without losing anything by using better variable names. seconds++; That gets the idea across very clearly to me and has the benefit of (likely) making the rest of the code clearer too
types for the win
Earlier quoted context omitted.
Patrick Naughton came from the Smalltalk world, so Java is definitely inspired by Smalltalk, but he didn't bring along the oriented bits. Its object model is a lot closer to C++'s. To have objects does not imply orientation.
“When I use a word,” Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…
Earlier quoted context omitted.
As someone who worked with Haskell and Rust in production this is a nightmare: - All functions end up returnig `Either/Result` - Stack traces are gone - Exceptions and panics can still creep so it's not even "safer" - There is no composability of different result types, you need something like `Either which is not supported in most languages (I think Scala 3 and Ocaml have this feature), or you create a "general wrap…
Stack traces are valuable and important, agreed. (In Scala it's pretty normal to use Either/Result with an exception type on the left so that you still get the stack trace). And it's definitely possible to carry an error state around too far when it's not recoverable and you should have just errored out earlier - ultimately you still need good coding judgement. "All functions end up returnig `Either/Result`" is a sig…
That's why I'm against checked exceptions in general: I avoid them in Java as much as possible.
> "All functions end up returnig `Either/Result`" is a sign you're doing something wrong.
I agree, that's why I'm sharing that it's a bad idea. I've had this experience recently in a team of very experienced developers (some of them who even have books written). In the wild you have Go in which essentially all non-trivial functions return `X, error`.
> How do you do e.g. input validation? Things that are going to be 4xx errors not 5xx errors, in HTTP terms
Recently I've been working on a piece of code that deals exactly with that. For such use cases we use the `bool Try(out var X)` pattern which follows what you have in the standard library (see `int.TryParse(string input, out int result)`) which works but I'm not a fan of. For this use case a `Either/Result` would work great, but is a very localized piece of code, not something that you would expect to see everywhere. Also, you might want to roll (or use) a specialized `Validation` type that does not short-circuit when possible (ex. in a form you want to check as many fields as possible in a single pass).
In summary, I'm not against the existence of `Either/Result` in general, I think there are great use cases for them (like validation); what I'm against is the usage of them to signal all possible type of errors, in particular when IO is involved.
Earlier quoted context omitted.
As someone who worked with Haskell and Rust in production this is a nightmare: - All functions end up returnig `Either/Result` - Stack traces are gone - Exceptions and panics can still creep so it's not even "safer" - There is no composability of different result types, you need something like `Either which is not supported in most languages (I think Scala 3 and Ocaml have this feature), or you create a "general wrap…
Effect systems such as Bluefin (my own) and effectful allow you to have multiple possible exception effects in scope without having to cram them all into one type (with some sort of "variant" or "open sum" type). It's a very pleasant way to work!
Most to all I agree. I disagree with monoliths and microservices. I am not a fan of microservice per se but I'm not a fan of monoliths either. I certainly prefer a mix depending on their use cases. However both designs deserve equal scrutiny. My monolith horror started when I was working with Ruby developers. The problem with a monolith is when it becomes too big for itself. Realistically something between microservi…
You can build everything the wrong way. In my experience making a monolith modular is organizationally easier than gluing together microservices and step on various toes and getting rid of needless abstractions.
Microservices if used sparingly in the right way are fantastic as they can offer flexibility in APIs that do not necessarily need a monolith obfuscating certain behaviors away from the monolith making the architecture more secure.
Everything needs to be purposefully built and used with the intention of serving the customer's needs without compromise.
I would posit that the exact enviroment you are in changes massively what is correct, what is a good rule of thumb and what is a bad practice.
What applies to a game developer does not apply to a web developer. What applies to a product developer does not apply to a library developer. What applies in a startup does not apply in a legacy org.
I'm sure there are some universal truths, but usually they are principles and not prescriptions.
E.g. Code should probably lean toward readability, but you quickly come up against time constraints, language constraints, performance constraints, interpersonal conflict, etc.
Edit: To that end, I would ask that when discussing what we find to be useful or not useful, that we caveat with the enviroments that we have found this to be true.
Earlier quoted context omitted.
I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, th…
> The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. It can't, and it won't, as long as we insist on always working directly on the "single source of truth", and representing it as plaintext code. It's just not sufficient to comprehensibly represent all concerns its consumers have at the same time . We're stuck in endless fights ab…
Earlier quoted context omitted.
There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…
Let's talk about in the way you seem to interpret it. Imagine if Blueprint A used imperial units while others used metric units. That's what inconsistent code style does to you.