Earlier quoted context omitted.
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.
Rhombus Language
101–110 of 161 posts
Re: Rhombus Language
#102Earlier quoted context omitted.
C#: ASP.NET Core (a slimmer, faster Spring Boot), EF Core (better Prism, jOOQ, etc.), very flexible build targets (JVM-style, self-contained JIT and AOT binaries), easy integration with F#, good pattern matching, access to low-level features only rivaled by Swift (although Swift has its own set of issues). Far better performance ceiling than all the languages here on the list.
You forgot async/await. But all that wasn't what propelled C# to popularity, and I say that as someone who's been writing it since 2002. It was an army of VB6 and Delphi line-of-business programmers migrating to the new stack and enterprises running Windows. The next big killer application was Unity, which didn't even use Microsoft .NET. Everything else is just marginal advantage: if you're a JVM shop, the existing e…
Re: Rhombus Language
#103I'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…
Care you to elaborate on Racket 2 controversy? I don't follow the language, but I'm aware of it, so I didn't learn about the controversy.
Re: Rhombus Language
#104Earlier quoted context omitted.
This is not playing devil's advocate - this is a _VERY_ legitimate question. I'll go further and say that without a "killer app" (and/or strong corporate backer), a language doesn't typically take off nowadays, regardless how good it is ([edit] but to the point of another commenter - I do agree that "exploration" is a good enough reason; one doesn't need to write languages only with the goal of making them popular).…
> 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.
Re: Rhombus Language
#105Earlier 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…
Most "Lisp is unreadable" forum posting activity is just trolling by nonpractitioners. You can usually tell because it doesn't hit on the real readability issues, only the imaginary ones.
To read a Lisp dialect, you have to know what numerous words mean.
A seasoned Lisp coder cannot read the following, besides understanding its source code structure as data. I would guess that defcrunk foo defines something named foo, which is a crunk whatever that means. After that I have to be looking at the documentation of defcrunk (or asking AI).
(defcrunk foo (splat zing)
(:crom jang)
(:flit (burch culd)))
I suspect that a good proportion of Lisp is like this for newcomers.Sometimes people make new Lisp dialects because they don't like the words and they want to make up their own. It might not be their main reason but it figures in there. Someone else has to learn those, including people that already know an existing Lisp or two.
Also, my above defcrunk thing will parse in many a Lisp dialect; and I could make a macro to make it work in some way. Trolls about Lisp have really latched on to this one. Their leader, a front end web developer, wrote a little article about it about an imaginary curse ...
Re: Rhombus Language
#106The 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…
I found Kotlin a "typed Ruby" (I found Ruby a "sane Perl"). Rust seems pretty nice to work with (good DX) in it's domain: close to the metal programs were every tick counts. The main DX issue with it would be compile times. Go's awful to me from a DX perspective as it is lacks proper error handling. Compile times are great though. Maybe OCaml is a good fit for me (and you!). Fast compile times and good error handling…
Re: Rhombus Language
#107Re: Rhombus Language
#108Earlier quoted context omitted.
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.
Re: Rhombus Language
#109I'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…
Here, the ... pattern combinator means 'match a list (segment) consisting of the pattern Posn(x,y) zero or more times, and because (free variables) x and y are under one ... combinator, bind x to a list of xs and y to a list of ys'. The template combinator ... means 'produce a list (segment) consisting of the template Posn(x, y) zero or more times, returning an error unless x and y are bound to lists. The reason I specified 'under one combinator' for the pattern part is that ellipses can be nested, resulting in contained pattern variables being bound to lists of lists etc. anyway, point is, this is all just compositional rules, with no spooky communication needed between pattern and template. I won't objectively argue that it's not magic, but it's at least not more magic than regexps.
Re: Rhombus Language
#110Earlier quoted context omitted.
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 writ…
What happened here was that this payroll system of yours was written by people who saw clearly the danger of BASIC's many footguns and mitigated it the best way they could, by supplementing their code with vast quantities of english prose. This is not an argument in favor of BASIC.
> Just as one can write spaghetti code in any language, one can equally write good clean code in any language.
This is only half the truth. It's like saying it's equally possible to drive well or poorly in a 1990 Yugo as it is in a 2025 Accord. The car actually does matter in a lot of cases. I despise Python's tooling, but if one were to do a thoughtful rewrite of your old payroll system in Python, all those code comments would be completely unnecessary (it would be impossible to commit the kind of error that the comments were needed to warn against), and the code itself would be far easier to read and maintain.