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.
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.
One of Tcl's most popular object systems is called incr Tcl. Tcl allows some Lisp-like metaprogramming (albeit effectively all stringly-typed, and with fexpr crawling horrors -- where it's really easy to confuse metalevels -- and weird scoping rules), so incr Tcl can be, and is, implemented in Tcl.
> 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.
Don't forget F#'s units of measure! Which by the way are pretty cool, as the compiler automatically infers new units of measure for you:
> [<Measure>] type km;
> [<Measure>] type hour;
> let distance = 60.0<km>;
> let time = 0.5<hour>;
> let avgSpeed = distance / time ;;
val avgSpeed : float<km/hour> = 100.0
(And of course forbids physically illegal stuff such as adding values with different dimensions)
>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.
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.
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.
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!
I'm still not clear on whether or not you are a native English speaker, but the point being made is that the expressiveness of a programming language shouldn't be tied to the semantics of a spoken language irrespective of whether the majority of the keywords are expressed in some given language (in this case English using Latin alphabet).
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.
I first heard the term in reference to how mootools messed with prototypes of JavaScript built-ins; at that time, I had no experience with either python or ruby.
Whatever context the term may have originated with, it far outgrew those origins. I definitely don't instinctively think of python programmers snubbing ruby when I hear the term.
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:
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.