Your first 3 minutes are FREE talking live with me.
Please visit my website at: https://tinyurl.com/ycyfbv5g
Or, call me right now at: 1-800-275-5336 x0160
Tuesday 29 September 2020
MASTER PSYCHIC READER~ ACCURATE & AMUSING
Please visit my website at: https://tinyurl.com/ycyfbv5g
Or, call me right now at: 1-800-275-5336 x0160
Tuesday 22 September 2020
Logo
When a company changes their logo, it's generally a group exercise in self pleasuring. It's rarely necessary. If you look at the Starbucks logo, the 1987 or 1992 logo is in color, a big transformation, but I personally wouldn't change my coffee drinking decisions based on any of their logos. As for 1971, I'm not sure what's more offensive nowadays, bare mermaid breasts or a black and white logo. And what in the hell is she holding? Are those her mermaid legs? What exactly does this imply? Is this a coffee shop or a brothel? Sick bastards. Logos are ridiculous and nobody cares.
When I was told we needed to change our logo, my first concern was the circle jerk of pointless design and then cost. Clearly there's no financial benefit to the exercise. We've had the same logo for 15 years. Is it a good logo? It looks good. I like the colors. I like the knight. As for the design itself, I have to admit, it's a giant pain in the ass. Our original logo is terrible, practically speaking. It's an impediment to its very purpose.
The use of black means it looks great on screen with a white background, but it's problematic with other forms of media, which require a very light background. It's so difficult to use, we tend either not to use it at all, making the brand identity somewhat weak, or we reverse the colors to put it on a black background with the logo in white. We mutilate the logo to make it work. It's a problem. But is it worth fixing? Enter the business case.
When it came to staff shirts, we resorted to white embroidery on black shirts. originally I had white shirts with a full color logo, but those were loathed by everyone, and they were hard to keep clean. You may not know this but everything we sell sits in a dirty warehouse before getting to us and gets even dirtier as it sits on our shelves. Keeping a retail store clean is a major feat, as it starts dirty and only gets worse. White shirts were always getting stained and looking bad.
The black, embroidered shirts we currently use, with a boring plain white stitched logo, turned out to be incredibly expensive. Each shirt costs $70 with embroidery. They also need to be made in batches in various sizes, so we're almost always buying more than we need, in sizes we hope will be useful. Invariably, those sizes don't match our diverse staff. So over time, we've been stuck with a box of very expensive shirts in the wrong sizes. The cost of bad design turns out to be very high.
Our new shirt design features a full color patch that can be sewn onto a variety of shirts. We choose the shirt from the Work Wear store next door, grab a patch, and sew it on. No big batches of variable sized, expensive, embroidered, logo perverting shirts. Also, if I want one of my robust, tactical shirts from 5.11, I buy it in the right color and sew on the patch, something not available before. Total cost per shirt for employees will be $25 or so, with no waste.
Then there's the increased merchandising we tend to avoid with the old logo. We've already ordered new patches, pins, stickers, and more. We'll have hats and t-shirts eventually. These were difficult to design with the old logo requirements and they sold poorly.
Now let's get onto the minor controversy of our design choices. We spent about a month defining the needs of the new logo with half a dozen designers. We identified core requirements. It should maintain the design elements of the old logo: the knight, the horse, the lance, the direction it's all headed (very symbolic) and of course, a diamond. The logo needed to remain fairly simple. The name needed an updated font that was compact with the design. The previous font used long, horizontal text and has been nothing but trouble for 15 years. The color black is problematic. It goes with nothing but white. Those who use black in their logos hamstring themselves design wise, so we omitted that. In fact, I would probably pick a different store name without a color in the title if I were to do it over. I have few regrets, but "black" is one. Let's take a look at the new design:
I think it pops. Rather than black, we have a dark blue, which works much better and represents one of our colors. It's a darker blue than our original logo (which some say was purple, a color I love). The diamond color, away from black, represents a shift in store colors that came about with our big construction project, three years ago.
Read More :- "Logo"
When it came to staff shirts, we resorted to white embroidery on black shirts. originally I had white shirts with a full color logo, but those were loathed by everyone, and they were hard to keep clean. You may not know this but everything we sell sits in a dirty warehouse before getting to us and gets even dirtier as it sits on our shelves. Keeping a retail store clean is a major feat, as it starts dirty and only gets worse. White shirts were always getting stained and looking bad.
The black, embroidered shirts we currently use, with a boring plain white stitched logo, turned out to be incredibly expensive. Each shirt costs $70 with embroidery. They also need to be made in batches in various sizes, so we're almost always buying more than we need, in sizes we hope will be useful. Invariably, those sizes don't match our diverse staff. So over time, we've been stuck with a box of very expensive shirts in the wrong sizes. The cost of bad design turns out to be very high.
Our new shirt design features a full color patch that can be sewn onto a variety of shirts. We choose the shirt from the Work Wear store next door, grab a patch, and sew it on. No big batches of variable sized, expensive, embroidered, logo perverting shirts. Also, if I want one of my robust, tactical shirts from 5.11, I buy it in the right color and sew on the patch, something not available before. Total cost per shirt for employees will be $25 or so, with no waste.
Then there's the increased merchandising we tend to avoid with the old logo. We've already ordered new patches, pins, stickers, and more. We'll have hats and t-shirts eventually. These were difficult to design with the old logo requirements and they sold poorly.
Now let's get onto the minor controversy of our design choices. We spent about a month defining the needs of the new logo with half a dozen designers. We identified core requirements. It should maintain the design elements of the old logo: the knight, the horse, the lance, the direction it's all headed (very symbolic) and of course, a diamond. The logo needed to remain fairly simple. The name needed an updated font that was compact with the design. The previous font used long, horizontal text and has been nothing but trouble for 15 years. The color black is problematic. It goes with nothing but white. Those who use black in their logos hamstring themselves design wise, so we omitted that. In fact, I would probably pick a different store name without a color in the title if I were to do it over. I have few regrets, but "black" is one. Let's take a look at the new design:
I think it pops. Rather than black, we have a dark blue, which works much better and represents one of our colors. It's a darker blue than our original logo (which some say was purple, a color I love). The diamond color, away from black, represents a shift in store colors that came about with our big construction project, three years ago.
This orangish yellow is called Curry in Sherwin Williams colors, which is the color we painted our staircase. It's a color that matches our birch fixtures. It provides a pleasing blue and gold ambience, the colors of the local university, UC Berkeley.
This shift in store colors came in a moment of crisis. The Curry color came from a decision I made with the architects when it was clear our paint color choices weren't working in practice. I was distracting myself at the time with another project, a used Jeep I was about to buy in Utah, because Utah was the closest location of a Jeep in this exact color I was smitten with. I had to have not only the features I was looking for, but it had to be in that color. It was clearly on my mind. Originally the Curry color was white, but when we painted it on on the staircase, it looked terrible.
So the color of the staircase and thus the logo got their color from a Jeep. The Jeep is in a Chrysler color called Amp'd. And thus our staircase became Amp'd, and our logo became Amp'd. And for the foreseeable future, we shall be Amp'd. Most people like the new logo, once they've accepted (or more often overlooked) the diamond isn't black. It's a tough ask, but if people can accept the Starbucks mermaid isn't holding up her legs suggestively any longer, I think this can be overlooked. Personally I love the direction of the logo. I especially love I won't be paying $70 each for a box of useless shirts.
Monday 21 September 2020
Storium Theory: Optional Challenges
Most of the time, when we put down a challenge, it's definite - a note that the story will be focusing on a particular point. But is it possible to use challenges differently? To lay down a challenge for something the players might want to focus on, but are not required to focus on?
But should you decide to use this tool, I think there are some very important things you will need to be sure you address.
Read More :- "Storium Theory: Optional Challenges"
I believe it is a tool for the toolbox...but one I would show great caution in using. I've only pulled out an optional challenge once or twice in my own games, and I am wary of using them often, if at all, in my own narration generally. Storium's rules are set up more for completion of challenges and requiring of challenges, and I think there's a good reason for that.
In setup, an optional challenge wouldn't be so different from a regular challenge - you still want to establish the starting situation, the facts of the challenge, and the possible places the challenge can end up once it is complete. There's not much different in the overall technique of setting it up.
But should you decide to use this tool, I think there are some very important things you will need to be sure you address.
First: How will you know if players are or are not going to play on the challenge? You will need a good way of knowing if players have not played on a challenge yet because they haven't gotten to it yet, or because they do not intend to play on it at all. An optional challenge, being optional, could be ignored completely by players for reasons that have nothing to do with slow play or inactivity. It is important to have a way of determining that the players are not going to play on the challenge, and that it is time to move the scene on.
I suggest that you consider one of the following ideas:
- Set a deadline based on the other challenges - if the optional challenge is not completed by the time the scene's other challenges are, you will consider it incomplete and move the scene on.
- Set a deadline based on actual time - if the optional challenge is not completed within X days after the rest of the scene's challenges are (or just within X days if there are no other challenges) you will consider it incomplete and move the scene on.
- Require an affirmative statement from a player that they intend to play on the optional challenge by a specific date. If you have no such statement by that date, you will remove the optional challenge.
These methods are probably not the only ones...or even likely the best...but they all allow you to know when you can regard the challenge as incomplete and move forward. Whatever choice you make, be sure you tell your players so they know what the requirements are.
Second: What happens when the optional challenge is incomplete?
This is a pretty important question, and one that, I think, gets at the reason I don't use optional challenges much. If something's critical enough to the story that you want to set up a challenge for it, it seems like it is something the group should have to interact with - even if their interaction is playing Weakness cards and having their characters utterly ignore it and let it go wrong. In other words, the characters might not care about something, but if it is important enough to the story to rate a challenge, the players should have to do something about it...even if that something is having their characters do nothing. The story of the challenge, once laid out, should probably progress.
If it goes well, then, it ends Strong. If it goes poorly, it ends Weak. If it is less clear, it ends Uncertain. But that's all determined by the cards.
So...what do you do with a challenge that seemed interesting enough to put out there as an option, but that seems like something the character's don't have to address?
My best bet is that you do nothing. An optional challenge is something that is interesting, but not critical. The players don't gain or lose anything by not going after it. It's only if they actually engage it that it matters to the story in any way.
Thus, if the players don't seem interested in it and leave it alone, it just drops off for the moment. Nothing bad happens, nothing good happens. It just fades away into the background again.
That's not to say you can't bring it back again later, or bring it back again later as a normal, required challenge. It's just that for the moment, it wasn't critical enough to be made required, so nothing's reaching any kind of story-altering point with it. It just fades away for now.
If on the other hand players play some of the cards on the challenge, but don't finish it, I'd probably go by my usual rule for ending a challenge early when it becomes absolutely necessary: Most likely, end it by whatever the current result would be (i.e. if it is going Strong, it ends Strong, if it is going Weak, it ends Weak, if it is going Uncertain, it ends Uncertain) - this method makes the players' card plays so far clearly matter, so that's my preference. If you use a different rule for those cases in your own games, be consistent.
But that brings me to another consideration...
Third: How many points do you put on the thing, anyway?
I'm going to just say outright that I think the answer is one, possibly two at maximum. An optional challenge is not the focus of the scene - it is by definition something that can be entirely ignored. Thus, it isn't anywhere near as important as other challenges, and shouldn't get a lot of focus in the scene at hand.
Furthermore, if you put more points on an optional challenge, it makes it harder to judge when players no longer care about it - once it has become active, how do you judge that it isn't going to be active any further? You can always rule that an optional challenge becomes required if at least one player plays a card on it, of course, but that could get messy in terms of game morale and community if players disagree about whether they want to play on it.
So...I suggest making your life as easy as possible by using only one or two points, tops, and making clear to your players that whatever "deadline" you set for the optional challenge is a completion deadline, not a play deadline - the challenge needs to be complete by then or you will move things on. That will prevent an optional challenge from causing delays.
Finally, though: Consider whether the challenge should even be optional in the first place.
Most of the things I've considered as, well, optionally "optional" challenges were ideas that I ended up deciding would either fit perfectly well as required challenges right then, or would fit perfectly well as required challenges later. I've rarely come across something that I considered important to note in challenge form, but not critical enough to be something the players had to address.
If you're considering an optional challenge, think about it a bit more for a while...is it really something that should be optional, or is it just something that hasn't come to a head yet? Maybe it's something you can get some actual drama out of later, and make it a normal challenge in a later scene. Or maybe it's something you can hint at with a minor required challenge now - perhaps to see if someone notices something - and bring in more fully down the line.
Or perhaps it is something that actually is pretty vitally important right now, in which case it should be a required challenge...right now.
So, when can an optional challenge be helpful?
I could see them being useful if you want to allow the group to choose a direction, but neither direction is necessarily better or worse for the story (if one direction is better and the other is worse, you'd instead do a regular challenge and set the first up as the Strong outcome and the second as the Weak). Then, you could set up two different one-point challenges, and tell the players they can only do one of them - that sets them off on that path and determines how it starts out for them.
It isn't my chosen way to find where the players want to go in the story, but I could see it working.
Another method might be something that is solidly an opportunity for the players - again, if they don't do anything, it doesn't go wrong or anything like that, but perhaps it is something they can use to "shortcut" the plot in some way. You'd have to be careful with this one - it's easy to run into the "why don't you just do this as a regular challenge" internal question - but there are ways I could see it working. If you do this, then, the Strong result is very good for the characters, and the Weak result is perhaps less so, but still generally quite good.
The problem I run into myself with that is that if you use that method, it becomes hard to argue that things aren't worse if the player decide not to play the challenge...in which case, again, I feel like it probably shouldn't be optional because it impacts the story in a notable way. And that's exactly where I've ended up when I've reflected on the few times I've used optional challenges...I end up feeling like what I did was render a part of the story optional when it was actually going to have a definite impact.
And that's the point I keep coming back to myself in considering this - I just generally can't justify putting a challenge down and treating it as "optional." When I put a challenge down, it means that a notable event has started in the story, and the players, through their card plays, need to see where it goes. It needs to get to some conclusion or another, so that we know where the story goes after it. When I find myself thinking of perhaps telling my players a challenge is optional, I start instead thinking of whether it should be there yet at all.
But: I know that this is a technique some other narrators have used in the past, and I'd very much be interested to hear others' thoughts on it. Have you used optional challenges? What did they represent in your game? And how did you ensure that you knew it was fine to move the game forward? Write in, and let me know!
Sunday 13 September 2020
MASTER PSYCHIC READER~ ACCURATE & AMUSING
Your first 3 minutes are FREE talking live with me.
Please visit my website at: https://tinyurl.com/ycyfbv5g
Or, call me right now at: 1-800-275-5336 x0160
Saturday 12 September 2020
Shoot Your Goo, Fun Puzzle Platformer Made With FTEQW In 48H!
Shoot Your Goo is (despite its name) a family friendly puzzle platformer made in just 48h for the GMTK Game Jam 2019. It could be described as a mix of Angry Birds and mini-golf, but see for yourself:
The source-code can be found here, and you can head over to InsideQC to discuss with the creators.
The team who made this has become quite proficient in turning out interesting game prototypes (Bloodletter, Escape from Space etc.) with the very cool FTEQW engine... a much advanced Quake1 derived engine (unofficial developer's documentation on the QuakeWiki & source code).
There are also a few other interesting projects with FTEQW, such as CubiQuake, FreeCS, and it has even gotten to the point of being nearly ready as a functional drop in replacement engine for Xonotic.
Semi-OT: Trenchbroom, the modern take on Quake engine mapping is continuing with great improvements and should be on your list to check out for sure
Discuss on our forums here.
Read More :- "Shoot Your Goo, Fun Puzzle Platformer Made With FTEQW In 48H!"
The source-code can be found here, and you can head over to InsideQC to discuss with the creators.
The team who made this has become quite proficient in turning out interesting game prototypes (Bloodletter, Escape from Space etc.) with the very cool FTEQW engine... a much advanced Quake1 derived engine (unofficial developer's documentation on the QuakeWiki & source code).
There are also a few other interesting projects with FTEQW, such as CubiQuake, FreeCS, and it has even gotten to the point of being nearly ready as a functional drop in replacement engine for Xonotic.
Semi-OT: Trenchbroom, the modern take on Quake engine mapping is continuing with great improvements and should be on your list to check out for sure
Discuss on our forums here.
Tech Book Face Off: How To Design Programs Vs. Structure And Interpretation Of Computer Programs
After reading and reviewing dozens of books on programming, software development, and computer science, I've finally come to a couple of books that I should have read a long time ago. I'm not quite sure why I didn't read these two books earlier. Distractions abound, and I always had something else I wanted to read first. I still wanted to see what they had to offer, so here I am reading How to Design Programs by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishnamurthi and Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman, and Julie Sussman. As I understand it, these books are meant to introduce new students to programming so not reading them until now will probably make it difficult to accurately critique them from the perspective of the target audience. I'm still going to give it a try.
The programming language used in this book as the vehicle for learning was a variation on Scheme called BSL (Beginning Student Language) that had heavy restrictions on the language features available for use. For example, lists could not be constructed with (list <list of elements>) or '(<list of elements>), instead needing to be built up from (cons <element> <list>). These and other features were added with BSL+, ISL (Intermediate Student Language), and ISL+ as the reader progressed through the book.
I was not a big fan of this approach, since it was tedious to learn the wrong way first (or at least the way nobody actually writes code) and then learn the right way that also makes more sense. Starting with the reduced forms of the language didn't add anything to the explanations, and it mostly served as a point of frustration as the reader was forced through unnecessary tedium until the nicer language features were introduced. It was also not clear by the end that ISL+ was equivalent to the full Scheme programming language, so by the time the student reached the end of the book, they wouldn't even be sure that they had learned a real programming language.
The book was quite ambitious, since learning how to design programs starting from square one actually involves learning three almost distinct things at once: the syntax of a programming language, how to write code, and how to program. The first task is about learning what a programming language is, what keywords and punctuation are available, and what it all does when put together in the correct structure. This task alone can be overwhelming for the new student. Then, the second task, learning to write code, involves taking a small, well-defined problem statement, thinking up a solution to it, and translating that solution into code that can execute in the newly learned programming language. Normally, once some part of the language has been learned, the first two tasks can be done together, and they support each other as the student practices them both.
The third task, learning how to program, is a much deeper activity that takes a much longer time to become proficient. Learning how to program is not just about solving bigger problems that may not be self-contained or well-defined. It's about learning how to organize all of the required code to solve the problem in a way that makes that code easy to understand, is less likely to suffer from bugs, is testable (and tested), and hopefully is flexible and extensible. I'm not convinced that this book taught this much more advanced skill, or at least not thoroughly.
The book starts out with a little prologue chapter entitled "How to Program." It gives a short introduction and a few examples of how to write some simple programs in BSL, and here the authors try to get the reader excited about what they'll be learning in the rest of the book. I had some misgivings about it. They have a strange way of trying to connect with the reader by disparaging various subjects that the reader is likely taking in school, or at least has fresh memories about, like physics:
The rest of the book is split into six major sections with "intermezzos" between each section. I'm not quite sure why the intermezzos are there because they just seem to continue on with more topics that would fit in as additional chapters within the six sections, but that doesn't matter much. The first section introduces BSL features in more detail than the prologue, and it also lays out the recommended steps of a design process in chapter 3. These steps are touted as the steps for how to design a program, but they're really steps for how to design a function. The process is fine as far as it goes, but it doesn't really scale to large programs. This process is used and refined throughout the book.
The first section only introduced language features that allow for fixed-size data, so the next section introduces lists and recursion. It's a whole five chapters on lists, including basically a whole chapter of problems for the reader to solve. I don't remember lists being quite so hard to understand that it would require five chapters to adequately get the point across, especially with lists being a fundamental data structure of Scheme. Sorry, BSL+. Part of the problem is that the authors seem to explain things in as many words as possible. The text ends up plodding along with slow, tedious explanations, some of which don't even make much sense.
Another part of the problem of understanding in this book is the poor choice of variable names. When the authors are not using single-letter names (shudder), they're using names like alos. What is alos? Is it like, "Alos, poor Yorick! I new him, Horatio?" No, that's not right. That would be 'alas.' Instead, alos means "a list of strings." But why not just use list-of-strings, or even strings if you're into the whole brevity thing. The point is, these super abbreviated and truncated variable names make things more confusing than they need to be, because you have to keep the translation to the full name in your head along with the meaning of the variable and the rest of the code. Using full words for variable names makes the code so much more readable and understandable. It's not like we're working under any space constraints with the text of the code, except for the constraints of our own working memory.
The third section goes into detail on functions and how they enable abstractions that will make the programmer's life easier. Abstractions allow the programmer to solve low-level problems once and then think about harder problems from a higher level. It's a critical programming skill to learn. This section follows a similar format to the last one, with four chapters on functions done in excruciating detail, one of which is full of problems for the reader. We also advance to ISL for this section, and near the end we achieve the final level up to ISL+. Yipee! I remember hating when textbooks would introduce one way of doing things and then later contradict themselves and reveal the real way of doing it. This failing is worse with simplified languages, so I'm pretty tired of "student languages" by now.
The next section covers intertwined data, which is a convoluted title for a section that doesn't have a strong theme. The chapters in this section range from introducing trees to building a simple interpreter to processing multiple lists in parallel. The fifth section focuses on recursion for five chapters, and here they make the distinction between structural recursion, which is based on scanning lists, and generative recursion, which is more general and doesn't use lists as the looping mechanism. The final section discusses accumulators that are used with recursion to enable calculating properties of data that requires keeping track of additional state during the recursion. It's basically passing extra state variables in the recursive call in order to calculate aggregate or cumulative values on the data. All of these sections continued to have chapters near the end that were filled with extra problems for the reader.
This book was super long at nearly 750 pages—one of the longest programming books I've read in a while—and it did not seem like it covered enough ground to warrant that length. There were also 528 problems in total, so a huge amount of practice if the reader worked through all of the problems. Most of the problems were pretty decent, and they stayed relevant and reasonable for the material covered beforehand. But the book as a whole didn't hold up to its goal of teaching the beginner how to design programs. Learning how to program is a huge undertaking, and I don't believe it's possible to adequately cover that whole process in one book. On top of that, the level of discussion in much of the book was too complex for the beginner, and it would just as likely serve to confuse them as to teach them. Conversely, it doesn't seem to work well as a second programming book, either because it is so slow and tedious and long. By the end all we've learned is the basics of Scheme, lists, functions, and recursion. The Little Schemer taught much more in a more entertaining way in less than 200 pages. I can't recommend slogging through this book instead.
Read More :- "Tech Book Face Off: How To Design Programs Vs. Structure And Interpretation Of Computer Programs"
 | VS. |  |
How to Design Programs
While I have read many programming books as ebooks on my Kindle, this is the first book I've read as an online book. It's available in print version, but the online version looked nicely formatted and was heavily cross-linked, which was quite helpful. Also, since the book was right alongside my code editor, I could easily try out the problems and copy-paste code into the editor to run it.The programming language used in this book as the vehicle for learning was a variation on Scheme called BSL (Beginning Student Language) that had heavy restrictions on the language features available for use. For example, lists could not be constructed with (list <list of elements>) or '(<list of elements>), instead needing to be built up from (cons <element> <list>). These and other features were added with BSL+, ISL (Intermediate Student Language), and ISL+ as the reader progressed through the book.
I was not a big fan of this approach, since it was tedious to learn the wrong way first (or at least the way nobody actually writes code) and then learn the right way that also makes more sense. Starting with the reduced forms of the language didn't add anything to the explanations, and it mostly served as a point of frustration as the reader was forced through unnecessary tedium until the nicer language features were introduced. It was also not clear by the end that ISL+ was equivalent to the full Scheme programming language, so by the time the student reached the end of the book, they wouldn't even be sure that they had learned a real programming language.
The book was quite ambitious, since learning how to design programs starting from square one actually involves learning three almost distinct things at once: the syntax of a programming language, how to write code, and how to program. The first task is about learning what a programming language is, what keywords and punctuation are available, and what it all does when put together in the correct structure. This task alone can be overwhelming for the new student. Then, the second task, learning to write code, involves taking a small, well-defined problem statement, thinking up a solution to it, and translating that solution into code that can execute in the newly learned programming language. Normally, once some part of the language has been learned, the first two tasks can be done together, and they support each other as the student practices them both.
The third task, learning how to program, is a much deeper activity that takes a much longer time to become proficient. Learning how to program is not just about solving bigger problems that may not be self-contained or well-defined. It's about learning how to organize all of the required code to solve the problem in a way that makes that code easy to understand, is less likely to suffer from bugs, is testable (and tested), and hopefully is flexible and extensible. I'm not convinced that this book taught this much more advanced skill, or at least not thoroughly.
The book starts out with a little prologue chapter entitled "How to Program." It gives a short introduction and a few examples of how to write some simple programs in BSL, and here the authors try to get the reader excited about what they'll be learning in the rest of the book. I had some misgivings about it. They have a strange way of trying to connect with the reader by disparaging various subjects that the reader is likely taking in school, or at least has fresh memories about, like physics:
Physics?!? Well, perhaps you have already forgotten what you learned in that course. Or perhaps you have never taken a course on physics because you are way too young or gentle. No worries.I don't understand this kind of writing. It's not cool and it's not helpful to pretend to joke along with students about how much physics or mathematics or any subject sucks. It drives me nuts. Why can't we encourage students to take more of an interest in these subjects by showing how the knowledge can be useful, interesting, and dare I say, fun?! Thankfully, these comments don't continue in the rest of the book, but it's still irritating that they subtly perpetuate this anti-learning bias. It ended up coloring my opinion of the book in a negative way.
The rest of the book is split into six major sections with "intermezzos" between each section. I'm not quite sure why the intermezzos are there because they just seem to continue on with more topics that would fit in as additional chapters within the six sections, but that doesn't matter much. The first section introduces BSL features in more detail than the prologue, and it also lays out the recommended steps of a design process in chapter 3. These steps are touted as the steps for how to design a program, but they're really steps for how to design a function. The process is fine as far as it goes, but it doesn't really scale to large programs. This process is used and refined throughout the book.
The first section only introduced language features that allow for fixed-size data, so the next section introduces lists and recursion. It's a whole five chapters on lists, including basically a whole chapter of problems for the reader to solve. I don't remember lists being quite so hard to understand that it would require five chapters to adequately get the point across, especially with lists being a fundamental data structure of Scheme. Sorry, BSL+. Part of the problem is that the authors seem to explain things in as many words as possible. The text ends up plodding along with slow, tedious explanations, some of which don't even make much sense.
Another part of the problem of understanding in this book is the poor choice of variable names. When the authors are not using single-letter names (shudder), they're using names like alos. What is alos? Is it like, "Alos, poor Yorick! I new him, Horatio?" No, that's not right. That would be 'alas.' Instead, alos means "a list of strings." But why not just use list-of-strings, or even strings if you're into the whole brevity thing. The point is, these super abbreviated and truncated variable names make things more confusing than they need to be, because you have to keep the translation to the full name in your head along with the meaning of the variable and the rest of the code. Using full words for variable names makes the code so much more readable and understandable. It's not like we're working under any space constraints with the text of the code, except for the constraints of our own working memory.
The third section goes into detail on functions and how they enable abstractions that will make the programmer's life easier. Abstractions allow the programmer to solve low-level problems once and then think about harder problems from a higher level. It's a critical programming skill to learn. This section follows a similar format to the last one, with four chapters on functions done in excruciating detail, one of which is full of problems for the reader. We also advance to ISL for this section, and near the end we achieve the final level up to ISL+. Yipee! I remember hating when textbooks would introduce one way of doing things and then later contradict themselves and reveal the real way of doing it. This failing is worse with simplified languages, so I'm pretty tired of "student languages" by now.
The next section covers intertwined data, which is a convoluted title for a section that doesn't have a strong theme. The chapters in this section range from introducing trees to building a simple interpreter to processing multiple lists in parallel. The fifth section focuses on recursion for five chapters, and here they make the distinction between structural recursion, which is based on scanning lists, and generative recursion, which is more general and doesn't use lists as the looping mechanism. The final section discusses accumulators that are used with recursion to enable calculating properties of data that requires keeping track of additional state during the recursion. It's basically passing extra state variables in the recursive call in order to calculate aggregate or cumulative values on the data. All of these sections continued to have chapters near the end that were filled with extra problems for the reader.
This book was super long at nearly 750 pages—one of the longest programming books I've read in a while—and it did not seem like it covered enough ground to warrant that length. There were also 528 problems in total, so a huge amount of practice if the reader worked through all of the problems. Most of the problems were pretty decent, and they stayed relevant and reasonable for the material covered beforehand. But the book as a whole didn't hold up to its goal of teaching the beginner how to design programs. Learning how to program is a huge undertaking, and I don't believe it's possible to adequately cover that whole process in one book. On top of that, the level of discussion in much of the book was too complex for the beginner, and it would just as likely serve to confuse them as to teach them. Conversely, it doesn't seem to work well as a second programming book, either because it is so slow and tedious and long. By the end all we've learned is the basics of Scheme, lists, functions, and recursion. The Little Schemer taught much more in a more entertaining way in less than 200 pages. I can't recommend slogging through this book instead.
Structure and Interpretation of Computer Programs (SICP)
This book was the textbook for the entry-level computer science course at MIT for a number of years. I, unfortunately, was unaware of it until after I had finished college (not at MIT) and had come across it mentioned in a blog post by Steve Yegge, I think. Ah, yes, here it is. Apparently, that's also where I got the idea to read How to Design Programs, but fortunately, SICP was a better recommendation. I also didn't have the same issues with the book's humor that Steve did. I didn't mind the silly names of the students in the exercises, (you always know that Louis Reasoner got it wrong; you just have to figure out how) and some of the other jokes were actually kind of funny:
SICP is split into five fairly balanced chapters. Each chapter starts off easy with an introduction to the material covered in the chapter and more detailed explanations of the mechanics of Scheme or the interpreter or whatever is the topic for the chapter. As things develop, the difficulty ramps up until near the end you can feel your brain going numb and draining out of your ears. Then you get a breather at the beginning of the next chapter with another gentle introduction.
The first chapter starts off with the requisite intro-to-the-language stuff that every book for a new programming language needs. After covering Scheme's operators and primitives, we move on to functions and immediately jump into recursion. By the end of the chapter we're learning about how to pass functions around as arguments and return values, and I wonder how an entry-level student could really grok all of this in a semester course. This is just chapter 1!
Chapter 2 teaches us all about how to structure and process data in Scheme. Since the fundamental data structure in Scheme is the list, this means we're going to get very comfortable with list processing (which is how Lisp gets its name, see?). Between these first two chapters, we gain a thorough understanding of the foundations of Scheme and how to put together Scheme programs to do interesting things with data. Even after reading so many books on programming and practicing it in the field for a couple of decades, I was quite enjoying this "beginner" programming book.
Helpful exercises are interspersed with the text throughout the book, generally at the end of each subsection, and they are quite well thought-out exercises. With 356 exercises in all, they provide a ton of practice to ensure that the reader is understanding the material. At first they seem to be somewhat random but standard fare, asking the reader to solve programming problems with rational and complex numbers and other such mundane mathematical problems. Then, near the end of chapter 2, we learn how to implement generic arithmetic operations that can automatically promote and demote arguments from one class of number to another. It's pretty slick, if somewhat impractical. I can't think of a system where this behavior would be necessary, but it's cool to get it working nonetheless.
The next chapter kind of let the wind out of my sails a bit. The previous chapters had really exemplified the elegance of Scheme with beautiful functional programming, but now we had to learn about the mucky reality of objects and mutable state. This chapter introduces the set! operations that allow variables to be changed in place instead of creating and returning new variables that are set with the define primitive. The allowance for changing variable values enables the creation and maintenance of objects with state, and this complicates the analysis of program execution because now we have to deal with side effects. The authors did a nice job of explaining when objects are useful, because we don't want to use them for everything:
Chapter 4 tackles the task that all Lisp books seem to reach eventually, and that is to write an interpreter. How to Design Programs did it. The Little Schemer did it. SICP does it to, but it doesn't simply stop with one interpreter. No, after the basic interpreter, we go on to write a lazy interpreter that does delayed evaluation. Then, we write another interpreter that does ambiguous evaluation, meaning the programmer can specify a problem and an input range for that problem, and the interpreter will perform a search to find a solution (or every solution) that satisfies the constraints of the problem. Think that's enough? Not now that we're on a role! The final interpreter extends Scheme to be a logic language similar to Prolog. You would think the previous ambiguous interpreter would be a good basis for this extension, but the text uses the lazy interpreter as the base instead. Extending the ambiguous interpreter is left as an exercise.
Things are getting pretty mind-bending by now, so why don't we finish things off with something truly warped. The last chapter goes through implementing a register machine model in Scheme. What's a register machine? It's basically a model of a computer that uses fixed registers, a load-store memory model, and low-level operations to execute an assembly language. Then we need something to run on this register machine, so we modify the interpreter to run on top of this assembly language. Now let's step back and think about what we've done. We now have an interpreter that takes in Scheme code, spits out assembly code, and runs it on a model of a computer (the register machine); and this is all done inside another Scheme interpreter running on a real computer. Wat? Let's think again about what we've done:
While these last two chapters were fun and fascinating, they were quite a stretch for one book. The first three chapters plus the basic Scheme interpreter would have been enough for the learning experience. I'm not sure how much practical knowledge readers would get out of the rest of the interpreters, the register machine, and the compiler. The explanations became very mechanical and it felt like a major effort just to fit in the code listings and brief descriptions while still keeping the book around 600 pages. Beyond the issue of cramming a bunch of complex stuff in the last chapter and a half of the book, there are much better books out there on compilers and interpreters, like the dragon book or Writing Compilers and Interpreters, that go into more detail and explain those details more thoroughly. Likewise for machine languages and computer architecture, if you really want to understand the underlying machine language and hardware, Computer Architecture: A Quantitative Approach is excellent. Although, for a lighter introduction, Computer Organization and Design might be a better place to start.
That criticism notwithstanding, SICP is an excellent book on both how to write programs in Scheme and how to write a Scheme interpreter. It's a solid textbook for a second course in programming, but not a first course. I can't imagine most entry-level students would grok everything this book tries to present, so it would be good to have some other programming language under your belt before tackling this beast. Given its age, it's still surprisingly relevant as a programming textbook, and quite enlightening.
SICP is far and away the better book in this face off. True, How to Design Programs is meant for a less technical audience, but I'm not convinced that it would be an appropriate book for non-programmers, either. Scheme is just not the right introductory language, and something like Python or Ruby would be a much better learning language. Taking that consideration out of the equation, SICP packs a ton more content into 150 less pages, and it goes in much more depth on both basic programming concepts like lists and functions, and advanced concepts like streams and interpreters. Did I mention it also uses way better variable names? The code is much easier to understand as a result, and it's only the complexity of the concepts later in the book that make that code difficult.
Definitely pass on How to Design Programs, but if you're in the mood to level-up your fundamental programming knowledge, give SICP a look. If you're so inclined to read it online, check out this version at Sara Bander's GitHub site. It's rendered in a beautiful Linux Libertine font that's an absolute joy to read on a screen, and the footnotes come up in text boxes when clicked. It's the best experience I've had reading an ebook.
In testing primality of very large numbers chosen at random, the chance of stumbling upon a value that fools the Fermat test is less than the chance that cosmic radiation will cause the computer to make an error in carrying out a "correct" algorithm. Considering an algorithm to be inadequate for the first reason but not for the second illustrates the difference between mathematics and engineering.I mean, come on. That's not half bad for a computer science joke. The majority of the book was not about fun and games, though. It's a serious book on introducing the computer science student to how programming languages—particularly Scheme—work.
SICP is split into five fairly balanced chapters. Each chapter starts off easy with an introduction to the material covered in the chapter and more detailed explanations of the mechanics of Scheme or the interpreter or whatever is the topic for the chapter. As things develop, the difficulty ramps up until near the end you can feel your brain going numb and draining out of your ears. Then you get a breather at the beginning of the next chapter with another gentle introduction.
The first chapter starts off with the requisite intro-to-the-language stuff that every book for a new programming language needs. After covering Scheme's operators and primitives, we move on to functions and immediately jump into recursion. By the end of the chapter we're learning about how to pass functions around as arguments and return values, and I wonder how an entry-level student could really grok all of this in a semester course. This is just chapter 1!
Chapter 2 teaches us all about how to structure and process data in Scheme. Since the fundamental data structure in Scheme is the list, this means we're going to get very comfortable with list processing (which is how Lisp gets its name, see?). Between these first two chapters, we gain a thorough understanding of the foundations of Scheme and how to put together Scheme programs to do interesting things with data. Even after reading so many books on programming and practicing it in the field for a couple of decades, I was quite enjoying this "beginner" programming book.
Helpful exercises are interspersed with the text throughout the book, generally at the end of each subsection, and they are quite well thought-out exercises. With 356 exercises in all, they provide a ton of practice to ensure that the reader is understanding the material. At first they seem to be somewhat random but standard fare, asking the reader to solve programming problems with rational and complex numbers and other such mundane mathematical problems. Then, near the end of chapter 2, we learn how to implement generic arithmetic operations that can automatically promote and demote arguments from one class of number to another. It's pretty slick, if somewhat impractical. I can't think of a system where this behavior would be necessary, but it's cool to get it working nonetheless.
The next chapter kind of let the wind out of my sails a bit. The previous chapters had really exemplified the elegance of Scheme with beautiful functional programming, but now we had to learn about the mucky reality of objects and mutable state. This chapter introduces the set! operations that allow variables to be changed in place instead of creating and returning new variables that are set with the define primitive. The allowance for changing variable values enables the creation and maintenance of objects with state, and this complicates the analysis of program execution because now we have to deal with side effects. The authors did a nice job of explaining when objects are useful, because we don't want to use them for everything:
The object model approximates the world by dividing it into separate pieces. The functional model does not modularize along object boundaries. The object model is useful when the unshared state of the "objects" is much larger than the state that they share. An example of a place where the object viewpoint fails is quantum mechanics, where thinking of things as individual particles leads to paradoxes and confusions. Unifying the object view with the functional view may have little to do with programming, but rather with fundamental epistemological issues.The second half of the chapter continues on from objects with concurrency, which does not play nice with mutable state at all, and introduces streams in order to deal with that problem. Streams are a mechanism that enables lazy execution of functions on lists. Instead of performing all of the computations on a list at the time the processing function is called, the function will return another function that will do the computation on its corresponding list element at the time that element is needed to be read. It's wild and confusing at first, but working through the exercises helps clarify how it all works.
Chapter 4 tackles the task that all Lisp books seem to reach eventually, and that is to write an interpreter. How to Design Programs did it. The Little Schemer did it. SICP does it to, but it doesn't simply stop with one interpreter. No, after the basic interpreter, we go on to write a lazy interpreter that does delayed evaluation. Then, we write another interpreter that does ambiguous evaluation, meaning the programmer can specify a problem and an input range for that problem, and the interpreter will perform a search to find a solution (or every solution) that satisfies the constraints of the problem. Think that's enough? Not now that we're on a role! The final interpreter extends Scheme to be a logic language similar to Prolog. You would think the previous ambiguous interpreter would be a good basis for this extension, but the text uses the lazy interpreter as the base instead. Extending the ambiguous interpreter is left as an exercise.
Things are getting pretty mind-bending by now, so why don't we finish things off with something truly warped. The last chapter goes through implementing a register machine model in Scheme. What's a register machine? It's basically a model of a computer that uses fixed registers, a load-store memory model, and low-level operations to execute an assembly language. Then we need something to run on this register machine, so we modify the interpreter to run on top of this assembly language. Now let's step back and think about what we've done. We now have an interpreter that takes in Scheme code, spits out assembly code, and runs it on a model of a computer (the register machine); and this is all done inside another Scheme interpreter running on a real computer. Wat? Let's think again about what we've done:
From this perspective, our evaluator is seen to be a universal machine. It mimics other machines when these are described as Lisp programs. This is striking. Try to imagine an analogous evaluator for electrical circuits. This would be a circuit that takes as input a signal encoding the plans for some other circuit, such as a filter. Given this input, the circuit evaluator would then behave like a filter with the same description. Such a universal electrical circuit is almost unimaginably complex. It is remarkable that the program evaluator is a rather simple program.It's mind-blowing, really, but we're not done. The last part of the last chapter walks through building a compiler so that we can compile Scheme functions down to the assembly language of the register machine, and modify the register machine so that it can run the assembly code directly instead of it being fed from the interpreter. If that's not enough, the last two exercises are simply about writing a scheme interpreter in C and a compiler in C instead of what we just did in Scheme. Easy-peasy, right?
While these last two chapters were fun and fascinating, they were quite a stretch for one book. The first three chapters plus the basic Scheme interpreter would have been enough for the learning experience. I'm not sure how much practical knowledge readers would get out of the rest of the interpreters, the register machine, and the compiler. The explanations became very mechanical and it felt like a major effort just to fit in the code listings and brief descriptions while still keeping the book around 600 pages. Beyond the issue of cramming a bunch of complex stuff in the last chapter and a half of the book, there are much better books out there on compilers and interpreters, like the dragon book or Writing Compilers and Interpreters, that go into more detail and explain those details more thoroughly. Likewise for machine languages and computer architecture, if you really want to understand the underlying machine language and hardware, Computer Architecture: A Quantitative Approach is excellent. Although, for a lighter introduction, Computer Organization and Design might be a better place to start.
That criticism notwithstanding, SICP is an excellent book on both how to write programs in Scheme and how to write a Scheme interpreter. It's a solid textbook for a second course in programming, but not a first course. I can't imagine most entry-level students would grok everything this book tries to present, so it would be good to have some other programming language under your belt before tackling this beast. Given its age, it's still surprisingly relevant as a programming textbook, and quite enlightening.
SICP is far and away the better book in this face off. True, How to Design Programs is meant for a less technical audience, but I'm not convinced that it would be an appropriate book for non-programmers, either. Scheme is just not the right introductory language, and something like Python or Ruby would be a much better learning language. Taking that consideration out of the equation, SICP packs a ton more content into 150 less pages, and it goes in much more depth on both basic programming concepts like lists and functions, and advanced concepts like streams and interpreters. Did I mention it also uses way better variable names? The code is much easier to understand as a result, and it's only the complexity of the concepts later in the book that make that code difficult.
Definitely pass on How to Design Programs, but if you're in the mood to level-up your fundamental programming knowledge, give SICP a look. If you're so inclined to read it online, check out this version at Sara Bander's GitHub site. It's rendered in a beautiful Linux Libertine font that's an absolute joy to read on a screen, and the footnotes come up in text boxes when clicked. It's the best experience I've had reading an ebook.
Thursday 3 September 2020
Movie Reviews: X-Men Dark Phoenix, Shazam, Alita: Battle Angel, Rocketman
Dark Phoenix: I liked this movie more than the masses did, apparently. Not that I thought it was a great movie, but it was better than the mess that was Apocalypse.
I think the biggest hate directed at this movie comes from the fact that this movie spits on any concept of fitting into the the other movies' timeline: it doesn't end in a way that fits in, and it takes place in the wrong decade. While I admit that it would have been better had it fit the timeline, I don't ding it any points for NOT doing so. I take the movie as it is, just like I don't care if it matches whatever is supposed to have happened in the comic books.
The story moves well enough: Jean Gray is a mutant with telekinesis, energy containment and blasts, and some mind reading. As a girl, she accidentally kills her parents. Charles Xavier takes her in and raises her in his school for gifted children. Some time later, on a rescue mission to save regular people in a space craft, she is exposed to and absorbs some kind of massive cloud of energy. She begins to lose control of her powers and some of her personality. During this process, she comes to find out that Charles "protected" her by lying to her about some things from her past and erecting some blocks on her power that were dangerous to her and others. Unbeknownst to her and everyone else, the energy she absorbed is some kind of power wanted by shape-shifting aliens who want to use it to destroy Earth. They try to win her over to their side and/or retake control of her power. Or something like that.
The movie is acted well and there is nothing wrong with the special effects, sound, or directing. One problem with the movie is that the aliens just kind of meander around; it's hard to figure out their exact powers or plan, they don't seem all that vicious (except for their ultimate goal), they don't exhibit any kind of emotion, and they are sometimes vulnerable to our heroes attacks and sometimes not without explanation as to why. So it's hard to relate to the struggle against them. Jean Gray doesn't emerge as much of a character, just someone who wanders around glassy eyed and generally upset. And Magneto is a shadow of his former self and not that interesting to watch. The others are not too bad.
The biggest problem is that the plot feels awfully like Captain Marvel's, which was a pretty terrific movie: a woman lied to by people who put blocks on her power, told to control her emotions, fighting shape shifting aliens. Captain Marvel manages to make the main character's smug constraints on her emotion seem human; she even smiles and laughs once in a while. This movie just isn't as good. It's also a reworking of the X-Men III: The Last Stand (from the previous timeline), which wasn't too bad of a movie either, although it suffered from some other, different, problems.
But at least this movie was watchable.
Shazam: Another DC movie, this one is pretty forgettable. A boy gets a suit that give him superpowers for reasons, and someone else want his power while others want to kill him, so there is fighting and a lot of young boys giggling. He is a foster kid who is sent from home to home, also for reasons, and ends up with a bunch of other foster kids in a home of an altruistic couple, and all of the other kids also join in the fun. The supernatural elements were ridiculous and even hokey. The whole plot was silly.
This movie is like if Spider-man happened, but instead of great action, a weighty sense of importance, great moral questions, excitement, tension, and good characters, a bunch of adolescent boys sat around and imagined how cool it would be to have a superpower. About the only good parts are the brief scenes of the boy's search for his mother and his mother's reaction to this.
Alita: Battle Angel: I gave this a shot, but it was only marginally better than Elysim, another story about people stuck on-world trying to get to the floating ship. Okay, Elysium was really bad, and this wasn't quite that bad, but it sure wasn't good.
You can kind of see through this animated movie how the comic source material (that I never heard of) could be pretty good. Flashes of some interesting world-building, characters, and plots hover around at the edges of the screen, but then they are gone, leaving us with a simple matter of roller skates, robot parts, races, a dull romance, silly action scenes, and nothing in the way of any characters that we care about. Highly unmemorable.
Rocketman: Taron Egerton inhabits adult Elton John in this biopic that will inevitably be compared to the recent Bohemian Rhapsody but is nothing like it, really. The latter is allegedly true, but mostly fiction, with weird changes to the true story that you wouldn't know were changes if you didn't know the actual history of Queen. It is also about Freddy Mercury's descent from drugs and promiscuity, but only mildly so; it is mostly about the music. Rocketman is a fantasy, but mostly true. It is a true musical with dramatic scenes or bridges breaking out into dance and song. The songs and drama are used to illustrate the character's feelings and experiences and the story is not about the music but about the descent, which is harsh and harrowing.
It is gripping and dazzling despite itself, much the way that Elton John was. Several songs are performed as showpieces, while others (mostly Goodbye Yellow Brick Road and Rocket Man) run through the more poignant scenes in chords and snippets. Elton was tolerated but unloved by his mother and her family, and rejected altogether by his father, even as an adult. He had a lifelong friendship with Bernie Taupin, who accepted him as a homosexual but was not one himself. Elton's descent includes pushing even Bernie away - temporarily - as depressed, drugged up, overly wealthy and indulged suicidal rock stars are likely to do. Except for the scenes with his parents, the story does not contain any real surprises, even for those who don't know anything about it, since it's pretty straightforward. But it is fun, or occasionally moving, to watch. And the music is great, even though it is all covers.
Read More :- "Movie Reviews: X-Men Dark Phoenix, Shazam, Alita: Battle Angel, Rocketman"
I think the biggest hate directed at this movie comes from the fact that this movie spits on any concept of fitting into the the other movies' timeline: it doesn't end in a way that fits in, and it takes place in the wrong decade. While I admit that it would have been better had it fit the timeline, I don't ding it any points for NOT doing so. I take the movie as it is, just like I don't care if it matches whatever is supposed to have happened in the comic books.
The story moves well enough: Jean Gray is a mutant with telekinesis, energy containment and blasts, and some mind reading. As a girl, she accidentally kills her parents. Charles Xavier takes her in and raises her in his school for gifted children. Some time later, on a rescue mission to save regular people in a space craft, she is exposed to and absorbs some kind of massive cloud of energy. She begins to lose control of her powers and some of her personality. During this process, she comes to find out that Charles "protected" her by lying to her about some things from her past and erecting some blocks on her power that were dangerous to her and others. Unbeknownst to her and everyone else, the energy she absorbed is some kind of power wanted by shape-shifting aliens who want to use it to destroy Earth. They try to win her over to their side and/or retake control of her power. Or something like that.
The movie is acted well and there is nothing wrong with the special effects, sound, or directing. One problem with the movie is that the aliens just kind of meander around; it's hard to figure out their exact powers or plan, they don't seem all that vicious (except for their ultimate goal), they don't exhibit any kind of emotion, and they are sometimes vulnerable to our heroes attacks and sometimes not without explanation as to why. So it's hard to relate to the struggle against them. Jean Gray doesn't emerge as much of a character, just someone who wanders around glassy eyed and generally upset. And Magneto is a shadow of his former self and not that interesting to watch. The others are not too bad.
The biggest problem is that the plot feels awfully like Captain Marvel's, which was a pretty terrific movie: a woman lied to by people who put blocks on her power, told to control her emotions, fighting shape shifting aliens. Captain Marvel manages to make the main character's smug constraints on her emotion seem human; she even smiles and laughs once in a while. This movie just isn't as good. It's also a reworking of the X-Men III: The Last Stand (from the previous timeline), which wasn't too bad of a movie either, although it suffered from some other, different, problems.
But at least this movie was watchable.
Shazam: Another DC movie, this one is pretty forgettable. A boy gets a suit that give him superpowers for reasons, and someone else want his power while others want to kill him, so there is fighting and a lot of young boys giggling. He is a foster kid who is sent from home to home, also for reasons, and ends up with a bunch of other foster kids in a home of an altruistic couple, and all of the other kids also join in the fun. The supernatural elements were ridiculous and even hokey. The whole plot was silly.
This movie is like if Spider-man happened, but instead of great action, a weighty sense of importance, great moral questions, excitement, tension, and good characters, a bunch of adolescent boys sat around and imagined how cool it would be to have a superpower. About the only good parts are the brief scenes of the boy's search for his mother and his mother's reaction to this.
Alita: Battle Angel: I gave this a shot, but it was only marginally better than Elysim, another story about people stuck on-world trying to get to the floating ship. Okay, Elysium was really bad, and this wasn't quite that bad, but it sure wasn't good.
You can kind of see through this animated movie how the comic source material (that I never heard of) could be pretty good. Flashes of some interesting world-building, characters, and plots hover around at the edges of the screen, but then they are gone, leaving us with a simple matter of roller skates, robot parts, races, a dull romance, silly action scenes, and nothing in the way of any characters that we care about. Highly unmemorable.
Rocketman: Taron Egerton inhabits adult Elton John in this biopic that will inevitably be compared to the recent Bohemian Rhapsody but is nothing like it, really. The latter is allegedly true, but mostly fiction, with weird changes to the true story that you wouldn't know were changes if you didn't know the actual history of Queen. It is also about Freddy Mercury's descent from drugs and promiscuity, but only mildly so; it is mostly about the music. Rocketman is a fantasy, but mostly true. It is a true musical with dramatic scenes or bridges breaking out into dance and song. The songs and drama are used to illustrate the character's feelings and experiences and the story is not about the music but about the descent, which is harsh and harrowing.
It is gripping and dazzling despite itself, much the way that Elton John was. Several songs are performed as showpieces, while others (mostly Goodbye Yellow Brick Road and Rocket Man) run through the more poignant scenes in chords and snippets. Elton was tolerated but unloved by his mother and her family, and rejected altogether by his father, even as an adult. He had a lifelong friendship with Bernie Taupin, who accepted him as a homosexual but was not one himself. Elton's descent includes pushing even Bernie away - temporarily - as depressed, drugged up, overly wealthy and indulged suicidal rock stars are likely to do. Except for the scenes with his parents, the story does not contain any real surprises, even for those who don't know anything about it, since it's pretty straightforward. But it is fun, or occasionally moving, to watch. And the music is great, even though it is all covers.
Tuesday 1 September 2020
Your August Search performance for 1solu.blogspot.com
Your August performance
on Google Search
on Google Search
123
Clicks (web)
5.02K
Impressions (web)
127
Pages with
first impressions
(estimated)
first impressions
(estimated)
Your content achievements
Top growing pages
Compared to previous month
Page
Clicks (web)
Top performing pages
How do people find you?
Top growing queries
Compared to previous month
+7 clicks (web)
+3 clicks (web)
+2 clicks (web)
Top performing queries
Google search type
By clicks
Web
123
Image
3
Video
0
Keep exploring your data to identify new opportunities
Was this email helpful?
You've received this transactional email because your site is listed in Google Search Console. You may unsubscribe from this type of message or add partners who should receive messages for this Search Console account
Google LLC, 1600 Amphitheatre Parkway Mountain View, CA 94043
Subscribe to:
Posts (Atom)