The Linux command line sucks
-
@remi said in The Linux command line sucks:
@thecpuwizard Is that serious, or a joke?
Largely serious... though "S"tudy rather than a simple "R"ead is surely appropriate it that context.
-
@thecpuwizard said in The Linux command line sucks:
@remi said in The Linux command line sucks:
@thecpuwizard Is that serious, or a joke?
Largely serious... though "S"tudy rather than a simple "R"ead is surely appropriate it that context.
OK then, show me how I'd get to
teefrom "I want to run a command and see its output on the command line at the same time that I write it to a file."
-
@remi said in The Linux command line sucks:
OK then, show me how I'd get to tee
Depends on the version of Linux/Unix....
In most cases it would be by turning the page after studying tail ...
However for BSD (and some derivatives) you would read about talk after tail but before tee...
-
@pleegwat said in The Linux command line sucks:
@remi I'd point you to
apropos, but probably the first search string I'd think of isapropos copy, which returns 570 results, not includingtee.apropos duplicateworks, but who'd think of that?Exactly. If you know the right keywords, you'll eventually find what you want. But there are many different ways to describe an action, and only a few of those work.
The best way to find the name of such a command is not any of the help systems of the command line itself, but good ol' Google (which will likely point out to a SO page, nowadays).
Also, all that is assuming in the first place that you are confident that there is a command to do that. If you just want to do something and imagine in your mind a way to do it, and somehow manage to break it into individual tasks, what are the chances that there are commands to do these individual tasks?
-
@thecpuwizard So you're saying, read a few hundreds of pages about esoteric commands, and remember all of them, before using it.
Let me amend my initial statement: the biggest conceptual issue I have with any command line is morons who want you to learn everything before typing a single thing.
-
the biggest conceptual issue I have with ... is morons who want you to learn everything before typing a single thing.
The opposite can be equally true...
My biggest issue is with people who think that should just start typing without a good bit of education first, and then a period of time working under the guidance of someone with more expertise [yes, I am a strong advocate of apprenticeships!].
-
@remi said in The Linux command line sucks:
@pleegwat said in The Linux command line sucks:
@remi I'd point you to
apropos, but probably the first search string I'd think of isapropos copy, which returns 570 results, not includingtee.apropos duplicateworks, but who'd think of that?Exactly. If you know the right keywords, you'll eventually find what you want. But there are many different ways to describe an action, and only a few of those work.
The best way to find the name of such a command is not any of the help systems of the command line itself, but good ol' Google (which will likely point out to a SO page, nowadays).
Also, all that is assuming in the first place that you are confident that there is a command to do that. If you just want to do something and imagine in your mind a way to do it, and somehow manage to break it into individual tasks, what are the chances that there are commands to do these individual tasks?
You might actually get furthest with
info coreutils, but info is horrible in usability.
-
@thecpuwizard There is "a good bit of education", and there is "learning all commands that exist". Plus, remember we are talking about a tool that is destined to be used to do various little tasks on the side of your main one. It's not a programming language that you're spending all your day using, it's something that you switch to in the middle of another task to get a tidbit of information, to fix an issue with something etc.
Back to my DIY analogy (not a car one, for a change), it's fully justifiable to say that people should have training and/or some form of mentorship before letting them loose with, I don't know, a table saw or some other specialized power tool. It's not, however, justifiable to require a "good bit of education" before letting them use a basic toolbox. Not that they won't make mistake, but simply that it is entirely unrealistic to expect that people who just want to pound on a nail will listen to any training on screwdrivers and pliers and whatnot.
-
@pleegwat Again, exactly. There are ways, yes, but they are all either worse than the initial problem, or require more or less already knowing the solution.
The only help that works relatively well for command line is Google.
-
@remi said in The Linux command line sucks:
Back to my DIY analogy (not a car one, for a change), it's fully justifiable to say that people should have training and/or some form of mentorship before letting them loose with, I don't know, a table saw or some other specialized power tool. It's not, however, justifiable to require a "good bit of education" before letting them use a basic toolbox.
In my DIY-ing I often use google and watch videos to figure out how to do something. Just like I do for topics in computing, CLI or otherwise.
-
@thecpuwizard said in The Linux command line sucks:
Largely serious... though "S"tudy rather than a simple "R"ead is surely appropriate it that context.
I know someone who explains boardgames rules in a similar way: by pretty much telling you all the rules to the whole game, when you’ve never played it before. This just doesn’t work, because by the time he’s halfway (or less) through you usually only remember broad outlines of what’s gone before. Far better to just be told what the general idea is and how to start the game, then learn the rules as you go, if and when they become relevant.
Same with CLI: if know what you want to do, you should have a way of finding out how to go about it, rather than learning everything before you get to do anything. Unfortunately, that tends to mean describing your problem to Google. (
manis only useful if you already know what the command is called and need a reminder of how to use it, in my experience.)
-
@gurth said in The Linux command line sucks:
by pretty much telling you all the rules to the whole game, when you’ve never played it before
Back in the day, I was a big player of Avalon Hill and related War Games. Not unusual for the rules to be upwards of 20 pages, occasionally over 50! You really did need to know the majority of the rules "internalized" in order to even setup the pieces (which could number in the hundreds) to start play.
Sometimes a couple of weeks [afternoons after school], just reading, and quizzing each other before ever attempting to set up the game for actual play.
People today (statistically) want instant (or nearly so) gratification instead of investing.
-
@thecpuwizard said in The Linux command line sucks:
Back in the day, I was a big player of Avalon Hill and related War Games. Not unusual for the rules to be upwards of 20 pages, occasionally over 50! You really did need to know the majority of the rules "internalized" in order to even setup the pieces (which could number in the hundreds) to start play.
My main hobby is roleplaying games, so I consider 20 to 50 pages to be a very short rulebook :) But the point is that trying to learn all the rules (whether for a game or a UI) to a level at which you can use them competently before you even get to do anything at all is pointless, because you could long ago have done the thing you wanted to do before you get that far, and will have learned all kinds of stuff you’re unlikely to need for that. Sure, it may come in handy later on, but if you have some knowledge and a good way of looking up the rest, you’ll get there sooner than if you start by getting all the theory down perfectly.
-
@sockpuppet7 Like this:
param([System.IO.FileInfo] $InputFile)Or, if you're writing it in C#,
[Parameter] public FileInfo InputFile { get; set; }Easy.
-
@bulb said in The Linux command line sucks:
It tries to DWIM, but the net result is it is write-only in a way Perl only ever dreamed of.
Examples?
-
@pie_flavor this topic is about CLI
-
@sockpuppet7 Right, the first one is how you'd write it in the CLI or as a script, and the second one is how you'd write it in C# to be used from CLI. Both result in you saying
<command name> -InputFile 'Adam''s first steps.mp4', and then PowerShell handles the parsing.
-
@pie_flavor said in The Linux command line sucks:
PowerShell handles the parsing
That is improvement over
command.comandcmd.exe, but not over Bourne Shell and derivatives, since those do handle the parsing too.The variables works better then in Bourne Shell. But note that some Bourne Shell derivatives actually fix that too. In
zsh, variables are normally not split, unless you explicitly ask for it, so you don't have to carefully quote them everywhere. Subject to configuration option, because some people need backward compati(de)bility.
-
@bulb Does it really? In
sh, fed that input, at this point do you have a filesystem object representing the location of a particular file, or do you have the literal stringAdam's first steps.mp4?
-
@pie_flavor You still have a string, because everything is a string. But it was parsed from the command line. You didn't say it interprets it as file. And it means the shell now needs to know what types of argument the command needs for which switch—which has some benefits, but makes things a lot more complex.
-
@bulb I challenge you to find an example where it would make things more complex in Powershell, where strings have implicit conversion to FileInfo and friends.
-
@pie_flavor said in The Linux command line sucks:
@bulb I challenge you to find an example where it would make things more complex in Powershell, where strings have implicit conversion to FileInfo and friends.
It is obviously more complex. Everything is a string is simple, because there is just one thing, strings.
Of course for users, most of the time, Powershell does what you mean. Except when you didn't mean it. Then it makes it harder to understand what's wrong.
-
@bb36e said in The Linux command line sucks:
they said they just copy everything over LAN when they need to share files between computers..
The only reason I use USB drives is because networking on Windows is so unreliable.
-
@bulb said in The Linux command line sucks:
@pie_flavor said in The Linux command line sucks:
@bulb I challenge you to find an example where it would make things more complex in Powershell, where strings have implicit conversion to FileInfo and friends.
It is obviously more complex. Everything is a string is simple, because there is just one thing, strings.
We have different meanings of the word
obviously.Of course for users, most of the time, Powershell does what you mean. Except when you didn't mean it. Then it makes it harder to understand what's wrong.
Please do what I said the first time, which is to find an example.
-
@pie_flavor said in The Linux command line sucks:
We have different meanings of the word obviously.
Actually, we have different meanings of the word complex.
@pie_flavor said in The Linux command line sucks:
Please do what I said the first time, which is to find an example.
That's the thing. Each and every use is more complex. And it might have fewer options and be much easier, but it is still more complex. Because the word complex is mostly totally unrelated to easy or hard. It is still related to readable though.
-
@bulb said in The Linux command line sucks:
@pie_flavor said in The Linux command line sucks:
Please do what I said the first time, which is to find an example.
That's the thing. Each and every use is more complex. And it might have fewer options and be much easier, but it is still more complex. Because the word complex is mostly totally unrelated to easy or hard. It is still related to readable though.
Please do what I said the first time, which is to find an example.
-
@pie_flavor Here, have an example:
<command name> -InputFile 'Adam''s first steps.mp4'
-
@thecpuwizard said in The Linux command line sucks:
@gurth said in The Linux command line sucks:
by pretty much telling you all the rules to the whole game, when you’ve never played it before
Back in the day, I was a big player of Avalon Hill and related War Games. Not unusual for the rules to be upwards of 20 pages, occasionally over 50! You really did need to know the majority of the rules "internalized" in order to even setup the pieces (which could number in the hundreds) to start play.
That's a very good example (and I remember some of those, and spending hours reading arcane details of how to check the moral of a unit without having the slightest idea yet what the unit was...), in that they were indeed basically unplayable until you had mastered all rules, and as a result they were almost un-played. Compare and contrast with more recent games, which almost always start with some overview, or simplified rules, that allow you to first grok the overall game mechanics before diving into the details, and that are much, much more playable. Basically, those old games might have been good games (although many of them were not... too much useless bookkeeping focussing on how rather than on what...), but the rules were, generally speaking, very poorly written.
People today (statistically) want instant (or nearly so) gratification instead of investing.
Ah, the good ol' times... kids these days, and uphill both ways, and get off your lawn. Your @boomzilla is showing. Come back when you've got real arguments.
-
@gurth said in The Linux command line sucks:
Far better to just be told what the general idea is and how to start the game, then learn the rules as you go, if and when they become relevant.
Which means losing horribly to someone already knowing the rules, plus making a ton of errors in next games, because some rules never 'became relevant' in the first play. Not to mention that the first game will drag forever, being interrupted constantly by explaining some random things that come into play atm.
This is just catering to sloppy players with goldfish attention spans.
-
@mrl said in The Linux command line sucks:
@gurth said in The Linux command line sucks:
Far better to just be told what the general idea is and how to start the game, then learn the rules as you go, if and when they become relevant.
Which means losing horribly to someone already knowing the rules, plus making a ton of errors in next games, because some rules never 'became relevant' in the first play. Not to mention that the first game will drag forever, being interrupted constantly by explaining some random things that come into play atm.
This is just catering to sloppy players with goldfish attention spans.
You're probably going to lose horribly to someone who is a lot more experienced in the game than you anyway. And any experienced player teaching a game to a newbie will explain the mistakes, unless they're a complete asshole (and if they don't, they're not really teaching the game).
-
@khudzlin said in The Linux command line sucks:
You're probably going to lose horribly to someone who is a lot more experienced in the game than you anyway.
If you never played the game, then every player will be a lot more experienced, theoretically, I guess. In reality it's rarely the case. Typical board game is played 3-4 times before it's replaced by something else. So encountering very experienced players is improbable.
Plus new players, having a fresh look at the game, can do surprising things and win. I've seen it many times.
And any experienced player teaching a game to a newbie will explain the mistakes, unless they're a complete asshole (and if they don't, they're not really teaching the game).
You can explain mistakes when rules are known. Playing 'learn as we go' is just a chaotic mess of unrelated bits of information, there's no explaining, just constant surprises. "Oh, you can't do that because of a rule I'll now explain", "Oh, that's a bad move, because endgame rules are different than you imagine, I'll explain later", "I generally don't recommend investing in this that early. Why? Too much explaining, you'll see", "Ha! Got you off guard here. Yes, of course I can do that, you didn't know?".
I don't get why people think this is a good idea.
-
@remi said in The Linux command line sucks:
Your @boomzilla is showing. Come back when you've got real arguments.
My arguments are the best arguments. They're great. Everyone tells me that they're the best arguments.
-
@bulb No part of that is complex. User inputs a string, command receives a file object. Nobody has to handle parsing or ambiguity. So everyone's happy. Give an example where the complexity makes it difficult.
-
@mrl said in The Linux command line sucks:
Playing 'learn as we go' is just a chaotic mess of unrelated bits of information, there's no explaining, just constant surprises.
There is telling all the rules without any logical order and hierarchy, and there is not telling any rule at all beforehand and explaining as the game progresses, and both are equally bad, in different ways (one makes it very difficult to actually start playing the game, the other makes it very easy to start playing but very difficult to play it right, which often makes it impossible to enjoy it).
And then there are rulebooks (or explanations) done by people who actually know how to teach something, and that know how to not focus on all tiny details at start, or maybe how to make rules into nested sets of rules that can be taught one at a time (for example in a wargame, start with a scenario with few special units and no reinforcements so you don't have to learn those parts) etc. Some video games manage to do that very well, and more and more board game do it as well.
It's not an issue of explaining everything or nothing, it's an issue of proper teaching vs. dumping unstructured information. Exactly like any lecture in school, the quality of the teacher is not related to how many details he does or does not give, but how these details are organised.
-
@mrl said in The Linux command line sucks:
Typical board game is played 3-4 times before it's replaced by something else.
That was most certainly not true for these games (with the groups that I played with). Typically took at least 10 plays of the game (where the more complex games had play times upwards of 20-30 hours!) do even have a good grasp of detailed effective strategy. Of course many of the early attempts aborted after just a few moves (sometimes just 1 or 2, but that could still be hours)...
@remi said in The Linux command line sucks:
for example in a wargame, start with a scenario with few special units
Start with placing approximately 150 individual pieces per player according to a set of rotation rules.....
-
@thecpuwizard If your idea of fun is spending more time laying out game pieces and then starting again because you forgot about rule 42.2.5.a.4.C after the first move, rather than actually playing the game, well, go ahead. But don't expect other people to follow you, or complain when they go play something where they can actually hope to, you know, play.
Also, many of those games actually had overly complex rules that focussed too much on trying to mimic whatever aspect of reality they care with, rather than finding a system that produces similar outcomes, but is much simpler to handle. More recent games are much better at abstracting things through clever mechanisms, so that you can spend your play time thinking about strategy, not micro-managing the effect of desert sand on the wheels of your armoured vehicle.
-
@remi said in The Linux command line sucks:
If your idea of fun
Yes, it very much depends on one's idea of fun! [doesn't everything in life?]
For a majority of the games, the rough outcome (i.e. who would win) was pretty much determined before ever setting up the game.
At the same time, analyzing "what might have happened if ...." was a key component of the enjoyment that many of us got.
-
@pie_flavor said in The Linux command line sucks:
@bulb No part of that is complex. User inputs a string, command receives a file object. Nobody has to handle parsing or ambiguity. So everyone's happy. Give an example where the complexity makes it difficult.
It does not make it difficult. Until it makes it buggy. When user inputs a string, but the command should receive a file object, then something in between needs to know what the command expects and convert it appropriately. And that is complex—there is additional knowledge the components need to have between them. When it's correct, it's all great. There are two problems:
- sooner or later somebody will get it wrong and then it'll be much harder to understand what's going on and
- many tool authors will simply neglect the extra work that it needs from them, because other shells don't, so you'll have to do it yourself and then it's no longer easier.
Bourne Shell is simpler, because it is just all just lists of strings. The shell does not need to know anything. And the command still does not do any parsing—remember, it receives a list of strings—and there is no ambiguity—the command receives each filename as separate string. The shell does the parsing, but it does it in the powershell case too. The advantage of powershell is that it does not need to do parsing in each pipeline step. But again at cost of complexity in the command definition.
That does not make Bourne Shell easier. Because the commands are a mess and a mess is hard. That's completely orthogonal to complexity.
-
@remi said in The Linux command line sucks:
There is telling all the rules without any logical order and hierarchy, and there is not telling any rule at all beforehand and explaining as the game progresses, and both are equally bad, in different ways (one makes it very difficult to actually start playing the game, the other makes it very easy to start playing but very difficult to play it right, which often makes it impossible to enjoy it).
From my experience, 'learn as we go' is always a terrible mess, which makes the game longer than explaining rules + actual game, and makes it impossible for newcomers to play well.
It's a good way of playing for sloppy players who don't care for playing properly and/or can't listen to explanations for longer than 30 seconds, because they loose interest. Oh, and also for people who 'just enjoy playing' and don't care about winning or playing well. I don't play with those kinds of people.And then there are rulebooks (or explanations) done by people who actually know how to teach something, and that know how to not focus on all tiny details at start, or maybe how to make rules into nested sets of rules that can be taught one at a time (for example in a wargame, start with a scenario with few special units and no reinforcements so you don't have to learn those parts) etc. Some video games manage to do that very well, and more and more board game do it as well.
Yeah, good rulebooks are rare. Best I ever seen is one for Dominant Species. It's just flawless, everything is explained in correct order, grouped by subject and gameflow mechanics, there's a lot of examples, it's easy to search, etc.
Second place is probably Gloomhaven. It's 47 pages long, but using it one may explain everything to a new player in one hour.It's not an issue of explaining everything or nothing, it's an issue of proper teaching vs. dumping unstructured information. Exactly like any lecture in school, the quality of the teacher is not related to how many details he does or does not give, but how these details are organised.
My way of explaining is
- General concepts, game objective, setting
- Era/Round/turn order and mechanics
- Specific steps/aspects of the game, shown on examples with game elements
- Non obvious quirks/tricks/traps plus some strategy advice
- Endgame
@thecpuwizard said in The Linux command line sucks:
@mrl said in The Linux command line sucks:
Typical board game is played 3-4 times before it's replaced by something else.
That was most certainly not true for these games (with the groups that I played with). Typically took at least 10 plays of the game (where the more complex games had play times upwards of 20-30 hours!) do even have a good grasp of detailed effective strategy. Of course many of the early attempts aborted after just a few moves (sometimes just 1 or 2, but that could still be hours)...
It seems like we're talking about different kinds of games. Longest game I played was Twilight Empire 3, which lasts 10-13 hours and we don't play it anymore, specifically because of its length.
My typical game session nowadays is about 6 hours long, which is one slowly played game or two if we choose something quick.
-
@mrl said in The Linux command line sucks:
Which means losing horribly to someone already knowing the rules
It’s been my experience that people who’ve never played a game before often do pretty or even very well the first time, then suck horribly the second because then they think they know how to play it :)
Though this observation isn’t exactly applicable to CLI, where the reverse is to be more likely the case.
-
@gurth said in The Linux command line sucks:
It’s been my experience that people who’ve never played a game before often do pretty or even very well the first time, then suck horribly the second because then they think they know how to play it :)
Though this observation isn’t exactly applicable to CLI, where the reverse is to be more likely the case.
This suddenly reminded me of this classic WTF:
The Sorcerer's Apprentice
I don't need The Sorcerer's help, Rod Taylor scoffed to himself, I've watched him debug time and time again; it doesn't look that hard! In those days, debugging mainframe applications was not a trivial task. There were no such things as error logs, trace listeners, or any of those other luxuries...
-
@bulb said in The Linux command line sucks:
It does not make it difficult. Until it makes it buggy. When user inputs a string, but the command should receive a file object, then something in between needs to know what the command expects and convert it appropriately. And that is complex—there is additional knowledge the components need to have between them. When it's correct, it's all great. There are two problems:
- sooner or later somebody will get it wrong and then it'll be much harder to understand what's going on and
- many tool authors will simply neglect the extra work that it needs from them, because other shells don't, so you'll have to do it yourself and then it's no longer easier.
Bourne Shell is simpler, because it is just all just lists of strings. The shell does not need to know anything. And the command still does not do any parsing—remember, it receives a list of strings—and there is no ambiguity—the command receives each filename as separate string. The shell does the parsing, but it does it in the powershell case too. The advantage of powershell is that it does not need to do parsing in each pipeline step. But again at cost of complexity in the command definition.
That does not make Bourne Shell easier. Because the commands are a mess and a mess is hard. That's completely orthogonal to complexity.
Here, have a
-
The thing I find odd is that for not much more complexity, you could do something like have a REPL that can call C functions on shared libraries instead of a shell that calls executables, and that would give you some basic type safety, multiple entry points into a "program" with different parameters for each representing different things it can do, parameter assistance and such. With just the C headers you could even have library defined data types you use as parameters instead of stringly typed data. The REPL could handle the marshalling and serialization and problems like that. No need to use C specifically in the REPL, of course, a saner language could be used. It's just that calling C functions in a shared library is no more difficult, conceptually, than calling a program. Simpler, since the parameters are available and you can understand what they do without looking at the body most of the time.
So something kind of like what TempleOS does, if I understood the small bit of crazy I glimpsed. You would think that with C and UNIX being made together, that would have occurred to them.
-
@bulb said in The Linux command line sucks:
It does not make it difficult. Until it makes it buggy. When user inputs a string, but the command should receive a file object, then something in between needs to know what the command expects and convert it appropriately. And that is complex—there is additional knowledge the components need to have between them. When it's correct, it's all great. There are two problems:
sooner or later somebody will get it wrong and then it'll be much harder to understand what's going on and
many tool authors will simply neglect the extra work that it needs from them, because other shells don't, so you'll have to do it yourself and then it's no longer easier.Either we have different meanings of the word 'example', or you're trolling.
-
@kian said in The Linux command line sucks:
The thing I find odd is that for not much more complexity, you could do something like have a REPL that can call C functions on shared libraries instead of a shell that calls executables, and that would give you some basic type safety, multiple entry points into a "program" with different parameters for each representing different things it can do, parameter assistance and such. With just the C headers you could even have library defined data types you use as parameters instead of stringly typed data. The REPL could handle the marshalling and serialization and problems like that. No need to use C specifically in the REPL, of course, a saner language could be used. It's just that calling C functions in a shared library is no more difficult, conceptually, than calling a program. Simpler, since the parameters are available and you can understand what they do without looking at the body most of the time.
So something kind of like what TempleOS does, if I understood the small bit of crazy I glimpsed. You would think that with C and UNIX being made together, that would have occurred to them.
Again, you can use PowerShell today:
How to reference .NET assemblies using PowerShell
I am a C# .NET developer/architect and understand that it uses objects (.NET objects) and not just streams/text. I would like to be able to use PowerShell to call methods on my .NET (C# library)
> [Reflection.Assembly]::LoadFile("c:\temp\MyMathLib.dll") > [MyMathLib.Methods]::Sum(10, 2) > $mathInstance = new-object MyMathLib.Methods > $mathInstance.Product(10, 2)If you enter this with PSReadline or in the ISE you should even have method name completion.
-
@kian said in The Linux command line sucks:
you could do something like have a REPL that can call C functions on shared libraries instead of a shell that calls executables
Yes, that would make sense.
With the right code, you can automatically turn any human interface into a computer interface, and vice-versa (you can call API endpoints from a human interface, or send programmed inputs to any human interface).
However the result won't be a good interface, because human and computer interfaces have completely different design requirements (a topic which we've talked about in other threads).
UNIX was, as far as I understand, built with the idea that you would chain different processes with pipes to create a "pipeline" that would process your data. So processes were the basic "building blocks" of programs, making them more of a computer interface than a human interface, with the command line being more like the equivalent of that C REPL would be today (not that they cared much about the difference in that time since all users were programmers). Ironically, this has pretty much been abandoned and now we use those "building blocks" directly.
-
@jbert said in The Linux command line sucks:
Again, you can use PowerShell today:
But you then have to deal with the fun that comes with integrating two libraries with slightly incompatible object models.
-
@dkf Well, you always have to do that. Be it from the shell massaging the text output from one program into the format another expects or if you have typed data dealing with slightly different types that to a human represent the same thing.
-
@dkf said in The Linux command line sucks:
incompatible object models
"incompatible" as in "unable to exist in the same process" has been very rare in my experience (i.e. once in over a decade of solid work).
-
@thecpuwizard said in The Linux command line sucks:
"incompatible" as in "unable to exist in the same process" has been very rare in my experience (i.e. once in over a decade of solid work).
That's rare. What's common is that DLL #1 wants this object model (that it provides the model classes for) and DLL #2 wants that object model (that it also provides model classes for). Each is happy to interoperate with anything that uses its own model, but want to use a different model? Fuck you.
