premium-concern
Joined 10 years ago
Joined 10 years ago
See the Opioid epidemic that is still taking lives in the US for more than 20 years. Imagine what an economic benefit it would be for the populace if all those average middle-class Jane and John Does wouldn't have had their life shattered by addiction and instead would be holding down a steady job paying taxes.
Or imagine how much cheaper it would be if the US' reckless abuse of antibiotics in both humans and livestock wouldn't cause such a rise of multi-resistant strains of diseases.
Maybe the public could help them substantially lower the costs by not allowing to advertise prescription drugs to laypeople?
Agree with the GP. There is some massive Stockholm syndrome going on here.
Some countries have well-functioning health care systems since the 18XX, not just since the feel-good story of "Murica is subsidizing other countries because we are such a great nation" became a thing.
Working health care is not rocket science, but it looks like everything that doesn't fit the American narrative of exceptionalism is conveniently ignored these days.
Also, only a few of the newer concurrent Java collections disallow nulls. All the classes commonly used allow null, as well as the collection interfaces themself.
Java had the chance to address this with Optional, but they got the implementation of the null handling completely wrong. Now they are stuck with it, which caused an obscene amount of complexity in the new generics spec to work around it.
Which Map are you talking about? I don't see the method that returns nulls for missing values.
> Kotlin has only single way.
... with the nice side-effect of being unable to tell whether the key didn't exist or if it was null. That's the single worst approach one can take.
val str: Function[String, String] = s => if (s.length > 3) s else null
val num: Function[String, Integer] = s => if (s == null) -1 else s.length
With Optional, you receive different results depending on whether you call map twice, or combine the functions first: scala> Optional.of("Foo").map[String](str).map[Integer](num)
res12: java.util.Optional[Integer] = Optional.empty
scala> Optional.of("Foo").map[Integer](str.andThen(num))
res15: java.util.Optional[Integer] = Optional[-1]
This is incorrect and violates the functor law.Optional is not a functor, in fact it violates the functor laws quite blatantly.
This problem was coined by Paul Graham as the "blub paradox":
you can only notice inferior languages, abstractions and
paradigms to what you currently know, but you can't easily
notice superior ones, unless you make an effort to learn more.Kotlin marketing != reality, it seems.
There is a large gap between those and the way Scala _just works_ across platforms.
The huge difference is that you can depend on libraries and have them "just work" regardless of whether they are implemented identical on each platform, or need specific variations to implement the expected features.
Neither JS/Node nor Java/GWT have that.
A language limited to a level of advanced beginners is not necessarily bad, though.