willtim

> it's not the underlying query language,

SQL and it's implementations do not support nested relations. The parent is suggesting that e.g. nested relations would enable better ORM solutions.

The "expression problem" from Wikipedia (quoting Phil Wadler):

"The expression problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)."

With a sufficiently expressive language, the expression problem can be solved, sometimes in multiple ways. However, the solutions often involve boilerplate, trickery or advanced type system features. A proposed solution to the expression problem may be impractical, but that is subjective and really a separate discussion.

I guess you could view the problem as a sort of lens with which to evaluate a language. E.g. Can this language solve the expression problem and what does the best solution look like?

This paper on "Object Algebras": https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf

is a great example of using ideas from functional programming and category theory to improve on the visitor pattern, such that the expresson problem can be solved.

The value of such mathematics is that it enables us to formalise some of these patterns and generalise them.

And Acorn (fruit of the oak tree), Tangerine, Blackberry and of course the Raspberry Pi.

I am very impressed with the recent changes happening to Java, all of which seem very carefully thought out and planned, keep up the good work!

> Therefore the real advantage of Loom user-mode threads and co-routines is syntactical programming convenience. That's the real innovation in Loom!

It's an interesting alternative to Async-Await / Haskell Monads / F# workflows for sure; and a better fit for Java. But I think some credit is also due for languages like C#, F# and Haskell for providing some healthy competition and prior art in this area.

> You can't eliminate the complexity; only move it,

Yes and by using null-in-every type for your messaging, now you've pushed the problem out of your app and published it to the world.

> Pretending it doesn't exist would cause more trouble in the real world than letting it be

I don't agree at all with this point. RDBMS types for example are non-nullable by default. Protobufs, XML and many other exchange formats also have optional types but not null added to every type. If you want better interoperability with programming languages, I think it would be better to go after e.g. IEE754 support.

A huge improvement over JSON, but you still implement Tony Hoare's billion dollar mistake! There also appear to be no schemas / static types or sum types (the dual to records)? A schema would allow to you to overload the string literal, rather than require all those prefixes.

A data-exchange format is essentially developing a mini-language. Even if we prohibit abstraction, we still want rich static types and the ability to define new types (algebraic types, nominal types). Taking inspiration from programming language theory, will hopefully help avoid a result like Google Protobufs, which is awkward, ad-hoc and non-compositional.

You do raise a very important point. At my organisation, Apache Avro was selected by the Java Devs due to the "cross-platform" marketing. However, they found out after it was too late, that the C/C++ implementations were too buggy/incomplete to effectively interoperate with the Java versions.

I don't like many of the syntax choices either (e.g. the function return type syntax borrows from, but is not consistent with ML/Haskell). However, the language and tooling is already a huge improvement over C and there is already a significant community and lots of momentum. I wouldn't let a few syntactic warts put me off what could be a major improvement in the standard of systems programming.

That Amazon, Facebook, Apple, Microsoft and other tech giants have become so big, is because competition is not always possible and free-markets do not regulate themselves. How can anyone compete with Amazon in its present form with hundreds of giant distribution centres worldwide? How can I create a competitor to Facebook and get even one person interested, if the other one billion are still on Facebook? How can I produce a competitor for the iPhone and get millions of apps ported?

I'm not convinced the premiums paid (taxes paid by corporations) match the risk and payouts given, it's only been 12 years since the last hundreds of billion dollar bailout. But yes, capitalism alone does not work.

I think it's fair. Unix has a lot of legacy baggage. It's largely terminal-based with three character folder names and two character commands, a monolithic kernel, the C programming language. In contrast, Acorn's ARX was fully graphical, used a microkernel and was written in Modula 2+/3. It sounds like the hardware wasn't quite ready for it though.

> It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller.

If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it. I do not understand your point.

> So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language

I guess you mean structured data types here? But you have missed my point completely about side-effects, it is side-effects (coupling via back-channels) that prevent composition, in general, in an OO language. OO languages also typically have an obsession with nominal types that can impede reuse.

> The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language.

You appear to be suggesting that languages/tools don't matter? Why not aspire towards languages that encourage safe composition and re-usable software? Your argument reduces down to "good motorcyclists don't need helmets".

If languages adopted structural typing, rather than nominal as the default, then it would be much easier to align the types (e.g. projection/renaming of columns). Most FP languages have a limited form of structural typing with tuples.

It has to be pure functional programming to get the full benefits of compositionality. Most mainstream "functional programming" is not necessarily pure and side-effects are not controlled/tracked. Analogous to how "mostly secure" is not secure, "mostly functional" does not get the full benefits.

Pure functional programming is complex, one has to compose effectful functions differently to pure functions. But the pieces do really fit like Lego bricks, especially when the same mathematical abstractions are used consistently. The Haskell community has been extremely effective at creating such consistency, by promoting various abstractions using category theory as a guide. The object-oriented community is not so different in this regard with their promotion of "patterns".

I've been writing Haskell professionally for 8 years. The problems with Haskell are the tooling, language stability, the learning curve and the difficulty of reasoning about performance, especially space usage. But composition and re-use works.

Developers spend most of their time reading other peoples code, so yes, one does have to learn the less sensible alternatives, if you choose this tool. It's called historical baggage for a reason.

Google are not much better. They supported my Pixel C for 2 years after I bought it (2017-19); and it was more expensive than a Samsung. I basically got scammed. Never again. I've given up on disposable tablets.

Yes Standard Chartered does have its own strict Haskell scripting language (Mu). But it mostly wraps C/C++ quant libraries, it's used as a alternative to Python (because Python is a bad idea at scale). GHC is used too and is what Mu was built in.

You do have a point, with Mac the choices have been made for you. I guess the most mac-like distro is probably Ubuntu. If you pick the LTS, you might even have a smoother ride than the macOS yearly updates.

> The visuals of Mac are vastly superior to any flavor of Linux I've tried.

This is subjective. I think the MacOS UI looks and acts like a toy. My Linux machine has a solarised theme (I can toggle light/dark) with minimal window borders (i3, polybar). I think it's much more tasteful than MacOS. GNOME looks better too and it's themeable, unlike MacOS. But this is all of course just my opinion.

This is anecdotal. My own anecdote is that we've had far more trouble with my wife's MacBook than my NixOS ThinkPad which just works, even after upgrades.

The Linux experience depends on the distribution, software and hardware you choose. You need to choose carefully.

You've missed off possibly the biggest advantage of ditching Intel. A perfectly usable machine without jet engine fans and a scolded lap. I don't use Mac's, but I see this as good for the industry.

Are you sure? Packages are signed for most of the mainstream distributions.

The absence of nullable references is completely orthogonal to pure FP and static typing.

Unfortunately as much as I love Linux, you are absolutely right. But I think it more of a social problem than a technical one.

Most mainstream statically typed languages use subtyping, that is why they permit equality comparisons of different (sub) types. But they should and do obey all the usual mathematical laws, associativity, transitivity etc.

The average developer spends most of her time reading other peoples code, so avoiding having to understand == is a luxury most will not have.

> That you don’t know this shows me that you don’t actually understand JS very well.

I know about the === operator, but the original one still exists, as does all the code that was (and still is) written using it that needs to be reasoned about. That you think adding a non-obvious alternative to the language magically makes the problem go away, suggests to me that you are the one lacking understanding, not me. It was also just one example of many well documented issues with the language.

> the === operator, which is what everyone uses

Since you accused me of "broadcasting without research", I'd like to see the evidence for this claim. I just looked at the HackerNews JS and there's plenty of double equals in there.