- cross-posted to:
- [email protected]
You must log in or register to comment.
Software craftsman
Fart sniffer detected
Am I wrong or does that title he’s given himself directly contradict his dislike of code ownership? Or is it just he assumes he deserves credit for the code written by any of his subordinates?
Lmao ok ill just follow best practices and end up inadvertently writing an orm from scrach then 🙆♀️
Extroverts cannot comprehend introverts.
Lol. Let’s ban accountability, refactoring, and debugging, never work alone, never coordinate, avoid productivity, and refuse ownership—then scream when things break, don’t integrate, and fall behind schedule.
“This is all your fault!” built-in. Why didn’t you intuitively know what myX is supposed to do and how it’s used?
Provocation just for “engagement” really. 102 comments so, to some degree, it works.
E: Guys, it’s satire. Lol.
Golang outside of infrastructure
What does that even mean?
Golang is petty slow with a GUI I’ve found, a web UI works well but GTK or something like that is slow. Maybe that’s what he means?
- ORM’s
- Place ALL of the business logic in stored procedures.
- Eliminate the backend.
- Make the front end connect directly to the database.
Profit- Introduce tons of bugs and terrible performance.
- Database is compromised within five minutes of going live.
I’m confused. Are you saying all of that is a consequence of not using ORMs? Because if so, that’s absolutely not true. ORMs truly are complete trash.
Sounds like you were hurt by an ORM.
One huge benefit of an ORM is that it does type checking. it makes sure your tables exist, relationships are valid, etc, and it makes easy things easy. If you add a column, it’ll make sure it gets populated, give you decent error messages, etc.
As long as you use a proper repository pattern setup and isolate DB interactions from the rest of the code, how you construct the queries is completely up to you. I try to use DTOs to communicate w/ the repo layer, so whether an ORM is used or direct SQL queries is largely an implementation detail.
https://github.com/launchbadge/sqlx
Not an ORM, but uses Rust’s compile time macros so you can write raw SQL and it will type check everything against either a real database connection or a JSON cache of the database’s schema.
Absolute best of both worlds.
That sounds really nice, I’ll have to check it out.
I have for years been pumped to create a sql only side project or sql + frontend
Code Ownership
Lol did someone try and make him maintain the shitty code he wrote
Individual accountability
Team accountability is almost always better.
Group punishments so that the group will give sock soap to the individual. Best of both worlds
jeez dude you’re carrying a lot of baggage
Correct, but sock soap is the solution
No mutable types? So like… no lists? no for … i++?
I get that there are alternative approaches, but I don’t quite see why you’d want to go to that extreme with this idea? It’s useful for some applications but even for a simple video game it’s likely not helpful.
It’s perfectly possible to work without mutability.
Is it desirable to be entirely without it? Probably not, but leaning immutable is definitely beneficial.
There are non-mutable lists and every other data type.
https://docs.scala-lang.org/overviews/collections-2.13/overview.html
https://docs.scala-lang.org/overviews/collections-2.13/concrete-immutable-collection-classes.html
“for… i++” is easily replaced with a foreach, range, iterable, etc… in any language of reasonable capability.
I get that there are alternative approaches, but I don’t quite see why you’d want to go to that extreme with this idea? It’s useful for some applications but even for a simple video game it’s likely not helpful.
I should’ve said that right away, really. That’s on me being online while tired. At that time I did not really think outside the box I was working in that day
It’s just a very common foot gun, especially in legacy code where it is not explicit in the design. Even when you have proper getters and setters, it’s way to easy for someone to overload the scope of some object, either intentionally or accidentally and modify it inappropriately.
I suppose immutability is a solution, I’m not sure if it’s a good idea to radically isolate everything though
it’s not radical, it’s just a guarantee that if you hold a reference to an object, it won’t change state under you. It’s a bit like every object has MVCC and copy-on-write semantics built in.
It’s easy enough to edit the object, producing a new copy, and then explicitly store it back where it goes or send it to whatever consumer needs it.
I get the idea, and how you keep it from copying a lot of data unnecessarily. A radical approach would be using immutable types exclusively
Oh, regarding copying data - immutable collections are based on https://en.m.wikipedia.org/wiki/Persistent_data_structure - when a change is applied, you get back a reference to a new data structures where as many inner references as possible are shared with the old one. So, all the parts that didn’t change, are not copied.
For something like a Scala case class (similar to a record), o.copy(membername1 = newvalue) returns a new object, with a new membername1 reference, but all other member references are the same as the copied-from object. So it’s a shallow copy with minimal changes.
you might see how default immutability as a policy makes this more predictable and able to be reasoned about - any mutable object in an object graph that has a shared reference in a copy may surprise you by suddenly changing state.
Of course, that’s the situation everywhere, all the time, in default-mutable languages. How many people set a default value of a Python function argument to [] or {} and were baffled when things started breaking because the instance of the default value was mutated?
Wow, the only one I agree with here is MongoDB (and probably Lombok, I don’t write Java), and that has more to do with their licensing issues than anything technical.
That’s pretty impressive.
Here’s my list:
- no-go list of languages - Java, PHP, Ruby, C++ (unless you absolutely need C++ for some domain)
- OOP - OOP should be isolated, not forced on every problem; many OOP advocates are dogmatic about injecting it everywhere
- waterfall - screw that noise, faster to market + faster feedback is generally better
That’s really it, and I’m totally willing to mentor someone who likes the above if they’re otherwise a good developer.
If you had to write Java you probably would like Lombok if you dislike boilerplate (it can build object constructors, comparators, and field accessor methods via annotation).
Java is boilerplate though. It’s finally getting almost tolerable with static imports, arrow functions/lambdas (whatever Java calls it), etc.
If I had to write Java, I’d push for Kotlin instead, after failing to convince management that there are much better options for the problem they need to solve.
You can say you’re running Java and write components in Kotlin or Scala, no one knows after the module is published!
He didn’t rule out BASIC so he good in my books.
Ew…
That’s: 10 PRINT “Ew…”
