To what extent writing your code in WebAssembly (eg Rust) can help with those points (eg structs in C argument). It would still run in a JS VM so I'm guessing a bit, but not to the full extent?
This article is really a reiteration of a https://wiki.c2.com/?SufficientlySmartCompiler argument. I would've sticked to a massively less appealing, but more closer to reality: "We've been lied to: JavaScript is pretty fast, but..." argument.
We tried to use it a year ago or so, because of the performance promise. We were getting random glitches every few thousand files during operations. There was no obvious pattern, so difficult to reproduce, and as far as I remember there was mentions of it in github. Hopefully they acknowledge and get over this hump, as it seems like a promising project all together.
That's interesting - I hate wasting food, I have never complained about my order (and not planning too, unless the food is spoiled I guess). If I don't like the food, I'll just never order again from the same place. I would definitely appreciate a company that offers money refund on food "no questions asked" even if I was never going to use it - it shows respect.
In a sense, yes - I believe the damaging effects of sugar and social media on the society is far greater than psychedelics might have if decriminalised.
They definitely don't deserve to be Class A in the UK and Schedule I in the US. Even more so, they shouldn't be classified as Schedule I by the United Nations.
I'm not sure about using it regularly, but people have been using these for ceremonies for centuries. I personally believe the choice should be left with an individual.
This type of empty fear mongering comment is unhelpful at best. It's a McDonalds of a comment. What's a lot of people? Why are psychedelics so special compared to anything else (sugar, Facebook, gambling). "It doesn't happen to everyone, but it's common" - what does this even mean? "Common" based on what criterion? How should our behaviour as a society change based on your comment?
As with any metaphor, technical debt has its' limits and its' traps. IMHO the biggest problem is that a comparison with lending implies that technical debt can be managed like people do with a loan. With loan you know how much of money-equivalence you take, how much you owe and how much interest you have accumulated on top.
Most of measurement - if at all possible - is much less obvious with technical debt. And inability to easily quantify it, opens up door for corruption.
Some reasons that I don't think have been covered yet:
- experienced programmers are promoted out of the tech track - it causes all sort of problems, people keep reinventing the wheel, they are forced to relearn through their own mistakes, transfer of knowledge and skills is hampered
- (probably as a consequence of the first point) people with 3 years of experience are believed to be senior programmers
- worse even - experienced programmers are promoted to non-coding roles aka architects. Over time they increasingly disconnect from the tangible artifact (code) while still hanging onto a false belief that they can function just fine by embracing it through a metaphor (diagrams, etc.) ("Simulacra and simulation"?.. but possibly I'm digressing)
Yes, yes and yes. Last time I checked human cognition and collaboration seemed to attract very little interest. I suppose this somehow falls into a slot of "Human Productivity".
For instance - instinctively I find Clojure easier to work with than Scala. How is it different for different people and why? How does the cognitive complexity scale as the program scales? Do some languages foster collaboration better? As the team scales does the subjective complexity of a program scales in some languages better as the others?
Or something even more fundamental - why do some people write a lot of comments and other don't. Is there a difference in program comprehension with different length of indentation or different formatting for that matter.
We need more insights into the psychology of programming (languages, design, comprehension, etc.). If that's not possible we should at least do more rigorous philosophy of programming.
"A Philosophy of Software Design" by John Ousterhout - a recent find and probably the best book on programme design I've ever read. Author is an experienced programmer and Computer Science professor at Stanford.
The test that never can get slower - I'm curious how they do it.. In my experience tracking performance regressions is much bigger challenge than solving performance issues.