651–660 of 788 posts
Earlier quoted context omitted.
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?
The old Carlin bit, was going to mention. :-D. I think he used, “asshole.”
Can someone explain the ORM thing to me? I’ve been a developer for 8 years but never really worked on an app that was really database dependent. ORMs for me have always been convenient, and the performance has been fine. I understand there’s obvious tradeoffs I’m making, and in some cases full control is necessary, but I’ve never seen it happen. What level of complexity does an app need to get to before an ORM become…
* They hide the queries. When your DB or cloud service gives you a printout of your 10 slowest queries, you then have to figure out what object code that relates to. And then is there even a way to fix it, or are you stuck with the ORM?
* LINQ-specific: Love the tech, but it's unclear whether my .wheres() are being sent upstream properly, or if I'm downloading the whole database and filtering it in memory.
* Another LINQ one: we wanted to do "INSERT IF NOT EXISTS" but could not.
* Back in Java land, magic like that tends to be incompatible with basic hygiene like consting all your class fields. Frameworks like being able to construct a Foo in an invalid state, and then perform a bunch of mutations until it's in a good state.
* They make it near impossible to reason about transaction states. If I call two methods under the same open db context, what side-effects can leak out? If I try to do an UPDATE ... SET x = x + 1, that will always increment correctly in SQL. But if read x from an ORM object and write back x + 1, that looks like I'm just writing a constant, right?
* Extra magic: if you've read a class from the db, pass it around, and then modify a field in that class, will that perform a db update: now? later? never?
But just in general, I want to look at the data, play with queries in a repl environment until they look right, and then use directly in the code without needing to translate from high-level&declarative down into imperative loops, sets and gets.
Earlier quoted context omitted.
What is wrong with time++; That seem obvious enough to me without any comments.
Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.
I tend to be a minimalist when writing comments. If I have to write out a comment to describe what I'm doing (like "advance 1 simulated second"), then I have failed at writing clear code. Sometimes I will write a comment to explain why I am doing something, if it's not clear (like "manually advance time to work around frobbing bug in foobar").
Comments add to your maintenance burden. Writing clearer code can often reduce that burden.
>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very…
Earlier quoted context omitted.
If there is anyone here who has time to explain to me (or link articles about) why functional components and hooks are considered to be better than class components, please enlighten me. Up until roughly 4-5 years ago I was doing small front-end React apps on the side (I'm a backend engineer) and was feeling very productive with class components. They made sense to me, concerns were nicely separated, and I felt I cou…
I only knew React until my current job, which uses Vue. I'd strongly recommend trying a framework other than React for your next project. After you're past the learning curve, it's much more intuitive.
> Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Excepti…
It was botched from the start because there's so many opportunities for unchecked exceptions as well. Without a more sophisticated type system that represented nullability, you can get NullPointerException anywhere. Divide by zero. And so on. You also have a problem similar to "monads and logging": if you want to log from anywhere in your program, your logging function needs to be exception-tight and deal with all th…
Recoverable errors should all be checked exceptions, and a part of each function's type signature. This would still be a huge pain to deal with, though, with the existing syntax.
> 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.
Is it ms? seconds? days? weeks? months? How far up do I have to read to figure that out? When I'm looking at a test case is broken, I ideally want context IN the actual test that lets me understand what the test author was thinking when they wrote it. Why does this test exist as it does? Why are the expectations that are in place valid? Write the comments for you-in-2-years.
I would prefer `somethingSec`, where "something" indicates the usage better than "time". E.g. `delaySec` or `elapsedSec`.
> You literally cannot add too many comments to test code (I challenge anyone to try) I think it is possible, depending how you write them. If you write long comments interspersed with the code, you have a lot of scrolling to do follow the control-flow. Long block comments should go at the top to "set the stage", and then lightly interspersed comments throughout to remind of the specific steps, where necessary. > Ver…
> ORMs are the devil in all languages and all implementations. Just write the damn SQL I'm re-evaluating this again. I used to be all-in on ORMs, eventually became annoyed with the shortcomings and the performance problems, but am realizing the disadvantages of foregoing them as well. * ORMs Bad: ORMs often lead to deep object graphs and tight coupling if you don't know what you're doing / don't factor the model prop…
This sentence is golden, it advances the bullshit bingo score better than the rest.
But honestly, in SQL the invariants should be constraints and triggers, enforced by the DB, not just by the application layer.