Hacker News Reader

Comment by bringtheaction | Hacker News Reader

> 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

[2]: https://www.python.org/downloads/release/python-350/

View on HN

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.

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.

Generally speaking, solution to a terminology problem isn't to create terminology n+1.

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.

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

The good old: Oh look, there are n different services, but all of them have not completely nailed it and my specific use case is not covered.

I'll create a new service that does all of the stuff the old services already did, aswell as this new thing, thus making the old n services obsolete. Everyone will be thankful for the unifying service and hail me for reducing the number of choices from n down to 1.

That's how we ended up with n+1 different services.

MVC is not MVP see also https://stackoverflow.com/questions/2056/what-are-mvp-and-mv...

Objects vs Structs - a struct is just a collection of data, while an object is a collection of data AND behavior (methods).

Callback vs Continuation - I wouldn't expect a continuation to be called more than once, while I callback can.

Pub/Sub vs Observer - with the observer pattern you register for updates directly on the object that is responsible for them, while with pub/sub there is a central component involved and you don't even need to know who originally published it.

So no, for none of the examples you gave you can just replace one term with the other.

That was intentional, see [1]

[1] https://youtu.be/Gw4WJJoDl3U?t=14m30s

So it seems like @kerkeslager's reasoning in a sibling comment was correct, that it ignited a naming war.

That said, maybe a list of tags for the styles would help? "Also called: [functional, imperative]" etc.?

Basically, she came up with her own names so that the examples could work stand alone without everyone bringing their "but to be called X it needs Y!" baggage and quibbling about it.

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

There's mypy.

Sorry, by "no standard tooling" I meant "no standard tooling" in the sense of no tooling in the standard Python distribution.

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.

And also that the second highest contributor is Guido van Rossum (https://github.com/python/mypy/graphs/contributors).

Fair enough, those are reasonable arguments the grandparents could (and should) have made.

Like the other commenter said, check out mypy.

http://mypy-lang.org/

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.

Reply on news.ycombinator.com