You don't say....
Response to “Literate programming considered harmful”
31–40 of 68 posts
Re: Response to “Literate programming considered harmful”
#32The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before. I think this is related to the proliferation of frameworks. I can't come up…
> Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks.
Or
- read the tests for that method.
- look at the commit log and associated bugs.
- use identifiers that are self-explanatory to some extent. auto-complete makes using long names manageable.
- step through it with a debugger to see what it does.
- use an editor/IDE that shows additional info about unknown methods, assuming a statically typed language
where it has total knowledge about available types.
Re: Response to “Literate programming considered harmful”
#33Earlier quoted context omitted.
> Enter Golang... a language smaller than even ANSI C. It's readable because if you've worked with Golang for more than a week, you basically know every language construct you'll encounter. That's not really what readability is to me. For example, I consider this idiomatic golang code (from the standard library, no less) to be entirely unreadable: https://golang.org/src/crypto/tls/handshake_messages.go#L297 For me re…
It's ultimately subjective, but I think that code is readable: the variables are well-named and each line says exactly what it does. Abstraction makes it easier for you to think you understand what the code is doing, but if you want to really understand what's going on, you also have to understand how the abstraction is implemented. Straightforward code like this can be understood directly, without having to dig thro…
If you think that code is readable, could you correctly write all pre/post-conditions in between statements?
Re: Response to “Literate programming considered harmful”
#34The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before. I think this is related to the proliferation of frameworks. I can't come up…
> The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before.
Not true. You just have to express it clearly. I view comments as a code smell - they generally indicate a part of the codebase that you know is poorly factored. If your language/framework doesn't allow you to express code clearly, get a better language/framework.
Laziness is one of the cardinal virtues of a programmer.
Re: Response to “Literate programming considered harmful”
#35The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before. I think this is related to the proliferation of frameworks. I can't come up…
I do not personally see this trend. In fact I see the proliferation of automatic-documenters and automatically checked minimum documentation requirements (which, as is often the case with blanket rules, tends to misfire producing volume but not quality; but this is another topic).
It seems literate programming assumes that the person doing development is the same as the one reading documentation. That is not always the case. And when it is not the case, the code embedded in documentation can hurt readability.
For example, I try to get all interface specs distributed, discussed and confirmed ASAP, usually WAY before the code is mature enough to be shown outside. Also, getting others to read, think about and comment on even short ICDs is difficult as is. Getting them to read early ICDs interspersed with early code? Not going to fly. My 2c.
Re: Response to “Literate programming considered harmful”
#36Earlier quoted context omitted.
> The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before. Enter Golang... a language smaller than even ANSI C. It's readable because…
> Enter Golang... a language smaller than even ANSI C. It's readable because if you've worked with Golang for more than a week, you basically know every language construct you'll encounter. That's not really what readability is to me. For example, I consider this idiomatic golang code (from the standard library, no less) to be entirely unreadable: https://golang.org/src/crypto/tls/handshake_messages.go#L297 For me re…
> For example, I consider this idiomatic golang code (from the standard library, no less) to be entirely unreadable
Really? It's a binary parser that's parsing data from a byte array and stuffing the results into a struct, it seems pretty straightforward.
Re: Response to “Literate programming considered harmful”
#37The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before. I think this is related to the proliferation of frameworks. I can't come up…
>The trend in programming lately seems to be less to no comments and less to no documentation Hasn't this always been the case for young programmers? Seems you don't comment until you have to go back to code you wrote yourself a year later and make major changes....you then realize you should have documented it, either inline step-by-step or as a proper doxygen/javadoc style. I can thank Dr. Leitner (CS 50/51) for en…
Funny enough, I had a C & C++ prof deduct points for comments with the argument that they were redundant and that the code should be self documenting. Then again, this is from a guy who never handed back assignments until the end of the semester and by then couldn't remember why he graded you the way he did. Would just respond with "you didn't understand the material".
Re: Response to “Literate programming considered harmful”
#38My new checklist for making programs easy to understand and work with in the future.
- Make the program in complete slices of a functionality and put those into folders and files that are descriptive of what the code does: "web/login/facebook/always_ask_for_email.lang"
- Do repeat yourself in different functionality areas.
- Name your variables and functions as if they should never conflict/as specifically as you dare.
- Use a functional and immutable programming language or write pure functions as much as possible.
- Stop thinking that patterns are necessary to solve the problem of turning data from one form into another.
I might be wrong.
Re: Response to “Literate programming considered harmful”
#39Earlier quoted context omitted.
>The trend in programming lately seems to be less to no comments and less to no documentation Hasn't this always been the case for young programmers? Seems you don't comment until you have to go back to code you wrote yourself a year later and make major changes....you then realize you should have documented it, either inline step-by-step or as a proper doxygen/javadoc style. I can thank Dr. Leitner (CS 50/51) for en…
Funny enough, I had a C & C++ prof deduct points for comments with the argument that they were redundant and that the code should be self documenting. Then again, this is from a guy who never handed back assignments until the end of the semester and by then couldn't remember why he graded you the way he did. Would just respond with "you didn't understand the material".
that's crap. self documenting code sometimes works...but not always. I love people that hand me HDL and say "it's self documenting." Then you open it, and wire names are "x_1245_to_y." Happened all the time when my students would turn in assignments. That stopped after they realized I graded the documentation too :).
Re: Response to “Literate programming considered harmful”
#40The trend in programming lately seems to be less to no comments and less to no documentation; and it is killing the joy I take in programming. Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. You can't do anything that hasn't been done before. I think this is related to the proliferation of frameworks. I can't come up…
> Without comments the only way the next guy has a chance to understand the code is if you stick to lowest common denominator patterns and frameworks. Or - read the tests for that method. - look at the commit log and associated bugs. - use identifiers that are self-explanatory to some extent. auto-complete makes using long names manageable. - step through it with a debugger to see what it does. - use an editor/IDE th…
Many of the techniques you listed are subcategories of reverse engineering. In an ideal world, the code and comments are clear enough that no reverse engineering is necessary.
Given a bizarre method, would you rather see a clear comment or spend half an hour stomping through a commit log?