191–200 of 788 posts
by the way, whats wrong with serverless functions?
Given a long enough time horizon, you'll deeply regret building on Serverless Functions> Most programming should be done long before a single line of code is written Nah. I (16+ years developer) prefer to iteratively go between coding and designing. It happens way too often that when you're coding, you stumble across something that makes you go "oh f me, that would NEVER work", which forces you to approach a problem entirely differently. Quite often you also have eureka moments with better solutions th…
Think about design and code (and functionality!) before you start coding. Think about design as well as code while you're coding. Think about design, code, and functionality while you're testing.
Earlier quoted context omitted.
Starting with raw SQL is fun. But at some point you find out you need some caching here, then there, then you have a bunch of custom disconnected caches having bugs with invalidation. Then you need lazy loading and fetch graphs. Step by step you'll build your own (shitty) ORM. Same thing for people claiming they don't need any frameworks.
> you find out you need some caching here, then there Forgive my ignorance, but how do ORMs help with adding caching? Or are you implying they obviate or reduce the need for caching?
Earlier quoted context omitted.
> you find out you need some caching here, then there Forgive my ignorance, but how do ORMs help with adding caching? Or are you implying they obviate or reduce the need for caching?
JPA implementations have "managed entities", sometimes called session or 1st level cache which is making sure that every entity is loaded at max. one time within a transaction. Like e.g. checking user/user permissions is something which typically has to be done in several places in course of a single request - you don't want to keep loading them for every check, you don't want to keep passing them across 20 layers, s…
> 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…
I have seen so many people going on and on about best practices and coding styles and whatnot and using big words just in hopes to keep discussions going so no one figures out out that they don't know how to code.
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…
> the formatting and conventions of the blueprint Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information. I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenat…
Earlier quoted context omitted.
I'm kind of wondering where the "mixed experience levels" part comes from. What is it about more homogeneously skilled teams that makes them less susceptible to the productivity boost that statically typed languages give in large code bases?
I'm reading in it that experienced developers (be it overall or in a specific codebase) "know" all the ins and outs, types, conventions etc, whereas less experienced people cannot yet know all of that; being able to lean on good types and / or other types of automated checks helps them make more confident changes.
Earlier quoted context omitted.
> They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. Syntactic sugar it needs is an easy way (like ! prefix) to turn it to a runtime exception. Procrastinating on exceptions is usually the correct thing to do in your typical business application - crash the current business transaction, log the error, return error resp…
The try/catch/rethrow model can easily be substituted by just adding a `throws` to the method. If you truly don't care, just make your method `throws Exception` or even `throws Throwable` and let the automatic bubbling take care of making you handle exceptions at top level.
Earlier quoted context omitted.
Let me try to explain it a bit more. From my experience, functional programmers come in two flavors. The ones who constantly nag others by telling them "everything you do is wrong", and "hey, come here, I want to show you something!". Unfortunately, the first camp is way more dominant than others. Again, from the same article, there's observation "People who care about the craft are rare. Cherish the who cares, meet…
Really? You think most functional programmers are arrogant? Have you considered that your position is lazy, and that actually you have the problem?
I mean, most (not all) functional programmers I met (for the last 20 years, no less!) started to praise functional programming by bashing imperative programming languages and never asked me about what I like about programming, and why I was so adamant to stay away from functional paradigm.
When you start selling what you like as an omnipotent silver bullet without listening to what the other party is saying, or by calling the other party lazy and the root of the problem you drive away people from the thing you are selling,
like you're doing right now.
Extra points for you for doing this, even after I have politely said that I have left that beef behind and trying to find the time to learn functional programming, and PLT in depth. Chef's kiss, actually.
> 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…
In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on. [1] https://en.wikipedia.org/wiki/Law_of_triviality