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

Understanding the Y Combinator

8dcc.github.io

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Understanding the Y Combinator

#51

Post by moi2388 »

ewuhic wrote: post #17

Cool article, BUT! it leaves so many terms unexplained: - What's the distinction between a "parameter`, a "variable", and an "argument"? - What is "body" as in "Body M"? - What's a "bound" variable? - What exactly is a "function call"? - In "... a value that is mapped to itself by the function.", what do "mapped to itself", and, more specifically, "mapped" mean? Would appreciate the answers!

My other comment links to a YouTube series explaining these concepts very clearly, in case you’re interested

Re: Understanding the Y Combinator

#52

Post by marcellus23 »

pdonis wrote: post #46
marcellus23 wrote: post #36

Earlier quoted context omitted.

The article is black on white for me. Are you sure you don't have an extension enabled or something?

As the last sentence of my (2) shows, the article itself is black on white for me too, but the code snippets are white (very faint white that I can't read without serious eyestrain) on black.

The text color in those snippets is pure white, and the background is nearly pure black (#111111). I don't think the problem is with the website.

Re: Understanding the Y Combinator

#53

Post by bschmidt1 »

If Y-Combinator is:

    Y = λf.(λx.f(x x))(λx.f(x x))
And in JavaScript it's:

    const Y = f => (x => f(x(x)))(x => f(x(x)));
Then Silicon Valley's YC must be:

    const YC = startup => (getMoney => startup(getMoney(getMoney)))(getMoney => startup(getMoney(getMoney)));

Re: Understanding the Y Combinator

#54

Post by tkz1312 »

lacker wrote: post #38

It's a shame that I like Y Combinator the organization so much, because I find the y combinator as a programming concept to be aesthetically displeasing. It only makes sense in the untyped lambda calculus, where types are all conflated and errors are forbidden. It relies on the fact that you can take any x and "apply x to itself". These properties are essentially gimmicks of the untyped lambda calculus. It's like the…

I have very similar feelings but in the exact opposite direction :)

The y combinator is a beautiful and satisfying thing that brings much joy when studied, the org is a bunch of cringe silicon valley vc types intent on owning the world…

Re: Understanding the Y Combinator

#55

Post by lispm »

tromp wrote: post #47
lacker wrote: post #38

It's a shame that I like Y Combinator the organization so much, because I find the y combinator as a programming concept to be aesthetically displeasing. It only makes sense in the untyped lambda calculus, where types are all conflated and errors are forbidden. It relies on the fact that you can take any x and "apply x to itself". These properties are essentially gimmicks of the untyped lambda calculus. It's like the…

Between lambda calculus and LISP, I find LISP to be the ugly one, not only because of its far greater complexity, but also its lack of referential transparency. David Turner / Ben Lynn make some good observations about LISP in section "History versus myth" of [1]. If lack of types is what you dislike of the plain lambda calculus, then Haskell is a much better solution than LISP. [1] https://crypto.stanford.edu/~blynn…

Lisp and Haskell are programming languages. Lambda Calculus not.

Re: Understanding the Y Combinator

#56

Post by jvalencia »

tkz1312 wrote: post #54
lacker wrote: post #38

It's a shame that I like Y Combinator the organization so much, because I find the y combinator as a programming concept to be aesthetically displeasing. It only makes sense in the untyped lambda calculus, where types are all conflated and errors are forbidden. It relies on the fact that you can take any x and "apply x to itself". These properties are essentially gimmicks of the untyped lambda calculus. It's like the…

I have very similar feelings but in the exact opposite direction :) The y combinator is a beautiful and satisfying thing that brings much joy when studied, the org is a bunch of cringe silicon valley vc types intent on owning the world…

And yet you're here?

Re: Understanding the Y Combinator

#57

Post by pdonis »

marcellus23 wrote: post #52
pdonis wrote: post #46

Earlier quoted context omitted.

As the last sentence of my (2) shows, the article itself is black on white for me too, but the code snippets are white (very faint white that I can't read without serious eyestrain) on black.

The text color in those snippets is pure white, and the background is nearly pure black (#111111). I don't think the problem is with the website.

> The text color in those snippets is pure white

Including the syntax highlighted parts? I don't think so.

> I don't think the problem is with the website.

I don't think you have fully considered the situation.

Re: Understanding the Y Combinator

#58

Post by cryptonector »

lacker wrote: post #38

It's a shame that I like Y Combinator the organization so much, because I find the y combinator as a programming concept to be aesthetically displeasing. It only makes sense in the untyped lambda calculus, where types are all conflated and errors are forbidden. It relies on the fact that you can take any x and "apply x to itself". These properties are essentially gimmicks of the untyped lambda calculus. It's like the…

> It only makes sense in the untyped lambda calculus,

You can use it in any language that has closures but doesn't have recursion to begin with. Granted, there's no reason to have a language like that, but fixing is a very common idiom in Haskell.

Re: Understanding the Y Combinator

#59

Post by cryptonector »

tromp wrote: post #47
lacker wrote: post #38

It's a shame that I like Y Combinator the organization so much, because I find the y combinator as a programming concept to be aesthetically displeasing. It only makes sense in the untyped lambda calculus, where types are all conflated and errors are forbidden. It relies on the fact that you can take any x and "apply x to itself". These properties are essentially gimmicks of the untyped lambda calculus. It's like the…

Between lambda calculus and LISP, I find LISP to be the ugly one, not only because of its far greater complexity, but also its lack of referential transparency. David Turner / Ben Lynn make some good observations about LISP in section "History versus myth" of [1]. If lack of types is what you dislike of the plain lambda calculus, then Haskell is a much better solution than LISP. [1] https://crypto.stanford.edu/~blynn…

Lambda calculus isn't practical for real-world programming. You have to add various types to make it practical. By then you have a LISP.

Re: Understanding the Y Combinator

#60

Post by kazinator »

cryptonector wrote: post #59
tromp wrote: post #47

Earlier quoted context omitted.

Between lambda calculus and LISP, I find LISP to be the ugly one, not only because of its far greater complexity, but also its lack of referential transparency. David Turner / Ben Lynn make some good observations about LISP in section "History versus myth" of [1]. If lack of types is what you dislike of the plain lambda calculus, then Haskell is a much better solution than LISP. [1] https://crypto.stanford.edu/~blynn…

Lambda calculus isn't practical for real-world programming. You have to add various types to make it practical. By then you have a LISP.

You don't have a Lisp until you add to lambda calculus a representation of its syntax using nested lists of symbols, with APIs to manipulate the lists, a way to intercept and transform the lists that are being processed as code and an eval function.
Post reply on HN