[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.

[Jtsummers]

Rebol itself is practically dead, no new release in a decade. It was also proprietary early on and a "weird" language (interesting, and good, but non-standard in so many ways that it was very niche). That killed its potential in the late 90s and early 00s when everyone was moving to open source scripting languages that filled the same niche, but with more conventional syntaxes and free access.

That's why it isn't more popular. In some ways it was a few years too early (to hit the zeitgeist around DSLs), but it was also a few years too late for its proprietary model.

[Tozen]

And something else that needs to be said specifically about the Red programming language. I like the full-stack concept, ease of use, cross-compiling, and the goals they are shooting for. But, the lead developers need to get it moving. Like a small fire needs to be lit under the butt, as the competition isn't standing still.

The last stable release has been stuck at 0.6.4 since 2018. I know the lead developers have recent automated builds (December 2021), but come on, such is not going to inspire faith in casuals to join the bandwagon nor keep getting mentioned by the media. Many users like to see newer stable releases, until the project achieves its stated goals. A lot is to be said for maintaining momentum and enthusiasm.

That's another aspect of the hurdles for the newer programming languages, it's harder than ever to keep people's attention and whip up excitement.

[Tozen]

The problem is that there are so many new languages that it's hard for any of them to gain enough momentum to encourage enough programmers or businesses to learn or even look at them. Not to mention that various top 10 languages are supported by huge companies that may rather snuff out or at least throw shade on up and coming languages that threaten their interests.

The development pace of many of the new languages is relatively slow, despite having some great ideas, syntax, or features. Which means years before they have a large enough ecosystem and libraries, to even come near to mounting a challenge to the more established languages.

For instance, another new one out there that I like is VLang (https://github.com/vlang/v). Like Red, it needs to find a sweet spot that will propel it to greater usage and recognition. Partly that can be cross-compiling and cross-platform application development. Also, strong emphasis on mobile development for both Android and iOS would help, but Apple makes their part of it difficult. To stand out, it means having easy to create UIs, their own IDEs (to maximize language features), updated documentation (to help beginners), books about it, etc... Just being on Visual Studio Code, with a hundred other languages, makes it hard to get noticed.

Compare Red with established heavyweights like C#, Python, JavaScript, or even contenders like Delphi/Object Pascal. Not so easy to pull attention away from those languages and the thousands of projects using them, unless something very compelling can be shown or proven.

[dragonwriter]

> Yeah, I have no idea why Rebol and Red aren't more popular

Rebol died (for all intents and purposes) because it stayed proprietary without a large enough proprietary market too long, and good enough open source languages took the niches it could have had and built out robust ecosystems that it never developed.

Red has been disadvantaged by the ecosystem consideration, and hasn't found a killer focus that gets people over that in enough mass. They tried chasing crypto for that...

[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...

[mananaysiempre]

Similarly, TeX bakes units into its syntax, but METAFONT (which is much more pleasant as a programming language in general) just has a production for <numeric token> <numeric variable> instead (yes, it has a very involved context-dependent grammar), though it gives up type checking because of that.

[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?

[Tozen]

Rebol, is mostly "dead", and I don't like to so easily throw the term around. But, originally it started out as a proprietary commercial language, then when it couldn't make enough money, went open source. It has some good concepts, and passionate followers, but didn't go mainstream. Even though it went open source, in the flood of so many languages that exists now, continual development stalled. However, it did produce several offshoot descendant languages.

Something to point out, is there is a lot of old tutorials and information on Rebol that becomes more useful as references, if a person learns any of the descendant languages.

Red (https://www.red-lang.org), is a very good open source offshoot. If a person is choosing between them, I think most would recommend it. But, the problem with Red is its development can be described as sluggish. The lead developers appear overly preoccupied with other projects, as oppose to getting Red into a more useful state and delivering on the stated goals and expected features.

For example, one of its main benefits is easy cross-compiling to other OSes. However, it's stuck in 32-bit, and needs to have a 64-bit version to keep pace with the requirements of macOS, iOS, and Android.

If Red's development was to keep on pace, which is important for multi-OS usability, I do think it would be worth knowing. Quite powerful and easy to learn language, for potentially a wide variety of purposes, with a light footprint.

[nmz]

In reality? None. Both give me lots of trouble. Red doesn't offer a good external program launch, which when things fail, I always drop down to sh. Rebol interestingly enough offers a wee bit more stability. but its age is clearly showing. r3 being open source has a bunch of versions and forks, none of them usable. there's also ren/c which is supposed to be usable, however I cannot build it on a pi4, there is also another attempt which is called arturo, written in nim, this one works but development is only done by a single person.

[dragonwriter]

There’s a few more living derivatives of the OG Rebol; the second of these also has a list of other derivatives and relatives:

https://github.com/metaeducation/ren-c

https://github.com/Oldes/Rebol3

[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"

[wk_end]

...which illustrates one of the oddities of Smalltalk's vision of OOP pretty well. I've made deposits into accounts, or maybe I've asked banks to make a deposit into an account on my behalf, but I've never (intuitively) instructed an account to make a deposit into itself.

[PaulDavisThe1st]

level error!

   account deposit: $100

was the message from the bank teller to the account, not from you :)

[wk_end]

Do bank tellers, conceptually, think of themselves as telling accounts to add $100 to themselves? Or do they think of themselves as adding $100 to an account?

[PaulDavisThe1st]

... when the bank teller's are software-driven entities, they might :)

[bitwize]

Yeah, you're supposed to say:

    bankTeller deposit: (100 dollars) in: myAccount.

[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 :)

[JadeNB]

I want so much to like it, but, even in its heyday, the documentation was so poor—everyone seemed so convinced that its English-likeness made it obvious that they seemed to refuse to document the 'obvious' commands. And now it seems that even Apple has decided to let it languish.

[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.

[Turing_Machine]

The joke when C++ appeared on the scene was that the successor to COBOL would be named ADD 1 TO COBOL GIVING COBOL.

[bitwize]

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.

[goatlover]

The logical conclusion of that reasoning is APL. Everything else looks like some weird pseudo english in comparison.

[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.

[lou1306]

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)

[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!

[throwaway675309]

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).

[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.

[futharkshill]

"monkey patch" is frequently used by Rubyists without anny derogatory meaning.

[michaelcampbell]

True, but it was taken on by the ruby community as a badge of pride after being used as a slur by the aforementioned other community, IIRC.

[zdragnar]

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.

[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.