I turned the laptop off and only booted once from Puppy Linux's Xenialpup over the weekend. When I turned on the laptop (2017 HP Envy) to start working in Windows 10, today, for some reason the desktop remembered that I had at least one Google Chrome tab and a few apps open.

I also started a new Chrome window for my "main" work, and the laptop was aggressively swapping for maybe a half-hour, during which time things barely worked, or were just slow as hell -- whatever you want to call it.

Now that I've been working for a couple of hours, everything is working well, but this just serves as a point of evidence that Windows 10, right when it starts up, isn't exactly ready for "vigorous computing."

It took me a while to figure it out, but I finally have my Ruby environment set up in Puppy Linux's Xenialpup (based on Ubuntu 16.04) so I can use my BlogPoster app and also work on its code.

I didn't have any trouble installing Ruby and the ruby-nokogiri package from the Puppy Package Manager. But I couldn't get ruby-twitter to install. gem install wouldn't work -- I didn't have the ruby-dev package -- and I didn't see the Ubuntu package that I needed.

I looked at the problem again, and I figured out that I was missing a repository in the Puppy Package Manager. Once I added the "missing" repository (which involved checking a box -- nothing too difficult), I was able to install ruby-twitter and get my script running.

My next problem was the vi in Puppy. I think it really is vi and not Vim. I couldn't get any formatting commands like :set number to work, either in command mode or .vimrc. The fix for this was quick: I installed Vim from the Puppy Package Manager.

Now I can call the "old" vi, or the "newer" Vim as needed, and my BlogPoster script is running great.

I'm having some issues pasting links into the terminal, but that's something I could overcome. Right now it's a lot of awkward "middle" clicking on the mouse, which for practical purposes means clicking both buttons at once. I'm getting better at it, but I could also use Geany instead of Vim as my editor. I tested Geany with my Ruby script, and it does work.

In other development-related news for this Puppy system, I installed the Racket programming environment from the script provided by the project. So far it works pefectly. I started up DrRacket and was coding right away.

I am still working on my BlogPoster app, which will take a URL pasted into a terminal, grab the web page's title and make that title and link the basis for a blog and social post.

The app is written in Ruby and uses the Nokogiri and Twitter gems, among others. I have code that will allow me to eliminate Nokogiri, but that's a fairly "light" gem. The Twitter gem, which makes posting via the Twitter API easy, has a lot of dependencies, and that is the one I'd really like to get rid of in favor of native code.

But that's getting ahead of myself. The app, as it stands now, is a huge if/then loop with a lot of ungainly code. I did add some code that keeps the app from crashing if Nokogiri doesn't get a "real" (i.e. live) web page, or there are connectivity problems.

What I am doing now is re-writing the app with distinct and separate methods, which I'm thinking of as functions that can allow for more modularity and code reuse. I probably should be using Ruby classes to organize these methods, but I'm saving that for the next rewrite. Going from a monolith with a lot of repeated code to a bunch of modules (still probably accessed via an if/then structure, albeit a much shorter and manageable one) is enough improvement for the next version.

For the next version, I hope to have a GUI. I'm leaning toward the Tk toolkit because this app isn't very complicated, and Tk is probably the most well-known of a very motley bunch of desktop GUI solutions for Ruby. It may be a little ugly, but it is cross-platform, which is what I have been aiming for. I am open to other GUI toolkits, but even this recent article, An overview of desktop Ruby GUI development in 2018 doesn't offer much hope.

I'm also considering a full rewrite in another language. I'm working on Racket right now, but I'd have to figure out a lot of things to make it happen.

Hard-core CS geeks worship at the altar of SICP, the acronym for the seminal Structure and Interpretation of Computer Programs by MIT's Harold Abelson, Gerald Jay Sussman and Julie Sussman, the functional-programming deep dive into Scheme and head-scratching problems that set the curriculum for "beginning" computer science and engineering students at the Massachusetts Institute of Technology from the 1980s onward.

While SICP (yes, everybody uses the acronym) is considered a holy grail for serious computer scientists, it's hella hard to figure out. For me, programming "methods" that make me jump through intellectual hoops made of mathematics make it hard for me to learn the actual programming.

Confession time: I have the same problem with Robert Sedgewick and Kevin Wayne's Computer Science (aka Introduction to Programming in Java). The examples the book presents and the problems it asks students/readers to solve involve a lot of thinking about the mathematical nature of the problem, and the nitty-gritty of making programs seems to fade into the background. That's why books like Y. Daniel Liang's Introduction to Java Programming seem to meet up with where I'm at in terms of learning programming.

But what about the lofty, Lisp-y ideals of SICP? Even MIT has moved on, and the school itself has a contingent offering and developing another Scheme/Lisp-driven textbook, How to Design Programs (read the latest edition for free, and get the print book from MIT Press).

So why the shift away from SICP? The professor-authors of How to Design Programs lay out their reasoning in this 2004 paper, The Structure and Interpretation of the Computer Science Curriculum.

Here is the abstract from the paper written by the HTDP author-professors (and yes, HTDP, sometimes HtDP, is the accepted shorthand; books with fervant fans get acronyms):

Twenty years ago Abelson and Sussman’s Structure and Interpretation of Computer Programs radically changed the intellectual landscape of introductory computing courses. Instead of teaching some currently fashionable programming language, it employed Scheme and functional programming to teach important ideas. Introductory courses based on the book showed up around the world and made Scheme and functional programming popular. Unfortunately, these courses quickly disappeared again due to shortcomings of the book and the whimsies of Scheme. Worse, the experiment left people with a bad impression of Scheme and functional programming in general. In this pearl, we propose an alternative role for functional programming in the first-year curriculum. Specifically, we present a framework for discussing the first-year curriculum and, based on it, the design rationale for our book and course, dubbed How to Design Programs. The approach emphasizes the systematic design of programs. Experience shows that it works extremely well as a preparation for a course on object-oriented programming.

The paper gets right into what we might want to call "the SICP problem" (slight deletions marked by ellipses serve to remove references to charts, and emphasis is mine):

More generally, SICP doesn’t state how to program and how to manage the design of a program. It leaves these things implicit and implies that students can discover a discipline of design and programming on their own. The course presents the various uses and roles of programming ideas with a series of examples. Some exercises then ask students to modify this code basis, requiring students to read and study code; others ask them to solve similar problems, which means they have to study the construction and to change it to the best of their abilities. In short, SICP students learn by copying and modifying code, which is barely an improvement over typical programming text books.

SICP’s second major problem concerns its selection of examples and exercises. All of these use complex domain knowledge. ... Some early sections and the last two chapters cover topics from computer science ...

While these topics are interesting to students who use computing in electrical engineering and to those who already have significant experience of programming and computing, they assume too much understanding from students who haven’t understood programming yet and they assume too much domain knowledge from any beginning student who needs to acquire program design skills. On the average, beginners are not interested in mathematics and electrical engineering, and they do not have ready access to the domain knowledge necessary for solving the domain problems. As a result, SICP students must spend a considerable effort on the domain knowledge and often end up confusing domain knowledge and program design knowledge. They may even come to the conclusion that programming is a shallow activity and that what truly matters is an understanding of domain knowledge. Similarly, many students lack an understanding of the role of compilers, logical models of program execution, and so on. While first-semester students should definitely find out about these ideas, they should do so in a context that reaffirms the program design lessons.

In summary, while SICP does an excellent job shifting the focus of the first course to challenging computer science topics, it fails to recognize the role of the first course in the overall curriculum. In particular, SICP’s implicit approach to program design ideas and its emphasis on complex domains obscures the goal of the first course as seen from the perspective of a typical four-year curriculum.

The HTDP professors want to make clear that the secret sauce is not Scheme, per se. They use a tuned subset of the language, something made possible by the Racket IDE (formerly DrSceme, now DrRacket):

Combining SICP with a GUI-based development environment for Scheme won’t work better than plain SICP. The two keys to our success were to tame Scheme into teaching languages that beginners can handle and to distill well-known functional principles of programming into generally applicable design recipes. Then we could show our colleagues that a combination of functional programming as a preparation for a course on object-oriented programming is an effective and indeed superior alternative to a year on just C++, Java, or a combination.

This is a deep topic, and I'm more concerned with figuring out the best way to learn programming concepts and practices without going too deep into the quirks of a single programming language, or hitting roadblocks in the form of scientific and mathematical concepts that are ancillary to the practice of programming itself.

Of course there's always the pull between the foundational approach favored by HTDP and maybe even in the "major" Java and C++ textbooks and college courses that use them, versus the practical approach of "here's how to make a program that actually does things ... learn these in-demand frameworks ..." and more urgently, "develop a foundation in JavaScript/Ruby/Clojure and go forward from there."

I came across this fascinating article from LispODROID, Ergonomics of the Symbolics Lisp Machine - Reflections on the Developer Productivity, about an actual computer where the systems software and applications are coded in Lisp, with the machine's primary use case appearing to be coding more things in Lisp.

Here's a picture of one model of the Symbolics Lisp Machine, which the article says was sold between 1981 and 1993:

Being somewhat fascinated by Lisps (including Scheme) and Clojure), I was interested.

A look at the Wikipedia page for Symbolics told me that while the company was headquartered in Cambridge and later Concord, Massachusetts, it made the Symbolics Lisp Machine in the San Fernando Valley community of Chatsworth, long known as a home to warehouses and manufacturing facilities. (Also pornography. But that's pretty much the whole Valley then and now, but especially then.) The Chatsworth facility closed in July 2005.

In the beginning, Symbolics Lisp Machines cost $70,000. Each. In 1980s money.

Among the other tidbits: Symbolics.com is the first-ever registered .com domain. (It might be the first domain name of any kind ever registered, but that seems like a harder claim to prove.)

Symbolics was born at the MIT Artificial Intelligence Lab, and a desire to keep the Lisp code away from another MIT-launched company, Lisp Machines Inc., led MIT's Richard Stallman to create the free software movement.

I guess more than anything I'm fascinated by computer systems that really went their own way in terms of conception, design and philosophy. You can code in Lisp today on pretty much any computer, but a Lisp Machine? That's something you don't here about today in our Unix/Windows/nothing-else world.

Some other links:

• Probably the best place to start is Lisp Information and Resources. This page is deep with links.
• Lisp Lore: A Guide to Programming the Lisp Machine by Hank Bromley (via archive.org)
• Practical Common Lisp by Peter Seibel
• Basic Lisp Techniques by David J. Cooper
• Common Lisp: A Gentle Introduction to Symbolic Computation by David S. Touretzky
• Symbolics Lisp Machine Museum
• My Lisp Experiences and the Development of GNU Emacs by Richard Stallman
• Rebuttal to Stallman’s Story About The Formation of Symbolics and LMI by Dan Weinreb

I reserve the right to add to this article.

Since I am not anxious to either dual-boot or replace Windows 10 with Linux on my main laptop (HP Envy 15-as133cl 15t), I thought I would go back to the live distribution that introduced me to Linux -- Puppy -- and see if I could make it do all the things I want and need it to do.

My history with Puppy goes WAY back. I remember running version 2.13 on all kinds of hardware -- castoff laptops, converted thin clients. It would run on anything.

Back then I booted Puppy from CDs. Nowadays, with "modern" Puppy I could boot from USB and save either to the laptop's hard drive or another USB drive.

I downloaded the latest Puppy, Xenialpup, and used the Fedora Media Writer in Windows to put it on a 4GB USB flash drive. Xenialpup is UEFI-compatible, and after turning off Secure Boot on the laptop, I was off and running the super-fast JWM desktop that has traditionally anchored the Puppy live system.

Surprisingly, I was able to get a pretty comprehensive Ode blog-posting setup going. I have Unison: I pulled version 2.40 from an old Ubuntu package and used dpkg-deb to extract the binary since I need the old version and not the Ubuntu Xenial version of Unison, which is 2.48. (On a related note, why is it so hard to get a working Unison 2.48 for CentOS?)

I pulled all of my scripts from the Windows Subsystem for Linux, and I've already synced the blog over to this system.

Thankfully, Puppy's unusual running-as-root way of working didn't screw up my file ownership on the server, or in my Windows Subsystem for Linux copy of the filesystem.

There was one old problem from Linux that I haven't had to deal with in a while: While typing, I had the typical "jumping" behavior due to "interference" with the touchpad. Though Puppy doesn't have a "disable the touchpad while typing" setting, I was still able to solve the problem quickly by disabling tap-to-click with the system's straighforward Input Wizard configuration utility.

Where I ran into problems was with my development environment. I got Ruby to work in Puppy after a little effort, but I couldn't get the equivalent of ruby-dev to build things like the Ruby Twitter gem, and the gem itself, which is a package in Ubuntu, is not easily available for Xenialpup.

So I can post to the blog but can't use my "new" social-posting routine that turns URLs into Ode-compatible files and then sends the results to both the blog and Twitter.

I can't run all the gems I want in Ruby. But I am also exploring Clojure, so maybe that would work.

I did manage to install the JDK, though I had to add it to my path, opting to do so in /etc/profile, in order to get it to work.

I downloaded the Leiningen script and installed it. I can create new Leiningen projects, but the REPL errors out in spectacular fashion.

I haven't tried to get Node working yet, but the Ubuntu version is old (4.2.6), and I'm not confident that this installation will play well with the overall npm ecosystem. I could try to download and install direct, but there's potential for a lot of trouble.

The mechanics of Puppy are working great. Despite the unorthodox packaging and software installation, I did manage to get quite a few things working. I have my favorite text editor (Geany), the full LibreOffice suite via SFS package, the Firefox browser with all of my bookmarks synced, and a super-fast desktop packed with a lot of (mostly) home-grown utilities.

But I couldn't get Puppy to go the last mile.

So the "story" for me and Puppy Linux in 2018 is good until the point at which I want to do development work. At that point it's better to stay in Windows (and the WSL) or opt for a traditional Linux installation.

Now if only there was a "full" Debian live environment that allowed for persistence. Maybe there is. I'll be looking.