People need efficient transport not efficient cars. Efficient cars are merely less bad, rather than good. We need more public transit and less urban sprawl so that we can reuse infrastructure efficiently.
> Jobs aren’t for financially sustaining you—they’re for financially sustaining us.
That is the crux. I feel like most businesses actually don't produce enough value to justify their own existence and therefore require below cost-of-living wages to keep them afloat.
Yeah, but they might live for another 6 months, or 18 months. They might see there kid graduate or get married or met a grandson in that time.
Also, a close family friend was given 6 months to 3 years to live when her cancer spread through her body. It's been 10 years. She is getting sicker and sicker and on chemo the whole time, but she is still managing to attend the odd family function when she is feeling up to it.
This shit isn't a game, these are peoples lives and we need to make sure they can live it even if it means a few less unicorn start ups.
Object oriented does not require state: it requires encapsulation. I incorporate as much immutability into my code as possible and I would say most of our objects never have their state changed from instantiation and I write Enterprise Java all day long.
The domain's job is to represent and encapsulate valid transformations in the domain. If it's not valid within the domain then it doesn't belong in it. If you get a well-formed XML file that has -7 as a social security number, that is not something that your domain has to deal with. It should be caught by the corruption layer. It's not a valid value for your domain. Where I work we regularily build an import domain that allows users to see all the invalid data and manually correct it before allowing it into the rest of the system. Once I have an instance of a Person object I should be able to trust that it is sane.
> The third, from the experience I have, is a big flashy "no no".
It depends; I'd say it's on a case-by-case. Doing a read can be much more acceptable than a write. It's all about trade-offs at that point, but the benefit of knowing "if I have an instance I know that it is sane" means you don't need to litter your code with guards and that pays dividends in maintenance and bugs and agility and testability and, yes, even performance. A big factor is the cost of load. I usually work on low-load (~14 concurrent users) high-importance systems (eg global pricing management) where correctness is at a premium and we usually have system resources to spare. YMMV. As I said: it depends.
> Some validation only makes sense on a specific operation. The object you constructed, due to some business rule, may be invalid to delete but valid to update for instance.
These are two different concepts I feel you are mixing up. An object may be valid, but that doesn't mean it's valid for all operations. For example there is basic validation that a file object is valid if it exists, but if you only have read access to it .append("foo") will fail on it. But it's still a valid file. Your constructor should be checking for the first kind of validity, and your methods for the second.
> What if you receive, from a webservice or something, a valid object format-wise but invalid from the business rule perspective?
That is what you need an [anti-corruption layer](http://www.markhneedham.com/blog/2009/07/07/domain-driven-de...) for. The object makes sense within that other services domain but not within yours. That domain may be closely related to yours, but it isn't you. You need a separate object for that (a simple struct ought to suffice usually). Then you act as a gatekeeper only allowing conforming objects into your system. Basically filter out the shit, and make sure if it makes it past your gate it is clean. Otherwise you might want to use the [state pattern](https://en.wikipedia.org/wiki/State_pattern) to allow for different validation rules of the same object (eg legacy accounts might not have an email address but all new ones must).
> What if there's some info in the database that would allow or not you to construct the object the way you need? You would go to the database and check the info in your constructor?
This is touchy. Sometimes, if it's important enough then yes. Sometimes you can code around it (eg having case numbers auto-generated at time of persistence). Other times you bite the bullet. Other times you rearchitect the data (storing it in memory to do the check quickly). Or as a last resort, except it as a compromise and start coding up some roll-back functionality. Aim for the ideal, and know when to step backwards towards the practical: that is the art of software development.
> EDIT2: The price is also way too much in my opinion. It basically costs as much as PHPStorm. Not sure why you would by DataGrip instead of Navicat.
Uhm for Navicat you need to buy a different license for each database and operating system you use. Where I work we use both SQL Server and MySQL and I use three different computers with different operating systems. JetBrains terms are much friendlier.
> And most mathematicians have been reluctant to invest the time necessary to understand the work because they see no clear reward: it is not obvious how the theoretical machinery that Mochizuki has invented could be used to do calculations.
I find this _deliciously_ ironic since that is the position most students have towards mathematics in general (replace "calculations" with "anything relevant in their lives").
Hmm, in your opinion do you think this would be a good technique then for digitizing paper maps? And if so, could you point in the direction of a library or textbook you'd recommend?
Is there an e-ink reader with a 8.5"x11"/A4 screen that'll display PDFs? All I want is to be able to bring all my tech ebooks with me to work and be able to look things up/brush up on things on the commute/flight etc.
2)If you move it to the state-level how does that simplify the statutes?