Google never "sells" your data to third parties. They keep the data themselves for advertisement purpose. On the contrary, apple shares any collected data with advertisement partners. Apple fanboys don't realize this.
Apart from agressive and deceptive marketing, Apple is a shitty company that asserts patents on rounded corners of phones and optional chaining in programming languages (Swift). They are objectively more evil than Google in my book.
Apparently I am biased. I would not have been in CSE if Google didn't commoditize the market. My first encounter to programming was on an Android terminal. But that's another story.
Vastly understated in my experience. Even trivial python programs contain errors that could be prevented with a trivial type system like Go's
And performance. Not being fast enough is a bug. Consuming much more energy is a bug, in my book.
Sufficiently expressive type systems are better than dynamic typing. They prevent so many errors, especially in FP-inspired high level data transformation functions. I am saying this as a person who doesn't even like most of FP. (You can infer from my comment history).
Well, maybe. But it is hard to believe if most of those things aren't rediscovered in these decades. And IIRC that GCC took over partially because it was quite better. GCC / LLVM appear to implement every new technique in someone's PhD thesis like Diophantine equation solvers into optimization passes. I suspect it is no longer the case.
If you're saying compiler itself is slow, well the rat race among compilers is producing benchmark binaries (sadly). But given how much we have advanced, I suppose fine grained incremental compilation should be norm in every compiler.
> Turbo Pascal, too
Here I suppose you are talking about compile speeds. Well Turbo Pascal had the advantage that it was integrated with an IDE. Eclipse and IIRC visual studio can also reach those speeds using incremental / background compilation.
> We'll probably never see the source code behind any version of the k interpreter by Arthur Whitney
I have heard a about this K. What is this? Is this an array programming language like APL? I would like some pointers.
> Having portable compilers that try to heavily optimize is a mistake.
Again here there are tradeoffs. People like the comfort of portability and thus don't care about small performance increments as long as code performs reasonably well. Although I would think we can have a peephole optimizer that can optimize based on target machine upon installation.
> No one seems to know what a CPU cache is!
While this may be true for normal programmer, compiler implementers care quite a lot about caches. Especially most JIT optimizations are about cache.
> Compiling to C / LLVM IR doesn't make sense.
Sure that's a tradeoff. But that allows to implement compilers in less time and utilize most optimizations.
However I too think the progress in compilers has stalled in these years. There are native programming languages being created. But it is almost Compile to C or embracing LLVM monoculture. Appreciably Go didn't do that. And due to proliferation of scripting / JIT languages, there's not much scope for optimizing or fast compilers. In particular I am sceptical of LLVM monoculture. The compilers rat race prioritizing benchmarks above other things isn't going to end well. Moreover my gut feeling is today's compiler infrastructure is not suitable for High level languages.
> "TBH if you've developed software in the past ten years, it's unlikely you haven't been hugely affected by what the FP community has been doing."
Apart from HN / reddit bubble, not many people know about FP, and not to imply that's their fault. FP is still weird, difficult for mere mortals, and ivory tower elitism is holding some of its useful ideas back.
Well, most Portuguese students with university degree in Informatics happen to have been exposed to FP and LP during their 5 year degree (or 3 + 2 as they usually do it nowadays).
Given that most HR departments still value having a degree, that is still quite a bit of people, specially if one extrapolates to other countries that share similar attitude to universities and HR hiring practices.
Half of those things aren't even specific to FP. And I bet most people don't even use pattern matching outside HN / reddit bubble, not to say it isn't cool.
People are quick to advocate anything from functional programming / academia here. Doesn't mean it would necessarily improve life of an ordinary programmer.
Having done a big tour of functional programming ideas in the last couple of years, I've found almost none of them to be generally helpful for the ordinary programmer, except sum types, which enable the option type and result types. Though even just having the one special casing those two and not exposing sum types to the language would be most of the benefit.
TL;DR I am on Windows and Go doesn't play well with its weird filesystem. It is all Go's fault for relying on highly used server OS semantics and therefore Go's simplicity is lie.