The previous poster is right that the commerce clause (amongst others) have been twisted incomprehsnibly and while there’s a benefit, it’s begging to be overturned (and in a ‘realist’ sense, they should be). The answer then is for an amendment to provide the (expected) additional powers to the federal government.
And then we end up in the same situation where there's some new thing that should probably be regulated at the federal level but can't be since it's not explicitly listed in the constitution.
Imagine one day we invent portable teleporters. They would immediately be used for crime once they are available on the market although there would certainly be plenty of legal uses. That sounds like something the federal government should regulate, yes? You simply can't leave that up to the states because everyone is going to have a different standard for who can own one such that all you would need to do is travel to the least regulated state, buy a teleporter, and teleport back home. Having 50 different laws saying who can and can't own one would simply not be feasible based on how easy people can travel across the country. The federal government would need to establish regulations but only if the constitution says they can. Congress in 2024 would not have any notion that those could exist and would likely not explicitly give the federal government the power to regular them.
That’s by design. It’s a feature of US constitutional history, not a bug. You might not like the feature, but it was hotly debated in the 1790s and state rights were agreed upon. Abuse the constitution and we’ll imperil ourselves in other ways
>And then we end up in the same situation where there's some new thing that should probably be regulated at the federal level but can't be since it's not explicitly listed in the constitution.
Which is sort of the point of the structure of the US government. A government of a United collection of States, whose power is derived not from holy writ or mandate but from the people of those states granting powers to that government. If they don't grant the power, the government can't do it.
>You simply can't leave that up to the states because everyone is going to have a different standard for who can own one such that all you would need to do is travel to the least regulated state, buy a teleporter, and teleport back home. Having 50 different laws saying who can and can't own one would simply not be feasible based on how easy people can travel across the country.
And yet we do this all the time. Cars and their ownership are regulated on a per-state level, marijuana (ironically because the federal government has overstepped too far and the states and their people fought back) is legal or not in various forms on a per state level (and this as I note, despite being federally illegal). Guns, knives and indeed pepper spray are similarly regulated on a state by state basis. As are radar detectors. So much of people's day to day lives are regulated at the state levels and it works plenty fine most of the time. This need for everything to be uniform across the country is tempting, but like all things in life is full of trade offs. One shouldn't have to cast their memory too far back in time to imagine what it might be like for a federal administration run amok to have absolute authority over too many things.
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.
Another option is to promote commuter electric motorcycles, e.g. something like the Ryvid Anthem which has a removable battery you can take inside and charge. With a range of 80 miles it's definitely a commuter motorcycle, but it's top speed of 75 MPH definitely allows you to hop on the freeway as part of your commute.
The best part? It costs less than a typical used ICE car, so it's very budget friendly. And it has virtually no maintenance.
I'm not against public transit but it's a significant investment and towns like mine have spent the past 40 years failing to make it happen and unlike an e-bike an electric motorcycle can fully utilize all existing roadways.
I think it's time to start re-thinking transportation.
Main issue with electric motorcycles is that it still doesn't solve the safety issue of motorcycles, especially at freeway speeds.
At least e-bikes are locked at 25kph/mph. And can be folded into public transportation.
* Currently the predominant category of motorcycle riders are young males who ride like idiots (i.e. they are their own biggest cause of their own accidents)
* People driving 2 ton vehicles with their heads completely up their posteriors while driving. Fortunately those people are generally easy to spot and deal with.
If anything, more motorcycle riding will make the roads safer because you actually have to pay attention to what you're doing while riding. You can't shave, put on your makeup, or read text messages while riding. You actually have to pay attention! Also, motorcycle-on-motorcycle crashes are extremely rare outside of the context of group rides.
My biggest concern with e-bikes is people treat them like bicycles. I see people cruising around my neighborhood going 35 MPH on an e-bike without any safety gear on outside of maybe a bicycle helmet. The motorcycle safety culture of ATGATT isn't even on the radar of the e-bikers. Not to mention they don't seem to know the strategies of lane position, how to make yourself visible to others, how to swerve and brake quickly - which are all standard fare for motorcycle riders.
So let's keep driving gasoline cars? Or are you suggesting that we can just wave a magic wand and change how people use transportation? What you want takes decades. In the meantime, the world is getting hotter.
> 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.
Well when you take into account GST, income tax their employees pay, corporate tax, payroll tax, import&export duties (and every business up and down the supply chain has the exact same tax burden), there is not a lot left over for the business or the employees.
The reason businesses exist is for creating profitable returns on capital investments. W/o profit, you simply do not have jobs in the first place.
No, it’s just that globalization means that laborers in wealthy countries who expect a high standard of living are indirectly competing against laborers in poor countries who expect a relatively lower standard of living. It’s just competition and expectations.
"Sorry could you repeat that? Someone in the next town over clicked their pen and resulting change in gravity due to the ink tube offset by 1cm drowned out your signal."
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.
> 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.
I kinda agree with your first remark. I once acted just as you described as my rule of thumb. But after sometime I found out that deciding if a validation is bound to the operation or not and if the cost (IO) of doing it first hand is worth or not isn't black and white as we want, they all have different tonalities of gray.
As for the second, this anti-corruption layer is dealing with validating the format of the data (typical deserialization problems such as missing properties and invalid types) or the actual content?
If it's the first it should be done outside the domain, that's a transport/markup specific thing. If it's the latter that's the domain job. My problem is when you don't instantiate the actual entity (that you know it's well formed) to check its content, dealing with a bag of properties for such thing (that should be done inside the domain) is awful. The domain should deal with its entities and nothing else.
The third, from the experience I have, is a big flashy "no no". Our typical boring OO systems may not be religious as FP is with side-effects, but that doesn't mean that we shouldn't have a little strive to isolate it. Unlike with the actual operations, the instantiation of the entities may take place in a myriad of places. When you mix this with IO side-effects as latency you contribute to create a little monster that you have to peek and poke to find out what's going on.
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.
> 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.
Agreed. That's a type/format problem. But if, for whatever reason, the domain should process social security numbers that starts with 9 differently that should not be outside of the domain by all means. That is your business rule, you should "trap it" in the domain.
> where correctness is at a premium
The correctness of both are the same. The programming effort and the performance between those differ, but it's never a correctness trade-off.
---
But instead of arguing back and forth, let me give you a problem that I had to deal with before:
Suppose that to have an entity with a state X there must already exist in the system an entity with state Y. Also, to have an entity with state Y there must already exist in the system an entity with state X.
How do you solve this deadlock "the chicken or the egg" problem if you never allow invalid entities to exist?
If you do allow invalid entities it's pretty simple: you instantiate both and handles both, together, to the domain.
> 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.
Navicat the Premium[1] edition includes all the databases. But to your point, you still have to pay separately for each operating system, and paying $599 for a single platform is expensive.
That being said, I've tried a dozen SQL utilities and the only one that is fast and responsive for large tables is Navicat. The other utils such as RazorSQL, SQLMaestro, Firefox XUL plugins, NET LINQPad, etc are memory hogs and very slow for browsing tables with 100,000+ rows. I haven't tried JetBrains yet but the 3 others that were written in Java and used JDBC were very slow so I wouldn't be surprised if DataGrip is slower than Navicat.
If one is mainly using SQL frontend tools to help with syntax completion to speed up typing in commands (ALTER TABLE, SELECT INNER JOIN, etc), any of those utilities will work fine. But if you happen to need the tool to provide a responsive "Excel-like datagrid" for browsing big tables, my experience has found that Navicat is unmatched.
2)If you move it to the state-level how does that simplify the statutes?