10 ms·

Exercises in Programming Style

381 points by henrik_w 9y ago

bringtheaction 9y ago
> There is also an example with types, but this becomes very awkward to show in Python. With the book having been published in 2014, and type hints [1] being introduced with Python 3.5 released in 2015 [2], without knowing how the book did it I guess this is one part of the book that could have been made better in 2018. [1]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html [2]: https://www.python.org/downloads/release/python-350/ https://www.python.org/downloads/release/python-350/
- tom_mellior 9y ago
  As as understand it, those hints are only hints to human readers. There is no standard tooling that actually does any type checking, either statically or dynamically (although such tooling can be built using Python's reflective capabilities). So while adding the hints may be valuable documentation, it wouldn't solve the problem of "showing how types protect against errors in the Adversity section".
  - gtklocker 9y ago
    There's mypy.
    - tom_mellior 9y ago
      Sorry, by "no standard tooling" I meant "no standard tooling" in the sense of no tooling in the standard Python distribution.
      - nullp0tr 9y ago
        Seeing that mypy is under github.com/python/, you can easily argue that it is in fact the standard tool for type-checking python code.
        milliams 9y ago
        And also that the second highest contributor is Guido van Rossum (https://github.com/python/mypy/graphs/contributors https://github.com/python/mypy/graphs/contributors).
        tom_mellior 9y ago
        Fair enough, those are reasonable arguments the grandparents could (and should) have made.
  - bringtheaction 9y ago
    Like the other commenter said, check out mypy. http://mypy-lang.org/ http://mypy-lang.org/
- faitswulff 9y ago
  I am planning on adding this book to my wishlist, but I agree with the reviewer's note at the end: > My only criticism of the book is the naming of the styles...In many cases, there are already establish names for the styles, but instead of using them, the author came up with her own. For example: Trinity instead of MVC, Things instead of Objects, Hollywood instead of Callbacks, Bulletin Board instead of Pub/Sub and Kick Forward instead of Continuation-passing. Those names are OK, but it is much better to stick to the industry standard ones. I'd definitely include this change in a 2018 edition, too.
  - kerkeslager 9y ago
    MVC = Model View Presenter? Objects = Structs or Workers? Callbacks = Continuations? Pub/Sub = Observer pattern? Depending on what programming language background you come from, you may not use the "established" names either.
    - barrkel 9y ago
      Generally speaking, solution to a terminology problem isn't to create terminology n+1.
      - kerkeslager 9y ago
        That depends what the terminology problem is. If the problem is that you're going to be criticized by a bunch of pedantic linguistic prescriptivists who want you to use their terms in the way they want, creating new terms avoids that criticism.
        abiox 9y ago
        > avoids that criticism is that really important to avoid? and one is just gaining new criticisms in trade, no? and of course, going bespoke and inventing everything yet again has it's perks. maybe you'll get to be the person who "invented" a term, should it catch on. great for the resume. :)
      - 9y ago
- gabriel 9y ago
  I believe the premise of the book is to expose the reader to an element of style that bridges different programming environments. Thus, "style" here is meant more in the terms of a restrictive technique to allow an exposure of these techniques, not writing in idiomatic, or latest-and-greatest Python. I'd suggest this book even to experienced engineers to focus on different types or a style of programming that he/she may not be familiar. And when you recognize some of the styles it'll be a re-enforcement technique that you were doing something that is seen over and over again (much like a pattern language). I recall going over styles that are seen more in systems programming (like C). The book will contribute to an understanding of code architecture styles across different languages. For the new engineer, I'd also highly suggest this book as you may begin to see a variety of ways to solve a problem. And I would not concern myself with idiomatic Pythonic styles as that will come with time.
jboynyc 9y ago
The author of this book launched a new open access journal called The Art, Science, and Engineering of Programming last year. Professor Lopes serves as editor-in-chief. Much like the book, the journal focuses on the practice of programming and its styles. http://programming-journal.org/ http://programming-journal.org/
rs86 9y ago
Amazing stuff!
mathieubordere 9y ago
Thanks for this! Added to my reading list ...
harel 9y ago
This is very interesting. Not completely unrelated, a friend once told me he can tell a lot about the personality of a person by looking at their code. Years later I actually understood what he meant. Style does have some correlation with personality. Psychology of code...
- meuk 9y ago
  Can you give some examples of how personality traits manifest themselves in code?
- DJohnBenton 9y ago
  That sounds kind of fun, can you give some examples?
  - henrik_w 9y ago
    Maybe not exactly, but this was recently in the news: "De-anonymizing programmers from executable binaries" https://news.ycombinator.com/item?id=16598962 https://news.ycombinator.com/item?id=16598962
  - harel 9y ago
    It's quite hard to examplify once I actually think about an example, but I'll try. It's more a global vibe of a piece of code rather then semantics but they do play a part (using Python as example): A young person (say 24), has experience coding of a few years, but very enthusiastic, loves reading programming blogs, a real stickler of doing it the "right" way, and sometimes forgets other people might have to read their code. They are not as pragmatic as they would be 10 years down the road. They would use vim or emacs in vim mode because that's more pro. Their code might have a good few "clever" one liners that do something complex in a very concise manner. Took a while to compress into a single line and will take a week to read back and understand. Clever, but only if it never breaks or never needs maintenance. They write factories, sometimes of factories. They have 110% test coverage, including trivial stuff that doesn't require it. They would refactor a piece of code many times until it feels it's the right shade of clever. I like these coders because I can learn something from them, but if you have tight deadlines they might actually get in the way. Great to have a couple of these in your car, but don't let them drive. from itertools import chain first_set = set(['one', 'two']).union(set(chain.from_iterable([next.key for next in some_yielding_iter()]))) other_value = make_value_factory_factory(first_set).make_value_factory() 10 years down the line these guys realise you write code once and it's read many times over, and the above turns into a more vanilla multi line readable expression of the same idea. A less enthusiastic version of said 24 year old, codes because they knows how to, but has no aspirations to get better at their craft. Less organised individual. Pep8 is a new variation of Pepsi Cola? They are not bad coders, just sloppy. Their code works but can be better. They would benefit pairing with the above person. def someFunction(value): if (type(value) == ThisClass): processObject(value) elif (type(value) == str): processString(value) After pairing, maybe they were inspired a bit. Maybe they refactor to this: from functools import singledispatch @singledispatch def process_value(value): process_object(value) @process_value.register(str) def _(value): process_string(value) def some_function(value): return process_value(value) I think a good exercise is to look at a person you know and try ot match their personality to the code style. Then look at some code which might or might not be theirs and try to assert if it is.
mannykannot 9y ago
This sounds like a very interesting book. The one small concern I might have (I have only read the review) is that the sample problem might not be a good case for some of the more complex techniques, such as introspection and metaprogramming. I think we have all seen code that seems to have been designed primarily to showcase all of its author's knowledge regardless of whether it helps, and I would not want the book to be misunderstood as an endorsement of that practice.
wickedwizard 9y ago
I had this book as a student of Prof Lopes' class at UCI. One of the best classes I had. Programming patterns/styles that senior programmers got through experience were covered, which I liked a lot. As students we had to compulsorily buy the book though.
pjmorris 9y ago
I like the review author's approach of writing his own version of the task before reading, then looking for its closest match among the presented styles.
tzs 9y ago
Note: its available on Safari Books Online. I would guess that a fair number of people here have SBO subscriptions.
ahjones 9y ago
The code associated with the book is all on Github: http://github.com/crista/exercises-in-programming-style http://github.com/crista/exercises-in-programming-style
andrepd 9y ago
Just one short note of appreciation for this book: Chapter 24 (Quarentine) helped Haskell IO and monads "click" to me. Now I understand what they mean when they say, for example, that "`IO String` represents not a string but a computation that will return a String. You can store this computation (and chain them), but they won't produce a value until you run them".

381 points by henrik_w 9y ago

> There is also an example with types, but this becomes very awkward to show in Python. With the book having been published in 2014, and type hints [1] being introduced with Python 3.5 released in 2015 [2], without knowing how the book did it I guess this is one part of the book that could have been made better in 2018. [1]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html [2]: https://www.python.org/downloads/release/python-350/ https://www.python.org/downloads/release/python-350/

tom_mellior 9y ago
As as understand it, those hints are only hints to human readers. There is no standard tooling that actually does any type checking, either statically or dynamically (although such tooling can be built using Python's reflective capabilities). So while adding the hints may be valuable documentation, it wouldn't solve the problem of "showing how types protect against errors in the Adversity section".
- gtklocker 9y ago
  There's mypy.
  - tom_mellior 9y ago
    Sorry, by "no standard tooling" I meant "no standard tooling" in the sense of no tooling in the standard Python distribution.
    - nullp0tr 9y ago
      Seeing that mypy is under github.com/python/, you can easily argue that it is in fact the standard tool for type-checking python code.
      - milliams 9y ago
        And also that the second highest contributor is Guido van Rossum (https://github.com/python/mypy/graphs/contributors https://github.com/python/mypy/graphs/contributors).
        tom_mellior 9y ago
        Fair enough, those are reasonable arguments the grandparents could (and should) have made.
- bringtheaction 9y ago
  Like the other commenter said, check out mypy. http://mypy-lang.org/ http://mypy-lang.org/
faitswulff 9y ago
I am planning on adding this book to my wishlist, but I agree with the reviewer's note at the end: > My only criticism of the book is the naming of the styles...In many cases, there are already establish names for the styles, but instead of using them, the author came up with her own. For example: Trinity instead of MVC, Things instead of Objects, Hollywood instead of Callbacks, Bulletin Board instead of Pub/Sub and Kick Forward instead of Continuation-passing. Those names are OK, but it is much better to stick to the industry standard ones. I'd definitely include this change in a 2018 edition, too.
- kerkeslager 9y ago
  MVC = Model View Presenter? Objects = Structs or Workers? Callbacks = Continuations? Pub/Sub = Observer pattern? Depending on what programming language background you come from, you may not use the "established" names either.
  - barrkel 9y ago
    Generally speaking, solution to a terminology problem isn't to create terminology n+1.
    - kerkeslager 9y ago
      That depends what the terminology problem is. If the problem is that you're going to be criticized by a bunch of pedantic linguistic prescriptivists who want you to use their terms in the way they want, creating new terms avoids that criticism.
      - abiox 9y ago
        > avoids that criticism is that really important to avoid? and one is just gaining new criticisms in trade, no? and of course, going bespoke and inventing everything yet again has it's perks. maybe you'll get to be the person who "invented" a term, should it catch on. great for the resume. :)
    - 9y ago
gabriel 9y ago
I believe the premise of the book is to expose the reader to an element of style that bridges different programming environments. Thus, "style" here is meant more in the terms of a restrictive technique to allow an exposure of these techniques, not writing in idiomatic, or latest-and-greatest Python. I'd suggest this book even to experienced engineers to focus on different types or a style of programming that he/she may not be familiar. And when you recognize some of the styles it'll be a re-enforcement technique that you were doing something that is seen over and over again (much like a pattern language). I recall going over styles that are seen more in systems programming (like C). The book will contribute to an understanding of code architecture styles across different languages. For the new engineer, I'd also highly suggest this book as you may begin to see a variety of ways to solve a problem. And I would not concern myself with idiomatic Pythonic styles as that will come with time.

jboynyc 9y ago

The author of this book launched a new open access journal called The Art, Science, and Engineering of Programming last year. Professor Lopes serves as editor-in-chief. Much like the book, the journal focuses on the practice of programming and its styles. http://programming-journal.org/ http://programming-journal.org/

rs86 9y ago

Amazing stuff!

mathieubordere 9y ago

Thanks for this! Added to my reading list ...

harel 9y ago

This is very interesting. Not completely unrelated, a friend once told me he can tell a lot about the personality of a person by looking at their code. Years later I actually understood what he meant. Style does have some correlation with personality. Psychology of code...

meuk 9y ago
Can you give some examples of how personality traits manifest themselves in code?
DJohnBenton 9y ago
That sounds kind of fun, can you give some examples?
- henrik_w 9y ago
  Maybe not exactly, but this was recently in the news: "De-anonymizing programmers from executable binaries" https://news.ycombinator.com/item?id=16598962 https://news.ycombinator.com/item?id=16598962
- harel 9y ago
  It's quite hard to examplify once I actually think about an example, but I'll try. It's more a global vibe of a piece of code rather then semantics but they do play a part (using Python as example): A young person (say 24), has experience coding of a few years, but very enthusiastic, loves reading programming blogs, a real stickler of doing it the "right" way, and sometimes forgets other people might have to read their code. They are not as pragmatic as they would be 10 years down the road. They would use vim or emacs in vim mode because that's more pro. Their code might have a good few "clever" one liners that do something complex in a very concise manner. Took a while to compress into a single line and will take a week to read back and understand. Clever, but only if it never breaks or never needs maintenance. They write factories, sometimes of factories. They have 110% test coverage, including trivial stuff that doesn't require it. They would refactor a piece of code many times until it feels it's the right shade of clever. I like these coders because I can learn something from them, but if you have tight deadlines they might actually get in the way. Great to have a couple of these in your car, but don't let them drive. from itertools import chain first_set = set(['one', 'two']).union(set(chain.from_iterable([next.key for next in some_yielding_iter()]))) other_value = make_value_factory_factory(first_set).make_value_factory() 10 years down the line these guys realise you write code once and it's read many times over, and the above turns into a more vanilla multi line readable expression of the same idea. A less enthusiastic version of said 24 year old, codes because they knows how to, but has no aspirations to get better at their craft. Less organised individual. Pep8 is a new variation of Pepsi Cola? They are not bad coders, just sloppy. Their code works but can be better. They would benefit pairing with the above person. def someFunction(value): if (type(value) == ThisClass): processObject(value) elif (type(value) == str): processString(value) After pairing, maybe they were inspired a bit. Maybe they refactor to this: from functools import singledispatch @singledispatch def process_value(value): process_object(value) @process_value.register(str) def _(value): process_string(value) def some_function(value): return process_value(value) I think a good exercise is to look at a person you know and try ot match their personality to the code style. Then look at some code which might or might not be theirs and try to assert if it is.

mannykannot 9y ago

This sounds like a very interesting book. The one small concern I might have (I have only read the review) is that the sample problem might not be a good case for some of the more complex techniques, such as introspection and metaprogramming. I think we have all seen code that seems to have been designed primarily to showcase all of its author's knowledge regardless of whether it helps, and I would not want the book to be misunderstood as an endorsement of that practice.

wickedwizard 9y ago

I had this book as a student of Prof Lopes' class at UCI. One of the best classes I had. Programming patterns/styles that senior programmers got through experience were covered, which I liked a lot. As students we had to compulsorily buy the book though.

pjmorris 9y ago

I like the review author's approach of writing his own version of the task before reading, then looking for its closest match among the presented styles.

tzs 9y ago

Note: its available on Safari Books Online. I would guess that a fair number of people here have SBO subscriptions.

ahjones 9y ago

The code associated with the book is all on Github: http://github.com/crista/exercises-in-programming-style http://github.com/crista/exercises-in-programming-style

andrepd 9y ago

Just one short note of appreciation for this book: Chapter 24 (Quarentine) helped Haskell IO and monads "click" to me. Now I understand what they mean when they say, for example, that "`IO String` represents not a string but a computation that will return a String. You can store this computation (and chain them), but they won't produce a value until you run them".