Software Development

791 Articles

Recto: In Case Programming Isn’t Hard Enough

August 17, 2025 by 20 Comments

There’s long been a push to stop writing code as a sequence of lines and go to something graphical, which has been very successful in some areas and less so in others. But even when you use something graphical like Scratch, it is really standing in for lines of code? Many graphical environments are really just interface builders, and you still write traditional code underneath. [Masato Hagiwara] asks the question: Can you write code that is actually a 2D graphic? Where the graphical layout isn’t a cover for code, but is the code itself? His answer is Recto.

Whereas a C program, for example, has a syntactical structure of lines, a Recto program has rectangles. Rectangles can contain data, and their structure naturally mimics the kinds of structures we usually use: columns, rows, matrices, and so on. Rectangles can also contain… wait for it… other rectangles. Special rectangles act as dictionaries or sets.

We thought this sort of reminded us of Lisp, and, in fact, [Hagiwara] makes that clear later in the post. The real problem is how do you…write? draw?… this kind of code? At first, he laid it out in a spreadsheet before compilation. Now he’s built an editor for it, and you can try it in your browser. There’s also a limited-feature compiler that can handle simple programs.

[Hagiwara] goes on to show how this representation would work for natural human languages, too. Honestly, we have enough trouble with English and the few other human languages we struggle with, but it is interesting to contemplate.

If you like strange languages, there’s Piet. Not that either of these is the weirdest we’ve ever seen.

Learn C With A Lisp

August 9, 2025 by 19 Comments

One reason Forth remains popular is that it is very simple to create, but also very powerful. But there’s an even older language that can make the same claim: LISP. Sure, some people think that’s an acronym for “lots of irritating spurious parenthesis,” but if you can get past the strange syntax, the language is elegant and deceptively simple, at least at its core. Now, [Daniel Holden] challenges you to build your own Lisp as a way to learn C programming.

It shouldn’t be surprising that LISP is fairly simple. It was the second-oldest language, showing up in the late 1950s with implementations in the early 1960s. The old hardware couldn’t do much by today’s standards, so it is reasonable that LISP has to be somewhat economical.

With LISP, everything is a list, which means you can freely treat code as data and manipulate it. Lists can contain items like symbols, numbers, and other lists. This is somewhat annoying to C, which likes things to have particular types, so that’s one challenge to writing the code.

While we know a little LISP, we aren’t completely sold that building your own is a good way to learn C. But if you like LISP, it might be good motivation. We might be more inclined to suggest Jones on Forth as a good language project, but, then again, it is good to have choices. Of course, you could choose not to choose and try Forsp.

A Gentle Introduction To Fortran

August 4, 2025 by 75 Comments

Originally known as FORTRAN, but written in lower case since the 1990s with Fortran 90, this language was developed initially by John Backus as a way to make writing programs for the IBM 704 mainframe easier. The 704 was a 1954 mainframe with the honor of being the first mass-produced computer that supported hardware-based floating point calculations. This functionality opened it up to a whole new dimension of scientific computing, with use by Bell Labs, US national laboratories, NACA (later NASA), and many universities.

Much of this work involved turning equations for fluid dynamics and similar into programs that could be run on mainframes like the 704. This translating of formulas used to be done tediously in assembly languages before Backus’ Formula Translator (FORTRAN) was introduced to remove most of this tedium. With it, engineers and physicists could focus on doing their work and generating results rather than deal with the minutiae of assembly code. Decades later, this is still what Fortran is used for today, as a domain-specific language (DSL) for scientific computing and related fields.

In this introduction to Fortran 90 and its later updates we will be looking at what exactly it is that makes Fortran still such a good choice today, as well as how to get started with it.

Continue reading “A Gentle Introduction To Fortran” →

AI Code Review The Right Way

August 1, 2025 by 29 Comments

Do you use a spell checker? We’ll guess you do. Would you use a button that just said “correct all spelling errors in document?” Hopefully not. Your word processor probably doesn’t even offer that as an option. Why? Because a spellchecker will reject things not in its dictionary (like Hackaday, maybe). It may guess the wrong word as the correct word. Of course, it also may miss things like “too” vs. “two.” So why would you just blindly accept AI code review? You wouldn’t, and that’s [Bill Mill’s] point with his recent tool made to help him do better code reviews.

He points out that he ignores most of the suggestions the tool outputs, but that it has saved him from some errors. Like a spellcheck, sometimes you just hit ignore. But at least you don’t have to check every single word.

Continue reading “AI Code Review The Right Way” →

Testing Your Knowledge Of JavaScript’s Date Class

July 21, 2025 by 18 Comments

JavaScript is everywhere these days, even outside the browser. Everyone knows that this is because JavaScript is the best programming language, which was carefully assembled by computer experts and absolutely not monkeyed together in five days by some bloke at Netscape in the 90s. Nowhere becomes this more apparent than in aspects like JavaScript’s brilliantly designed Date class, which astounds people to this day with its elegant handling of JavaScript’s powerful type system. This is proudly demonstrated by the JS Date quiz by [Samwho].

Recently [Brodie Robertson] decided to bask in the absolute glory that is this aspect of JavaScript, working his way through the quiz’s 28 questions as his mind gradually began to crumble at the sheer majesty of this class’ elegance and subtle genius. Every answer made both logical and intuitive sense, and left [Brodie] gobsmacked at the sheer realization that such a language was designed by mere humans.

After such a humbling experience, it would only seem right to introduce the new JS convert to the book JavaScript: The Good Parts, to fully prepare them for their new career as a full-stack JS developer.

Continue reading “Testing Your Knowledge Of JavaScript’s Date Class” →

Coroutines In C

July 14, 2025 by 20 Comments

It is virtually a rite of passage for C programmers to realize that they can write their own cooperative multitasking system. C is low-level enough, and there are several ways to approach the problem, so, like Jedi light sabers, each one is a little bit different. [Christoph Wolcher] took his turn, and not only is his system an elegant hack, if that’s not an oxymoron, it is also extremely well documented.

Before you dig in, be warned. [Christoph] fully admits that you should use an RTOS. Or Rust. Besides, after he finished, he discovered the protothreads library, which does a similar task in a different way that is both more cool and more terrible all at the same time.

Once you dig in, though, you’ll see the system relies on state machines. Just to prove the point, he writes a basic implementation, which is fine, but hard to parse and modify. Then he shows a simple implementation using FreeRTOS, which is fine except for, you know, needing FreeRTOS.

Using a simple set of macros, it is possible to get something very similar to the RTOS version that runs independently, like the original version. Most of the long code snippets show you what code the macros generate. The real code is short and to the point.

Multiprocessing is a big topic. You can have processes, threads, fibers, and coroutines. Each has its pros and cons, and each has its place in your toolbox.

Measuring The Impact Of LLMs On Experienced Developer Productivity

July 11, 2025 by 74 Comments

Recently AI risk and benefit evaluation company METR ran a randomized control test (RCT) on a gaggle of experienced open source developers to gain objective data on how the use of LLMs affects their productivity. Their findings were that using LLM-based tools like Cursor Pro with Claude 3.5/3.7 Sonnet reduced productivity by about 19%, with the full study by [Joel Becker] et al. available as PDF.

This study was also intended to establish a methodology to assess the impact from introducing LLM-based tools in software development. In the RCT, 16 experienced open source software developers were given 246 tasks, after which their effective performance was evaluated.

A large focus of the methodology was on creating realistic scenarios instead of using canned benchmarks. This included adding features to code, bug fixes and refactoring, much as they would do in the work on their respective open source projects. The observed increase in the time it took to complete tasks with the LLM’s assistance was found to be likely due to a range of factors, including over-optimism about the LLM tool capabilities, LLMs interfering with existing knowledge on the codebase, poor LLM performance on large codebases, low reliability of the generated code and the LLM doing very poorly on using tacit knowledge and context.

Although METR suggests that this poor showing may improve over time, it seems fair to argue whether LLM coding tools are at all a useful coding partner.