|
Sagacity posted:Now do the same thing with multiple versions of an application that require incompatible configuration files in the same location, or mutually incompatible system libraries. That was not a problem I ever had. If you did and docker solved it for you, then by all means, have at it.
|
# ? Feb 15, 2020 23:28 |
|
|
# ? Jun 6, 2024 12:33 |
|
Absurd Alhazred posted:Why are you making the system libraries incompatible? Why is your application only able to run with a specific set? Why throw the ABI, heck, API contract out the window? Because you need to move fast and break things? BRB, I'll just get vendor X to rewrite their software to have the same requirements as vendor Y.
|
# ? Feb 15, 2020 23:33 |
|
Thermopyle posted:BRB, I'll just get vendor X to rewrite their software to have the same requirements as vendor Y. "Lol, just lol that you demand any kind of standard from your vendors. "
|
# ? Feb 15, 2020 23:35 |
|
It definitely sounds like a better model to say "every little package and dependency on this system gets veto rights over what libraries and library versions my application gets to use" rather than "I've tested my code against this specific set of dependencies and, barring any issues with them, I'll just stick with those."Absurd Alhazred posted:"Lol, just lol that you demand any kind of standard from your vendors. " Bugs and issues in edge-case interactions between multiple pieces of third-party code? Preposterous! Why don't you just tell them to write code that doesn't have any problems?
|
# ? Feb 15, 2020 23:48 |
|
heres some guides about dependencies: - don't use the absolutelly last version of everything: some people just do exactly this - if you don't need a thing, that will create a new dependency, don't use that thing. - less dependencies is better than more dependencies has for libraries - mantain the same interface if you can. OOP exist for things like the facade pattern. If is imposible, change the mayor version of the app. 1.2.3 should not be completelly different api than 1.2.2 If people followed the above, the world would be more sane
|
# ? Feb 15, 2020 23:55 |
|
Docker seems like a complicated extension of static linking. (I'm pretty sure that's not an original observation.)
|
# ? Feb 16, 2020 00:55 |
|
Absurd Alhazred posted:Why are you making the system libraries incompatible? Why is your application only able to run with a specific set? Why throw the ABI, heck, API contract out the window? Because you need to move fast and break things?
|
# ? Feb 16, 2020 08:47 |
|
https://twitter.com/kotlin/status/1227993505332682753 The people behind the Kotlin language are actually advertising a feature where you can override constants by variables in subclasses as a good thing. For starters this breaks the Liskov substitution principle. Other than that, well, literally the only use case for this is to allow for terrible code design.
|
# ? Feb 16, 2020 09:31 |
|
It seems somewhat reasonable, since it allows a split between a const parent interface and then an internally-mutable implementation of that. You're unlikely to be bitten by this by accident, since you need to explicitly mark your constant as "this can be overridden by subclasses" in order for subclasses to use this feature.
|
# ? Feb 16, 2020 09:45 |
|
Exactly, this is similar to how you'd use interior mutability in Rust to expose a very simple immutable interface used by consumers, but you're able to modify the internal data structure. This can be useful for a LRU cache for instance. For consumers the cache is more or less a read-only Immutable getter, but the cache itself modifies itself to keep track of read timestamps.
|
# ? Feb 16, 2020 10:07 |
|
Also it doesn't break LSP. The only contract the parent class promised was "you can call .getValue() to get a string". Nothing in the parent's public API suggested that the string would be a constant.
|
# ? Feb 16, 2020 14:11 |
|
The real horror is that the language supports inheritance
|
# ? Feb 16, 2020 14:20 |
|
I've been using Kotlin for over a year now and have yet to type "open"!
|
# ? Feb 16, 2020 16:45 |
|
NihilCredo posted:Also it doesn't break LSP. I'm admittedly less than novice when it comes to kotlin, but based on my understanding of what `open val` means I'm not sure this is right. The parent's public API suggests to me that the value of that field for a given instance will not change; that's what val means, isn't it? The complaint isn't that it's not treated like a constant, but rather that it allows the value for individual instances to be mutable. I would expect open val to mean that the value is immutable for any given instance of the class, but the value for that instance may not be the value specified in the parent class, as child classes can override it. That's apparently not what it means, which is surprising. If the intent is to provide a way, as mentioned, to provide a read only interface that reflects internal mutable state, or otherwise may change across accesses for a particular instance of the class, that sounds like exactly what a nullary method provides you.
|
# ? Feb 16, 2020 18:11 |
|
Steve French posted:I'm admittedly less than novice when it comes to kotlin, but based on my understanding of what `open val` means I'm not sure this is right. The parent's public API suggests to me that the value of that field for a given instance will not change; that's what val means, isn't it? Nah, val just means "read-only". A val field or local will by necessity only ever have one value (making it equivalent to final in Java), but a val property can be any kind of getter as long as it doesn't have a setter. I don't think the JVM supports the concept of a "final property".
|
# ? Feb 16, 2020 18:28 |
|
NihilCredo posted:Nah, val just means "read-only". A val field or local will by necessity only ever have one value (making it equivalent to final in Java), but a val property can be any kind of getter as long as it doesn't have a setter. I don't think the JVM supports the concept of a "final property". Ah, okay. So in kotlin val vs var is more about the interface with the value, rather than a property of the value itself being guaranteed. As in, var means you can mutate it, and val means you cannot, but not that it can't be mutated at all. I'm coming from Scala, where it's more of a property of the value: val means it cannot be changed, ever, var can be. As a result, a nullary method (def) can be overridden with a var or val, but a val cannot be overridden with a var or vice versa. If you want a value that can be read externally but modified internally, there's just a bit more boilerplate: you define a public def backed by a private var (or any other thing, really)
|
# ? Feb 16, 2020 20:30 |
|
Absurd Alhazred posted:"Lol, just lol that you demand any kind of standard from your vendors. " How exactly do you propose that anyone enforce what other companies do?
|
# ? Feb 16, 2020 23:05 |
|
Docker is great because you can work with a wide range of technologies without having to install a bunch of supporting (sometimes incompatible) poo poo on your machine and all of your environment is basically described in code.
|
# ? Feb 16, 2020 23:08 |
|
a hot gujju bhabhi posted:Docker is great because you can work with a wide range of technologies without having to install a bunch of supporting (sometimes incompatible) poo poo on your machine and all of your environment is basically described in code. Ok, please help me here, what kind of technologies does Docker allow you to work on that you would have been otherwise unable to do so? I thought about them for about 20 seconds now and I cannot come up with an answer. I must have a very poor imagination.
|
# ? Feb 17, 2020 00:01 |
|
a hot gujju bhabhi posted:How exactly do you propose that anyone enforce what other companies do? Standards and contracts, like in any other industry.
|
# ? Feb 17, 2020 00:02 |
|
Absurd Alhazred posted:Standards and contracts, like in any other industry. Agreed, let's all standardize on one particular version of every library, and nobody is allowed to use any older or newer version. That way all the software is guaranteed to use the same version.
|
# ? Feb 17, 2020 00:17 |
|
Jabor posted:Agreed, let's all standardize on one particular version of every library, and nobody is allowed to use any older or newer version. That way all the software is guaranteed to use the same version. Yes, the only industry where any change or improvement ever happens is software. We're all still riding in Ford's cars because it's impossible to innovate without creating an ecosystem that drives people to give up and just carry their environment with them everywhere.
|
# ? Feb 17, 2020 00:23 |
|
Volguus posted:Ok, please help me here, what kind of technologies does Docker allow you to work on that you would have been otherwise unable to do so? I thought about them for about 20 seconds now and I cannot come up with an answer. I must have a very poor imagination. There is nothing that Docker enables that couldn't be done some other way. It makes certain packaging and deployment processes a lot easier and more repeatable. That's what makes it a useful tool. Absurd Alhazred posted:Yes, the only industry where any change or improvement ever happens is software. We're all still riding in Ford's cars because it's impossible to innovate without creating an ecosystem that drives people to give up and just carry their environment with them everywhere. Cars, which have safety-critical bugs that actually kill people even after legislators and regulators wrote and passed actual laws that said they couldn't have any safety-critical bugs. Bugs and integration issues happen. Containers help isolate them. They're not the perfect tool for everything, but they can be really useful!
|
# ? Feb 17, 2020 00:28 |
|
Absurd Alhazred posted:Yes, the only industry where any change or improvement ever happens is software. We're all still riding in Ford's cars because it's impossible to innovate without creating an ecosystem that drives people to give up and just carry their environment with them everywhere. Do you actually have any concrete suggestions, or are you just entirely full of platitudes?
|
# ? Feb 17, 2020 00:30 |
|
Space Gopher posted:There is nothing that Docker enables that couldn't be done some other way. So what is a hot gujju bhabhi talking about then?
|
# ? Feb 17, 2020 00:30 |
|
Containers are a response to the world as it exists. Far from "giving up," they're an interface that makes it easier to continue to derive benefit from work done in the past, even if it was not implemented in a hygienic way.
|
# ? Feb 17, 2020 00:34 |
|
Jabor posted:So you actually have any concrete suggestions, or are you just entirely full of platitudes? Implement open standards like TCP/IP, C++, OpenGL, Vulkan, OpenVX, etc, and then people can write software to them. Or have proprietary libraries with a published and documented API, and then take responsibility for bugfixes and behavioral changes, with strong backwards compatibility guarantees, like Microsoft does, or at least used to do, and how Nvidia does now. I don't have to "suggest" anything novel, web-services people need to stop focusing on accepting that all of their libraries and environments suck and start enforcing some level of competence.
|
# ? Feb 17, 2020 00:35 |
|
Absurd Alhazred posted:Implement open standards like TCP/IP, C++, OpenGL, Vulkan, OpenVX, etc, and then people can write software to them. Or have proprietary libraries with a published and documented API, and then take responsibility for bugfixes and behavioral changes, with strong backwards compatibility guarantees, like Microsoft does, or at least used to do, and how Nvidia does now. We'll just do what Microsoft used to do back in the good old days before dirty web programmers ruined everything! wait, what is this dll hell, incompatible binary libraries everywhere, this is awful if only there was some way to isolate sets of libraries and dependencies into separate instances of the same host system
|
# ? Feb 17, 2020 00:39 |
|
Absurd Alhazred posted:Standards and contracts, like in any other industry. Sure, maybe. I mean, it's not exactly impossible that my little startup could get MegaCorp, some electronics vendor in China, some OSS project, and a half dozen other entities to all agree to some hypothetical standard and sign a contract. Of course, it's way easier to just use Docker which is super simple to use, deploy, and scale. Absurd Alhazred posted:Implement open standards like TCP/IP, C++, OpenGL, Vulkan, OpenVX, etc, and then people can write software to them. Or have proprietary libraries with a published and documented API, and then take responsibility for bugfixes and behavioral changes, with strong backwards compatibility guarantees, like Microsoft does, or at least used to do, and how Nvidia does now. Those standards have little bearing on what people use Docker for. I mean, Postgres 7.5 and Postgres 9.4 both adhere to industry standards, but that doesn't mean you can have both installed on the same system at the same time. (Not sure if that's the case with those specific databases, but it's the idea that counts) Thermopyle fucked around with this message at 00:43 on Feb 17, 2020 |
# ? Feb 17, 2020 00:41 |
|
So here's an example. I have one piece of third-party software that depends on OpenCV 3.4. I have a second piece of third-party software that depends on OpenCV 4.2. I want to use both of these pieces of software as part of my complete solution, which requires some amount of isolation since they require different versions of a (dynamically-loaded) supporting library. Who in this situation, in your worldview, is the fuckup that should be taken out beyond the woodshed for causing all these compatibility problems?
|
# ? Feb 17, 2020 00:41 |
|
Jabor posted:So here's an example. Possibly the first 3rd-party vendor. Maybe you.
|
# ? Feb 17, 2020 00:46 |
|
In the meantime, there's a sprint goal that needs hitting, so
|
# ? Feb 17, 2020 00:48 |
|
Absurd Alhazred posted:Possibly the first 3rd-party vendor. Maybe you. And what exactly do you think the benefit of doing things your way is? I mean, are you familiar with how easy Docker is to implement and use? It sounds like you're advocating for grueling years of legal and technical work in order to avoid...something incommunicable.
|
# ? Feb 17, 2020 00:48 |
|
we're all missing the greater point here in that in a perfect world, computers wouldn't exist
|
# ? Feb 17, 2020 00:50 |
|
CPColin posted:In the meantime, there's a sprint goal that needs hitting, so Ah yes, you have poo poo management, the solution is to keep using an outdated binary incompatible component as a dependency of your software. It's loving 2020. If you're strongly dependent on a 3rd party library that depends on C++98 ABI (that's what breaks backwards compatibility between OpenCV 4 and 3, by the way), then the problem is you.
|
# ? Feb 17, 2020 00:51 |
|
No the solution is to use docker
|
# ? Feb 17, 2020 00:57 |
|
Yeah, and that's why we will never have flying cars, colonize the solar system, or faster than light travel. Docker is a bandaid, not a solution. Bandaid upon bandaid to stop the bleeding of past mistakes. And then add more bandaid when the blood finally gets through. Brilliant.
|
# ? Feb 17, 2020 01:02 |
|
I still don't understand what the complaint is. I mean, it costs effectively nothing to use Docker.
|
# ? Feb 17, 2020 01:05 |
|
NtotheTC posted:No the solution is to use docker Thermopyle posted:I still don't understand what the complaint is. There are externalities to not pushing library developers to actually keep up with each the latest versions. Eventually you're going to run into combinatorial explosion.
|
# ? Feb 17, 2020 01:06 |
|
|
# ? Jun 6, 2024 12:33 |
|
Volguus posted:Yeah, and that's why we will never have flying cars, colonize the solar system, or faster than light travel. Docker is a bandaid, not a solution. Bandaid upon bandaid to stop the bleeding of past mistakes. And then add more bandaid when the blood finally gets through. Obviously the solution is to abolish bandaids.
|
# ? Feb 17, 2020 01:06 |