Live data from Hacker News

The Red Programming Language

red-lang.org

71–80 of 135 posts

Re: The Red Programming Language

#71

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-…

I like the idea of DSL, but in real projects, I hate almost every DSL introduced by coworkers.

Re: The Red Programming Language

#72
post #67
post #63

Earlier quoted context omitted.

I've seen it. Sometimes a DSL is more readable than trying to shoehorn control flow into method calls (".then().catch()..."). Or see C#'s LINQ.

> Or see C#'s LINQ. This might be one of the rare times it's worth it. The C# team alread has the experience and tooling to maintain a language. Maintaining a DSL might be a reasonable choice for them. It's rarely a good idea for app or library devs to make a similar decision.

Yes, this reminds me of meta-programming in languages like Python, it's useful if you want to create a framework like Django, but if you work on products, chances are good you should not use it.

Re: The Red Programming Language

#73
post #35

Earlier quoted context omitted.

Regex

TBH, I feel like regexes would be much easier to understand in a more literate form with standard syntax. Something like: user_part = re.repeat(re.alnum | re.chars(".-_+")) domain_segment = re.repeat(re.alnum) domain = re.list(domain_segment,separator=".",minimum=2) email_address = user_part + "@" + domain Where, in a real program, `domain` would be defined in a "standard library of constructions" that you can just i…

I don't quite understand where regex gets its reputation from. I think that once you remember the meaning of the operators, it's not too bad. (And the concise syntax is actually very helpful.)

I get that the meaning of the operators is not clear unless you're already familiar with regex, but neither is the meaning of !, ?, %, &, |, ^, ~, &&, ||, >, *, //, &, ++ (prefix), ++ (postfix), and so on. You learn these because you need them once, and then they're burned into your mind forever. Regex was similar for me.

Re: The Red Programming Language

#74

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-…

I’m right there with you. Modern languages have such a plethora of tooling available that DSLs and any API approaching a DSL have this massive gap unless they really embrace whatever patterns the host language’s tooling enables.

Not long ago, i had to work with a coworker’s mini language and function runner engine, which was basically a mini programming language. Except without a debugger or type checker or stack traces or any of the other million niceties we’d have had if we just used the host language to execute things ‘natively.’

That said, while the level of tooling for big languages goes up, the bar for creating yesteryear’s tooling is going down, with all the LSP tooling we have now, for example. Maybe someday we’ll get languages with tools where libraries have nice tooling without crazy dev effort, and then we’ll change our tune on DSLs.

Re: The Red Programming Language

#75
post #27

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-…

An API is just as much a DSL.

[deleted]

Re: The Red Programming Language

#76

Earlier quoted context omitted.

TBH, I feel like regexes would be much easier to understand in a more literate form with standard syntax. Something like: user_part = re.repeat(re.alnum | re.chars(".-_+")) domain_segment = re.repeat(re.alnum) domain = re.list(domain_segment,separator=".",minimum=2) email_address = user_part + "@" + domain Where, in a real program, `domain` would be defined in a "standard library of constructions" that you can just i…

I don't quite understand where regex gets its reputation from. I think that once you remember the meaning of the operators, it's not too bad. (And the concise syntax is actually very helpful.) I get that the meaning of the operators is not clear unless you're already familiar with regex, but neither is the meaning of !, ?, %, &, |, ^, ~, &&, ||, >, *, //, &, ++ (prefix), ++ (postfix), and so on. You learn these becau…

Also, regexps are just that: regular. You can mostly read them from left to right decoding each symbol at a time.

Re: The Red Programming Language

#77
post #35

Earlier quoted context omitted.

Regex

TBH, I feel like regexes would be much easier to understand in a more literate form with standard syntax. Something like: user_part = re.repeat(re.alnum | re.chars(".-_+")) domain_segment = re.repeat(re.alnum) domain = re.list(domain_segment,separator=".",minimum=2) email_address = user_part + "@" + domain Where, in a real program, `domain` would be defined in a "standard library of constructions" that you can just i…

recommend you check out raku Grammars … https://docs.raku.org/language/grammars

Re: The Red Programming Language

#78

Earlier quoted context omitted.

TBH, I feel like regexes would be much easier to understand in a more literate form with standard syntax. Something like: user_part = re.repeat(re.alnum | re.chars(".-_+")) domain_segment = re.repeat(re.alnum) domain = re.list(domain_segment,separator=".",minimum=2) email_address = user_part + "@" + domain Where, in a real program, `domain` would be defined in a "standard library of constructions" that you can just i…

I don't quite understand where regex gets its reputation from. I think that once you remember the meaning of the operators, it's not too bad. (And the concise syntax is actually very helpful.) I get that the meaning of the operators is not clear unless you're already familiar with regex, but neither is the meaning of !, ?, %, &, |, ^, ~, &&, ||, >, *, //, &, ++ (prefix), ++ (postfix), and so on. You learn these becau…

I think regex gets some of its hate from people writing painfully complex matchers. 99% of my day to day regex use is simpler string searches on the command line or in my editor. I’m really happy I took the time to learn the syntax (spent about a week on it around 15 years ago) because now it doesn’t get in my way.

Re: The Red Programming Language

#79
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…

Conversely, Ruby is often seen as facilitating DSL's, but none of it changes syntax, because the syntax as-is is flexible enough that redefining methods is sufficient. But everything still abides by the same syntactical rules.

The more orthogonal or flexible the language is, the less there tends to be a distinction between redefining syntactical elements and defining functions or methods.

Re: The Red Programming Language

#80
post #31
post #27

Earlier quoted context omitted.

An API is just as much a DSL.

No, an API uses existing rules, but a DSL uses its own ad hoc rules. GP is right. Don't make DSLs, make APIs, which are: * More composable * More reusable * More simple to reason about * More natively supported * More portable * More readable * More maintainable

An API creates its own ad hoc rules too. They just don't change the grammar.

In languages where the grammar is sufficiently flexible, the distinction all but disappears, but even in languages where the grammar is rigid and API's stand out like a sore thumb, the API itself still creates a new rule-set that you need to learn.

You can choose to not call that a new language all you want, but the cognitive load is still there.

Post reply on HN