fckgnad

If you've been programming for 30 years, it doesn't show. I'm sorry.

This is what a relation is: https://www.techopedia.com/definition/21677/relation in the context of relational databases.

I think you're confused.

>What string manipulation is required in the ORM phase?

You're just on some strange pedantic purity bent as the other person commented. Even the op refers to his "query builder" as an "orm". Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder.

Despite all this it's fairly obvious you know what we mean and what we are trying to say. You're just playing a part here.

The distinction between smalltalk and other oop languages is not relevant.

The majority of the human race thinks of java as oop and is referring to such languages when communicating. Please do the same.

>I'm not sure object oriented programming ever really caught on.

Uh they have. They were the dominant paradigm for a long time. You haven't been around long enough. I'm going to be real with you, a lot of what you say shows that you're relatively new.

>Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures?

Doesn't seem like a relation. Seems like your referring to a single table with no relationship to other tables specified.

You took a tuple and converted it to a named tuple. In SQL named tuples or named sets is the exclusive syntax... all columns are defined by name and type, all columns are queried by name. Indexed ids must be explicitly defined and in SQL they are not the default.

>Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code.

This is incorrect. First off with an orm you are implementing your datastore in two places. You define the model in SQL and redefine it in application code. There is no separation here. The orm is by definition a leak. It destroys the concept of a single source of truth.

Second. A change in schema in SQL necessitates a change in model in application code. It cannot be separate by definition. Otherwise your model in code doesn't match what exists in reality.

>String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory.

Where on earth does Json come from? No man. String manipulation is what an orm does for you. SQL databases can only operate on strings. If you don't have an orm then you are doing the string manipulation yourself because strings of SQL are literally the only interface these databases can accept.

I don't think you fully understand the mechanism at work here. Your orm is sending strings to your SQL database over a network. That is what an orm is.

>I think too many people try and discuss tools based on things that aren't relevant or are idealistic or that remove the nuance from the argument.

Some people think the universe is just apple and oranges. Everything is a tool that can be used somewhere nothing is truly good or bad. Well how about that? On the entire earth there isn't a technology that is absolutely great or raw shit and anyone who has such an opinion lacks nuance or is too idealistic.

No. To over-rely on nuance is to say nothing is black and nothing is white and everything is nuanced even when the nuance is inconsequential. This is wrong. Generalities and essential truths exist. For example, punching yourself in the face is generally bad, but if you talk about nuance and context then if you had a poisonous bug on your face, then punching yourself to save your own life is a good thing. But despite this the generality remains true.

The nuance for ORMs is only this: if you want to create a tree or a graph for graph algorithms like bfs or dfs on top of a non graph database then ORMs are literally the main abstraction to use. That's it. This is rare, because usually you have other databases other then relational that are better for this. But if you don't have the resources to load an entirely new type of database into production then ORMs are one way to perform graph algorithms on an existing SQL database.

For this instance the situation is clear, the nuance is negligible. ORMs are bad for most cases the same way eating poison is bad for you in most cases. If you want to talk about the nuance of when eating poison is sometimes good for you, be my guest. But the generality remains true.

>I think any discussion of tools without a clearly scoped use case is next to useless.

Agreed. Let's scope it to the all practical use cases seen in the wild. My argument is for the vast majority of use cases ORMs provide little benefit other then cosmetic.

This whole thing about scope is quite pointless imo. Because obviously the above scope I described basically what I'm referring to. You know it. Why do I need to spell this out specifically or be useless? Shouldn't the implication of scope be derived automatically from the discussion via usage of common sense?

If you want static checks it needs to be done separately from the main language.

What I find is that a good ide or editor is capable of doing this for a string if you tell it what that string is.

Static checks are not a reason to create a whole new abstraction over a language. As I said it's a sign that new features are needed as an extension. In terms of type safety for SQL I find certain ides already cover most of this so even a typescript style extension on top of SQL is not needed.

I stated in my first post that the proper abstraction is an extension to SQL. It is ok to extend a language to cover missing features or correct mistakes.

Typescript and sass are extensions, that's why they are good. ORMs are not extensions.

Before the advent of advanced natural language processing like chatGPT, SQL was literally one of the highest level of language abstractions we can arrive at. It's declarative and English like.

Thus, given that SQL is generally at the highest level... any abstraction you would've built on top SQL would inevitably and in general not be higher. These abstractions are movements in progress that are horizontal in nature and therefore relatively pointless.

The point of most abstractions is to provide a higher level interface. An orm does not do this. Instead an orm is a shift in philosophy that declares the SQL philosophy to be incorrect.

I don't completely disagree with that philosophy. But the proper way to implement your philosophy is to write a database; not a transpiler that transpiles your philosophy onto a technology with a different philosophy.

I completely agree. I think it's ocd thing. Programmers turn to ORMs because they appear elegant as it gets rid of string manipulation.

You need a higher level perspective shift to realize that the orm is actually the uglier abstraction then just using plain strings.

It's a generality that's generally true. It's also common sense.

For the same reason why Translating python to ruby is generally and obviously pointless.

The main thing that makes ORMs alluring is that people don't like to mess with a language in a language. Dealing with strings is inelegant.

Seeing why the orm is worse then string manipulation requires a 4 dimensional perspective shift that's really hard for people to comprehend.

>The role of ORM is to convert relations (sets of tuples) into the object structures our applications usually model data as.

I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go.

You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations.

You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual.

Here's another way to put it:

The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.

ORMs are bad because it's a high level abstraction on top of a high level abstraction. SQL is already high level, so it's pointless to build on top of it. It also makes things much much more harder as SQL is a leaky abstraction and all leaks need to be passed through from one high level abstraction all the way up another one.

Let's say I wanted to build an abstraction on top of ORMs. You would think I'm crazy. Why? Pause here for a bit.

Your rationale here... is exactly why you don't want to build an abstraction over SQL.

Anyway. The author does have a somewhat valid point about the auto joining of foreign key relationships on a table. But this is only one missing feature. Creating a whole new high level dsl on top of another high level dsl just for this is over engineering.

The real abstraction needed here is some sort of extension to SQL. Either extend the language itself in the standards, or the implementation or typescript style via transpilation.

The only other valid reasoning behind ORMs is just cosmetic such that you don't have to have to deal with SQL primitives as strings inside another language.

I kept making comments because nobody answered. I now have answers thanks.

I'm looking for a person who has done BOTH meth and MDMA and I want him to compare the experience of each. My guess is that Meth operates on another level of profoundness, one that is both different and significantly higher then MDMA.

My guess is that once you take Meth, MDMA isn't really that big of a deal anymore.

I am not comparing coke and MDMA nor am I comparing LSD. I know the profiles of those drugs I am not referring to that. Those drugs have less overlap with MDMA.

Have you done MDMA AND heroin/Meth? More important meth. Because these drugs have a huge overlap when you examine the physiological effects. Pleasure, love and bliss are generated by the same chemical.

The topic at hand here is not hallucinogenic drugs. MDMA is not hallucinogenic.

The topic at hand is centered around drugs that generate pleasure. You're a little left field with hallucinogenic drugs. I'm sure there's some sort of "profoundness" there as well but it's a different topic.

I'm just taking it up a level. I'm guessing the meth user looks at you and says,

"You clearly haven't taken Meth."

If MDMA users claim it's profound, is it really the same in the eyes of a meth user who has done both MDMA and meth? If the meth user can invalidate the experience with his own, then what does it say in general?

I already stated the risk is irrelevant to the discussion.

Here's a better way to phrase the question. Has someone who has taken both MDMA, heroin and Meth care to explain the differences in "profoundness" or "life affirmation" levels of each drug?

I suspect ignorance is bliss. People who haven't taken MDMA don't know how profound it is. People who have taken MDMA but not Meth don't realize that MDMA is childs play and that Meth is even more profound.

All feelings, drug induced, or not aren't really there. None of it is real.

Truth is just an expression. I use it in the same light as "profoundness".

I understand the stigma associated with the drug. But the emotions generated by the drugs themselves are in reality actualized by the brain and that actualization cannot be invalidated. It is worth it to ask, think and wonder about this actualization even when you have no plans around taking the drugs yourself.

Another perspective: The box was never meant to be open. We are not meant to understand the full truth of the universe.

There are other boxes too, each box with a slightly different experience and each with a different price to pay. The price is irrelevant to the discussion though.

My question for you is, why is MDMA profound? Why the focus on this particular box. Why aren't you talking about the profound experiences generated by meth or heroin?

Strongly typed languages already did take over the software development paradigm. It happened when Java, C++ and C were the dominant languages. Then it regressed back to dynamically typed languages as ruby, php, python and js skyrocketed into popularity.

With the advent of typescript and other things like it... types are now back in vogue but for how long?

The universe is a four dimensional loop. Programming, like history, like life, moves in an endless flat circle. It's all so predictable... Because This ENTIRE thread represents a precursor to the inevitable and impending oscillation back to the beginning of the circle. Types will fall out of vogue and history will repeat.

Important distinction:

Are types worth it? Yes. Is typescript worth it? Maybe.

Exactly. My post is the realization of two things:

1. All of us reading this post are more likely to be part of the 80. We are all likely delusional and we are all likely to be wrong.

2. The second thing to realize is that one person out of those 100, is Actually better then everyone else. Who is he and how do we find him? I'm curious about whether this person said yes or no.

Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things?

You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion because you can see it in other people.

I am here to tell you that there is a higher plane of understanding. This higher plane of understanding is this:

Even when you are aware that others are prone to biased and fallacies, this awareness does not make you immune to those same biases and fallacies. Because what you understand is also cliche. You are voted up because your awareness is also shared by others. Others observe the biased and fallacies of other people and think that they themselves are above it when in actuality everyone is just looking at each other. We are all mirrors.

There is an even higher plane of understanding. I am not on this level and neither are you. This plane of understanding is the realization that one of us is NOT delusional. Someone is actually right. Someone sees the reality of how something should work and he is right and he is ACTUALLY surrounded by straw men.

The tragedy of the design of computer programs is that we have no theory of efficiency, no theory of what is most optimal. So if someone is right, we have no way of knowing. We are doomed to forever live in a world of blog posts where one of those blog posts is right but we can't know for sure.

You obviously wrote this because you think that the author of the blog post is NOT that man. But because we have no theory to prove otherwise, you simply state common tropes of human fallacies and biases and you use that analogy to discredit his post. It's pointless. Analogies aren't proof, they are themselves delusions but weaponized and used to seemingly prove a point or discredit one. They are convincing but manipulative. Your post can actually discredit every blogpost in the universe and that is why it is useless, pointless and manipulative.

Rather then write sweeping analogies of human biases which can actually "disprove" every single blog post on the face of the earth... offer evidence and example scenarios about why you disagree. Because personally I think the blog poster is right. His thoughts on microservices is correct. Convince me about why he isn't that one guy who is actually right, but know that the argument is endless because none of us can actually verify anything.

Nooo acronyms are horrible. When you have hundreds of services that are acronyms it becomes a nightmare.

I disagree. But cute is better than a fucking acronym. Never never never use acronyms or one letter variable names.

No. I know what DI is. The debate is similar to imperative vs. OOP. But this is not exactly what I am referring to. Literally look at the second example, it's DI over and over and over again.

I am referring to DI 100%. Function composition works better and is a replacement for DI. You're the one that isn't getting it.

Either way, imperative programming and OOP are orthogonal concepts. There never really was an argument about imperative vs. OOP.

Additionally function composition is an FP concept. I'm not promoting FP over OOP here... far from it, I am simply saying that specifically for DI, you can borrow a pattern from FP and use it in place of DI because function composition is a much better pattern.

The Dependency injection pattern is just not that great in general. There are alternative patterns that are better.

It is not a problem with frameworks. Think about it. If the pattern was good, then a good framework must exist. If no good framework exists then logically it is very likely that Something is wrong with the Pattern itself.

Anyway the reason why DI is bad is because it's too complex. In your program, you should have logic, and then have data move through that logic to produce new data or to mutate.

When you have dependency injection, not only do you have data moving through logic, but you have logic moving through logic. You are failing to modularize data and logic and effectively creating a hybrid monster of both data and logic moving through your program like a virus.

The pattern that replaces dependency injection in this: functions. Simple.

Have functions take in data and output data then feed that data into other functions. Compose your functions into pipelines that move data from IO input to IO output. If you want to change the logic you simply replace the relevant function in the pipeline. That's it.

One very typical pattern is to have IO modules get injected into modules so that one can replace these things with Mock IO during unit testing. With function pipelines things like IO modules should be IO functions, not modules injected into other modules. When you want to unit test your function pipeline without IO simply replace the IO functions with other mock IO functions. That's it. I will illustrate with psuedo code below.

    compose(a,b) = lambda x : a(b(x))
    a * b = compose(a,b)
    pipeline = IOoutput * x * y * z * f * IOinput
    pipeline()

The above is better then:

    class F(IOinputClass):
         f(x) = IOinput()
    
    class Z(F)
         z(x) = F.f(x)

    class Y(Z)
         y(x) = Z.z(x)

    class X(Y)
         x(x) = Y.y(x)

    class IOOutput(X)
         print(x) = print(X.x(x))

   pipeline = X(Y(Z(F(input))))
   pipeline.print()

You can see the second example is more wordy and involves unnecessary usage of state when you inject logic into the module. (I left out the constructor that assigns the class instance to state but the implication is there).

Dependency injection is a step backwards. It decreases modularity by unionizing state with logic. It's a pattern that became popular due to the prevalence of using classes excessively. If you can I would avoid this pattern all together.

I see, my mistake.

Yes.

For functional programming it is a required optimization for performant programs.

This is because loops don't exist in functional programming. The base way of imitating looping in functional programming is recursion then building abstractions on top of the recursion like map and reduce.

Yes, you're right. My mistake.

They're talking about the developers working on spark and K8? That's different. But I don't think they are talking about that. They are more likely talking about using these tools.