Thanks, but I'd rather not.
331 karma · joined February 16, 2015
Thanks, but I'd rather not.
My point was that Docker purports to solve the sandboxing and security problems.
In reality, this is something that 90% of people who use Docker don't give a shit about. For the vast majority Docker is just a nice and easy-to-use packaging format.
The sad part is that
a) Docker failed at security.
b) In trying to solve the security problem Docker ended up with a pretty crufty (from a technical point of view) packaging format.
Maybe we need to start from scratch, listen to the devs this time and build something they actually want.
Nix tries to solve this, but it isn't there just yet.
A slightly smarter .tar.gz would have solved the problem just as well.
Utter bullshit.
Chrome is dominant due to two factors:
a) Distribution deals by Google to bundle Chrome everywhere they can. (Including shady crap like 'warez' sites, illegal music, OEMs, etc.)
b) Google aggressively peddling Chrome on their properties and making them deliberately slow and buggy with other browsers.
It's not a coincidence that Gmail suddenly became slow and buggy under Firefox with their latest redesign.
Reach, penetration and target audiences is like 95% of what modern advertising does.
Modern advertising works on simple statistics rules like "people who drink Pepsi might need heartburn medicine" or "people who recently bought home appliances might want to buy another one".
These things are simple applications of the CLT. No psychology or manipulation is needed or wanted.
Advertising today is mechanical applications of the central limit theorem / law of large numbers to sociological problems.
Well, no. ML solves the classification problem, not the prediction problem.
E.g.: The "is this a cat picture" problem is effectively solved, but we _still_ can't reliably predict something as primitive as a simple binary proportion.
I don't know how contracting works, but for corporate project the rule is always "follow the money", then once you figure out the money flow, only then do the requirement gathering bit.
Doing it in the opposite order will result in tears.
Whiteboard problems absolutely do work.
The vast majority of applicants cannot code at all. And I mean that literally: they're at a loss at how to write a function that adds two numbers or counts the number of elements in a list.
Worse is that these guys can be employed as developers (even 'senior' ones!) for years and years in 'serious' enterprises.
How, you ask? By using copy-paste and cleverly navigating their enterprise processes and dodging responsibility.
Maybe this is what you mean by 'being good at working with others', but it's definitely not what I want in a software developer.
Source: I've interviewed a great deal of people for lots of positions over the years.
I guess I'm saying that one should be less emotional at this point and more cautious and rational.
Git won because it was a) unopinionated and b) powerful enough to support arbitrary workflows for any enterprise.
For the enterprise, being 'uniform and predictable' is way, way, way down lower on the list of important criteria in version control. (And in fact may even be a negative, due to the weird legacy workflows many enterprises have.)
What makes you say that? That's like expecting software engineers to understand the implications of clock synchronization in your server CPU. Sure, it'd be nice if employees had that level of dedication, but who are we kidding? That's not what they are being paid for.
> Such government effort can only be successful if it involves lots of doctors.
Well, no. Doctors aren't the ones making epidemiology science research. At best they might read a paper or two if somebody pushes them.
General practitioners are simply running off standard checklists for standard ailments. It's no different from reading a car repair manual.
And unlike car mechanics, you probably won't succeed in suing your doctor if he used the wrong checklist and got you injured by mistake.
P.S. Being a doctor in a more complex specialty is not much different, but then you're expected to read literature and keep up with current science research. It's still fundamentally checklist-based, but at least there's an expectation that the checklists are being updated.
Antibiotics should be regulated by a serious government effort, not by doctors.
Why? It's not rocket science, and it's not like this is a complex decision that you couldn't adequately make after 15 of Internet searching.
The fake mystique imparted on general practitioner doctors is a toxic force for bad in the world.
> Doctors shouldn't be prescribing antibiotics unless there is a big real need.
The doctor doesn't know if there is a "big real need", and in fact cannot.
The doctor is just running off a standard checklist for one of among 50 almost exactly alike cases during his workday.
"Classes" is a low-level thing that you'd need for implementing many language features. Including things like 'abstract data types' of the ML kind.
Good C++ style has always viewed "OOP" as something highly suspect and hacky.
(This didn't apply to "classes" in the C++ vein, which are mostly about pre/post-conditions and RAII.)
C++ without a standard C++ library is not really C++.
> No, it was because Bjarne wanted features from Simula whilst still generating fast code.
Yeah, but Simula is somewhat its own thing, before the OOP madness.
> Again, look at Qt. Look at CERN's ROOT. Java looks a lot like it does because that's how C++ code was written at the time.
Only because C++ was the only thing available at the time, so people twisted it into 'OOP', despite the fact that C++ was very a poor fit for 'OOP'.
Death and rape threads on the intertubes is just people being mean.
Deal with it, there will always be somebody who hates you. Life's tough.
Yeah, citation needed, d00d.
> with a more Pythonic input syntax
A 'more Pythonic syntax' is literally the least important requirement anybody needs in a programming language.
No way. C++ was always much more into the functional programming paradigm. (See the STL, for example.)
The connection between C++ and OOP is because OOP was the insane hype at the time when C++ was being invented. The OOP lipservice was mandatory in order to be taken seriously by the fashion-driven programming industry, but real C++ programmers always looked down on OOP and considered it a code smell and crutch.
Because the job of the OS is to manage computer hardware resources.
'JSON' and 'SQL' (whatever that means) are not hardware resources.
Next stupid article, please. This one is broken.
You know, the use-case it was originally designed for. (I read the hype for Java 1.0, I was there.)
Nobody at the time could imagine that Java would eventually become the enterprise COBOL replacement.
PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude.
C is not the bogeyman you're looking for.
The JVM is not a true VM. It's heavily coupled to the Java object model and the Java GC.