Earlier quoted context omitted.
I was skeptical when I heard “Python-like Racket syntax,” but this certainly looks like the Python I wish I was writing. Edit: racket is a nice language, went my thinking, why give it a Python syntax? But I think they’ve answered that.
I think they say "Python-like syntax" because "ML-like syntax" is too big a turnoff ;)
Rhombus Language
141–150 of 161 posts
Re: Rhombus Language
#142Re: Rhombus Language
#143Is it possible to have Hindley–Milner type system for a LISP?
Re: Rhombus Language
#144Earlier quoted context omitted.
> Typescript: V8/Node.js / javascript on the server-side I would dare to say that more people use Typescript in frontend than in backend projects, so basically Typescript killer "app" is the browser, because you are forced to use Javascript, but JS does not scale that good for mid, big projects.
I agree; but I _think_ chronologically Node & server-side-JS came first? The driver is the same though: "larger codebases, running on top of Javascript" - and indeed nowadays probably the browsers are the things that run the larger codebases.
Just like VSCode started as the Web IDE Monaco, written in this new Typescript thingie, before pivoting into Electron.
Re: Rhombus Language
#145Earlier 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…
Re: Rhombus Language
#146Earlier quoted context omitted.
I’m not sure about Go being full of footguns, but for one, a panic in any goroutine forcibly terminates the entire application.
The constant incantation of if err != nil is bad for my aging hands and frankly hurts even more when you see Rust's single-character error marshalling using ? operator.
The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block.
I dont understand why people dont use this kind of thing for the most common programming constructs.
Re: Rhombus Language
#147Earlier quoted context omitted.
The constant incantation of if err != nil is bad for my aging hands and frankly hurts even more when you see Rust's single-character error marshalling using ? operator.
I have aliases for these kinds of general things (in vim) for most languages i use. Eg. if im inside a typescript file i have a mapping produces if ($obj) { $ } and i tab to enter the next "$" to insert the correct things. The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block. I dont understand why people dont use this kind of thing for the most common programming c…
Re: Rhombus Language
#148Earlier 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’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 jump…
Re: Rhombus Language
#149Earlier quoted context omitted.
a big part of the racket project has been about establishing robust tools for transforming syntax. focusing on this use case has resulted in a much more generalized notion of pattern matching and template reconstruction than is typical. these kind of pattern/template combinators, as developed for racket/match and syntax-parse, might appear special-casey at first glance but from use i can attest that they are clean an…
I understand what it's doing, I just don't like that it does it.
It's trying to unify how macros produce syntax objects via `syntax-rules`-style pattern matching and ellipses with how regular pattern matching on values works, so there aren't two separate pattern languages (one for macros and one for everything else).
Re: Rhombus Language
#150I am going to play the devil's advocate. What problem does Rhombus solve? An approachable syntax is a necessary, but not sufficient requirement for mass adoption. According to the goals page, its other major feature is an extensible syntax. Why should I prefer it over, say, Scala? Scala has syntax macros, it runs on the JVM and can access Java's massive library of libraries, it has been used to implement large and co…