Why I Don't Love Gödel, Escher, Bach • Hacker News Board

Re: Why I Don't Love Gödel, Escher, Bach

#191

Post by dredmorbius » Thu, Jul 05, 2018, 5:16 PM UTC

prr123 wrote: post #132

jkabrg wrote: post #91

Earlier quoted context omitted.

What does "fulfill himself as a flight" mean? Is the lesson that since professors are "less free" than everyone else, they criticize everyone else out of bitterness? Or is it that since they're so specialized and able to make a living only in their specialty, they don't need to practise good judgement outside their discipline? Is it that they live in an ivory tower and don't know the difference between theory and pra…

From what I got from the essay (it's been a while...), people who chose a "serious" path in life see no value in things that do not contribute to their goal. E.g.: If you focus too much on engineering, you stop being able to see value in other aspect of life, such as philosophy. De Beauvoir describes a couple of states of freedom of mind: 1. Children who believe in what they're told and don't think about their freedo…

I also see an effort-reward dynamic, similar to Dutch disease or resource curse.

The specialised activity provides high reward, the generalised little, or at least less.

Re: Why I Don't Love Gödel, Escher, Bach

#192

Post by rspeer » Thu, Jul 05, 2018, 5:18 PM UTC

stuntkite wrote: post #65

rspeer wrote: post #62

Earlier quoted context omitted.

Wow, I would recommend exactly the opposite. If you wanted a dry statement of Hofstadter's philosophy, you could read I Am A Strange Loop, but GEB is remarkable for its form, including the dialogues.

Eh, worked for me! YMMV. I couldn't do the dialogs until I got through the rest. I also enjoyed IAASL a bit more than I enjoyed GEB. Definitely not saying what helped me figure the book out is what everyone should do.

I guess this just goes to show there's a variety of reasons people enjoy Hofstadter's work.

Hofstadter, introducing IAASL, said something like: "I wrote this book because people got so distracted by the form of GEB that they didn't get the point I was making."

My reaction: "I understood the point, I just didn't care about it as much as everything else that was happening in GEB."

Kind of similar to my appreciation of Bach himself, in fact. The content of Bach's compositions is frequently about praising God, which has no particular relevance to me. But the form and aesthetics of Bach are wonderful.

Re: Why I Don't Love Gödel, Escher, Bach

#193

Post by tptacek » Thu, Jul 05, 2018, 5:19 PM UTC

pvg wrote: post #169

pnathan wrote: post #142

Earlier quoted context omitted.

> plenty of very good arguments can be made you're better off not-reading at least one of them. I'm extremely confused as to why this would be the case for TAOCP. While I wouldn't recommend TAOCP for "just reading", I don't know why it wouldn't be recommended for study. Knuth provides a very interesting approach for algorithms analysis, deep in substance.

Let's say, like many people, you enjoy the occasional article from The Onion . You can very easily continue enjoying them without reading Animal Farm , Gulliver's Travels or the collected works of Aristophanes. TAOCP, to me, is in a similar category - it's worth remembering Knuth essentially carved the field of study out himself. If you need a reference or textbook, there are by now better places to start. If you are…

I agree that nobody needs to read TAOCP (or, really, even any equivalent textbook) to be a good programmer.

I disagree with how you've characterized it. I'm unlikely to ever read all of TAOCP and, yes, the reason for that is that doing so would feel a little bit like a commitment to read the whole OED from cover to cover.

But in fact TAOCP isn't really a reference book and it is pretty rewarding, in a straightforward, professional sense. I dip in and out of it sort of at random and I can think of several times when doing so has made me sharper, or when I directly took something from TAOCP and ended up applying it.

My takeaway from this is that TAOCP is a super weird book, one we can't really put our finger on to characterize.

Re: Why I Don't Love Gödel, Escher, Bach

#194

Post by pvg » Thu, Jul 05, 2018, 5:20 PM UTC

pnathan wrote: post #176

pvg wrote: post #169

Earlier quoted context omitted.

Let's say, like many people, you enjoy the occasional article from The Onion . You can very easily continue enjoying them without reading Animal Farm , Gulliver's Travels or the collected works of Aristophanes. TAOCP, to me, is in a similar category - it's worth remembering Knuth essentially carved the field of study out himself. If you need a reference or textbook, there are by now better places to start. If you are…

I see what you mean. I'll be frank, I think that Knuth's analyses have surprisingly fresh and useful approaches, particularly compared with the other algorithms texts I've read. The usual texts are better at compressed results and a "Straight path" through, but as ways of thinking, I find Knuth more useful to study. I wouldn't recommend TAOCP to anyone not interested in algorithms, mind.

Oh, I'm an unrepentant TAOCP and Knuth fanboy. TAOCP is undoubtedly a Great Work™. I'm just bothered by the notion that someone would feel bad or inadequate for not having read it.

GEB, on the other hand is... I dunno, an ok monitor riser if you don't have anything else handy.

Re: Why I Don't Love Gödel, Escher, Bach

#195

Post by schoen » Thu, Jul 05, 2018, 5:21 PM UTC

core-questions wrote: post #163

kranner wrote: post #118

Earlier quoted context omitted.

Is it such a great thing to be born that we are doing something good for certain pigs by causing them to come into existence?

Is it such a great thing to be born that we are doing something good for our children by causing them to come into existence? I mean, c'mon. The only way for there to be something good, or great, from a first-person experience, is for there to be a first person to actually do the experiencing. Caveat, of course, bringing something into an existence that is only suffering is probably not so great. This is why we need…

David Benatar is the most famous exponent of the opposing view:

https://en.wikipedia.org/wiki/David_Benatar

https://en.wikipedia.org/wiki/Antinatalism

Edit: though several weaker views are more common in animal rights advocacy, for instance that being born in order to be raised for food is not a benefit to an animal, that being born in order to be raised for food in a factory farm is not a benefit to an animal, or that being born is a benefit but that conferring a benefit on an animal doesn't make conferring harms on the same animal legitimate or appropriate even if the benefits and harms are structured as a "package deal".

Re: Why I Don't Love Gödel, Escher, Bach

#196

Post by xrd » Thu, Jul 05, 2018, 5:21 PM UTC

stuntkite wrote: post #6

I'd owned this book for many years and had a similar experience to OP. But one day someone gave me `I am a Strange Loop`, which I started reading and enjoyed way more. After getting in a little bit Hofstadter makes some apologies for GEB saying it was the sum of work of a very young person. I think he was 24? I think it's pretty incredible considering his age. The things that lead him to thinking critically about con…

Terrific comment on your path to getting more from this book. I just purchased IAASL and am going to review the OCW link. This kind of discussion is so valuable in getting through books like GEB which can be very challenging and require starts and stops.

Re: Why I Don't Love Gödel, Escher, Bach

#197

Post by beaconstudios » Thu, Jul 05, 2018, 5:22 PM UTC

chriswarbo wrote: post #174

beaconstudios wrote: post #114

Earlier quoted context omitted.

it's self-evident _at this point in time_, given you could feed such a machine the collatz conjecture as an algorithm and we just don't know if any arbitrary input will halt. I'm not claiming it is self-evident in perpetuity. By bounding problem I guess I mean the mathematical equivalent of knowing it can halt. I'm not a mathematician as I previously stated so I don't know the terminology. I don't think the space I'm…

> My interest is in creating a static analyser based on the set of axioms or deductions that can be derived from that space. From the sound of it, I think this might be a little backwards: axioms and deductions give rise to a space of possible proofs, and those can be used for things like static analysis. One example of going the other way is "reverse mathematics", where we try to find a set of axioms that give rise…

you're right, my phrasing wasn't ideal there. I'll try to clarify:

what I want to do is to create a static analyser based on a set of axioms/deductions that can determine which of the "always halts/does not always halt/don't know" categories a program fits into. (I'm rephrasing the categories because a program like "(x: int) => x == 1 ? halt : loop" fits into the second category).

What I'm wanting to figure out is the mathematical field in which these types of axioms reside. My naive assumption was that computability theory is the answer but in researching the various branches of similar fields it seems to me that there is a lot of crossover and similarities between concepts in different fields. So I wasn't sure if there was a field that covers what I would describe as "given a sequence of transformations of typed values, representing those transformations as relationships between inputs and an output, can we definitively prove that the program halts, or does not always halt".

For example, given the function "f(x: int) => x is even ? f(x + 1) : halt" I can know from looking at it that it will halt on any valid input because for any int x, recursing on x + 1 has to reach a value where x is not even. I just don't know how I would formalise such knowledge into a system that can actually deduce such conclusions as you could clearly change "x is even" to any "x is wholly divisible by " and the conclusion would hold.

Re: Why I Don't Love Gödel, Escher, Bach

#198

Post by chriswarbo » Thu, Jul 05, 2018, 5:27 PM UTC

beaconstudios wrote: post #61

chriswarbo wrote: post #37

Earlier quoted context omitted.

(Caveat: I'm a computer scientist, not a mathematician) The halting problem, and universal computation itself, came directly out of work on incompleteness. Incompleteness is about being unable to prove statements in a particular system; it leaves open the possibility that a more powerful system might be able to prove that statement (but that more powerful system will have its own incompleteness, and so on). Turing go…

the question that fascinates me is - what is the property of a program that makes it undecidable? I've been playing around with the idea of trying to make a program that determines halts/doesn't halt/don't know, given some representation of a program. I'm running into some interesting implications when I incorporate dependent typing, but it feels like there must be something theoretical that's already out there.

> what is the property of a program that makes it undecidable?

It's important to keep in mind that undecidability and the halting problem only apply in general, not for some particular input or program.

With that said, I think it's to do with program length. The Busy Beaver numbers tell us the maximum number of steps a turing machine can take before halting, when given a program of a certain length. No matter how clever we try to make our static analyser, we ultimately have to write it down as a program (e.g. a turing machine tape, or something more sane ;) ) and this will have a particular, finite size. Hence there is an upper bound on the number of steps that any static analyser can take (the Busy Beaver number for its program length), unless it runs forever without giving us an answer.

Consider a particularly simple static analyser: it reads in a program, executes that program for N steps, and checks to see if it halted yet. If it halted, the static analyser halts with the answer "halts"; if it didn't halt, the static analyser halts with the answer "dunno". This static analyser can be improved by using a larger value of N; yet that necessarily requires a longer static analyser program (to contain the larger N value). That's what the Busy Beaver numbers tell us: calculating a number larger than BusyBeaver(X) requires a program more than X bits long; so we can't use a value of N that's larger than the Busy Beaver number of our static analyser's program length. If we want a bigger N, we will eventually need to make our program longer, since that's the only way to increase this bound caused by the Busy Beaver.

Note that there is another way we could "improve" such a static analyser: we could remove the cutoff completely, and just run the given program until it halts. In this case, the static analyser itself may not halt, so we're back to square one ;)

Now consider that there are infinitely many programs we might feed into a static analyser. These input programs can be arbitrarily long (much longer than our static analyser), and hence the limits imposed on them by the Busy Beaver numbers can be arbitrarily higher than the limits of the static analyser. In particular, their control flow can be arbitrarily complex, such that figuring out whether or not it halts can require an arbitrary amount of calculation steps. Since the number of steps any particular static analyser can perform is bounded by its Busy Beaver number, there will be infinitely many programs which that static analyser can't figure out; even though the same algorithm could figure them out, if given a larger limit to work with.

In this sense, we can think of all static analysis algorithms as being like Busy Beaver approximators: they're trying to calculate the largest number they can, in order to reach the number of steps required to analyse whatever program they've been given. They can do this in two ways: by bloating out their codebase to be much bigger than the programs they analyse, or by making their code more complex than the programs they analyse.

From a practical point of view, most human-written programs are incredibly simple and verbose; so these Busy Beaver limits aren't really a problem. Yet they're the reason that certain problems cannot be solved in the general case.

Some nice links:

https://www.scottaaronson.com/writings/bignumbers.html

https://en.wikipedia.org/wiki/Chaitin%27s_constant

https://en.wikipedia.org/wiki/Kolmogorov_complexity#Chaitin%...

Re: Why I Don't Love Gödel, Escher, Bach

#199

Post by pvg » Thu, Jul 05, 2018, 5:27 PM UTC

tptacek wrote: post #193

pvg wrote: post #169

Earlier quoted context omitted.

Let's say, like many people, you enjoy the occasional article from The Onion . You can very easily continue enjoying them without reading Animal Farm , Gulliver's Travels or the collected works of Aristophanes. TAOCP, to me, is in a similar category - it's worth remembering Knuth essentially carved the field of study out himself. If you need a reference or textbook, there are by now better places to start. If you are…

I agree that nobody needs to read TAOCP (or, really, even any equivalent textbook) to be a good programmer. I disagree with how you've characterized it. I'm unlikely to ever read all of TAOCP and, yes, the reason for that is that doing so would feel a little bit like a commitment to read the whole OED from cover to cover. But in fact TAOCP isn't really a reference book and it is pretty rewarding, in a straightforward…

It's written much better than any reference book has any business being written. It's also very much intended to be both a survey and a reference work, among other things. But at this point, we've shaved the yak to a smooth shine and are carefully splitting the yak-hairs one by one. GEB ain't no TAOCP.

Re: Why I Don't Love Gödel, Escher, Bach

#200

Post by cestith » Thu, Jul 05, 2018, 5:29 PM UTC

Personally, I enjoyed the whimsy and the references in GEB. I considered the weak references past the author's knowledge to be a nod and a pointer to go make a bibliographic romp through other material as one wished. It's an inspiration along the discussion of its ideas, but is not complete. That incompleteness may be because it so deeply references itself, hence the book itself being a funny metaphor.

As directly useful reading to get someone more acquainted with a broad discussion of algorithms and logic without textbook depth of individual topics, I'd recommend _The_New_Turing_Omnibus_ by Alexander Dewdney and _The_Advent_of_the_Algorithm_ by David Berlinski. Probably the latter and then the former, actually.

I wouldn't call GEB a bad read. I think because of its high reputation people expect too much from it, like it should be the definitive book of truth about logic and proofs. It's one book, and if one reads it in the light of it being a fun romp through topics that are somehow loosely connected in the vein of James Burke I think it delivers rather well.