Tech Talk 1: The Back-end Theory

I'm going to make the very reasonable assumption that ChatGPT will not be able to design and implement my website entirely on its own.  Well, this isn't an assumption as much as it is evidence after the fact, since I've already had to put in some of my own digital sweat equity to get the site to its current state:

Our current website in its mobile habitat.

Before starting the project I also had some preconceived notions about what I wanted to use to build my site, but I thought it was worth asking ChatGPT anyway, lest it come up with surprising or amusing answers.

What programming language should I use for my backend and why?

• Python
• Javascript (Node.js)
• Java
• Ruby
• Go (Golang)

That's a reasonable automated response.  ChatGPT also provided some rudimentary pros and cons for each suggestion that also proved to be sensible.  I had a more enjoyable experience asking a machine about its opinion on programming languages than my fellow meatbags.  Software engineers tend to be opinionated about the most pedantic things.  If I asked a competent, trusted professional "Is language X useful for building a website?" the rest of the exchange is not unlikely to follow this pattern:

"No." 

"Why?" 

"Because it sucks."

Incidentally for those of you dying to know where I fall in the software dogma landscape, I'm an emacs person.  I like emacs.  I would switch to vi in a heartbeat if I weren't too lazy to spend time retraining my brain to deal with new key bindings, because it's ubiquitous.  Nowadays most of my work is done in IDEs online, so even my emacs knowledge begins to suffer.  This is how morally dubious my heart is in the computer science world.  I would sell out my cherished text editor just to get some blog views.

All of the languages above will more than get the job done, and I personally, would be happy to work in any of them if given no options.  But I have options, so some make me happier than others.

A note of advice if you're staffing up, don't choose the one that's quickest to prototype, or the one that everyone thinks is cool, or the one everyone else in your industry is using.  Choose the one that the people you're hiring have the most experience in.  Everything else can be adjusted.  Software engineers have their preferences, but keep everyone focused on the fact that solving the problem is the fascinating part.  The tool is secondary.

Also, don't fall for the trap of thinking the languages are that different.  A good software engineer is a good software engineer.  They may feel more comfortable in one language, but they can quickly learn another to become productive.  Remind them of this when they claim they don't work on that long discarded Rails app.

That doesn't mean there aren't trade-offs, though, so let's look at ChatGPT's suggestions in the reverse order that I'd select for this project.  Again, this doesn't mean I wouldn't be unhappy to use any of them if a particular ecosystem or employer required it, so don't sulk if I didn't choose your favorite tool:

Ruby

Ruby and Python are very similar in the spaces they serve, their strengths, and their weaknesses.  They're great for being productive immediately and Ruby, in particular, gained a foothold in the mid-aughties (I need every excuse possible to use that phrase) with its heavy reliance on Rails - an extremely opinionated web framework that often boosted productivity even more.

In the last few years, Ruby's popularity has fallen off a bit.  For that reason alone, there's an ever-so-slight risk that its documentation and development may lag slightly behind the other languages.  In addition, the other languages took a page from Rails usability and created their own variations, so Ruby's immediate advantage isn't as great as it was, say, 15 years ago.

Go

Go offers a lot of stability and scalability with its ecosystem.  Its concurrency model, in general, makes programming for scalability much easier than in other languages (much like one of my all-time favorites, Erlang).  In the website space, it has some frameworks, but nothing nearly as mature as the other languages.  If we have to write applications that support our front-end application, I think Go's an excellent choice, but we're not there yet.

Java

If I knew that this site would definitely scale up and need teams of developers nearing or in the 100s, I may be tempted to use Java immediately.  It's well-used among the developer community and its tooling is generally built to support websites that scale massively without needing to have every engineer concern themselves with underlying performance fundamentals.  However, it does tend to require more boilerplate to set up and maintain (though it's improved greatly over its lifetime) and still requires more initial compute resources when starting up a machine, making it a less desirable choice when we're on a shoestring budget and staffing isn't our biggest cost concern.

Javascript

Let's be honest, one way or another I'll be using Javascript for this project.  Whether or not I'll be using it for server-side programming is another matter.  From that perspective, Javascript is as equally capable as Ruby or Python.  It also has similar tooling and every Backend as a Service that offers any free or cheap plan starts (and to my chagrin, occasionally ends) with Javascript.  As far as I can tell, people tend to dislike it for one of three reasons:

1. Some of the funky syntax and unusual logic choices from its original incarnation.  Much of this has since been corrected, especially in ES6, and it's now a pure joy to switch between its functional and imperative modes.  Sure, it still has its warts, but so does every other language - programming or human (as Grammarly constantly reminds me).
2. "It's a front-end language" It's not uncommon to encounter snobbery in the software engineering world, often for the dumbest of reasons.  Front-end development has acquired a similar yet distinct set of problems to solve that require as much design and forethought as any back-end system, even if it doesn't get that credit.  Solving a tough problem in the simplest possible fashion is still the definition of an elegant solution regardless of where that solution resides and what tool we use to solve it.
3. It's too fragmented.  This one holds more water for me.  There's been a huge push to move all of the logic onto the client, to make the application feel more native to the user's sensibilities.  While the reasoning is sound - better usability - sometimes we don't stop and think if the implementation goes too far.  A slick site is nice.  A functioning one is necessary.  Concentrating too much on the former can impair the latter.  I like the myriad of front-end tools and am also prone to getting sucked in by their siren song.  However, when there are too many tools - seemingly exploding every week - it's hard to choose something for fear that it may become obsolete before you've grown comfortable with it.

Python

There are a few reasons I'm choosing Python for our back end.

• I like it.  It has a clean syntax and is as immediately productive as Javascript or Ruby.
• I've had significant exposure to it as either a glue tool at my job as a software engineer or through various hobby projects.
• It has an ecosystem as robust as any other.
• In an attempt to showcase some of the trade-offs that go into software engineering, it's good to have some variety.  Very few companies run monolithic stacks.  Since we'll have to use Javascript elsewhere, this provides a good complement.
• It's the lingua franca for machine learning and AI tools.  I strongly suspect we'll delve into the space (this whole blog is about my collaboration/struggle with Generative AI, so it's not a stretch to expect this).  Choosing something that keeps our basic skills in the language up-to-par is a prudent choice.

Choosing a framework for the backend is the logical next step.  In the case of the other languages, it's fairly straightforward: 

• Ruby pairs with Rails
• Go pairs with nothing I'm familiar with, so I wouldn't choose it for web development.
• Java and Spring Boot go together like peanut butter and jelly.  Not always the most exciting combination, but always a reliable standard.
• Javascript and Express are a logical pairing (for me at least).

But Python? Python has two strong alternatives - Django and Flask.  I like old-school jazz and drinking, so both are logical choices.  If I knew for certain that I'd be scaling this up more in terms of both staffing and computing resources, I'd opt for Django.  It requires slightly more overhead and has an odd boilerplate project/site structure (for my brain, at least), but it's very mature and isn't overbearing.

However, because I expect the site to remain small and want to be more explicit when I do add new functionality for my readers, I'm starting with Flask, which is more of a build-it-as-you-need-it framework.

Of course, all of this may change over time, but that's the software development lifecycle - deny that any massive problem with your infrastructure exists until it becomes untenable; then announce an over-engineered rewrite that takes years to complete; finally, run that new system alongside the existing one while claiming the legacy system retirement will begin during the next planning cycle, but never prioritize it.

Once ChatGPT figures this out, BEWARE!  Then we know it's on to us.

Until next time my human and robot friends.