Quote from AntC on July 9, 2025, 10:24 am

Hmm. I suspect 'Empirical Investigation's are largely an exercise in confirming prejudices. Early in my programming career I got told RPG is intuitive. (Must be some sense of "intuitive" I wasn't previously aware of.)

I don't find Java to be cryptic. (It's TECO that started the 'indistinguishable from line noise' meme.) I do find Java so verbose that the program's logic gets smothered with administrivia. Haskell was refreshing in comparison. What attracted me was it got the balance about right in the scale of elegant -> terse -> cryptic. (At least when I encountered it around 2010. These days that's not so true.)

a field name needs to have the same datatype whatever record it is in

You'll find there's at least one TTM-aligned environment takes that approach -- for attributes appearing in a given schema. It seems not unreasonable that SNo 'means' the same thing everywhere, so is the same type. (I hate schemas that have an id in every table, and a name in many tables -- even though they might be same-length Strings, a Supplier Name is not comparable to a Product Name to a Customer Name.)

Why you'd restrict a field name to only one record type has never made sense. There's a kind of historical explanation in that Haskell was at first very timid about anything polymorphic/that is, that was spread across many (record) types. But the explanation is not a justification nor motivation. Haskell/functional programming goes in bigly for partial application. You might have a routine that goes through a database uplifting a qty field by 5%. If you don't know whether that's Int or Float or Money or what, neither do you know what record type(s) it applies to, the program that calls the routine is very hard to typecheck statically.

 they didn't come up with an alternative syntax when the . was taken

I think the history was (I wasn't there at the time/neither were design decisions closely documented)

• . as function compose arrived first. [**]
• . like all operators was allowed to be written tightfix: qty+1; round.double
• Then a module/namespace system arrived, using qualified Module.Sub.foo.
• That was thought not to be too awkward, because (sub)Module names must begin upper-case; components lower.
• Already there were corner cases: Just.double (where Just builds a data item so is kinda a function) clashes with dot-qualified, so can't be written tightfix, instead Just . double; whereas tightfix double.Just is accepted.
• There were other uses of . as not operator: most obviously as decimal point with tightfix digit both sides 3.14e0; forall a. a -> Maybe a is the fully-spelled-out type signature for Just. You can tightfix or space-surround the . as you choose.
• That would have been the point to say . is not just an 'ordinary' operator, can never be written titghtfix qua operator. (If you want to write compose tightfix, define some other glyph as compose.)
• That nettle wasn't grasped, so there grew up an idiom of building higher-order functions as player.position.xcoord, treated as a conceptual unit/qualified name.
• [**] It could have been worse: Standard ML uses lower-case o for compose, because it looks like the math symbol. But that's an alpha/can't be an operator in Haskell except by special pleading; and anyway can't be written tightfix between other alpha names roundodouble.

 

Quote from Erwin on July 7, 2025, 7:49 pm

... prevent the language from embracing the RM in full.

In this case the RM is nowhere near: we want the flavour of OOP struct.component. We'd get better conceptual alignment with the RM as an unintended side-effect.