I gotta ask what in particular "problems" C# solves over Java, and I'm not talking about J2SE 1.4. Having dipped into C#, it feels like the designers resented OOP and reusable code. C# is not the new kid on the block and is almost 20 years old now.
Over that 20 years, C# has been continuously improved with language features added at a faster rate than Java. Some examples:
* properties
* LINQ
* async/await
* dynamic types
* better generics
* inferred typing - `var`
* null conditional operators
* custom iterators - `yield`
* pattern matching
Also, .net is more of a “pit of success” language — Java with all its legacy baggage requires a lot more knowledge to avoid mistakes.
so... properties that require a steeper learning curve, a system that's worse far worse than JPA+Spring Data (or you could use the hibernate in both languages - a java development), another word for var/let, I'd disagree about generics, var/let again, I wonder what rust devs would say about these null inline conditionals that require more knowledge, and... yield is actually neat if also not another non-traditional baggage thing to learn. Anyhow, I guess my take is that Rust is a better language than C# in all the ways that C# might be better than Java and more... Except that C# is a lot like Java and is the language of choice if you use Unity - so it does have a big awesome ugly library that Java does not have. Really we should feel sorry about all the Unity baggage C# devs get to deal with. Then there's Microsoft land, which has not inspired me of code quality and can't get out of VB think.
Hibernate is an ORM. LINQ is just what the name says it is language integrated query. Linq is understood by the compiler, translated into expression trees at run time and then any third party provider can translate it to the destination language. You can pass Hibernate expressions around and depending on context, they can get translated to regular IL when working with Lists, Sql when working with RDMSs or MongoQuery when working with Mongo, etc.
Maybe it's less of a C# thing, and more of a Unity thing - but I'd say that Unity has some major architectural anti-patterns - which may just be to appease the ease of a the awesomeness of a wysiwyg type game engine.
You mean the fact that methods aren't virtual by default?
As Hejlsberg explained, the problem with virtual-by-default is that every time one of your public methods calls another public method on the same object, it makes it that much more complicated to reason about your invariants. If the called method is non-virtual, then you're in full control, and you know exactly what happens. But if it can be overridden, then you need to define a contract for overriders to follow, and you can't assume that it does anything other than what's expressed in that contract (in particular, you can no longer call that method without ensuring that all class invariants hold, even if it's expensive). Furthermore, the overriders often also need to know which other methods on the class do or do not call this method.
In practice, this is so much hassle that not even the Java standard library does that. For example, given ArrayList, if you override add(), does that affect addAll()? The docs don't say. So in practice, the only things that are safe to override is what the docs say are safe to override... which is to say, exactly like "virtual", except it's not enforced by compiler. Overriding random methods often works, but is a hack not dissimilar to using Reflection to access non-public members - even if it works, you're relying on implementation details of the class.
If you believe Facebook to have violated the law in your state, you can write your Attorney General and ask them to enforce the law or explain how Facebook is not in violation of the law.
How is this not in violation of most wiretapping laws? Facebook is not the common carrier in these cases. Both parties of conversations with teens are not consenting to the wiretapping, which is not allowed in many US states. I’m not sure teenage consent is considered “consent” and the parents aren’t a party to the conversations Facebook is wiretapping. Facebook is both paying people and recording the electronic communications... So how the hell is this legal under current laws?
>How is this not in violation of most wiretapping laws?
This is, perhaps, the most apt question to take away from this. If an individual did this, even with an EULA, that would be a fast-tracked way for them to see the inside of a penitentiary in almost any country, yeah?
im sure a disclaimer is in the eula (boo).. but if it were deemed illegal, i suspect fb would just pay the fines, or more likely, be given time to come into compliance with the law..
FB isn’t the service provider, they’re intercepting and recording private conversations they aren’t a party to... where not all the parties are consenting, and sometimes the party is not of age to consent... If it’s criminal, why should they be given “time”?
i agree its not justice, but the answer is because they have power. you could download the vpn and then try to press charges. hope you have lots of money.
A 19 year old can. If he access private discussion with his 13 year old brother, indirectly the study will gather data of the kid. RGPD don’t care if you gathered data directly or inderictly, you are liable.
It's not quite that cut and dry in the UK[0], and the article mentions that parental consent was required.
But if they were operating in the UK, I'm somewhat doubtful their disclosures as reported in the article could be classed as informed consent under GDPR given the "specific protection" children are provided [1].
Has this been used in Europe, as well? If yes, can someone affected please excercise their GDPR rights and ask for information and access to personal data?
If the problem YAML is size / formatting, that's something a good IDE can simplify even more. For loading up configs that would otherwise be properties files, I have found it to be quite clean. If you think of it a domain language for configuration, YAML is great. It can be understood pretty much intuitively, and it does some things quite well. On the other hand, when it comes to exchanging data, JSON > XML > X12 EDI... EDI? Yes, it's still a thing... a terrible thing...
If a hash is salted with a domain it won't be use-able on other websites. You should additionally hash the hash on the server, and if you store the client hashes, you can update the salts on next-sign in. A better question is why clients should be sending unhashed passwords to servers in the first place.
https://medium.com/the-coming-golden-age/internet-www-securi...
This discussion is only relevant with an attacker that can break tls. A hash that such an attacker couldn't reverse might be slow on old phones so there is a tradeoff.
Also, hashed passwords shouldn't be logged either.
