8 ms·

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

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 5y ago
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 5y ago
  Yeah, I have no idea why Rebol and Red aren't more popular. ( https://www.red-lang.org/ https://www.red-lang.org/ ) They pack such a bang for the buck it's almost embarrassing for other language/runtimes.
  - dragonwriter 5y ago
    > 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...
  - Jtsummers 5y ago
    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 5y ago
    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 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.
  - Tozen 5y ago
    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.
- fault1 5y ago
  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-parser.scm https://github.com/JuliaLang/julia/blob/master/src/julia-par...
  - mananaysiempre 5y ago
    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 5y ago
  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
- tomcam 5y ago
  Which is the better choice these days, Rebol or Red?
  - nmz 5y ago
    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 5y ago
    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/metaeducation/ren-c https://github.com/Oldes/Rebol3 https://github.com/Oldes/Rebol3
  - Tozen 5y ago
    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 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.
- dragonwriter 5y ago
  > Rebol takes things further by identifying $ as a datatype. Well, money! is a datatype, $ is a sigil that identifies a money! literal.
JadeNB 5y ago
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 https://daringfireball.net/2005/09/englishlikeness_monster). There's a reason we don't program in COBOL!
- nauticacom 5y ago
  I must be the only person on the planet who likes AppleScript :)
  - JadeNB 5y ago
    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 5y ago
> 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.
- brabel 5y ago
jollybean 5y ago
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.
ignitionmonkey 5y ago
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.
- PaulDavisThe1st 5y ago
  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 5y ago
    ...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 5y ago
      level error! account deposit: $100 was the message from the bank teller to the account, not from you :)
      - wk_end 5y ago
        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?
dragonwriter 5y ago
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.

nmz 5y ago

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 5y ago
Yeah, I have no idea why Rebol and Red aren't more popular. ( https://www.red-lang.org/ https://www.red-lang.org/ ) They pack such a bang for the buck it's almost embarrassing for other language/runtimes.
- dragonwriter 5y ago
  > 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...
- Jtsummers 5y ago
  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 5y ago
  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 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.
- Tozen 5y ago
  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.
fault1 5y ago
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-parser.scm https://github.com/JuliaLang/julia/blob/master/src/julia-par...
- mananaysiempre 5y ago
  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 5y ago
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
tomcam 5y ago
Which is the better choice these days, Rebol or Red?
- nmz 5y ago
  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 5y ago
  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/metaeducation/ren-c https://github.com/Oldes/Rebol3 https://github.com/Oldes/Rebol3
- Tozen 5y ago
  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 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.
dragonwriter 5y ago
> Rebol takes things further by identifying $ as a datatype. Well, money! is a datatype, $ is a sigil that identifies a money! literal.

JadeNB 5y ago

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 https://daringfireball.net/2005/09/englishlikeness_monster). There's a reason we don't program in COBOL!

nauticacom 5y ago
I must be the only person on the planet who likes AppleScript :)
- JadeNB 5y ago
  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 5y ago

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

brabel 5y ago

jollybean 5y ago

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.

ignitionmonkey 5y ago

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.

PaulDavisThe1st 5y ago
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 5y ago
  ...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 5y ago
    level error! account deposit: $100 was the message from the bank teller to the account, not from you :)
    - wk_end 5y ago
      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?

dragonwriter 5y ago

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.