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

Rye: Homoiconic dynamic programming language with some new ideas

github.com

Post reply on HN
Print view View original

81–86 of 86 posts

Re: Rye: Homoiconic dynamic programming language with some new ideas

#81

Post by middayc »

elbear wrote: post #79
middayc wrote: post #73

Earlier quoted context omitted.

This is a valid argument. There are already a plenty of programming languages where you can do that. You can make temporary variables in Rye too, but it also tries to work well for these chains of expressions or function calls, and I personally prefer this style many times. There is no wrong way, IMO.

If you're the only one reading the code, then sure write it however you like it. But using long chains of expressions is the same as one-liners or point-free style in Haskell. It saves some typing and also you can skim the code more easily, but only if you're extremely familiar with what's going on there. I wonder how much you can benefit from this, if you return to the codebase after a 6-month break though. Maybe so…

I'm not trying to change your opinion, I just want to follow my opinion when coding. :)

I prefer more verbs and not too many nouns, and I think our brain is used to reading "sentences" like that.

    get http://example.com |parse-html |find-links |for-each { .if-external { .print-it } }
Is not that dissimilar from instruction we can understand quite well:

    Take a basket, look into it, pick out apples, if the apple is red take it.
If there are complex procedures, I also want to name a temporary result. It's like a divide and conquer strategy. You divide complex expression or instructions to separate definitions and combine those. But I also don't want to divide too much. This on the other hand again obscures IMO.

If I name every internal state, we get this.

    hmtlStr = get("http://example.com)
    html = parse(htmlStr)
    links = findLinks(html)
    for l in links {
      take = isExternal(l)
      if take {
         print(l)
      }
    }
Which I can parse, but it takes more energy to validate that I used the right variable at the right place, not some variable from higher up in the code for example. You probably also don't code like this, but there is some middle ground ...

Just as a thought experiment, don't take me too seriously I will try to "humanize" those instructions:

    Take a basket in your hands.
    Look into the basket in your hands.
    Find apples in looked basket in your hands.
    For every apple.
    Check if the apple is red.
    If it's red, take the apple.
Maybe you can make more balanced version which will be the best of both worlds. Thanks for the discussion :).

Re: Rye: Homoiconic dynamic programming language with some new ideas

#82

Post by alexisread »

sparkie wrote: post #62
_nalply wrote: post #7

Earlier quoted context omitted.

Why is it difficult?

It's difficult to optimize because evaluation of expressions depends on the dynamic environment, which you don't have ahead-of-time. You can't even assume `+` means "add the arguments", because `+` may have been bound to something completely different prior to evaluating the expression containing `+`.

Late to the party here. What would be your take on dynamic-by-default, but the ability to fix the env a la Dreams (http://elilabs.com/~rj/dreams/dreams- rep.html) or Zig (comptime)? You can obv. do this in Rye via a static context.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#83

Post by elbear »

tome wrote: post #80
elbear wrote: post #79

Earlier quoted context omitted.

If you're the only one reading the code, then sure write it however you like it. But using long chains of expressions is the same as one-liners or point-free style in Haskell. It saves some typing and also you can skim the code more easily, but only if you're extremely familiar with what's going on there. I wonder how much you can benefit from this, if you return to the codebase after a 6-month break though. Maybe so…

FWIW Haskell is the only language in which I've been able to return to code that I wrote six months later and still understand it.

It depends on how you wrote it. In general, I found it hard to understand point-free expressions (in the code of others, because I never used them).

Re: Rye: Homoiconic dynamic programming language with some new ideas

#84

Post by elbear »

middayc wrote: post #81
elbear wrote: post #79

Earlier quoted context omitted.

If you're the only one reading the code, then sure write it however you like it. But using long chains of expressions is the same as one-liners or point-free style in Haskell. It saves some typing and also you can skim the code more easily, but only if you're extremely familiar with what's going on there. I wonder how much you can benefit from this, if you return to the codebase after a 6-month break though. Maybe so…

I'm not trying to change your opinion, I just want to follow my opinion when coding. :) I prefer more verbs and not too many nouns, and I think our brain is used to reading "sentences" like that. get http://example.com |parse-html |find-links |for-each { .if-external { .print-it } } Is not that dissimilar from instruction we can understand quite well: Take a basket, look into it, pick out apples, if the apple is red…

I find your first example easy to understand.

It's funny, because I'm watching my experience as I'm reading the code and I feel like variables are like a little break while doing work. When you don't use them, it feels like a constant run.

Also, they give some extra structure, because they name the output of the function. It's true that you have to make extra effort to think of the name, though.

I'll be honest, your example with naming every internal state feels comfortable. Sometimes I do chain a few expressions together, but I avoid chains that are too long. I want to say that more than 3 is too much, but maybe it depends on the specific code.

I don't have examples of my own code handy, so I can see how I did it in the past. Now that I think about it a bit more, I think I'm okay with a longer chain, if it involves transformations of the same structure, but not if it involves destructuring. I perceive the `for` loop as a destructuring.

Re: Rye: Homoiconic dynamic programming language with some new ideas

#85

Post by dllthomas »

elbear wrote: post #83
tome wrote: post #80

Earlier quoted context omitted.

FWIW Haskell is the only language in which I've been able to return to code that I wrote six months later and still understand it.

It depends on how you wrote it. In general, I found it hard to understand point-free expressions (in the code of others, because I never used them).

IME, point free expressions are exceptionally clear when sufficiently simple, but get muddy fast. The inflection point is probably not too far from

    let rms = sqrt . sum . map (^^ 2)

Re: Rye: Homoiconic dynamic programming language with some new ideas

#86

Post by kunley »

middayc wrote: post #49
kunley wrote: post #48

About getters.. are they foo? or ?foo ? The examples have it mixed, "Meet Rye" doc has it as ?foo

If you don't come from Rebol it would probably be weird to you that there are many specific word-types in Rye. name: Janko ; name: is a set-word - it binds value to a word ?print ; ?print is a get-word - it get's value word is bound to in this case a print builtin function :age ; left leaning set-word (this is get-word in Rebol) what? ; just a regular word ... name get's the value anyway, so we don't need to use ?nam…

Thanks for the explanations. Indeed I don't come from Rebol and the conventions seem like a terra incognita, although I can sense a significant value in them.

From a past romance with Forth I see in general how concatenative languages seem to be underappreciated a bit

Post reply on HN