Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rhombus Language

rhombus-lang.org

Post reply on HN
Print view View original

81–90 of 161 posts

Re: Rhombus Language

#81

Post by sevensor »

HexDecOctBin wrote: post #53
lygaret wrote: post #4

This is racket's [rhombus], which might be an interesting second link here; it's a scheme, underneath, with the full power of Racket libs available. [`shrubbery`], the replacement for s-exprs, is pretty interesting, expanding s-expr simply with grouping, and then a separate infix-pass on top. I've been playing with using it as the basis for a separate language; it's in an interesting place in the AST space, especiall…

I really wish they had kept the old C-like Honu syntax rather that the Python-like Shrubbery. If Rhombus is supposed to be an educational language, copy-pasting and trying out new code is going to be a important part of ecosystem, and indentation based syntax is not ideal for that.

I’ve never seen anybody learn much by copy pasting. If you want to learn, you must put fingers to keys.

Re: Rhombus Language

#82

Post by spdegabrielle »

pjmlp wrote: post #20
rednafi wrote: post #8

Earlier quoted context omitted.

Thanks. It’s nice to see at least a few in the FP community recognize that Lisp dialects, with their parenthesis-ridden S-expressions, are hard to read and write.

This is nothing new, see - M-expressions ( https://en.wikipedia.org/wiki/M-expression ) - Lisp 2 ( https://en.wikipedia.org/wiki/LISP_2 ) - Dylan ( https://en.wikipedia.org/wiki/Dylan_(programming_language) - Wolfram ( https://en.wikipedia.org/wiki/Wolfram_Language ) - Julia ( https://en.wikipedia.org/wiki/Julia_(programming_language) ) However the large majority of Lisp folks end up using plain old Common Lisp and S…

This is a new approach :)

For more details see the paper https://dl.acm.org/doi/pdf/10.1145/3622818 or watch the talk https://www.youtube.com/watch?v=hkiy1rmKA48

Re: Rhombus Language

#83

Post by mapcars »

Looking through the examples, macros and pattern-matching, for me that would be impressive like 10 years ago.

If you want to see really innovative, readable and powerful language check out Red. While the language development seems to be ceased, the ideas (coming from old proprietary Rebol language) of working with code and data go much deeper than just macros: it has built-in DSL (called parse) for making DSLs on the fly and not just pre-runtime code manipulations. https://www.red-lang.org/

And there is XL language which might have even more powerful extensibility features, like adding types or pattern matching or asynchronous processing. Sadly I couldn't compile and try the only implementation it has, only judging by the docs explaining its ideas. https://xlr.sourceforge.io/

Re: Rhombus Language

#84

Post by mapcars »

pmontra wrote: post #18

The examples on the home page are a nice way to quickly show the features of a language. I'll check the documentation to see how to work with files, make HTTP calls, parse JSON. It's the first time in more than 10 years that I actually feel like trying a new language. The last time was Elixir. Since then I had to use Lua (hobby project) and Python (work) but I don't enjoy them much. I would have skipped them if I had…

You ever heard of Crystal, Red, XL?

Re: Rhombus Language

#86

Post by Bogdanp »

zerr wrote: post #34

Does anyone use Racket outside academia? Is it production ready (or friendly)? Especially Typed Racket.

I’ve used it for all kinds of production stuff over the years, from web to desktop and mobile apps.

Re: Rhombus Language

#87

Post by obogobo »

spdegabrielle wrote: post #71
HexDecOctBin wrote: post #53

Earlier quoted context omitted.

I really wish they had kept the old C-like Honu syntax rather that the Python-like Shrubbery. If Rhombus is supposed to be an educational language, copy-pasting and trying out new code is going to be a important part of ecosystem, and indentation based syntax is not ideal for that.

A valid point. There is a long history of identifying the problems and risks of copy-pasting, and trying to reduce it. I remember it was a selling point of Java in the early days. For all the efforts it doesn't seem to be going away. (all the boilerplate in Java probably didn't help) I'd love to see a C-like Rhombus. A Chombus.

lol at Chombus

Re: Rhombus Language

#89

Post by psychoslave »

eviks wrote: post #27

How hard would it be to uniquely extend the language to make *fun* into *fn* and *...* into a single letter *…*? fun all_same([str0, str, ...]): all(str0 == str, ...)

So basically, assuming no special constructor for array, this is

    fun all_same(array(str0, str, ...)):
      all(=(str0, str), ...)
Which taking could just as well be rendered only using English words for each token:

    let all-same of array of former eft latter eft more sam sam be
        all of tie of former eft later sam eft more sam
Though "more" could also be replaced with "etcetera" or "etc" or "mo" for terseness or "and·son·on" for something more casual.

Admittedly some of these words are not very frequently used in English, but that can actually be a big plus for a programming language keyword. On the other hand all of these terms have a meaning recorded in lexicographic works that would make perfect sense for the context they are placed in each position above. And taking the exact opposite of the approach to carry so much semantic in non-phonetic symbols, that is making them as semantically as void as a space or a comment in code parlance, they can just as well be introduced again:

    【let〖all-same｟of(array〚of[former„eft”latter„eft”⋮more⋮]sam〛)sam｠be〗⧘:⧙ {
            all｟of(tie〚of[former„eft”later]sam〛„eft”⋮more⋮)sam｠∎
     }】◼
Ok, a bit far fetched, but it does illustrate well what this reversed approach regarding soundless symbols can open in term of additional scriptural cues compared to the one which also will bind them to some semantic and syntax constraints.

https://en.wiktionary.org/wiki/mo#Adverb

https://en.wiktionary.org/wiki/sam#Adverb

https://en.wiktionary.org/wiki/eft#Adverb

Re: Rhombus Language

#90

Post by odyssey7 »

hnlmorg wrote: post #44
timkq wrote: post #29

Earlier quoted context omitted.

TypeScript & Rust don't "look nice to work with" because they force you to write maintainable code that doesn't just stop working because of a random runtime error. In my opinion, Go looks nice to work with but actually is a hidden monster full of footguns.

Curious to read that because I’ve always had the opposite opinion of the above: Typescript looks nice to work with but the tool chain is horrible (this isn’t really Typescripts fault though, more a synonym of it having to compile to JS). Go looks horrible to work with (too simplified syntax) but is actually really nice because the tooling is (mostly) spot on and it’s simplified syntax weirdly helps with maintainabili…

JS isn’t breaking, it’s the layers between there and Typescript.
Post reply on HN