The Jupyter Notebook

Ah, the majestic Jupyter notebook.  The python programming method that we all love to hate.  For the unfamiliar, Jupyter notebooks are a python programming method that allows you to program and run python code in separate cells as you program.  There is a benefit to this for, say, doing math, since you can assign variables once and run the calculations in a separate block of code.  This prevents the user from needing to run the code in a terminal or IDE and rerun the assignment of variables.  You can also see line by line what each function is outputting by simply writing the variable name you want to output as another line.  In this way it's very similar to a debugger where you can stop the code at certain points and see the output as the code is executing.

If you've never needed to use Jupyter notebooks before, this probably sounds all well and good.  It is, but anyone who has ever needed to use the Jupyter notebook for a math class using Sympy or Numpy knows the frustration of opening up a notebook and spending 10-15 minutes (or longer, no judgments here) trying to figure out why the code won't work only to see that you forgot to execute the first block of code where the libraries are imported.  And you'll have to run every block of code in chronological order as soon as you open the notebook, or else it simply won't work.  None of the viewers for notebooks will run the code once you open it, to avoid overusing disk space and RAM, I suppose including the semi-popular viewer Anaconda, Google Colab, and Visual Studio.  It would also be very easy with this feature set on to turn python notebooks into a vehicle for viruses and trojans.  If Tom Scott's Youtube channel has taught me anything, however, it's to be afraid of every threat and possibility of error from all angles when coding.

Python notebooks can be a powerful tool as shown by the version of AI Dungeon 2 that can be run in a notebook.  I've been thinking a lot recently about python code that I have interacted with and wondering if it can be run as a more modular, modifiable code in a Jupyter notebook.  One example is the weekly playlist code that Ben has been working on for a while now.  The code removes songs from an old playlist and adds the new songs, as well as changing the name.  It might not be possible to write the code in a notebook due to the process of downloading the Spotipy library, but if it were, you could run the code in steps to make sure that each step of the process had properly finished before beginning the next part of the process.  I may post on here the version that Ben has written currently with edits alongside a version in a Jupyter notebook format.  It's just an interesting concept overall, and I think that this format should be considered by hobbyists for applications in the future just to see how far we can push the limits of the format.

More on Apple's transition to the ARM CPU

Just to add to my post from earlier, I'm adding on a few links to some helpful articles and editorials that better illustrate the points I'm trying to convey.

https://appleinsider.com/articles/20/02/25/why-apple-will-move-macs-to-arm-and-what-consumers-get

https://www.laptopmag.com/news/macbooks-with-arm-cpus-to-launch-in-2021-and-intel-should-be-worried

The Implications of a successful Mac ARM CPU

Recent rumors indicate that Apple may be switching from their current method of using Intel x86 CISC (Complex instruction set computing) CPUs to using ARM (Advanced RISC Machines) (RISC stands for Reduced instruction set computing).  Past all the acronyms, this could be a very exciting leap forward for the world of computing.  RISC CPUs have a more efficient use of computing power to accomplish the same things that a CISC computer can.

In recent years ARM computers have been getting more and more popular in tech communities, most notably the Raspberry Pi, everyone's favorite $40 computer the size of a credit card.  The Pi, however, isn't meant to act as a full desktop computer, and instead is angled more at hobbyists and small scale applications to accomplish tasks.

Personally, I think that the success of a Mac computer with an ARM CPU could change the way that we look at computers in the near future.  First off, the success of an ARM CPU in the new Mac computers would mean that the CPUs would be viable for companies like AMD (or even Intel) to start producing.  The biggest obstacle between where we are now and this ideal situation of ARM/CISC commercial availability is the widespread usage of the Windows Operating System.  In the ideal free market space, the success of ARM would create a vacuum for both existing and new operating systems to fill, like Debian, Ubuntu, or even Raspbian, the operating system designed specifically for the Raspberry Pi.  Chromium, the Google Chrome flavor for ARM based computers  makes this even more viable, porting everyone's favorite web browser to a whole new variety of operating systems and processors.

Honestly, I never really got the preference that people have for Mac OS.  As a lifelong Windows user, the idea of having an operating system that is so black box is mind-boggling.  Recently, however, I've been getting more and more used to the idea of a user-centered OS that just makes everything easier to deal with.  It's the same reason I've had an iPhone for a long time now, and couldn't switch to a Samsung even if I tried (although I'm ready to have a new discussion with the Google Pixel).  The past popularity of Linux operating systems before the rise of Intel proves that this kind of world can exist, and the standardization that has taken place over time for file types and computing programs means that we'll at least have some common ground to operate on.

I'm excited to see what can happen from this.  And I guess in the end, nothing really changing is also a possibility.