I think the value in art like this is that it isn’t a matter of skill but of dedication.
Should art be something that only the 1% most skilled and well trained artists can ever hope to be celebrated for?
Whilst I won’t deny that incompetent leadership and planning are involved, I think there are structural reasons for the game industry being uniquely problematic.
Games have massive cost efficiencies from scaling. Studios are incentivised to always make the biggest games they can with their budget. Games team sizes vary strongly with the project period. They can’t handle more than a small team early and can absorb almost any number of people at any skill level before release.
End result is that game development is always boom and bust. Small core teams build a game up slowly, then more and more are added until just before release when a mad scramble for anyone and everyone they can be bought borrowed or stolen to get the game released on time. Then there’s no work except for the core team on the next game.
The obvious solution is to have many games running in one studio to even out the team sizes and absorb the crunch, but that implies either studio sizes beyond anything we see currently (and no increase in per project scope) or much smaller scope for games.
I’ve seen models like they work, and be much less painful to work with for everyone involved, but it did require different market conditions to justify the alternative model, I’m not sure the entire industry could switch.
That’s not to say fixing the problem is impossible, just that the bad incentives will always be there to push back against improvements..
By that metric go back to John Barber’s 1791 patent for a gas turbine.
Brayton needed to solve actual hard core engineering problems to make the device practical, thus it wasn’t the same idea only similar. There’s little comparison as Brayton was selling commercially viable engines vs writing a paper on a much older idea.
Yeah, pretty dubious phrasing. On the other hand, "protect food heritage" is so obviously a reframing that I didn't even concider that as the whole story.
All the bits of OOP I use on a daily basis in C++ seem to have made it into rust in ways that seem pretty obvious to me.
It's true that a lot of the OOP ideas went into C++, but C++ has always been fairly agnostic to whether you actually use those features. Rust just seems to have taken that a little bit further.
The closest to an exception is inheritance, but it's been months since I've built an inheritance hierachy that wasn't just an interface that could be done with traits. When it comes up I happily use inheritance to do it and if I was writing Rust I would moan a bit and come up with an alternative design, but I'd hardly call it a big deal.
It seems like most languages built today have a thick vein of OOP in their design (discounting functional etc). You don't have to be 100% or 0%, Rust is way closer to OOP languages than it is to C.
Interfaces are part of type theory. Generics so to say.
The unique thing about OOP is objects with mutating state that communicate with one another. This is really the only part of OOP that is uniquely OOP. All other things that are "OOP" like interfaces or object.method() notation are not intrinsic to oop.
That literature is wrong. Interfaces exist outside of of oop. Saying it's oop is like saying addition is oop because you used it in your programs.
Interfaces exist in functional languages as well. You need to search for the thing that is uniquely oop. Interfaces is not it. Clearly this is an inconsistency.
If IEEE defines interfaces as oop then it is also saying functional programming is oop. This doesn't mesh with our intuition of the meaning of these two terms.
There is a differentiator that is uniquely oop and uniquely functional and that is mutation via setters vs. immutability. Functional programs must be immutable, while oop allows for mutation via setters.
Some people like to roll with the notion that oop and functional are orthogonal concepts, this is an inconsistent notion. You have to realize that mutation via setters definitively makes the two concepts parallel and opposite. Functional cannot mutate.
If the industry ever truly mathematically formalized the term oop rather then relying on crude improvised guidelines via IEEE then mutation via setters is the formal definition of oop.
Everyone nowadays gets confused because lack of proper formalism. The think if they used a method like a getter or inheritance or a class, then they did oop. When this is the case, suddenly everything looks like oop. Suddenly oop is prevalent and the dominant paradigm and used everywhere.
I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet.
Some of the initial implementation of interfaces go back to CLU ADTs, Smalltalk traits, Objective-C Protocols, Java interfaces, C++ pure virtual classes, BETA patterns, Eiffel, CLOS protocols....
> I prefer the academic truth, validated by renowned peers in the industry, presented at acknowledged conferences, to random opinions on the Internet.
You don't even know who wrote the IEEE definition and who validated it. Second this isn't academic truth. This is just some arbitrary chosen standard chosen by industry. Not academic at all.
In mathematics, the ultimate logical form of academia there is a term for "interfaces". It's called categories, and there's a entire theoretical framework behind it called "Category Theory". This theory of "interfaces" goes beyond just OOP and category theory can be used to foundation-ally describe all of mathematics and function as a sort of replacement of set theory.
Don't worship authority for authorities sake. If the IEEE declared 1+1=3 would you believe it? Instead use your own brain. Do my arguments have merit? Does the IEEE definition seem inconsistent? Does my definition make logical sense? If you can think of these things on your own merits instead of blindly following the IEEE then you'll see that the definition of OOP is just something academia hasn't really thought about deeply from a theoretical and mathematical standpoint. OOP is more like a term that comes from applied engineering with very little theoretical foundation.
I'm sure maybe you heard of haskell and category theory? Haskell is a purely functional language and it has huge connections with category theory. Basically Haskell IS the language of interfaces. It's entire type system is centered around categories or AKA "interfaces". It is the defacto language of interfaces much more-so then OOP languages like Java.
If you said haskell was OOP, people who love that language would vomit. Haskell is not OOP, but it has interfaces, so the obvious conclusion here is "interfaces" ARE not an OOP exclusive concept. It's therefore bad for a formal definitio of OOP.
So now the question is WHAT is it about OOP that makes it uniquely OOP. Or is it just a hodgepodge of random stuff and it will be forever a word that is muddy, inconsistent and poorly defined?
type classes ARE interfaces and they ARE categories. You can say the the programming methodology is influenced from OOP using this concept. But as a taxonomy the naming is improper. Categories is the most rigorously defined vocabulary for this concept. The term becomes inconistently taxonomied when coupled with OOP. It's historical baggage because Categories/Interfaces essentially were popularized by OOP.
OOP is not formally agreed upon in academia there is no consensus. So your reliance on academia here is flawed. Use your own brain rather then blindly trusting others. You know about the replication crisis right? Science is found to be wrong over 50% of the time especially in fields like psychology. Don't be blind.
The language authors agree with me. Your slides don't prove anything, it's just explaining the relationship not the origin. I'm not pulling this out of my ass. Your comment is also just fucking rude. Please stop.
Rust is not geared towards oop. But it can be bent to do that.
You should be asking the question in what way does OOP mutate state and what other programming paradigms don't? What described above is unique to the oop style.
In general when you write rust. Unless you love oop, in general the syntax isn't set up to promote you creating a graph of objects that mutate one another. Java promotes this style the most.
For rust the style the syntax promotes is movement of data through pipelines. The data can get manipulated as it moves through the pipeline.
For functional programming it's similar. You have pipelines, but nothing is being manipulated. Each segment of the pipe in this case takes an input and produces a new output without moving or changing anything.
any part of OOP that is "unique to the oop style" and not used by other programming paradigms is going to be the worst part of OOP.
OOP has been around long enough that all the good ideas have been borrowed/copied/reinterpretted/stolen many times over. Any ideas that managed to remain unique to OOP all this time must have sucked.
Naw. Youre thinking inheritance. That's not what it is. Inheritance can be used in FP. It's not uniquely OOP at all. The only thing uniquely OOP is the concept of setters. It's fundamental and isn't some side concept either. Setters are fundamental to how you program in OOP. OOP is basically a graph of objects mutating one another.
Setters are not used in any other programming paradigm. Not in FP, not in C style programming... Any style of programming that strictly is not OOP does not use setters.
>most of that complexity could have been avoided with a better language design
Are you saying that the ownership/borrowing model for memory safety was a poor choice, or that it's possible to make a language on that model that has vastly less complexity than Rust?
Because your phrasing implies the second, but I don't think I've ever heard anyone make that claim before (presumably because there's no such language lying around anywhere, so it seems hard to defend).
If the first, then I'd point out that wouldn't be a language design flaw, but rather a flawed goal (ie a goal that proved too complex to achieve) - their goal was a memory safe language that didn't rely on a GC, and the resultant design complexity is basically the best example of a way to solve for that goal so far. I'm sure there will eventually be simpler options, but I don't think you can blame designers for not having access to undiscovered techniques. That's what most anti-Rust arguements boil down to.
If you just mean you don't like the syntax, then yeah, I agree, it's a bit alien for me too, but I hardly concider that anything beyond personal taste and the difficulty of learning something new.
I meant the general syntax design, not specifically the memory model.
For example there are multiple syntaxes for adding annotations or directives to the code. Some things are written very differently compared to other languages for no apparent reasons (e.g. derive). Some keywords have different meaning in different contexts (e.g self and type). And so on...
Basically, there are some rough edges that shouldn't really be there
Out of curiousity, what solution do you think would work (assuming you accept that enforcing any sort of emissions standards is a good idea overall).
My best attempt: perhaps as long as systems to maintain emissions standards have failed, the vehicle could be made to pay a fine per X miles travelled that approximates the cost of correcting either the actual emissions of that engine or if such data is unavailable, a plausible worst case emissions of the engine. At a vague guess I could see that being $250 per 1000 miles or so (simplifying emissions to be "4x typical CO2 emissions of a van", which could be way off, and current best-case DAC costs to undo the damage ~$250 per tonne).
That's still a fairly steep fine, but at least it isn't artificially limiting the vehicle.
Living in a state with mandatory annual vehicle inspections, these are obviously the solution. You can put non-compliant parts on your car, swap them out before inspection, find a dodgy shop that will let some things slide, etc. But for the most part it significantly raises the barrier to driving around with a derelict vehicle.
Emissions should be checked with a tailpipe sensor, as they used to do before they started to lazily rely on OBD2. Then digital restrictions on the emissions computers (etc) could then be narrowly scoped to reporting the last time the firmware was flashed. And if someone is still willing to swap that module out and back every year, then just let them. They could also just burn diesel in a 55 gallon drum in their back yard.
That does seem sensible yes, I'm also not particularly interested in preventing people from doing stupid things to their cars if they're that insistent on doing them, it just hurts everyone else.
I guess the problem is how to encourage manufacturers to ensure their emissions functions remain high quality. If the _only_ feedback is customers eventually getting failed inspections and thus higher repair bills eventually, which presumably then leads to them complaining about the cost of the cars maintenance, that's a pretty weak feedback loop compared to direct punishment for producing products that fail emissions checks.
The problem is that once you punish manufacturers more directly they start installing these braindead systems in self defense, after all, if nobody can drive their cars when they're broken then they can't be punished for failing emissions checks.
I guess you could just forbid them from blocking customers at the same time as you punish them, but that's a little unsatisfying.
Maybe just require a way to detect modification or emissions override, and anyone who does that pays the fine if they fail inspection, and for anyone else the manufacturer pays. They'd presumably be begging people to install modifications so they can hand off any fines...
> Maybe just require a way to detect modification or emissions override, and anyone who does that pays the fine if they fail inspection, and for anyone else the manufacturer pays. They'd presumably be begging people to install modifications so they can hand off any fines...
For passenger vehicles (including diesel pickup trucks but not diesel semi tractors), after you buy it, if you make modifications to it, you the owner are now responsible for it. Also note that the diesel pickup truck is classified as a passenger vehicle rather than a commercial vehicle and so needs to meet the standards of a passenger vehicle.
However... where it gets interesting is when you switch to commercial and industrial equipment. In these cases, the manufacture is always responsible unless they go out of their way to lock it down.
For example, if you made a farm tractor and could adjust the software to change the fuel air mixture to optimize it for certain altitudes (farming at 5000 feet has different tuning than farming at sea level) then if it was possible for the person using it to change that... you, the manufacture are still responsible for any things with emissions. For industrial equipment, you need to lock it down to the point where the person doing it is knowingly violating warranties and regulations.
... And then you've got John Deere with its DRM on the firmware to make sure that farmers don't modify them to go racing ( https://youtu.be/hK-WO9SzVcs ) and get the company in trouble (and the EPA is less of an issue than someone modifying the settings for a combine and getting killed).
> Products claims over defective industrial machines are subject to many of the common defenses in products cases, including comparative fault of the user or a third party (CACI No. 1207A and 1207B), misuse or modification (CACI No. 1245), and more.
> These claims may also become a target for the sophisticated user defense, in which a Defendant accused of failing to warn argues they are not liable because the Plaintiff is a sophisticated user who, because of their position, training, experience, knowledge, and / or skill, knew or should have known about a product’s risk of harm (CACI No. 1244).
> Overcoming such a defense requires assessment of what a user knew or should have known at the time of an accident. More importantly, Plaintiffs’ attorneys should anticipate such a defense when bringing a products liability claim over a Defendant’s failure to warn, and explore other alternatives for proving defects based on defective design or manufacturing, if supported by the facts, and especially if a Plaintiff may qualify as a sophisticated user.
> 1. The [product] was [misused/ [or] modified] after it left [name of defendant]’s possession; and
> 2. The [misuse/ [or] modification] was so highly extraordinary that it was not reasonably foreseeable to [name of defendant], and therefore should be considered as the sole cause of [name of plaintiff]’s harm.
Can one claim that changing the fuel settings on a tractor is extraordinary that it can't be reasonably foreseen? If not, then John Deere is still responsible unless they take every possible action to prevent it from happening.
I was curious about the legal justification for your claim, so I read your main source (biren.com). It seems like you're taking what is a possible defense against a product liability claim (CACI 1245), and pulling it out of context. But rather, for that to even apply, there still has to be a fundamental design defect in the product.
So if there is a safety interlock controlled by software, which the end user then disables by replacing the software, and then someone gets hurt - even though the manufacturer could have reasonably foreseen the modification, the manufacturer still isn't liable because their (removed) safety interlock code wasn't defective in the first place.
But regardless of the current state of the law, a new law that prohibited companies from prohibiting modifications to software on devices they sell would obviously affect that. The thing your citing is California jury instructions, that are presumably a distillation of case law. So rather than even needing to be amended by a legislature, they would be implicitly adjusted with the passage of a right to repair law.
