terminaljunkid

Bullshit.

Read Apple privacy policy properly. They share data with "advertising partners".

Apple sued Samsung for billions on a ridiculous patent case on rounded corners in smartphones.

Apple patented optional chaining in Swift. Although there is lot of prior art, and the thing is fucking obvious for any PL designer.

People like to shit on Google. But Apple is just more evil than Google any given day.

Common lisp was never about minimalism. It was about lisp dialects like scheme.

Mozilla particularly has really bad suit-dominant administration. Brendan Eich is here on HN. He can explain better.

I will fill in..

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.

> Types solve 2% .......

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).

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.

> The best stuff was all proprietary for decades.

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.

Apparently basic phones and feature phones demised after mangolian gangster characters used it in movies.

Apple is defending themselves against the same thing happening to them again.

There is a sweet spot and for different people, that spot lies in different places.

Having a proliferation of types is bad for everyone but highest order FP Weenies among us.

People are quick to advocate anything from functional programming / academia here. Doesn't mean it would necessarily improve life of an ordinary programmer.

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.

In Firefox / Chrome, tick "view desktop site" from three dot menu, and view in landscape mode.