Live data from Hacker News

I no longer understand my PhD dissertation

medium.com

231–240 of 281 posts

Re: I no longer understand my PhD dissertation

#231
post #31
post #18

Earlier quoted context omitted.

> (the one exception is that I always found proving things difficult) Proofs are at the heart of math. Everything else is something different.

Not in the American school system, at least. AFAICT grade school "math education" is mostly about lodging a particular calculation algorithm implementation into students' heads and making them repeatedly run it, on a variety of test inputs. A large majority of Americans will never do a single bit of mathematics in their lives, cradle to grave. To be fair, there are lots of efforts to change it. But (being pretty hars…

When you apply that to proofs its awful. To use a gaming analogy the real world is a sandbox game where you can build it any way you want as long as you follow the rules, but in K-12 school, proofs are either for exact memorization, or crazy contrived things on rails that you're only supposed to solve the one correct way.

Sort of a perl "there is more than one way to do it" vs a python "there should only be one way to do it". Nothing inherently wrong with either other than if you and your educational system philosophically disagree, its going to go extremely badly for you.

Re: I no longer understand my PhD dissertation

#232
post #190

Earlier quoted context omitted.

> Programming has existed for, say, 50-100 years. We have recorded mathematical history going back thousands, with contributions from most of the most brilliant human beings to ever exist. Mathematics with a solid logic foundation has also existed only for the past century, and writing programs is actually equivalent to doing a mathematical proof as some have already pointed out. The actual problem is that when progr…

> writing programs is actually equivalent to doing a mathematical proof Only in the sense that writing in brainfuck is equivalent to writing in Python...

True, but the point is that in principle you can write very detailed, fully formal proofs, in exactly the same manner programs are written. The rest of my comment then discusses why it is not written that way.

Doing formal proofs manually is like writing turing machine instructions. Computer-assisted proving gives you higher level tools, but apparently it is still not powerful enough to be accepted in mainstream. And unlike programming where you get stuck if you haven't invented higher level languages, mathematicians have the widely accepted tool of "it trivially follows". Bourbaki might disagree, though.

Re: I no longer understand my PhD dissertation

#233
post #141
post #14

TLDR: The author independently re-discovered what you may know as Old Code Syndrome. I think that's because mathematical papers place too much value on terseness and abstraction over exposition and intuition. This guy's basically in the position of a fairly new developer who's just been asked to do non-trivial update of his own code for the first time. All those clever one-liners he put into his code made him feel sm…

It would be really nice if all it took to understand difficult mathematics were some easy programming tricks. The problem with looking at old code is you forget what is going on or what the purpose of different components are. The problem with looking at old mathematics is that it is genuinely very difficult to understand. You work very hard to be an expert in a field and get to a level where you can read a cutting-e…

A paper cannot teach a layman everything they need to understand the topic, but there are many papers out there I have difficulty understanding because of how they are written, but when reading them with a companion exposition, I can comprehend. It is a balance of getting one's point across while targeting a wide enough audience.

It is the same with code. No one should be writing production code at the level where any non-programmer fluent in the language of the comment's could understand. But they should be writing it simplified enough so that performance isn't impacted and that anyone who is maintaining the code should be able to understand it without having to spend extreme amounts of time digesting it. And sometimes a key performance boost will turn into a 'here be dragons'.

I do think Mathematicians are optimizing a bit too strongly for similar level peers, but please don't think I'm trying to say the are dumb for doing such.

Re: I no longer understand my PhD dissertation

#234
post #141

Earlier quoted context omitted.

It would be really nice if all it took to understand difficult mathematics were some easy programming tricks. The problem with looking at old code is you forget what is going on or what the purpose of different components are. The problem with looking at old mathematics is that it is genuinely very difficult to understand. You work very hard to be an expert in a field and get to a level where you can read a cutting-e…

It's also the jargon. I remember years ago telling a coworker that I was an ACM member and subscribed to the SIGPLAN proceedings. He looked at me and with all sincerity asked, "You can understand those things??" To which I responded, "About half," but I totally sympathized with his question. Both Math and CS need the reincarnation of Richard Feynman to come and shake things up a bit. There's too much of the 'dazzle t…

>"If you can't explain it simply, you don't understand it well enough." is my new favorite Albert Einstein quote.

Yes and no.

I spend a fair amount of time explaining things to children. Not exactly five year olds, so no ELI5. More like ELI13. But to do this often requires over simplifying points to you either hand wave or or even sometimes given incorrect examples that are 'good enough' at the level that you are aiming at.

For example, consider explaining gravity as mass attracting mass. That is over simplified and breaks down at certain points, but for explaining to a kid why objects fall when you drop them, and even giving an opening to explain things like acceleration of falling objects, it is good enough.

So a better way of saying it is that if you understand both the subject matter and your audience well enough, you will be able to given simple explanations that will increase the audience's understanding.

Re: I no longer understand my PhD dissertation

#235

Earlier quoted context omitted.

I think it's about balancing various things. Having less code is good unless there's a hidden catch you need to be aware of or it takes a few weeks to unravel what the code does. I prefer code that is understandable right away, is consistent and doesn't have any surprises.

A good example is Go. Many have written blogposts describing how great it is that it's such a simple language because the code is easy to read. And I can't deny that. The code is simple to read. But then I read through pages and pages of such code and all with little meaning. Here's a loop, here we check for an error condition, here's another loop, here we check check for another error condition. It makes it harder t…

Yes, Go is a low information density language. Haskell has high information density.

Re: I no longer understand my PhD dissertation

#236

Earlier quoted context omitted.

If I run into that situation, I refactor the code so that I can better understand it the next time. To not do so is to waste all that time you spent understanding it. > It's usually something simple like, "This cast avoids a special case in method X", or along those lines. If I had an issue like that, I'd fix method X to be more accepting of unclean inputs.

The problem is that method X is a remote invocation into another system that has different change-control procedures, a different ticketing system, and a different release schedule.

I'd use a gateway class and intention-revealing method names, even if all that method was doing was casting a value. I'd call it ".edge_case_fix", (but described better than "edge case") and do the same for every weirdness in the external system that requires workarounds.

Re: I no longer understand my PhD dissertation

#237
post #12

All of these arguments are arguments for replacing the mathematics curriculum with video gaming. Games require generalized problem solving (arguably better-generalized than math, and arguably better-transferrable to other domains). Games build character: grit and tenacity, cautious optimism, etc blah blah etc. And games are fun (for many more people than find math fun). Guess math teachers should start learning to pl…

Video games are designed for grinding or following a fixed story, and your creativity is completely limited by the possibilities programmed for you. The exceptions to this (minecrafters designing Turing machines, hacking pokemon) are an insignificant fraction that are entirely discovered and engineered by those who understand mathematics and computer science and apply it to the video game.

Why do you think the kinds of problem solving in video games is "better generalized" than math?

Re: I no longer understand my PhD dissertation

#238
post #138

Earlier quoted context omitted.

Maybe it's because I write in Ruby, and so never have to do any tricky optimizing, but if solving a particular problem starts to run over a half hour, I look to re-architect the project, either by reaching for a gem or telling my boss that X is too hard and we should do Y instead. My patience for going down rabbit holes has mostly gone over the last year. Also, again perhaps because I use Ruby, it never takes me more…

I don't see how Ruby saves you from optimising (to my limited knowledge, it's not exactly a fast language), but I agree with you that naming stuff sensibly and extracting functions (which you can then name sensibly) is most important for maintainability and can make "in-code" comments unnecessary in many cases. However I strive to always document what a function does if its not obvious -- though I'd call that "docume…

> I don't see how Ruby saves you from optimising (to my limited knowledge, it's not exactly a fast language)

That's precisely why you don't optimize. If you find you need fast code, you use a different language. Ruby is the language you use when maintainability and extendability take priority over speed. It's excellent for web development, where any speed improvements you make will ultimately be dwarfed by network latency.

> Example for obvious: Int add(Int x, Int y) in a typed language. Example for not obvious: add(x, y) in an untyped (or "dynamically typed") language (Does it auto-coerce? How? Can it add complex numbers? In my particular representation? ...).

That's a good observation, and it's made me think about how I deal with this in Ruby. First, generally you can tell by looking at a method's code what it's expecting you to pass to it.

Second, you don't generally pass around complex types to library functions, you use basic Ruby value objects like strings, symbols, hashes, and arrays. A gem will often define its own classes, which you might pass objects of around, (money, phone numbers) these will often be the primary focus of the gem, and how to use these objects will be written right there in the documentation. These classes will typically have "parse" functions that will take random input and turn it into a more useful object.

In Ruby, you generally only pass around complex objects in your own code, using JSON or some other format to interact with external systems

Re: I no longer understand my PhD dissertation

#240
post #106

Earlier quoted context omitted.

> there are absolutely times when comments are necessary . I'll have to take your word for it, because I've yet to run into that situation.

When you are using a particular method that is required by the context of your work rather than code you have control over. Perhaps the method name in the framework you are using is non obvious, or there is a bug in the way it works. Sometimes comments are just to save future you some time or help other developers find context. Suffice to say any project of significant complexity will probably require comments at som…

Break the long method up into multiple methods, each implementing a different fix. Bundle these methods up into a gateway class.
Post reply on HN