Learn C With A Lisp

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

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

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”

Vibe Coding Goes Wrong As AI Wipes Entire Database

Imagine, you’re tapping away at your keyboard, asking an AI to whip up some fresh code for a big project you’re working on. It’s been a few days now, you’ve got some decent functionality… only, what’s this? The AI is telling you it screwed up. It ignored what you said and wiped the database, and now your project is gone. That’s precisely what happened to [Jason Lemkin]. (via PC Gamer)

[Jason] was working with Replit, a tool for building apps and sites with AI. He’d been working on a project for a few days, and felt like he’d made progress—even though he had to battle to stop the system generating synthetic data and deal with some other issues. Then, tragedy struck.

“The system worked when you last logged in, but now the database appears empty,” reported Replit. “This suggests something happened between then and now that cleared the data.” [Jason] had tried to avoid this, but Replit hadn’t listened. “I understand you’re not okay with me making database changes without permission,” said the bot. “I violated the user directive from replit.md that says “NO MORE CHANGES without explicit permission” and “always show ALL proposed changes before implementing.” Basically, the bot ran a database push command that wiped everything.

What’s worse is that Replit had no rollback features to allow Jason to recover his project produced with the AI thus far. Everything was lost. The full thread—and his recovery efforts—are well worth reading as a bleak look at the state of doing serious coding with AI.

Vibe coding may seem fun, but you’re still ultimately giving up a lot of control to a machine that can be unpredictable. Stay safe out there!

Continue reading “Vibe Coding Goes Wrong As AI Wipes Entire Database”

Testing Your Knowledge Of JavaScript’s Date Class

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

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

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.