If you get everything you know about programming languages from Twitter, Reddit or blogs, you might miss that there are fascinating things in every programming language, old and new.

Or at least they're fascinating to me (or you) at any given moment.

My semester of programming at LA Valley College was heaving on using loops of all kinds, but we didn't get to separating things via functions or object-orientation.

I'm trying in my own code (currently Ruby) to make things more modular with blocks, some taking arguments and others not, and using classes is something I'm trying to wrap my head around.

I was reading one of my Java books (Sedgewick and Wayne's Computer Science) where the authors say in the long Chapter 2 (they're all long chapters) that separating operations into distinct functions is something programmers should strive to do.

It's the idea of organizing the code, and the ways the various languages allow (or maybe encourage you to do that) that I find fascinating at the moment.

Using Vim in my project has really helped my skills in that editor. That's what working with a couple dozen small Vim files per day will do for you.

I had to ssh into a server yesterday and set up a small script and a cron job, and I could feel how different that process was now that I can do more with Vim.

I can move around in files much more easily, and I know the basics of copy/move/paste, which is more than I could say before.

Clojure is trying to push me in the Emacs direction, and maybe I could get comfortable with that editor, but the universality of Vim/Vi is hard to ignore.

There's a random \n in my BlogPoster script. It doesn't show up all the time, but there are circumstances where it appears in the final output.

Am I inadvertently inserting it, or will I have to chomp it out? That is the question.

Update: I figured out where the random \n was being inserted, and I was able to .chomp it out in Ruby.

I'm not sure exactly why the random \n was being inserted. It could be in the editing operation of the file (I hope not, because that complicates things), or in the conversion of the edited file back to a Ruby variable.

According to its web page, "Reason lets you write simple, fast and quality type safe code while leveraging both the JavaScript & OCaml ecosystems."

Often called reasonml, it is based on OCaml, is integrated with NPM and compiles to JavaScript.

The language is a Facebook-sponsored project, so it's marketing is pretty good, plus it works in some way with FB's React JavaScript framework.

Two good places to start are the What & Why and Community pages.

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.