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/).

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.

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

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.

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:

• Clojure with Alex Miller (Aug. 3, 2017)
• ClojureScript with David Nolen (Nov. 9, 2017)
• Problem Solving and Clojure 1.9 with Rich Hickey (May 3, 2018)

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.