Paolo Amoroso's Journal

development

A few days ago I blogged on why I cancelled my paid plan to Replit.

It was a short personal note to record my decision as I often do to document my experiences with tools and products, possibly of interest to the few dozen regulars per day who read my blog.

A day on the home page of Hacker News, over 170 votes, almost 150 comments, and nearly 20,000 views later, it became clear I underestimated the impact of the post. I should have expected mixing parting ways with a product by a red hot startup like Replit, and a red hot technology like AI, could generate some attention.

The discussion in the comments on Hacker News is pretty interesting and I can't do more than reply to a few. But I'd like to address a couple of issues raised in the comments.

Some readers wondered whether I feel entitled to great products at little or no cost, thus making it difficult for companies to survive and innovate. I'd actually be happy to pay for Replit at the new higher price. But my shift to Lisp, and the diverging direction of Replit's evolution, widen a gap between cost and benefits that reduces the value of Replit to me, possibly even at the old lower price.

Others pointed out I'm a niche user while Replit caters to an audience of mainstream developers with different needs. This is true. Replit's features make it a great value for those users such as web developers. For example, deploying a web app by just listening to a port is beyond magical. But this is not what I need.

Replit cofounder Faris Masad also read my post and invited me to a video call. He gave me the opportunity — thanks! — to elaborate on the issues raised in the post and share my feedback on what Replit is missing for Lisp. Faris listened carefully, as he said improving Lisp support can improve the experience also with other languages.

This conversation and the other feedback convinced me to follow more closely the evolution of Replit and reevaluate my decision.

#development #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

I cancelled my annual Replit Hacker plan and I'll let it lapse at the end of December of 2023.

Replit is a popular and growing multi language development environment in the cloud. I've been subscribing to the Hacker plan for the past few years and it worked well for my Python projects, as such an online environment is a good match for my chromeOS lifestyle. But two changes made me reconsider the value of the product.

The first is Replit changed its paid tiers by raising the price of my plan and removing some features. I actually saw it coming when Replit began receiving massive funding by major investors, who are likely pressuring the company to reduce costs and turn profits. Still, this left a sour taste as it felt like a bait and switch.

The other change is my shift of focus back to Lisp, the programming language I love most and know best.

Replit doesn't work well with a highly interactive language like Lisp. It doesn't directly support any Lisp dialects and its default code editor provides little or no integration with a running Lisp image. Moreover, the files created or uploaded outside of the editor are often not preserved across sessions. If I have to install and maintain a full Lisp system in the Linux shell of a Replit workspace, I might as well install it locally on my desktop computer.

Finally, like other development tool vendors, Replit is doubling down on AI coding features which affect the cost of paid plans. But I'm not interested in this as the whole point of my hobby programming is to write all the code myself and learn from the experience.

Update

This post was shared on Hacker News and I blogged about the reactions.

#development #Python #Lisp

Discuss... Email | Reply @amoroso@fosstodon.org

As a hobby programmer, my greatest skill gap is achieving good software design. There's very little useful literature on problem decomposition and the main way of learning design seems a byproduct of writing lots of code.

I hope discovering and reading A Philosophy of Software Design, a book by John Ousterhout of Tcl fame, will make a difference.

The book starts by defining complexity in software and explaining its effects on the evolution and growth of systems. Along with this it defines the module, a unit of system decomposition that helps reason about design issues. The remainder of the book provides some key red flags to spot complexity, and presents principles and coding practices that improve design while controlling complexity.

Although general, these principles are precise enough to be applicable and effective. The principles and the red flags gently funnel a system along a path through the design space that progressively shapes the system to reduce complexity.

The strength of A Philosophy of Software Design is the guidance it provides helps achieve good design even without highly structured processes or step by step instructions. Ousterhout acknowledges with humility the vastity of the endeavour and doesn't promise silver bullets or instant solutions.

Another thing I like is the few code samples are surprisingly short, clear, and effective at making a point. Although the code is in Java and C++, the material applies to any language.

#books #development

Discuss... Email | Reply @amoroso@fosstodon.org

I'm reading the book Writing An Interpreter In Go by Thorsten Ball, which I got along with the sequel Writing A Compiler In Go.

I have always been fascinated by compilers and seeked good learning resources. These books bridge the gap between short tutorials that teach how to write an arithmetic expression parser, and 900 page compiler tomes packed with math.

I don't know Go, but Ball designed the books and sample code so that no knowledge of the language is required other than a general programming background. All I know about Go comes from reading the Wikipedia entry and a short reference. Yet the code of Writing An Interpreter In Go is easy to understand, reads as pseudocode, and is arranged in short blocks rarely spanning more than a page.

I really love Writing An Interpreter In Go.

The book presents the material in a smooth and clear progression and anticipates the questions the reader may have. For example, whenever I wonder why some code does or doesn't do something, the next paragraph acknowledges and addresses the hurdle.

I hope Ball's books will help me rewrite the assembler of my Suite8080 suite of Intel 8080 Assembly tools, finally replacing the ad hoc syntacting analysis mess with a true and extensible parser.

#development #books

Discuss... Email | Reply @amoroso@fosstodon.org

I assumed in Turbo Pascal for CP/M, when printing to a terminal, writeln wraps lines longer than the screen width. A quick test under CP/M-86 on the V20-MBC proved such lines are truncated instead. In hindsight it makes sense, as there's limited output state on a terminal system with no frame buffer.

#v20mbc #retrocomputing #development

Discuss... Email | Reply @amoroso@fosstodon.org

Back in the CP/M and MS-DOS days, developers shipped software with all sorts of device drivers to support such basic peripherals and system services as terminals, graphics cards, mices and input devices, memory management, mass storage units, printers, network equipment, and more.

Every developer pretty much had to reinvent the wheel. Yet the industry thrived, and many software houses and independent programmers published successful applications and games.

These days mobile developers gripe about Android fragmentation, a consequence of the success of open platforms like CP/M and the IBM PC.

#Android #development #retrocomputing

Discuss... Email | Reply @amoroso@fosstodon.org

I often search GitHub for libraries and software I need, or browse to discover something interesting. But sometimes I skip or miss several potentially interesting items.

Why?

Because many repos don't provide any information or metadata. Or they don't stand out and get lost. It's a missed opportunity, especially because a few quick fixes may raise the odds of getting the repos noticed.

What can you do to improve the discoverability of your repositories?

First, provide a README.md file with at least one screenshot or other image, a short description of what the code does, installation and setup instructions, and a handful of usage examples.

Next, upload a preview image that social platforms can use to generate a nice snippet with a thumbnail when sharing a link to the repo.

The image may be the same one in README.md. Nothing fancy, even a screenshot of a terminal window running your code will do. On GitHub, you can upload an image to the repo under Settings > General > Social preview.

Finally, add relevant tags to the repo.

If you set up a social image and someone browses the GitHub listing of the repos matching one of your tags, the repos with a social image will stand out prominently. For example, visit the intel-8080 GitHub tag. You can't miss my suite8080 repo, right? It's Suite8080, a suite of Intel 8080 Assembly cross-development tools I'm writing in Python.

These fixes take a dozen minutes and are well worth a try.

#development

Discuss... Email | Reply @amoroso@fosstodon.org

My work on Suite8080 is making me rediscover the Unix M4 macro processing language.

Suite8080, a suite of Intel 8080 Assembly cross-development tools I'm writing in Python, includes also an assembler. I designed the latter to optionally read from the standard input, a feature that gives for free macro processing via a separate tool like m4. I can feed macro Assembly source to m4 and pipe the expanded output into the assembler.

The M4 language is a good choice thanks to its power and ubiquity on POSIX systems.

However, m4 is an obscure tool with a learning curve made steep by the unintuitive quoting and expansion rules. There are few resources and no books or tutorials. The very few code samples are abstract, short, and formatted with little or no whitespace and indentation, which doesn't help readability.

After extensive online research, I put together a list of the best learning and reference resources:

#Linux #development

Discuss... Email | Reply @amoroso@fosstodon.org