[HN Gopher] State of Rhombus (programming language)
___________________________________________________________________
State of Rhombus (programming language)
Author : Decabytes
Score : 33 points
Date : 2022-02-12 16:45 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| skybrian wrote:
| Here is a description of shrubbery syntax:
| https://github.com/mflatt/rhombus-prototype/blob/shrubbery/s...
| zelphirkalt wrote:
| I've seen the talks from RacketCon about it, but I was not
| impressed this time. They never talk about ergonomics of
| editing code properly. With S-expressions I can always select
| any expression or sub expression, because there is a clear
| start and end marker. This is probably about tooling. You could
| probably build some language support for that for shrubbery
| syntax, but it is going to be hairy. I am not convinced support
| for that will ever be as good as the code editing experience
| with S-expressions. That is why already the readme makes me
| think: "No!":
|
| > Another disadvantage of S-expressions is that many of the
| parentheses are redundant after the expression is pretty-
| printed, because indentation provides the same grouping
| information in a more human-readable way.
|
| The parentheses are not redundant at all! They are useful
| markers for selecting, cutting, pasting source code. I have
| mentioned this on the mailing list before, when there was
| discussion about moving away from S-expressions.
|
| I get it, they want to keep an open mind and research other
| syntax. That's fine and good! But don't act, as if the
| parentheses are redundant and of no use. Find something better
| that supports the same level of code editing ease, then come
| back and present. I think it might even be impossible to do
| that, because you will still need those start and end markers,
| whatever they look like, or build the tooling, that has so deep
| understanding of the language's syntax, that it can "read your
| mind" and select the correct parts.
|
| I will keep an open mind for when they surprise me and come
| around with something, that checks all the boxes.
| JonChesterfield wrote:
| Indentation based optimises for reading and sexpr based
| optimises for writing/editing.
|
| The syntax here looks isomorphic to sexpr. If so, one could
| program by reading the | based form, then convert the whole
| file to sexpr to edit it, then pretty print back to indent
| form when done. Better if the parens only replace the | and
| whitespace on the conversion so the cursor doesn't jump.
|
| I'm not sure I like that but it is a somewhat interesting
| design point.
| User23 wrote:
| All but the most inexperienced lispers read code by
| indentation.
|
| Also, pretty much any language that parses to an AST could
| easily output same as s-expressions if desired. Which
| incidentally is something I enjoy so much about Lisp. It
| makes it trivial to reason about code as a tree of
| structured objects instead of a string.
| skybrian wrote:
| Modern editors have good support for many languages that
| don't use S-expressions. Have you tried out VS Code?
|
| I think for this effort to succeed, they only need to do as
| well with editor support as other mainstream languages.
| zelphirkalt wrote:
| No offense, but editing mainstream language's code is a
| pain compared to working with S-expressions. If they manage
| to get merely to that level of code editing convenience,
| they can keep their new syntax, I'm gonna stick to
| S-expressions.
|
| I often see people using VS Code editing code. To me it
| often looks painful and I have the urge to do the code
| editing myself in Emacs with all my key bindings and good
| S-expression support. I have seen people being even much
| faster than me as well, with extra commands they define for
| moving S-expressions around and paredit and so on. Maybe VS
| Code can somehow be configured to offer the same comfort in
| code editing. I have not seen it done so far.
| Decabytes wrote:
| I think it's like you said. We will just have to wait and
| see. You are not the only one that has voiced their
| apprehension about moving away from S-expressions. One
| thing I really appreciate about the Racket Team is their
| commitment to reducing the barrier to entry into the
| language. Whether it's the Documentation, A built in IDE
| for the language, package manager, binary downloads
| directly from the website, or moving away from mailings
| lists and Google Groups to Discourse. You could even say
| that moving on top of Chez Scheme to reduce the amount of
| C code to maintain is also reducing the barrier. It's
| easier to get into Racket in 2022 then it has been at any
| point in time. Especially if you aren't familiar with
| Lisps like I was a few years ago.
|
| I think this is another move in that direction. If it
| fails, then we will have a strong data point into why
| Lisps are just better for some things. But the team is
| dedicated to not just doing things the old way and we've
| gotten so much good from that mode of thinking that I'm
| excited to follow this process whether it fails or not.
| freemint wrote:
| The metaprogramming capabilities seems quiet similar to Julia's,
| I wonder how they will differ by the end.
| isaacimagine wrote:
| I'm really excited to see how rhombus turns out, and can't wait
| too see how they resolve some of the hairier design decisions
| around building a form-based language with implicit forms.
| (Shrubbery seems interesting.)
|
| As an aside, I'm working on a different new programming language
| that supports language-level programming through a macro/effect
| system (and doesn't use s-expressions). In practice, Macro
| systems work well on any language that has the concept of 'forms'
| (see: Homoiconicity isn't the point)
___________________________________________________________________
(page generated 2022-02-12 23:01 UTC)