Live data from Hacker News

I no longer understand my PhD dissertation

medium.com

201–210 of 281 posts

Re: I no longer understand my PhD dissertation

#201
post #196
post #192

Earlier quoted context omitted.

Sorry, but that is ridiculous. I have recently started working on an existing project which is all new to me. Having to go through git commits looking for relevant comments is just a silly suggestion. Its far more useful when I am browsing through the code, trying to understand it, to see a comment beside the relevant piece of code, not hidden away in git commit messages.

No need to apologize for different opinion. IMHO comments aren't there for newcomers. You are a newcomer for a month or 2. You are a developer for years most often. Besides, how is //Steve in accounting asked me to put this in foobifyTheBaz(bazPtr, foobificationParams); more helpful for newcomers than just foobifyTheBaz(bazPtr, foobificationParams); Comments answering "why" are very important when bugfixing/changing…

> That's the main advantage of commit messages over comments - they are always fresh and encode the exact lines they refer to.

Unless they're something like "fixed indentation".

Re: I no longer understand my PhD dissertation

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

Thing is, I did understand it. Hell, I looked through my notes from maths degree (5 years ago) and guess what - most of it seems like nonsense. The worst bit is that because these were notes to myself - jam packed with comments of "so obviously" followed by a transformation I can make no sense of at all.

It makes me pretty sad to think what a waste of time that learning was. Also the flip side of "hehe - I was well smart" is "shit - I'm now a moron"

Re: I no longer understand my PhD dissertation

#203
post #201
post #196

Earlier quoted context omitted.

No need to apologize for different opinion. IMHO comments aren't there for newcomers. You are a newcomer for a month or 2. You are a developer for years most often. Besides, how is //Steve in accounting asked me to put this in foobifyTheBaz(bazPtr, foobificationParams); more helpful for newcomers than just foobifyTheBaz(bazPtr, foobificationParams); Comments answering "why" are very important when bugfixing/changing…

> That's the main advantage of commit messages over comments - they are always fresh and encode the exact lines they refer to. Unless they're something like "fixed indentation".

In which case it's one click away. And anyway you should enable checkstyle and autoformat on saving files, and you can use "ignore whitespace changes" in git view for legacy code.

Re: I no longer understand my PhD dissertation

#204
post #158
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…

> Do you think perhaps there's a reason why a simple and easy trick like commenting and renaming lemmas has been discovered and solidified as standard practice in programming, but hasn't been adopted in mathematics? Are mathematicians really just SO dumb? No, they aren't, but the example in question would have been easier to understand if he had tried to explain what was going on, instead of just saying "it is trivia…

... especially if code is to be considered in the terms of information theory. Context is important and context can't be encoded without raising the entropy. Also, speech and to a large degree mathematical symbolism are sequential, so multi dimensional problems would have to be broken down into one sequential dimension, raising the entropy exponentially or whatever or loosing information. Can't help it.

Re: I no longer understand my PhD dissertation

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

Ironically my professor advices me during my thesis not to add all of my source code to the appendix. Yay, let's make things not reproducible :D

Re: I no longer understand my PhD dissertation

#206

The author almost realized the much more important conclusion of the fact he lived. He shouldn't conclude the article by asking "what is the purpose of studying maths?" and then giving an three stupid answers. He should have asked: is this actually "knowledge" as they say academia brings to society? Is the money researchers earn being well spent? Did I actually deserve to be remunerated by this piece of work no one u…

Considering that PhDs get paid next to nothing, I actually think they're getting paid pretty adequately.

Nothing would be better, considering this article.

Re: I no longer understand my PhD dissertation

#207

I've been working with Haskell* for a couple of years and it is quite often that I work with code that I don't fully understand. I'll come across a terse bit of code, then carefully take it apart to see what it does (by taking bits and pieces out and giving them names instead of passing in using point-free notation and also adding type annotations). Once I see the whole picture, I make my own change and then carefull…

> If I left this verbose and other bits verbose then it would be hard to see the whole picture. I really can't sympathize with this. How exactly is this helping any one at all, if you have to struggle with it yourself? Is it a bunch of dense monolithic code? Decompose into smaller methods / separate files. Setup your text-editor/IDE in an effective way for quickly navigating across large chunks of related code. Imho…

The way I see it, I have limited capacity to build a mental picture of whatever I am working on. When I'm looking at pages and pages of verbose and repetitive code, it is quite hard. What does this bit do? Just checking the error condition and re-throwing the error. What does that bit do? Same boring stuff. Where is the meat?

When I'm looking at few lines of terse but complicated code, it is easier; it is all meat and little fat. Just enough to make a good steak.

But this only works if I understand the mechanics of that terse code. So when I work on something else for a while and I come back to some code for which I no longer have an accurate mental picture in my brain I need to refresh my memory.

I think mathematics is the same way. Imagine a full A4 page of equations. It is really hard, at least for me, to hold in my brain a mental model of what it all means. Sure, there's a ton of background that I need to be familiar with, but it's not in my mental picture. Imagine this: suppose you wrote rules for how addition works, and then multiplication, and then build it all up so you can do linear algebra. That's too much!

When I advocate terse code I don't mean it in a "here's my obfuscated C code sense". I mean that when I write "f . g . h" there might be more going on here than meets the eye, but as long as you know the rules of what . means in this context, it is super easy to follow.

Re: I no longer understand my PhD dissertation

#208

I've been working with Haskell* for a couple of years and it is quite often that I work with code that I don't fully understand. I'll come across a terse bit of code, then carefully take it apart to see what it does (by taking bits and pieces out and giving them names instead of passing in using point-free notation and also adding type annotations). Once I see the whole picture, I make my own change and then carefull…

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 to see through all that and answer the question "what does this code try to accomplish?". At least for me, the more code there is, the harder it is to see.

Re: I no longer understand my PhD dissertation

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

I think you missed the point of the article, which was that students, parents, standards-setters, educational theorists, and legislators have a distorted idea about what education is for and why certain subjects are taught. We don't teach history so that children can recite the years in which various battles happened. We don't teach algebra in order that everyone in society knows how to factor a simple polynomial.

The author can no longer understand his dissertation, but that doesn't mean he failed, or that the educational system failed by granting him a PhD for the work. Rather, the dissertation was about proving to the system and himself that he had learned how to tackle a complex problem and generate a solution that would pass muster with his academic mentors. In the process he learned many skills indirectly, became a more effective problem-solver in general, and had fun, all of which are far more valuable and far more important than the topic of his dissertation and whether or not he still understands it.

Re: I no longer understand my PhD dissertation

#210
post #196
post #192

Earlier quoted context omitted.

Sorry, but that is ridiculous. I have recently started working on an existing project which is all new to me. Having to go through git commits looking for relevant comments is just a silly suggestion. Its far more useful when I am browsing through the code, trying to understand it, to see a comment beside the relevant piece of code, not hidden away in git commit messages.

No need to apologize for different opinion. IMHO comments aren't there for newcomers. You are a newcomer for a month or 2. You are a developer for years most often. Besides, how is //Steve in accounting asked me to put this in foobifyTheBaz(bazPtr, foobificationParams); more helpful for newcomers than just foobifyTheBaz(bazPtr, foobificationParams); Comments answering "why" are very important when bugfixing/changing…

So what you actually write is

    // We foobify the baz in order to ensure that both
    // sides of the transaction have their grinks froddled.
    // This was a request from Steve in Accounting;
    // see issue #4125 for more details.
so that (1) if you'd otherwise be wondering "wait, what they hell are they doing that for?", you get an answer (and, importantly, some inkling of what would need to have changed for removing the code to be a good idea), (2) there's an indication of where you can find more details (hopefully including the original request from Steve in Accounting), and (3) if the code around here changes, you can still tell that the relevant bit is the foobification of the baz.

I strongly approve of putting relevant info in your VCS commits too, of course. But, e.g., if someone changes the indentation around there then your git blame will show only the most recent change, which isn't the one you want, whereas the comment will hopefully survive intact.

Post reply on HN