Title photo
frugal technology, simple living and guerrilla large-appliance repair

Regular blog here, 'microblog' there

Many of my traditional blog post live on this site, but a great majority of my social-style posts can be found on my much-busier microbloging site at updates.passthejoe.net. It's busier because my BlogPoster "microblogging" script generates short, Twitter-style posts from the Linux or Windows (or anywhere you can run Ruby with too many Gems) command line, uploads them to the web server and send them out on my Twitter and Mastodon feeds.

I used to post to this blog via scripts and Unix/Linux utilities (curl and Unison) that helped me mirror the files locally and on the server. Since this site recently moved hosts, none of that is set up. I'm just using SFTP and SSH to write posts and manage the site.

Disqus comments are not live just yet because I'm not sure about what I'm going to do for the domain on this site. I'll probably restore the old domain at first just to have some continuity, but for now I like using the "free" domain from this site's new host, NearlyFreeSpeech.net.

Sat, 12 Jan 2019

My article on SICP and HtDP was linked on Hacker News, and here's what I said in the comment thread

I went to Hacker News, as I do, and I found an article I wrote some time ago linked in the feed.

In case you need to know more before you click, here is the title of my original article on the books Structure and Interpretation of Computer Programs and How to Design Programs: If not SICP, then what? Maybe HTDP?.

The Hacker News link prompted a very long discussion.

Here is what I wrote in that thread:

I'm the author of the original blog post, and I wanted to say that SICP, as well as HtDP, and even a book like Robert Sedgewick's Computer Science (https://www.amazon.com/Computer-Science-Interdisciplinary-Robert-Sedgewick/dp/0134076427/). are in a completely different category than more mainstream how-to-program books (like anything from O'Reilly, Manning, No Starch, Pragmatic Programmers) and even the other popular college texts like Y. Daniel Liang's Introduction to Java Programming and Data Structures (https://www.amazon.com/Introduction-Programming-Structures-Comprehensive-Version/dp/0134670949/) or the book in my intro class, Tony Gaddis' Starting Out with C++: Early Objects (https://www.amazon.com/Starting-Out-Early-Objects-9th/dp/0134400240/).

Supposedly all of these books assume (or at least allow for) no background in programming, but I think the reality is that taking SICP or even HtDP into the intro class at a non-elite university or a community college would be a complete non-starter and/or abject failure.

What I'm trying to say is that there is a place for both of these approaches: A deep look into computer science, and the nuts and bolts of basic "get it done" programming.

Should both of these things happen in a single class, or series of classes? I think the answer is yes. But how to do that and not leave non-elite students back on the road is another matter.

I believe that the HtDP authors think that the "domain-specific knowledge" required of SICP was a barrier.

And I also understand how advanced CS students think that a class focused on how to manipulate strings, use loops, deal with variables of various types, and work with basic logic in the context of a specific computer language is NOT computer science.

But in my view, most students -- and all average students -- need to crawl quite a way, then walk, before they can run.

Even Sedgewick's Computer Science, which focuses on Java and has a wealth of great questions/assignments all along the way, could really be a barrier to students who aren't steeped in math and science. I learned some math while going through the book, but I didn't learn so much programming. Liang's approach might be too basic for someone who has already done years and years of programming but is way more approachable for those who have not.

My guess is that many professors tried SICP and had a very poor rate of success. I fully support a selective class that says, "this is very hard, but you will learn a lot and look at the world in a different way, and if you really want to understand computer science, this is the class for you."

But there also needs to be more of a gateway class for future programmers (not necessarily graduate-school-bound CS majors) that eases them into the world of writing code. Offering the basics and sneaking in some CS seems better than doing it the other way around.

In a way, it's like the difference between carpentry and architecture. You can teach people who want to build houses how to design them, but at some point they're going to have to get out a saw, hammer and nails and make something happen.

What I'm trying to get at here is the idea that computer programming and computer science are different things taught in different ways. It's possible and probably advantageous to teach both at once, but there's quite a devil in those particular details, and nobody seems to be happy with how it's done. The CS-first, math-problems-out-front approach has the potential to alienate non-elite students and should probably be restricted to those who know what they're getting into.

Sun, 18 Nov 2018

A local web-based program might not be such a bad idea

I just wanted to make a simple GUI program. You know, one that lives on your computer hard drive and creates, modifies and saves files, then uses that data to do things. Oh, and I wanted it to be cross-platform, meaning it would work on Windows, MacOS and Linux with little or no modification.

Sounds easy, right?

Previously: Everything doesn't have to be a web program

Well, despite the fact that local GUI programs aren't exactly dead — web browsers are GUI programs, for Christ's sake, the average coder is less and less interested in writing programs that run on desktop and laptop computers and almost exclusively interested in creating web apps that run in a browser and that maybe, possibly get magically turned into mobile phone apps through some voodoo with React Native or a similar and massive hunk of code.

"But I don't want to worry about security and establishing a account system for my app, which really should just run as a local program on a local PC," I said.

Read the rest of this post

Mon, 17 Sep 2018

Everything doesn't have to be a web program

Desktop GUI programming used to matter. Just about every programming language offered a way to build a desktop application that wasn't tethered to the terminal.

And many programming languages either ship with or allow the installation of modules that allow for a desktop GUI.

Javascript, unfortunately, didn't do it in a lightweight way. While I've heard rumblings of some kind of React-based way to create a desktop GUI via Node.js (aka Javascript in your local terminal), the language of the web (and now servers everywhere) has latched on to Electron, basically a full Google Chrome browser in a local window.

I just want a GUI to be a GUI. Java has the once-new (wasn't everything) JavaFX, and the still-old Swing, but there's no excitement and few tutorials. That doesn't mean JavaFX isn't one of your best bets in creating desktop GUI software. For better or worse, it is.

The computing world really wants you to write GUI applications in whatever frameworks Microsoft or Apple offer. I want something cross-platform. I'm not interested in Swift, Objective C or C#, though I do have to admit that C# code looks as clear as anything out there.

While I like the apps I see written in QT, which is cross-platform, that just doesn't seem to be my thing. Sure, I've coded in C++, but it's not something I'm hankering to revisit.

I've written a little Perl, but that holds little attraction at this point.

My language of choice at the moment is Ruby. It should be Java (or Clojure, Go, Elixir, Haskell ... you get the idea), but it's Ruby.

Ruby used to have people who were sort of interested in GUIs. There was a RubyFX project at one point. Abandoned.

Ruby Shoes was clear and concise. For some reason it now only runs with JRuby, the Ruby on Java. The MRuby (aka "regular" Ruby) version was abandoned.

There's a GUI that still ships with Ruby. It's the same one that ships with Perl and Python.

It's called Tk.

Tk is old school. I think people cared about it once. It is tied to the TCL programming language. Those ties are close enough that I considered figuring out how TCL works and coding in that.

But Tk still works, and it is sort of, kind of still under development. I think.

The problem is that there are few resources for learning Tk with Ruby or Perl. I have been using the Tkdocs.com website, and I managed to get the first sample GUI program working. It's a simple converter from feet to meters, and I've been able to start hacking together my own program from that shell.

I'd love a book on Tk and Ruby that was published in the past 10 years. I might just have to settle for an old book.

For some reason or maybe a few, I have avoided coding in Python. I might have to change my mind. There is more interest in Tk in the Python world. I think there are even recent books on the Python and Tk. There might even be newer tutorials on the web. I've stumbled across a book from Packt, but I haven't investigated the web resources.

Right now my command-line application -- which is working, by the way -- is written in Ruby. So I'd love to stay in Ruby and figure out Tk.

But I'm at a crossroads. I feel like I'm reinventing the wheel by trying to code a GUI application in Ruby. Maybe I'd have an easier time reimplementing everything in Java. I'm sure I'd be better off going with Python.

I could also do this as an Android app. That way I could use it on my phone and tablet and have a GUI framework (that being Android itself) that isn't mired in the 2000s.

For those who say, "just do it as a web app," I don't want to deal with the security issues of running a web-exposed service. Maybe I should figure that out. This still feels like a desktop GUI application. There's no reason for it to be a browser-controlled, web-based service.

If I stick with Tk, I'm not sure a TCL- or Python-focused book will get me where I need to be. I might have to travel back in time to 2008, when Ruby was hot, and grab whatever Ruby GUI books were out then.

I thought I wanted to make my blogPoster Ruby script more class-based (currently it is 0% toward that goal) and leave the GUI for later. But now I'm thinking GUI first.

I'm reading the excellent "Head First Ruby" book, and that is doing a great job of teaching me how classes work in Ruby. I'm excited about that, and it pulls me in yet another direction.

This is what learning programming and just programming (where you're always learning) are all about. That's what I'm telling myself, anyway.

Mon, 14 May 2018

Clojure episodes from the CaSE Podcast -- and they have transcripts

Here are three excellent podcasts (each with a transcript) about Clojure from the CaSE (Conversations about Software Engineering) Podcast, all with Joy Clark as host:

Tue, 24 Apr 2018

A messy ending to the installation of JDK 10 in Windows

I'm aiming to learn more Java, and in preparation decided to replace Java 8 with Java 10 on my Windows 10 laptop.

The first time through the installer, I only got the JRE and not the full JDK. Then I removed my old JDK installations via Windows' add-and-remove-programs utility and re-installed the JDK software via Oracle's bundle.

The second time I got the full JDK, but a check of java and javac on the Windows command line showed java working but javac not.

A quick Googling brought up a Stack Overflow question (and answer) that told me I had to add the JDK to my Windows path.

Once I did that, javac worked. Since the JDK comes from Oracle with a GUI installer, even if I somehow missed the checkbox where the installer modifies my system's path, having to Google and then do this manually is a messy ending to installing the JDK. If I'm installing the JDK, I want it in my path, and that should be the default.

It's an unnecessary hurdle for new programmers or people who aren't the best amateur sysadmin.

Thu, 22 Mar 2018

What is Reason, the programming language?

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.

Mon, 26 Feb 2018

If not SICP, then what? Maybe HTDP?

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

Sun, 25 Feb 2018

The Symbolics Lisp Machine was a real thing

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:

A Symbolics Lisp Machine

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:

I reserve the right to add to this article.

Mon, 29 Jan 2018

Ruby String Methods (Ultimate Guide) - a great tutorial from rubyguides.com

Rubyguides.com does a great job presenting all the things you can do with strings in Ruby.

How to change permissions on all directories in a directory while leaving the files alone

I have a situation where I want all of the directories in my project to have 755 permissions while all files have 644 permissions.

All of the files have the same extension, so it's easy to single them out:

$ chmod 644 *.txt

But what do you do for directories? I did a search, and a Linux Questions thread gave me the answer:

$ find . -type d -exec chmod 755 {} \;

Works like butter.