Software disenchantment
-
I'm seriously baffled by this git-bashing by windows users. I mean, it's just a directed acyclic graph with diffs on the source tree as nodes, and some labels called 'branches'. What's so hard about that? What do you need a bloody GUI for, besides displaying history?
-
@sebastian-galczynski said in Software disenchantment:
I'm seriously baffled by this git-bashing by windows users. I mean, it's just a directed acyclic graph with diffs on the source tree as nodes, and some labels called 'branches'. What's so hard about that? What do you need a bloody GUI for, besides displaying history?
-
@sebastian-galczynski said in Software disenchantment:
I mean, it's just a directed acyclic graph with diffs on the source tree as nodes, and some labels called 'branches'.
Duh.
-
@sebastian-galczynski said in Software disenchantment:
I'm seriously baffled by this git-bashing by windows users. I mean, it's just a directed acyclic graph with diffs on the source tree as nodes, and some labels called 'branches'. What's so hard about that? What do you need a bloody GUI for, besides displaying history?
I'm sure this made sense to you when you wrote it.
-
@pie_flavor said in Software disenchantment:
@sebastian-galczynski said in Software disenchantment:
I'm seriously baffled by this git-bashing by windows users. I mean, it's just a directed acyclic graph with diffs on the source tree as nodes, and some labels called 'branches'. What's so hard about that? What do you need a bloody GUI for, besides displaying history?
I'm sure this made sense to you when you wrote it.
-
@Tsaukpaetra It still makes sense. Git is easy to use once you understand its data model. Some posts in this thread reveal serious misunderstandings, like @Gąska trying to make 'git branch --delete' delete remote branches automatically on next push. I don't know how this particular patch works (now you can't push a deleted local branch), but if it replaces the present meaning of 'git branch --delete' it would effectively force you to track locally every branch you ever touched until it's deleted from upstream, which is wasteful and wtfish. You can't abstract inherent complexity away.
My take-away is that people whining about Git (like the one lone windows user in my team constantly 777ing random text files) try to use it as a black box without understanding what happens, which is probably impossible given the problem being solved (distributed version control). Those who get it, usually have no problems, unless there's a massive merge conflict, but that would cause problems with any system imaginable short of some god-like AI.
-
@sebastian-galczynski said in Software disenchantment:
Git is easy to use once you understand its data model.
That's like saying it's easy to fly Concorde once you understand aeronautics. It's complete gibberish. One thing has very little to do with the other. No matter how well you understand aeronautics, it's not going to tell you when to advance the throttle on take-off, or how to calculate fuel load for a Atlantic crossing. (In fact, if you knew all the procedures, you could do the entire flight without knowing jack-shit about aeronautics, barring some terminology that would appear in the procedures.)
@sebastian-galczynski said in Software disenchantment:
Some posts in this thread reveal serious misunderstandings, like @Gąska trying to make 'git branch --delete' delete remote branches automatically on next push.
Sounds like he's trying to make it predictable. Like "hey if I say delete, how about actually delete?"
@sebastian-galczynski said in Software disenchantment:
I don't know how this particular patch works (now you can't push a deleted local branch), but if it replaces the present meaning of 'git branch --delete' it would effectively force you to track locally every branch you ever touched until it's deleted from upstream, which is wasteful and wtfish.
I don't even understand this sentence. I won't pretend to.
@sebastian-galczynski said in Software disenchantment:
You can't abstract inherent complexity away.
Maybe not; but could they fucking TRY? Because they haven't even fucking tried to.
@sebastian-galczynski said in Software disenchantment:
My take-away is that people whining about Git (like the one lone windows user in my team constantly 777ing random text files) try to use it as a black box without understanding what happens,
So why wasn't it written with a teaching interface, so users learn how to use it as they use it? Or a discoverable UI, so you can take a look at just the program itself (without having to rely on external resources, like manuals or websites) and figure out how to accomplish the task you want accomplished? Why doesn't it have a simple "undo" so you could experiment without risk of losing all your work?
People use Git as a "black box" because that's how Git wants to be used. That's what you get when you install it. That's the only UI they wrote for it.
@sebastian-galczynski said in Software disenchantment:
which is probably impossible given the problem being solved (distributed version control).
My understanding is that there are several products that solve the same problem and are significantly easier to use than Git.
There's also the minor point that 99% of those horrible people using Git as a black box probably don't want distributed version control in the first place, as they have no need for it. The only thing the "distributed" part of Git gets them is you can work offline, but guess what? TFS 2013+ lets you work offline and it's centralized as heck.
@sebastian-galczynski said in Software disenchantment:
Those who get it, usually have no problems, unless there's a massive merge conflict, but that would cause problems with any system imaginable short of some god-like AI.
Once again: even if you know what the program is doing, it doesn't (necessarily) help to figure out how to use the program. Which is moot anyway, because if your defense of this program is, "once you read 12 textbooks it's easy!" isn't that just a way of saying it's not easy at all?
Look, let's take Photoshop. If I use Context-Aware Fill in Photoshop, I have no idea how exactly that algorithm works. But I don't need to know that to use the feature-- the developers of Photoshop did a good job of abstracting the bullshit away so the artist can focus on the task they want accomplished. Why should they have to know exactly what math Photoshop is doing to grab context-aware textures from the surrounding image? What would that gain them, if all they're doing is repairing a blotch on a photo? Nothing. It would be a waste of their time to learn it, and the developers of Photoshop understand that.
I'd say the developers of Git did a bad job of same, but the real issue isn't that they tried and failed (like, say, Lotus Notes), but that they never even tried. The product's been around since, what, 2007?, and they still haven't tried. It's hopeless.
-
@blakeyrat said in Software disenchantment:
No matter how well you understand aeronautics, it's not going to tell you when to advance the throttle on take-off, or how to calculate fuel load for a Atlantic crossing.
False. These decisions are made based on, aeronautics, and an understanding of the particular vicissitudes of the Concorde would fall in somewhere on the path to infinite aeronautical understanding.
-
@Gribnit said in Software disenchantment:
False.
Poop.
@Gribnit said in Software disenchantment:
These decisions are made based on, aeronautics, and an understanding of the particular vicissitudes of the Concorde would fall in somewhere on the path to infinite aeronautical understanding.
Of course they are, but that's not the point. Imagine this is Concorde:
In my hypothetical, you're piloting the plane, not writing the procedures. The pilot, co-pilot, and engineers don't need to know exactly how those figures were derived, they only need to know what those figures are. And they're written down in a handy binder.
-
@blakeyrat so it's even easier! Anyone can fly the Concorde!
-
@Gribnit said in Software disenchantment:
@blakeyrat so it's even easier! Anyone can fly the Concorde!
Nobody can fly it, they're all mothballed. Idiot.
-
@blakeyrat said in Software disenchantment:
I don't even understand this sentence. I won't pretend to.
And that's the problem.
I'll try to explain. In Git your local branches are not the same as remote branches. They're a different set, usually with some common elements (tracking branches). Some of your local branches may track remote branches, but not necesserily. You also may not track some remote branches. Let's say your coworker is working on a big feature 'foo', on a separate branch. He asks you for help with a particular fragment of code, calling a library which you happen to know well. You fetch, you checkout 'foo'. This creates a local branch 'foo'. You fix the problem, push and you delete this local branch, because you won't work on this anymore and you don't want to track the progress until it's finished and merged. The proposed patch would simply break this use case. Now one could argue that this is unnecessary, and it should be simplified so that your local branches == remote branches and there's only one remote. Ok, but you lose features this way.
You want to only simplify the UI? Fine, but how would this simplified UI behave, when there's 2 remotes, local non-tracking branches and untracked branches in each remote? 'Unknown error, please call the admin'?Why doesn't it have a simple "undo" so you could experiment without risk of losing all your work?
Of course it has, locally you can just reset --hard. Reverting pushed commits cannot be reduced to simple 'undo', because someone else could commit something on top of that, and now what?
99% of those horrible people using Git as a black box probably don't want distributed version control in the first place, as they have no need for it
This is possible. But git being distributed solved many other problems (like server failure), and did it first. Subversion was the most common competitor, and TFS is too tied to MS ecosystem to be considered for non-windows projects. So people settled for the best universal solution, which was the right decision. Mind you, even MS uses Git now for their development.
-
@sebastian-galczynski said in Software disenchantment:
Of course it has, locally you can just reset --hard.
Right; such an intuitive command.
@sebastian-galczynski said in Software disenchantment:
Reverting pushed commits cannot be reduced to simple 'undo', because someone else could commit something on top of that, and now what?
You can make a reverse commit from it now, so I don't see why that's such a burden exactly.
But here's the real point: any action you can do in the UI should be undo-able. If it were, people would feel comfortable playing with the UI without fear of deleting all their shit and they'd learn it much quicker.
This was a standard feature in GUIs from 1984, but I guess it's too much to ask from a open source-y developer in 2007 whose primary driving motto appears to be "FUCK USERS! FUCK YOU!"
@sebastian-galczynski said in Software disenchantment:
This is possible.
Almost certainly true, from my experience. But sure, "possible", why not.
@sebastian-galczynski said in Software disenchantment:
But git being distributed solved many other problems (like server failure), and did it first.
Has server failure ever been cited as a problem with, say, TFS or Subversion? Have you ever heard of a Subversion server going down constantly? Seriously?
@sebastian-galczynski said in Software disenchantment:
Subversion was the most common competitor,
And it's servers, just constantly going down all the time! Man. You couldn't get anything done with those damned unreliable Subversion servers!
@sebastian-galczynski said in Software disenchantment:
So people settled for the best universal solution,
No they didn't.
First of all, TFS is a better product all around, and even the only reason you can come up with to not use it is: "MICROSOFT IS THE EBIL SPELL IT WITH A DOLLAR SIGN ME HATE MICROSOFT OPEN SOURCE ROX!!!" which is not a real reason. Remember when TFS server adopted the Git protocol, it took years of patches to get Git to the same level that TFS was at a decade ago. YEARS of patches.
Secondly, even if the best solution was distributed version control (which it is not), there are distributed version control systems that are far better-designed than Git.
Thirdly, Git's really shitty. It's not the best anything. It's pretty close to the worst of any category you can fit it in.
@sebastian-galczynski said in Software disenchantment:
Mind you, even MS uses Git now for their development.
Yeah it took them YEARS to make Git almost as good as their previous SCM software; what a glowing recommendation.
-
-
@Gribnit FALSE!
-
@sebastian-galczynski said in Software disenchantment:
@Tsaukpaetra It still makes sense. Git is easy to use once you understand its data model. Some posts in this thread reveal serious misunderstandings, like @Gąska trying to make 'git branch --delete' delete remote branches automatically on next push. I don't know how this particular patch works (now you can't push a deleted local branch), but if it replaces the present meaning of 'git branch --delete' it would effectively force you to track locally every branch you ever touched until it's deleted from upstream, which is wasteful and wtfish. You can't abstract inherent complexity away.
My take-away is that people whining about Git (like the one lone windows user in my team constantly 777ing random text files) try to use it as a black box without understanding what happens, which is probably impossible given the problem being solved (distributed version control). Those who get it, usually have no problems, unless there's a massive merge conflict, but that would cause problems with any system imaginable short of some god-like AI.
Yes let's understand every single facet of how the tool works. I don't need to know Java's garbage collection strategy, I just need to know that it happens. If I understood what the fuck a redirected bicycle whatchermabucket was, I'd be writing my own.
-
Yes let's understand every single facet of how the tool works.
Not every, but some fundametal aspects - yes. There are some things which you can successfully abstract away, and some that you can't. Relational database behind an ORM is the most obvious example of the latter, but Git data model seems similar. You can make some 'simplified' interface, but every time a person not understanding what's behind starts using it, they will fuck everything up.
I don't need to know Java's garbage collection strategy, I just need to know that it happens.
Exactly. But you need to know what objects and references are, because it's the fundamental thing the GC operates on. In case of Git the fundamental thing is the graph. You can't simplify it to a tree, or a straight line of commits. It's a directed acyclic graph.
It reminds me of the countless disasters, when a junior gets his hands on Django ORM, or Doctrine or something like that. 'I don't want to do anything with this scary SQL' he thinks, and creates some abomination like 600 db queries to display a table on the main page. The data is relational, these are not objects in memory, you can't hack something up and leave the rest to 'magic'. That doesn't mean the ORM is useless - it greatly speeds up writing queries and data mapping. But you still need to know what's behind to use it correctly.
-
@sebastian-galczynski said in Software disenchantment:
[git] did it first
No.
But the alternatives that did it first were (and might still be) quite expensive. And tangled up with businesses run by assholes of calibre to make Linus Torvalds look moderate and civil to all.
-
@pie_flavor said in Software disenchantment:
I don't need to know Java's garbage collection strategy,
You do if you're tuning it for performance, since that depends on knowing what's going on (and what happens in a particular app; GC tuning is a very application-specific activity).
-
@sebastian-galczynski said in Software disenchantment:
Yes let's understand every single facet of how the tool works.
Not every, but some fundametal aspects - yes. There are some things which you can successfully abstract away, and some that you can't.
Every single Git's competitor successfully abstracted away the fact server's branches might not necessarily correspond to local branches.
-
@sebastian-galczynski said in Software disenchantment:
You can make some 'simplified' interface, but every time a person not understanding what's behind starts using it, they will fuck everything up.
I see people doing that quite frequently by using one of JetBrains's IDEs. They hide a bit too much (IMO) and as a result the potential for getting a disaster is magnified. By contrast, Eclipse hides less (if you can find the right view window) and so causes less trouble.
(Neither of these are part of blakey's tool ecosystem, but I've insufficient experience the Visual Studio system to comment.)
-
@Gąska said in Software disenchantment:
Every single Git's competitor successfully abstracted away the fact server's branches might not necessarily correspond to local branches.
That works… if you make some simplifying assumptions (such as “there's just one upstream I care about”) but there's a limit to what you can abstract away without being awkward in other ways. For some use cases, that's an acceptable tradeoff; e.g., if you're specialising to supporting a small strongly-cooperating group of developers where you basically don't mind seeing everyone else's work, you don't need nearly so much separation of the ideas of local and remote branches.
-
@sebastian-galczynski said in Software disenchantment:
Relational database behind an ORM is the most obvious example of the latter
There's a reason why people hate ORMs. There's a reason why they're considered by many as the worst way to deal with databases.
You can make some 'simplified' interface, but every time a person not understanding what's behind starts using it, they will fuck everything up.
People who don't understand what's behind a filesystem don't seem to fuck up filesystems very often. People who don't understand what's behind TCP connection don't seem to fuck up networking very often. People who don't understand what's behind TFS don't seem to fuck up TFS very often. Git and ORM are clearly special in this regard.
I don't need to know Java's garbage collection strategy, I just need to know that it happens.
Exactly. But you need to know what objects and references are, because it's the fundamental thing the GC operates on.
To be honest, I don't even need to be aware of GC at all. I need to know about objects and references because I deal with objects and references directly in my code - because my code's purpose is to manipulate objects and references. I don't need to manipulate GC. Likewise, in version control system, all I care about is branches and commits, and merges. Who cares about graphs and other internals? I just want to commit and merge code, and create and delete branches.
In case of Git the fundamental thing is the graph. You can't simplify it to a tree, or a straight line of commits. It's a directed acyclic graph.
It reminds me of the countless disasters, when a junior gets his hands on Django ORM, or Doctrine or something like that. 'I don't want to do anything with this scary SQL' he thinks, and creates some abomination like 600 db queries to display a table on the main page. The data is relational, these are not objects in memory, you can't hack something up and leave the rest to 'magic'. That doesn't mean the ORM is useless - it greatly speeds up writing queries and data mapping. But you still need to know what's behind to use it correctly.
-
@dkf said in Software disenchantment:
@Gąska said in Software disenchantment:
Every single Git's competitor successfully abstracted away the fact server's branches might not necessarily correspond to local branches.
That works… if you make some simplifying assumptions (such as “there's just one upstream I care about”) but there's a limit to what you can abstract away without being awkward in other ways. For some use cases, that's an acceptable tradeoff; e.g., if you're specialising to supporting a small strongly-cooperating group of developers where you basically don't mind seeing everyone else's work, you don't need nearly so much separation of the ideas of local and remote branches.
I can't even imagine a situation where you'd want to share a repository with someone but not the branches in it. At least 99.9999% of development work all around the world involves strongly cooperating groups of developers where no one minds anyone else seeing any of their work, whether it's corporate environment or open-source.
-
@Gąska said in Software disenchantment:
Likewise, in version control system, all I care about is branches and commits, and merges. Who cares about graphs and other internals?
The graph is just how the commits relate to one another. It's not even internals. Internals would be sth like whether it's implemented with a matrix or an adjacency list, or some kind of pointers, and this would be trurly unimportant to the user.
-
@sebastian-galczynski if by graph you mean the fact that commits can have many children and either one or two parents, yes, this is important to know. Everything else is internals.
-
-
@dkf that's cherry picking.
-
@sebastian-galczynski said in Software disenchantment:
Not every, but some fundametal aspects - yes.
FundaMETAL! Put up the HORNS MAN!
https://www.youtube.com/watch?v=CD-E-LDc384
@sebastian-galczynski said in Software disenchantment:
There are some things which you can successfully abstract away, and some that you can't.
Maybe they could have, maybe they couldn't have. Maybe they couldn't, but a more competent development team could have, and they could have hired or consulted this more competent development team.
Most likely they didn't even fucking try.
@sebastian-galczynski said in Software disenchantment:
You can make some 'simplified' interface, but every time a person not understanding what's behind starts using it, they will fuck everything up.
Yah; just like every time I use Context-Aware Fill in Photoshop I fuck up the image.
OH WAIT I DON'T. Nobody does. For two reasons:
- The Photoshop team has successfully abstracted the algorithm away so it's not "leaky".
- Photoshop has a fucking Undo command! So even if I did use Context-Aware Fill in a bad spot, I can just Undo it and try again.
@sebastian-galczynski said in Software disenchantment:
In case of Git the fundamental thing is the graph.
If you're Nerdy McProgrammerDork maybe. That's not what the user of the software gives a shit about.
@sebastian-galczynski said in Software disenchantment:
You can't simplify it to a tree, or a straight line of commits. It's a directed acyclic graph.
Could they have at least drawn it graphically? In this tool made long after every computer on Earth has access to bitmapped graphics? It's almost as if the word "graph" implies it could be displayed as... a graph...ic? Huh!
They. Didn't. Even. Fucking. Try.
@sebastian-galczynski said in Software disenchantment:
That doesn't mean the ORM is useless - it greatly speeds up writing queries and data mapping. But you still need to know what's behind to use it correctly.
Did it ever occur to you that that just might mean the ORM software/library is also shitty and incomplete? I mean I'm constantly griping about Entity Framework's shortcomings because I foolishly tied my wagon to it, but I don't say "the whole concept of ORM is bad!" I say "Entity Framework is bad!"
Software doesn't have to be shitty. It could be good. Sounds like you've just given up on computers ever being any good at all. Your viewpoint is depressing.
-
@sebastian-galczynski said in Software disenchantment:
You want to only simplify the UI? Fine, but how would this simplified UI behave, when there's 2 remotes, local non-tracking branches and untracked branches in each remote?
Git already knows if a branch is tracked, untracked or local. They really made 0 effort on making it's commands intuitive for an end user.
-
@Gąska said in Software disenchantment:
There's a reason why people hate ORMs. There's a reason why they're considered by many as the worst way to deal with databases.
I've never heard of that. Why are they the worst way to deal with databases? As long as you pick a good one, like Diesel, I don't know what could be bad about it.
-
@pie_flavor because the relational paradigm and the objective paradigm are fundamentally different, and any attempts to shove data model of one paradigm into the other is bound to have performance that's suboptimal at best and outright abhorrent at worst, and also sacrifice most or all of the benefits of either paradigm, or both paradigms. I'd link some articles about this, but I feel particularly lazy today, and it's easy to google up.
-
@Gąska have you ever used Diesel? If you join two tables, you get back tuple of the first table's record type and an Option of the second table's record type. Seems pretty relational to me.
-
@pie_flavor but is it objective? Can you have a variable that represents a particular entity instance across many tables, and can (one way or the other) access or alter the instance's properties, and have those changes automatically replicated in database (instantly or at commit)? Because without that, it can't really be called Object-Relational Mapping.
-
@Gąska Yes, why wouldn't you? All result structs have methods to update the DB with their modified fields.
-
@Gąska said in Software disenchantment:
@pie_flavor but is it objective? Can you have a variable that represents a particular entity instance across many tables, and can (one way or the other) access or alter the instance's properties, and have those changes automatically replicated in database (instantly or at commit)? Because without that, it can't really be called Object-Relational Mapping.
Hibernate can do stuff like that. Well, I have no doubt that we could come up with some convoluted
data model that it could not handle.I like Hibernate a lot. It even has a sql-like query language (HQL). That said, I still drop to native sql for a variety of things, where either it's easier to do things in bulk or when the query is complex enough that HQL doesn't cut it.
Like any tool, effective use requires understanding its limitations. Statements like yours seem overly dogmatic at the expense of cutting your nose off to spite your face.
-
@pie_flavor then tell me - how well does Diesel fare when you completely forget about the R in ORM and treat them like ordinary objects - pass them around, copy them, sort them, conditionally modify one property in some objects in a collection based on their another property? Will the resulting DB calls be even close to the idiomatic SQL?
-
@blakeyrat said in Software disenchantment:
Could they have at least drawn it graphically?
Yes, and they did. Git comes with gitk, and there are at least five other visualization tools on every platform.
@blakeyrat said in Software disenchantment:
but I don't say "the whole concept of ORM is bad!" I say "Entity Framework is bad!"
I don't say 'the concept of ORM is bad' either. I only say one needs to know that there's a relational database behind your object-oriented interface.
Otherwise you end up with N+1 queries to display N records, instead of a join, and/or hundreds of useless rows instead of a count(). In my experience, developers have serious problems with these things, partly because ORMs are sold as a 'you don't need to know SQL' solution. And they really work like that, only horribly inefficiently, because no program can predict that you will do something requiring a join, or an aggregate function, 100 lines of code later after you already fetched the data.
-
@Gąska said in Software disenchantment:
Will the resulting DB calls be even close to the idiomatic SQL?
What else would they look like?
-
@sebastian-galczynski said in Software disenchantment:
@blakeyrat said in Software disenchantment:
but I don't say "the whole concept of ORM is bad!" I say "Entity Framework is bad!"
I don't say 'the concept of ORM is bad' either. I only say one needs to know that there's a relational database behind your object-oriented interface.
Otherwise you end up with N+1 queries to display N records, instead of a join, and/or hundreds of useless rows instead of a count(). In my experience, developers have serious problems with these things, partly because ORMs are sold as a 'you don't need to know SQL' solution. And they really work like that, only horribly inefficiently, because no program can predict that you will do something requiring a join, or an aggregate function, 100 lines of code later after you already fetched the data.Whereas I say that this is the very reason why the entire concept of ORM is bad. What you see as a necessary knowledge, I see as a problem.
-
@sebastian-galczynski said in Software disenchantment:
Not every, but some fundametal aspects - yes. There are some things which you can successfully abstract away, and some that you can't.
The problem you maybe have trouble grasping is that good software understands the problem first, and then provides tools that solve the problem. So the abstractions good software provides are rooted in the problem domain, and the implementation is tasked with bridging the gap between the problem domain and the underlying model that solves the problem.
Shit software puts the underlying model as the interface. I don't want to direct cyclones, I want to keep my code in order so I have a history of changes and can organize my work with my colleagues. Your interface should say nothing about how they solve the problem, it should just understand the tasks I want to do, and provide an interface that does it. If there's one right way to go about doing what I want to do, and a wrong way to do it that will destroy my code, the interface should not even let me get near the wrong way.
This is like editing programs that refer to the different windows as "buffers". They could have called them "drafts" for example, which would be an abstraction rooted in the problem domain: I'm writing things, and I have a temporary version I'm still editing. Instead they called them buffers because that's how they're implemented in code, and they have no idea how to write good interfaces.
-
@Gąska said in Software disenchantment:
@pie_flavor then tell me - how well does Diesel fare when you completely forget about the R in ORM and treat them like ordinary objects - pass them around, copy them, sort them, conditionally modify one property in some objects in a collection based on their another property? Will the resulting DB calls be even close to the idiomatic SQL?
Eeh. Now you're getting close to 'mutating stuff out from under you', which should absolutely never be possible in Rust. They don't have built-in triggers, if that's what you're asking. The trait which has those commit methods isn't capable of storing state, and you still define the struct.
-
@pie_flavor I think you misunderstand my fundamental question - can I treat Diesel's ORM objects as any ordinary Rust object without severe performance penalties related to uncontrollable growth of DB queries needed to complete the operations I've performed on the objects?
-
@Kian said in Software disenchantment:
Shit software puts the underlying model as the interface.
Yes/No. There's a cost to all these layers, sometimes a huge cost, and hiding it all can lead to vast amounts of pointless work for no real gain. Imagine a web service (either SOAP or REST/JSON) that you've wrapped in a client library so that it appears to be a standard collection type of your language (a “list” hereon). That's a nice abstraction, don't need to show all that complex network activity to users who don't care about it. Except… you find that users are mostly using the library to find out how many items there are in the list, usually just to see if the number of items is zero when it could also be many millions, and don't actually want to know what the items are most of the time. They're moving millions of bytes over the network to discover a trivial boolean fact (or at worst a 32-bit integer's worth), and that's before you start thinking about the cost of the server side of the query. Adding in a way of satisfying the query more directly will be exposing a more complex interface at the network-level API, but will greatly benefit the overall application. [That particular gem is from one of my colleagues. This sort of shit happens for real.]
It's a deep truth that adding more layers of hiding of details will solve all problems… except for all the myriad problems it actively causes.
-
@Gąska said in Software disenchantment:
@pie_flavor I think you misunderstand my fundamental question - can I treat Diesel's ORM objects as any ordinary Rust object without severe performance penalties related to uncontrollable growth of DB queries needed to complete the operations I've performed on the objects?
Yes. Rust has no property stuff. Modify the struct however you want; any DB commit made to it will rely solely on the current state of the struct and not on operations that have been done to it to put it in that way.
-
@pie_flavor if modifying the object doesn't change the data in DB, it's not ORM.
-
@Gąska Of course it does! You just have to commit it first, via
.update(&db_conn).
-
@pie_flavor I feel we're going in circles here.
Let me ask you this way: what exactly is the difference between working with ORM (Diesel or something else) and working with DB directly? What benefit does ORM bring, and what are associated costs? If we took idiomatic OOP code that does CRUD stuff on a memory-mapped file, and replaced the data objects with ORM objects without changing any of the logic of how objects are accessed and modified, is it possible to easily fall in some performance traps related to unnecessary amount of DB reads (not writes - just reads)?
-
@Gąska said in Software disenchantment:
@pie_flavor I feel we're going in circles here.
Let me ask you this way: what exactly is the difference between working with ORM (Diesel or something else) and working with DB directly?
Working with the DB, you write raw SQL and receive raw results which you must manually parse into the desired data structures. ORM automates 99.999% of this, and provides facilities for the other .001% that let you integrate your own automation into this process.
What benefit does ORM bring, and what are associated costs?
The benefit is not doing anything the raw way and having the complexity handled by something else. This is akin to the explanation of why C is better than assembly.
If we took idiomatic OOP code that does CRUD stuff on a memory-mapped file, and replaced the data objects with ORM objects without changing any of the logic of how objects are accessed and modified, is it possible to easily fall in some performance traps related to unnecessary amount of DB reads (not writes - just reads)?
Not that I can tell. There are several ways of building the query, and all are explicitly query operations and not invoked accidentally. The part of the struct that handles database access is entirely separate from the struct definition itself - it's a derived trait. The only perf trap I can think of for ORM layers similar to Diesel is the instantiation of structs, but it's Rust so structs are free.
-
@Gąska said in Software disenchantment:
is it possible to easily fall in some performance traps related to unnecessary amount of DB reads (not writes - just reads)?
Do you think that such traps make ORM worthless? You can fall into similar traps with direct DB access. Or anything else. This really smells of cargo cult / blub.
