Visually-heterogeneous syntaxes, for all of their flaws, are easier to read because it's easier for the human brain to pattern-match on distinct features than indistinct ones.

Although, I would point out that while your argument ad absurdum is generally reasonable (the fact that syntax can make the difference between a very good language and an unusable one), whitespace and malbolge also have terrible semantics that contribute to them being unusable.

As a former Lisp enthusiast (and still an enjoyer), I'd actually use my own darling as an example: Lisps have amazing semantics and are generally good languages. Their syntax is highly regular and structured and easy to parse...except that it's brain-hostile, and I'm convinced that it actively makes it harder to read and write - not just adopt, but actually use.

I like to think that I put a lot of ~~craftmanship~~ into my code, but the effort put into every single letter of a roughly fifteen-thousand-word book (to say nothing of the letter at the beginning of the chapters or the illustrations) is on another level.

This perceived inflexibility is what my comment was getting at - that for primitive type systems available back in the 80's, yes, the types significantly constrained the programs you could write. With today's type systems, however, you have far more flexibility, especially those with "Any" types that allow you to "punch a hole in the type system", so to speak.

When I tried typed Python a few years ago, I found out that, to my surprise, 99% of the code that I naturally wrote could have static types attached (or inferred) without modification because of the flexibility of Python's type system.

I also learned that types are a property of programs, more than just languages. If a program is ill-typed, then having a dynamically-typed language will not save you - it will just crash at runtime. Static types are limiting when either (1) they prevent you from writing/expressing well-typed programs because of the inexpressiveness of the type system or (2) it's burdensome to actually express the type to the compiler.

Modern languages and tools present massive advances in both of those areas. Type systems are massively more expressive, so the "false negative" area of valid programs that can't be expressed is much, much smaller. And, with type inference and more expressive types, not only do you sometimes not have to express the type in your source code at all (when it's inferred), but when you do, it's often easier.

The "Any" type is really what steals the show. I don't think that there's a lot of value in a fully statically-typed Lisp where you can't have dynamic values at all - but I think there's a lot of value in a Lisp with a Python-like type system where you start out static and can use "unknown", "any", and "object" to selectively add dynamic types when needed.

Because, being a Lisper, you probably think like me, I'll give you the idea that really convinced me that types are positive value (as opposed to "only" being small negative value): they enable you to build large, complex, and alive systems.

Types are a force-multiplier for our limited human brains. With types, you can more easily build large systems, you can more easily refactor, you can start with a live REPL and more easily transition your code into source on disk. Types help you design and build things - which is why we use Lisps, after all!

Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference in expressiveness between program semantics and type semantics (and runtime vs tooling) for much of computing. Now that types and tools are advancing, static Lisps are feasible, and I love that.

Are there any resources on learning to design simpler layout systems (like flexbox + any other important parts) without having to adjust the design to compensate for older systems (e.g. if you were to try to implement CSS).

I can't be the only one who wants a simpler layout language than CSS that's designed with two decades of hindsight to provide the maximum simplicity-expressiveness product. Are there any serious projects to engineer something like this, or has everyone given up and either embraced CSS3 (waiting for the LLVM backend) or gone back to plain text?

I'm also surprised (in a good way) that Shinmera is working on this - I've seen him a few times before on #lispgames and in the Lisp Discord, and I didn't know that he was into this kind of low-level development. I've looked at the guts of SBCL briefly and was frightened away, so kudos to him.

I wonder if SBCL (+ threading/SDL2) works on the Raspberry Pi now...

I've heard this argument before, but there's a common existence proof to the fact that it's possible: video games. People who play many different kinds of video games (RTS, MOBA, MMO, RPG) get used to making decisions as to whether to buy things many times an hour with barely any cognitive load - their brains just get used to working with smaller units of time and money.

And why shouldn't they? I found sources online that say that a YouTube video earns about $5 per 1k views, or 0.5c per view. If I have to pay half a cent to watch a video, even a short five-minute one, that's almost below the threshold of caring, and even those making median income are probably going to be constrained by the actual time that they have available to watch, rather than the cost of the videos. People will spontaneously spend $20 to go out to eat - after the initial adjustment to a micropayment system, they should have very little trouble spending 60 cents to watch YouTube for five whole hours after work, especially if the micropayment system has common-sense features such as clearly showing your wallet balance over time, how much you've recently spent, and how much longer your balance will last at your current rate of consumption.

Now, to be fair, the fact that it's possible, and that people will quickly get used to it after they spend some time with it, doesn't mean that people will be interested in trying it in the first place, and that's a much harder problem, because subscription services are more lucrative for companies. I think the only way to get micropayments off the ground would be a grassroots movement supported by a bunch of content creators making their stuff available on a micropayment platform. Otherwise, companies that move away from ads (e.g. Google) will just turn to subscription services to lock their users in.

How about we not pollute HN with low-effort, content-less, anti-intellectual, flamebait knee-jerk reactions? Let's leave those on Reddit, please.

This is massively misinformed. The majority of privacy controls exist in iOS itself completely independently of the distribution method, and many more unimplemented potentially beneficial privacy controls can also be implemented at that level. This has been true for years.

It's not enough for some people to be able to use Linux - if you want to recommend it for general use, it has to be usable for almost everyone.

https://news.ycombinator.com/item?id=39130904

https://news.ycombinator.com/item?id=39130904

This clearly invalidates your point, and supports "Linux would be either painful or more realistically a no go", because it's obviously not enough for some relatives to be able to easily use Linux - most of them need to be able to. The fact that you have more capable-than-normal relatives or more Linux-friendly-than-normal hardware is irrelevant to the fact that most people do not.

How does one learn how to (1) think in this way (which necessitates not only abstract description but multiple concrete examples) and (2) what workflows and commands are necessary to effectively implement this?

Tragedy of the commons and negative externalities. If you're applying for a ton of jobs, then lying on your resume comes with potential upsides (you could get a job that you normally wouldn't) with very little personal downside (employers don't really have a way to share which applicants falsified resume data).

Sure, doing this raises the noise level and makes it harder for people who don't lie on their resumes (tragedy of the commons), but from an individual perspective, that's a negative externality that they don't have to care about.

Funny that you say "not even remotely close" while providing zero evidence yourself, but then ask other people to present their evidence.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

There you go. There's the evidence. No goalpost-moving, please.

For evidence that Javascript can be used to build large, production-quality applications, see coldtea's comment: https://news.ycombinator.com/item?id=37568707