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

91–100 of 161 posts

Re: Rhombus Language

#91

Post by f1shy »

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…

Also sweet expressions [0]

[0] https://dwheeler.com/readable/sweet-expressions.html

Re: Rhombus Language

#92

Post by arunix »

soegaard wrote: post #63
Y_Y wrote: post #54

I've been cautiously optimistic about Rhombus since the initial "Racket 2" controversy. I'd have preferred they went with something more like Wisp or Wraith, but it could be a lot worse. I am somewhat troubled by tricks that are "too magic", like this example from front page: class Posn(x, y) fun flip_all([Posn(x, y), ...]): [Posn(y, x), ...] flip_all([Posn(1, 2), Posn(3, 4)]) // ⇒ [Posn(2, 1), Posn(4, 3)] Why should…

It's not magic. It's pattern matching. The `[Posn(x, y), ...]` is a pattern that matches a list of positions. The `[Posn(y, x), ...]` is a template that produces a list of positions.

That syntax suggests the first pair will be flipped, and the rest will just be as they were, i.e. more like flip_first

Re: Rhombus Language

#93

Post by f1shy »

datadeft wrote: post #37

Is it possible to have Hindley–Milner type system for a LISP?

Absolutely: you can make that with some macros and using type annotations. I do not know how difficult can it be, but surely there are thing already done.

Re: Rhombus Language

#94

Post by soegaard »

arunix wrote: post #92
soegaard wrote: post #63

Earlier quoted context omitted.

It's not magic. It's pattern matching. The `[Posn(x, y), ...]` is a pattern that matches a list of positions. The `[Posn(y, x), ...]` is a template that produces a list of positions.

That syntax suggests the first pair will be flipped, and the rest will just be as they were, i.e. more like flip_first

When the pattern `[Posn(x, y), ...]` matches a list of positions, since `Posn(x, y)` is followed by `...` the `x` is bound to a sequence of first coordinates and `y` is bound to a sequence of second coordinates.

In the template the `Posn(y, x)` is followed by `...` so the same number of positions is produced as the common length of x and y.

Re: Rhombus Language

#95

Post by pjmlp »

spdegabrielle wrote: post #82
pjmlp wrote: post #20

Earlier quoted context omitted.

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

Sure, and great that other attempts are being made, only pointing out to the OP, that there is previous work on this domain.

Thanks for the links.

Re: Rhombus Language

#96

Post by freeopinion »

kalekold wrote: post #38
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.

> Go looks nice to work with but actually is a hidden monster full of footguns. Really? Me and my team been using it for years with no problems whatsoever.

Do you feel the same way about English?

Re: Rhombus Language

#97

Post by velcrovan »

lproven wrote: post #68
cardanome wrote: post #36

Earlier quoted context omitted.

It is hard to have empathy for a problem you don't have. I have only recently become open to the idea that people might legitimately experience pain using an unfamiliar syntax. For me, it is a non-issue. From Lisp to C to APL to Forth to Prolog, syntax was never an issue for me. I greatly enjoy learning languages with different approaches to syntax. It has never caused me pain. Only joy. Then again programming langua…

> It is hard to have empathy for a problem you don't have. I do not find this myself, and it is a standard part of the design of a lot of commercial software: intentionally thinking about disabilities, impairments, and difficulties, and working on accommodating people who struggle with these things. Examples: * GUIs that flash the screen to signify a bell sounding for deaf users. * Keyboard-operated GUIs for users wi…

For years I maintained an ERP system written in BASIC. It was legitimately terrible. The lack of lexical scoping and decent flow control made it nearly impossible to reason about for even simple changes. There’s nothing brilliant about line numbers and all-global variables, it’s literally one of the laziest, sloppiest design decisions you could make in a programming language.

Granted, if your only experience of BASIC is fond memories of the TRS-80 at your grade school, yeah any contempt for it will seem simplistic and poorly motivated. Maybe try having to depend on it for literally anything in a professional setting and you’ll have a more informed perspective.

Re: Rhombus Language

#98

Post by fernmyth »

cardanome wrote: post #36
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.

It is hard to have empathy for a problem you don't have. I have only recently become open to the idea that people might legitimately experience pain using an unfamiliar syntax. For me, it is a non-issue. From Lisp to C to APL to Forth to Prolog, syntax was never an issue for me. I greatly enjoy learning languages with different approaches to syntax. It has never caused me pain. Only joy. Then again programming langua…

It’s not about an unfamiliar syntax. S-exprs are objectively hard to read. The same shape for function calls, macros, blocks, and data means I can’t distinguish them by sight to detect the code structure. I have to do conscious paren matching.

Structure recognition should be pushed as far down in the subconscious as possible. Rainbow parens help, but it’s not nearly enough to stop other expression fragments from jumping into attention. Likewise clojure’s different bracket types for data structures, likewise the editor highlighting the paren matching the one at the cursor. Better than nothing, but incomparably worse than just having visually distinct syntax in the first place.

C-style is fine. Python-style, ML-style, SQL-style, BASIC, shell: all fine for structure recognition. But lisp is just a soup. Or a fog.

Same problem with elasticsearch queries, too.

Re: Rhombus Language

#99

Post by lproven »

velcrovan wrote: post #97
lproven wrote: post #68

Earlier quoted context omitted.

> It is hard to have empathy for a problem you don't have. I do not find this myself, and it is a standard part of the design of a lot of commercial software: intentionally thinking about disabilities, impairments, and difficulties, and working on accommodating people who struggle with these things. Examples: * GUIs that flash the screen to signify a bell sounding for deaf users. * Keyboard-operated GUIs for users wi…

For years I maintained an ERP system written in BASIC. It was legitimately terrible. The lack of lexical scoping and decent flow control made it nearly impossible to reason about for even simple changes. There’s nothing brilliant about line numbers and all-global variables, it’s literally one of the laziest, sloppiest design decisions you could make in a programming language. Granted, if your only experience of BASIC…

1. I helped maintain a payroll system written in GW-BASIC for a year or two. It was designed cleanly and well, with each module of code a separate file chain-loaded in from disk as a de facto overlay system. The variables that each module inherited were thoroughly documented in code comments at the top of each module, so it was clear what it would inherit in RAM and which you needed not to touch.

Just as one can write spaghetti code in any language, one can equally write good clean code in any language.

2. Remember what the _B_ in BASIC stands for. Despite that it was used professionally, yes, but there is in any and all fields a need for easy tools for beginners to learn with.

https://www.fortressofdoors.com/take-the-pedals-off-the-bike...

As discussed here:

https://news.ycombinator.com/item?id=42697467

Re: Rhombus Language

#100

Post by Jtsummers »

unwind wrote: post #42
wavemode wrote: post #6

From the 2nd example: class Rect(left, top, right, bottom) fun rect_like_to_rect(v): match v | Rect(_, _, _, _): v | {"LT": [l, t], "RB": [r, b]}: Rect(l, t, r, b) | {"TL": [t, l], "RB": [b, r]}: Rect(l, t, r, b) rect_like_to_rect({"TL": [0, 2], "RB": [10, 5]}) // ⇒ Rect(0, 2, 10, 5) Isn't this wrong? I'd expect to see Rect(2, 0, 5, 10) instead. It also seems like "RB" was meant to be "BR".

If you indent each line by, uh, something (I use 4 spaces), HN gives you code formatting: class Rect(left, top, right, bottom) fun rect_like_to_rect(v): match v | Rect(_, _, _, _): v | {"LT": [l, t], "RB": [r, b]}: Rect(l, t, r, b) | {"TL": [t, l], "RB": [b, r]}: Rect(l, t, r, b) rect_like_to_rect({"TL": [0, 2], "RB": [10, 5]}) // ⇒ Rect(0, 2, 10, 5) rect_like_to_rect({"LT": [0, 2], "RB": [10, 5]}) // ⇒ Rect(2, 0, 5,…

Two spaces are all you need. There are only two formatting rules on HN so it's easy to remember: * around text adds emphasis emphasis.

  Two spaces before each line
  creates a code block.
Post reply on HN