[nauticacom]

Snippets like this:

    account deposit: 100 dollars.

are why I love Smalltalk (and its followers, e.g. Ruby). So much expressiveness, reading like a sentence. And Smalltalk even had the ingenuity to use period as a statement terminator, so it feels even more like a descriptive sentence describing the domain concept.

[nmz]

Rebol takes things further by identifying $ as a datatype.

    account/deposit $100

Nobody cares about rebol but I always bring it up in terms of expressivity.

[carapace]

Yeah, I have no idea why Rebol and Red aren't more popular. ( https://www.red-lang.org/ ) They pack such a bang for the buck it's almost embarrassing for other language/runtimes.

[fault1]

julia can do things sort of like this because it has juxtaposition = 'implicit multiplication'

julia's parser (which is written in scheme!): https://github.com/JuliaLang/julia/blob/master/src/julia-par...

[nauticacom]

Just took a quick look at Rebol and it looks interesting! I love languages that push the boundary of what they allow programs to "naturally" express

[dragonwriter]

> Rebol takes things further by identifying $ as a datatype.

Well, money! is a datatype, $ is a sigil that identifies a money! literal.

[tomcam]

Which is the better choice these days, Rebol or Red?

[ignitionmonkey]

I don't see any sentence nor expressiveness in that. It's the same structure as most method calls.

"Deposit 100 dollars in my account." is a sentence, and that's doable in most languages. It just depends on how high you want to go with it. Functions are ubiquitous and powerful:

    deposit($(100), in(my_account))

And if we remove brackets like a lot of languages (I prefer not to)...

    deposit $ 100, in my_account

Functions remove the need to tie actions to objects too. We can rely on types/interfaces.

    deposit($(100), in(the_river))

We could go further, again, depends where you want to stop. Expressiveness isn't really limited by most languages.

[layer8]

Also, reading like a sentence is not expressiveness. Expressiveness in programming languages is about abstractions, like for example macro capabilities. Reading like a sentence is merely about fluent APIs and (sometimes) syntactic sugar.

[PaulDavisThe1st]

Best to read the smalltalk as always embedded in an invisible framework that looks like this:

hey OBJECT !, I want you to ACTION with ARGUMENTS

so ... "hey account!, I want you to make a deposit with $100"

[jollybean]

I'm doubtful that 'reads like English' is 'expressiveness' because language is nuanced and imprecise.

That's not what we want in a software language.

In fact, we should not even call them 'languages'.

If by accident of history we called it 'Machine Instructions' - would anyone have ever tried to make it seem like Enligsh?

Clear, concise, unambiguous is I think what we want. Just enough overhead to keep it clear but not so little that it's ambiguous.

[JadeNB]

This can cut both ways, though—English-likeness can be bad for a language when it comes to the boundaries of what English expresses well (see https://daringfireball.net/2005/09/englishlikeness_monster). There's a reason we don't program in COBOL!

[nauticacom]

I must be the only person on the planet who likes AppleScript :)

[rzwitserloot]

> reading like a sentence.

But therein lies the problem. Let's forget about programming for a moment and talk human languages instead.

In english, you say "Cheese omelet". In dutch, you say "Kaas omelet". In french you say "Omelette du fromage".

Neither is better than the other; it's just how it is. A native english speaker who is learning both dutch and french may posit the feeling that dutch feels 'more natural' and has 'more obvious word order'. But I'm sure you'd agree that this is just based on happenstance; simply because english and dutch so happen to match. There's nothing intrinsically better about putting the cheese in front of the omelet instead of after it. Nevertheless, for a native english speaker, dutch will seem simpler... __right up until the moment you turn "native", and you no longer translate each word on its own back to english first__. Once you've hit that level, there's no difference. At all. You hear the words and your brain visualizes a cheese omelet instantaneously.

The same logic applies to programming langauges. "It reads like a sentence"? What are you on about? If I see this code:

    account.deposit(Dollar.of(100));

I know what that means, __instantly__, in the exact same fashion someone who is entirely fluent in both french and english makes absolutely no difference whatsoever between Omelette du Fromage and Cheese Omelet. Simply because I program enough javascript, java, C#, (C-esque syntax) that __THIS__ is natural to me.

Rails in particular is egregiously in violation of this ridiculous aim to make it look like english (but, fortunately, nothing so crazy as AppleScript). Rails prides itself on being able to write `5.minutes` - they monkey patch numbers to add a minutes function.

But in programmese, of any flavour, that makes very little sense. You want to create a value of type Minutes, or in some languages, you want to create a value by using a function from the namespace Minutes, and this operation that requires a parameter (the amount of minutes). Putting the param _before_ the namespace / class / type / function name / whatever your programming language uses here - is _highly exotic_ - something very very very few programming languages do. Except Rails (I'm going by memory here - I believe the minutes function on numeric types is a monkeypatch Rails adds, it's not stock Ruby). They do it, apparently (in that they call it out in their tutorials) because "5 minutes" reads like english and leave it at that - clearly insinuating that 'reads like english' is upside.

No it isn't.

And that's why "account deposit: 100 dollars." is by no means "easier to read" simply because it reads like an english sentence.

[jackblemming]

One hundred percent agree. Please stop trying to write really verbose code that looks like some weird pseudo english. Mathematicians realized having a grammar specific for mathematics was a GOOD thing NOT a drawback. Even if you have to learn a few symbols at first.

What I want to see: 5 + 3

What I don't want to see: Add the number five to the number three.

[brabel]

> Rails prides itself on being able to write `5.minutes` - they monkey patch numbers to add a minutes function.

That can be done in strongly, statically typed languages with either extension functions (Kotlin, Dart) or type classes (Rust, Haskell).

People do it because there are advantages beyond the subjective reason that it reads better (I can speak several human languages and in all of them you would say number-timeUnit - so it's not just English even if it's not completely universal). It's also easier to "look up" functions based on the type of the value, for example.

[mercurial]

> In french you say "Omelette du fromage".

No you don't, that's literally "Omelet of the cheese". You say "Omelette au fromage", which is "Omelet with cheese".

I do agree with your broader point, though.

[_dain_]

>Rails prides itself on being able to write `5.minutes` - they monkey patch numbers to add a minutes function.

In languages like Nim with Uniform Function Call Syntax this is actually completely natural and universal: f(a, b) and a.f(b) are completely equivalent in all cases. So if you have an ordinary `minutes` function that takes a number and returns a time/duration, you can write either 5.minutes or minutes(5) as the fancy takes you. No special monkeypatching required, it just works everywhere for every function and every type.

[_dain_]

>But therein lies the problem.

Exactly. This is why I dislike SQL. The relational model is great, but it was hamstrung at birth by the foolish insistence that it "read like English" so that non-programmers could write queries. Now we're stuck with a deranged syntactic mishmash.

[batman-farts]

Interestingly, a large number of the people actively developing Pharo seem to be native speakers of French and Spanish. People from Inria are the lead devs, and it’s got a lot of momentum with South American universities too. I guess they see value in it as a pedagogical tool, at least.

[nauticacom]

I definitely understand the argument that different human languages have different semantic patterns. The only non-English language I know (reading, not speaking) is classical Latin, which likes to have nouns and verbs at the opposite ends of phrases; after reading a lot, it just starts to "feel" right.

    account.deposit(Dollar.of(100))

I also know what this means, but somehow it just doesn't "feel" right. Maybe it's because all the other words are in English, so I want 100.dollars to follow English word order? But account.deposit(...) feels much better to me than deposit(into: account, ...), which is the "wrong" word order. I'm perfectly willing to accept that I just have a sense of what "feels" good to me and it's not necessarily logical or reasoned, just a general aesthetic of nouns playing in a world of data.

As an aside, I always find it funny when people use "monkey patching" in an attempt to decry giving language users expressive power. I love monkeys! I love monkey patching!

[setpatchaddress]

The derogatory and inaccurate use of “monkey patch” to describe adding methods to an open class identifies you as a Python advocate, so grains of salt applied, but:

I can’t speak for this particular Rails usage, but one of the most powerful things you can do with Ruby is build domain-specific languages without modifying the language itself. *This is a core feature of Ruby.*

The criticism you’re making is one of the Rails DSL — there’s nothing in Ruby preventing you from instead writing account.desposit(Dollar.of(100)).

Put another way: This is like people criticizing RISC-V for not having multiplication in the core ISA — they don’t seem to grasp that RISC-V is an ISA construction set. Ruby is a language construction set.

[dragonwriter]

really, it should be:

  account acceptDeposit: 100 dollars.

accounts don't deposit money, they accept deposits.

Or, for a more realistic domain model:

  ledger credit: accountNumber debit: cashHoldingsAccount amount: 100 dollars.