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

The Red Programming Language

red-lang.org

Post reply on HN
Print view View original

121–130 of 135 posts

Re: The Red Programming Language

#121

Post by bunderbunder »

fn-mote wrote: post #48
AnimalMuppet wrote: post #33

Earlier quoted context omitted.

Even without the new spiffs, I still don't see the point of DSLs. From where I sit, I see exactly zero problems where I think that new syntax is what I need to be able to write a solution.

I used to feel that way. I’m still not a convert, but now I’ve seen a lot more complexity papered over by a nice DSL. Standard math syntax is a DSL. I understand math a lot more quickly than I understand the same thing written in 20 lines of code. I think the language we use to express ourselves influence the quality of the product. If your language encapsulates complexity, then you can build more complicated things.…

The protocol buffer / grpc definition language is another great example of where a DSL can shine. Especially if you compare it to efforts to accomplish basically the same task using pre-existing languages, such as OpenAPI (JSON) and WCF (XML).

Re: The Red Programming Language

#122

Post by bunderbunder »

jolt42 wrote: post #109
AnimalMuppet wrote: post #33

Earlier quoted context omitted.

Even without the new spiffs, I still don't see the point of DSLs. From where I sit, I see exactly zero problems where I think that new syntax is what I need to be able to write a solution.

Lisps don't support OO, concurrency like Go, or type checking but you can write a DSLs for them. Not useful? How about a rules engine?

You could write DSLs for them, but you could just as easily do it within the existing syntax. Which is exactly how all the popular lisp implementations of OO, concurrency and type checking work in practice.

Many of them do use macros. But that's not about creating a special language; that's about moving expensive computations and checks that can be done statically to compile time where they belong.

Re: The Red Programming Language

#123

Post by justin66 »

tejtm wrote: post #46
dev_l1x_be wrote: post #6

Earlier quoted context omitted.

"In 1988, Sassenrath left Silicon Valley for the mountains of Ukiah valley, 2 hours north of San Francisco. From there he founded multimedia technology companies such as Pantaray, American Multimedia, and VideoStream. He also implemented the Logo programming language for the Amiga, managed the software OS development for CDTV, one of the first CD-ROM TV set-top boxes, and wrote the OS for Viscorp Ed, one of the first…

pretty sure he finished out his post Rebol career with Roku

One can go to his web page to find out what he's doing with himself.

Re: The Red Programming Language

#124

Post by justin66 »

sph wrote: post #87
therein wrote: post #54

Earlier quoted context omitted.

Interesting, that at least explains why this happens a little bit. https://i.imgur.com/a/phd4lVr

Holy nanny state. The authors of a language have thought about using cryptocurrency, so it's flagged as a phishing and scam site? Literally 1984.

That message was created by... the state?

Re: The Red Programming Language

#125

Post by Izkata »

sph wrote: post #88
kazinator wrote: post #64

Earlier quoted context omitted.

From your brief description that is likely incomplete, it looks as if the length? function is treated as a prefix operator of low precedence relative to the infix operators. The infix operators are all at the same precedence level and have left-to-right associativity. I made an infix parser in which certain prefix operators (named math functions) have a low precedence. This allows for things like 1> log10 5 + 5 ;; i.…

Not sure why you got downvoted, but Rebol is not a Lisp. It doesn't work because of precedence rules or special rules, but because arguments accumulate until there are enough to eval the previous function in the stack, so you can do stuff like print tostring 5 + cos pi Works a bit like a shift/reduce parser, with heavy use of fexprs (blocks in Rebol parlance) I know you enjoy Lisps, so you might like this toy Rebol e…

I'm guessing because their understanding is still wrong:

  3> log10 5 + 5 + log10 5 + 5    ;; i.e. (log10 5 + 5) + (log10 5 + 5)
  2.0
In Rebol this would be equivalent to (log10 (5 + (5 + (log10 (5 + 5)))))

Re: The Red Programming Language

#126

Post by mdaniel »

bunderbunder wrote: post #121
fn-mote wrote: post #48

Earlier quoted context omitted.

I used to feel that way. I’m still not a convert, but now I’ve seen a lot more complexity papered over by a nice DSL. Standard math syntax is a DSL. I understand math a lot more quickly than I understand the same thing written in 20 lines of code. I think the language we use to express ourselves influence the quality of the product. If your language encapsulates complexity, then you can build more complicated things.…

The protocol buffer / grpc definition language is another great example of where a DSL can shine. Especially if you compare it to efforts to accomplish basically the same task using pre-existing languages, such as OpenAPI (JSON) and WCF (XML).

Captain Pedant here, but OpenAPI also accepts yaml which suffers from a ton less { and "

gRPC and I are not friends and I've thankfully never needed to interact with WCF

Re: The Red Programming Language

#127

Post by mdaniel »

agos wrote: post #86
taylorallred wrote: post #24

Languages that encourage making DSLs are a two-edged sword. On the one hand, you get to make a language that is more clear and fine-tuned to your use-case. On the other, you have an ad-hoc language with no support that you have to maintain along with the documentation (considering that you can't expect anyone else to know the DSL ahead of time). As I've gotten older, I've determined that well-designed APIs in a well-…

this is a very important lesson. I remember the frustration of dealing with the Gradle and whatever was the name of the DSL used by Fastlane. Gradle especially kept changing so documentation was never really useful and there was zero help from the tooling

> and there was zero help from the tooling

That's mostly my experience with ruby, too: you can type anything, don't worry about it!

I wanted to mention that Gradle since I think about version 7 supports mostly static typing via Kotlin but regrettably it's lipstick on a pig since almost inevitably one needs to interact with the Groovy side of the house and then all bets are off

Re: The Red Programming Language

#128

Post by dragonwriter »

bunderbunder wrote: post #30
vidarh wrote: post #27

Earlier quoted context omitted.

An API is just as much a DSL.

Kind of, except that a non-DSL API doesn't create any new syntax. Which means that you get to keep all sorts of quality-of-life tools like syntax highlighting and correctness checking in the editor, autoformatting, possibly some amount of linting, etc. A few years ago I revisited Racket after a long hiatus, and that was maybe the biggest thing I noticed. I really don't like syntax macros as much as I did back in the…

> Kind of, except that a non-DSL API doesn't create any new syntax.

Internal DSLs are always (by definition) valid code in the host language; external DSL, where parsing and interpretation or compilation to executable code for raw text code in the DSL are implemented in the host language, are all new syntax, but “languages that encourage making DSL” are usually ones that are favored for internal, not external, DSLs.

Re: The Red Programming Language

#129

Post by bunderbunder »

dragonwriter wrote: post #128
bunderbunder wrote: post #30

Earlier quoted context omitted.

Kind of, except that a non-DSL API doesn't create any new syntax. Which means that you get to keep all sorts of quality-of-life tools like syntax highlighting and correctness checking in the editor, autoformatting, possibly some amount of linting, etc. A few years ago I revisited Racket after a long hiatus, and that was maybe the biggest thing I noticed. I really don't like syntax macros as much as I did back in the…

> Kind of, except that a non-DSL API doesn't create any new syntax. Internal DSLs are always (by definition) valid code in the host language; external DSL, where parsing and interpretation or compilation to executable code for raw text code in the DSL are implemented in the host language, are all new syntax, but “languages that encourage making DSL” are usually ones that are favored for internal, not external, DSLs.

I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that.

I think the internal/external terminology might be kind of outdated, anyway? I think this might be the first time I've encountered it in the wild in over 10 years.

Re: The Red Programming Language

#130

Post by dragonwriter »

bunderbunder wrote: post #129
dragonwriter wrote: post #128

Earlier quoted context omitted.

> Kind of, except that a non-DSL API doesn't create any new syntax. Internal DSLs are always (by definition) valid code in the host language; external DSL, where parsing and interpretation or compilation to executable code for raw text code in the DSL are implemented in the host language, are all new syntax, but “languages that encourage making DSL” are usually ones that are favored for internal, not external, DSLs.

I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that. I think the internal/external terminology might be kind of outdated, anyway? I think this might be the first time I've encountered it in the wild in over 10 years.

> I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that.

When people talk about REBOL/Red (or Ruby or Lisps) encouraging making DSLs, they are referring to internal DSLs. In Ruby, these are just APIs consisting of normal objects and methods, in Lisps they often involve macro calls, which may or may not correspond to what people mean by an API, and in REBOL/Red the design of the language is such that “normal” functions can do things that would take macros in Lisp.

Post reply on HN