71 karma · joined August 10, 2017
So really there's no practical difference between a company of 11 people and a company of 11000 people from a management perspective.
The technological/practical concerns you'll be dealing with are totally different, of course, but as far as 'people management' stuff goes, there's little difference.
P.S. Life would be easier if you just bit the bullet and finally learned those algorithms. It ain't that hard.
That said, the assumption is that advertisers are the victims here. However, in reality ad spending is driven by huge multinational, bureaucratic and dysfunctional companies. For many of these companies the goal is simply to spend the allocated budgets, and forget about sanity and KPI-driven processes. In that sense advertisers and fraudsters are willing accomplices.
I haven't seen 'new' or 'delete' in the wild for a decade now. (Well, except for various legacy libraries or student code on Github.)
The thing is: ad tech doesn't want your personal data. Ad tech doesn't even want 'individually-targeted' ads. Advertising is applied sociology and works with statistics and its laws of large numbers.
What ad tech really wants is to assign you to broad classes of sociological groups. ('Gamer', 'parent', 'hobbyist', 'instagram user', etc.)
The insane spree of personal data collection by Google and Facebook isn't driven by advertising needs. It's a deeper and more insidious strategy for things in the future that aren't advertising-related. (I think the strategy bosses in these FAANG companies imagine a future with something like China's social credit system, except on steroids. But this is just my hunch.)
It was always a transparent ploy to make it more expensive for small-time ad network operators and give Google and Facebook yet another monopoly advantage.
And ironically, it is Google and Facebook who are the huge privacy violators, not the small ad tech companies; GDPR only serves to erode your privacy in the end.
Prolog is really a database query language. Similar to SQL or GraphQL. Prolog failed because it never got integrated into a serious enterprise data storage engine. (Most Prolog implementations are just text files and in-memory hash tables.)
> Doesn't actually parse, it's a lexer.
Good lord!
On welfare.
The fact that the candidate went on to a non-programming position confirms.
In any case, it was the strings you pulled that let the guy get promoted.
The idea is older than structured programming, older than the C programming language, older than the idea of object-orientation. It's probably even older than McCarthy's LISP.
Safe to say that if it hadn't caught on during this time, then it never will.
Oh wow, such news.
In other shocking developments: water falls from the sky when it rains, and cigarettes are addictive.
Sorry. Code is code, that's what your job entails and you can't make programming into something it isn't.
The question is the time period you're looking at.
Real estate is one of those things that don't spoil with time, so it's conceivable to have a return on investment in 500 years.
If so, the article is off the mark, the whole idea of the concept is a less car-centric life. You're supposed to commute to work by public transport and walk inside your "superblock" during leisure time.
So a random employer is allowed to control employee devices, but a parent isn't allowed to control their children's devices?
Really?
This is flat-out evil on Apple's part.
You're right, it takes a mind-boggling amount of wasted effort and negligence to turn a simple thing like corporate chat into something as bloated and broken as Slack.
Making something simple and easy is harder than just letting entropy destroy your product.
Have you ever actually been on the interviewer end of the process?
Literally over half of the candidates literally don't know how to program! They can sort of string together a Markov-chain something if you sit them down in front of an IDE and let them copy-paste stuff until syntactic errors go away, but put them at a whiteboard and they don't know where the parentheses go in a function call.
(They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.)
So-called "neural nets" are just logistic regression with a fancy name. Seems "deep learning" is just a wavelet transform with a sigmoid basis. (So, boring math stuff we already knew forever, plus marketing mumbo-jumbo.)
Junior programmers pick on whitespace formatting and variable names because that's the only kind of criticism their skill level allows.
As a guy who actually wrote "datacenter software" for over a decade: you don't speak from experience and what you said is false.
Basically, OS threads are the smallest and lightest form of concurrency currently in existence. Any userspace 'fiber' will be heavier and slower than actually spawning a pthread.
The problem is when you couple pthreads with interpreter runtimes. (Python, Lua, Ruby, etc.) These runtimes (and especially the GC engines they use!) don't play nice with OS threads, so you're forced to invent various rube-goldberg fiber-like contraptions on async primities.
The end result is slower, heavier and more brittle than any pthread-only solution, but interpreter runtimes necessarily impose overhead, you learn to deal with it.
I don't have enough eyes to roll at the cluelessness of your comment.
A great idea if you want to save the planet by having people die out from exploding (pun intended) obesity.