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 smart and got the job done at the time. But he's now beginning to realize that if he keeps doing that, he's going to be cursed by his future self when he pulls up the code a few months later (never mind five years!) and has zero memory of how it actually works.

I'm not intending to disparage the author; I've been there, and if you've been a software developer for a while you've likely been there too.

Any decent programmer with enough experience will tell you the fix is to add some comments (more expository text than "it is obvious that..." or "the reader will quickly see..."), unit tests (concrete examples of abstract concepts), give variables and procedures descriptive names (The Wave Decomposition Lemma instead of Lemma 4.16), etc.

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-edge research paper. Then if you let that knowledge atrophy, you won't be able to understand it without a lot of re-learning when you look at it again.

Unfortunately cute tricks like comments and concrete examples won't save you here (if concrete examples even exist -- oftentimes their constructions are so convoluted the abstract theorem is far easier to understand, and often times they are misleading. The theorem covers all cases, but all of the easily understandable concrete examples are completely trivial and don't require the theorem at all.)

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. 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?

The answer is those tricks just aren't good enough. Mathematicians do exposition. They do plenty of explaining. Any textbook and even many research papers spend a huge amount of time explaining what is going on as clearly as is possible. As it turns out the explanation helps, but the material is just plain hard.

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 programming you are talking to computers, so you have to lay out each step, or the computer will not know what to do. Sure you can use libraries to do very complex things all at once, but then that's because those libraries have already laid out the steps.

But when doing mathematics you are talking to humans and you often skip steps in a very liberal way. There is indeed a library of theorems that is written down, but there is also an unwritten library of "it trivially follows", which, if a mathematician is asked to actually write it down, might feel humiliated.

When you think that there is something so trivial that computers must be able to do, you still have to find or invent a library for that. When you think there is something in mathematics so trivial that it must be true, you just need to convince your audience.

One day all mathematical papers will come with a formal proof, but that day has not yet arrived.

Formal proofs do nothing to help understand the mathematics, all they do is help to check for errors in logic -- have you ever read a formal proof? They are leagues more obtuse and difficult to understand than any piece of mathematics from any field.

A program is technically truth-value equivalent to doing a proof, but the resulting document/piece of text are MILES apart. The proof is an explanation in plain language to others who understand the topic why something is true. The formal proof is a sequence of opaque inference rules that the computer promises is equivalent to a real proof.

It's the difference between understanding a formula and plugging it into your calculator. The calculator is more likely to compute correctly, but it gives you no help when it comes to actually understanding mathematics.

Mathematicians as a community completely reject the notion of using formal proofs (while sometimes begrudgingly accepting they may be useful to check our work) because they completely miss the point of what we are actually doing.

Only in the sense that writing in brainfuck is equivalent to writing in Python...

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.

Users of high-level languages, typically do not think about what the compiler is doing, and if in fact they do not know the compiler action--often the only way to find out is by reading the compilers source code.

This is akin to looking a math paper seeing "it trivially follows..." and your only recourse to find out why it so trivially follows is to get a mathematics degree.

With programming the information is always there. If you don't understand a higher level language but do understand the language in which the compiler is implemented, you can always read the compiler.

The "it trivially follows", the information is simply missing. Gaining a mathematics degree will often give you the intellectual power of finding the missing pieces yourself, but the only sure way is to ask the authors themselves.

Getting a math degree just to be able to fill in the gaps created where 'it trivially follows' is equivalent to being required to memorize the API for a framework because clearly defined documentation is hidden behind a paywall.

so called 'intellectual power' has little to do with it. What you're describing is familiarity with navigating a minefield of poorly structured information and tapping a academia (ie at a very high cost of entry) for 'special access' to resources that bridge the gaps.

Of software development suffered from the same informational constraints and lack of innovation, we'd still be playing pong.

To be cynical about it.

I guess that's not much different from most fields' use of specialized vocabulary, etc. There are many informal methods of dissuading people from competing in your own little corner of the labor market.

Hmm you are from US aren't you? :)

> Only in the sense that writing in brainfuck is equivalent to writing in Python...

Actually, in the very concrete sense that a program is a proof for the forumala that is equivalent to its type[0].

[0] https://en.wikipedia.org/wiki/Curry–Howard_correspondence

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 trivial that this or that follows". I think the comparison with "old code syndrome" is pretty much spot on, to be honest.

http://research.microsoft.com/en-us/um/people/lamport/pubs/l...

As far as I can tell, nobody has really adopted any of his proposals yet, and most papers continue to be written in pseudo-prose. Remember, mathematics used to be written in full prose (e.g. "the square of the hypotenuse is equal to the sum of the squares of the other two sides") and it took hundreds of years for us to realise that "x^2 + y^2 = z^2" was a better notation.

While mathematics may be "genuinely very difficult to understand", so is any complex piece of software. Software engineering techniques might be useful to mathematicians, even if they are all new-fangled and modern.

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 them with bullshit' going on. It's no wonder that it takes so long for basic research to see application in real scenarios. You people bury your research under layers of obfuscation about half the time. Does it really help anybody to do that? Why do you do that?

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

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"

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.

It’s also one of his more moronic quotes. Certainly on a very abstract, dumbed-down level everything can be explained simply; sure, if you cannot give your parents a rough idea what you’re doing, you might want to look into more examples. But there are plenty of things which require a very extensive basis to be understood thoroughly.

For example, it is very easy to summarise what a (mathematical) group is and for anyone with a basic understanding of abstract maths, it will be understandable. It’s also very simple to find some examples (integers with addition, ℝ/{0} with multiplication etc.) which might be understandable by laypeople, but you will either confuse the latter or only give examples and not the actually important content.

Further, when you have “simply explained” what a group is, can you go on and equally “simply explain“ what a the fundamental representation is and how irreducible representations come about? You just need a certain level of knowledge (e.g., linear algebra) already and not every paper can include a full introduction into representation theory.

Then why is paper still the overwhelmingly preferred medium?

Using hypertext it would be trivial to link to an external source describing the specific concept used from linear algebra.

Not providing supporting links is only good for an audience that holds the entirety of mathematical knowledge in their heads (ie mathematicians in academia).

The rest of the world, incl those who have since moved on like the author, don't fit into that category.

Therefore, the work can only be accurately read and understood by the tiny minority of specialists capable of decoding the intent of the work.

Limited reach = limited value to society.

Is the intent of a PHD really to advance the field of mathematics? Or is it just another 'measuring stick' for individuals to prove to others how 'smart' they are?

E.g., encapsulation - given a theorem with a highly technical proof, but ideas from the proof are not super important, hide the proof in an appendix. This is directly analogous to private functions which are only used to power a public one.

Naming lemmas is also helpful, although not sufficient.

Mathematicians aren't dumb. But they do have a set of traditions and a rhetorical style which is often blindly copied. Also, most mathematicians haven't been exposed to good software engineering practices - consider how few use git and instead just email around "paper_v3_chris_edits.tex". Having worked in both the math world and the CS world, math folks can learn quite a bit from software.

(And vice versa - e.g., I just wrote a blog post about how some abstract math solved a real software engineering problem for me: http://engineering.wingify.com/posts/Free-objects/ )

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.

Programming and math _is_ essentially the same (Curry Howard isomorphism) and the problems are indeed equally complex.

The difference is that programming is driven on economical terms, hence agility, flexibility, etc. has been developed.

Mathematics is driven in the university sphere, where mostly intrinsic motivation drives. Not many mathematics professors have the urge to sit down and learn scrum, read manifests of coding practice etc.

The math culture will eventually see itself be forced to go these ways to keep up.

Also, while programming, you can design your functions and their interfaces before writing them down. In maths, that's impossible: you're constrained by what can/cannot be done.

Scrum or coding practice doesn't apply here. Maths don't have to "keep up", they're already way ahead of their applications. It also doesn't need to be fast or flexible, just rigorous. And while motivation and intuition helps (specially when learning) some concepts cannot be motivated or given an intuition, and even in that case you still have to learn the small details and formalizations.

Have you forgotten the pains that you went through trying to understand the difference between values, pointers and references, lexical and dynamic scoping, static and dynamic typing, and the like? Can you see them with your eyes? Have you ever tried fully explaining any of those to a non-CS major in half an hour? :)

Abstractness is pretty subjective. For non-programmers, even the idea of CPU and memory can be abstract. And it doesn't help to open up a computer and point to the hardware; that is like claiming a mathematical paper is not abstract by pointing to the very concrete paper and ink that embodies it.

Some concepts in mathematics are way above the abstraction level that you mention. For example, the projective plane, or nowhere-differentiable functions, or geometry in higher dimensions; those are concepts that not only do not have any physical equivalent, but are also very difficult to grasp and imagine in your head.

Would it actually work? I honestly don't know, but I'd seriously love to try it.

Math _indeed_ have the idea about interfaces and implementations. They are called something different (exitensisal types from a PL point of view).

I will recommend you to look into type theory, in particular the book "types and programming languages" provides a very good introduction.

In CS we have two areas that make it completely clear that math and CS are coupled, that is complexity theory and programming languages. After having taken a course in each, and pondering a bit, it should indeed be possible to see the that they are the same.

I'm not doubting you, I'm no mathematician, but my understanding is that it is only positive, as it improves the legibility of the text.

If it only happened on mathematical papers... It is all over the place, in books, classes, etc. Few professors tell you what are they doing and why; they just throw formulas, theorems and symbols at you. Intuition is not given its necessary importance, first because it's hard to grasp some concepts, and second because sometimes there's no easy intution behind them unless you have deeper knowledge in the subject.

Regarding "unit tests", or descriptive names... That's very difficult once you get into advanced math. Examples are probably going to be trivial or too contrived to be useful. And if you have to give a name to a theorem or lemma, you'll end up describing its full contents.

We did a bunch of linear regression(with maple?) i believe. And some manual differential equations. I was one of the best in that class, but when I asked what we need this stuff for the other people in the class looked at me and said the following:

"if you ask this question you're in the wrong class"

I went on to study engineering, and i guarantee you the other two still don't know what that stuff is good for. They learned the formulas by heart and then went on with their lives.

I mean it was fun for me, it was basically a coding exercise. And I was happy because I was faster than everyone else, but I didn't get why we were doing it.

The same actually bothered my about the studies. Just one example: folding is a fairly easy concept. But for some reason they first want to drill it into your head, you learn a bunch of techniques and then if you're lucky and you stick with it, eventually it clicks and you'll realize why in a completely unrelated class.

Why can't we just provide a simple real life example first and then go on explaining the details?

Aren't things easier to grasp when you can have a real understanding/connection to it? Isn't that precisely why people that learn coding at home tend to be better than those that just studied it, because they were told it's a solid profession to study?

I think with a good example and visual representation you can probably teach most of the stuff that's taught in Uni to young kids. But then you would be forced to admit that you wasted a lot of time during your own life, who'd want to admit such a thing.

That's a very good approach, which I try to follow in all my writings. Basically, I imagine a reader that is generally uninterested in the material, so the first thing to do is to "pitch" the mathematical concept using a simple example, or just say why the concept is useful. In the remainder of the lesson, I assume the reader might lose interest and stop reading at any point, so this is why I put the most valuable content first (definitions and formulas), followed by explanations, and finally a general discussion about how the material relates to other concepts.

I am always so disappointed when I hear people express this. Being able to place an effort in a broader context is so helpful in being able to approach the work well. A few teachers in the Literature department in high school had the same attitude and it was incredibly demoralizing and left me kinda directionless in their classes. I wish things like https://youtube.com/watch?v=suf0Jdt2Hpo had existed back then to give me some idea of what useful and interesting literary analysis looked like and could do.

I used to know a math lecturer, and his attitude was very much that it was his job to throw proofs at his students, and the bright ones would put the rest together for themselves.

He wasn't even remotely interested in the less bright ones, and certainly not in presenting the material in a way that made it easier for them to follow.

Digital has real potential here, because you can build animations and virtual math labs to explore concepts and give them a context, and suddenly math becomes practical and not just an excuse for wrangling abstract symbols for the sake of it.

It'd be cool if, once you start your major, there was basically an overview class explaining why each of your courses is important and what concepts (at a high level) you should be grokking with each course and semester; basically some context to frame your learnings.

I learned trig and geometry from my shop and programming courses... Trying to do graphics in QBasic and determine lengths and angles in carpentry gives concrete examples. It's not as though most math sprang spontaneously from pure thought-stuff - at some point, architects, inventors, astronomers and others in concrete endeavors discovered these rules.

It's not difficult to explain the first few topics on calculus in terms of distance, speed and acceleration. Other examples I remember were washing lines (a catenary), the path traced by a stream train's wheels and rocketry.

My teacher in England always had a real world example, but students with the other teacher didn't.

But sometimes there is no real life example. Fundamentally, math is abstract. Yes, mercifully, its models often have analogues in nature, making its purpose utilitarian and intuitive. But sometimes no analogue exists. As in much of modern physics, in math, often you have only abstraction.

I think that's why math is difficult to learn. Without compelling illustrations based in the physical world the student must follow the concepts and proofs using the rigor of math's legal transformations, fortified only by the faith that these formalisms will sustain truth. But too often the practitioner must remain oblivious to the utility and implications of both the end and the means.

The intuition for the person who discovered this lemma, clearly envisioned the underlying process as a device pumping out new strings belonging to the language.

Education by satire / humor is a sadly under-explored field. "A satirical approach to linear algebra"... not sure if I'd kickstart support that, or turn around and start running. In the eternal spirit of "anything that sounds interesting and impossible is a great startup opportunity" I propose that someone ... etc etc, you know.

"Misspell Chomsky's name as Chompsky, and I'll give you a pass; Misspell Turing as Turning or something? I'll flunk you"

That's not true. Proofs are a core process of all mathematics. Writing proofs can take up a majority of your time in some classes.

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.

Now, if I have that problem, it's now two problems. The original problem, and the readability problem. The readability problem is solved first, and the original problem can only be solved afterward.

I don't see comments helping me, I could spend the time better by making better method names, better local variable names, extracting methods, ensuring that lines do not run off of the screen.

Maintaining my old code got significantly easier after I started doing this.

Today I put in a log statement to see why the code deletes data from the database if there is no new temperature data for the time period. The cron job has been running all day and so far every time it attempts to delete the data, there is no data to delete.

Another line runs a different script if the time is 15:00. No idea what is magical about that time. I added a bunch of log statements to see what happens at 15:00 that is different from every other hour of the day. So far I have no clue.

I’m sure the original coder had a reason for inserting these bits of code, but damned if I know what it was.

There are dozens of instances like this in the code. A one line comment would have saved me hours of work and the client several thousand dollars.

I don't know why people say this type of thing, as if there's some choice you have to make between good names and comments. You can have both, and there are absolutely times when comments are necessary. Too many comments may be a "smell", but code that doesn't require any comments at all is very unlikely.

I think it would really help to have a language, that differs between the original methods raw body (displaying the pure intentions) and blends out the various filters and catchy expeption handling.

Such a function with catchy names, could be allmost as good as a coment- and is usually there. Coments can be useless too /* Function taking these arguments, returning this type */

Comments are for why.

Sometimes the why is obvious, then you don't need a comment. The rest of the time, add that comment. Even if it's something like "Steve in accounting asked me to put this in."

It's generally true that the code expresses the what, but it's also true that it can take the reader time to discern. A simple comment here and there can be a shortcut to this discernment which, over thousands of lines of code can save serious time.

And when you change the line because Tom asked you to change it again - you don't need to remember to remove the comment about Steve.

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.

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);

    foobifyTheBaz(bazPtr, foobificationParams);

And you don't look for git commits. You enable git blame annotations in your IDE and hover over the relevant lines to immediately know who, when, and why changed that particular line. That's why commit messages are as important as good naming IMHO.

By the way, when you have code like:

    //Steve in accounting asked me to put this in
    foobifyTheBaz(bazPtr, foobificationParams);
    barifyTheBaz(bazPtr, barificationParams);
    if (mu(bazPtr)) {
        rebazifyTheBaz(bazPtr);
    }

    // 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.

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.

I envountered it a few times and it was never a big problem.

The problem with comments in the code is - they have to be maintained "by hand", and they are often separated from the context after a few independent changes.

When you change a function called inside the foobify function because of another change request you will most probably forget to check all the calling places all the way up the callstack and fix the comments refering to foobify function. And then comments may start to lie.

I encountered lying comments a few times and it usually is a big problem. I started to ignore comments when debugging, and I'm not the only programmer that I know that does that.

I do think there is a place for comments in the code, for example for documentation of some API, but IMHO commit messages are the perfect place for explaining reasons of particular change, and I prefer not to repeat that.

http://cdn.meme.am/instances2/500x/4310914.jpg

Unless they're something like "fixed indentation".

Which way does the returned force vector point? Towards mass A, or towards mass B?

2) Vector3 UnitVectorWithDirection(Vector3 originalVector);

What does this function do when the magnitude (length) of originalVector is zero?

3) float ArcTan(float x);

What is the allowable range of values for x?

...

1) Vector3 calcNewtonianGravityToB(float massA, Vector3 positionA, float massB, Vector3 positionB);

2) Vector3 unitVectorWithDirection(Vector3 originalVector_mayBeZero); vs. Vector3 unitVectorWithDirection(Vector3 originalVector_throwsIfZero); (if in a supporting language, throws declaration would also clarify).

3) float ArcTan(float x_throwsIfZero); or float ArcTan(float x_returnsNaNIfNot0to1), etc.

This assumes:

(a) You're not working in a language or environment that supports range constraints in the first place, cause if you are then that's ideal.

(b) You're working on personal code or a small team. If you're writing code for public consumption you have no choice but to add detailed API documentation if you want to be successful, even if it's not DRY.

Certainly calling things like "x_returnsNaNIfNot0to1" works, but I find it a bit ugly and it gets complicated if you have multiple or more complex constraints.

This is where languages with docstrings are nice. In Python all I would do is add a """ comment describing the inputs and the return values.

You then have a) a comment describing the code; and b) documentation that's standard so people can pull it up with pydoc or ? in Ipython. When I'm working in Jupyter, I often hit shift-tab to check what a function is expecting.

For one, handling rotation sign (is positive clockwise or counter-clockwise), left-handed vs. right-handed coordinates, etc. through c++ template parameters.

Ideally, you'd have some tests as well that would test those kind of corner-cases and illustrate failure cases and expected outputs.

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 some point. That complexity can come from the code, the task, the stakeholders or the dependencies.

Unless you are happy with a method name like getSimpleProductInstanceThroughCoreFactoryBecause ModuleRewriteWillBreakCompatibilityWithSecurity PatchSUPEE5523 ()

In that case I guess you're right.

Edited to stop the method name stretching HN layout.

There were no fixes performed in the method, the method just gets a product instance from a factory. The comment gives reasons for why it was using a core factory directly instead of using the automatic object resolution mechamisms.

The real method name was getProductInstanceFromCoreFactory. Still long, still clear as to what it is doing. But making the context clear would be more code than it is worth.

Avoiding comments by writing clearer code isn't a bad habit, but my point is that they are very useful to provide context for something that getting context for would otherwise be erroneous or cumbersome to implement.

> 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.

I can't tell you how many times I've been reading a comment that runs quite contrary to what the code really does. You then end up reading the code to reason about it anyway, paying two taxes. After too many of those experiences, you just end up going straight to the code as the source of ground-truth.

This all depends on the readability of the code / and how soon these comments get out of sync. Maybe my experience is atypical, but I doubt it.

This way, I can run git blame (or the equivalent VCS command) on the file and get a reasonable set of comments that usually match up with the code.

I certainly am.

Also, again perhaps because I use Ruby, it never takes me more than a few seconds to name something. If it does, then it's a code smell and I go looking for the missing class.

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? ...).

Someone mentioned that sometimes comments are useful e.g. to document a quirk/bug in library function you call, and I have some examples of that in my own code. But most often you should be able to rectify that by wrapping said function in your own one that omits the problem.

If a function seems impossible to give it a sensible name that isn't ridiculously long, split it up. The more clear code of the individual parts and how they are combined should give a hint of what is actually computed here. Maybe it's a new concept in your business logic, in which case providing a clear and exact definition makes sense anyway (put it into the appropriate place in your documentation). This whole procedure can take a significant amount of time, but it will be worth it in maintainance!

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

Ah, now I get you :)

> First, generally you can tell by looking at a method's code what it's expecting you to pass to it.

Here we might differ, I would always prefer to state clearly in the function doc what types of parameter values are allowed. For example, even if you have a really simple little wrapper in javascript:

  function log(x) {console.log(x);} 

  /** 
   * Logs x to console.
   * @param x a value of a primitive type (other types are not guaranteed to be logged in a readable manner). 
   */
  function log(x) {console.log(x);}

Yes exactly, it will be documented as any public API should be. I have no problems using opaque types. But a function call(x) which expects x to be some object representation and not any old string (for which the library has constructors, e.g. PhoneNumber(string)) should surely document this, no?

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" -Brian W. Kernighan

I read a book by Brian Kernighan a few years back, "The Elements of Programming Style" and for me it has so much good advice. The book may not be as relevant in the days of Ruby, C99 and the like, but valuable advice nevertheless.

I wonder if reading the literature (countless books written by the early adopters and renowned engineers) would mould the programmers to do things differently. For instance, reading "JavaScript: The Good Parts" completely changed the perspective with which I look at the language. It made me fall in love with it.

When you design anything - a rocket engine, an immunoassay product, whatever - it should be part of the work to document the assumptions, calculations, and rationale for the design to a degree that somebody skilled in the art could follow your work when you're gone.

The abstraction is necessary: you cannot do algebraic geometry with varieties alone. But while the core of the subject is a multithousand page jewel of abstraction, Vakil is a perfectly readable, example filled introduction to algebraic geometry, covering most of the contents of the glory that is EGA.

Only the rare lemmas are intrinsically interesting. Most often it's the theorems that are worth knowing as steps on the path to understanding something much more. Those lemmas that get used again and again are named, often descriptively.

I sort of have a conversation with myself as I document code where I tell myself why something needs to be done and, if necessary, how. As a result of this anyone can go into my code for any project at any time and find their way around. In fact, they don't even have to be domain experts to understand domain-specific code because I often take the time to document such thing pretending I am just learning about it (to a point).

Over the years, I've stopped and started about 3 pretty major personal projects and through that I progressively got better at writing and documenting code in a way that make it easy to pick back up after a long break.

Just to briefly establish that I have some qualifications here, while I do not have a PhD and am not nor have I ever been a professional mathematician, I did have a lot of success in mathematics as an undergraduate, publishing research in the intersection of algebraic topology, differential geometry, and analysis with a professor at an Ivy League university.

I was myself a practitioner of the school of It Is Clear That..., until I realized that my mentor for the above research, a famed professor and former Putnam Fellow who even has inequalities named after himself, didn't follow some of the stuff I'd written in some notes I showed him. And if he didn't follow it, then I knew that meant I probably didn't understand it as well as I thought I did. It wasn't a big surprise to me then that, after a few weeks of effort, I was completely unable to take my approach further. His approach, of course, worked.

He represents one of few mathematicians I've personally known who emphasized clarity just as much as correctness and technical depth, and he had no desire to appear smart. But at this point in time he already had his career mostly behind him. There was nobody left for him to impress.

Part of the problem, ultimately, is that phrases like "it is trivial that..." do serve a purpose when used appropriately. As a result, it's hard to argue that they should categorically be excluded from mathematical writing. But that then opens them up to abuse, and in a culture so obsessed with appearing smart, that abuse can be quite extreme sometimes. Because instances of abuse are often motivated out of appearing smart rather than legitimate economical concerns of space, bringing up the issue with the author amounts to a moral accusation against them, which makes their defense of the phrases even more impassioned. They're not going to admit that they're just trying to puff up their ego.

The worst part is that, in some circles, if you criticize this sort of writing you'll just be greeted by a bunch of people who are proud to exclaim that, of course, they are smart enough to fill in the blanks, and if only you were too then you surely couldn't possibly still have any objections to it.

For me, transitioning from mathematics to software development was a huge breath of fresh air, as the culture is (generally) the exact opposite. Nearly every good programmer I've met has valued clarity and maintainability equally alongside correctness.

http://github.com/EGreg/Platform

I kind of developed that style organically as I went along, in both PHP and JS.

I tried to make the output readable as well. I've seen many frameworks output a bunch of gibberish, but with today's bandwidth it's not such a big deal to add a little bit of whitespace and make everything readable. Here's a fairly complex application, you can view the source of any page:

http://qbixstaging.com/Groups/

Mostly, code style is about consistency. You can have infinite arguments about whether opening braces should go on the same line as the operator/function, but at the end of the day as long as you stay consistent it doesn't really matter.

Here are some consistency issues I found. Your function declarations put the opening brace on the following line, but flow controls open on the same lines. Ex: https://github.com/EGreg/Platform/blob/master/platform/plugi...

In the same vein, commenting seems inconsistent - this file's docblock opens with /* */ style comments, but then you switch to // style. Ex: https://github.com/EGreg/Platform/blob/master/platform/Q.php...

Further down, you use two styles of if(), one with braces and one without, right next to each other: https://github.com/EGreg/Platform/blob/master/platform/Q.php...

I much prefer 2 space indents to tabs. To me, it's much more readable. I noticed your HTML output is also tabbed, which (arguably) needlessly increases the horizontal width you need to see a page of code, especially with modern deeply-nested structures.

Overall the project looks well thought out, and you may have valid reasons for any/all of the above. Just throwing in my initial reactions as a project outsider.

Also, dunno if you know about PSR, but here it's a good starting point that many people (potential contributors) are familiar with: http://www.php-fig.org/psr/psr-2/

I guess I wanted to know more feedback about the design and architecture of the system, the names for things etc.

Any special rationale behind that approach?

fairly new has nothing to do with it. I'm struggling to read my own code since 1998 and constantly in battle with myself to strategically place comments at the right places. I doubt that I'll ever correctly estimate my own ability to comprehend my sh1t no matter how many years of experience I have. In fact it seems to have gotten worse with experience. The more I know the less I can trust myself. Not sure if I'm alone with that.

Sorry, but if I was this guy's advisor, I'd keep his ass in school until he took away his pretentious "it is obvious from ___ that"'s.

Ph. D education just isn't what it used to be.

Some bits of the DMD compiler back end go back 32, 33 years!

It's just a different kind of "brick in the wall" - only the diamonds in the rough can turn out to be hugely important for something else in the future.

In reality, chances are that most research won't lead to anything significant - but the 1% that does will have outsized impact that will more than pay for the rest. And we don't know which 1% this will be in advance.

Although there have been a few Fouriers across history, the most compelling brilliant scientists had one foot in applied science working on theory in the spare time. Euler, Gauss, Faraday, Langmuir. Most of the best basic science had goals "to explain something pressing" (which is not the same as "do something because there will be no payoff") anyways, like Planck, Einstein, Peter Mitchell.

There's something to be gained about cutting your teeth on problems with results, instead of just lollygagging about in theoryland.

Feynman talked about this in an exercise where he described the motion of spinning discs - a very "applied" problem, and remarked that later those insights proved useful in a separate, unrelated problem.

I often see technology growing in a "staircase" fashion. Things plateau, and then there's a period of many small 'chink in the armor' improvements... and then one of those ideas inspires something that floods into a whole new area.

Sometimes it takes a lot of smart brains throwing time at 'useless' junk before that insane theory is found. Othertimes we just await an Einstein-like brain to come on the scene and activate new stuff.

Math was always extremely easy for me growing up. Up through my first differential equations class I found almost everything trivial to learn (the one exception is that I always found proving things difficult).

I made the mistake of minoring in math and that slowly killed my enjoyment of it. Once I got to differential geometry and advanced matrix theory it all just became too abstract and I just wanted to get away from it.

For several years after college I would routinely pull my advanced calculus text out and do problems "for fun". After a while I stopped doing that. Within a few years of no longer being exposed to math, I found it all incredibly foreign and challenging, to the point where I would say I have a bit of an aversion/phobia to it.

I'm trying to reverse that now by tackling a topic I'm interested in but have previously avoided due to the math-heavy nature of it - type theory.

Hopefully I can find the joy in math again through this.

I think my point is that you can lose competence in math very very quickly through lack of constant exposure.

The same is probably true of programming but I hope to never end up in that position.

Proofs are at the heart of math. Everything else is something different.

To be fair, there are lots of efforts to change it. But (being pretty harsh here) a significant number of math teachers really don't have the ability to understand math themselves, let alone teach it.

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.

“Proofs are to mathematics what spelling (or even calligraphy) is to poetry. Mathematical works do consist of proofs, just as poems do consist of characters.”

Arts -> Social Sciences -> Life Sciences -> Physical Sciences -> Mathematics -> Arts

Mathematics was/is a very creative process for me.

[1]: http://mysite.science.uottawa.ca/mnewman/LockhartsLament.pdf

Mankind hasn't yet figured out a good way to teach the first Differential Equations course.

The first serious Calculus course introduces some level of rigor and formalism, but this alone is not sufficient for Diff Eqs. And the DE courses are typically leaning towards applications, so they tend to succumb to the "fiddle these dx's and dy's around like it's magic, in the end it might work out" approach.

The business is well founded, which you will discover later. But no one has figured out how to massage that into the first course.

At the end I'd emerge with a bunch of photos of whiteboards with clear intermediate steps, and then I'd write it up as a short report in LaTeX. Of course, as the report turned into a paper, I took out all the useful 'trivial' steps - which always feels a bit wrong. I think it's also useful at this stage to drop everything for a month or two and come back and see if you still understand what you wrote.

I think the "deep dive", putting prolonged effort in, and writing it up are all key aspects.

With the semester system I had plenty of time to read the material and really explore the mathematics behind what I was learning. With the quarter system I was so busy running around and catching up in different classes that I never really had the time available to sit down and do that. It sucked. I think the quarter system kind of 'beat' the interest out of me because now it is hard to get back into that state of mind.

semester > quarter :(

Fast forward to the real world, one of my biggest challenges is helping people figure out how to get from A-Z. A is obvious to me. Z is obvious to me (although I'm probably wrong as much as I'm right), but getting someone to understand my reasoning is almost impossible.

It isn't the answer that I seek in doing this; it's the desire to know why the answer is what it is. I think I have become more interested in learning far after graduating from university.

It's probably because most of your problem solving knowledge is your own invention. Whereas math and programming is your own invention if you solve all the problems by yourself, if you code everything from the start. This gives you the understanding of the problems, and the reasoning/tools to solve it.

I've been dropping in and out of problem solving fields through the years, and I've noticed that my knowledge practically disappears, but my problem solvings skills can adapt to any framework (mathematics, physics, programming) it just takes a little bit of time to re/learn the terminology.

This is not that important in my opinion. If you're lacking exposure, it must be because you don't apply math every day, and it won't be a big deal. If you apply math every day? Then you will quickly catch up with whatever field you're using.

If you're in pure math, then none of that matters as well, only proofs do. And lack of exposure will often not harm any of the tricks you learned while constructing/understanding them.

Not sure if related to your username, but I have a book on it (that was recommended to me here, in fact) on this topic, which I was curious about due to its implications in the programming field

Same here and I have developed a kind of a complex around it. I used to spend hours practicing proofs just so nobody comes to know that I'm terrible at them. I used to find numerical proofs to problems that had simple general proofs.

However, looking at the other replies it seems we both haven't the faintest idea what Math is ;)

More generally, in the very excellent book The Sense of Style: The Thinking Person's Guide to Writing in the 21st Century,[1] author and researcher Steven Pinker makes the point that the hardest thing for any writer to do is to avoid the "curse of knowledge," assuming that readers know what you know as they read your writing. It's HARD to write about something you know well without skipping lots of steps in reasoning and details of the topic that are unknown to most of your readers. This is one of the best reasons for any writer to submit manuscripts to an editor (or a set of friends, as Paul Graham does) before publishing.

And, yes, if you think what I wrote above is unclear, as I fear it is, please let me know what's confusing about what I wrote. I'd be glad to hear your suggestions of how to make my main point more clear. I'm trying to say that anyone who writes anything has to put extra effort into making his point clear.

[1] http://www.amazon.com/gp/product/B00INIYG74/

>We miss the mark by several major grades of expertise. Aiming for outside academics gets you an article that will be popular among specialists in your field. Aiming at grade school (admittedly, naively so) will hit undergraduates. This is not because your audience is more stupid than you think, but because your words are far less helpful than you think. You're way way overshooting the target. Aim several major gradations lower, and you may hit your mark.

This phenomenon has a name, the Illusion of Transparency: http://lesswrong.com/lw/ke/illusion_of_transparency_why_no_o...

Also see some of the other posts there on the issue, it's quite interesting.

I think doing maths would be better if it was done interactively with software. If equations were code then you could blow it up and look into fine details and then shrink it to a terse form while software keeps track of the transformations to make sure what you write is equivalent. Maybe it's time to add a laptop to that paper pad?

* not arguing anything language specific here except that Haskell makes use of variety of notations that makes the code shorter and more like mahts. More so than most languages.

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 there is a world of difference between terseness that helps readability and code re-factoring vs. terseness that makes you want to bang your head against the monitor.

That said I think the requirements, or say qualities which define good code and good dissertation's are quite different. Code needs to be maintained, refactored and altered throughout it's lifetime, a dissertation might only need to be built up and understood once to prove a particular result which can be re-used after that.

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.

[1] https://coq.inria.fr/

I prefer code that is understandable right away, is consistent and doesn't have any surprises.

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.

Guess math teachers should start learning to play League of Legends and Pokemon.

Alternatively, I guess we need better reasons than those to teach a subject.

If you think about it, a lot of education is really a kind of game and games themselves are often educational, usually by accident.

Frex, I think a lot of people would recognise the value of teaching kids to play chess in order to improve their concentration and problem-solving skills. Well, why not more modern board games?

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

I'm currently struggling with an online Machine Learning class (the Coursera one... at the tender age of 43), and I can only take it (so far, at least... just failed my first quiz... fortunately I can review and re-take) because I was rather obsessed with matrices, oh, about 28 years ago. "You mean I can rotate things in an n-dimensional space without using trig?"

graduated in math, let me tell you this is how all my fellow students felt like every semester in every class.

For me, Math has always resembled riding a bike more than anything else. Sure, the first few moments, the path is a bit overgrown and all the weeds need to be cleared off but it was always significantly easier revisiting a topic than understanding it for the first time.

For those who forget so quickly, I wonder if you felt like you truly understood it in the first place?

While your description has some merit, there's a huge amount of trivia in the format of "I can do X, I just have to do Y first", "X has no known solution, try something else", and "operation X is very useful, try it". That goes away, and everything gets way harder.

Of course, the higher level functions might get covered in cobwebs - but I suspect not the same way; I would have kept these higher level skills up to date because:

- I recently went though a couple of books on Bayes and computer vision. I would have used Mathematica - refreshing my memory. - I sometimes need to do some stats / analysis - Refresh... - I recently picked up a Student's guide to Maxwell's equations - Refresh... - I need to help my children with Calculus...

If I had been using a high level tool my whole life I think I actually would make use of calculus and other mathematics.

I'm curious if anyone else feels the same.

As I recognize this more in myself, I am more inclined to become a bit of a librarian and develop better methods of personal note-taking and information retrieval, so that I lose less each time my mind flutters. At the moment that's turned into a fascination with mind maps - every time I need to critically-think through a problem I start mapping it. In the future I might look into ways of searching through those maps.

http://www.cs.cmu.edu/~tom/mlbook.html

Where other textbooks tended to jump two or three steps ahead with a comment about the steps being "obvious" or "trivial", Mitchell would just include each little step.

Yes, you could argue it was my responsibility to remember all of my calculus and linear algebra. But it is kind to the reader to spell out the little steps, for those of us who maybe forgot some of our calculus tricks, or maybe don't even have all of the expected pre-requisites but are trying to press on anyway. Or actually know how to perform the steps but have to stop and puzzle through which particular combination of steps you are describing as "obvious" in this particular instance.

I just remember how nice it was to have those extra steps spelled out, and how much more pleasant it made reading Tom's book.

So thanks, Dr. Mitchell!

-Richard Feynman

s/smart/dumb

:)

Quantum mechanics is the worst. I dislike a lot of the "popular science" language and analogues used to describe it, but the real (academic) pedagogical material is completely inappropriate for regular people. I'm worried that I'll be an inscrutable physicist before I grok it well enough to explain to a highschooler, though.

It is the same principle as writing programs so they are easier for the next programmer to read. That person may be you.

Often it's understandable short-cuts, but often it also turns out that the author has left out very substantial chunks of knowledge, or sometimes clearly don't understand why they got the results they did.

In CS papers there's an additional red flag: Maths. Outside of a few maths heavy areas of CS where it is justified, if a CS paper is full of equations, it's a good sign they'll have glossed over a lot of essential information, such as parameters that often turns out to be essential to be able to replicate their results. Not always, but often enough for me to be vary.

I'm guessing it is because in the instances that include pseudo-code or working code, it is instantly obvious that something is missing, both to the author and to reviewers, but when it's obscured in equations it takes more effort to identify the same flaw because so many steps are often legitimately left out because of conventions that it's non-trivial for someone not steeped in the same notation to determine which bits should be defined and which bits are not necessary. I'm sure most of the time it's not intentional. But taking that shortcut seems to make it a lot easier to forget which additional information is actually necessary. And the irony is that I've seen plenty of example where the equations have taken up just as much space as pseudo-code or even working-but-naive implementations would have taken.

The same thing a bachelors degree does for everyone else. You've proven that you can start, stick with, and complete a task that takes multiple years and a complicated set of steps.

But a lot of the reason for this experience for me at least was that I started uni after having spent about 15 years learning to program already, and by the time I picked up again and did my masters, I'd had another 10 years of commercial software development experience.

These things are not really geared for people like us that came to them with a lot of pre-existing knowledge, but at people like my class-mates first time around that had hardly touched a computer before, and that did need a lot of hard work to come out with a good understanding of the problems.

As a hiring manager this is why I rarely care whether someone has a degree or not if they can demonstrate experience. And on the other side of the table, I only took that degree because in the UK there are still sufficiently many employers that have an obsession with degrees regardless of experience...

[0] I'm looking at you, three years of 'numerical methods', which reduced to memorising algorithms to perform by hand.

[1] I count myself amongst the absolutely useless 'applied mathematicians' from my class.

"If you're not sure what you want to do with your life, study Math. Why? Because Math teaches you how to think."

The skills I learned studying Mathematics have been invaluable, the Math that I currently am able to recall is abysmal.

The author did a great job calling this out succinctly: Mathematics is an excellent proxy for problem-solving

I'd say the ideal way to develop knowledge, understanding and skill in almost any field is a combination of systematic practice and receiving personalised guidance and training from someone who thoroughly understands the field itself to at least the level you are trying to reach and is able to share that understanding effectively based on your current level of understanding.

Sadly, this is usually hopelessly unrealistic, because there are nowhere near enough suitable trainers around to give everyone close to 1:1 training in that format. But the further we drift from it, the more impersonal and generic training becomes, the more isolated individual practice becomes, the less immediate and detailed feedback becomes, the less effective the training regime as a whole will be.

Given that neither undergraduate-style mass lectures nor postgraduate-style research are particularly efficient at conveying useful information, guiding practice, or promoting rapid and actionable feedback, I personally don't rate either particularly highly on an idealised scale. Perhaps a more practically useful question would be whether there are ways to improve university-level training that are realistic given the time and money constraints and, beyond a certain point, the lack of many if any people who actually are more knowledgeable or skillful in increasingly specialised fields than the research student who is dedicated to exploring them.

On the subject of lectures, it does slightly surprise me that in 2016 we still have researchers with neither much interest in teaching nor the presentation skills to do it well being asked/compelled to deliver undergraduate lecture courses at individual universities. You'd think with the easy access to video presentations and supporting materials now offered by the Internet, universities might have collaborated by now to build the personal elements of tuition around video lectures given by academics who do have the interest and are gifted presenters.

On the other hand, I suppose that would expose how little personal attention many students actually receive in return for the fees and debts they take on, and universities don't want to encourage potential students to question how much real value they provide. Surely it would be more reliable and efficient as an education method if they focused their efforts on small group tuition and individual guidance, though.

Number theorists (amongst others) are seemingly obsessed with bounding things. There are entire books written about obtaining and then refining bounds - which appear to be nothing more than inequalities. There is great real-world value to be derived from seeing 'inequalities' as tools to leverage. Brian Kernighan once commented that controlling software complexity is the essence of programming [0]. I believe similar thinking applies to other aspects of software engineering, and product and business development. If you can take a hard problem, and bound its complexity, then you can say "the problem is no more complex than this". This is very useful. The chief value proposition of many SaaS businesses is the trivialisation of the upper bounds of complexity of hard problems. For instance, for many developers, Heroku makes the complexity of deployment very low.

[0] http://quotes.cat-v.org/programming/

This may lead to a few problems too:

(1) Prior knowledge can serve as a blinder. Our conceptual toolkits may end up consisting of unwieldy theorems that while useful are cumbersome to use.

(2) The number of theorems with no immediately evident practical use is so large that they may end up being "forgotten" anyways, and this will result in us having to do the "mental heavy lifting" all over again.

http://matt.might.net/articles/phd-school-in-pictures/

My experiment formed the basis of a fairly productive new research program for my thesis advisor, so at least it lived on in somebody's brain, but not in mine. ;-)

Sometimes it happened that school attempted to teach me something I was interested in and I ended up understanding it. At other times, however, it all went to /dev/null.

Perhaps it doesn't make sense today because it never did, and the self deception has long worn off, not because the author has gone daft.

Several weeks ago, on the last work day before going on vacation, I submitted fixes for nine issues I found in one USB host controller driver. The last time I looked at the code was more than a year ago. I had refactored it and really improved its quality. Looking at some of the code now, I couldn't understand it that well. But that's because it wasn't as good as I thought it was. I was still relying on the fictitious story of how I thought certain aspects of the code worked really well thanks to me, and it wasn't meshing with the reality emanating from freshly reading it with more critical eyes. And, of course, I was also confronted by a reproducible crash. As I'm reading the code, I'm forced to throw away the false delusions and replace them with reality. This is because I'm smarter and fresher today, not because I've forgotten things and gotten dumber! It's taking effort because something is actually being done.

Perhaps a similar problem is here: he's reading the paper with more critical eyes and seeing aspects that don't match the fake memory of how great that paper was, which was formed by clouded judgment at the time of writing. Maybe that obscure notation that he can't understand is actually incorrect garbage. His brain is reeling because it's actually digging into the material and trying to do proper work, perhaps for the first time.

If you can show that your five year old work is incorrect garbage, that suggests you're actually superior today to your former self from five years ago. So that could be the thing to do. Don't read the paper assuming that it's right, and you've gone daft. Catch where you went wrong.

By the way, I never have this problem with good code. I can go back a decade and everything is wonderful. Let's just say there is a suspicious smell if you can't decipher your old work.

Good work is clear, and based on a correct understanding which matches that work. There is a durable, robust relationship between the latent memory of that work and the actual work, making it easy to jog your memory.

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 understands -- and, in fact, no one has read except for maybe three people?

Not to mention PhDs usually have to TA (teach students), which accounts for some of their pay.

(I could say there's no way to measure "value to society", in fact this concept means nothing, but I agree on settling on "an enourmous amount of productive capital to someone, not exactly the society").

Radioactivity. http://www.nobelprize.org/nobel_prizes/themes/physics/curie/

Nash equilibrium. http://rbsc.princeton.edu/sites/default/files/Non-Cooperativ...

Emergence of digital circuit design. https://en.wikipedia.org/wiki/A_Symbolic_Analysis_of_Relay_a...

A pretty ridiculous thing to claim.

Those may be reasons to study maths (although, studying anything seriously probably yields comparable benefits) but doing a PhD and writing a thesis is not only about yourself: it's supposed to advance the field. It's something you do for the general community.

In my experience, earning a PhD in [redacted] was excellent training in problem solving. And in developing working expertise in new areas. I suspect that the choice of field is indeed irrelevant.

> Mathematics embeds character in students

I'd say that actually finishing a PhD does that.

> Mathematics is fun

Whatever you pick for your dissertation topic had better be fun ;)

So, I started to read crypto journals. Basically anything co-authored by Chaum, Micali, Goldreich, Wigderson. After a few weeks, I starting to get the hang of it. Sort of like learning a new language. So, I gave the presentation and then forgot about it.

A few years later, I decided to show my powerpoint to someone and describe the process. WTF? How did this lead to that? Didn't understand half of it. Was really embarrassing.

And then he asked it: "How the hell did I do that?" --Kurt Vonnegut, Timequake

I find the experience common when I look back on things I write or design or build. As Bill Gates said, “Most people overestimate what they can do in one year and underestimate what they can do in ten years.”

So basically he went doing other stuff not functional-analysis-related and his functional-analysis got rusty.

It seems quite reasonable to me. Call it old code syndrome, call it "my math got rusty", it seems quite normal to me.

Also: according to http://fjmubeen.com/about/, the author got his phd in 2007. It's 2016.

Almost ten years. What... What are we talking about?